Schlagwort: Selflart

Der Trockner will nicht

Die Gat­tin will trock­nen, die App ver­bin­det sich aber nicht mit dem Trock­ner (ja, man könn­te das Gerät auch mit der Hand bedie­nen, aber wir alten Leut­chen sind schließ­lich modern!)
Reboot tut immer gut.
Aber nicht in die­sem Falle.
Ping auf trockner.sokoll (selbst­ver­ständ­lich habe ich eine eige­ne TLD) funk­tio­niert, Netz ist also da. Strom gezo­gen und drau­ßen gelas­sen. Ping funk­tio­niert immmer noch. Hä???
Dann muß es ja wohl ein ande­res Gerät sein, aber welches?

Die /etc/dhcp/dhcpd.conf:

[…]
    host trockner {
      option host-name "trockner";
      hardware ethernet 34:86:5d:a0:71:84;
      fixed-address 192.168.1.57;
    }
[…]
    host sophia-tp {
      option host-name "sophia-tp";
      hardware ethernet 4:ea:56:78:ac:b2;
      fixed-address 192.168.1.57;
    }
[…]

Bamm! Die 192.168.1.57 ist dop­pelt ver­ge­ben, und da die Toch­ter ihren Lap­top auf­ge­klappt hat­te nach der Schu­le, die Gat­tin den Trock­ner aber erst danach ein­ge­schal­tet hat, stand der Trock­ner ver­zwei­felt ohne IP da. Und ohne IP nimmt er kei­ne Befeh­le ent­ge­gen, weder von uns noch vom Chinamann.

Ich muß bei Gele­gen­heit mal mit dem Admin reden.

Ins Knie schießen für Fortgeschrittene

Ges­tern ging @workplace das Dra­ma los:
DNS-Reso­lu­ti­on für unse­re Hosts ging mal, mal nicht mit SRVFAIL. Unser eige­ner auto­ri­ta­ti­ver Ser­ver hat­te kei­ne Pro­blem, aber der Rest der Welt: 1.1.1.1, 8.8.8.8, 9.9.9.9 und so wei­ter. Alle wie ein Blin­ker: An-Aus-An-Aus.
Als anstän­di­ger Hob­by-Admin betrei­be ich die frag­li­che Zone natür­lich mit DNSSEC, seit vie­len Jah­ren völ­lig schmerzlos.
Doch ges­tern zeig­te mir Dns­viz viel rot:

Very uncool. Nun KANN das eigent­lich gar nicht pas­sie­ren, ich habe in mei­nem bind die Zone so konfiguriert:

zone "sagich.nicht" {                                                                                                                                                                                                                          
  type master;                                                                                                                                                                                                                           
  auto-dnssec maintain;                                                                                                                                                                                                                  
  key-directory "/keys";                                                                                                                                                                                                                 
  inline-signing yes;                                                                                                                                                                                                                    
  file "sagich.nicht";                                                                                                                                                                                                         };

Das gan­ze Sig­ning pas­siert also auto­ma­tisch, und das seit Jah­ren, und dar­an hat sich auch nichts geän­dert. Kru­zi­tür­kn! Ich bin kein DNS­SEC-Pro­fi, wie gesagt, das läuft seit Jah­ren sta­bil und ohne mensch­li­ches Eingreifen.

Heu­te früh dann noch mal mit fri­schem Tee einen Blick in die Run­de gewor­fen: Mein Pri­ma­ry hat eine Seri­al von 2021021014, wäh­rend der Secon­da­ry 2021070247 hat. Let’s do the math: 2021021014 < 2021070247. Wenn man Seri­al schreibt, hat sich die Schreib­wei­se YYYYMMDDzwei­stel­li­ge­sin­kre­ment bewährt. Es gibt im Fir­men-DNS (hof­fent­lich) nur zwei Men­schen, die da schrei­ben können/dürfen — einen Kol­le­gen und mich. Der höhe­ren Seri­al 2021070247 nach zu urtei­len, hat jemand am 07. 02. 2021 die Seri­al erhöht, um einen gewal­ti­gen Sprung. Was zur Fol­ge hat­te, daß der Secon­da­ry ab die­sem Zeit­punkt kei­ne Noti­fies mehr ent­ge­gen­nahm, war­um auch. Auch nicht die Noti­fies, daß sie die RRSIGs geän­dert haben…
Ich für mei­nen Teil kann mich nicht erin­nern, am 7. 2. im DNS geschmiert zu haben — was aber nicht all­zu­viel bedeu­tet, viel­leicht habe ja doch ich das vergeigt.
Jetzt müs­sen wir war­ten, bis der Admin des Secon­da­ries die Zone bei sich löscht und neu zieht, dann ist hof­fent­lich alles wie­der schön.

#sel­flart #dns #dns­sec

Apache, CentOS 7, gestacktes Zertifikat

Mal wie­der einer aus der Ecke #sel­flart:

Ein Kauf­zer­ti­fi­kat läuft aus und soll durch ein LE-Zer­ti­fi­kat ersetzt wer­den. Kein Ding. Tau­send­mal berührt, tau­send­mal ist nichts pas­siert.
Alt:

  SSLCertificateFile /path/to/certificate.crt
  SSLCertificatekeyFile /path/to/privkey.key
  SSLCertificateChainFile /path/to/chain.crt

SSLCer­ti­fi­ca­teChain­File ist aller­dings depre­ca­ted, man soll Zer­ti­fi­kat und Chain stacken.
Kein Problem!

  SSLCertificateFile /path/to/le/fullchain.pem
  SSLCertificatekeyFile /path/to/le/privkey.pem

Web­ser­ver rel­oa­ded, mit openssl s_client … | openssl x509… gegen­ge­scheckt, alles fein.

Ein Tag spä­ter fällt auf: Builds gehen nicht mehr, Java mault mit kryp­ti­schen Stack­traces über kaput­tes SSL. Pha­se eins Arsch­kar­ten­rou­ting (da bin ich ein eben­bür­ti­ger Mit­spie­ler): Fixt euer gamm­li­ges Java, daß es auch mit LE zuran­de kommt!. Jira-Tickets ent­ste­hen. Man glaubt gar nicht, wie groß ein Jira-Ticket wer­den kann, bevor über­haupt jemand an dem Pro­blem arbeitet!
Jeden­falls, um es abzu­kür­zen: Nach Pha­se n Arsch­kar­ten­rou­ting stellt sich raus: Der Web­ser­ver sen­det nur sein eige­nes Zer­ti­fi­kat, nicht aber das Inter­me­dia­te aus fullchain.pem.
Die Lösung ist damit klar:

  SSLCertificateFile /path/to/le/cert.pem
  SSLCertificateChainFile /path/to/le/chain.pem
  SSLCertificatekeyFile /path/to/le/privkey.pem

Argh!

Das Tolle an Linux/postfix

ist ja, daß die Waf­fen gela­den und aus­ge­rich­tet sind.
Und root hat die Macht über den Abzugshahn.

Heu­te also Fol­ge 4711 #Sel­flart.

Da der Exch­an­ge hin­ten sowie­so .exe und Co. nicht ent­ge­gen­nimmt, muß mein Post­fix vor­ne das ja auch nicht tun. So dann! Mut!

root@mx1:~# grep ^mime_header_checks /etc/postfix/main.cf
mime_header_checks = regexp:/etc/postfix/mime_header_checks
root@mx1:~# cat /etc/postfix/mime_header_checks
/name=[^>]*\.(bat|com|exe|dll|mht|vbs)/ REJECT
/name=[^>][0-9]+\.docx{,1}/ REJECT
root@mx1:~#

So soll es sein (Die zwei­te Zei­le bezieht sich auf die­se Hei­se-Mel­dung)
Doch was ist das?

root@mx1:~# grep E81BF5FFE3 /var/log/mail.info
May  7 11:04:53 mx1 postfix/smtpd[30608]: E81BF5FFE3: client=sonic328-45.consmr.mail.ne1.yahoo.com[66.163.191.20]
May  7 11:04:54 mx1 postfix/cleanup[30568]: E81BF5FFE3: message-id=<1557213647.728781@dmarc.yahoo.com>
May  7 11:04:54 mx1 postfix/cleanup[30568]: E81BF5FFE3: reject: header Content-Disposition: attachment; filename="aol.com!example.net!1557100800!1557187199.xml.gz" from sonic328-45.consmr.mail.ne1.yahoo.com[66.163.191.20]; from=<noreply@dmarc.yahoo.com> to=<dmarc-report@example.net> proto=ESMTP helo=: 5.7.1 message content rejected
root@mx1:~#

Hä? Wie­so das denn? Ist doch alles in Ordnung?
Kopf­kratz. Nein, es ist nicht alles in Ord­nung. Im Namen des Attach­ments steht aol.com.

Die kor­rek­te Zei­le muß also lau­ten, *trom­mel­wir­bel*

/name=[^>]*\.(bat|com|exe|dll|mht|vbs)$/ REJECT

Und alles ist wie­der schön.

OT: Wür­de post­fix mit­tels jour­nald log­gen, hät­te ich den Feh­ler wohl nie gesehen…