Beiträge von ñull

  • Possible bugs hostingplan, subscription, client account propagation

    I noticed that a client was not able to create mailboxes because the domain did not appear in the select box. I then discovered the possible reason. The hosting plan was supposed to be email-only but the reseller had forgotten to activate the email; it had no service at all. This apparently still allowed the reseller to create the domain, but it did not show up in the client's email manager. I think this is bug nr 1. When the hosting plan does not include email, then in no circumstance should the email manager appear in the client account.


    Then I enabled the email in the hosting plan. This change did not propagate to the client account until I deleted the domain and recreated it. Now I don't know what is the expected behavior in this case. Should the change in the hosting plan propagate to the client domain? If so, then this could be considered another bug.


    Since this is a production environment, I am reluctant to do more experiments. May be Herr Keppler & Co can try to reproduce it on a test system? Not very important of course, but I still report it here for completeness.

  • .http.conf in Proxy and skel support

    Thread

    Beitrag
    RE: Server Zertifikat
    […]


    LiveConfig normal auf :8443 laufen lassen, zusätzlich aber eine Domain (z.B. config.example.com) im Webspace via LiveConfig erstellen. Weiterleitungs-Typ Proxy, Ziel: "https://localhost:8443".

    Für "config.example.com" bekommt man ganz normal Zertifikate.
    antondollmaier

    suggests the use of a proxy domain to use LE certificates for LC itself, taking away the administrative hassle of updating and manually installing valid LC certificates.


    From apache 2.4 the default setting is that peer certificates are checked for errors, which makes the proposed proxy solution error out on localhost and anything else that can be wrong with the LC certificate, expiry for instance. I could only get it working when LC had a valid certificate and with the right domain pointing to localhost. Then I thought to be smart and put a .httpd.conf with:


    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerExpire off
    SSLProxyCheckPeerName off


    Unfortunately by default .httpd.conf is not included in proxy virtual domains. The work around is to manually change the apache configuration, but that would be easily overwritten by LC. I could not figure out how to override the responsible LUA apache.buildConfig in custom.lua; LC refused to run. May be because apache.buildConfig is declared as local?


    Another inconvenience issue is with LUA users.addUser in that it does not copy the /etc/skel when a new user is created. This is simply caused by the missing -m switch in the useradd commands.


    Find here the lua files to fix both issues. Could these please be included in a next release? Thank you!

  • Virtual domain specific .http.conf also for Proxy

    Presently the only way to customise Apache configuration is to create a .httpd.conf as root in the subscription home directory which is then included inside every VirtualHost, except Proxy domains.


    Would it be possible to extend this? I would like that each VirtualHost has its own include file, also the proxy ones.


    For instance when the ServerName is virtual.host.com then the included customisation file could simply be .httpd.virtual.host.com.conf . May be as compatibility fall back you could still include .httpd.conf in all virtual domains where no VirtualHost specific inlcude file exists.

  • DNS serial: How it is formed and updated

    Today I added a test subdomain and I am doubting the serial got updated. It says 2017082309 ; serial which suggests that it is the ninth update on the 23rd of August. Today is the 25th so I expected it to be 201708250x (not sure if this was the first change today).


    Aparently at creation the date is used but after that with updates it is only incremented, not changing the date. Not sure, but I though that it was convention to first update the date and then increment. Can that be patched in the next release? Thank you!

  • also-notify and forcing rewrite of /etc/bind/named.conf.options

    I have the following in my custom.lua:


    Code
    bind.LOCALOPTIONS = {
  ['allow-recursion'] = "{ trusted; <my-kvm-host-ip>; }",
  ['also-notify'] = "{ <my-ns2-ip>; <my-ns2-ipv6; }"
}


    I had to update the ns2 ip addresses, but now how do I force LC to rewrite named.conf.options? I tried restarting LC, then rewriting "DNS template" and "Extermal DNS Servers" but it did not change named.conf.options.


    Shouldn't LC add the also-notify without resorting to custom.lua? Isn't it the idea that secondary DNS get notified?

  • In the spirit of Let's Encrypt include it in Basic

    I think the idea behind Let's Encrypt was that no-one would need to be without certificate and therefore they donate the certificates. However LE is not that easy to implement, and some would still go without valid certificate to save money. That must have been also the reason why LC supports it, to make it easier to implement.


    I wonder therefore why Let's Encrypt certificate management is not available in Basic license and that you have to spend some 7€/month more for Standard license, bringing it again out of reach for many users. In comparison for the price difference of €84 per year you can have either an extensive certificate or you can buy a longer validity. Also the disappointment effect of discovering that LC supports it but then seeing the price that is needed.


    That is contrary to the idea of LE. Could you please reconsider this matter? In line with the reasoning to make certificates easy and available for all, wouldn't it be more logical to make it available in all LC licenses? It might give you even a boost in sales when you can market Basic as the most affordable control panel supporting Let's Encrypt!

  • MX and other automatic DNS records should appear in DNS manager

    I don't have a problem that there is a MX record. I do have problem that I cannot override it per domain. In principle this domain needs MX service but not with the local mail server. I don't want it to disappear, I want to override automatic (hidden) behaviour and change the MX to another. If the automatic behaviour would write the MX in the DNS manager then I could change it, but now it is hidden I felt obliged to report this as my complaint.

  • MX and other automatic DNS records should appear in DNS manager

    When you have a mail server with the name mx123.thisserver.com, then with active DNS management, every domain you add to this machine will automatically have mx123.thisserver.com as default MX record that will be visible in the zone file or with this query


    dig thisserver.com @localhost mx


    Please change this imposing behaviour to default behaviour. A way to do it is by changing from "Custom DNS records" TAB to "DNS Records" and show there the proposed MX record editable. This would allow us to put a different mailserver per domain, more my idea of management.


    Small exceptions like this now generate a lot of extra administration time or simply not using LC to manage the DNS at all. This cannot be the intention of the author.

  • bind.LOCALOPTIONS fails

    Had to do with bootstrapping ns A and AAAA registers. Bind kept asking for these records and the bind failure also interrupts the rewriting of the bind configuration.

  • 2FA OTP in a separate field (not the password field)

    When a user saves his password (securely in a encrypted container) in the browser then the OTP will cause the save password dialogue to pop-up every time you log-in. To prevent this I think the OTP should be in a separate field, not appended to the MTP (=More Time Password).

  • Reuse a Let's encrypt certificate between subscriptions / accounts.

    I think I must retract this question. I notice now you can create a certificate at admin level and then assign it to a reseller's end user, which apparently in this case I did. I changed the end user instance of this certificate from Start SSL to Let's Encrypt, but I should have done that on admin level. I tried now to do it on admin level and it seems to have "taken over" the certificate management although there could be a conflict there.


    First of this seems all very confusing and at end user level it should be clearer who in fact really owns the certificate. When admin made certificate then I thing the end user should not be able to touch it or when he does, it should break the dependency chain (remove it from admin).


    Secondly I think it should be clearer in the user interface what is really going on here. On the end user side I could not see that the certificate in fact was made on admin level and assigned to the end user (you can only see this on the admin side). This lead me to make the mistake.


    I cut and paste the certificates from end user to admin now and it was accepted and then enabled the ACME management on it. I don't know if Let's Encrypt will now accept that management was taken over by the new ID. If this is not possible without errors, LC should warn me or make it impossible to do so (instructing me how to do it right). I then disabled the ACME management at the end user side. I now wait and see what happens next renewal attempt, if it will error out because of ID change.