Beiträge von antondollmaier

Und, ist das Zertifikat von LiveConfig noch gültig oder ist es bereits abgelaufen?

Was passiert denn beim manuellen Aufruf von "/opt/php-5.6/bin/php-cgi -i"?

Zitat von kk

Das bedeutet: es kann nicht ohne weiteres virtuelle SFTP-Benutzer geben (zumindest nicht so lange das über Port 22 = SSH läuft). mod_sftp setzt die Konfiguration eines eigenen Ports dafür vorraus (was man den Anwendern dann auch erst einmal erklären muss).

Naja. System-Benutzer mit doppelter User-ID wären eine mögliche Lösung (so hat's Confixx mit den FTP-Accounts gemacht), was aber widerrum das chroot-Problem nicht löst.

Die mod_sftp-Lösung ist relativ sexy, mit dem Nachteil des dedizierten Ports.

Wer eher SFTP bevorzugen möchte, kann natürlich auch den SSHd auf z.B. 2201 legen und mod_sftp auf 22.

Hier[tm] wird hauptsächlich SSH angefragt, so dass SFTP per se eigentlich irrelevant ist - und der Port-Wechsel eher hinderlich.

Zitat

Unsere Empfehlung daher: FTPS (FTP+SSL/TLS) verwenden - das unterstützen alle aktuellen FTP-Programme, und da sind keine Bastelarbeiten notwendig.

Die Clients - schon.

Die Firewalls - nicht.

Wir hatten gerade in der Anfangszeit häufig Probleme mit Kunden, die den PASV-Mode über DPI freigeschalten haben. Nachdem die Firewall aber den PASV-Port nicht aus dem verschlüsselten Control-Traffic parsen konnte, wurde der PASV-Traffic gar nicht erst erlaubt.

Zitat von kk

Aber um die Diskussion zu beenden, hier eine kurze Vorschau auf eine Bildschirmmaske von v2.8:

... und schön Salz in die Wunde reiben ...

Wann gibt's das Release denn?

Zitat von kk

Aber: wir haben inzwischen schon mehrfach die Rückmeldung erhalten, dass mod_http2 zumindest bei Apache unter Debian 9 und Event-MPM beim Download von großen Dateien (>300MB) Probleme macht (einige Hoster haben das derzeit bewusst deaktiviert).

Es gibt einen Bug in Event-MPM, der komplett den Apache lahm legen kann.

Außerdem gibt es auch in Stretch einen Bug in HTTP/2, der Safari-Clients betrifft.

Wir haben aktuell HTTP/2 aktiv (es sei denn, Kunden benötigen zwingend Safari...), aber von mpm_event auf mpm_worker umgestellt.
Mit mpm_prefork ist HTTP/2 gar nicht möglich, wie kk schon schrieb.

Zitat von kroerig

der Empfänger sie aber erhalten muss, dann haben wir ein (ggf. auch rechtliches) Problem.

Nö.
Entweder, die Mail wird von lcsam als "suspected Spam" markiert - und kommt dann durch.
Oder sie wird rejected - kam also rein rechtlich niemals an.

LiveConfig wurde ohne "Junk"-Ordner konzipiert. Das ist die rechtlich vollständig korrekte Lösung.

Zitat von thomas16

SA läuft, Erkennung alles mit 0,0
(...)
allerdings ist dass das Verhalten seit Deb8-Deb9

Debugging hoch, manuell via spamc eine Erkennung ausführen.

Ich tippe auf ein Rechte-Problem. /var/lib/spamassassin enthält fast alle Regeln. Gehört der Ordner dem falschen Nutzer, kann SpamAssasssin die Regeln nicht lesen und somit auch keine Punkte vergeben.

Was sagen denn die Logs nach so einem Reboot, warum LCSam SpamAssassin nicht findet/nutzt? Was sagt der Spamasassin-Dienst selbst dazu?

Was passiert, wenn über "spamc" manuell eine Mail an spamd übergeben wird?

Wir fahren hier ausschließlich Debian Stretch und hatten diese Symptome kein einziges Mal. Ich bin mir auch sicher, dass LiveConfig niemals eine Version veröffentlicht, die Konfigurationen schreibt, die nicht Reboot-fest sind.

Zitat von clickpress

Ich würde gern z.B. den Parameter pm.max_children = 8 erhöhen, wo und wie mache ich das?

Aktuell über Webinterface/Configs - gar nicht.

Zitat

Ich vermute mal nicht in dieser .conf, oder?

Korrekt. Die wird allerdings bei Änderungen neu geschrieben.

Die web.lua bzw. apache.lua kann natürlich direkt geändert werden - das ist dann zumindest längerfristig, wenn auch nicht liveconfig-update, fest.

Zitat

Kann ich das über die PHP-Einstellungen in LC erledigen?

Nein.

kk: bitte den ersten Beitrag auf die neuen RewriteRule anpassen. Danke!

Eventuelle Hinweise in "dmesg"/journal zu Segfaults in den Binaries, die entweder kaputt sind oder auf kaputten RAM hinweisen könnten?

Please set the FQDN of your server not to "hisdomain", but instead use "server.hisdomain.com" or similar. That's also included in the general setup manual of LiveConfig.

Zitat von kk

Kurz zur Info: mit LiveConfig v2.8.0 gibt es einen LCDefaults-Key "mail.forwards.blacklist", bei dem man bestimmte Zieldomains für die Verwendung in E-Mail-Weiterleitungen sperren kann (kommagetrennte Liste). Also z.B. so was wie "gmx.de,web.de,t-online.de".
Bestehende Weiterleitungen sind davon nicht betroffen, die Blacklist wird nur beim Anlegen oder Bearbeiten eines Postfachs geprüft.

Kurze Rückfrage: Aktuell ist ja 2.7.4-r5214 - ist dort der Commit r5157 (vgl https://www.liveconfig.com/de/…6889&viewfull=1#post16889) schon drin enthalten?

Achtung: NEOS ist auch betroffen, dort wird der SetHandler auch verwendet:

# Prevent execution of script files
SetHandler default-handler
<Files *>
  # Override again if executed later in the evaluation list
  SetHandler default-handler
</Files>

Zitat von tfi

Vorhandene Domains mit PHP X.Y sollen die PHP Version X.Y beibehalten.
PHP 7.3 soll neue Standardversion werden und für alle neuen (Sub)Domains gelten.

Diese Option wäre zu begrüßen.

Zitat von ksmx

Die neuen API-Methoden lassen sich dafür auch nicht nutzen?

Da es nur DomainAdd und kein DomainUpdate gibt - nein.

Zitat von ksmx

Dovecot und Postfix sollen *ein* Zertifikat erhalten, welches mehrere SANs enthaelt. Ich moechte die Kunden nicht zwingen die Einstellungen ihres eMail-Programms aendern zu muessen, deshalb soll das System mehrere valide Namen haben.

Da stellt sich die Frage, was leichter ist: einmalig Kunden dazu zwingen, ihr Mailprogramm zu ändern, oder sich um ein SAN-Zertifikat zu bemühen.

Zumal es - abhängig von der Umgebung - im SAN-Zertifikat auch Privatsphären-Probleme gibt. Immerhin sieht jeder, welche CN sonst noch geschützt werden.

Zitat

Kann ich über Liveconfig ein Letsencrypt-Zertifikat erstellen, welches mehrere SANs besitzt?

Abgesehen von der Domain und der WWW-Subdomain - nein.

Zitat

Angenommen ich baue mir ein LE-Zertifikat per Certbot ganz an Liveconfig vorbei, dann wuerde ich es gerne trotzdem an Liveconfig uebergeben, so dass Liveconfig es an die Dienste (Postfix, Dovecot) verteilt. Ist dies der Weg den ich gehen sollte? Muss ich dafuer wirklich mit der API sprechen? Ich wuerde gerne allzu große Klimmzüge vermeiden.

Certbot/Dehydrated - möglich.
Übergabe an LiveConfig - nicht.

Einfach die phpinfo() anschauen.

Befehl in ein eigenes Bash-Script auslagern und dieses in der Crontab ablegen/ausführen.

Oder gleich das PHP-Script via CLI aufrufen und die Mail dort erzeugen:

/usr/bin/php -f /var/www/..../cron.php

Zitat von CreativeDEV

Tatsache. Die Mails liegen im mail-spool des lokalen Users nico. Aber wie kommen diese da rein? Ich verstehe das Mapping an der Stelle einfach nicht ganz.

Da Postfix "domain.de" als HOstname verwendet, wird "Nico@domain.de" an den System-User "nico" übermittelt - irgendwie muss Postfix ja auch internes verwalten können.

Die virtuelle Domain, die über LiveConfig angelegt wird, wird daher ignoriert (und auch in den Logs als Warnung angegeben!).

Zitat

liefert den Domainnamen mit Endung.

In der /etc/hosts Datei ist sowohl das Mapping für v4 und v6 gesetzt.

Nochmals: genau das ist falsch.

Umbenennen auf "server.domain.de" oder ähnliches - nur die Domain führt zu obigen Fehlern.