Please run:
sudo -u www-data -H /opt/php-5.4/bin/php-cgi -v
Should look:
~# sudo -u www-data -H /opt/php-5.4/bin/php-cgi -v
PHP 5.4.42 (cgi-fcgi) (built: Jun 14 2015 10:46:39)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
~#Missing librarys will be shown - although the package does install those automatically.
Vielleicht wäre eine Limitfunktion nicht schlecht die je Provider einstellbar ist (Also Summe X pro Stunde)
Öhm. "live.fr", "live.co.uk", "hotmail.de", "hotmail.com", "outlook.com" - landet alles bei Microsoft. Wäre also ein Provider. Wie soll da genau reglementiert werden?
Grundsätzlich würde die Sperre nicht schaden. Effektiver dürfte aber eher die Limitierung der zu verschickenden Mails sein (vgl. cluebringer, vgl. HostEurope).
Welche Möglichkeiten gibt es diese (alten) Passwörter über die SOAP Api ins LiveConfig zu bekommen?
Ganz normal per SOAP übergeben:
https://github.com/LiveConfig/…master/cfximport.php#L744
http://www.liveconfig.com/de/h…e.HostingMailboxAdd.xhtml
Danke für den Tipp, aber als Reseller hab ich keinen Root-Zugriff. Den braucht man wohl für die Installation.
Wie von Martin Krüger bereits geschrieben: Quota-Notify bei vollem Postfach ist bereits standardmäßig aktiv.
Notify für Web-Quota lässt sich nur (sinnvoll) über einen Cronjob o.ä. realisieren.
Was war dann konkret in der mydestination eingetragen? Offenbar lag es ja genau an diesem Eintrag.
Ich habe LiveConfig wie schon zuvor mehrfach Installiert und habe nun das Problem das alle eMail Postfächer keine Mails empfangen können. Ich bekomme als Antwort: unknown user: "test"
Ich habe in wenig Google benutzt und gelesen das ich in der POSTFIX main.cf die Option "mydestination" komplett geleert werden soll.
Du hast "example.com" sowohl als Hostname für deinen Server als auch als DOmainname in LiveConfig verwendet.
Ändere den Hostname auf z.B. "server.example.com" ab, dann klappt's auch mit "example.com" wieder.
Weitere Infos im LC-Handbuch:
https://www.liveconfig.com/de/…server.requirements.xhtml ("Gültiger Hostname")
Sorry, aber gemäß TKG §3 Satz 10 erbringst du durchaus "Dienste zur Telekommunikation" und bist damit meldepflichtig. Spätestens, wenn E-Mail als Dienst erbracht wird (was du bei "Webhosting" ja tust), erbringst du einen meldepflichtigen Dienst.
Gerne hilft die Bundesnetzagentur weiter.
Aber gut, dass du das Problem doch noch gelöst bekommen hast 
Kannst dich ja mal melden, dann kann ich's mir ja anschauen.
du scheinst deinen Server alleine zu nutzen, dann geht das alles.
Bei weitem nicht.
ZitatPHP 5.6 ist schon gut, nur leider unterstützt der Grossteil der Software dies nicht. Also lieber noch ein paar Monate warten...
Oder halt notfalls die PHP-Pakete von LiveConfig installieren und so dem Kunden, der es unbedingt benötigt, die alte Version (5.4 reicht da ja zur Auswahl mit 5.6) anzubieten.
Shopware5 läuft aktuell noch mit 5.4, wird es aber zeitnah nicht mehr unterstützen. Joomla 3.4 läuft auch mit PHP 5.5 besser als 5.4, Typo3 Flow/Neos ja sowieso.
Ähm, nach dem hier und dem Beitrag im anderen Thread gehe ich jetzt davon aus das du deine Kunden alle persönlich betreust?
Teils, durchaus. Ist halt schlichtweg eine Preisfrage.
Alles andere läuft dann auf "Lieber Kunde, kümmer dich um deinen Wartungsvertrag für $CMS, erspart dir auch Ärger mit gehackten Installationen. Außerdem ist mit neuerer PHP-Version die Performance besser sowie bei neueren CMS-Versionen mehr Features dabei." raus.
Wer immer noch Joomla 1.0 hosten muss (ja, gibt es hier auch - noch), darf sich halt nicht über Spamversand oder ausgehende DDoS wundern.
Ich bleibe vorerst mit meinen Servern bei Wheezy...
Weil?
- PHP 5.4 ist EoL
- PHP 5.6 ist DEUTLICH performanter als 5.4
- Dovecot 2.2 nochmal besser als Dovecot 2.1
- Jessie bringt MariaDB
- €dit: Nach den letzten OpenSSL-Fails sollte man es auch vermeiden, auf Wheezy (oder generell alten Versionen!) zu bleiben. Stichwort DH-Parameter.
Ich seh ehrlich keine Gründe, noch bei Wheezy zu bleiben. "Aber mein $CMS kann kein PHP 5.6!" - dann wird's Zeit für ein Update von $CMS 
Apps werden in einem Ordner unterhalb des Webroots installiert. Normale Nutzung ist damit nicht mehr möglich.
cd ~/htdocs; ln -s ../apps/wordpress ./wordpressZitatUnterstützung von negativen Zahlen in php.ini
[r3635] Anzeigen und Bearbeiten des Pfads von zusätzlichen FTP-Accounts
Unterstützung eigener Application-Installer-Repositories
yeah!
Wie schaut's aus mit dem Permission-Bug für Admins?
sicher, dass das unter Debian Jessie funktioniert?
Laut weakdh.org benötigt man openssl >= 1.0.2, bei Jessie ist derzeit 1.0.1k-3 dabei und der Changelog lässt keinen Backport erkennen...
Point taken. Gerade getestet, der Apache 2.4.8 kennt nicht mal den SSLOpenSSLConfCmd.
We're doomed.
Per "find -type f | xargs grep sock | grep tmp"
Besser:
> grep -HR sock /etc/liveconfig /usr/lib/liveconfig
ZitatWeiß jemand, wie man LC von diesem Verhalten, den Socket an der falschen Stelle in /tmp statt an der passenden Stelle unter /var/run/mysqld/ zu suchen, abbringt?
Umstellen auf "db_host=127.0.0.1", dann verwendet LiveConfig nicht den Unix-Socket, sondern die TCP-Verbindung.
LiveConfig-Logmeldungen aus der Zeit vor/nach Bootvorgang (/var/log/liveconfig/liveconfig.log)?
Spaß beiseite: sobald der Eintrag in die passwd erfolgreich geschrieben wurde, löscht LC das (nur temporär gespeicherte) Passwort aus seiner Datenbank (nach dem Prinzip: sobald wir das Passwort nicht mehr brauchen, wollen wir es da auch nirgendwo mehr gespeichert haben).
ah!
ZitatSo lange das Krypto-Konzept dafür aber nicht abgeschlossen ist, speichern wir keine ungehashten Passwörter.
Wer speichert denn schon Plaintext-Passwörter ... (außer Plesk)
Zitatrsync betrifft nur den Kopiervorgang - so oder so muss trotzdem aus der alten und der neuen /etc/dovecot/passwd das Quell- bzw. das Zielverzeichnis herausgesucht werden.
Ja, ist mir bewusst. War auch nur eine allgemeine Ergänzung
Zum Schluß noch den Passwort-Hash aus der "alten" dovecot/passwd in die neue dovecot/passwd kopieren - fertig.
LC speichert das Postfach-Passwort nicht in der (My)SQL-Datenbank, sondern nur in der passwd-Datei? Wie kommt das Passwort denn aus der GUI raus und da rein? ..
Rsync dürfte übrigens die deutlich einfachste Methode sein, die Mails zu übertragen. Da braucht es kein IMAP-Passwort.
Tipp: nimm mod_wsgi. Options +ExecCGI und über eine app.wsgi aufrufen. Klappt angenehmer als mod_python, erlaubte mehrere Anwendungen und vor allem läuft die Anwendung dann nicht mit www-data.
aktuell ist das eine ordentliche Klickerei und skaliert überhaupt nicht...
Dito. *10z*
