Beiträge von mjk

Ich habe hier seit dem Update auf r5120 leider den Fehler, das beim Löschen einer Subdomain der Serverprozess (Business-Lizenz von LiveConfig) sich verabschiedet:

[2018/11/14 03:55:55.800935] [27232|27232] Server child process 27409 terminated; uncaught signal: 11 (Segmentation fault)
[2018/11/14 03:55:55.800982] [27232|27232] Resource usage statistics:
[2018/11/14 03:55:55.800992] [27232|27232]        Uptime: 73 sec.
[2018/11/14 03:55:55.801001] [27232|27232]     User time: 0.0048
[2018/11/14 03:55:55.801047] [27232|27232]   System time: 0.0004
[2018/11/14 03:55:55.801076] [27232|27232] Backtrace: (liveconfig/server, r5120)
[2018/11/14 03:55:55.801092] [27232|27232]   [ 0] 000012aca8
[2018/11/14 03:55:55.801102] [27232|27232]   [ 1] 00000ec486
[2018/11/14 03:55:55.801111] [27232|27232]   [ 2] 000000f890 /lib/x86_64-linux-gnu/libpthread.so.0
[2018/11/14 03:55:55.801122] [27232|27232]   [ 3] 0000081c3a /lib/x86_64-linux-gnu/libc.so.6
[2018/11/14 03:55:55.801131] [27232|27232]   [ 4] 0000184a4a
[2018/11/14 03:55:55.801139] [27232|27232]   [ 5] 00000cbbba
[2018/11/14 03:55:55.801148] [27232|27232]   [ 6] 000011ed3d
[2018/11/14 03:55:55.801157] [27232|27232]   [ 7] 000011ed91
[2018/11/14 03:55:55.801165] [27232|27232]   [ 8] 00005106a2
[2018/11/14 03:55:55.801174] [27232|27232]   [ 9] 0000008064 /lib/x86_64-linux-gnu/libpthread.so.0
[2018/11/14 03:55:55.801184] [27232|27232]   [10] 00000e862d /lib/x86_64-linux-gnu/libc.so.6
[2018/11/14 03:55:55.801215] [27232|27232]   Data[0]: 'STATS'
[2018/11/14 03:55:55.803154] [27453|27453] Server child started...
[2018/11/14 03:55:55.816046] [27453|27460] Updating AppInstaller repository (https://update.liveconfig.com/repo-v3.json)...
[2018/11/14 03:55:56.038361] [27232|27232] Server child process 27453 terminated; uncaught signal: 11 (Segmentation fault)
[2018/11/14 03:55:56.038393] [27232|27232] Resource usage statistics:
[2018/11/14 03:55:56.038404] [27232|27232]        Uptime: 1 sec.
[2018/11/14 03:55:56.038414] [27232|27232]     User time: 0.0000
[2018/11/14 03:55:56.038445] [27232|27232]   System time: 0.0012
[2018/11/14 03:55:56.038464] [27232|27232] Backtrace: (liveconfig/server, r5120)
[2018/11/14 03:55:56.038479] [27232|27232]   [ 0] 000012aca8
[2018/11/14 03:55:56.038489] [27232|27232]   [ 1] 00000ec486
[2018/11/14 03:55:56.038499] [27232|27232]   [ 2] 000000f890 /lib/x86_64-linux-gnu/libpthread.so.0
[2018/11/14 03:55:56.038511] [27232|27232]   [ 3] 0000081c3a /lib/x86_64-linux-gnu/libc.so.6
[2018/11/14 03:55:56.038521] [27232|27232]   [ 4] 0000184a4a
[2018/11/14 03:55:56.038530] [27232|27232]   [ 5] 00000cbbba
[2018/11/14 03:55:56.038540] [27232|27232]   [ 6] 000011ed3d
[2018/11/14 03:55:56.038550] [27232|27232]   [ 7] 000011ed91
[2018/11/14 03:55:56.038559] [27232|27232]   [ 8] 00005106a2
[2018/11/14 03:55:56.038569] [27232|27232]   [ 9] 0000008064 /lib/x86_64-linux-gnu/libpthread.so.0
[2018/11/14 03:55:56.038579] [27232|27232]   [10] 00000e862d /lib/x86_64-linux-gnu/libc.so.6
[2018/11/14 03:55:56.039999] [27462|27462] Server child started...
[2018/11/14 03:55:56.050341] [27462|27469] Updating AppInstaller repository (https://update.liveconfig.com/repo-v3.json)...

Ist das ein bereits bekannter Fehler?

Edit:
Debian Jessie 8.11

aziegler: Danke für das Angebot, mir ging es allerdings primär erstmal darum, ob die Sache mit Debian 9 behoben ist bzw. ob es eine temporäre Lösung vorab gegeben hätte. In diesem Fall werden wir die Server-Upgrades entsprechend vorziehen.

Ich muss das Thema leider doch nochmal hervorholen. Insbesondere aufgrund der aktuellen Situation in Hinsicht der DSGVO sollten ja nun alle Dienste wenn möglich auf Verschlüsselung setzen. Wenn nur verschlüsselte Verbindungen erlaubt sind (SSL Session reuse aber deaktiviert) dann bestehen die Probleme nach wie vor - langsame Verbindungen, abgebrochene Connects usw... leider nicht nur mit FileZilla, sondern so wie es aussieht auch mit anderen Clients (z.B. WinSCP). proftpd-basic hat in Debian 8 die Version "1.3.5-1.1+deb8u2" - sind dort die aktuellen Patches noch immer nicht enthalten? Welche Lösungsvarianten hätten wir in der Sache, ausser einem Upgrade zu Debian 9 (funktioniert dort denn FTP über TLS einwandfrei?) ? Kennt jemand einen FTP-Client, welcher mit SSL und Debian 8 einwandfrei läuft?

Zusatzfragen:

1.
Soweit mir bekannt, kann der Kunde derzeit in seinem eigenen Zugang nicht selbst einstellen, wie lange die Logs aufbewahrt werden oder ob diese anonymisiert werden sollen. Habe ich da etwas übersehen, wird das noch implementiert oder wird auch zukünftig nur in den Vertragseinstellungen diese Möglichkeit gegeben sein?

2.
Wenn die Speicherzeit der Logs noch auf dem Standard-Wert (100 Tage) steht, es bereits Verträge mit diesem Wert gibt und man diesen Wert in den Angeboten nun nachträglich anpasst - wird dies von LiveConfig für alle angelegten Verträge übernommen und anschließend beim nächsten Logrotate berücksichtigt?

Kurze Rückinfo von meiner Seite aus in der Sache:
Der Fehler ist bis dato nicht mehr bei uns aufgetreten. Die doppelten IP-Adressen habe ich bestehen lassen, wir hatten allerdings vor kurzem eine Migration aller Serversysteme. LiveConfig hat in diesem Zusammenhang wohl automatisch die geänderte Netzwerkkonfiguration erkannt, die alten IPs entfernt und die neuen Adressen in der Datenbank eingetragen, nun stimmt die Auflistung wieder.

Zitat von antondollmaier

Gut, hat sich ja Ende der Woche erledigt, da dann ja Zeitumstellung ist.

So kann man es auch sehen. Dann haben die Entwickler wieder Zeit bis zum 26.03.2017, das entsprechend zu fixen

Hallo,

einigen Kunden von uns ist aufgefallen, dass die Uhrzeit auf der LiveConfig-Oberfläche "falsch" angezeigt wird, nämlich genau 1 Stunde zurück. Die Uhrzeit scheint aber nicht falsch zu sein, sondern derzeit lediglich im CET-Format angezeigt zu werden (statt CEST). Auf dem Serversystem selbst ist die Timezone richtig konfiguriert und in Liveconfig in den Einstellungen auch "Europe/Berlin (CEST) [GMT +02:00]" ausgewählt worden. Das scheint also lediglich eine kosmetische Sache zu sein, welche allerdings die Kunden irritiert - oder habe ich eine Einstellungsmöglichkeit übersehen?

Eine Tabelle "SERVERIPS" existiert nicht, dafür aber eine Tabelle "IPS":

mysql> select * from IPS;
+-------+-------------+----------------+------------+----------------------+------------+----------+
| IP_ID | IP_SERVERID | IP_INTERFACEID | IP_VERSION | IP_ADDRESS           | IP_NETMASK | IP_FOUND |
+-------+-------------+----------------+------------+----------------------+------------+----------+
|     1 |           1 |              1 |          4 | 144.XX.XXX.XXX       |         27 |        1 |
|     2 |           1 |              1 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
|     3 |           2 |              2 |          4 | 88.XXX.XXX.XXX       |         27 |        1 |
|     4 |           2 |              2 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
|     5 |           3 |              3 |          4 | 88.XXX.XXX.XXX       |         27 |        1 |
|     6 |           3 |              3 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
|     7 |           4 |              4 |          4 | 136.XXX.XXX.XXX      |         26 |        1 |
|     8 |           4 |              4 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
|     9 |           5 |              5 |          4 | 78.XX.XXX.XXX        |         27 |        1 |
|    10 |           5 |              5 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
|    11 |           3 |              3 |          4 | 88.XXX.XXX.XXX       |         27 |        1 |
|    12 |           3 |              3 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
|    13 |           4 |              4 |          4 | 136.XXX.XXX.XXX      |         26 |        1 |
|    14 |           4 |              4 |          6 | 2a01:XXX:XXX:XXXX::2 |         64 |        1 |
+-------+-------------+----------------+------------+----------------------+------------+----------+
14 rows in set (0.00 sec)

Doppelte IPs:
ID 5 + 11, 6 + 12
ID 7 + 13, 8 + 14

Diese werden unter "Server" -> "Serververwaltung" dann ebenfalls doppelt angezeigt:

[Blockierte Grafik: http://fs5.directupload.net/images/160730/ttmgerex.png]

Genügt in der Sache ein einfaches

delete from IPS where ID > 10;

oder sollten zur Sicherheit zuvor noch andere Dinge geprüft werden? Welche Tabellen nutzen derzeit die IPS Tabelle, dann könnte ich einmal nachsehen ob die doppelten IDs dort aufgeführt sind?

Hallo,

bei der Durchsicht in Liveconfig (Bereich Server) ist mir soeben aufgefallen, dass bei unserem Datenbank- und Mailserver-System 2 IP-Adressen für IPv4/IPv6 angezeigt wurden. Bei Aufruf des Servers in der Auflistung stellte sich heraus, dass die jeweiligen Adressen exakt identisch sind, also doppelt angezeigt werden. In der Liveconfig-Datenbank tauchen die Adressen ebenfalls in der Tabelle "IPS" mit anderer ID auf (jeder Server hat normalerweise 1x IPv4 + 1x IPv6, jetzt hat jeder Server allerdings 4 Einträge).

LiveConfig Version: 2.2.0 (r4254), Business Edition
Auf dem Mail-/Datenbankserver ist lcclient installiert und aktiv, genauso wie bei den Webserver-Systemen. Bei den letzteren ist aber keine doppelte IP vorhanden. In den Logs konnte ich auf die schnelle ebenfalls nichts finden.

Irgendwelche Ideen?

Grüsse,

Michael

Manchmal sieht man den Wald vor lauter Bäumen nicht... Vielen Dank Herr Keppler, die von Ihnen beschriebene Lösung funktioniert einwandfrei.

Entschuldigt wenn ich diesen Topic nach langer Zeit wieder hervorhole, allerdings suche ich nach einer Lösung für eine Aktivierung der richtigen ionCube-Version individuell pro Kunde. Folgendes Problem:

1. In /opt/php-X.X/etc/conf.d/ läßt sich die Konfiguration zwar pro Version, aber nur Global anpassen, das möchte ich nicht.

2. Es gibt in den Userverzeichnissen zwar das Verzeichnis "conf" (/var/www/webX/conf/phpXX), die dortige php.ini wird aber bei Änderungen überschrieben. Ein conf.d Verzeichnis existiert dort nicht.

3. Wenn ich eine neue Option bei den "PHP-Einstellungen" in der Liveconfig Weboberfläche eintrage, dann gilt diese für alle PHP-Versionen beim jeweiligen Vertrag Global. Ich kann im Falle von IonCube also nur eine Version korrekt konfigurieren und die PHP-Option beim jeweiligen Vertrag aktivieren.

Habe ich eine Einstellungsmöglichkeit übersehen, oder kann man IonCube derzeit wirklich nur Global in allen Verträgen aktivieren, wenn das ganze mit allen PHP-Versionen funktionieren soll?

Bisher ist das Problem noch nicht gelöst, zumindest nicht unter Debian 8. Wir haben derzeit nur in Zusammenhang mit Filezilla entsprechende Kundenrückmeldungen. Die einzigen Möglichkeiten wären wohl, entweder proFTPd zu entfernen und zu ersetzen (z.B. durch vsFTP) oder die aktuelle proFTPd Version selbst zu kompilieren. Mir wäre die erste Variante lieber, allerdings gibt es wohl in Liveconfig keine direkt ersichtliche Möglichkeit, einmal konfigurierte Dienste wieder zu entfernen, daher ja auch mein Posting vom 17.03. mit dieser Anfrage.

Leider besteht dieses Problem noch immer und seitens Debian ist noch keine Lösung in Sicht. Wäre es denn praktikabel, den bestehenden proFTPd gegen vsftpd auszutauschen? Die Installation unter Debian selbst wäre kein Problem, aber gibt es hierzu etwas unter LiveConfig zu beachten? Wie bekomme ich den proFTPd dort vorher aus der Serververwaltung wieder heraus?

Hallo Herr Keppler,

das Problem ist am gestrigen Tag auch bei uns aufgetreten:

[Blockierte Grafik: http://fs5.directupload.net/images/151227/fubeascu.png]

Die Datenbank wird durchgestrichen in LiveConfig angezeigt, aber bei der Gesamtzahl der zulässigen Datenbanken noch mit eingezählt. Wir verwenden LiveConfig 2.0.1 Standard auf dem DB-Server (MySQL 5.5.46 (5.5.46-0+deb8u1, Debian Jessie 64 Bit), zusammen mit einer LiveConfig Business-Lizenz für die Verwaltungsoberfläche auf einem anderen System (ebenfalls Debian Jessie). Die Datenbank selbst wurde wohl auf dem Datenbankserver bereits gelöscht, fehlerhaft ist also lediglich noch der Eintrag in der LiveConfig-Datenbank.

Die Logdateien zeigen leider keine weiteren Details, lcclient und liveconfig wurden bereits auf beiden Systemen neu gestartet. Gibt es einen einfachen Weg, den Fehler zu beheben? Wir verwenden eine MySQL-Datenbank auf dem Server mit der Business-Lizenz, reicht es dort einfach ebenfalls den DB_STATUS neu zu setzen wie im Posting vom 22.09.2012 beschrieben, oder können wir bei der Fehlersuche noch anderweitig behilflich sein?

Hallo,

da dieses Problem bereits das zweite Mal bei mir auftritt, frage ich diesmal zur Sicherheit hier im Forum nach. Wir hatten für einen Kunden eine normale HTML-Seite auf den LiveConfig-Server umgezogen, heute ist aufgefallen das eine 403-Forbidden-Meldung erscheint (.htaccess könne nicht gelesen werden). Nach kurzer Recherche haben wir festgestellt, das die Zuordnungen der Verzeichnisse wie folgt waren:

drwxr-x--- 7 www-data web58    4.0K Nov 22 22:24 conf
drwxr-x--- 3 web58    web58    4.0K Dec  2 15:19 htdocs
drwxr-x--- 3 www-data web58    4.0K Dec  3 06:25 logs
drwxr-x--- 2 web58    web58    4.0K Nov 22 22:24 priv
drwxrwx--- 2 web58    www-data 4.0K Nov 22 22:24 tmp

Dadurch hatte der Apache-Daemon keinen Lesezugriff auf htdocs, da dieses Verzeichnis ebenfalls der Gruppe "web58" gehörte. Sobald man die Gruppe per chown korrigierte, funktionierte der Zugriff wieder:

drwxr-x--- 3 web58    www-data 4.0K Dec  2 15:19 htdocs

Die Frage ist nun lediglich, woher dieser Fehler kommt. Ich kann leider nicht genau sagen ob die Gruppenzuordnung bereits nach Erstellung des Vertrags so bestand oder erst später geändert wurde - ich meine mich aber erinnern zu können, das wir nach dem Umzug der Webseite die Aufrufbarkeit getestet hatten und dort alles einwandfrei lief. Der Fehler trat exakt so auch bereits bei einem anderen Account in der Vergangenheit auf. Zur Sicherheit habe ich eben auch nochmal alle anderen Accounts auf dem Server geprüft, dort war alles korrekt der Gruppe www-data zugewiesen.

Fehler gefunden:
In Apache ist mod_negotiate per Standard aktiv. Da "Options MultiViews" gesetzt ist, hatte dies mit mod_rewrite kollidiert, da der Kunde zusätzlich folgende Dateien auf dem Webspace hatte:

/impressum.php
/kontakt.php
usw.

Ein mod_rewrite von domain.de/impressum funktionierte somit beispielsweise nicht mehr. Lösung: In der .htaccess-Datei MultiViews ausschalten:

Options -MultiViews

Bei der Kontrolle der übrigen Konfiguration ist mir desweiteren aufgefallen, dass php5-cgi nicht unter /etc/apache2/conf-enabled auftaucht. Mittels "a2enconf php5-cgi" kann dies natürlich geändert werden, da PHP als FastCGI-Variante derzeit aber einwandfrei läuft stelle ich mir die Frage, ob dies überhaupt aktiviert werden muss?

Leider stosse ich hier auf ein ähnliches Problem, Apache gibt mir unter Debian Jessie diesen Fehler aus:

[negotiation:error] [pid 3211] [client 1.2.3.4:36781] AH00687: Negotiation: discovered file(s) matching request: /var/www/web60/htdocs/impressum (None could be negotiated)., referer: http://domain.de/

php5-cgi ist installiert:

apt-get install php5-cgi
Reading package lists... Done
Building dependency tree       
Reading state information... Done
php5-cgi is already the newest version.

lcclient --diag

Distribution description: 'Debian GNU/Linux 8.2 (jessie)'
Checking for web server software:
 - Found 'apache' web server
   Version: '2.4.10'
   Package version: '2.4.10-10+deb8u3'
   SNI support: yes
   Modules: core so watchdog http log_config logio version unixd access_compat alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex cgi deflate dir env fcgid filter mime mpm_prefork negotiation php5 proxy proxy_http rewrite setenvif socache_shmcb ssl status suexec
 - PHP 5.4.45 (code='php54', bin='/opt/php-5.4/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-5.4/etc/php.ini'
 - PHP 5.5.30 (code='php55', bin='/opt/php-5.5/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-5.5/etc/php.ini'
 - PHP 5.6.15 (code='php56', bin='/opt/php-5.6/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-5.6/etc/php.ini'
 - PHP 7.0.0 (code='php70', bin='/opt/php-7.0/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-7.0/etc/php.ini'
 - PHP 5.6.14 (code='php5', bin='/usr/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/etc/php5/cgi/php.ini'

cgi-Modul ist aktiviert:

a2enmod cgi
Module cgi already enabled

liveconfig und lcclient wurden ebenfalls neu gestartet und auch mehrfach bei dem betreffenden Kunden etwas am Vertrag geändert, damit die Config neu erstellt wird, trotzdem bleibt der Fehler. Verwendet wird eine .htaccess-Datei mit folgenden Rewrite-Rules:

RewriteEngine on 


RewriteRule ^([a-zA-Z0-9]*)/$ index.php?i=$1
RewriteRule ^([a-zA-Z0-9]*)$ index.php?i=$1

Habe ich irgendwo etwas übersehen?

Ein SSH-Tunnel wäre eine Möglichkeit, allerdings sollen mehrere Datenbankserver unterstützt werden. Dort sehe ich dann nur die Möglichkeit, diese über verschiedene Ports auf "localhost" mittels SSH-Tunneln anzubinden. Da LiveConfig aber bereits eine SSL-Unterstützung für externen Datenbankzugriff mitbringt, dachte ich es gäbe eine einfachere Möglichkeit um bei jedem Connect SSL zu verwenden.

Hallo,

zwei kurze Fragen - in Benutzung ist eine LiveConfig Business-Lizenz mit jeweils separatem Web-, Mail- und Datenbankserver.

Auf dem Datenbankserver ist SSL konfiguriert, Liveconfig zeigt in der Serververwaltung auch die SSL-Unterstützung an. "Externer Zugriff" ist dort deaktiviert, bei dem Punkt "Zugriff erlaubt" steht aber die IP-Adresse des Webservers. Ist es möglich, die Datenbankverbindungen zwischen diesen beiden Systemen per Standard zu verschlüsseln? In der jetzigen Einstellung gestattet MySQL den Zugriff von der IP, aber Verschlüsselung findet wohl nicht statt.

Gibt es eine Möglichkeit bei einem bestehenden Kundenvertrag den Server zu wechseln? Beispielsweise wenn der Kunde bisher den Webspace auf Server1 genutzt hatte, nun aber auf Server2 wechseln will, der Mail- und Datenbankserver aber identisch bleiben soll.

Grüsse,

Michael

Hallo Herr Keppler,

vielen Dank für die schnelle Rückantwort! Ihre Vermutung war richtig, ein "aptitude install php5-cgi" gefolgt von einem Restart des lcclient Dienstes hat den Fehler behoben, bei den übrigen Accounts wurde das Verzeichnis "php5" nun auch angelegt. Ich ging fälschlicherweise am Anfang davon aus, dass LiveConfig eine der FastCGI-Versionen aus /opt nutzen wird, sofern keine Standard-Version von Debian selbst installiert ist. Gibt es auch die Möglichkeit, eine Standard-FastCGI Variante innerhalb eines Angebots festzulegen, welche dann nur bei der Ersterstellung voreingestellt wird?

Grüsse,

Michael