I've managed to fix one of the recent problems with my FreeIPA. To be more specific – after few months breakage, ACME issuer is working again for me.

Solution was dead simple after I've found the relevant line in the logs:

2024-02-07 21:59:24 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3]
SEVERE: Servlet.service() for servlet [ACME] in context with path [/acme] threw exception
org.jboss.resteasy.spi.UnhandledException: com.netscape.certsrv.base.UnauthorizedException:
Authorization failed: Authorization failed on resource: group=Certificate Manager Agents, operation: {1}

I've fired up an LDAP client (I'm using JXplorer), went to /ipaca/groups/Certificate Manager Agents and added two records. Type uniqueMember with value uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca, plus another one for the second replica. FreeIPA started to issue certificates again, although there are still some strange trackbacks in the logs.

Why the group membership dissapeared? I don't know.

As cool as FreeIPA is – I'm using it for over 10 years at home – sometimes I fell it breaks just by being looked at.

TLDR: If you have accounts or groups with UID or GID not falling in any defined range ID ranges, fix that by any of: 1) changing the UID/GID; 2) extending defined ID range; 3) creating a new ID range covering those UIDs/GIDs.

Then generate new SIDs with ipa config-mod --enable-sid --add-sids.

Few months ago my FreeIPA installation stopped allowing users to login. It was mostly a nuisance for me, nothing critical:

• on most important computers I have local accounts

• services authenticating with plain LDAP continued to work

• so what didn't work? Login into FreeIPA's web interface. But admin accounted worked, so…

When I eventually started to debug, I found following logs in krb5kdc.log:

krb5kdc[3123](info): AS_REQ : handle_authdata (2)
krb5kdc[3123](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26),
camellia128-cts-cmac(25)}) 192.168.x.x: HANDLE_AUTHDATA: zdzichu@PIPEBREAKER.PL for krbtgt/PIPEBREAKER.PL@PIPEBREAKER.PL, No such file or directory

Some searching the web later, I've concluded No such file or directory refers to SID, a Security Identifier. SIDs are some Microsoft's Active Directory properties. I see no reason to have them on Linux-only FreeIPA installs.

The Upgrade section in the documentation is wrong:

The upgrade does not turn on the feature. If the admin wants to enable SID generation, he needs to update the packages and run the new command

It's not true, admin desires don't matter. As Alexander Bokovoy wrote on the mailing list:

FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured to do so on new installations even when integration with AD is not considered, due to tightened requirements to process constrained delegation in Kerberos.

So SIDs are really required in FreeIPA now. I don't want them, but whatever. There is a command which is supposed to generate missing data:

ipa config-mod --enable-sid --add-sids

It finished without errors, but login still didn't work.

More searching. The commands fires up a job (in LDAP server?) so let look into dirsvr's errors.log:

[12/Jan/2024:14:07:51.524937136 +0100] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[12/Jan/2024:14:07:51.566941696 +0100] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [135] into an unused SID.
[12/Jan/2024:14:07:51.585948214 +0100] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
[12/Jan/2024:14:07:51.597088076 +0100] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32].

OK, we're getting somewhere. I had some an obsolete group defined with GID 135. Let's remove it and re-run the command.

[12/Jan/2024:14:24:29.879953617 +0100] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [1037] into an unused SID

I know this UID, this is one of the users I've migrated to FreeIPA. Obviously I cannot remove it.

Turns out, FreeIPA has something called ID ranges. If you have accounts or groups with UID or GID not falling in any defined range, sidgen script just fails.

I had to go to IPA Server -> ID Ranges -> Add in web console and make changes. I did not want to mess with already defined ranges, so I created a new one. An “unix” range. Base 1000, size 1000, had to guess some numbers for RID ranges before it was accepted.

Not that I'm so smart to figure it out. There's Knowledgebase solution 394763 for exactly this problem.

And just like that, kerberized login to FreeIPA started working again.

Knowing what was wrong, I've started noticing (and understanding) other people have the same kind of issues.

One problem down, two to go. Replication between my replicas is not working. Again with unhelpful message:

[12/Jan/2024:14:33:32.812986996 +0100] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=kaitain.pipebreaker.pl-to-okda.pipebreaker.pl" (okda:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.

I did all the steps from KB 2988311 but it didn't help.

Second problem, ACME on FreeIPA ceased to work for me.

I hadn't had willpower to debug these two, yet.

Since the beginning, systemd had a Restart= directive to do just that – restart a service when it fails or exists. Some tuning was provided by RestartSec= (how long to wait between restarts), StartLimitBurst= (how many times to try) and few minor directives.

Starting with systemd v254, we have two new knobs:

• RestartSteps= the number of steps to take to increase the interval of auto-restarts

• RestartMaxDelaySec= the longest time to sleep before restarting a service as the interval goes up

Together, they provide ability to exponentially extend wait-time between restarts. First restart is quite quick, but then system waits more and more. Here what it means.

Let assume a service with following settings:

Restart=always
RestartSec=100ms (the default)
RestartMaxDelaySec=10s
RestartSteps=5

Upon a failure, systemd will wait (rounded a bit):

0. 100ms until first restart

1. 250ms until next restart (first step)

2. 630ms until next restart (second step)

3. 1.58s until next restart (third step)

4. 3.98s until next restart (fourth step)

5. 10.0s until next restart (RestartSteps=5 – fifth step) and following restarts

Second example. Given:

RestartSec=1s
RestartMaxDelaySec=10s
RestartSteps=3

subsequent restarts will be done after waiting:

0. 100ms

1. 2.15s (step 1)

2. 4.64s (step 2)

3. 10.0s (step 3, as in RestartSteps=3).

Hope this helps. You can find the exact formula in src/core/service.c.

Firma Logitus, od kilku lat mój dostawca internetu, została w tym roku przejęta przez Netię. Moja dotychczasowa umowa właśnie wygasła, więc zostałem przełączony na netiową infrastrukturę.

Mimo zapewnień konsultantki z infolinii, że nic się w dostępie nie zmieni, pierwsza wizyta technika zakończyła się niepowodzeniem. Otóż chciał on przekonfigurować mój router¹, bo jednak technologia dostępu się zmieniła! Zamiast zwykłego DHCP – Netia używa PPP-over-Ethernet.

¹ Moim routerem jest po prostu domowy serwer (sieć dostawcy mam podłączoną po switcha na dedykowanym VLANie), do zmiany na pppoe nie byłem gotowy. Musieliśmy spotkać się tydzień później, a ja w międzyczasie zrobiłem research.

Następnym razem się udało, ale jakim kosztem. Mam silne flashbacki sprzed 25 lat, kiedy to ostatni raz używałem pppd. Niewiele się tu zmieniło. Wciąż brakuje sensownych wartości domyślnych, więc plik konfiguracyjny puchnie przy każdej usterce.

Do pięknie zintegrowanej konfiguracji sieciowej w systemd-networkd trzeba było dołączyć osobnego demona pppd, żyjącego w swoim świecie, więc całość wygląda teraz jak powiązana sznurkami. Znowu nie obyło się bez skryptów ip-up poprawiających konfigurację po nawiązaniu połączenia. W tym przypadku – do którego urządzenia sieciowego ma się przypinać tunel SIT do Hurricane Electric. Tak, Netia w mojej okolicy w dalszym ciągu nie ogarnia IPv6.

Jedyny powiew świeżości to możliwość monitorowania łącza. Przekompilowałem pppd w Fedorze z jedną łatką z wersji 2.5.1, dzięki mój Prometheus zbiera trochę statystyk (chociaż pośredniczy w tym skrypt w… Perlu, udający CGI). Z tego wykresik rysuje Grafana. Stały narzut PPPoE to prawie 3ms opóźnienia na LCP echo request-reply (taki ping w warstwie łącza danych), czasami skacze do kilkunastu ms.

Wyraźnie widać też zwiększenie opóźnień o 4-5ms na wykresach rysowanych przez Smokeping:

Pierwsza „awaria” miała miejsce już po tygodniu. O 23:57 przestało cokolwiek przychodzić, pomimo nawiązanej sesji i wymagany był restart pppd. Normalnie jak z modemami w ubiegłym wieku.

Podsumowując, z Netią jest obiektywnie gorzej niż było w Logitusie. Pierwsza faktura na 0zł też nie jest plusem, miewałem takie u poprzedniego dostawcy. A dane na niej nie działają w panelu Netia Online.

Obecnie używam z Netią poniższej konfiguracji pppd, a definicję dla systemd oparłem na znalezionej tutaj.

# With  this option, the peer will have to supply the local IP address during IPCP negotiation
noipdefault

defaultroute

# Do not require the peer to authenticate itself.
noauth

# Do not exit after a connection is terminated; instead try to reopen the connection
persist

# Specifies how many seconds to wait before re-initiating the link after it terminates.
holdoff 2

# I've got one silent break in connectivity, restarting pppd helped
# add pinging the other end to monitor this
# send an LCP echo-request frame to the peer every n seconds
lcp-echo-interval 2
# will presume the peer to be dead if n LCP echo-requests are sent without receiving a valid LCP echo-reply
lcp-echo-failure 3
# will send LCP echo-request frames only if no traffic was received from the peer
# unfortunately, will cause ppp-rtt data to be empty if the traffic is constant
#lcp-echo-adaptive

# with 2.5.1 + prometheus exporter as a perl script
lcp-rtt-file /run/ppp-rtt.data

## Don't detach from the controlling terminal.
#nodetach
# Use  this option to run pppd in systemd service units of Type=notify (up_sdnotify implies nodetach).
up_sdnotify

plugin pppoe.so

# Use the ethernet device interface to communicate with the peer
nic-vl2isp
# Set the ppp interface name for outbound connections.
ifname pppoe-netia

user "5l3d21u@bn24.pl"

Mam bardzo pozytywne odczucie związane ze smart kontrolerami marki Shelly.

Większość sterowania w domu mam polutowane na bazie modułów Sonoff i d1mini. We wszystkich wgrywałem lub wymieniałem firmware, żeby mieć:

• w pełni lokalne działanie, bez jakieś chińskiej chmury

• obsługę MQTT do integracji

Ostatnio kupiłem modulik z serii Shelly mini… i po krótkiej analizie zostawiłem oryginalne oprogramowanie. Bo wszystko ma.

Moduły są całkiem małe (29×35×16mm), przy odrobinie szczęścia można je upchnąć w puszce pod włącznikiem. MQTT w standardzie (a także obsługa webhooków, websocketów i własnego JSON-RPC po UDP). Procesor ESP32 wystarcza to komunikacji z użyciem TLS. Niestety sieciowo zaimplementowano jedynie IPv4.

Interfejs webowy jest czytelny i przemyślany. Np. koło adresu MAC jest wygodny przycisk kopiujący go do schowka.

Tak, przy okazji mierzy zużyte kWh. Oprócz tego podstawowe terminarze i akcje można zakodować bezpośrednio na kontrolerze. W opcjach jest opcja repeatera WiFi, prawdopodobnie można na bazie tych modułów zrobić mesh.

Jeśli dać tym urządzonkom dostęp do internetu, z poziomu tego interfejsu można też zaktualizowaź firmware do najnowszego stabilnego lub beta.

Na stronach Shelly wszystkie funkcje i API są dobrze udokumentowane. Podłączenie pod mojego OpenHABa zajęło mi mniej niż kwadrans. Do nowszych wersji OpenHAB są nawet natywne bindingi.

Shelly dostaje moją foczkę aprobaty.

Jak najtaniej kupić stację pogodową? Wcale nie kupować. Sąsiedzi z pewnością już jakieś mają, a każdy szanujący się haker ma jakiś odbiornik SDR w szufladzie.

rtl_433 „z pudełka” obsługuje ponad 200 różnych protokołów i ma bardzo przyjemny wysyłacz MQTT.

Wyraźnie widać, że któryś sąsiad powiesił termometr w nasłonecznionym miejscu ;)

Fun fact: większość czujników ciśnienia, w kołach samochodów na parkingu pod blokiem, wysyła też informacje o swojej temperaturze.

Twórcy przeglądarek w końcu ogarnęli się z kluczowym elementem ukrywania z jakimi stronami się łączymy, czyli prywatność++. Bo o ile wymieniane dane są szyfrowane przez TLS, to zanim to nastąpi przeglądarka WWW musi powiedzieć z jaką stroną chce gadać. Te informacje są (były) widoczne dla wszystkich. Taki niezaufany obserwator może nie wiedzieć co robimy, ale z samego faktu połączenia z http://szybkiewypo.pl może coś tam wywnioskować.

Ta nieszyfrowana informacja nazywa się Server Name Indicator (SNI). Jej zachowująca prywatność wersja to Encrypted SNI (ESNI), które przez kilka lat się nie przyjęło. Ostatnio jednak udało się dopracować standard i jako Encrypted Client Hello (ECH) zostało włączone w popularnych przeglądarkach.

Działanie można sprawdzić na https://tls-ech.dev/. Uzbrojony w Chrome 117.0.5938.149 kliknąłem i…

You are not using ECH. :(

Co jest, powinno działać! Sprawdziłem #encrypted-client-hello we flagsach – włączone. Inna przeglądarka? W Mozzarella Firefox 118.0.1 tak samo nie działa. Podejrzane.

Zacząłem trochę researchu, czytania. I znalazłem dwie poszlaki. W opisie ficzera w Chrome mamy taki zapis:

While supported on all platforms, ECH requires keys fetched via DNS in the new HTTPS record. Chrome can currently fetch the HTTPS record over DoH and over our built-in DNS resolver. As of writing, the built-in DNS resolver is not yet enabled.

Podobne z Firefoksem:

No, but DoH is required by Firefox to get ESNI going so please first make sure you have that enabled!

DoH to oczywiście DNS-over-HTTPS. Spoko funkcjonalność, ale akurat mam ją wyłączoną w mojej domowej sieci. Wprowadziłem blokowanie reklam na poziomie lokalnego DNS (bazy z PiHole). Szkoda by było, jakby kogoś z domowników czy gości tego nie objęło, bo przeglądarka postanowiła rozwiązywać nazwy na własną rekę.

Tak więc w obecnych implementacjach przeglądarki używają ECH jedynie w powiązaniu z DoH. Moim zdaniem niesłusznie. Nie ufają lokalnym DNSom, które mogą być spoko. Pozwalają jednocześnie na podsłuchiwanie negocjacji TLS gdzieś „po drodze”. Ignorują inne bezpieczne sposoby rozwiązywania nazw (DNS-over-TLS, DNS-over-TOR itp).

Czynią mnie smutnym.

Pojazd mój powszedni (hulajnoga Joyor s8s) ma trochę od czapy zrobione oświetlenie. Postanowiłem to poprawić.

W ramach eksperymentu, sprawozdania będę publikował nie tutaj, a na forum Hackerspace Pomorze.

Właśnie stuknęła w miarę równa rocznica mojego pisania na tym blogu. Pierwszy post pojawił się równo 20 lat temu. Uff!

Zaczęło się na serwisie Jogger, a gdy ten skończył działalność – przeniosłem wypociny na własny serwer. W międzyczasie próbowałem też publikacji na Google+. Też już nie działa, ale wpisy stamtąd zintegrowałem z resztą treści.

Początek był w zasadzie przypadkowy. Byłem w tamtym czasie developerem EKG2, to jest multikomunikatora. Wersja pierwsza obsługiwała tylko sieć Gadu-Gadu, ja w drugiej rozwijałem wsparcie protokołu Jabber/XMPP. Jogger był serwisem który umożliwiał publikowanie poprzez wysyłanie wiadomości Jabberem. Doskonały sposób na testowanie działania swojego kodu.

Przy okazji Joggera, super rozwiązaniem budującym społeczność była publikacja wszystkich notek na głównej stronie serwisu. To taka namiasta Planety, czyli agregatora różnych blogów. Po zamknięciu Joggera i wielkim rozproszeniu joggerowców, powstała nowa planeta zrzeszająca osoby stamtąd.

Jak to bywa na początku, poza wpisami testowymi nie wiedziałem za bardzo o czym blogować. Próbowałem recenzować oglądane filmy, eksternalizowałem przejścia na uczelni, próbowałem ''polemiki w internecie''. Generalnie bez większych sukcesów. Najbardziej chyba podchodziły mi wpisy techniczne. Może bez konkretnych tematów, ale mam nadzieję pomocne, gdy któryś zostanie komuś wskazany przez wyszukiwarkę.

Dekadę temu miałem okres, gdy ucząc się nowej technologii robiłem tak jakby jakby notatek. Mi to się przydało – pomagało w sensownym ułożeniu nowej wiedzy, natomiast dla innych użyteczność była znikoma.

W miedzyczasie zostałem deweloperem Fedora Linux, która również ma swoją planetę. Aby tam publikować zacząłem czasem pisać po angielsku, notki są oznaczone odpowiednim tagiem.

Nigdy nie dałem rady publikować regularnie. Jakiś czas temu próbowałem utrzymać tempo co najmniej jednego wpisu miesięcznie, ale nie udało się. Chociaż zawsze jest o czym pisać, to Dunning-Kruger wchodzi mocno. Jak coś poznajemy, to na początku często jest euforia. Super, świetna sprawa, świat musi się o niej dowiedzieć. I wtedy łatwo pisać. Z czasem wchodzą refleksje. E, dopiero to poznaję, na pewno jest mnóstwo wpisów specjalistów w tej dziedzinie (pewnie nawet je właśnie czytam ucząc się), bez sensu pisać.

Wtedy trzeba sobie uświadomić, że w każdej chwili jest dużo osób które są na początku naszej drogi. I dla nich zasygnalizowanie jakiegoś tematu jest cenne, daje punkt zaczepienia i może stać się początkiem niezłej przygody. Z myślą o nich warto pisać.

Podsumowując. Przegladając moje wpisy z dwóch dekad łatwo znajduję takie, do których bym się nie przyznał. Zwłaszcza te z G+. Pokazywanie, że się ma silne opinie nie polega na byciu opryskliwym. Brak szacunku dla innych nie jest oznaką niczego dobrego. Na szczęście przeszło mi to lata temu i z nowszych notek jestem zadowolony.

A Ta notka powstawała przez prawie pół roku, chyba najdłużej ze wszystkich dotychczasowych. 2,5% czasu istnienia bloga :) 20 lat temu byłem studentem. Teraz pracuję. Za 20 lat będę dalej pracował, chociaż za rogiem będzie już emerytura. A czy będzie jeszcze kolejne 20… to się zobaczy.

Dzisiaj napiszę o sieciach (mój konik), problemie z opóźnieniami i dwóch rozwiązaniach (krótko- i długoterminowym).

I've migrated my home server to boot using UEFI. It means suprising number of things:

• I did something useful during my unplanned PTO days

• Fedora's GRUB instructions are useful and precise

• I was really wrong in my rant couple years ago. Although I had to switch firmware into Windows 8 (no CSM) mode today.

• the server is ready for modernization later this year, the upgrade of fives: some AMD Ryzen 7xxx (AM5 socket), DDR5, PCIe5. Packed in a SSUPD Meshroom S case. Getting back to the integrated GPU and hopefully lowering power consumption (now it idles at around 90W🙁)

• I can unsubscribe from BIOS Boot SIG, as this was my last legacy-booting computer. The SIG mailing list is completely empty, apparently all the ruckus with needing BIOS booting within Fedora has no real standing.