Beiträge von ñull

    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?).

    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.

    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?

    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?

    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.

    In fact I tried it out before writing. To reproduce:


    • Created a new customer and in it I created a new subscription with a hosting plan that has ssh enabled called testaccount
    • As root I created the /var/www/testaccoun/.ssh/authorized_keys with my public key. Note the missing "t". The entered subscription ID was truncated without warning. The entry field should not allow more characters to prevent this and avoid confusion.
    • I logged in successfully with ssh testaccoun@mydomain.com
    • By default you end up in the home directory /var/www/testaccoun. I executed:

      Code
      $ chmod u+w .
      $ ls -al
      total 28
      drwxr-x--- 7 testaccoun www-data   4096 2012-09-27 15:03 .
      drwxr-xr-x 7 root       root       4096 2012-09-27 15:01 ..
      drwxr-xr-x 2 testaccoun testaccoun 4096 2012-09-27 15:01 htdocs
      drwxr-x--- 2 www-data   testaccoun 4096 2012-09-27 15:01 logs
      drwxr-x--- 2 testaccoun testaccoun 4096 2012-09-27 15:01 priv
      drwx------ 2 testaccoun testaccoun 4096 2012-09-27 15:04 .ssh
      drwxr-x--- 2 testaccoun testaccoun 4096 2012-09-27 15:01 tmp



    As you can see the single dot (the home) has now rw permission.

    Ich würde sagen das Mailman mehr universell einsetzbar ist. Auf der phplist Webseite lese ich:

    Zitat


    phplist is a one-way email announcement delivery system. It is great for newsletters, publicity lists, notifications, and many other uses. (It is different from group mailing list systems like mailman.)


    Ich glaube das man phplist auch gut unabhängig von LiveConfig benützen kann, vielleicht als installierbare Anwendung. Deshalb würde ich Mailman oder etwas äquivalentes bevorzugen. Vielleicht wäre Sympa eine gute Alternative?

    After your explanation about suPHP, I understand that a symlink is not a solution, but you could allow home folder read-write.


    There is no further need to protect the conf, logs and stats folder, because they are not owned by the user and have only group read access. Furthermore the home folder is owned by the user so the user him/herself can change the permission to read-write. I see therefore no reason why LiveConfig won't set the initial home folder permission to read-write for convenience sake.

    The subscription Id is the same as Unix user ID if I'm not mistaken. Since is it is not possible to change the SSH setting of a subscription, you have to delete it and recreate another that has it set differently. After removing a subscription, it refuses to create a new one with the same ID, saying it is already in use. If it is deleted it should be reusable.

    I removed all subscriptions (after removing all email, web domains). Now I try to delete the customer, but it won't let me saying I should first remove all contacts. Where do you remove contacts from a customer? When I click Edit customer you can only choose another "Owner-C" contact, not delete it.

    When I log in as user with

    Code
    su - username

    and try what I often do, namely start mc (midnight commander) then I get permission errors that the user (the application started by the user) is not allowed to create its configuration folder. I then I discovered that the user has no write permission there.


    When this was consciously chosen for a important reason, then my suggestion is to have the home directory where is usually is at /home/username and there you can allow the user to write, without interfering with that important reason. With a symlink you could then bring /var/www/username in the home folder for convenience.

    As administrator you can override many options in the client's subscription. One thing I miss is the SSH access. I would not give bash access to the normal user. As web designer I would like to run drush (Drupal's command line management tool) logged in as the user. When I want to do this type of maintenance I would like to temporary change SSH access to permit bash, login as the user, do my work, logout and reset to the subscription's value. That way all work is done with the right file ownership. Could this SSH override be added?