Das längste Thema

Zitat von mfnalex

[...] Danke für den Link, bin gelistet bei fulldom.rfc-clueless.org und whois.rfc-clueless.org. [...]

bei mir auch. Ich denke, es liegt an der deutschen TLD, denn die Domains .com und .net sind bei clueless nicht geblacklisted.

Zitat von joas

bei mir auch. Ich denke, es liegt an der deutschen TLD, denn die Domains .com und .net sind bei clueless nicht geblacklisted.

so ist es, denn es ist die .de-TLD gelistet ...; sowas nennt ma Kolateralschaden ...

mal was pseudo-esotherisches: im Win32-API gibt es einen API-Call, den man aufruft,

um das System mit folgender "Geschichte" nicht zum Stehen zu bringen

long double calcSum( int n )
{
    long double ldblSum = 0.0;
    while ( --n > 0 )
        ldblSum += log10l( (long double) n );
    return ldblSum;
}

wird das mit sehr großen 'n' aufgerufen und hat man NUR einen Core, dann steht die Kiste ...

sprich ein preemptives Multitasking ist damit ebenfalls 'deaktiviert' und genau die Funktion

die das verhindert, hätt ich gerne gewußt, aber f. Linux

in der Win32-API Doku findet man das ...

Zitat

Threads that do not contain windows should use the Sleep function with a sleep time of zero milliseconds to give up the remainder of their current time slice.

wo find ich des Pendant zu Linux ...

mainziman Meinst du https://linux.die.net/man/2/sched_yield ?

Seit meinem Update auf das neueste Nagios XI startet NRPE nicht mehr auf dem Monitoring-Server...

[root@monitor system]# service nrpe status
Redirecting to /bin/systemctl status nrpe.service
● nrpe.service - Nagios Remote Plugin Executor
   Loaded: loaded (/usr/lib/systemd/system/nrpe.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mi 2018-08-01 00:19:41 CEST; 2s ago
     Docs: http://www.nagios.org/documentation
  Process: 8543 ExecStopPost=/bin/rm -f /usr/local/nagios/var/nrpe.pid (code=exited, status=0/SUCCESS)
  Process: 8542 ExecStart=/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f (code=exited, status=2)
 Main PID: 8542 (code=exited, status=2)

Aug 01 00:19:41 monitor.meine-domain,de systemd[1]: Started Nagios Remote Plugin Executor.
Aug 01 00:19:41 monitor.meine-domain,de systemd[1]: Starting Nagios Remote Plugin Executor...
Aug 01 00:19:41 monitor.meine-domain,de systemd[1]: nrpe.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 01 00:19:41 monitor.meine-domain,de systemd[1]: Unit nrpe.service entered failed state.
Aug 01 00:19:41 monitor.meine-domain,de systemd[1]: nrpe.service failed.

Das Update ist laut Nagios problemlos installiert worden. Hab es sowohl mit dem Web-Updater als auch übers Terminal probiert.

Jemand eine Idee, woran das liegen könnte?

Meine nrpe.service:

[Unit]
Description=Nagios Remote Plugin Executor
Documentation=http://www.nagios.org/documentation
After=var-run.mount nss-lookup.target network.target local-fs.target time-sync.target
Before=getty@tty1.service plymouth-quit.service xdm.service
Conflicts=nrpe.socket

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
Restart=on-abort
PIDFile=/usr/local/nagios/var/nrpe.pid
RuntimeDirectory=nrpe
RuntimeDirectoryMode=0755
ExecStart=/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f
ExecReload=/bin/kill -HUP $MAINPID
ExecStopPost=/bin/rm -f /usr/local/nagios/var/nrpe.pid
TimeoutStopSec=60
User=nagios
Group=nagios
PrivateTmp=true
OOMScoreAdjust=-500

Ein " sudo -u nagios /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f" liefert mir leider überhaupt keine Fehlermeldung. "netstat -tulpen|grep 5666" liefert ebenfalls nichts. NRPE will einfach nicht starten.

Zum Glück gibts die Snapshots

mfnalex nrpe.service: main process exited, code=exited, status=2/INVALIDARGUMENT Exit Code 2, Invalide Argumente.

Was liefert denn --help zu -c und -f. Irgendwelche Pflichtargumente aufgelistet, die fehlen?

Zitat von killerbees19

Wenn das stabil läuft, sehe ich trotzdem keinen Grund mehr, für Postfix mehr als Port 25 nach außen zu öffnen.

Läuft bisher übrigens größtenteils zufriedenstellend.

Es gibt nur ein Problem, das ich nicht gelöst bekomme: Lokale Scripte (wie z.B. Roundcube) können zwar zu dovecot-submissiond verbinden und sich erfolgreich authentifizieren, danach dreht allerdings Postfix durch und verweigert den Versand, weile er behauptet, dass man nicht eingeloggt ist. Die Ursache dafür ist wahrscheinlich, dass über XCLIENT der Client nicht auf 127.0.0.1 bzw. ::1 gesetzt werden darf. Ob das wirklich so ist, weiß ich noch nicht sicher, aber es wäre eine gute Erklärung. Andernfalls könnte der dahinter liegende Client sonst vielleicht selbst nochmals XCLIENT ausführen, nehme ich mal an.

Lässt man die Scripte ganz normal mit STARTTLS oder TLS über die öffentliche IP-Adresse verbinden, klappt es einwandfrei. Aber das ist irgendwie nicht Sinn der Sache…

Edit: Eventuell klappt es, wenn man ein Dummy-Interface mit einer privaten IP-Adresse anlegt und Postfix <-> Dovecot darüber kommunizieren lässt? Das muss ich in nächster Zeit einmal ausprobieren!

mfnalex Ja genau das habe ich gesucht; Danke

Einen Anbieter aus Österreich dürfte es nun auch erwischt haben. Habe ne Mail dazu erhalten.

Zitat von margau

Es gibt doch hier einige Leute, die Proxmox mit LXC und einer Public IP laufen haben.

Hat jemand schonmal ein erfolgreiches Reflection NAT mit IPTables gebaut?

Hintergrund: Habe eine öffentliche IP, und die Dienste kommen mit DNAT auf die richtige Private IP. Nur wenn ich von einem Container auf diesem Host einen anderen von der öffentlichen "Seite" aufrufen will, tut das DNAT so nicht mehr. Was ist da die einfachste Lösung?

Da ich bestimmt 10 verschiedene DNATs pro Host habe brauche ich auch etwas, was "Flott" geht (und nicht für jede Kombination Container-anderer Container einzeln gebaut werden muss )

Danke und Viele Grüße

margau

Alles anzeigen

Typisches Hairpin Problem. Entweder du rufst intern auch über interne IPs auf, oder du machst es wie ich und setzt einen internen DNS Recursor ein.

Zitat von Kraeutergarten

Einen Anbieter aus Österreich dürfte es nun auch erwischt haben. Habe ne Mail dazu erhalten.

erwischt bei was/durch was/mit was?

Email Adressen sind von ihnen aufgetaucht. Wurden wohl gehacked.

Zitat von Kraeutergarten

Email Adressen sind von ihnen aufgetaucht. Wurden wohl gehacked.

wessen Email Adressen und wo?

Email Adressen aus der Datenbank. Meine die ich dort benutze ist auch gelisted.

haveibeenpwned.com

Hach, es ist vollbracht.

Meine Webangebote laufen nun auch produktivv mit TLSv1.3(28) Es sollte ja nicht mehr lange dauern, bis 1.3 offiziell freigegeben wird.

Aus Rücksicht auf meine Apple-User hatte ich jetzt sogar noch 1.0 an Bord, das wird nu eingestampft. Die sollen gefälligst ihre Software updaten...

Ich hatte da tatsächlich jemanden, der meinte: "Ist ja schön, dass das alles sicher ist, aber was nützt das, wenn es zu nichts kompatibel ist?" Naja, die Frage muss man da dann zu den älteren Apple-Produkten stellen, denn nur da hatte man noch Ewigkeiten Beschränkungen, was neuere TLS-Implementierungen angeht (Apple-Mail).

Zitat

habe einen Root wo der TS draufliegt

mal sehen, wie lange noch...

Bei dem Anbieter gabs wohl zum Glück nur eine defekt API und dadurch wurden nur die Emails geleaked.

Der Vorfall beim anderen Anbieter zeigt mal wieder deutlich, wie praktisch der Benachrichtigungsservice bei HIBP von Troy Hunt ist.

Dieses Mal war es "nur" ein Pastebin Eintrag, der automatisch gefunden wurde. Der wäre eventuell lange unentdeckt geblieben.

Zitat von chaosrind

Es sollte ja nicht mehr lange dauern, bis 1.3 offiziell freigegeben wird.

Dauert noch so ungefähr -4 Monate. TLS 1.3 ist schon seit Ende März 2018 freigegeben.