Beiträge von Sumeragi

    Nodejs kann ja jeder Nutzer lokal installieren. Einfach die binaries herunter laden, entpacken und die Binaries nach ~/bin/ verlinken.

    Man kann seit PDA 4.66 Dienste für Nutzer einrichten/starten. Dort kann man dann "~/bin/npm skript.js" eintragen und es sollte laufen. Der Dienst sollte dann auf einen eigenen Port laufen. Dann kann man beim Endkunden unter Subdomains ein Proxy auf den Dienst einrichten.

    fpm:

    Code
    [Sat Aug 01 17:14:38.270719 2020] [proxy:error] [pid 15774] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /service/FPM-solotcbc-7.4.2/socket (*) failed
    [Sat Aug 01 17:14:38.270933 2020] [proxy_fcgi:error] [pid 15774] [client 217.61.194.123:60214] AH01079: failed to make connection to backend: httpd-UDS

    Der Apache bekommt keine Verbindung zum PHP socket. Die Frage ist, wieso.


    Zur Not einmal den fpm Prozess stoppen:

    Bash
    svc -d /service/FPM-solotcbc-7.4.2/

    und

    Bash
    /service/FPM-solotcbc-7.4.2/run

    auf der Konsole ausführen und schauen ob es Fehler gibt.

    Twilo


    kurz: offenbar, ja


    Beim anfordern eines neuen Passwortes wird ein Eintrag in die Tabelle new_passwd vorgenommen. In die Spalte ip wird die Client IP eingetragen.

    Bei Verwendung des Proxy vhosts wird bei mir dann die IPv4 Adresse des Servers anstelle der IP meines Anschlusses eingetragen.

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