[*]Wenn keine DNS-Abfragen "nach außen" erlaubt sind (Firewall), dann erkennt LiveConfig das nun automatisch und nutzt in diesem Fall die in /etc/resolv.conf hinterlegten Resolver. In diesem Fall sollten die Resolver aber DNSSEC-Validierung unterstützen!
und welche werden sonst benutzt??
Bei uns ist es Ubuntu 10.4 mit dem 5.3 der Distri... nicht schlagen, bitte! Wir müssen von der alten Gurke eben die Daten noch migrieren.
nicht schlagen, aber der der dafür verantwortlich ist, dass ein System seit über 4 Jahren ohne Sicherheitsupdates am Internet hängt, ist rechtlich mit dran wenn dort - oder noch schlimmer von dort aus - etwas passiert.
sorry für den OT, aber da kann ich nicht still bleiben...
Außerdem gibt es auch in Stretch einen Bug in HTTP/2, der Safari-Clients betrifft.
Der Teil wurde endlich in 2.4.25-3+deb9u7 behoben.
SRS ist nicht die perfekte Lösung.
Keine Weiterleitungen und froh sein 
wohl eher gleich 18.4 am Besten...
Was wären empfohlene Werte für die Einstellungen?
Das hängt davon ab, wie viel RAM da ist und wie viele gleichzeitige User man so hat.
Ich würde mal sagen, übliche Userzahl mal zwei genommen oder sowas...
nein.
Codeprotocol imap { process_limit = 200 }
Einfach genau so in die dovecot.local.conf eintragen.
nicht ganz richtig.
service imap-login {
process_limit = 200
}ich rate sehr dazu, das Limit nicht allzu hoch zu setzen, da es dann auch dazu führen kann dass ein DoS auf den Mailserver den Rest des Servers mitzieht.
In /etc/awstats/liveconfig/ stapeln sich die Configs auch der längst gelöschten User.
Könnte Liveconfig da nicht bitte aufräumen?
Ja, wir können das manuell machen bzw. mit eigenen Scripts, aber irgendwie ist das doch Aufgabe von LC
bei uns nicht, vielleicht wurde es inzwischen behoben.
Viele Massenhoster scheren sich nicht um dieses Situation. Da werden alte Versionen entzogen und neuere Standard-Versionen aktiviert. Falls eine Webseite danach nur eingeschränkt oder gar nicht mehr funktioniert, dann muss sich der Kunde selbst kümmern.
Äh, und was ist daran falsch? Wenn der Kunde Webhosting bucht, hat er keinen Anspruch darauf, dass der Hoster auch die Website aktualisiert/pflegt...
/var/www/<Vertrag>/.httpd.conf mit folgendem Inhalt anlegen:CodeSSLProtocol -SSL3 -TLSv1 -TLSv1.1
wirkt sich aber auf alle Domains/vHosts mit der selben IP-Adresse aus, nicht?
kommt also aus dem lokalen Storage und wurde nicht über die Stretch-Repositories installiert.
Ich würde kein suPHP mehr nutzen.
Ergänzung:
es wurde also irgendwann per "dpkg -i ....." installiert, was man vermeiden sollte, da man keinerlei Updates erhält.
Das ist in diesem Fall der Hauptgrund gegen suphp - aber wie Anton schon schrieb gibt es ja auch keinen einzigen Grund dagegen, FastCGI zu nutzen
Mit den korrigierten Werten klappt es nun auch wieder mit SuPHP!
unter welchem Betriebssystem und welcher Version denn?
Debian Wheezy? Falls ja: AUA. Bitte updaten.
Falls neueres Debian:
bitte mal das Ergebnis von:
"dpkg -l | grep suphp"
posten.
Das Paket gibt es nämlich eigentlich seit Jessie schon nicht mehr und wird entsprechend auch nicht mehr mit Sicherheitsupdates versorgt...
Also erst den Server von Debian 7 auf Debian 8 und anschließend von 8 auf 9 aktualisieren (ein erfahrener Admin sollte das in <30min schaffen).
Ich möchte hier schon ergänzen, dass das stark abhängig ist von der Leistungsfähigkeit der Hardware, dem letzten reboot (stichwort fsck) und weiteren Punkten.
Ich jedenfalls würde mich als erfahren bezeichnen und 30 Minuten sind sportlich, selbst ohne fsck und auf flotter Hardware - zumindest wenn man am Ende auch gewissenhaft "aufräumt".
ah, es wurde upstream seit 3 Jahren ignoriert, klasse ...
warum wurde eigentlich der Liveconfig Passwort Treiber noch nicht upstream eingereicht, damit er automatisch mitgeliefert wird mit roundcube?
https://github.com/roundcube/r…/plugins/password/drivers
Ich denke das sollte machbar sein, dass man eine bestimmte PHP-Version als Standard für neue Domains auswählt.
Das geht übrigens inzwischen, so:
echo 'LC.web.PHPDEFAULT="php72"' > /etc/liveconfig/lua.d/59-default-php.luader Vollständigkeit halber:
behoben seit 2.6.1-r4987 (18.06.2018)
ich glaube das geht nur, wenn du liveconfig-meta deinstallierst oder aber das liveconfig-meta Paket angepasst wird.
Wir benutzen liveconfig-meta nicht, da es auch Pakete installiert die wir nicht auf jedem Server brauchen.
PHP 7.1 bin ich jetzt losgeworden, indem ich wieder die virtuellen PHP-Packete (php7.0) hinzugefügt habe.
Aber eigentlich will ich die auch nicht haben...
warum nicht? ohne die virtuellen krachts z.B. beim Update auf 18.04 (was du mal angehen solltest demnächst)
