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

19.2.2017 14:28 | Přečteno: 2481× | GNU/Linux | | poslední úprava: 19.2.2017 19:02

Dnes to bude jen takový telegrafický zápisek: o tom, jak spouštět javovský aplikační server PayaraFish (dříve GlassFish) pomocí systemd a o tom, jak přejmenovat šifrovaný disk, aby nám systém taky ještě někdy naběhl, a na závěr ještě pár slov o novém-starém IBM ThinkPadu.

systemd a PayaraFish

Instaloval jsem nový aplikační server a místo abych donekonečna oprašoval svůj starý init skript, tak jsem ho konečně přepsal do systemd. Stručný postup:

Vytvoříme si v systému uživatele payara a v jeho adresáři rozbalíme ZIP stažený z webu autorů. Vytvoříme si soubor: /etc/systemd/system/payara.service s obsahem:

[Unit]
Description = PayaraFish
After = syslog.target network.target

[Service]
User=payara
ExecStart   = /usr/bin/java -jar /home/payara/opt/payara41/glassfish/lib/client/appserver-cli.jar start-domain
ExecStop    = /usr/bin/java -jar /home/payara/opt/payara41/glassfish/lib/client/appserver-cli.jar stop-domain
ExecRestart = /usr/bin/java -jar /home/payara/opt/payara41/glassfish/lib/client/appserver-cli.jar restart-domain
Type = forking

[Install]
WantedBy = multi-user.target

Poznámka: v některých návodech se můžete setkat s ExecReload místo ExecRestart, ale to nefunguje, protože příkaz restart-domain ukončí proces a spustí nový (nejde o pouhé znovunačtení konfigurace) a systemd si pak myslí, že služba spadla.

Povolíme a spustíme službu:

systemctl enable payara.service
systemctl start payara.service

Oproti starému init skriptu je to jednodušší a deklarativnější (je to víc konfigurák než skript). A init systém má lepší přehled o spuštěné službě:

# systemctl status payara.service
● payara.service - PayaraFish
   Loaded: loaded (/etc/systemd/system/payara.service; enabled; vendor preset: enabled)
   Active: active (running) since Ne 2017-02-19 13:02:54 CET; 24min ago
  Process: 2735 ExecStop=/usr/bin/java -jar /home/payara/opt/payara41/glassfish/lib/client/appserver-cli.jar stop-domain (code=exited, status=0/SUCCESS)
  Process: 2759 ExecStart=/usr/bin/java -jar /home/payara/opt/payara41/glassfish/lib/client/appserver-cli.jar start-domain (code=exited, status=0/SUCCESS)
 Main PID: 2774 (java)
    Tasks: 63
   Memory: 266.4M
      CPU: 13.872s
   CGroup: /system.slice/payara.service
           └─2774 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -cp /home/payara/opt/payara41/ \
           glassfish/modules/glassfish.jar -XX:+UnlockDiagnosticVMOptions -XX:NewRatio=2 -XX:MaxPermSize=192m -Xmx512m -client -javaagent:/home/payara/opt/pa

úno 19 13:02:50 localhost-1 systemd[1]: Starting PayaraFish...
úno 19 13:02:54 localhost-1 java[2759]: Waiting for domain1 to start ...
úno 19 13:02:54 localhost-1 java[2759]: Successfully started the domain : domain1
úno 19 13:02:54 localhost-1 java[2759]: domain  Location: /home/payara/opt/payara41/glassfish/domains/domain1
úno 19 13:02:54 localhost-1 java[2759]: Log File: /home/payara/opt/payara41/glassfish/domains/domain1/logs/server.log
úno 19 13:02:54 localhost-1 java[2759]: Admin Port: 4848
úno 19 13:02:54 localhost-1 java[2759]: Command start-domain executed successfully.
úno 19 13:02:54 localhost-1 systemd[1]: Started PayaraFish.
úno 19 13:03:06 localhost-1 systemd[1]: Started PayaraFish.

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.

A teď už můžeme vesele nasazovat naše Java EE aplikace poskytující data z SQL databází, transformující XML dokumenty XSLT šablonami a řízené EJB a JMS za pomoci továren a proxy tříd :-)

Přejmenování šifrovaného disku

Dělal jsem si pořádek v discích v počítači a trochu je i fyzicky přerovnával a při té příležitosti (a souvisejícím restartu) jsem si chtěl dát do pořádku i pojmenování šifrovaných disků – jeden disk se jmenoval /dev/mapper/sda3_crypt (což vzniklo kdysi při instalaci systému) a chtěl jsem, aby měl logičtější název.

Š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. Tušil jsem, že to nebude stačit jen tak přepsat v tomto souboru, a update-initramfs -u mi dal za pravdu, když vypsal varování, že sda3_crypt nemůže najít v konfiguráku. Systém by pak nenaběhl a museli bychom ho opravovat pomocí živého CD a chrootu.

Tak jsem raději hned nerestartoval, nahodil ještě Xka a WWW prohlížeč a zjistil, co je potřeba – (de)šifrovaný disk musíme přejmenovat v ještě běžícím systému:

dmsetup rename sda3_crypt ssd120_crypt

A pak potřeba přegenerovat všechny initramfs:

update-initramfs -c -t -k all

Běžně dávám jen volbu -u, ale kdybych chtěl náhodou spustit starší jádro, tak by mi nefungovalo. Dále bylo doporučeno aktualizovat GRUB (update-grub), ale to v mém případě nebylo nutné.

IBM ThinkPad X61 Tablet

Většinou používám stolní počítače a jako notebook jsem si před časem koupil ThinkPad X230. ThinkPadům jsem přišel na chuť a teď jsem přikoupil do sbírky ještě X61 Tablet. Je zajímavé, že i po tolika letech je to pořád dost dobře použitelný HW a v podstatě jediný problém je výdrž baterky – jinak by to šlo používat na většinu práce i dneska. Navíc v dokovací stanici má i paralelní port, což se může hodit pro komunikaci s různým hardwarem… Co mne trochu zklamalo, je zamrzání systému při použití stylusu (dotaz, chyba). Pokud máte taky X61 nebo podobný tablet, dejte prosím vědět, v jakých distribucích a verzích vám to funguje a v jakých ne, případně nějaké tipy na ladění a opravu.

       

Komentáře

[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.