Beiträge von kk

Zitat von RB-Media-Group

Can't run /usr/lib/liveconfig/lua/liveconfig.lua: /usr/lib/liveconfig/lua/web.lua:1208: attempt to perform arithmetic on a nil value

Die Ursache für diesen Fehler liegt in der Erkennung der PHP-Versionen.
Was genau haben Sie denn in der /usr/lib/liveconfig/lua/custom.lua eingetragen? (interessant sind nur die addPHP-Aufrufe)
Für jede dieser hinzugefügten PHP-Versionen: was liefert des Aufruf des angegebenen PHP-Binaries mit der Option "-v"?

Beispiel:
custom.lua: LC.web.addPHP('php53', '/opt/php-5.3/bin/php-cgi')
=> Was liefert "/opt/php-5.3/bin/php-cgi -v" ?

Viele Grüße

-Klaus Keppler

Zitat von hchristo

[Wed Oct 22 03:18:54 2014] [notice] Apache/2.2.22 (Debian) DAV/2 mod_fcgid/2.3.6 PHP/5.5.17-1~dotdeb.1 mod_ssl/2.2.22 OpenSSL/1.0.1e configured -- resuming normal operations

Sieht so aus als ob Sie FastCGI und mod_php aktiviert haben. Macht keinen Sinn. mod_php bitte entfernen/deaktivieren.

Zitat von hchristo

[Wed Oct 22 03:19:14 2014] [warn] [client 127.0.0.1] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[Wed Oct 22 03:19:14 2014] [error] [client 127.0.0.1] Premature end of script headers: index.php

Der Webspace ist offenbar mit FastCGI konfiguriert. Vermutlich ist aber das Paket "php5-cgi" nicht installiert.

Soweit ich weiß existieren CentOS/RHEL-Repositories mit PHP 5.5/5.6.

Die PHP-Pakete (KB#22) wurden eben auf 5.4.34, 5.5.18 und 5.6.2 aktualisiert.
Außerdem ist in allen Paketen nun auch wieder die suhosin-Erweiterung enthalten (um z.B. via PHP hochgeladene Dateien automatisch mit maldet/ClamAV zu scannen).

Viele Grüße

-Klaus Keppler

Ok... wenn der alte und der neue Kunde jeweils dem selben admin/Reseller gehören, dann bleibt das eingestellte Angebot künftig erhalten.
Die Änderung wird eben eingebaut und ist im nächsten Update (ab r3133) enthalten (Preview davon in Kürze verfügbar...)

Viele Grüße

-Klaus Keppler

Hmm, gute Idee - hier braucht's in der entsprechenden RewriteRule beim Apache das "NE"-Flag (NoEscape: http://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_ne)
Ist im nächsten Update mit drin.

Viele Grüße

-Klaus Keppler

Zitat von Febas

Wie könnte ich aus den zwei vorhanden Servern so ein Setup bestmöglich herstellen? Gibt es eventuell eine Anleitung dazu?

Ergänzung: Ist es dann wenigstens möglich, Mail- und DB-Server von localhost auf externen Server zu migrieren? Meine Vorstellung:

Die Ordner /var/mail , /var/lib/mysql , /etc/postfix, /etc/dovecot jeweils auf den externen Server verschieben, und in der LiveConfig-Datenbank den externen Server eintragen? Wäre das korrekt/möglich?

Prinzipiell ist das schon möglich, aber nur mit manuellen Eingriffen in die Datenbank.
Daher gilt: auf eigene Verantwortung, und vorher Backup der Datenbank anlegen!

Ich gehe davon aus, dass Mail- und Datenbankserver fertig installiert/konfiguriert und am LiveConfig-"Master" angemeldet sind. Legen Sie dann testweise einen individuellen Vertrag mit einem Postfach und einer Datenbank auf den jeweils neuen Servern an.
Danach beenden Sie LiveConfig auf dem Master sowie auf allen anderen Servern (lcclient). Erstellen Sie ein Backup der LiveConfig-Datenbank. Beenden Sie MySQL, Postfix und Dovecot. Kopieren/rsyncen Sie alle Daten auf die neuen Server (/var/lib/mysql, /var/mail, /etc/dovecot).

Für die DB: in der LiveConfig-DB finden Sie in HOSTINGCONTRACTS.HC_DBSERVERID nun die interne ID dieser MySQL-Instanz (suchen Sie am besten so: SELECT HC_DBSERVERID FROM HOSTINGCONTRACTS WHERE HC_NAME="web###"; )
Aktualisieren Sie alle bestehenden Verträge (HOSTINGCONTRACTS.HC_DBSERVERID) entsprechend.
Damit die bestehenden Datenbanken korrekt auf dem "neuen" Server erkannt werden, müssen Sie außerdem die Tabelle DBS überarbeiten. Hierzu suchen Sie mittels SELECT DB_SERVERID FROM DBS WHERE DB_NAME="neueDatenbank"; die ID der vorhin testweise neu angelegten Datenbank heraus. Mit dem hier zurückgegebenen Wert aktualisieren Sie dann ebenfalls die anderen Spalten in DBS.DB_SERVERID.

Für Mail: analog; legen Sie im Testvertrag ein Postfach an. In HOSTINGCONTRACTS.HC_MAILSERVERID finden Sie die ID des "neuen" Mailservers, mit der Sie dann ebenfalls alle anderen Datensätze (HC_MAILSERVERID) aktualisieren. Das neue Postfach hat in MAILBOXES.MB_MAILSERVERID eine ID bekommen, mit welcher Sie die bestehenden Postfächer (MB_MAILSERVERID) aktualisieren müssen.

Starten Sie danach zuerst alle Dienste wieder (MySQL, Dovecot) und danach LiveConfig auf allen Servern. Aktualisieren Sie in irgend einem beliebigen Vertrag mal ein Datenbank- und ein E-Mail-Passwort und prüfen, ob das auf den neuen Servern korrekt durchgeführt wird. Dabei die Logdateien im Auge behalten.

Viele Grüße

-Klaus Keppler

Nein, der bestehende "einzelne" Server kann leider (noch) nicht ohne weiteres in die andere Gruppe mit aufgenommen werden. LiveConfig speichert alle Daten (Einstellungen etc.) jeweils zentral auf dem "Master". Um einen bestehenden Server mit aufzunehmen brauchen wir also noch so eine Art "Import", mit dem alle Einstellungen vom bisherigen Einzelserver zum Master übertragen werden können. Außerdem muss bei dieser Gelegenheit geprüft werden, ob es Probleme geben könnte (wenn z.B. zwei Verträge mit dem selben Namen existieren). So ein Import (sowie auch ein "Export" einer Multiserver-Nodes in einen separaten Server) ist geplant, dürfte aber erst Anfang kommenden Jahres in Angriff genommen werden (dieses Jahr sind noch genügend andere Punkte offen, insbes. DNS-Verwaltung und Backup). Viele Grüße -Klaus Keppler

Sie meinen vermutlich, wenn man einen Vertrag einem anderen Kunden zuweist ...?

In diesem Fall: "It's not a bug...". Nehmen wir mal folgendes Beispiel:
Kunde A
- Angebot A_Basic
- Vertrag web1
Kunde B
- Angebot B_Profi

Wenn nun der Vertrag "web1" zum Kunden B verschoben wird, muss dieser natürlich auf "individuell..." umgestellt werden, weil das Angebot "A_Basic" ja beim Kunden B gar nicht existiert.

Was wir machen könnten: LiveConfig könnte bei der Neuzuordnung prüfen, ob beim Zielkunden (hier: Kunde B) ein gleichnamiges Angebot existiert. In diesem Fall müssten Sie also vor der Neuzuordnung ein Angebot "A_Basic" beim Kunden B anlegen. Dann könnte LiveConfig bei der Neuzuordnung das (gleichnamige) Angebot des Ziel-Kunden zuweisen.
Nachtrag: oder vielleicht könnten wir in der Maske zur Neuzuordnung gleich ein Dropdown mit der Liste der Angebote des Ziel-Kunden mit integrieren...

Zitat

Da wir gerade nach der Migration von Confixx auf LiveConfig ca. 6000 Accounts zusammen legen ist das leider sehr nervig und zeitaufwendig.

Kennen Sie die Option "--newreseller" vom cfximport.php? Da können Sie beim Import schon einen Vertrag einem anderen Kunden (Reseller) zuordnen. Die Angebote werden dann auch automatisch mit importiert. Und Sie sparen es sich, 6000 Kunden über die Oberfläche neu zuzuordnen.

Nachtrag: hab' ich ganz vergessen: ab Version 1.7.5 unterzeichnet LiveConfig alle erzeugten Zertifikatsanfragen (CSRs) sowie selbst unterschriebene SSL-Zertifikate mit SHA2 (SHA256). Zudem wird bei SSL-Zertifikaten nun auch der SHA256-Fingerabdruck angezeigt. Der Ruf von SHA1 ist ja auch schon etwas angekratzt...

Zitat von andreas

Es müsste doch lauten "Die Domain ... ist nicht über https verfügbar"

Hmm, stimmt... Dafür müssen wir aber in die SSL-vHost-Konfiguration noch eine andere ErrorDocument-Anweisung aufnehmen.
Wird gleich erledigt, kommt kurzfristig im nächsten Update.

Zitat

Bei mir schreibt LC nichts ins Logfile beim Updaten des Dovecot, FTP usw., beim Apache schon. ist das normal?

Ja, ist (noch) normal. Es werden derzeit noch nicht für alle Dienste die Programm-Ausgaben vom Neustart protokolliert (wird derzeit schrittweise ausgebaut).

Vielen Dank für die Hilfe bei der Fehlersuche. Die aktuelle Version 1.7.5 behebt das Problem.

Viele Grüße & einen schönen Abend

-Klaus Keppler

Ab sofort steht LiveConfig 1.7.5 (r3127) für den produktiven Einsatz bereit.
Schwerpunkt dieses Updates ist die SSL-Konfiguration der von LiveConfig verwalteten Dienste - konkret die Abschaltung von SSLv3 aufgrund der kürzlich bekannt gewordenen "Poodle"-Angriffsmöglichkeit.

Die Änderungen sind:

• Konfiguration eines Standard-SSL-Zertifikats für SNI-Konfigurationen mit Apache httpd
• automatischer Verbindungsaufbau zur MySQL-Datenbank nach Neustart des LiveConfig Server-Prozesses
• OpenSSL von 1.0.1i auf 1.0.1j aktualisiert
• SSLv3 für HTTPS/LCCP-Schnittstellen von LiveConfig deaktiviert
• SSLv3 aufgrund der POODLE-Attacke für alle konfigurierten Dienste deaktiviert (Apache, NGINX, Postfix, Dovecot, ProFTPd, vsftpd)
• Übersetzungen aktualisiert
• Unterzeichnung von Zertifikatsanfragen (CSR) und selbstsignierten Zertifikaten mit SHA256; Anzeige des SHA256-Fingerabdrucks von SSL-Zertifikaten

Was die SNI-Konfiguration von nginx betrifft: hier wird es in Kürze noch ein separates Update geben.

Um die Konfigurationen der von LiveConfig verwalteten Dienste zu aktualisieren, gehen Sie bitte wie folgt vor:

• Apache/nginx: irgendeine IP-Gruppe bearbeiten (z.B. an den Namen irgendein Zeichen anfügen) & speichern
• FTP: Button "neu konfigurieren" klicken
• Postfix: Button "bearbeiten..." klicken und dort direkt auf "speichern"
• Dovecot: Button "bearbeiten..." klicken und dort direkt auf "speichern"

Das Update lässt sich wie immer reibungslos über die Repositories einspielen.

Viele Grüße

-Klaus Keppler

Danke für die Rückmeldung. Ich habe noch ein paar Tests durchgeführt und dabei festgestellt, dass dieses Verhalten auftritt wenn der LiveConfig-Server-Prozess beendet wird (durch einen Fehler oder ein gezieltes kill-Signal). Unter bestimmten Umständen versucht der Server-Prozess dann aber nicht die MySQL-Verbindung wieder aufzubauen (wird gleich behoben...).
So oder so ist jedenfalls etwas passiert, was nicht hätte passieren dürfen: der LiveConfig-Server-Prozess hatte irgend ein Problem. Könnten Sie bitte prüfen, ob in der Datei /var/log/liveconfig/liveconfig.log irgendwelche Stacktraces zu finden sind? (suchen Sie darin einfach nach dem Begriff "trace"). Falls ja, senden Sie uns diesen Abschnitt oder die ganze Log-Datei bitte an support@liveconfig.com.

Der Bugfix zum automatischen MySQL-Reconnect kommt noch mit in die gerade in Fertigstellung befindliche v1.7.5 mit hinein.

Viele Grüße

-Klaus Keppler

Per Cron-Job lässt sich das leider nicht lösen.
Die Meldung "Not connected" kann nur unter zwei Bedingungen auftauchen:
- wenn LiveConfig frisch gestartet wird, oder
- wenn die Verbindung zwischen LiveConfig und dem zuständigen Child-Prozess aktiv beendet wurde (z.B. weil der LiveConfig-Client-Prozess beendet wurde)

Darf ich fragen welche Version Sie aktuell einsetzen? Falls Sie LiveConfig 1.7.4 <r3109 verwenden, aktualisieren Sie bitte auf die neueste Version (mind. 1.7.4-r3112). Dort wurde ein Fehler im LiveConfig-Client-Prozess beseitigt, der in seltenen Fällen zur Unterbrechung der Verbindung mit dem Server geführt hatte.

Viele Grüße

-Klaus Keppler

Was genau liefert bei Ihnen die Ausgabe des Befehls "/usr/bin/php-cgi -v" ?
Haben Sie eine besondere PHP-Version installiert? (also z.B. aus einem anderen Repository oder manuell compiliert)

Hallo,

hatten Sie eventuell zwischendurch einen Neustart des Servers oder ein Upgrade von liveconfig & mysql-server durchgeführt?
Wenn LC die Verbindung zur MySQL-Datenbank verliert stellt es diese eigentlich automatisch wieder her. Ich kann mir lediglich vorstellen, dass LC sich beim Start nicht mit MySQL verbinden konnte und daher keinen neuen Versuch unternommen hat (diesen Fall testen wir hier später mal durch).

Viele Grüße

-Klaus Keppler

Zitat von aziegler

Danke. Auch ohne NOUPDATE macht man diese Änderungen wohl schneller per Skript als sich auf jedem verwalteten Server manuell durchzuklicken, da wird man ja wahnsinnig...

CLI kommt ja auch bald. Beim nächsten SSL-Desaster reicht dann (voraussichtlich) so etwas ähnliches wie

aptitude update
aptitude upgrade
liveconfig --cli reconfigure web mail ftp

Zitat

Was ist mit
http://www.postfix.org/postconf.5.html#smtp_tls_protocols

Hmm, stimmt - sollte der Vollständigkeit halber auch mit dazu. Zwar ist es schwer bis unmöglich, einen SMTP-Client mit POODLE anzugreifen, aber wer weiß was da noch kommt...

Ab sofort steht LiveConfig v1.7.5 (r3122) als Preview zum Download bereit.
Wir haben uns dazu entschlossen, noch mal eine Zwischenversion vor der v1.8 herauszugeben, welche die aktuell bekannt gewordene SSLv3-Sicherheitslücke betrifft.

Die Änderungen sind:

• Aktualisierung der OpenSSL-Bibliothek auf die heute freigegebene Version 1.0.1j
• Deaktivierung von SSLv3 in LiveConfig (HTTPS/LCCP)
• Deaktivierung von SSLv3 in allen von LiveConfig verwalteten Diensten (s.u.!)

Zudem wird nun für HTTPS auf gemeinsamen IPs (also mit SNI) automatisch ein Standard-SSL-Zertifikat erzeugt.

Um die Konfigurationen der von LiveConfig verwalteten Dienste zu aktualisieren, gehen Sie bitte wie folgt vor:

• Apache/nginx: irgendeine IP-Gruppe bearbeiten (z.B. an den Namen irgendein Zeichen anfügen) & speichern
• FTP: Button "neu konfigurieren" klicken
• Postfix: Button "bearbeiten..." klicken und dort direkt auf "speichern"
• Dovecot: Button "bearbeiten..." klicken und dort direkt auf "speichern"

Wir testen die neue LiveConfig-Version morgen Vormittag noch ausführlich durch; wenn keine Fehler auftauchen (bzw. gemeldet werden ;)) dann wird die neue Version morgen Nachmittag produktiv freigegeben.

Viele Grüße

-Klaus Keppler

So, die Änderungen sind alle eingecheckt und werden nun von unserem Jenkins compiliert & getestet (das dauert noch eine Weile...). Sobald die Pakete fertig sind gebe ich noch mal Bescheid.

Die geänderten Einstellungen sind:

• Apache:
  [highlight]SSLProtocol ALL -SSLv2 -SSLv3[/highlight]
• nginx:
  [highlight]ssl_protocols TLSv1;[/highlight] (bzw. [highlight]ssl_protocols TLSv1 TLSv1.1 TLSv1.2;[/highlight] mit nginx 1.1.13+ und 1.0.12+)
• Postfix:
  [highlight]smtpd_tls_protocols = !SSLv2, !SSLv3[/highlight] (Postfix v2.6+)
  [highlight]smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3[/highlight] (Postfix v2.5)
  [highlight]smtpd_tls_mandatory_protocols = TLSv1[/highlight] (Postfix <v2.5)
• Dovecot:
  Dovecot 1.x: SSLv3 kann nicht abgeschaltet werden (s.u.)
  Dovecot ab 2.1: [highlight]ssl_protocols = !SSLv2 !SSLv3[/highlight]
• ProFTPd:
  [highlight]TLSProtocol TLSv1[/highlight]
• vsftpd:
  keine Änderung notwendig, SSLv3 war bereits deaktiviert (ssl_sslv3=NO)

Bei Dovecot 1.x/2.0 lässt sich SSLv3 nicht abschalten (zumindest nicht ohne den Code zu patchen). Das ist aber auch nicht dramatisch, da die POODLE-Attacke voraussetzt, dass der Angreifer die Daten beeinflussen kann, die zum Server gesendet werden - wie auch bei den BEAST- und CRIME-Angriffen. Das klappt in der Praxis nur dann mit realistischem Aufwand, wenn man in eine Webseite JavaScript-Code einschleust und den Datenverkehr komplett abhören kann (z.B. mit WLAN-Proxies). Da bei POP3/IMAP-Zugriffen praktisch kein Einfluss auf die vom Client zum Server gesendeten Daten genommen werden kann, ist ein Angriff dort (nach derzeitigem Wissensstand) praktisch nicht möglich.

Insgesamt ist der POODLE-Angriff ernst zu nehmen, aber nicht annähernd so schlimm wie Heartbleed oder Shellshock. Es handelt sich um einen Angriff auf den Client (konkret: auf den Webbrowser), der auch nur dann möglich ist, wenn man die komplette Kommunikation zwischen Client und Server "abhören" kann (insbes. also bei WLANs).