Lennart Poettering (autor systemd) v sobotu na Mastodonu napsal, že poučením z CrowdStrike by mělo být používání automatického záložního bootování, jaké například představuje Automatic Boot Assessment v systemd.
Podpora pro Automatic Boot Assessment je v systemd již dlouhou dobu, avšak distribuce ji nepoužívají (výjimka je snad jen NixOS). Lennart si ještě postěžoval, že distribuce obecně moc nedbají na bezpečnost, například stále nepodepisují initrd.
(zdroj: phoronix)
navic ani zpravicka nesouvisi s systemd initem, ale s systemd-boot bootloaderem ;-)
když už není heavy samotný linux, tam systemd je za mě zajímavá volba, umí to startovat rychle, dobře se to testuje, read-only rootfs není problém. Máme image, kde běží 4 služby, celkově 12 procesů, start máme za 5s (2s kernel, 3s userspace, multi-user.target je firovaný do 3s) na něčem, co je srovnatelné asi rpi.
A proč používat takhle těžkotožání věci? Hlavní důvod za mě je asi schopnost se snadno integrovat s existujícím ekosystémem na vývoj, snadno dělat image, velké množství lidí dostupných na linux, dobré podmínky pro testování na vm.
Věci jako systemd-analyze blame, kontrola služeb, jednotné kolektování logů prostě ulehčují práci. Ne vždy jsou embedded malé knoflíky, někdy to je poměrně výkonný strojek a priorita není ušetřit watty, ale zvýšit spolehlivost (to nejen běhu, ale i se vyvarovat chyb při vývoji).
to ale asi není nějaká obecná certifikace, ale jedná se o soulad s provozními pravidly jak má nějaká instituce interně stanovené, ne?
Je běžné, že každá firma má nějaké jiné vnitřní podmínky a best practice, támhle musím mít služub X, támhle musím být tenhle repositář nebo tuhle distribuci, támhle musím dodržet tyhle pravidla pro konfiguraci nebo automatizaci, támhle musí takhle vypadat audit log, tady zase musí mít všechny logy tenhle formát atd.atd.
Rozdíly jsou docela běžné, přidělává to ale zbytečně práci se někam integrovat.
Tak... co je dneska "embedded"? Může to být cokoliv od termostatu s wifinou až po 4K reklamní signage panel s GPU akcelerací. Na něco z toho je systemd overkill, na něco ne.
Systemd moc prostředků nežere, obrovsky pomáhá ukočírovat dynamičtější konfigurace (různě se měnící sítě, storage, periferie), má dobrou instrumentaci, použitelnou dokumentaci, a obří pool lidí ze kterého jde brát odborníky, protože se to používá všude. Dneska je snadnější postavit embedded team z lidí co dělají NixOS a systemd než nějaké buildroot nebo yocto.
Zajímavé. tohle zabezpečení je na takovém místě, aby se nešlo jen tak dostat na systému mimo schválený postup. A řešením je toto zabezpečení obejít. Pak tedy je původní zadání ok nebo chybné?
V jedné diskusi (https://krebsonsecurity.com/2024/07/global-microsoft-meltdown-tied-to-bad-crowstrike-update/#comments) se píše ...
I am a Certified Healthcare CIO, so I have years of background working in this field. There is a lot of friction between the “new” generation of IT Leaders and my generation of IT leaders. My generation has always focused much effort on testing and regression testing of code and patches, the result being longer patch cycles. New DevOps teams want to patch more often with less testing. Both approaches have their pros and cons. This is an example of the “old” way of testing being more appropriate. In my world, if we had 10 variants of Windows Operating Systems (Windows 10, release xxxxxx, Windows 11, release xxxxxx), I would require 1000 tests to be run, 100 on each variant, before we released to PROD. In todays DevOps world, it is common to minimize testing, and just fix “whatever breaks” on the backend, after-the-fact. The reality is that we need to meet in the middle between these two processes and come up with something that prevents this from happening
There is truly no excuse for this. IMO, the CIO, CTO, and the CEO needs to be held accountable for this, as this is one of the most basic process issues of any technology department, much less a technology company.
