KeyHelp Installer bleibt nach PHP hängen [GELÖST]

[lutvit]

Wenn ich KeyHelp auf einer virtuellen Maschine von linode.com installiere, bleibt der Installer genau nach dem Installieren von PHP hängen.

Hier sind die letzten Einträge im syslog:

Code: Select all

Nov 10 15:13:02 uk-2 systemd[1]: Starting The PHP 7.0 FastCGI Process Manager...
Nov 10 15:13:02 uk-2 systemd[1]: Started ACPI event daemon.
Nov 10 15:13:03 uk-2 systemd[1]: Started The PHP 7.0 FastCGI Process Manager.
Nov 10 15:13:03 uk-2 php7.0-intl: php_invoke intl: already enabled for PHP 7.0 fpm SAPI
Nov 10 15:13:03 uk-2 php7.0-intl: php_invoke intl: already enabled for PHP 7.0 cli SAPI
Nov 10 15:13:03 uk-2 php7.0-mbstring: php_invoke mbstring: already enabled for PHP 7.0 fpm SAPI
Nov 10 15:13:03 uk-2 php7.0-mbstring: php_invoke mbstring: already enabled for PHP 7.0 cli SAPI
Nov 10 15:13:03 uk-2 php7.0-mysql: php_invoke mysqlnd: already enabled for PHP 7.0 fpm SAPI
Nov 10 15:13:03 uk-2 php7.0-mysql: php_invoke mysqlnd: already enabled for PHP 7.0 cli SAPI
Nov 10 15:13:04 uk-2 php7.0-mysql: php_invoke mysqli: already enabled for PHP 7.0 fpm SAPI
Nov 10 15:13:04 uk-2 php7.0-mysql: php_invoke mysqli: already enabled for PHP 7.0 cli SAPI
Nov 10 15:13:04 uk-2 php7.0-mysql: php_invoke pdo_mysql: already enabled for PHP 7.0 fpm SAPI
Nov 10 15:13:04 uk-2 php7.0-mysql: php_invoke pdo_mysql: already enabled for PHP 7.0 cli SAPI
Nov 10 15:13:04 uk-2 systemd[1]: Reloading.
Nov 10 15:13:04 uk-2 systemd[1]: Started ACPI event daemon.
Nov 10 15:13:04 uk-2 systemd[1]: Reloading.
Nov 10 15:13:04 uk-2 systemd[1]: Stopping The PHP 7.0 FastCGI Process Manager...
Nov 10 15:13:04 uk-2 systemd[1]: Started ACPI event daemon.
Nov 10 15:13:04 uk-2 systemd[1]: Stopped The PHP 7.0 FastCGI Process Manager.
Nov 10 15:13:04 uk-2 systemd[1]: Starting The PHP 7.0 FastCGI Process Manager...
Nov 10 15:13:04 uk-2 systemd[1]: Started The PHP 7.0 FastCGI Process Manager.
Nov 10 15:15:01 uk-2 CRON[8863]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Nov 10 15:15:17 uk-2 systemd[1]: Started Session 3 of user root.

Dieser Fehler tritt auf bei Ubuntu 16.04, 18.04, Debian 9.

KeyHelp Installer log gibt es nicht. Es gibt kein Verzeichnis unter dem Pfad /var/log/keyhelp/

Ich denke, dass der Fehler in der Funktion "create_keyhelp_user" liegt.

[lutvit]

Habe versucht, die folgenden Befehle vor der Installation auszuführen, kein Erfolg:

Code: Select all

useradd --home-dir /home/keyhelp/ -M --shell /bin/false keyhelp
usermod --home /home/keyhelp/ --shell /bin/false keyhelp
mkdir -p /home/keyhelp/
chown --recursive keyhelp:keyhelp /home/keyhelp/

Es ist auch möglich, dass bash hängen bleibt.

Hier sind Informationen zu bash:

Code: Select all

GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)

[lutvit]

Ich habe ein originales Abbild von ubuntu 18.04 manuell auf einem VPS von Linode installiert. Das gleiche Problem, wie oben beschrieben. Es liegt also nicht an den Images von Linode.

Ich bin mir sicher, dass ich KeyHelp vor einigen Monaten ohne dieses Problem auf Linode VPS installiert habe.

Das Problem muss irgendwo im Installer liegen.

[OlliTheDarkness]

Ich habe ein originales Abbild von ubuntu 18.04 manuell auf einem VPS von Linode installiert. Das gleiche Problem, wie oben beschrieben. Es liegt also nicht an den Images von Linode.

Ich bin mir sicher, dass ich KeyHelp vor einigen Monaten ohne dieses Problem auf Linode VPS installiert habe.

Das Problem muss irgendwo im Installer liegen.

Moin,
oder das Problem liegt einfach an der konfiguration der VPS.

Ich hatte dieses Problem mit der anscheinend stehenden Installation bei mehreren VSystemen in der Vergangenheit.
Im schlechtesten Fall brauchte die Installation 3+ Stunden war aber letztendlich erfolgreich.

Eine Fehlerquelle war nicht direkt ausmachbar aber durch configen hier testen da und kurz davor stehen alles aus dem Fenster zu werfen (^^) hat sich eine fehlerhafte Netzwerkkonfiguration rauskristalisiert.

Schalte mal nach der Systeminstallation die ipV6 unterstützung ab, starte neu und führe dann mal die KH Install durch...

Bei mir war es in 97% hilfreich.

In den anderen 3% waren es andere dumme Fehler, keiner davon aber auf Seiten von KH

[v3ng]

Ich habe ein originales Abbild von ubuntu 18.04 manuell auf einem VPS von Linode installiert. Das gleiche Problem, wie oben beschrieben. Es liegt also nicht an den Images von Linode.

Ich bin mir sicher, dass ich KeyHelp vor einigen Monaten ohne dieses Problem auf Linode VPS installiert habe.

Das Problem muss irgendwo im Installer liegen.

Moin,
oder das Problem liegt einfach an der konfiguration der VPS.

Ich hatte dieses Problem mit der anscheinend stehenden Installation bei mehreren VSystemen in der Vergangenheit.
Im schlechtesten Fall brauchte die Installation 3+ Stunden war aber letztendlich erfolgreich.

Eine Fehlerquelle war nicht direkt ausmachbar aber durch configen hier testen da und kurz davor stehen alles aus dem Fenster zu werfen (^^) hat sich eine fehlerhafte Netzwerkkonfiguration rauskristalisiert.

Schalte mal nach der Systeminstallation die ipV6 unterstützung ab, starte neu und führe dann mal die KH Install durch...

Bei mir war es in 97% hilfreich.

In den anderen 3% waren es andere dumme Fehler, keiner davon aber auf Seiten von KH

IPv6 musste ich bei mir noch nie deaktiveren, würde ich auch nicht empfehlen.
Schau lieber ob der Hostname/ FQDN im System richtig gesetzt ist, das ist standardmäßig bei Linode nicht der Fall.

[nikko]

Der FQDN ist KH beim Setup zunächst egal. Wenn dieser gesetzt ist, wird SSL (LE) gleich für die Serverdomain angelegt und die Installation läuft betreffend Amavis etc. fehlerfrei durch.
Für die Installationsgeschwindigkeit ist der FQDN nicht ausschlaggebend.
Bei Geschwindigkeitssorgen ist das Disablen von IPV6 durchaus ein sinnvoller Versuch.

[lutvit]

Der Fehler liegt wohl tatsächlich bei IPv6, zumindest bei Linode.com. Vor der Installation muss man es deaktivieren.

Folgenden Befehl ausführen und sysctl.conf bearbeiten:

# nano /etc/sysctl.conf

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Befehl ausführen:

# sysctl -p

Dann sollte die folgende Ausgabe erfolgen:

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Jetzt kann man KeyHelp installieren.

Sollte der Installer wieder hängen bleiben, diesen abbrechen (Ctrl+C) und nochmals ausführen. Hat bei mir funktioniert.

[OlliTheDarkness]

Der Fehler liegt wohl tatsächlich bei IPv6, zumindest bei Linode.com. Vor der Installation muss man es deaktivieren.

Folgenden Befehl ausführen und sysctl.conf bearbeiten:

# nano /etc/sysctl.conf

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Befehl ausführen:

# sysctl -p

Dann sollte die folgende Ausgabe erfolgen:

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Jetzt kann man KeyHelp installieren.

Sollte der Installer wieder hängen bleiben, diesen abbrechen (Ctrl+C) und nochmals ausführen. Hat bei mir funktioniert.

Moin ,

na siehste und das ohne Glaskugel der Weißheit

ipV6 ist und bleibt bei einigen Konfigurationen immernoch das Sorgenkind.

Schön das es nun läuft.

[nikko]

Da ich jetzt nicht weiß, ob die sysctl.conf bei Updates unangetastet bleibt, hier etwas eleganter:

Code: Select all

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Diesen obigen Code ausführen...,
danach eine Datei namens /etc/sysctl.d/01-disable-ipv6.conf anlegen.

Folgenden Code dort hinein:

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1

Abschließend Reboot.