Beiträge von ñull

  • Grenzen bei der E-Mail Konfiguration?

    Heute fand ich diese Instruktionen für Mailman unter Debian. Sollte wahrscheinlich auch unter meinen Ubuntu funktionieren und anscheinend nicht sehr Kompliziert.


    Meine frage ist, wenn ich das so ausführen würde für einer meine Kunden, was passiert dann nachher, wenn Mailman oder eine andere Lösung in LC integriert wird? Wann ich meine Kunden zu LiveConfig umziehe, will ich sie nicht nachher belästigen mit noch mal eine Änderung. Ich meine, können wir wenigstens wissen welche Mailinglist Lösung Kepler IT unterstützen wird? Das schönste wäre wenn dazu etwas im Roadmap erscheint.

  • SSH und Userrechte

    Ich sollte dafür eigentlich /etc/skel einsetzen können, aber leider hat Liveconfig anscheinend nicht den Standard useradd benützt.


    Ich würde bevorzugen zurück zu kehren zum Standard mit Benutzerverzeichnis in /home/ und benützung van useradd um die Behauptung "Minimalinvasiv" wieder wahr zu machen.

  • Feature request: Home folder write permission

    So the answer is that "LiveConfig" will not change the configuration structure and therefore we will need to implement this work around?


    That, i.m.h.o. is not according to LiveConfig's claim (from your frontpage):

    Zitat

    Minimal-invasive


    Server configuration files are modified as conservative as possible. Their structure remains in the way it is typical for your distribution.


    In standard Linux you can change everything in your home directory. The home directory is yours and you determine what you can do with it and it is always under /home/. That is the idea of ownership in Linux. In that context changing location and making it read-only is intrusive. The way it is implemented makes it impossible for the user to create off-site folders, that in some web applications are needed to create a secure file system. These are all restrictions that need to be "worked around" if you let LC be as intrusive as it is at the moment.

  • xcache and liveconfig

    Zitat von WebOscar

    xcache will not run under FastCGI if mod_fcgid is used, which is - for any reason - almost the default. It will run well, if FastCGI is used with mod_fastcgi, as long mod_fastcgi has a proper setup! What mod you are using for FastCGI?


    What I see is that fcgid is installed:


    Code
    dpkg --get-selections|grep fcgi
libapache2-mod-fcgid                            install


    Beside that I don't see anything related. How would I check? Remember I am using Ubuntu 11.10 here. Should I use another distribution or version?

  • xcache and liveconfig

    Well the problem was that I had not installed libapache2-mod-php5. So the apache configuration was there but still it was running the subscription as fastcgi.


    Feature request: a solution for this problem, like for instance a warning or automatically setting the configuration to a mode that is available or automatically installing the package that is needed.


    Still I have this problem that under Fast-Cgi I cannot check if xcache is really active. Under mod_php I get a positive feedback that the php files of Drupal are cached by using the xcache admin tool, but I fail to enter this tool in fastcgi

  • xcache and liveconfig

    I am used to xcache and would like to know how to set this up with LiveConfig. Does it work with fastcgi? I don't see xcache reported in phpinfo(). My sites are terribly slow since I moved them to LiveConfig and that must be because of the missing caching.


    Thinking it had anything to do with fastcgi I changed the plan to mod_php, but the phpinfo() keeps saying it using fastcgi. Is this a bug?

  • Changing SSL certificate should rewrite Apache config

    By means of import I changed and existing SSL entry to become a valid certificate. The interface allows me to do this, so you suppose that LC will take care of the rest. However I did not see the certificate of the associated domain updated until I entered the domain section and cycled through removing and adding the SSL configuration. Only then the apache configuration was updated and the changed certificates became active on the domain.


    I don't know what happens behind the scenes, but apparently the old cert files remain while new ones are written. I have restarted Apache manually and the old certs remained valid, hence my conclusion that the config files were not updated. May be it would be better when the files keep the same name, because then an Apache restart would be enough (or even not necessary?).

  • SSL vulnarable for BEAST

    I came accross this https://www.ssllabs.com/ssltest/index.html and tested a LiveConfig site with it. Apparently some SSL configuration is missing making it vulnarable for the "BEAST" attacks. To mitigate this I applied the changes in the configuration manually but I think LiveConfig should do that for us by default:


    Code
    SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH



    The other vulnerability called SCREAM is fixed client side, since there are a number of Apache releases that do not support server side disabling of SSL compression yet. After backports are released the SSL compression should be off by default.

  • Feature request: Home folder write permission

    Well thanks (ironical), now with release of the new version of LiveConfig, the home folder is owned by root and write protected. This makes it impossible for the users to even manually create the folders that applications create automatically (.bash_history, .selected_editor, .mc folder, .ssh folder, .fishsrv.pl, .drush, drush-backups, .cache) , making the ssh console connection really very user unfriendly. It will make the use of drush, the Drupal configuration tool, impossible without extensive changes as root. Therefore the feature request remains valid.


    Taking into account your considerations I would reformulate it, to please separate from the home folder all that the user should not touch. That way there is no problem making the user folder writeable and owned by the user, which is the default in all Linux systems when a new user is created. When you go away from that default, you only seek problems.


    I think the goal of LiveConfig or just any Hosting Control Panel should be that it is least intrusive as possible on the default behaviour of the operating system and in this case it is annoyingly intrusive.


    Do you at all agree that a Control Panel should be least intrusive as possible?

  • "eigene DNS-Server"

    Ich wollte gerne wissen wann ungefähr wir diese Funktionalität von primäre und sekundäre DNS erwarten können?


    Ich kann biss jetzt DNS noch weiter verwalten mit meine vorheriges Kontrolpanel, aber irgendwann ist das nicht mehr haltbar.


    Der Zonentransfer Master und Slave hat bis jezt übrigens gut geklappt mit tinydns und sync über ssh. Tinydns braucht nicht die vollständige Zonedateien. Mein jetziges Kontrolpanel lasst bei jede DNS Änderung diesen Makedatei durchlaufen:


    Zitat

    remote: data.cdb
    rsync -az -e ssh data.cdb slavedns.com:/var/lib/svscan/tinydns/root/data.cdb
    data.cdb: data
    /usr/local/bin/tinydns-data


    Ist so etwas bei LiveConfig auch möglich?

  • Frage zu Mailinglisten Manager

    So weit ich begreife haben phplist, mailman und auch Sympa ihren Verwaltungsportal. Bei z.b. Cpanel konnte man nur neue Mailman liste erstellen und alte löschen. Dann gab es nur einen Link zur Mailman eigenes Verwaltungsportal für die Mitgliedsverwaltung usw. Bei ezmlm gab es kein eigenes Verwaltungsportal und Kloxo übernahm dann diese Rolle. Ich denke das LiveConfig nur tun muss was nicht vorhanden ist und das ist für Mailman und Sympa hauptsächlich die Einbindung im Mailsystem.