Názory k článku Linuxový desktop a migrace dat mezi počítači

Znám lidi, kteří utilitou rsync přesunou obsah celého disku na nový počítač

patrim mezi ne :-) pokud do noveho NB nejde strcit puvodni disk, nebo chci vetsi, nebo jen stejnej system do zalozniho/tes­tovaciho nb, pripravim v Live disk (EFI+LUKS oddil, nad LUKS LVM), naklonuju pres rsync jednotlive LV, upravim v /etc host,hostname,fstab,cryp­ttab,cmdline, UUID pro resume, regeneruju initramfs, nainstaluju zavadec a rebootnu do naklonovaneho systemu :-)

Je fascinující kolik věcí je potřeba upravit, aby šlo systém s LVM/LUKS spustit na novém disku... nechceš uveřejnit návod? :)
Já když se o toto naposledy pokoušel, tak jsem to nakonec vzdal, že bude rychlejší nainstalovat nový systém :D

to co sem psal upravit, v podstate s LUKS a LVM nesouvisi :-)

navic pokud bych klonoval po siti disk v jendom nb na disk v druhem nb, muzu v cilovem udelat stejne nazvy odemknuteho LUKS, nazev LVM VG, EFI oddil se stejnym UUID a zmenit jen hostname :)

pro prehled ty soubory co sem pretim psal:

host, hostname - obsahuje jmeno stroje
fstab - obsahuje nekolikrat /dev/vgname/lvname + EFI UUID
crypttab - obsahuje UUID oddilu na kterem je LUKS a jmeno pod kterym LUKS odemkne
cmdline - pouzivam sicherboot (nad systemd-boot) a v /etc/kernel/cmdline je root=/dev/vgna­me/lvname pro rootfs a dalsi parametry startu co se u Grubu davaji do /etc/default/grub
UUID pro resume - soubor /etc/initramfs-tools/conf.d/resume - obsahuje UUID swapu, vlastne ani ted nevim zda je potreba kdyz v cmdline mam resume=/dev/vgna­me/swap :)

já to dělám tak, že mám virtuální stroj, ve kterém pracuju. Pak je mi prakticky jedno, na jakém fyzickém stroji to mám a na jakém OS běží... Když mi chcípl notebook, tak jsem to přesunul na desktop, a pracoval jako obvykle, pak jsem notebook opravil, a virtuálku přesunul zpátky.
Nic jednoduššího jsem zatím nevymyslel :)

To je hezké, ale jen jste problém posunul o jednu cibulovou vrstvu dál.
Po čase totiž může být potřeba reinstalovat onu virtuálku - a jste zpět u přesouvání aplikací a domovských adresářů. Jen to bude jednodušší, použijete-li stejný hardware (tedy virtualizační software).

No to jsem naštěstí za těch 10 let zatím nepotřeboval, ale máte pravdu že to asi jednou přijde :(
Kdysi jsem měl takhle upravený stripnutý OS ve virtuálkách specificky pro každou práci na které jsem dělal, a teď posledních 7 let u jednoho zaměstnavatele dělám pořád to samý, takže jsem nic měnit nemusel, pořád stejná práce, pořád stejné prostředí, takže mě do žádné změny nic nenutilo.

v jednom pripade som to posunul na vyssi level: takuto VM mam zriadenu na firemnom hoste :)
Brutalna vyhoda, ze je ze nic neopusti firmu a keby ma presiel vlak, tak je tam "vsetko".

Co sa tyka zivotnosti, uz to zije tiez roky a nevidim dovod preco by ma to nemalo prezit.

Zrovna nedávno nám dodavatel prezentoval novou versi aplikace. Na obrazovce měl Windows s prezentací v PowerPointu, přes VPN se připojil do firmy na Windows Terminal server, tam spustil virtuálku s Windows, v té PuTTY - a připojil se na virtuálku s Linuxem, kde byla ta aplikace.
Kouknu pozorněji: a ten PowerPoint byl ve Windows, běžících jako virtuálka na notebooku s Linuxem!
(Protože jejich firma má politiky pro Windows, a Office 365 na všechno,)

Znam lidi jako ja kteri presouvaji pres dd na vetsi disk:-) a pak uz jen resi narychlo hranice partisny+expand fs. Ted s EFI snad ani grub resit netreba pokud si dobre pamatuji.
SSD mne asi za to ma po prvnim zapise trochu mene rado, ale SSD je stejne spotrebni zalezitost. Driv umre na moje brutalni pouzivani nasledne.
Desktop je posledni vec se kterou se chci tentovat a venovat tomu prilis casu. Kriticke veci jsou naskriptovane a sdilene v tymu tak jako tak.

23. 8. 2023, 10:52 editováno autorem komentáře

Stinná stránka kopírování je, že po pár letech vzniká naprosto jedinečný a neopakovatelný systém. Je to pohodlné jenže jak se to podělá tak se to podělá. Dlouhodobě se mi osvědčila varianta přesně opačná, ne něco opatrovat, ale mít postup jak to znova vytvořit. Takže git, v něm změny konfiguráků, script s apt, pár poznámek a hotovo víc není co migrovat. Funguje to na serveru funguje to na desktopu. Pokud to dělá člověk pro sebe nepotřebuje to mí ani blbuvzdorné ani automatizované a jako bonus má přehled co je kde změněné. Funguje to na serveru funguje to na desktopu.

Súhlas, miesto kopírovania konfigu zo starého počítača, radšej mať script, ktorý zmení konfig na novom do podoby, ktorú chcem. Navyše to vyrieši určité problémy, ako keď v novom systéme sa zmení štruktúra config súboru pre konkrétny software, čo prepísaním môže daný software úplne znefunkčniť. A na migraci dát / súborov, jednoducho obnova z duplicity (ktorý mi mimochodom zálohuje práve aj kľúče, certifikáty a mnoho ďalšieho, čo tu autor rieši a nevyriešil).

22. 8. 2023, 11:43 editováno autorem komentáře

Presne tak. Rucne zkopiruju skript, ktery nainstaluje co je potreba, nastavi co je potreba a pres syncthing nataham vlastni data na novy pocitac. A mam 1:1 kopii toho co jsem mel predtim, co mam na desktopu, notebooku ci jinde. Nektery potrebny soft si kompiluju sam a to si syncthingem nataham taky.

To sem zvedav, jak s timhle systemem resis, ze se ti zmeni verze, a tvuj konfigurak (a jeho zmeny) je zcela nefunkcni.

Skopirovat to cele je mnohem jednodussi.

Tohle se mi nestává (viz příspěvek níže). Nicméně vyresetovat konfiguraci v Gitu nebo updatovat na nový formát by mělo jít taky, ne?

Jenze kdyz menis system, zmeni se ti typicky verze ze? Kdyz skopirujes system, nemeni se nic.

A je poreba rict, ze v mnoha pripadech ani stejna verze systemu (jak tu i zaznelo) neznamena stejny system. Napriklad muzes mit ve stavajicim systemu nejaky link, ktery tam vznikl pri nejake aktualizaci a v novem uz nebude ... s cimz tvoje konfigurace nepocita a odkazuje se pres ten link.

Jasne ze na to asi prijdes, protoze neco nebude fungovat, ale rec je tu o tom, ze se chces presunout, pokud mozno efektivne a rychle, na novy HW. Takze asi nechces resit, co kde prestane fungovat.

Treba prepis konfigurace = klidne i nekolik hodin zkoumani toho, jak se to ci ono "ponovu" dela. Priklady? Co ja vim trebas postfix, kde se s verzema ruzne meni i bydefault chovani ... ale da se zachovat prave uvedenim verze do konfiguraku. Nebo treba strongswan, kde mas dva diametralne odlisny zapisy, pricemz zatim jsou teda +- podporovany oba.

Kdyz nainstalujes novy system, typicky se predpoklada, ze konfigurace a vse ostatni bude reflektovat aktualni doporuceni, a tudiz tam jaksi budou chybet ty veci, ktere treba na stavajicim systemu umoznuji pouzivat starsi verzi konfigurace.

Zcela obecně souhlasím. Empiricky moc ne. Když používám stejný systém, stejně si povyšuju verze různých aplikací, ať už přímo updatem v dané distribuci nebo z PPA, instalací ze zdrojů (make/cmake nebo pip nebo cargo install nebo cokoli) a konfiguraci už tam pro starší verzi mám a je na aplikaci, aby se s tím vyrovnala.

Většina aplikací to dává, princip je úplně stejný, když jsem přecházel třeba z LTS 20.04 na 22.04. Jasně, může se stát, že nějaká aplikace se rozhodne něco radikálně změnit a legacy formát neřešit, ale to je život. Jenže já upgradovat chci a dělám to tak, že si na jednu partition nainstaluju novou verzi, přepíšu si domovský adresář z původního a pokud vše alespoň trochu funguje, řeším detaily za pochodu. A věci v /etc, typicky právě ten postfix nebo třeba cups, řeším opatrným srovnáním starého a nového. U většiny věcí to je v pohodě. Kdybych zjistil, že mi nejede nějaká per user konfigurace, jasně že bych mohl konfiguraci z nového systému vyresetovat a pak řešit, co změnit.

Pokud jde o přenos systému na systém (jiný stroj bez přístupu k původním oddílům), hodí se mít starý home a etc někde po ruce ve formě tarballu. Největší quest je stejně pročistit si napřed cache browserů, Downloads od velkých ISO souborů a jiných bloatů, domácí tmp od buildů apod. Což se hodí tak jako tak.

Dělám jen jednu věc současně, buď přecházím na novou verzi nebo na nové železo.

Keď volám kopec príkazov pre nastavenie tak to už počíta s danou štruktúrou. A ak použijem kľúč, ktorý neexistuje v novej verzii alebo bol zmenený tak to failne nastaviť dané nastavenie, ale software naďalej funguje. Trebárs `gsetting` či `dconf write` je bezpečnejší než proste nakopírovať súbor. Od toho to API tam aj je. API je štandardizované, ale interná štruktúra je menná. Ak sa API mení, tak máš okamžite o tom informáciu, a navyše sa nemení rovno, ale je tam medzi-verzia kedy to upozorňuje že je to "deprecated". O inštalovaní programov "kopírovaním" ani nehovorím. `apt install xyz` vždy korektne vyrieši dependencies a nainštaluje program správne, ale skopírovanie súborov programu to takmer vždy skončí fiaskom.

22. 8. 2023, 19:50 editováno autorem komentáře

Já se teda hodně málokdy potkávám s tím, že by se Linux „podělal“ tak že by to nešlo rozumně opravit -- v nejhorším se dají třeba auditovat všechny změněné soubory na FS oproti balíčkovacímu systému. A pokud se něco podělá, tak je to právě konfigurace, bohužel často třeba konfigurace desktopového prostředí, která není textová, takže se to blbě verzuje tebou popsaným způsobem (ano, kdybych používal třeba Fluxbox, tak tam je konfigurace jednoduchá a textová; větší WM/DE bohužel mají složitou). Nebo třeba konfigurace Firefoxu a Thunderbirdu, což je neuvěřitelná změť sqlite souborů a jsonů :(.

Tak to podelani-se je asi pritazene za vlasy, ale spis se po case - pri nevhodne udrzbe - zacnou hromadit na disku zbytne knihovny z balicku, co nic nedstranilo :-) A jinak git zvladne verzovat i binarni bloby, ze neco neni v textaku asi neni uplne neprekonatelny problem... pro potreby eventuelniho rollbacku to rozhodne je dostacujici (kdyz preskocim to, ze tohle vyresi i snapshot filesystemu). A treba u toho Firefoxu skutecna konfigurace zas takovej brutus neni, to ze v tech sqlite/jsonech jsou i dalsi veci vc. treba historie je vec, ktera se pri nejhorsim asi obetovat da (vlastne je i dobry je tu a tam procistit, co si budem povidat - sqlite neni uplne genialni databaze, kdyz toho obsahuje v sobe vic).

> pri nevhodne udrzbe - zacnou hromadit na disku zbytne knihovny z balicku, co nic nedstranilo

Já občas procházím balíčky, na kterých nic nezávisí. A občas tak odstraním něco co ve skutečnosti bylo důležité a pak mi nefunguje počítač :)

"Já občas procházím balíčky"

Trebas gentoo pri cisteni (emerge --depclean) pravidelne odstranovalo nano, coz byl ovsem jediny systemovy editor ... a delo se to tak roky, protoze panove nebyli schopni to do tech zavislosti pridat.

Nevim jestli se to deje porad, dost dlouho sem neinstaloval zadnou novou instanci, u tech starsich to mam samozrejme poresene po vlastni ose.

A neni to jediny takovy balicek.

ja zas delam, ze jakmile neco menim v /etc tak puvodni soubor zkopiruju na miste do *.orig, takze pak snadno dohledam kde a co sem zmenil, pokud soubor pridavam tak dam "touch nazev.orig" tedy bude tam s 0 size...

Zajímavé téma, které jistě zajímá spoustu uživatelů. Předesílám, že jsem letitý uživatel Ubuntu a tím pádem možná moje zkušenosti jsou jiné, než zkušenosti uživatelů Fedory, ale neodpustím si dvě poznámky:

1. Zvyknul jsem si přenášet celý domovský adresář a to i při přechodu na vyšší verzi systému. Aplikace instaluju normálně. Konfiguráky fungují obyčejně úplně normálně, pokud aplikaci nenainstaluju, není konfigurace potřeba, ale jelikož workflow mám pořád dost stejné, je otázka času, kdy nainstaluju aplikaci přes apt a bude tam. Výhoda flatpaku tudíž pro mě při přenosu je prakticky nulová.

2. Nikdy bych v dnešní době podobné věci neřešil shell scriptem, zvlášť pokud bych se systém snažil časem rozšiřovat, řešit robustnost, případně třeba časem přidat nějaké rozumné UI apod. Je to fakt nutné? Nechci vyvolávat flame war, ale fakt to nechápu.

2) Jirka se myslím UI rozhodně nebrání. :-) Shell script je takový proof-of-concept a výhodou bych řekl, že entry-level je díky tomu nízko pro nějaké rozumné rozšíření.

I Toolbx byl ze začátku jen shell script a pak se to přepsalo do Go, protože to je úzce provázané s Podmanem, který je napsaný v Go a má pro něj API. Myslím si, že pro rychlý vývoj proof-of-concept zvlášť u nástrojů, které integrují řadu dalších nástrojů, to dává smysl. Možná, že dál se to ani nikdy nedostane. Ten shell script má zase tu výhodu, že se z něj dají jednoduše vyzobávat věci, případně na něm stavět vlastní řešení na míru, zrovna ta migrace je věc, ke které má velká část lidí individuální přístup.

Myslím, že to nikdy nebude dost komplexní na to, aby to nešlo rychle přepsat do plnohodnotného jazyka a dát tomu GUI.

Taky přenesu domovský adresář, data zůstanou na obvyklém místě, konfigurace jde většinou použít i v novejší verzi aplikace. Systém je pak nová instalace s obvyklými aplikacemi a pár úprav v /etc. Nějakou část aplikací nakonec ani znovu neinstaluju. Pokud se to nerozjede celé na první pokus, nějakou chvíli jede původní nebo nový systém paralelně ve virtualboxu, než se podaří všechno odladit. Celé na Debianu, obvykle si vystačím s upgradem každou druhou major verzi, tj. jednou za 4 roky, často právě taky s výměnou hw :)

Ink
[...]že jsem letitý uživatel Ubuntu[...]
[...] Nikdy bych v dnešní době podobné věci neřešil shell scriptem, [...] případně třeba časem přidat nějaké rozumné UI [...]

na neco co je v podstate automatizovana posloupnost prikazu ktere bys psal v terminalu, je bash/shell skript naopak to nejidealnejsi ;-) navic z principu je to v podstate i takove howto/docs jak to udelat rucne

ohledne pridani GUI, k bash skriptu pozuvam YAD (coz je nasledovnik Zenity) pro predstavu co v YAD lze snadno:
http://smokey01.com/yad/
https://askubuntu.com/a/1039377

Linux je o tom, ze staci de fakto syncnout jen home - dnes mam home na samostatnem SSD - apky si bud pamatovat a kdyz na neco zapomenu, tak doinstalovat, nebo udelat rpm -qa ... odstranit verze z nazvu, popr. preventivne vynechat stare baliky - bohuzel fedora nejake verze ma klidne i fresh instalace nove baliky oznacene jako ze starce verze i kdyz jsou prekopilovany nove pro danou verzi.

nejlepsi na prenos home je bud DD - btrfs ma svuj blokovy sync v sobe, imho je jedno zda na dd (dd_rescue) uzijete NC nebo SSH - velmi zajimava volba na mnoho malych souboru je TAR - idelne bez komprese, kopresi nechat na SSH a pres sitovou rouru pakovat a rozbalovat na druhem stroji ...

Popr ja mam doma velky NAS a muzu udelat TAR.GZ a ten pak rozbalit na novem stroji, btw. dik je udelat DD ve stejnem stroji a protoze novy je bud stejny nebo vetsi, pak jej staci roztahnout - jednou to zarve, ze zalozni tabulka part. neni na konci diku, ale jinde, zda to fixnout gparted to zvetsi - jedno zda i s FS nebo ne ... LVM (PV/VG) to same ... imho ja uz mam home jen na sifrovanych discich LUKS - sice jsem emigroval z CR, ale nikdy nevite, kdy CZ fasistickemu statu rupne v bedne - nebo cele EU - tak kdyz mi ukradnou domaci PC, nebudou mit pristup k plno vecem - kolik mam NASu a kde radeji ani rikat nebudu ;-))

Virtual desktop je taky OK, vmware treba umoznuje replikovat do vmware worksation ze serveru - kde ale zustan, pak clovek prijde a vmware se sam replikuje zpet na server a je jej mozno tam zase prehodit jako primarni.

Nektere firmy maji home na NFS, jine jej tam pravidelne replikuji - btw windows dnes ma roaming profil na onedrive - trochu nebezpecne, nebot se v tom hrabe MS/CIA/NSA - ale to je vec firmy.

Osobně na home jsem použil rsync a důležitou konfiguraci se snažim nově držet v home-manageru. Systém mám nixos s konfigurací kterou si držím ve vlastnim repu (flake). Vyřešilo mi to v podstatě všechny problémy kdy potřebuju přejít mezi WS a notebookem a přitom si na obou držet identickou konfiguraci systému a stejné "balíky".

NixOS má v tomto ohledu zajímavé věci. I OSTree, které Silverblue používá, je de facto operační systém v gitu, takže je celkem snadné si udržovat vlastní verze, replikovat je na jiných počítačích atd. Já se ale zaměřuju na aplikace a uživatelská data, toto je momentálně mimo scope. Experimentuje s tím Jorge Castro v jeho Universal Blue.

Když jsem měnil ntb, šel jsem "opt-in" cestou. Možná to bylo i proto, že jsem měnil distribuci. Na nový systém jsem pak instaloval a přenášel jen věci, které mi skutečně chyběly.

Přenos dat řešil skript, kterému jsem řekl cestu na starém systému a on vše v ní přenesl na stejné místo v systému novém.

Takto to delam i ja, zmena pocitace je prilezitost k prehodnoceni co je/neni potreba, kterou je dobre nepromarnit.

Takze si vemes 14 dnu dovolene, a misto povalovani se u vody budes zkoumat, ktery balicek/aplikaci pouzivas a ktery ne? Protoze driv se to rozhodne stihnout neda ...

A nebo chodis tech 14 dnu a rikas "juj, tohle nemuzu protoze nemam X ... a tamto taky ne protoze nemam Y ...a tuto nemuzu, protoze nevim co mi chybi ..."

Používáš nějaký OS bez podpory závislostí?

Ja to obvykle zvladnu tak za 2 hodiny, ale kazdy mame jine tempo.

Vzhledem k tomu, že mi hlavní počítač vydrží tak 10..15 let, mám na něm tolik vytuněných unikátních věcí, že se k přechodu rozhoupávám třeba 2 roky, přesun mi trvá několik měsíců a vlastně nikdy nepřenesu úplně všechno co bych chtěl, protože uchodit některé staré aplikace na novém OS by bylo ještě náročnější, takže hledám náhrady a občas mě i něco příjemně překvapí.

Úplně obráceně to mám na serverech. Tam to jde přes scripty vyřešit na pár zeditovaných řádek.