Beiträge von loswebos.de

Ergänzung, diesmal "CentOS release 6.7 (Final)"

Zitat

service liveconfig stop
Stopping LiveConfig Server: liveconfigCan't get shared memory segment: Invalid argument
Server not running?

Scheinbar stoppen die LiveConfig Prozesse nicht automatisch, sofern ich die "kille" ändert sich am Bild auch nichts.

Wird dann auch unter Nginx passend zur gewählten PHP Version die richtige php.ini verwendet werden?

# NGINX_FCGI_INI_PATH=/var/www/##user##/conf/php5
# NGINX_FCGI_BIN=/usr/local/php/56x/bin/php-cgi

sollte ja korrekter Weise

# NGINX_FCGI_INI_PATH=/var/www/##user##/conf/[COLOR='#FF0000']php_56x[/COLOR]
# NGINX_FCGI_BIN=/usr/local/php/56x/bin/php-cgi

lauten.

Also in der Preview, meine ich

Hallo Herr Keppler,

kann ich leider nicht nachvollziehen, bin aber der Meinung dass ich die Prozesse gekillt hatte.
Den Server hatte ich fix rebootet, danach ging's logischerweise.

Hallo,

beim Update von 2.0.1 (r3988) auf 2.0.2-r4019 lässt sich LiveConfig nicht neu starten.
OS: CentOS Linux release 7.2.1511

service liveconfig restart
Stopping LiveConfig Server: liveconfigCan't get shared memory segment: [B]Invalid argument[/B]
Server not running?
failed!
Starting LiveConfig Server: liveconfig - /usr/sbin/liveconfig: Server already running? Can't create shared memory segment: Invalid argument
failed!

ipcs
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    


------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x1717e79d 0          root       640        304        3                       


------ Semaphore Arrays --------
key        semid      owner      perms      nsems

Viele Grüße,
Torsten Walther

Hallo,

man kann als Workaround auch temporär die UnitFiles anlegen. Betrifft beispielsweise auch das InitScript für nginx-php-fcgi.

Beispiel für /etc/systemd/system/nginx-php-fcgi.service

[Unit]
SourcePath=/etc/init.d/nginx-php-fcgi
Description=nginx-php-fcgi
After=remote-fs.target systemd-journald-dev-log.socket


[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/nginx-php-fcgi start
ExecStop=/etc/init.d/nginx-php-fcgi stop

Das nur ein sehr generisches Standard Template...

Hallo,

etwas schwierig zu umschreiben.

Hat ein Webhosting Vertrag (Beispiel: user1) keine Domain zugewiesen (somit auch kein nginx-vhosts file) , passiert folgendes:

LiveConfig versucht regelmässig die nginx-php-fcgi Prozesse dieses Users zu beenden:

LC.exec(/etc/init.d/nginx-php-fcgi stop user1): program output: Stopping nginx-php-fcgi (via systemctl):  [  OK  ]

Resultat: Es werden _ALLE_ nginx-php-fcgi Prozesse gekillt, auch die von user2,user3 usw.

Bitte dringend beheben, das Verhalten mit einer DummyDomain zu beheben ist nicht ganz im Sinne des Erfinders.

VG,
Torsten Walther

CentOS7
LiveConfig 2.0.1-r3988

**Push**

10 Zeichen

Naja, dass hat relativ wenig mit LiveConfig zu tun. Einfach mal die MessageID aus dem Maillog grepen und schauen über welchen User diese eingeliefert wurde (SASL, pickup). Das sollte dann schon einige Informationen hinsichtlich des Verursachers liefern.

Hallo,

lt. /usr/lib/liveconfig/lua/nginx.lua ist die Anzahl der NGINX_FCGI_CHILDREN hardgecoded, also in der aktuellen LC Version immer auf 5 gesetzt.

Nun haben wir einige Kunden (ManagedServer mit LiveConfig) welche in bestimmten Setups wesentlich höhere Werte benötigen.

Es wäre praktisch wenn der Wert via Panel je Kunde bestimmt werden könnte.
Bislang watchen wir die nginx.lua nach Updates und Ersetzen den entsprechende Wert.

VG,
Torsten

Hallo,

erstmal besten Dank für die Nginx-PHP-Versionswahl generell. (Okay, wählen konnte man Sie schon immer, nur wurde sie nicht verwendet *g)

Der nginx vhost wird nun mit korrektem Binaryerzeugt, jedoch wird unabhängig von der gewählten PHP Version _immer_ die php.ini der Standard PHP Version verwendet.

Zitat

# PHP-FCGI configuration - DO NOT MODIFY!
# NGINX_FCGI_USER=tools
# NGINX_FCGI_SOCKET=/var/www/tools/conf/sockets/nginx-php-fcgi.php_56x.sock
# NGINX_FCGI_CHILDREN=5
# NGINX_FCGI_MAX_REQUESTS=1000
# NGINX_FCGI_INI_PATH=/var/www/tools/conf/php5
# NGINX_FCGI_BIN=/usr/local/php/56x/bin/php-cgi

Alles anzeigen

Statt /var/www/tools/conf/php5 müsste dort eigentlich /var/www/tools/conf/php_56x ausgewiesen werden, damit der /etc/init.d/nginx-php-fcgi die richtige INI verwendet.

Viele Grüsse,
Torsten

PS: Und ja, es gibt durchaus Gründe für versionspezifische php.ini's

Besten Dank für die NGINX PHP Versionwahl !

Hallo Herr Keppler,

ist den in der Preview die Länge des Passwort Feldes in der SOAP Api hochgesetzt worden?

Zitat

http://www.liveconfig.com/de/f…d5-Passwort-vorhanden-ist

Nee, wird vermutlich nicht so einfach klappen. Das Passwort-Feld in der SOAP-API darf max. 40 Zeichen lang sein (hängt damit zusammen, dass das LC-intern verschlüsselt und dann Base64-codiert in einem 64-Byte-Feld gespeichert wird).
[...]
Hilft das weiter? Ansonsten müssten wir vermutlich diese 40-Zeichen-Grenze aufbohren.

Da scheinbar (wie in vielen anderen Threads) keine Antwort mehr kommt... muss es halt der Workaround tun. Mit den Einschränkungen, dass kein LiveConfig Weblogin möglich ist bis der MailUser das Passwort ändert. Keine Ahnung welcher Rattenschwanz noch dranhängt.

Den alten Hash in ein File pwd.log

EMAILADRESSE HASH

schreiben und dann .. angelehnt an das cfx-mail.log/rsync vom Confixx Import Skript:

while read line; do
  FROM=`echo "$line" | cut -f 1`;
  TO=`echo "$line" | cut -f 2`;
  echo "SET PWD FOR $FROM TO $TO";
  sed "/^$FROM/ s/##DUMMYHASHWERT##/$TO/" -i.bak /etc/dovecot/passwd
done < pwd.log

Die SOAP Api ist zwar in Summe nicht schlecht, aber sofern nicht sämtlich CREATE/READ/UPDATE/DELETE Features an sämtlichen Objekten, die man via SOAP anlegen kann, umgesetzt sind, ist es eher ein netter Versuch.

Meiner Meinung nach, sollten vor neuen Features oder schicken HTML Tricks erstmal die restlichen Baustellen beseitigt werden.

Dh. beworbenes Feature X sollte auch in allen von Liveconfig angeblich unterstützten Konstellationen nutzbar sein, sofern es das darunter liegende OS auch unterstützt.

Bsp.: PHP Versionswahl unter Nginx sollte lt. http://www.liveconfig.com/de/f…UI-Fragen?p=9525#post9525 noch einige Woche dauern. DAS WAR ENDE FEBRUAR.

Zitat von kk

Hilft das weiter? Ansonsten müssten wir vermutlich diese 40-Zeichen-Grenze aufbohren.

Gibt es den hier ein vorankommen? Fällt die 40 Zeichen Grenze, wenn ja: wann?
Die Workarounds / Alternativen sind eher mühsam. Geht im aktuellen Fall auch um 250 Mailkonten

Mit Änderung des dovecot.LUA Scriptes geht's nicht (Error while calling Web Service: Invalid password, vermutlich wegen der mehr als 40 Zeichen).

Der Workaround mit manuellem Eintrages des CRAM-MD5 Strings in der /etc/dovecot/passwd funktioniert der Abruf via IMAP, POP3.

ABER: Wenn ich via API das Feld weblogin auf True setzen will, klappt die Anmeldung nur mit dem angesprochenen Dummy Passwort. (LiveConfig wird sich bei Mailadressen, ja nicht gegen DoveCot authentifzieren)

Die Erweiterung der 40 Zeichen Grenze würde ich für Sinnvoll halten, dann wäre das ganze in sich "rund".

Das Passwort ist nicht wie longpw beim Confixx gesaltet und würde durch dovecot.lua Passwort Validierung nochmal mittels cram_md5(data.password) gehasht werden.

if string.len(data.password) == 34 and string.match(data.password, "^$1$%w%w%w%w%w%w%w%w$[%w./]+$") then
      -- MD5-CRYPT password (propably imported via SOAP interface)
      pwd = data.password
      algo = "MD5-CRYPT"
    else
      -- create CRAM-MD5 hash
      pwd = LC.crypt.cram_md5(data.password)
      algo = "CRAM-MD5"
    end

Ich werde mal die

pwd = LC.crypt.cram_md5(data.password)

für den Importvorgang auf

pwd = data.password

ändern, dass könnte funktionieren. Da es scheinbar ja schon CRAM-MD5 ist.

Hallo,

Passwort wäre dann 64 x die Raute
PlainMD5 dürfte ja nur 32 haben.

Ich hab mal im Setup des alten Mailserver / Postfixadmin geschaut.

$CONF['encrypt'] = 'dovecot:CRAM-MD5';

Kann man damit was anfangen?

Guten Tag,

wir müssen für einen Kunden ein auf Postfixadmin basiertes Mailsystem nach LiveConfig migrieren. Allerdings haben wir nur MD5 Passwort Hashes die uns zur Verfügung stehen. (Also keine gesalzenen)

Welche Möglichkeiten gibt es diese (alten) Passwörter über die SOAP Api ins LiveConfig zu bekommen?

VG,
Torsten Walther

Da Fragen ggf. in anderen Threads untergegangen sind.

1) Wann wird den die PHP Versionswahl unter Nginx endlich funktionieren?

2) Wenn 1 nicht zeitnah behoben wird / werden kann, warum wird dann nicht wenigstens das Optionsfeld für die Versionswahl ausgeblendet, sofern man eine nginx IP Gruppe für die Domain / Subdomain auswählt?

3) Im Info Popup zu PHP Versionswahl wird auf http://www.liveconfig.com/de/h…torial.domains.phpversion verlinkt. den Artikel gibt es noch nicht.

Im Popup könnte man zumindest darauf hinweisen, dass es bei NGINX nicht funktioniert.

4) Wann könnten denn Nginx AccessLogfiles auf Vertragsebene verfügbar sein?

Bis auf das Nginx Thema, läuft LiveConfig ins Summe relativ "rund" (CentOS 6 & 7).

Wir setzen allerdings LiveConfig aktuell nur bei einigen ManagedServer Kunden ein, da es für den Massengebrauch (SharedHosting) meines Erachtens noch viel zu viele Unstimmigkeiten gibt, die wiederum für _UNS_ viel zu supportaufwendig wären. Schade eigentlich.

Vg,
Torsten Walther