Beiträge von ñull

    I have two Liveconfig managed servers, A and B. Server A has LC managed DNS-, mail-, database- and webserver. Server B has LC managed database- and webserver. I created a reseller contract with the mail on server A, web and database on server B. I then log-in as the reseller and create an end user contract. I then add a domain for the end user. I only see external DNS as choice. While LC manages the DNS on server A it does not allow me to add domains there.


    Is this a bug or missing feature?

    I tried the following with success:


    - lcclient -k stop
    - rm /etc/liveconfig/lcclient.key
    - lcclient --activate # asks for the new license code
    - lcclient -k start


    I also forgot that the choice of server is when the contract is created, NOT when creating the hosting plan.

    Apparently by mistake I gave the client server also a Business license, which, according to documentation apparently is not what I should have done. It says that Basic or Standard is "erforderlich". Interestingly enough I still was able to add the server and configure it like normal, only I don't see the new server anywhere available when I attempt to assign it to a hosting plan. Could that be because I used the wrong license? Then why does it allow me to add the server with the wrong license?


    If indeed "erforderlich" means that it excludes clients with a Business license, how should I correct my error without breaking the configuration? Or should I?:


    - Remove the server
    - Change the license
    - Add the server again


    How would you change the client license? The same as with liveconfig master?: https://www.liveconfig.com/de/handbuch/server.license.xhtml

    Seht so aus das Apache Option FileInfo jetzt nicht mehr verfügbar ist, aber ich sehe das nicht ernannt im Änderungsverlauf. Bitte doch lieber erwähnen.


    Ich habe es gelöst (wie alle LC Eigenartigkeiten) mit .httpd.conf. Meine nötige Änderungen für Drupal:


    #Allow Drupal .htaccess settings
    <Directory /var/www/contract/htdocs/sites/default/files>
    AllowOverride Options=FollowSymlinks,SymLinksIfOwnerMatch
    AllowOverrideList SetHandler
    </Directory>


    <Directory /var/www/contract/htdocs/>
    AllowOverride FileInfo AuthConfig Indexes Limit Options=Indexes,MultiViews,FollowSymlinks,SymLinksIfOwnerMatch
    </Directory>

    In the description of CustomerGet it tells us that the return value is an array
    (Array mit Kundendatensätzen). This however is not always true. When there is only a single "Kundendatensatz" then it will return this directly without packing it in an array.


    The same can be seen with "Kundendatensatz" subscription.


    Not sure if this consistent throughout the API or only in CustomGet. Sure there is a work around for this but it would be nice when at least the API documenation is not misleading us. Better still when it were true what it says and always return an array.

    After migrating to another server and upgrading from Ubuntu 14.04 LTS to 18.04 LTS, I decided that it has little use to have a separate subdomain for the mails server when this client likely will never expand to more than one server. His domain is also his mailserver domain.


    Then he complained that no email arrived. I looked in the mail log file and discovered this warning notice, that in fact should be an error notice, because mail was not delivered as a consequence:


    Zitat von /var/log/mail.log

    Feb 24 15:00:34 hishost postfix/trivial-rewrite[30655]: warning: do not list domain hisdomain.com in BOTH mydestination and virtual_mailbox_domains


    As work around I decided to remove $myhostname from mydestination :


    Zitat von /etc/postfix/main.cf

    mydestination = localhost.localdomain, localhost #, $myhostname


    After that, email started coming in.


    Not sure if that can be fixed or improved in LC. Until that is decided, in fact I should prevent that LC overwrites this with:


    Zitat von /usr/lib/liveconfig/lua/custom.lua

    postfix.NOUPDATE = true



    But this should also work:


    Zitat von /usr/lib/liveconfig/lua/custom.lua

    postfix.LOCALCONFIG = {
    ['mydestination'] = "localhost.localdomain, localhost"
    }

    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.

    Thread

    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!