Mikroblog #7: systemd+Payara, přejmenování šifrovaného disku (diskuse)

[Max]

Díky za tip na PayaraFish. Původně jsem přemýšlel, že od Glassfishe uteču k WildFly.
Zdar Max

[⧠ A = 0]

Já mám (už tak dva–tři roky nepoužívaný kvůli největší slabině tabletových thinkpadů, jíž je pant obrazovky) x61 tablet a problémy se zamrzáním jsem nikdy neměl. Kde to jde, používám debian, takže určitě jsem tam měl squeeze, možná i wheezy.

[pc2005]

Napsal jsem zprávu do té poradny. Nebo to chceš řešit tady?

Škoda, že ten X61 už má nejspíš ten intel remote management procesor .

BTW pro [TX]6[01] Thinkpady se prodával paralelní port dokonce do toho minidocku (jak je v něm DVD mechanika, baterka nebo disk).

[xkucf03]

Napsal jsem zprávu do té poradny. Nebo to chceš řešit tady?

To zamrzání v poradně, kouknu na to…

BTW pro [TX]6[01] Thinkpady se prodával paralelní port dokonce do toho minidocku (jak je v něm DVD mechanika, baterka nebo disk).

Co je minidock? Notebook samotný prostor pro mechaniku nemá, je tam jen disk. A v dokovací stanici je optická mechanika (případně baterka nebo disk) a porty: paralelní, sériový, USB, zvuk, síť.

BTW: nezkoušel jste někdo paralelně k originální baterce připojit další články (4× nebo 3× 3,7 V podle typu) a prodloužit její výdrž? Připojit jen zdroj (bez nějaké elektroniky) na kontakty pro baterku nejde (notebook se sice zapne, ale hlásí chybu baterie). Ale pokud by tam originální baterka byla, tak by to mohlo prodloužit její výdrž – prostě by se vybíjela pomaleji (akorát by tam nesměl být moc velký rozdíl napětí, aby nešlo moc proudu z jedné baterky do druhé).

Případně by šlo si udělat powerbanku, která dá cca těch 20 V, a zapojit ji místo zdroje, ale tam budou větší ztráty.

[pc2005]

Já jsem to našel pod víc názvama, minidock je asi blbost no. Nebo ten x61 nemá slot, ve kterým je mechanika? Ja teda x61 nemám mám t60p, ale tyhle řady mě přišly stejný.

... Jo na thinkwiki se to nazývá ultrabay. Podle modelu v tom jsou LPC piny, PATA piny a power piny.

Baterie by šla rozšířít (i v tom ultrabayi), pro t60p se dokonce prodávaj až třířadý (možná až čtyřřadý) moduly (to pak 1-2 řady vyčuhujou za hranu). Ale mám dojem, že x6x řady maj jinej formát akupacku. Jinak připojit další řadu tam teoreticky můžeš, ale je problém že v tý baterce je MCU, ve kterým budou údaje o kapacitě (a asi jako dlouho se má nabíjet). A hlavně ten MCU je od výroby pořád po proudem a když ho od toho akupacku odpojíš tak může na některých modelech zapomenout důležitá data (na YT jsou videa jak ho přemosťujou na externí power při výměně článků za nový). Pak taky s větším akupackem to bude těžký jako kráva.

P.S. Dokonce se ke thinkpadům dá sehnat schéma .

[xkucf03]

T řada je o dost větší – X má jen 12 palců a optická mechanika tam fakt není. Na druhou stranu ty dokovací stanice nejsou jen na stůl – někteří lidé to s tím i nosí :-) Pak je to prostě takový tlustý notebook.

A hlavně ten MCU je od výroby pořád po proudem a když ho od toho akupacku odpojíš tak může na některých modelech zapomenout důležitá data (na YT jsou videa jak ho přemosťujou na externí power při výměně článků za nový)

jj, o tom jsem taky slyšel, je potřeba to držet pořád pod proudem. Uvažuji, že bych to udělal u té X61 Tablet baterky – koupit nové ploché články a dát je tam. Teď má výdrž asi jen hodinu.

... Jo na thinkwiki se to nazývá ultrabay. Podle modelu v tom jsou LPC piny, PATA piny a power piny.

V tom mém docku k X61 je PATA a napájecí konektor – takže bych si mohl vyrobit i dodatečnou baterku (ty originální stojí asi šest tisíc, pokud je vůbec někde ještě mají), protože tu mám jednu neznačkovou, ve které odešel jeden článek – šla by z ní použít ta elektronika – počítám, že Číňani tam tu ochranu proti odpojení neimplementovali.

X230 už má jen SATA.

[pc2005]

Ono těch T60p bylo víc typů já mám menší úhlopříčku (cca 14").

Jo aha takže dock pro x61 má v sobě ultrabay? Radši budu používat názvosloví z thinkwiki, ten "dock" jsem našel jen na činskejch prodejcích z ebaye .

Tak baterku v ultrabayi nemám, asi bude slabší než ty klasický 18650 články v hlavní baterce. Podle schématu k T60p má prakticky stejnej konektor jako hlavní baterka, tedy i s I2C komunikací do EC MCU (u mě H8S hitachi). Takže bych řekl, že pokud ten EC nedostane správnou komunikaci, tak ty baterky nepřepne.

Jinak ultrabay baterky se prodávaj a nejsou zas tak drahý (ale je jich kotel typů (viz thinkwiki). Jestli máš nějakou s odpáleným článkem, tak by možná fakt stačilo ten článek vyměnit a modlit se že ten MCU v acupacku bude OK .

P.S. Jinak když jsem vyměnil článek v akupacku Magiciana, tak po čase málem shořel (dával jsem pozor a včas jsem odpojil li-ion od elektroniky, už byl horkej). Ale ta elektronika byla už načatá a byla neoriginální (kde PIC fejkoval data z originálního nabíjecího ASIC čipu). Ten PIC fungoval jako zkrat článku (taky napájenej i když je akupack mimo mobil) .

[kralyk z abclinuxu]

Šifrované disky jsou definované v souboru /etc/crypttab a typicky tam máte název (de)šifrovaného zařízení (to, co pak bude v /dev/mapper/) a UUID šifrovaného oddílu.

To záleží na konfiguraci. Mam šifrováno komplet všechno v konfiguraci LUKS on LVM a v crypttab nic nemám. Jméno pro mapper je určeno boot parametrem kernelu.

Mimochodem, to jméno pro mapper není vůbec podstatné, mam tam něco jako "lvm" nebo takněco.

Důležitější jsou třeba jména LVM volume groups, particí v GPT a podobně. Takhle si typicky vytvářim dvojice pojmenované stylem Jekyll & Hyde, Fred & George a podobně, které navzájem zálohuju (vždy jeden je nasazen k použití a druhý je záložní, jsou ale zcela prohoditelné, takže když např. přestane fungovat Jekyll, nahradim Hydem a koupím nový Jekyll, na který re-zálohuju data).

[xkucf03]

Já to mám:

Btrfs
LVM
LUKS
MD RAID
HDD+HDD

Případně:

Btrfs
LVM
LUKS
SSD

Šifrovat až nad LVM se mi nechtělo jednak kvůli RAIDu a jednak kvůli tomu, že by byly vidět názvy oddílů, jejich počet a velikost. A pak na to nemusím myslet, můžu si vytvářet LV, jak chci, a vím, že všechno už je šifrované. Na druhou stranu si pak člověk může udělat snadno nešifrovaný oddíl třeba pro nějaká dočasná data, když to má jako ty (ale na to používám spíš další disky).

[kralyk z abclinuxu]

Já jsem to samozřejmě napsal blbě, mam taky LVM on LUKS ...

[Bedňa]

systemd mj. zná ID procesu, pod kterým běží služba (ne jen příkazu, který ji spustil), a není to jen nějaký zdivočelý démon běžící kdesi na pozadí, o kterém systém nic neví a nemá ho pod kontrolou.

Bez toho, že by ma zrovna táto téma zaujímala, naozaj nieje možné v Linuxe zistiť hocijaký proces ktorý niekde beží bez sytemd? Nejak sa ta bariera v tom našom Linux enviroment stále prehlbuje a musím povedať objektívne, že to ide len z jednej strany.

PS pre redakciu: Furt ma to neskutočne vytáča a popísalo so o tom dosť ako nasierate užívateľov. Nedokážem si ani skopírovať text aby som neklikol kde nechcem. Bolo to odstránené a už dlhý čas je to späť.

[xkucf03]

naozaj nieje možné v Linuxe zistiť hocijaký proces ktorý niekde beží bez sytemd?

Vypsat si běžící procesy samozřejmě můžeš, taky si je můžeš nějak organizovat na základě názvu binárky, uživatele atd., ale většinou nebudeš vědět, odkud byl ten proces spuštěn (jestli ten démon vzešel z init skriptu, nebo ho pustil někdo bokem). Nebo obráceně: zjistit, jaké všechny procesy byly spuštěny při startu nějaké služby. Systemd o tom má přehled AFAIK díky cgroups – což nebrání jiným init systémům to dělat taky, ale jinde jsem to takhle pěkně neviděl.

[Josef Kufner]

Ono když se ten proces utrhne z terminálu a zbaví se rodičů, tak se jeho původ zjišťuje blbě. Staré SysV init skripty si uložily PID a doufaly, že až se bude ukončovat, tak že ten proces bude ještě ten samý a naživu. A kdyby nebyl, tak to nezjistí, ani nemají pořádně jak.

Systemd a ostatní supervizory to řeší mnohem lépe. Proces spustí bez ošklivých triků. Supervizor zůstane rodičem, dostane signál, jakmile proces skončí, a navíc může jeho výstup ukazovat uživateli a posílat do správného logu (obzvlášť když se časem log odrotuje).

Systemd jde ještě o kousek dál a procesy si hlídá pomocí cgroups, takže uhlídá i ty zvrhlé staré blbosti a nějaký druhý či třetí fork ho nerozhodí.

Kdysi dávno se na startování služeb používal inttab, kde se vyjmenovaly procesy a init je nastartoval na pozadí podobně, jako to dnes dělá Systemd. Jenže to nějak zapadlo, nemělo to žádné API a vůbec to bylo takové moc hloupoučké. Na druhou stranu to byl dobrý způsob, jak startovat šikovnějšího supervizora vedle jinak minimalistického initu. Potíž pořád ale byla v tom, že pokud by supervizor upadl, tak už procesy neposbírá, neboť cgroups nebyly, a systém šel do kytek tak jako tak. Takže namísto minimalistického initu s obskurním a omezeným API máme o trochu větší init s docela použitelným DBus API.

[Bedňa]

Chalani, cgroups pokiaľ viem, nič so systemd nemá (nemal pri vzniku), áno systemd robí kopec vecí automaticky, unifikovane, chrumkavo, ale kto im o to stojí :)

[Josef Kufner]

Cgroups vznikly o cca 4 roky dříve než Systemd. Systemd cgroups používá. To je celé.

[Matlák]

PS pre redakciu: Furt ma to neskutočne vytáča

Dej si do userscriptu tohle:

var jobsAds = top.document.getElementsByClassName("jobs-ad-logo");

for ( ix in jobsAds ) {
    jobsAds[ix].style.width = '100%';
}

zatím to funguje.

[Josef Kufner]

Nebo si v profilu nastav vlastní CSS: #ls { overflow: hidden; }

[Max]

Opraveno a nasazeno.
Zdar Max

[Max]

Ahoj, zpět je to od doby migrace. Na nový server jsem nasadil verzi abc, která byla v gitu, aby byla jistota, že to co je nasazeno 100% odpovídá tomu, co je v gitu. Zřejmě nebyly nějaké změny commitovány, takže po migraci se něco vrátilo zpět.
Zdar Max

[Matlák]

Zřejmě nebyly nějaké změny commitovány,

Typický problém. Doporučuju všechno nejdřív commitnout a pak nasazovat na server přes CI (ale to bych tady, doufám, učil orly lítat).

[Bedňa]

OK, dík.