Beiträge von kk

Wie schaut denn die access.log-Datei vom betroffenen Kunden aus - tauchen da überhaupt aktuelle Einträge drin auf?
(/var/www/<Vertrag>/logs/access.log)

Wenn nein: laufen die Domains dieses Kunden eventuell mit NGINX?

Zitat von Robbi

könnten Sie uns mitteilen, wie genau der Zeitraum ist, bevor wieder eine automatische Antwort an die gleiche Adresse gesendet wird? Und ob ggf. wo man das verändert kann?

Dovecot-Sieve nutzt die standardisierte "vacation"-Routine. Der Parameter "days" entscheidet, nach wie vielen Tagen erneut eine Antwort gesendet werden soll: https://tools.ietf.org/html/rfc5230#section-4.1
Standard-Einstellung ist 1 Tag - kürzere Intervalle gehen also nicht (ohne weiteres).
Dieser Wert wird auch durch LiveConfig in die sieve-Datei der jeweiligen Postfächer geschrieben (dovecot.lua, Zeile 837).

LiveConfig fasst .htaccess-Dateien in Webspace-Verzeichnissen nicht an.
Der Passwortschutz durch LC wird direkt in der vHost-Konfiguration (/etc/apache2/sites-available/...) eingetragen.

Viele Grüße

-Klaus Keppler

Zitat von weltmeister

Kann es sein, dass seit dem letzten Update die SSH-Zugänge für die Endkunden nicht mehr funktionieren?

Das kann ich zumidnest schon mal ausschließen - LiveConfig ändert definitiv nichts an SSH-Zugängen.

Die einzige richtige Antwort liefern auch in diesem Fall nur die Logfiles - unter Debian insbes. /var/log/auth.log

Starten Sie bitte LiveConfig neu (damit der das php5-cgi-Paket nun auch "kennt"), und danach speichern Sie irgendeine Domaineinstellung eines betroffenen Vertrags noch mal neu (damit LiveConfig eine neue vHost-Konfiguration und somit auch einen neuen PHP-FCGI-Starter erzeugt).

Kann es sein, dass Sie das Paket "php5-cgi" nicht installiert haben...?

Was liefert "liveconfig --diag"? (der Abschnitt von "Checking for web server software:" bis "Checking for ftp server software:" genügt)

Zitat von Chrizzo

Gibts denn überhaupt änderungen bezüglich der Apps?

Ab Version 1.9 können eigene App-Repositories definiert werden (https://www.liveconfig.com/dev/issues/185). Beispielcode wird gerade vorbereitet und steht in Kürze bei GitHub bereit (https://github.com/liveconfig).

Zitat von aziegler

Herr Keppler, könnten Sie bitte für den App-Installer nicht einfach das "roundcube....-complete" Paket benutzen?
da wäre Pear&co. schon enthalten!

Ist nun umgestellt - ab sofort installiert der AppInstaller das "roundcube-xxx-complete"-Paket.

Merkwürdig... ich habe hier auf einem Wheezy-Server auch kein Net_IDNA2 installiert, und es geht trotzdem.

Laut Debian Bug #620218 hilft es eventuell, das Paket "php5-intl" zu installieren ("aptitude install php5-intl").

Zitat von CubexHD

Okay zu früh gefreut. Sobald ich mich einlogge bleibt es bei domain.de/?_task=login stehen mit einem whitescreen.

Steht etwas im RoundCube-Log? (/apps/<RoundCube-Verzeichnis>/logs/errors)

Zitat

Unter /logs/priv/ ist auch nichts.

- ist "log_errors" in der php.ini wirklich aktiviert? (Webhosting -> php.ini Einstellungen)
- welche PHP-Version ist für die RoundCube-Subdomain ausgewählt? (muss IMHO mind. 5.4 sein)

- ist "php-pear" installiert? (führen Sie ggf. den Befehl "aptitude install php-pear" aus)
- das Log sollte im Verzeichnis ~/logs/priv/php_errors.log auftauchen, sobald es erste Meldungen gab (konkret also nach dem Aufruf von RoundCube, wenn nur eine weiße Seite erscheint)

Ja, der AppInstaller kümmert sich inzwischen um den überflüssigen und IMHO fehlerhaften "FollowSymLinks"-Befehl.

Eventuell fehlt noch das Paket "php5-pear". Ansonsten bitte im LiveConfig unter Hosting -> Webspace die php.ini-Einstellungen bearbeiten und dort "log_errors" auf "on" setzen - dann erhalten Sie ein separates PHP-Fehlerprotokoll (kann man dann auch im LiveConfig im Log-Viewer ansehen).

Zitat von aziegler

Was passiert eigentlich mit den PHP-Versionen bei einem solchen Upgrade?
Bleiben die fest eingestellten alle erhalten und nur die mit "default" ändern sich?

Ja, genau. Die "default"-Einstellung setzt als Apache-Handler "application/x-httpd-php", was dann jeweils mit /usr/bin/php-cgi ausgeführt wird.

Prüfen Sie bitte folgende Punkte:

• ist apache2-suexec installiert und aktiviert? ("a2enmod suexec")
• ist im betroffenen Webspace-Vertrag PHP auf "FastCGI" eingestellt? (siehe z.B. /etc/apache2/sites-enabled/<Vertrag>.conf - da steht beim PHP-Abschnitt als Kommentar wie das konfiguriert ist)

Zitat von aziegler

Code

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.

Ganz einfach: falsche Reihenfolge.
Erst "quota"-Paket installieren, dann Quota im Filesystem einrichten & aktivieren.

In diesem Fall also bitte die Quota-Optionen noch mal aus der fstab entfernen, dann emount, dann quota installieren & konfigurieren.

Kann ich nicht bestätigen... hier wird das Group-Quota reibungslos beim Boot aktiviert. Es gibt zwar eine Warnung, dass kein User-Quota aktiviert ist, am Ende führt das quotaon.sh aber den Befehl "quotaon -aug" aus.

Ich habe das eben mal anhand des Demo-Servers geprüft. In der /etc/fstab steht als Mount-Option "grpjquota=aquota.group,jqfmt=vfsv0". Nach einem Reboot war Group-Quota aktiviert (Test mit "repquota -ag").

Hier ist eine kurze Schritt-für-Schritt-Anleitung, um ein Debian 7 (Wheezy) auf Debian 8 (Jessie) zu aktualisieren.
Wir haben das Update selbst auf mehreren Servern komplikationsfrei durchgeführt - falls jemandem doch noch etwas auffällt, freuen wir uns natürlich über ein Feedback.

Grundlegende Kenntnisse der Serveradministration setze ich an dieser Stelle einfach mal voraus.
Eine umfangreichere Anleitung gibt es auf der Debian-Website.

Wichtig bei Debian 8:

• mod_suphp ist nicht mehr vorhanden. Webspaces müssen im LiveConfig also vorher ggf. von suPHP auf FastCGI umgestellt werden!
• beim Upgrade von Debian 7 auf 8 wird systemd nicht automatisch installiert (der Systemstart sollte vorerst also bei sysvinit bleiben)
• immer wenn Sie während des Upgrades gefragt werden, ob Sie bestehende Konfigurationsdateien beibehalten oder durch eine neuere Version überschreiben wollen, dann entscheiden Sie sich für beibehalten ("N" - NICHT überschreiben).

Schritt 1: Debian 7 auf den aktuellen Stand bringen

aptitude update
aptitude upgrade

Schritt 2: APT-Quellen aktualisieren
Hierzu in der Datei /etc/apt/sources.list die Repositories von "wheezy" auf "jessie" ändern. Eine komplette sources.list könnte dann z.B. so aussehen:

deb     http://ftp.de.debian.org/debian/     jessie main contrib non-free
deb-src http://ftp.de.debian.org/debian/     jessie main contrib non-free
deb     http://security.debian.org/ jessie/updates  main contrib non-free
deb-src http://security.debian.org/ jessie/updates  main contrib non-free

Bitte verwendet nach Möglichkeit einen lokalen Mirror-Server (z.B. vom jeweiligen Rechenzentrum).

Schritt 3: Paket-Datenbank aktualisieren

aptitude update

Schritt 4: APT aktualisieren

apt-get install apt

Schritt 5: restliche Pakete aktualisieren

apt-get upgrade

Schritt 6: überflüssige/veraltete Pakete entfernen, fehlende Pakete nachinstallieren

aptitude upgrade
aptitude dist-upgrade

WICHTIG: bei diesem Schritt wird mod_suphp entfernt (das ist in Debian Jessie nicht mehr enthalten, s.o.).

Schritt 7: Neustart
Server neu starten, um den neuen Kernel zu laden

reboot

Schritt 8: LiveConfig-Konfiguration aktualisieren

dpkg-reconfigure liveconfig

Dabei wird die Datei /etc/apache2/conf.d/liveconfig nach /etc/apache2/conf-available/liveconfig.conf verschoben und mit "a2enconf liveconfig" aktiviert. Ohne diesen Schritt werden evtl. keine access.logs für die einzelnen Webspaces erzeugt.

Sollte irgendein Dienst nicht starten, weil etwas mit der Konfiguration nicht mehr passt (uns ist bislang kein Fall bekannt), dann melden Sie sich im LiveConfig an, gehen auf "Serververwaltung" und lassen die Konfiguration des betroffenen Dienstes neu erstellen.

Das LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig v1.8.3 (r3577) bekanntgeben zu dürfen.
Die wichtigsten Änderungen sind:

• Unterstützung von DKIM (per OpenDKIM)
• Anzeige des Speicherplatzes auf dem Server
• überarbeitete Serverübersicht (Berichte -> Server) - zeigt Plattenbelegung und Anzahl der Kunden pro Server

sowie viele Detailverbesserungen - siehe Änderungsverlauf.

Ab Version 1.8.3 wird Debian 8 (Jessie) auch komplett unterstützt. Während des Upgrades auf v1.8.3 werden notwendige Änderungen am Konfigurationslayout automatisch vorgenommen (derzeit betrifft das nur Apache2 - dort muss /etc/apache2/conf.d/liveconfig verschoben werden).
Eine Anleitung zum Upgrade von Debian 7 auf Debian 8 mit LiveConfig gibt's gleich in einem separaten Beitrag.

Unsere Gentoo-User müssen sich leider noch ein klein wenig gedulden - durch Umstellung auf einen neuen Build-Server müssen unsere Gentoo-VMs fast komplett neu durchcompiliert werden, was noch einige Stunden dauern wird.

Die Arbeiten an der nächsten Version (LiveConfig 1.9) laufen bereits auf Hochtouren, eine erste Preview ist bereits für Übermorgen geplant.

Im Namen des LiveConfig-Teams

-Klaus Keppler

Äh, jein, der Bug ist erst im 1.9er-Zweig beseitigt, weil wir hierfür Änderungen an der Rechteverwaltung vorgenommen hatten die mit verhältnismäßig großem Aufwand in die 1.8.3 hätten zurückportiert werden müssen.
Die erste 1.9er-Preview steht aber schon in den Startlöchern - kommt voraussichtlich am Mittwoch Nachmittag.