Hallo,
wir haben immer häufiger Supportanfragen, die darauf zurückzuführen sind, dass ein Vertrag mit suPHP oder mod_php angelegt wurde, obwohl das nicht installiert ist.
LiveConfig prüft ja schon, ob das installiert ist, warum kann es diese nicht installierten Betriebsmodi nicht einfach ausblenden im entsprechenden Dropdown beim Anlegen von Verträgen?
nachdem das Ticketsystem wieder läuft, hier der Link dazu:
https://www.liveconfig.com/dev/issues/189
Da steht's im Handbuch:
http://www.liveconfig.com/de/h…advanced.lcdefaults.xhtml
In LC ist es unmöglich nachträglich die Verzeichnisse von die FTP Konten zu wissen, weil sie nicht aufgelistet werden und auch nicht nachträglich veränderbar sind. Könnte man das bitte nachbessern?
Wir hatten das auch angefragt, das wurde schon als Verbesserungsvorschlag aufgenommen - wann es umgesetzt wird, weiß man natürlich nicht.
Mir fiel kürzlich auf, dass Liveconfig die CipherSuite zwar bei Apache, Proftpd und Dovecot anpasst, aber bei Postfix nicht.
Wird das noch geändert oder muss man das dann selbst per custom.lua regeln?
Und dafür reicht die Zeile mit "SSLOpenSSLConfCmd" in die conf.d/*.conf. Der Parameter ist aber erst ab 2.4 verfügbar, für 2.2 gibt es keine (sinnvolle) Möglichkeit, die DH-Parameter >1024 Bit zu erzwingen.
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...
* Voraussetzungen: da sollte man Apache 2.4.x ergänzen zusätzlich zu 2.2.x und auch MariaDB -- wobei das eigentlich redundante Informationen sind, die schon unter "Funktionsumfang" liegen...
EDIT:
die "echten" Fehler wurden alle behoben
Dass lokal erzeugte Mails nicht signiert werden, hatte ich ja schon an anderer Stelle angemerkt - nun wissen wir also auch, warum.
Sofern a keine großen Nachteile hat - wovon ich hier bisher nichts lese - wäre ich auch für (a)
> Soweit ich weiß stuft SSLLabs derzeit auch noch keine Bewertung
> herab, sondern weist lediglich auf die schwachen Parameter hin.
Das tun Sie leider doch.
stimmt leider 
Noch eleganter wäre es, wenn der Admin entscheiden kann, ob er anstehende Änderungen an der Konfiguration automatisch übernehmen oder nur darauf hingewiesen werden möchte.
mir wäre ja am liebsten, wenn man das per Kommandozeile anstoßen könnte... "liveconfig --recreate-service-configs" oder so - aktuell ist das eine ordentliche Klickerei und skaliert überhaupt nicht...
Also für SFTP kann man auch proftpd mitbenutzen wenn der installiert ist. Läuft bei mir problemlos. (http://www.liveconfig.com/de/forum/threads/1316-Mit-Proftpd-parallel-SFTP-Zugriff-zur-Verfügung-stellen)
Danke, aber separater Port führt wieder zu weiterem Support-Aufwand...
wäre natürlich schön, wenn LiveConfig hierbei unterstützen könnte 
vor allem damit man keinen cronjob braucht...
EDIT:
hier die copy-paste-Lösung:
addgroup sftponly
cat << EOF >> /etc/ssh/sshd_config
# SFTP for FTP-Accounts
Match Group sftponly
ChrootDirectory /var/www/%u
ForceCommand internal-sftp -l INFO -f LOCAL6
AllowTcpForwarding no
PermitTunnel no
X11Forwarding no
EOF
service ssh reload
for i in $(grep -E ":/var/www/.+:/usr/sbin/nologin" /etc/passwd | cut -d":" -f1); do usermod -aG sftponly $i; done
echo '*/5 * * * * for i in $(grep -E ":/var/www/.+:/usr/sbin/nologin" /etc/passwd | cut -d":" -f1); do usermod -aG sftponly $i; done' >> /var/spool/cron/crontabs/rootMini-bugreport zu DKIM:
* wenn man auf das "i" klickt neben "Test-Modus", kommt "undefined"
* der Handbuch-Link im tooltip zu dkim führt in's leere
* ein icon in der Domain-Liste sollte bitte anzeigen, dass die Domain dkim aktiviert hat
* Bei Versand einer Mail via roundcube (->php) wird keine dkim signatur eingefügt
we had that issue, too.
our workaround was to use a different type (not "number") for the variable...
Ist nun umgestellt - ab sofort installiert der AppInstaller das "roundcube-xxx-complete"-Paket.
Danke. [10 zeichen]
PHP 5.3.29 (DotDeb) war die Standard PHP Version
achso, Danke 
von 5.3.29 auf 5.6.7
woher hatten Sie 5.3.29 denn? in squeeze-lts ist 5.3.3.1-7+squeeze26 und in wheezy 5.4.39-0+deb7u2
danke für den guten Willen, die Antwort hilft mir also so leider nicht
Ganz einfach: falsche Reihenfolge.
da habe ich diesmal wohl etwas anders gemacht als sonst...
Was passiert eigentlich mit den PHP-Versionen bei einem solchen Upgrade?
Bleiben die fest eingestellten alle erhalten und nur die mit "default" ändern sich?
fstab:
/dev/md5 /var ext4 errors=remount-ro,grpjquota=aquota.group,jqfmt=vfsv0,discard 0 2mount:
/dev/md5 on /var type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered,jqfmt=vfsv0,grpjquota=aquota.group)apt-get -f install
quota (4.01-8) wird eingerichtet ...
[warn] Checking quotas...[....] Warning: user quota not configured in filesystem `/var.' ... (warning).
done.
[....] Turning on quotas...quotaon: Kann Quotadatei auf /var [/dev/md5] nicht finden, um Quotas zu (de-)aktivieren.
invoke-rc.d: initscript quota, action "start" failed.
dpkg: Fehler beim Bearbeiten des Paketes quota (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
quota
E: Sub-process /usr/bin/dpkg returned an error code (1)EDIT:
evtl. betrifft es auch nur Neuinstallationen, keine Upgrades? Meine Frage war dann nicht passend zum Thema, da es eine Neuinstallation ist.
Danke.
Kann es sein, dass man unter Debian 8 Probleme mit "nur grpjquota, keine usrquota" hat, wie es bei LiveConfig vorgesehen ist?
Debian 8 nutzt im Quota-Initskript das Skript /usr/share/quota/quotaon.sh und dieses berücksichtigt im Gegensatz zum alten Initskript nicht mehr, dass die grpjquota unter .../aquota.group liegen kann.
Hat da schon jemand einen Quickfix dafür vielleicht?