Beiträge von monderka

    Nach dem Update sehen auf beiden geupdateten Server die Ergebnisse des nächtlichen letsencrypt-Jobs so aus:


    /opt/pdadmin/bin/letsencrypt --all

    PLEASE SEE THE PERL2EXE USER MANUAL UNDER "Can't locate somemodule.pm in @INC"
    FOR AN EXPLANATION OF THE FOLLOWING MESSAGE:
    Can't locate Tie/Hash/NamedCapture.pm in @INC (@INC contains: /opt/pdadmin/lib PERL2EXE_STORAGE /opt/pdadmin/bin) at PERL2EXE_STORAGE/English.pm line 148.
    BEGIN failed--compilation aborted at PERL2EXE_STORAGE/English.pm line 148.
    Compilation failed in require at PERL2EXE_STORAGE/ConsolidatedAdminAndCustomerCode.pm line 14.
    BEGIN failed--compilation aborted at PERL2EXE_STORAGE/ConsolidatedAdminAndCustomerCode.pm line 14.
    Compilation failed in require at /opt/pdadmin/bin/letsencrypt line 14.
    BEGIN failed--compilation aborted at /opt/pdadmin/bin/letsencrypt line 14.

    Auf dem centos8 kam folgende komische Meldung beim PD-Admin Update.

    SE vorher von 6-389 auf 6-391 war problemlos


    Aendere Feld vhosts.id

    Aendere Feld whitelist.id

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    Writing /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected

    AP24: creating run-v2, symlinking to run

    /usr/local/pd-admin2/httpd-2.4/bin/apachectl: line 79: 1432643 Killed $HTTPD -k $ARGV


    Update erfolgreich.


    Alle Dienste scheinen aber regulär gestartet zu sein.


    Nachtrag:
    im Verzeichnis /usr/local/pd-admin2/httpd-2.4/bin ist auf der maschine cur die apachectl drin, während auf anderen jede menge andere Dateien sind von ab bis suexec

    Hatte nach dem Update auch keine Probleme den Apache zu erreichen. War aber das erste mal das bei einem PD-Admin Update das passiert ist. Ich hatte direkt vorher das letzte SE-Update gemacht und da gab es kein Problem. Sei es drum, scheint ja zu laufen.

    Zitat

    PID TTY STAT TIME COMMAND

    9062 ? Sl 0:00 /usr/local/pd-admin2/httpd-2.4/bin/httpd -D NO_DETACH -DSSL

    Das ist Debian11 beim Update von PDadmin 4.85_64 auf 4.86_64


    ....

    Aendere Feld vhosts.id

    Aendere Feld vhosts.php_sapi

    Aendere Feld whitelist.id

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    ln: die symbolische Verknüpfung '/lib64/libssl.so.10' konnte nicht angelegt werden: Die Datei existiert bereits

    ln: die symbolische Verknüpfung '/lib64/libcrypto.so.10' konnte nicht angelegt werden: Die Datei existiert bereits

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    Writing /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected

    AP24: creating run-v2, symlinking to run

    (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80

    (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80

    no listening sockets available, shutting down

    AH00015: Unable to open logs

    httpd not running, trying to start


    Update erfolgreich.

    Ich habe nun versucht eine Datei mit folgendem Inhalt zu einem virtualhost-eintrag zu ergänzen, aber der unten stehen fehler meint das es zwei virtualhost-einträge gibt.



    /opt/pdadmin/bin/httpd_vhosts.pl

    Writing /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected

    AH00526: Syntax error on line 476 of /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf:

    <VirtualHost> cannot occur within <VirtualHost> section


    An welcher Stelle findet die Zuordnung zu einem bestimmten virtualhost-eintrag aus dem pdadmin statt?

    Hallo Michael,


    das habe ich auch auf einer Maschine die noch unter Debian5 läuft und bis zur Migration aller Kunden noch am Netz bleiben muss. Ich löse das derzeit so das ich auf einem anderen Linuxsystem, kein PD-Admin Server, folgende Schritte mache:


    1) wget --debug -O /opt/pdadmin/license.conf.neu "http://www.pd-admin.de/license/?action=get_licence&name=pd-admin-4&IP_ADDR=xxx.xxx.xxx.xxx"


    2) grep -q "LICENSE PRODUCT: pd-admin" /opt/pdadmin/license.conf.neu && mv /opt/pdadmin/license.conf.neu /opt/pdadmin/license.conf


    3) license.conf auf den PD-Admin Server kopiere


    Das hält dann immer einen Monat.


    Ich werde die Maschine zum Jahresende fertig migriert haben, aber solange muss dieser Workaround herhalten.

    Wir haben vor einiger Zeit eine Maschine mit Debian9 von SE4 auf SE6 gehoben. Ich stelle euch nächste Woche mal die Schritte dazu hier rein, das ging problemlos. Anschließend haben wir dann das ganze auf Debian10 gehoben.

    ja, genau das ist das Problem, vermutlich muss ich die www nutzen und ich würde natürlich auch die SSL-Zertifikate aus der der Infrastruktur der Pdadmin-Umgebung aktuell halten wollen... Vielleicht gibt es ja noch weitere Ideen. Habe da noch keinen Zeitdruck aber beschäftige mich mal schon damit um dann eine idee zu haben wenn es "ernst" wird.

    habe auch noch keine Idee wie ich da einen workaround rum baue wenn ich das im PD-Admin nicht irgendwie einstellen kann. Das mit der automatisch generierten virtualhosts ist das problem. vielleicht definiere ich es einfach im "statischen" bereich des template mit. muss ich mal austesten.

    Es soll für ein Drittmodul in eine Seite folgendes integriert werden:


    Kunde Wanderwege

    https://www.kundendomain.de/unsere_wanderwege

    Hierfür muss ein Reverse Proxy angelegt werden.

    Bei der Einrichtung ist besonders darauf zu achten, dass unter der URL https://www.kundendomain.de/_global keine Ressourcen der Webseite liegen dürfen, da dieser Pfad für das Tourenmodul notwendig ist bzw. dieser im Proxy auf https://module.tourlieferant.com/_global gemappt werden muss.

    Für den Webserver Apache hänge ich Ihnen ein entsprechendes Beispiel mit an, das mit der Kunde gegeben hat um es einzurichten.

    Code
    <VirtualHost *:443>
       ServerName www.kundendomain.de
       ServerAlias kundendomain.de
       ...
    Code
       <IfModule mod_proxy_http.c> SSLProxyEngine on
         RewriteEngine on
         RewriteRule "^/unsere_wanderwege(.*)$" "https://module.tourlieferant.com/unsere_wanderwege$1" [P]
         ProxyPassReverse "/unsere_wanderwege" "https://module.tourlieferant.com/unsere_wanderwege"
         RewriteRule "^/_global(.*)$" "https://module.tourlieferant.com/_global$1" [P]
         ProxyPassReverse "/_global" "https://module.tourlieferant.com/_global"
        </IfModule>
    </VirtualHost>

    Hallo,

    habt ihr schonmal im PD-Admin einen reverse proxy eingerichtet?

    Ich habe im Forum nichts dazu gefunden. Geht das überhaupt oder muss ich die apache config direkt editieren?


    viele Grüße

    Manfred

    Da bin ich ganz bei dir. Ich werde es jetzt so machen das ich die shell aufmache um das zu installieren und dann wieder schließe. Da müssen die halt bei mir anklopfen wenn sie wieder rein wollen. Denn eigentlich will ich ja gar niemanden auf die Shell lassen.

    Erstmal vielen vielen Dank für den positiven Input. Das Forum hier ist immer wieder super. Eines der besten die ich je genutzt habe.


    Konkret in diesem Fall ist es ein centos8.

    Wenn ich per putty mich mit dem systemnutzeraccount des kunden anmelde kann ich mit cd .. bis auf die Systemroot zurück. Zwar fehlen die Rechte dort was zu ändern, aber man kann rumschnüffeln. Aber evtl. fehlt wirklich eine einstellung in der sshd.conf um dies für User zu begrenzen.


    Mit dem Userabhängigen Composer finde ich auch besser ich will saubere Systeme haben und auf seinem Hostingaccount kann jeder tun und lassen was er will.

    das mit dem usr/home ist wohl irgend eine andere linux distribution.

    aber das von dir schaut besser aus und einleuchtender.


    Das im Homeverzeichnis führst du als benutzer des accounts aus oder als root?

    Eigentlich wollte ich meinen usern keinen bash zugang geben, aber das muss ich wohl dann.

    Mein Problem ist das man mit der bash bis auf die System-root gehen kann und am system ggf. rumfummeln kann. oder ich muss die sshd anders konfigurieren das man aus dem home-verzeichnis nicht ausbrechen kann.

    Hallo,


    seit einiger Zeit beobachte ich - trotz fail2ban regeln solche Massenspams die ich irgendwie nicht abwehren kann.

    Ich behelfe mir das ich mit iptables das gesamte C-Netz sperre wenn ich das mitbekomme, aber das ist natürlich nicht sehr effizient.


    Aug 5 16:26:58 server14 greylisting[20682]: sender nokitesr@sbirkaprikladu.eu, address 193.179.204.67 seen for the first time: rejected

    Aug 5 16:36:46 server14 greylisting[27907]: sender nokitesr@sbirkaprikladu.eu, address 193.179.204.67 passed thru

    Aug 5 18:20:31 server14 greylisting[24128]: sender primmat.smtp@client.virtualzone.eu, address 193.179.204.67 seen for the first time: rejected

    Aug 5 18:26:46 server14 greylisting[26031]: sender primmat.smtp@client.virtualzone.eu, address 193.179.204.67 passed thru

    Aug 5 18:26:53 server14 qmail: 1628180813.372118 delivery 2425: failure: 193.179.204.46_does_not_like_recipient./Remote_host_said:_552_5.2.2_<primmat.smtp@client.virtualzone.eu>:_Recipient_address_rejected:_Mailbox_is_full/Giving_up_on_193.179.204.46./



    oder:

    Aug 5 14:32:31 server14 greylisting[18189]: sender shimanaleonod@quietlivity.com, address 23.88.38.153 seen for the first time: rejected

    Aug 5 14:32:32 server14 greylisting[18198]: sender shimanalqenod@quietlivity.com, address 23.88.38.153 seen for the first time: rejected

    Aug 5 14:35:42 server14 greylisting[20062]: sender shimeaytiueod@quietlivity.com, address 23.88.38.153 seen for the first time: rejected

    Aug 5 14:36:25 server14 greylisting[20196]: sender shimantiueod@quicksignsinc.net, address 23.88.38.153 passed thru

    Aug 5 14:36:43 server14 greylisting[20305]: sender shimanftiueod@quietlivity.com, address 23.88.38.153 seen for the first time: rejected

    Aug 5 14:39:23 server14 greylisting[21344]: sender shimanttiueod@reliabilityweb.com, address 23.88.38.153 passed thru

    Aug 5 14:39:25 server14 greylisting[21406]: sender shimanttiueod@reliabilityweb.com, address 23.88.38.153 passed thru

    Aug 5 14:40:12 server14 greylisting[21723]: sender shimanahlenod@quietlivity.com, address 23.88.38.153 passed thru

    Aug 5 14:40:16 server14 greylisting[21744]: sender shimantiueuod@quicksignsinc.net, address 23.88.38.153 passed thru

    Aug 5 14:43:40 server14 greylisting[23010]: sender shimanaleenod@quietlivity.com, address 23.88.38.153 passed thru

    Aug 5 14:44:01 server14 greylisting[23258]: sender shimanaletnod@reliabilityweb.com, address 23.88.38.153 passed thru

    Aug 5 14:47:35 server14 greylisting[25503]: sender shimzeytiueod@quicksignsinc.net, address 23.88.38.153 passed thru

    Aug 5 14:48:34 server14 greylisting[26741]: sender shimanalegnod@quicksignsinc.net, address 23.88.38.153 passed thru

    Aug 5 14:48:40 server14 greylisting[26787]: sender shimanaclenod@quietlivity.com, address 23.88.38.153 trusted host

    Aug 5 14:51:24 server14 greylisting[28108]: sender shimanaklenod@quirkytravelguy.com, address 23.88.38.153 trusted host

    Aug 5 14:51:55 server14 greylisting[28391]: sender shimanaluenod@reliabilityweb.com, address 23.88.38.153 passed thru

    Aug 5 14:54:06 server14 greylisting[29125]: sender shimanalemnod@rittmananalytics.com, address 23.88.38.153 passed thru

    Aug 5 14:55:46 server14 greylisting[29644]: sender shimanalehnod@quietlivity.com, address 23.88.38.153 passed thru

    Aug 5 14:55:47 server14 greylisting[29687]: sender shimanalepnod@quietlivity.com, address 23.88.38.153 passed thru

    Aug 5 15:01:16 server14 greylisting[1652]: sender shimdeytiueod@quirkytravelguy.com, address 23.88.38.153 trusted host

    Aug 5 15:02:33 server14 greylisting[2262]: sender shimanalernod@reliabilityweb.com, address 23.88.38.153 trusted host

    Aug 5 15:04:01 server14 greylisting[2395]: sender shimanaklenod@quietlivity.com, address 23.88.38.153 trusted host

    Aug 5 15:06:32 server14 greylisting[2878]: sender shimanalegnod@quietlivity.com, address 23.88.38.153 trusted host


    Habt ihr da bessere Lösung solche Einlieferung im Keim zu ersticken?

    Manfred