Beiträge von browsingman

  • MySQL Datenbankverzeichnis ändern

    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.

  • Upgrade von Reihe 6

    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.

  • MyISAM vs. InnoDB

    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?

  • Trafficauswertung

    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).

  • Virtualhost Container -> benutzerdefinierte Einträge ablegen und automatisiert mit in die httpd.conf aufnehmen können

    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.

  • Undefined subroutine at /opt/pdadmin/www/customer/customer.cgi

    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.

  • Update 64bit pd-admin 4.81 auf pd-admin 4.82 schlägt fehl

    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 ....

  • Update 64bit pd-admin 4.81 auf pd-admin 4.82 schlägt fehl

    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.

  • CentOS 8 certbot-auto

    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.

  • Imagick unter PHP 8 fehlt noch - wie läßt es sich nachinstallieren?

    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.

  • Imagick unter PHP 8 fehlt noch - wie läßt es sich nachinstallieren?

    Bei den aktuellen Server-Umgebungen ist im PHP 8 noch kein imagick.so Modul enthalten.


    Über pecl läßt es sich nicht installieren, da dort die Änderungen aus dem aktuellen git noch nicht eingepflegt sind.

    Ich habe daher die Sourcen runtergeladen, kann sie aber nicht so final kompilieren, das sie mit dem php 8 funktioniert.


    Die aktuell in git eingepflegte imagick Version soll aber mit php 8 lauffähig sein.


    Bisherige Vorgehensweise:

    Code
    git clone https://github.com/Imagick/imagick.git
/usr/local/pd-admin2/php-8.0.3/bin/phpize
 ./configure CFLAGS="-I/usr/local/pd-admin2/include/ -I/usr/local/pd-admin2/include/ImageMagick/" --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


    Das Konfigurieren schlägt fehl, da er den Verweis auf die MagickWand Header nicht findet. Wenn ich aus dem include Verzeichnis der pdaminse die Dateien übernehme, kann ich zwar die Konfiguration machen und auch das Erstellen des .so Files durchführen, aber am Ende funktioniert es nicht, weil in dem Kompilat libpath Verweise auf das Stammsystem sind und nicht auf die pdadminse Umgebung referenziert wird. Ein make test schlägt auch entsprechend fehl.


    UPDATE:

    Mit dem geänderten configure Aufruf, der dei Include Files dem make mitgibt, läßt sich das Modul kompilieren.

    Wenn ich allerdings das Modul im php 8 einbinde, kann ich den FPM Service nicht mehr starten, der Start schlägt fehl.


    Hat jemand eine Idee, wie man dennoch zu einem funktionsfähigen Kompilat gelangt bzw. woran es liegt, das sich der FPM Service mit eingebundenen Modul nicht mehr starten läßt?

  • Mailserver Verbindung wird bei manchen Gegenstellen (z.B. hosteurope) sofort abgebrochen

    Wenn die Verbindung fehlschlägt, kommen im wesentlichen 3 Gründe in Betracht:
    1. Verbindung abgelehnt, weil geblacklistet (aus welchen Gründen auch immer)
    2. Verbindung abgelehnt, weil eine Verschlüsselung gefordert ist
    (viele Server setzen mittlerweile TLS 1.2 als Mindestlevel voraus)
    3. Verbindung abgelehnt, weil ein Kommunikationsfehler auftritt (Socket-Fehler, MTU-Size, fehlerhafte Namensauflösung, Netzbereich per Firewall blockiert)

    -> Blockierte Netwerkbereiche


    Das muss dann halt alles geprüft werden.

  • pd-admin Server hinter einem DS-LIte Internetzugang betreiben

    Abseits dessen, das diese Konfiguration sehr ungewöhnlich ist und sicherlich auch geeignet ist, den eigenen lokalen Internet-Anschluß gut auszulasten, versuche ich mal zu verstehen, was jetzt die eigentliche Frage ist:
    a) Wie kann ich die Mails mit einer anderen IP-Adresse versehen?

    b) Fehlen noch iptables-Einträge (generell)?


    Falls die Frage sich auf Punkt a) bezieht, so ist meine Einschätzung, das die für den Versand verwendete eMail Adresse ja nicht auf der IP-Konfigurationsebene festgelegt wird, sondern in dem betreffenden Service (in diesem Falle wohl qmail(-smtpd).


    Somit sollte es eigentlich ausreichend sein, in qmail die IP-Konfiguration zu hinterlegen, welche verwendet werden soll.

    Das müsste dann folgende Datei sein, sofern der entsprechende qmail-patch eingebunden wurde:

    /var/qmail/control/outgoingip


    Normalerweise existiert diese Datei nicht, so das die jeweilige IP des Hosts verwendet wird, auf welchem der Dienst läuft.

    Ich bin mir allerdings auch nicht mehr ganz sicher, welche qmail-Patches seitens pd-admin berücksichtigt worden sind.


    Grundsätzlich ist es aber eine Konfiguration, welche nicht auf Firewall-Ebene mit iptables anzupassen wäre, sondern in der jeweiligen Konfiguration des Mail-Services, welcher für den Versand verwendet wird.

  • Coreruleset und mod_security -> kein JSON Support!

    Mit 0.375 wurde als Neuerung coreruleset mit aufgeführt.

    Gleichwohl ist in den Templates dazu keine Konfiguration in der pdadmin SE-Umgebung zu finden.

    Ich vermute mal, das hier noch weitere Anpassungen / Konfiguration von Herrn Bradler für Folge-Releases geplant sind.


    Aus meiner Sicht müsste hier auch eine .conf Datei für mod_security beigefügt werden.


    Ich habe testhalber mal eine Datei modsecurity.conf erstellt:

    Ergänzend habe ich dann noch folgende Zeilen in der httpd24.conf-template eingefügt:

    Code
    include /usr/local/pd-admin2/httpd-2.4/conf/modsecurity.conf
include /usr/local/pd-admin2/httpd-2.4/conf/coreruleset-3.3.0/crs-setup.conf
include /usr/local/pd-admin2/httpd-2.4/conf/coreruleset-3.3.0/rules/*.conf


    Im Ordner coreruleset-3.3.0 sowie im Ordner coreuleset-3.3.0/rules habe ich die *.example in *.conf umbenannt und in der Konfigurationsdatei crs-setup.conf noch folgende Regel aktiviert, damit die gängigen Produkte wie nextcloud und wordpress nicht pauschal geblockt werden.


    Code
    SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_drupal=1,\
  setvar:tx.crs_exclusions_dokuwiki=1,\
  setvar:tx.crs_exclusions_nextcloud=1,\
  setvar:tx.crs_exclusions_wordpress=1


    Grundsätzlich würde das nach einem Neustart des Apache Webservers so gut funktionieren, ABER es muss noch eine weitere Voraussetzung erfüllt sein:

    Das mod_security Modul müsste mit JSON Support kompiliert werden. Aktuell ist es das nicht.


    Es wäre schön, wenn man diesen "Bug" noch mit dem nächsten SE-Update lösen würde ;)