Schlagwort: Selflart

Wir schießen uns in die Füße, erneut

Das Schö­ne an Linux ist ja, daß man als root über sämt­li­che Waf­fen vefügt, um sich gepflegt in die Füße zu schie­ßen, und nut­zer­freund­lich wie Linux nun mal ist, sind die­se Waf­fen auch schon gela­den, aus­ge­rich­tet und ent­si­chert — man muß nur noch abdrücken.

Vor ein paar Wochen: Ich woll­te ein Video mit nach AV1/Opus umco­die­ren und hat­te irgend­wie nicht begrif­fen, daß die Enco­der bei Debi­an im ganz nor­ma­len Repo­si­to­ry lie­gen und war also der Mei­nung, ich müs­se das selbst über­set­zen. Das ist ein ziem­lich dickes Brett, was man da boh­ren muß, zum Bei­spiel sind man­che Biblio­the­ken in golang geschrie­ben, so daß man noch ein go nach­in­stal­lie­ren muß. Ich fing also an, und natür­lich wur­den erst­mal ton­nen­wei­se Abhän­gig­kei­ten nach­in­stal­liert, bevor es über­haupt ans Bau­en ging. Am Ende hat­te es funk­tio­niert — und ich stell­te fest, daß das völ­lig umsonst war: Debi­ans ffmpeg lie­fert alles mit, was ich brau­che. Lehrgeld.

Der Rech­ner hat eine rela­tiv klei­ne Root-Par­ti­ti­on, und der gro­ße Rest wird für ZFS ver­wen­det. Alle Diens­te, die ins Inter­net expo­niert sind, lau­fen dort. Also jeden­falls / war arg voll, aber ich wuß­te nicht mehr, was ich alles sinn­lo­ser­wei­se nach­in­stal­liert hat­te. Da kam mir eine Idee: Ein­fach alle dev-Pake­te löschen und hin­ter­her noch ein autore­mo­ve, damit auch die Abhän­gig­kei­ten gelöscht wer­den. Hat gut funk­tio­niert, danach war wie­der eini­ger Platz frei. Das war vor ein paar Tagen.
Heu­te sehe ich mal wie­der ins Zab­bix. Da steht auf ein­mal, daß zfs-zed.service nicht lau­fen wür­de. Also ver­su­che ich ihn zu star­ten, doch systemctl meint, es gäbe ihn nicht, und in der Tat: es gibt ihn nicht. Ich ahne etwas:

Start-Date: 2024-05-05 20:58:18
Commandline: apt -y purge dpkg-dev
Purge: build-essential:amd64 (12.9), zfs-zed:amd64 (2.2.3-1~bpo12+1), zfs-dkms:amd64 (2.2.3-1~bpo12+1), dpkg-dev:amd64 (1.21.22), xtables-addons-dkms:amd64 (3.23-1), dkms:amd64 (3.0.10-8+deb12u1)
End-Date: 2024-05-05 20:58:53

ZFS-on-Linux ist aus Lizenz­grün­den als dyna­mi­sches Ker­nel­mo­dul rea­li­siert. Und muß mit dkms(8) gebaut wer­den, was diver­se Hea­der erwar­tet, die eben in dev-Pake­ten lie­gen. Die hat­te ich aber gelöscht, und mein tap­fe­res autore­mo­ve hat­te dann das kom­plet­te ZFS weg­ra­siert (aber nicht die Daten). Und solan­ge die Büch­se läuft, macht das auch nichts.
Heu­te dach­te ich dann, ich soll­te nicht län­ger war­ten mit einem Reboot. Code, der nur noch im RAM liegt, nee, muß nicht sein. Also reboot und tja, kein ZFS, kei­ne Dienste.

Die Lösung: Nach­se­hen, ob der Pool noch da ist (zpool import) und dann impor­tie­ren (zpool import <poolname>) Reboot, alles wie­der schön.

Und die Flin­ten nach­la­den nicht ver­ges­sen fürs nächs­te mal!

 

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…