Beiträge von browsingman

    Mir auch nicht wirklich ... deswegen habe ich ja gefragt.


    Aber aufgrund dieser Tatsache wird das Update dann nicht durchgeführt und es erfolgt ein Rollback.

    Finde ich etwas unglücklich. Lief jahrelang problemlos durch und nun seit der 0.401 geht es nicht (mehr).


    Ich habe ja schon überlegt, die Prüfung in der se-update.sh einfach auszukommentieren und zu schauen, was passiert, aber leider weiss ich nicht, was die Entwickler sich dabei gedacht haben und kann die Auswirkung nicht wirklich abschätzen.

    Welche Version von pd-admin wird eingesetzt?

    4.102


    Welche Version der Serverumgebung wird eingesetzt?

    0.401 Reihe 6


    Welche Fehlermeldung erhalten Sie?

    - siehe unten -


    Wie sind die problematischen Dienste konfiguriert?

    Standard SE Installation


    Wenn ich ein Update der SE-Umgebung machen möchte, wird die Installation abgebrochen und es erfolgt ein automatischer Rollback.

    Es erscheint die Fehlermeldung auf dem Bildschirm (und im Log):

    checking subdirectory structure before importing changed files

    /var/mysql: alt:Verzeichnis, zu importieren:Symbolischer Link


    *** Import der neuen/ge▒nderten Dateien/Verzeichnisse ***

    *** kann wegen eines Dateitypkonflikts nicht vorge- ***

    *** men werden. ***



    Wenn ich mir nun die data.inf und data2.inf anschaue, steht in der entsprechenden Zeile

    data.inf -> DA 0000000000000000000000 /var/mysql

    data2.inf -> 0,0


    Im der Pd-Admin SE Umgebung ist /usr/local/pd-admin2/var/mysql ein symbolischer Link auf /home/mysql


    Hat jemand eine Idee, wieso das Update hier nicht durchläuft?

    Ich habe mir das jetzt mal näher angeschaut und bin zu folgender Erkenntnis gekommen:

    a) Der Übergabeparameter $1 übergibt den Hostnamen und nicht die IP-Adresse oder die Port-Adresse

    b) Das führt dazu, das jede Domäne in der Regel zweimal übergeben wird (einmal für den Port 80 und einmal für den Port 443).

    c) Es gibt leider keine Unterscheidungsmöglichkeit, ob es der Container für Port 80 oder der Container für Port 443 ist.


    Das führt dann dazu, das ich ohne großen Aufwand für beide Container nur den gleichen Inhalt hinterlegen kann.


    Wenn ich also eine Proxy-Umleitung nur für SSL anlegen möchte, aber nicht für HTTP, dann müsste ich im Prinzip auch noch einen Zähler einbauen, um hier unterschiedliche Inhalte übergeben zu können.


    Wäre es nicht möglich, den Port als Übergabeparameter $2 mit zu übergeben, damit man das direkt unterscheiden kann?

    Tja,

    dann lebt ihr im Land der Glücklichen und habt entweder kein MySQL 8 oder verwendet MySQL 8 auf einem System mit SSD.


    Auf Systemen mit normalen Festplatten ist MySQL 8 in der Regel um den Faktor 5 - 10 bei UPDATE und INSERT Kommandos langsamer.

    Deswegen dauert dann das Hochstarten des MySQL 8 auch wesentlich länger.


    Als ich noch normale HDD Festplatten hatte, konnte es nach dem Update bis zu 5 Minuten dauern, bis der MySQL Server wirklich verfügbar war.

    Durch den reinen Tausch auf eine SSD dauerte es dann nur noch 30 Sekunden. Also wirklich krass der Unterschied und auch in unendlich vielen Foren bis zum Ende ausdiskutiert (Tuning von Parametern, IIOPS , etc ...).

    Standardmäßig wird MySQL im Verzeichnis /home/mysql abgelegt.

    Ich würde gerne das Verzeichnis auf ein anderes Verzeichnis verlagern, um eine SSD nutzen zu können, die wesentlich mehr IOPS unterstützt.


    Hat jemand hier im Forum Erfahrung, ob das im Zusammenspiel mit pd-admin möglich ist und welche Schritte dafür benötigt werden?

    Ein Hard-Link dürfte ja ausscheiden, da anderes Volume und ob ein Soft-Link ausreichend wäre, vermag ich nicht so schnell zu beurteilen.


    Ok, manchmal hilft es sich das genauer anzuschauen:

    /usr/local/pd-admin2/var/mysql ist ein Symlink auf das eigentliche Data-Verzeichnis.


    Den kann man einfach umbiegen, da die Update Skripts mit readlink immer den eigentlich Pfad auslesen und wiederherstellen.

    Ich betreibe seit mehreren Monaten die Reihe 8 auf einem meiner Server und kann sagen:
    - Sie läuft soweit stabil

    - Die Datenbank-Performance ist mit herkömmlichen Festplatten wesentlich schlechter als mit MySQL 5.5
    (MySQL 8 ist wohl sehr stark auf SSDs optimiert

    -> Teilweise Abhilfe: innodb_buffer_pool_size sowie innodb_buffer_pool_instances so anpassen, das mher Arbeitsspeicher verwendet wird
    -> Update und Inserts sind trotzdem immer noch deutlich langsamer als mit MySQL 5.5)


    Muss man sich also seinen Use Case genau anschauen


    Zum Thema Update wurde ja schon in anderen Forenbeiträgen aufgezeigt, das man erst alle Datenbanken exportieren muss, um sie dann in einer neuen Installation wieder zu importieren. Die dafür von Daniel Bradler bereitgestellten Skripte haben bei mir soweit einwandfrei funktioniert.

    Gibt es eigentlich einen speziellen Grund, warum die Tabellen in der vadmin Datenbank noch im MyISAM Format sind?

    Bzw. sprich was dagegen, diese nach InnoDB zu konvertieren?

    Und wer dabei den Error 1067 bekommt:

    Der Defaultwert für Date (0000-00-00) muss durch 1000-01-01 ersetzt werden.

    0000-00-00 wird bei neueren mySQL Versionen nicht mehr als Defaultwert akzeptiert (zumindest wenn der Strict-Mode für Transaktionen gesetzt ist).

    Ich habe immer wieder mal das Problem, das ich einzelne vhost Container mit benutzerdefinierten Einträgen ergänzen müsste, die ich aber so nicht ohne viel Aufwand einbinden kann, das die httpd_vhosts.pl die Änderungen immer wieder überschreibt.


    Ich würde mir daher eine Erweiterung der httpd_vhosts.pl in der Form wünschen, das man die benutzerdefinierten Einträge in einem Ordner ablegen könnte und diese von der httpd_vhosts.pl zusätzlich mit eingelesen werden.


    Beispiel:

    /opt/pdadmin/etc/vhosts_custom

    -> <domain-name>.ini


    Der Vorteil wäre, das man zum Beispiel benutzerdefinierte Proxy-Einträge oder Spezialeinstellungen für Module hier ergänzen könnte.


    In der Vergangenheit gab es schon mal aus der Community ein Plugin hierzu, das aber zum einen nicht weitergepflegt wurde und zum anderen das mehrfache Schreiben der httpd.conf (einmal durch die httpd_vhosts.pl, einmal durch das Modul-Addon) bedingte, was nicht unbedingt optimal für die Funktionsweise des Apache Webservers ist.

    Ich kann das Problem auf meinen Systeme (Systeme mit Serie 4 und Serie 8) nicht nachvollziehen.

    Du bist dir schon im Klaren, das sowohl CentOS 6 als auch Serie 3 End of Life ist?

    Ich würde dir empfehlen, mindestens auf CentOS 7 sowie Serie 4 zu wechseln.

    Besser wäre, generell mal auf aktuelle Versionen zu gehen.


    Davon ab solltest du vielleicht mal checken, ob die Verlinkung von Perl auf das Perl vom der pd-admin Umgebung zeigt.
    Nicht das da Libraries nicht gefunden werden, weil nicht die pd-admin se perl Bibliotheken nicht angezogen werden.

    Was mir auch noch aufgefallen ist (das habe ich aber schon seit der 4.81:

    [Sun Jul 4 20:52:41 2021] administrator.cgi: get <http://www.pd-admin.de/download/VERSION> failed: _rc = <501> _msg = <Protocol scheme 'https' is not supported (Crypt::SSLeay not installed)> at /opt/pdadmin/www/administrator/administrator.cgi line 590.

    [Sun Jul 4 20:52:41 2021] administrator.cgi: get <http://www.pd-admin.de/download/SE-LATEST> failed: _rc = <501> _msg = <Protocol scheme 'https' is not supported (Crypt::SSLeay not installed)> at /opt/pdadmin/www/administrator/administrator.cgi line 590.


    In der WebGUI zeigt er auch folglich die neuen Versionen nicht mehr an ....

    Wenn ich versuche auf pd-admin 4.82 zu updaten, erhalte ich folgende Fehlermeldung:

    DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'function varchar(32) NOT NULL default '',

    auid int(11) NOT NULL auto_increment' at line 4 at ./mysql-update.pl line 47.

    Kann Tabelle audit nicht erstellen.

    Kann MySQL-Datenbank nicht anpassen.


    Kann natürlich daran liegen, das ich aktuell MySQL 8 einsetze; sollte aber eigentlich grundsätzlich nicht passieren ....


    Update:

    Scheint daran zu liegen, das das Keyword "function" ein reserviertes Wort ist.


    Der generierte Befehl für die Erstellung der Tabelle lautet:

    CREATE TABLE audit (

    args text NOT NULL default '',

    user int(11),

    auid int(11) NOT NULL auto_increment,

    status varchar(12),

    function varchar(32) NOT NULL default '',

    ts timestamp,

    type enum('user','reseller','pop3'),

    PRIMARY KEY (auid)

    );


    Packe ich das Keyword function in `` (also `function`) und nehme ihm beim args text NOT NULL noch das "default ''" weg, dann kann er die Tabelle zwar anlegen. Aber das hilft dann auch nicht wirklich -> pd-admin 4.82 läuft installationstechnisch durch, protokolliert aber nichts in die audit Tabelle.

    Soll das bedeuten, das Du noch eine SE der Reihe 1-3 installiert hast?


    Falls schon Reihe 4 installiert ist, reicht es doch, die pd-admin 64bit Version drüberzuinstallieren und gut ist.

    Und falls es wirklich nicht funktionieren würde, kann man die 32bit Version einfach wieder drüberinstallieren.

    UPDATE:
    Ich habe es zum Laufen bekommen.

    Vorgehensweise:


    Runterladen des Source-Codes

    Code
    git clone https://github.com/Imagick/imagick.git


    Anpassen der Datei /usr/local/pd-admin2/bin/MagickWand-config (dort den Pfad auf die pkg-config überall austauschen, der verweist aktuell auf einen nicht existierenden Pfad).


    Durchführen der Konfiguration und Compilierung:

    Code
    /usr/local/pd-admin2/php-8.0.3/bin/phpize
    PKG_CONFIG_PATH=/usr/local/pd-admin2/lib/pkgconfig/
    export PKG_CONFIG_PATH
     ./configure CFLAGS="-I/usr/local/pd-admin2/include/ -I/usr/local/pd-admin2/include/ImageMagick-6/ -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16" --with-php-config=/usr/local/pd-admin2/php-8.0.3/bin/php-config --bindir=/usr/local/pd-admin2/bin --includedir=/usr/local/pd-admin2/include --libdir=/usr/local/pd-admin2/lib:/usr/local/pd-admin2/syslib4:/usr/local/pd-admin2/syslib3:/usr/local/pd-admin2/syslib:/usr/local/pd-admin2/lib
    make clean
    make

    Das Compilat liegt dann unterhalb des Ordners imagick im Ordner modules.


    Test der Abhängigkeiten / Installation der Library

    Abschließend noch die php.ini anpassen, um die Extension imagick.so zu aktivieren sowie den FPM-Service neu durchstarten.


    Und danach sollte es laufen.