Beiträge von Sumeragi

    Alternative wäre evtl. $standard_ipv6 in der pdadmin.conf hinzuzufügen.


    Beim Standard VirtualHost folgendes eintragen:

    Code
    <VirtualHost $$STANDARD_IP:80 $$STANDARD_IPV6:80>

    Den generierten :443 Eintrag kopieren und stattdessen $$STANDARD_IPV6:443 verwenden.

    Das hatte ich zuvor gemacht. Also den vhost für Port 80 kopiert, IPv6 Adresse und Port 443 eingetragen. Nur dann hat man halt dass Problem mit der Lizenz.

    Bis eine IPv6 Unterstützung für die Verwaltungsoberfläche implementiert ist halte ich die Proxy Lösung für am geeignetsten.

    Ich greife dies hier noch einmal auf...


    In meiner /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template habe ich folgendes eingetragen:

    Damit konnte ich über eine IPv6 Adresse pd-admin aufrufen und es wurde die Lizenz korrekt angezeigt. Probleme traten bisher nicht auf und mir ist auch nichts derartiges aufgefallen.

    Diff: crontab_to_backup.diff
    +nice -n 19 setuidgid $USER tar --preserve-permissions $PARM_EXCLUDE -czf $BACKUPDIR/user/$USER/$ROTATION/backup.tar.gz $HOME crontab.dump

    :/ anstatt crontab.dump müsste doch der "vollständige" Pfad zur Datei angegeben werden. Sprich $BACKUPDIR/user/$USER/$ROTATION/crontab.dump. Schließlich findet kein cd statt. So dürfte die Datei nicht gefunden werden. Die Zeile müsste also lauten:

    Bash
    nice -n 19 setuidgid $USER tar --preserve-permissions $PARM_EXCLUDE -C / -czf $BACKUPDIR/user/$USER/$ROTATION/backup.tar.gz $HOME $BACKUPDIR/user/$USER/$ROTATION/crontab.dump

    Und ich bin auf ein "Fehler" gestoßen. Wenn ein Nutzer keine Cronjobs hat führt der crontab Befehl zu no crontab for someUser. Ich habe daher

    Bash
    nice -n 19 crontab -l -u $USER > $BACKUPDIR/user/$USER/$ROTATION/crontab.dump

    angepasst

    Bash
    test -f /var/spool/cron/$USER && cat /var/spool/cron/$USER > $BACKUPDIR/user/$USER/$ROTATION/crontab.dump

    Anstatt cat kann natürlich auch weiter crontab -u $USER -l verwendet werden.

    Ich weiß nicht wie gambio Mails über PHP versendet, aber ich würde es über eine Mailbox versenden. Wenn eine Mail eingeliefert wirde, kümmert sich der Mail Server um die Zustellung. Mir ist es bei PHP schon Mal passiert, dass Mails "verschwanden". Das wäre für ein Shop sehr ungünstig. Auch stufen einige Anbieter Mails mit "X-PHP-..."-Header schlechter, und somit unter Umständen als Spam, ein.


    Klappt denn die unverschlüsselte Einlieferung über Port 25? Was ist mit der Einlieferung über Port 465? Ist denn etwas im debug Log zu sehen?

    Folgendes ist mir aufgefallen:

    Bei mir sieht es so aus:

    database.clamav.net löst bei Ihnen auch auf 130.255.76.239 auf. Bei mir ist es eine CloudFlare IPv6. Ich denke irgendwo da liegt das Problem.

    Ich habe bei Ausführung von freshclam ebenfalls keine Probleme.


    Was passiert denn Sie eines der Files manuell herunter laden?

    Bash
    curl -vvv https://database.clamav.net/daily-25824.cdiff --output delete.me && rm delete.me

    In der .bash_profile hingegen schon


    Bei keiner der Dateien ändert sich der Timestamp, wenn man Änderungen an den PHP-CLI-Einstellungen vornimmt. Was sich ändert, ist die Datei bin/php - aktuell sieht sie so aus:

    Die PATH Variable ist in der .bash_profile richtig angepasst. Es macht ja schließlich Sinn, dass beim Setzen der PHP-CLI $HOME/bin als erstes in PATH gesetzt wird. Vielleicht geschieht die Anpassung nur beim ersten Mal setzen? :/

    Bei mir auf einen neuen Testserver (Debian 10) gibt es beim Kunden nur die Datei .profile

    IIRC ist .profile das Debian Pendant zur CentOS .bash_profile

    MIT aktivierter Option "Lokale php.ini verwenden.":

    Bash
    #!/bin/bash
    export PHP_BINARY=/usr/local/pd-admin2/bin/php-7.4-cli
    exec /usr/local/pd-admin2/bin/php-7.4-cli -c /home/USER/php.ini "$@"

    OHNE aktivierter Option "Lokale php.ini verwenden.":

    Bash
    #!/bin/bash
    export PHP_BINARY=/usr/local/pd-admin2/bin/php-7.4-cli
    exec /usr/local/pd-admin2/bin/php-7.4-cli "$@"

    Funktioniert wie es soll...


    Um auf das Problem zurück zu kommen:

    In der .bashrc findet sich keine PATH Variable:

    Code
    # .bashrc
    # User specific aliases and functions
    # Source global definitions
    if [ -f /etc/bashrc ]; then
    . /etc/bashrc
    fi

    Richtig, es fehlt die PATH Variable mit Angabe von $HOME/bin. Wenn ein PHP Prozess (Non-Login Shell) startet wird ~/.bashrc von der Bash abgearbeitet. Nicht aber ~/.bash_profile. Die .bash_profile kommt nur bei Login Shells zum Einsatz => also z.B. bei SSH. Daher findet der PHP Prozess nicht die gesetzte PHP-CLI.


    Ich habe dies vor langer Zeit dadurch gelöst, dass ich

    Bash
    $ grep '$HOME' /etc/skel/.bashrc
    PATH=$HOME/bin:/usr/local/pd-admin2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

    gesetzt habe. Damit wird bei neuen Nutzern automatisch $HOME/bin verwendet.


    Auf dem Screenshot sieht man ja auch, dass /usr/local/pd-admin2/php-7.2.31/bin/php-cli angegeben ist. Jedoch ohne "-c /home/USER/php.ini". Daher wird hier die Standard php.ini geladen, welche allow_url_fopen deaktiviert hat. Da es dort ein Ändern Button gibt, schätze ich kann dies angepasst werden und würde vorschlagen dort mal "/home/USER/bin/php" für die PHP-CLI anzugeben. Natürlich mit aktivierter lokaler php.ini ;) Alternativ könnte man auch versuchen "/usr/local/pd-admin2/php-7.2.31/bin/php-cli -c /home/USER/php.ini" anzugeben.

    Wie sieht denn die PATH Variable in der .bashrc aus? Ich meine bei Aktivierung der lokalen php.ini wird die PATH Variable in der .bash_profile angepasst. Die Datei wird aber nur bei Login Shell ausgewertet. Die .bashrc bei jedem neuen Prozess.

    => Bei einem neuen PHP Prozess wird somit nur die .bashrc ausgewertet, nicht aber die .bash_profile. Dadurch wird dann die Default php.ini geladen.

    Wenn es bei Dir nicht funktioniert, machst Du irgendetwas falsch ;-)

    Der Fehler war, dass in der Datei nicht der Inhalt der Passwort Variable, sondern die Variable steckte :whistling:


    Ich habe irgendwann einmal gemäß MySQL Doc (Table 4.2) eine .my.cnf bei dem Nutzer root angelegt:

    Bash
    [client]
    socket=/usr/local/pd-admin2/var/mysql.run/mysql.sock
    user=root
    password=password123

    Eine solche Datei könnte man für die entsprechenden Nutzer anlegen. Dann hat man zwar das Passwort wieder in mehreren Dateien, aber dies wäre zumindest standardisiert.

    evtl. für das vadmin Passwort eine neue Gruppe mit allen Benutzern (popuser, qmaild, root) hinzufügen, welche die Datei mysql_pw_vadmin.cnf lesen können muss; somit muss das vadmin Passwort dann nicht mehr in 6 verschiedenen Dateien* stehen …

    • /bin/checksmtppasswd
    • /home/popuser/mysql_passwd.conf
    • /opt/pdadmin/etc/pdadmin.conf
    • /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/dovecot-sql.conf.ext
    • /usr/local/pd-admin2/etc/authlib/authmysqlrc
    • /usr/local/pd-admin2/etc/proftpd.conf
    • /var/qmail/vadmin-check.pl

    genauso nur EINE perl Datei mit den Zugangsdaten und nicht 4 an unterschiedlichen Stellen

    Bei den Dateien unter /usr/local/pd-admin2 handelt es sich um Konfigurationsdateien einzelner Dienste. Da ist gar nicht klar, ob diese mit der o.g. Lösung arbeiten können. Vermutlich müssen die Daten dort eingetragen bleiben...

    Ich denke dafür wäre die beste Lösung zunächst die Dateien mit MySQL Zugangsdaten zu dokumentieren. Dann kann man ein Skript basteln welches das Passwort aktualisieren kann und/oder die betreffenden Dateien ausgibt.


    Löst natürlich nicht das Problem mit den Warnungen X/ Ich denke da muss man sich jeweils das Skript anschauen...

    Ich sehe kein Unterschied zwischen der Speicherung in $PASSWORD oder $MYSQL_PWD. Dies wären beides Variabeln, welche ausgelesen werden könnten. Auf meinem VPS ist /proc mit "hidepid=2" gemountet, so dass Nutzer nur Ihre eigenen Prozesse sehen können. Aber auch ohne dies konnte ich mit ps bzw. unter z.B. /proc/$PID/environ das Passwort nicht auslesen.


    Letztlich ist die Information unter dem Hinweistext für mich viel wichtiger:

    MYSQL_PWD is deprecated as of MySQL 8.0 and will be removed in a future MySQL version.

    Somit ist die Variante mit MYSQL_PWD nicht zukunftssicher und es müsste daher eine andere Lösung gefunden werden.


    Die vorgeschlagene Lösung scheint aber nicht getestet worden zu sein?

    password = $(cat /opt/pdadmin/etc/mysql_rootpw.conf)

    password = $(grep password /opt/pdadmin/etc/pdadmin.conf |cut -d'"' -f2)

    Die .cnf Dateien sind ja keine Bash Skripte, sondern werden vom MySQL Client interpretiert. Da funktionieren u.a. cat und grep nicht. Ich habe meine .my.cnf entsprechend angepasst und erhalte

    Bash
    $ /usr/local/pd-admin2/bin/mysql --defaults-file=~/.my.cnf vadmin -e 'SELECT id FROM accounts;'
    ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

    pd-admin: 4.63

    SE: 0.356

    Welche Reihe wird denn hier aktualisiert?

    Bash
    $ grep mime /usr/local/pd-admin2/htdocs/roundcubemail/config/config.inc.php
    $

    Bei mir steht in der Konfig nichts drin. Mir ist beim Aktualisieren auch nichts aufgefallen... Zudem ist mime_magic deprecated und durch fileinfo ersetzt worden. Fileinfo wiederum ist in PHP enthalten, Bsp:

    Bash
    $ /usr/local/pd-admin2/bin/php5-5.6-cli -i | grep fileinfo
    fileinfo
    fileinfo support => enabled
    $ /usr/local/pd-admin2/bin/php-7.4-cli -i | grep fileinfo
    fileinfo
    fileinfo support => enabled


    Was muss ich da "checken"?


    Was muss ich machen, damit dieser Hinweis verschwindet?

    Kommt es denn abgesehen von der Warnung zu Fehlern?

    Wenn die Datei notwendig ist, warum wird das bei der Installation nicht gemacht

    Bei mir ist die Datei ebenfalls da. Ich hätte ja vermutet, dass diese bei Updates benötigt wird...

    Aber auf einem neu installierten Server gibt es die Datei nicht und auf einem Server,

    wo schon einmal ein Update gelaufen ist, gibt es die Datei. Ist schon komisch.

    ... aber wenn diese nicht bei allen Nutzern auftauscht wird diese wohl nicht allgemein benötigt. Vielleicht nur in einem bestimmten Fall :/

    Code
    export DIEMSGL="421 TOO MANY CONNECTIONS"
    export FORCETLS=1
    export CHKUSER_START=ALWAYS

    ist bei Dir anders und beim exec unten gibt es noch ein -j; ich konnte noch nicht ermitteln, was das -j macht


    Wurden DIEMSGL und CHKUSER_START von Dir hinzugefügt?

    Ich kann mich nicht daran erinnern, dass ich da Änderungen vorgenommen habe... Will es aber auch nicht gänzlich ausschließen... Ansonsten


    qmail-smtpd läuft auf Port 25

    qmail-msa läuft auf Port 587

    qmail-smtpSd läuft auf Port 465


    Ich würde erst einmal mit netstat und lsof schauen, ob die Dienste laufen und auf den Ports lauschen. Anstatt des strace, was ja immer etwas schwierig zu lesen ist, würde ich einfach Mal

    Bash
    svc -d /service/qmail-smtpd
    /service/qmail-smtpd/run

    auf der Konsole ausführen, Zustellung auf einer zweiten Konsole testen und schauen was bei der Ersten angezeigt wird.