Disclaimer: Diese Seite dient hauptsaechlich der Belustigung und des Sarkasmus
>>>>> die Leitung ist im gleich Moment ausgefallen wie der $IX-Routerserver.
>>>>
>>>> Nein, die ist schon seit Di, 10.6., 19:10 Uhr kaputt.
>>>
>>> Ich hatte im 1. OG einen V. SDH Konverter ausgebaut von dem wir sicher waren das er nicht mehr in Betrieb ist. Scheinbar war er es doch, laeuft wieder das Geraet und Alina pingt nun auch wieder.
>>
>> *grins*
>>
>> Passiert, aber wird man nicht stutzig, wenn 5min nachdem man etwas ausbaut, eine Trouble-Meldung von Nagios kommt?
>
> sollte man, ja.
> Hatte die falsche Sicherheit das das Geraet nicht mehr in Benutzung sein sollte und gucke auch noch zu unregelmaessig in die Trouble Mails.
>
> Klassischer fail, muss ich mich umorganisieren.
Wir sollten auch Nagios besser konfigurieren, damit man nicht so gegen die Meldungen abstumpft. Niemand sollte "trouble"-Mail automatisch wegsortieren wollen. Man tut es, weil zu viele Dinge normalkaputt sind. Wir müssen dahin kommen, dass eine "trouble"-Mail auch wirklich Handlungsbedarf bedeutet, dann übersieht man eine wichtige Mail auch nicht mehr so schnell wie jetzt zwischen 20 unwichtigen.
Viele Grüße,
$kollegie
PS: normalkaputt.de ist noch frei!!
>>> Das wäre auch noch mal ein Punkt für's Monitoring.
>> das ist im Monitoring sogar bei unseren API Checks aufgefallen ab 08:20.
>> Hatte selber heute morgen etwas Internetprobleme und habe das dann kurz bevor ich ins Buero wollte nur noch sehen koennen und nicht ernst genug genommen.
>> Nicht angeschlagen ist aber unser "Token Laufzeit" check.
>> Da waere mal interessant ob der Token wirklich die ganze Zeit gueltig war, es aber trotzdem nicht funktioniert hat oder was da war.
>> Nagios hat ordnungsgemäß gequiekt. Ging vielleicht im kaputten Normalzustand unter.
>> normalkaputt.de ist übrigens noch zu haben. Ran an die Buletten, Kollegen!
> $SOFTWAREAPIPROXY selber hat firewallmäßig keine Beschränkungen und also auch ein aktuelles Token vom neuen $KILLSWITCH.
Das bedeutet, dass, obwohl das Token jede Menge Daten enthält und eigentlich self-contained sein könnte, der $SOFTWARE API-Service nachhause telefoniert, um das Token zu validieren - oder übersehe ich da was?
Wenn das so wäre, hieße das ja, dass ein länger laufendes Token uns gar nicht helfen würde und unsere Prozesse auf jeden Fall sofort bei einem Ausfall des Auth-Servers stehen würden.
Validation result:
{
"errorMessages" : [ "Line: 17, column: 4302, Auf \"&\" in der Entityreferenz muss umgehend der Entityname folgen.", "Error validating via XSLT: Auf \"&\" in der Entityreferenz muss umgehend der Entityname folgen." ],
"errorPaths" : [ "/CMS/beitrag[1]/inhalt-liste[1]/inhalt[21]/objekt[1]/p[4]/cms_link[1]" ],
"status" : "SOFTWARE_ERROR",
"statusId" : -1
}
>>> AUTH TLS^M' at 2025-12-04-18:14:11.378 ## A=www-data@$HOST+796 number=796 process=3013226
<<< 234 Proceed with negotiation.' at 2025-12-04-18:14:11.379 ## A=www- data@$HOST+796 number=796 process=3013226
unexpected EOF on command channel: at /etc/lprng/filters/ftpifs line 164.' at 2025-12-04-18:14:11.389 ## A=www-data@$HOST+796 number=796 process=3013226
Mögen die unser AUTH TLS nicht mehr oder ist deren Zertifikat abgelaufen?
Man könnte die 1 für TLS in ftpif.conf wieder auf 0 setzen und das Passwort wieder klartext übertragen (YEAH!).
[...]
> müsste jetzt auch dann los. $DRUCKEREI hat nix geändert sagen sie.
haben sie aber:
0 s:CN=$CN
i:C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Riddling Rhubarb R12
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Dec 2 15:10:04 2025 GMT; NotAfter: Mar 2 15:10:03 2026 GMT
Neues Zertifikat von vorgestern, anscheinend von STAGING statt dem richtigen, aber vielleicht fehlinterpretiert oder Zufall.
>> Habe ssl in $HOSTNAME:/etc/lprng/filters/ftpif.conf für diesen Kunden deaktiviert, läuft.
> okay, ist aber ja eigentlich nicht was wir wollen.
definitiv nicht, auch wenns jahrzehntelang so war.
Weiter gehts auf scheissekonfiguriert.de
Mehr Bilder aus Korea melmac.space/photos/korea
Deine IP: 2600:1f28:365:80b0:3698:4c:d826:8bee