Beiträge von monderka

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

    Hallo Zusammen,


    irgendwie schaffe ich es nicht den composer für einen Hostingplatz zum laufen zu bekommen.

    Kann mir da jemand einen Tipp geben oder mir auf die sprünge helfen...

    Das war die Anleitung die ich für das Bin-Verzeichnis im PD-Admin-Customer und dem Home des Kunden angepasst habe, aber irgendwie läuft es nicht.


    php -d allow_url_fopen=On -r "readfile('https://getcomposer.org/installer');" > composer-setup.php
    2php -d allow_url_fopen=On composer-setup.php
    3php -r "unlink('composer-setup.php');"
    4echo alias composer=\"/usr/bin/php -d allow_url_fopen=On /usr/home/$USER/composer.phar\" >> ~/.bashrc
    5source ~/.bashrc
    schonmal danke falls mir jemand das rumfummeln abkürzen kann.

    Manfred

    Ich habe jetzt alle auf 128000000 gesetzt.
    Nachdem ich das hier auch gefunden habe was zwar anders ist aber auch ähnlich klingt.


    RE: Fehlermeldung im Zusammenhang mit smtpd


    Auf dem CentOS8 habe ich den qmail-smtpd neu gestartet und die 64bit Version nochmal drüber installiert.

    Schaut auf den ersten Blick aus als wäre das das die Lösung. Ich beobachte das bis morgen bevor ich das weiter ausrolle und hier ggf. vollzug melden kann.


    Danke an alle. Das Forum ist wirklich toll und funktioniert wirklich. DANKE DANKE

    Also, es muss an der 64bit PD-Admin 4.81 liegen.

    Wenn ich die 32-bit Variante bei Debian9 und CentOS8 (was vorher auch verwendet wurde) drüber installiere werden die PTR-Ablehnungen auch nur dann abgelehnt wenn es tatsächlich keinen PTR gibt.


    Hat jemand schonmal bei Debian9 und CENTos8 die 64-bit umgestellt?

    Das fällt mir aktuell auf diesen geupdateten Server im messages Logfile auf:


    09:26:07 server10 smtpd[2880563]: 1623137167.561107 Use of uninitialized value $Sys::Hostname::Long::hostlong in pattern match (m//) at PERL2EXE_STORAGE/Sys/Hostname/Long.pm line 166.


    /usr/bin/perl ist aber auf /usr/local/pdadmin/bin/perl gelinkt

    Auf beiden Servern die bei hetzner stehen sind die PTR Auflösungen korrekt, aber sobald ich im PD-Admin Mails ohne gültigen PTR auf ablehnen stelle werden ALLE eingehenden mails abgelehnt.

    Jetzt auf allen Maschinen aufgetreten mit Debian10, Debian9 und CentOS8 bei mir.


    dig -x 40.107.21.88


    ; <<>> DiG 9.10.3-P4-Debian <<>> -x 40.107.21.88

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33925

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 4096

    ;; QUESTION SECTION:

    ;88.21.107.40.in-addr.arpa. IN PTR


    ;; ANSWER SECTION:

    88.21.107.40.in-addr.arpa. 3331 IN PTR mail-vi1eur05on2088.outbound.protection.outlook.com.


    ;; Query time: 0 msec

    ;; SERVER: 213.133.99.99#53(213.133.99.99)

    ;; WHEN: Tue Jun 08 09:37:15 CEST 2021

    ;; MSG SIZE rcvd: 119

    hm. rätselhaft.

    Mindestens meiner hat ja einen PTR-Record:


    dig -x 87.191.185.204


    ; <<>> DiG 9.10.3-P4-Debian <<>> -x 87.191.185.204

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4816

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 512

    ;; QUESTION SECTION:

    ;204.185.191.87.in-addr.arpa. IN PTR


    ;; ANSWER SECTION:

    204.185.191.87.in-addr.arpa. 86114 IN PTR david.onit4u.de.


    ;; Query time: 21 msec

    ;; SERVER: 192.168.181.1#53(192.168.181.1)

    ;; WHEN: Tue Jun 08 09:23:31 CEST 2021

    ;; MSG SIZE rcvd: 85

    PD-Admin Version: v4.81 64bit

    Debian 9

    SE: 6-0.380


    Seit dem Update der PD-Admin-Version lehnt der Server ALLE eingehenden mails mit "missing PTR Record" ab wenn das eingeschaltet ist:v


    Jun 7 14:57:21 server15 greylisting[27812]: sender service@xxxxxxxx.de, address 52.100.174.xxx: missing PTR record.

    Jun 7 14:57:21 server15 greylisting[27818]: sender servizio@xxxxxxx.it, address 40.107.21.xxx: missing PTR record.

    Jun 7 14:57:21 server15 greylisting[27819]: sender service@xxxxxxxx.de, address xxx:111:xxx:xxx::30d: missing PTR record.

    Jun 7 14:57:22 server15 greylisting[27826]: sender servizio@xxxxxxxx.it, address 40.107.21.xxx: missing PTR record.

    Jun 7 14:57:22 server15 greylisting[27831]: sender servizio@xxxxxxxx.it, address xxx:111:xxx:xxx::62d: missing PTR record.


    Erst wenn ich die PTR-Prüfung abschalte kommen die Mails rein.


    Jun 8 08:51:58 server15 greylisting[2413]: sender manfred.onderka@onit-gmbh.de, address 87.191.185.204: missing PTR record.


    Nach Abschaltung der PTR-Prüfung und Ablehnung

    Jun 8 08:54:10 server15 greylisting[5476]: sender manfred.onderka@onit-gmbh.de, address 87.191.185.204 bypassed: SPF ok.

    Jun 8 08:54:12 server15 qmail: 1623135252.596577 info msg 69075050: bytes 8526 from <manfred.onderka@onit-gmbh.de> qp 5529 uid 1016

    Jun 8 08:54:13 server15 qmail: 1623135253.147768 info msg 69075034: bytes 8691 from <srs-SRS0=aEnKiTj+=LC=onit-gmbh.de=manfred.onderka@server15.xxxxxxx.de> qp 5561 uid 1029