Zwar nicht so schlimm wie bei RAD750, aber zumindest ist mal was zu sehen
Find das ganz lustig, ist eine neue Maschine
Zwar nicht so schlimm wie bei RAD750, aber zumindest ist mal was zu sehen
Find das ganz lustig, ist eine neue Maschine
Lauter 22ger Bans?
Ja fast alles SSH. Bisschen Postfix ist auch dabei, fällt aber nicht ins Gewicht.
...ist eine neue Maschine
Aber keine neue IP
Ja fast alles SSH. Bisschen Postfix ist auch dabei, fällt aber nicht ins Gewicht.
Standardport? Falls ja, magst du den j4f mal ändern und schauen wie es sich dann entwickelt?
Absolut sinnvoll wäre es, SSH auf einen anderen Port lauschen zu lassen. Damit wird Fail2ban so gut wie nicht mehr gebraucht.
Absolut sinnvoll wäre es, SSH auf einen anderen Port lauschen zu lassen. Damit wird Fail2ban so gut wie nicht mehr gebraucht.
Deswegen die Frage:
Standardport? Falls ja, magst du den j4f mal ändern und schauen wie es sich dann entwickelt?
Denn fail2ban hat bei mir so gut wie nichts zu tun. Aber selbst mein Testserver, bei welchem ich auf 22 zurückgestellt habe, hat nicht ansatzweise so viel zu tun:
Ratet mal, wann die Umstellung war
Huhu, da bin ich wieder
Ich habe gestern 2 Apache Server aufgesetzt, und die DNS-Records der entsprechenden Domains geändert.
ApacheDE kann ich über die IP erreichen, und auch wenn ich die Domain eingebe (http://www.beispiel.de) leitet diese direkt auf die Apache Default Page.
ApacheCOM kann ich weder über die Subdomain (apache.example.com), noch über die direkte IP erreichen:
Die Website ist nicht erreichbar
apache.example.com hat die Verbindung abgelehnt.
Versuche Folgendes:
Verbindung prüfen
Proxy und Firewall prüfen
ERR_CONNECTION_REFUSED
fail2ban hat nichts gebannt, port 80/tcp ist offen (443/tcp ebenso, auch wenn nicht relevant).
Jetzt kommt der kompliziertere Part:
ApacheCOM hatte früher die Domain von ApacheDE. Wenn ich jetzt die IP von ApacheCOM aufrufe, kommt dennoch die Domain von ApacheDE (http://www.beispiel.de) mit https vorne ran gestellt.
Erst dachte ich das DNS Problem sitzt lokal, aber ein ipconfig /flushdns auf meinem Windows hat leider keine Besserung gebracht.
Irgendwo sitzt da noch der Wurm drin, aber ich finde ihn nicht. Wo muss ich suchen?
Poste mal deinen vhost
Ich habe noch keinen vHost angelegt oder die 000-default.conf verändert. Auf keinem der beiden Server.
Erst dachte ich das DNS Problem sitzt lokal, aber ein ipconfig /flushdns auf meinem Windows hat leider keine Besserung gebracht.
Reicht nicht immer aus. Kann auch sein, dass der Browser (insbesondere Chrome) das noch zwischengespeichert hat.
Reicht nicht immer aus. Kann auch sein, dass der Browser (insbesondere Chrome) das noch zwischengespeichert hat.
Hatte ich deswegen mit dem Chrome Gast-Profil, Edge und Firefox überprüft. Keine Verbesserung.
Was sagt denn die Propagation der beiden domains?
Was sagt denn die Propagation der beiden domains?
Alles fein.
Allerdings ist mir gerade aufgefallen, dass die blanke IP in Firefox geht - für beide Server.
Nur die Subdomain apache.example.com will einfach nicht auflösen...
Ich probiere nun seit 2 Stunden rum, und bin an dem Punkt angekommen, an welchem ich mich im Kreis drehe.
Es gibt zu diesem Thema 1.000 Beiträge in 100 Foren, und trotzdem komme ich nicht dahinter was nicht läuft, bzw. mich der nicht "weitertraue".
Das Kernproblem meiner matomo-Instanz:
Meine /etc/cron.d/matomo-archive:
MAILTO="analytics@example.com"
5 * * * * www-data /usr/bin/php /var/www/html/matomo/console core:archive --url=https://analytics.example.com > /home/matomo/matomo-archive.log
Spätestens bei einem systemctl status cron kam ich dann mal wieder an meine heiß geliebten Rechte:
bud@matomo:~$ systemctl status cron
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; preset: enabled)
Active: active (running) since Sun 2023-11-19 21:08:02 CET; 2 weeks 1 day ago
Docs: man:cron(8)
Main PID: 417 (cron)
Tasks: 1 (limit: 2315)
Memory: 472.0K
CPU: 2min 26.657s
CGroup: /system.slice/cron.service
└─417 /usr/sbin/cron -f
Dez 04 21:42:01 analytics cron[417]: (*system*matomo-archive) RELOAD (/etc/cron.d/matomo-archive)
Dez 04 21:45:02 analytics CRON[3029651]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dez 04 21:45:02 analytics CRON[3029654]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/d>
Dez 04 21:45:02 analytics CRON[3029651]: pam_unix(cron:session): session closed for user root
Dez 04 21:50:01 analytics CRON[3030414]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dez 04 21:50:01 analytics CRON[3030415]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/d>
Dez 04 21:50:01 analytics CRON[3030414]: pam_unix(cron:session): session closed for user root
Dez 04 21:55:01 analytics CRON[3031182]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dez 04 21:55:01 analytics CRON[3031183]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/d>
Dez 04 21:55:01 analytics CRON[3031182]: pam_unix(cron:session): session closed for user root
Display More
Soweit ich das sehe, sind die Rechte für cron selbst falsch gesetzt? Müsste das nicht www-data ausführen?
Uuund ich bekomme leider keine Mails vom Server... Muss ich abgesehen vom MAILO noch etwas einstellen?
Edit: es läuft gar kein stündlicher cron, und schon gar keiner für www-data. Jetzt weiß ich gar nicht mehr weiter...
darf www-data nach /home/matomo schreiben? Vielleicht mit einer Subshell arbeiten?
Wenn Du möchtest, dass der Cron unter einem bestimmten User läuft, dann sehe ich zwei Möglichkeiten: entweder mit su - user -c /bin/command oder -s /bin/shell arbeiten, oder crontab -e gleich als der User (mit shell in /etc/passwd) ausführen.
Bud Was willst Du uns mit dieser Logausgabe sagen? Der Cronjob soll nur um xx:05 ausgeführt werden, aber dieser Zeitpunkt taucht da gar nicht auf?
Oder sollte das ein Cronjob für */5 (alle fünf Minuten) werden?
Mit dem crontab Befehl werden außerdem keine Cronjobs aus den /etc/cron* Ordnern aufgelistet, sondern nur die aus /var/spool/cron/crontabs.
Ich würde generell empfehlen, keine cron-Dateien manuell anzulegen, sondern immer crontab zu nutzen (mit -u user).
nehmt mich mit, nehmt mich mit
Docker ist bei mir so ein Thema was seit längerem auf meiner To-do-Liste steht und ich es gerne verdränge.
Mir ist jedoch bewusst, dass einiges mit der Nutzung von Docker optimierter laufen würde.