Ganz kurze Antwort: ja. 
Wir sind immer dankbar für so ein Feedback - häufig wachsen Eingabemasken einfach historisch mit vielen neuen Funktionen. Wir werden das zum Anlass nehmen, die Mail-Maske umzustricken und analog der Domain-Einstellungen auch in einzelne Tabs aufzuteilen. Einen ersten Entwurf dazu wird's dann schon in 1-2 Wochen geben (ab kommender Woche wird das nämlich schon bearbeitet, weil eh noch ein paar andere kleinere GUI-Änderungen anstehen).
Kommt auf die App an. Viele enhalten bereits Updatefunktionen (WordPress, owncloud, Joomla, ...) - andere wie eben phpMyAdmin noch nicht.
Das LiveConfig-Team freut sich, die Freigabe von Version 1.9.0 (r3657) bekannt geben zu dürfen.
Die wichtigsten neuen Funktionen sind:
Zudem gab es eine Menge Detailverbesserungen und Fehlerbeseitigungen. Alle Details finden Sie im Änderungsverlauf.
Das Update lässt sich - wie immer - reibungslos über den jeweiligen Paketmanager installieren. Viele Funktionen (insbes. DNSSEC, DANE/TLSA, OCSP-Stapling) lassen sich nur mit aktuellen Versionen von Apache/NINX/Postfix nutzen, so dass wir empfehlen, mittelfristig die jeweilige Distribution zu aktualisieren (z.B. auf Debian 8 oder CentOS 7).
Die Anleitungen im neuen Wiki werden übrigens auch ständig erweitert - neu sind die Artikel zu DNSSEC und DANE/TLSA.
Vielen Dank für die Verwendung vom LiveConfig!
Nicht unbedingt - der AppInstaller vergleicht eine SHA-Prüfsumme mit dem Download, daher ist der Transport relativ egal.
gibt es eigentlich bereits ein Lösung, das man den jeweiligen Kunden nur bestimmte Apps zuweisen kann?
Nein. Macht IMHO auch wenig Sinn, da der Kunde ja prinzipiell alles auf seinem Webspace installieren kann.
Sie können aber einzelne Apps generell aus dem AppInstaller ausblenden (http://www.liveconfig.com/de/f…=7615&viewfull=1#post7615).
Eben wurde die Preview von LiveConfig v1.9.0 aktualisiert (r3654). Diese Version ist gleichzeitig "Release Candidate", wenn auch noch nicht alle ausstehenden Änderungen von uns darin enthalten sind. Hintergrund hierfür ist, dass es morgen (09.07.) ein kritisches OpenSSL-Update geben wird, was wir dann kurzfristig integrieren werden und damit das Release erfolgt.
Viele Grüße
-Klaus Keppler
Ging eben online. 
And what's with
sudo -u web1 -H /opt/php-5.4/bin/php-cgi -c /var/www/web1/conf/php54 /var/www/web1/htdocs/###your_php_script###.php(replace "web1" with the affected subscription name, and "###your_php_script###.php" with the path to a real script).
Have you tried to call a phpinfo() file? Does it work or do you get the same error?
phpMyAdmin hat vor wenigen Tagen (ohne weitere Ankündigung...) den Download-Server geändert:
https://www.phpmyadmin.net/new…site-and-downloads-moved/
Wir haben den AppInstaller aktualisiert - nach einem LiveConfig-Neustart oder nach spätestens 24 Stunden (nach dem täglichen Repo-Update) funktioniert die Installation somit wieder.
Viele Grüße
-Klaus Keppler
Please select any hosting subscription (eg. "web1"). Back up the php.ini file for PHP 5.4.x from that subscription (something like "~web1/conf/php54/php.ini").
Then - in LiveConfig - log in as admin, switch to that user (web1), open "Hosting" -> "Webspace", and then edit the php.ini settings for that subscription. Switch "log_errors" to "on".
Wait a minute, then open the website again. If the error persists, please have a look at ~web1/logs/priv/php_errors.log. If the error has gone, please compare the current (new) php.ini file with the one backed up previously (something like "diff ~web1/conf/php54/php.ini /tmp/old_php.ini")
Ja, die übliche Antwort, die man sich anhören darf... (bei anderen Adressaten wohl auch gerechtfertigt)
Ich kann das ja nachvollziehen (wir können von einem Netz aus etwa keine Mails an .mil schicken - schlicht weil .mil-DNS-Anfragen von dort aus ignoriert werden; wenn man den DNS-Lookup über einen anderen DNS ausführt klappt's).
Trotzdem denke ich, dass es in diesem Fall sinnvoller ist, irgendein Relay auf irgendeinem billigen vServer einzurichten und über Policy Routing betroffene Mails über diesen (quasi als Smarthost) zu senden.
Da man mit manchen Mail-Providern öfter Probleme hat, wenn sämtliche Mails einer Adresse dorthin umgeleitet werden [...]
Was für Probleme denn genau?
Wir haben hier ja auch eine Menge Mails an AOL und Google, die aber alle reibungslos durchkommen. Bei AOL muss man halt die Feedback-Loop (FBL) einrichten, bei Google sollte man nicht per IPv6 einliefern (außer die Absenderdomain hat SPF/DKIM). Aber auch prominentere Kunden mit fünfstelligen Mailaussendungen pro Tag machen hier keine Probleme.
Prinzipiell halte ich es für sinnvoller, die Ursache zu beseitigen statt aufgrund der Symptome einfach die Weiterleitung zu verbieten. Wie schon früher in diesem Thread erwähnt schränkt man die Kunden dadurch ein, was vielleicht nicht überall auf Zustimmung stößt.
Uns kam noch die Idee, optional Weiterleitungen komplett für einen Vertrag zu verbieten (wenn z.B. Policies im Unternehmen das nicht erlauben).
Die Limitierung von ausgehenden Mails insgesamt ist eine andere Sache - da LC seit einer Weile ja die I/O-Statistiken für Mails bereits erfasst, wird genau das der nächste Schritt sein (HE war da wohl ein bisschen schneller ;)). Zudem finden sich im Internet Anleitungen, wie man die Zustellung an bestimmte Ziele anhand der Zieldomain oder auch des Ziel-SMTP-Servers limitieren kann (ließe sich auch so einrichten, dass LiveConfig das nicht weiter betrifft).
So lange noch die Postfächer auf dem LiveConfig-Server angelegt sind und E-Mail für die betroffene Domain aktiviert ist, werden die Mails auch lokal zugestellt.
In diesem Fall also: alle noch vorhandenen Postfächer löschen, und anschließend im Kundenaccount unter "Hosting" -> "Domains" die betroffene Domain bearbeiten und dort das Häkchen bei "E-Mails mit dieser Subdomain aktivieren" entfernen.
Nee, wird vermutlich nicht so einfach klappen. Das Passwort-Feld in der SOAP-API darf max. 40 Zeichen lang sein (hängt damit zusammen, dass das LC-intern verschlüsselt und dann Base64-codiert in einem 64-Byte-Feld gespeichert wird).
Eine Möglichkeit wäre es, einfach irgendein Dummy-Passwort für den Import zu verwenden und anschließend in der /etc/dovecot/passwd die Passwörter direkt durch die alten CRAM-MD5-Hashes zu ersetzen (z.B. mit sed). LiveConfig schreibt die Passwörter nämlich nicht ein zweites Mal raus (im Gegenteil - wenn das Passwort erfolgreich gesetzt wurde, lösche LiveConfig es sicherheitshalber aus seiner eigenen Datenbank).
Hilft das weiter? Ansonsten müssten wir vermutlich diese 40-Zeichen-Grenze aufbohren.
Welches Format haben denn die Passwörter aktuell? Beginnen die auch mit "$1$..."?
Die SOAP-API (HostingMailboxAdd()) reicht das angegebene Passwort unverändert an die Lua-Funktion "addMailbox" (Datei dovecot.lua) durch; erst dort wird in ca. Zeile 763 geprüft, welches Format das Passwort hat. Hier ließe sich dann auch die Verarbeitung von einfachen MD5-Hashes integrieren - schicken Sie uns ggf. einfach mal ein Beispiel-Passwort (am besten die Zeichen a-z0-9 durch "#" ersetzen, damit das niemand entschlüsselt
Viele Grüße
-Klaus Keppler
Ursache gefunden, Fehler beseitigt (mit v1.9.0-r3645). War leider recht kompliziert (daher hatte das auch gedauert). Letztendlich sind Verträge dann nicht betroffen, wenn man abweichend vom Angebot eine bestimmte Shell einstellt.
Wir testen die Änderungen noch durch und schreiben automatisierte Tests dazu, damit das künftig sauber funktioniert. Der Fehler schlich sich nämlich bei der rekursiven Prüfung auf übergeordnete Reseller-Einschränkungen mit ein.
Scheinen wohl alle im Sommerurlaub zu sein :cool:
Nein, ab 28° Bürotemperatur gibt's Hitzefrei. Wir melden uns im Oktober wieder. :p
Spaß beiseite: wir haben den Fehler inzwischen gefunden. Das Init-Script für lclogparse wird korrekt installiert (d.h. mit einem Reboot wird der Dienst auch immer gestartet), aber nach der ersten Installation selbst kann es sein, dass unter manchen Bedingungen der Service nicht automatisch gestartet wird. Ist mit v1.9.0-r3644 behoben (sollte ab morgen online sein - wir sind in den letzten Zügen...)
Na, das einfachste ist es doch, die gewünschten Anweisungen einfach in eine .htaccess-Datei zu schreiben.
<IfModule mod_expires.c>
ExpiresActive on
...
</IfModule>Viele Grüße
-Klaus Keppler
... oder einfach mal ein Postfach mit 1MB Quota anlegen und eine Mail mit 700 kB Attachment hinschicken.
Quota-Warnungen gibt's bei Überschreiten von 80% und bei Erreichen von 100% Quota.
Quota-Notify bei vollem Postfach ist bereits standardmäßig aktiv.
Nur der Vollständigkeit halber: lässt sich (als Admin) unter Serververwaltung -> Mail -> Dovecot aktivieren/deaktivieren ("[X] Quota-Warnung aktivieren").
ZitatNotify für Web-Quota lässt sich nur (sinnvoll) über einen Cronjob o.ä. realisieren.
Steht schon länger hier auf der Wunschliste, ich hab's eben mal "offiziell" gemacht.
https://www.liveconfig.com/dev/issues/193
