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?
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?).
Fast response!
Do you allow entering features and bug reports directly in Redmine?
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:
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDHThe 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.
Zeitrahmen (unverbindlich): ab Ende nächster Woche sollten die ersten Tests möglich sein.
Schön! Vielen dank.
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?
+1 APIs zur automatisierten Bestellung von Domains
Schöne Ablenkung; jetzt bleibt durch dieses Diskussionsgeräusch noch immer meine Antwort fällig 
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:
Zitatremote: 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.
I can confirm that then indeed I can rename the conf folder. I think it would be safer then when the conf folder (and others like these) would not be in the home directory.
In fact I tried it out before writing. To reproduce:
$ 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 tmpAs 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?
$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric
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
su - usernameand 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.
The SSH setting of the subscription is set to SFTP/SCP. I tried:
Zitatsu - username
Cannot execute /usr/bin/scponly: No such file or directory
Do we have to write that script ourselves? Would this be the setup?
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?
Fails with the following Error: failed to copy languagepack file
