HSTS-Header haben mit LiveConfig IMHO nichts zu tun. Wäre auch kontraproduktiv, wenn LC hier eigenständig die HSTS-Header für Kunden-Verträge verschickt (Welche Gültigkeitsdauer? Mit und ohne Subdomains? Was ist bei Wildcard-SSL-Zertifikaten? Evntl. soll doch Content ohne HTTPS übertragen werden?).
Also den Header in der .htaccess selbst setzen, da bleibt der dann normal auch drinnen.
ich habe auf allen LC Clients eine Domain angelegt und auf diese das SSL Zertifikat installiert, dieses wurde auch beim jeweiligen LC Client unter /etc/liveconfig/sslcert.pem eingetragen.
Nachdem auf dem LC Clients kein öffentlich erreichbarer Dienst (und damit auch keine Web-GUI) läuft, bringt das gar nix.
Aktuell in Arbeit sind (neben etlichen kleineren Bugfixes) ein überarbeitetes Backup, Lösch-Funktionen in der SOAP-API sowie das komfortablere Bearbeiten (und Löschen!) von Kontakten.
poah :O
Da freu ick mir aber 
Das ist auch nicht besonders elegant und lässt sich auch nicht über die API ansteuern :-/
Yes! Ein API-Verbündeter! :cool:
ZitatEs wäre, um einen Betrieb im produktiven Rahmen zu ermöglichen, dringend anzuraten, dass eine Sperrung einzelner Verträge ermöglicht wird - idealerweise auch über die API.
Sehe ich voll und ganz genauso.
Es gibt da noch EINIGE andere Probleme, die über die API lösbar sein sollten! "Kunde löschen" gehört da dazu (dass es "Vertrag löschen" gibt, aber "Kunde löschen" nicht, lässt sich ja auch nicht mehr alleine mit "eigentlich war die API nur für den Import gedacht..." erklären )
Betrifft Debian in keiner Version:
https://security-tracker.debian.org/tracker/CVE-2015-1793
LiveConfig scheint mir auch nicht betroffen zu sein.
Da war Confixx klar besser.
Dass LiveConfig durchaus Optimierungspotential im Bereich UX hat, dürfte KK&Team bewusst sein. Aber ausgerechnet Confixx als "einfach zu bedienend" zu bezeichnen, geht dann doch etwas weit (warum wurde die Mail-Quota in eine gesonderte Maske ausgelagert?).
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.
