Linux telepítés utáni konfig költöztetés

Linux-kezdő

Sziasztok!

Érdekelne néhány bevált módszer az újratelepítés utáni gyors rendszer belakásra. Mire gondolok konkrétan: van egy egész jól belakott X disztró, aminek van pár apró idegesítő problémája, ezért felrakok egy új Y disztrót amit szeretnék, hogy minél jobban hasonlítson az előző, már jól belakott környezetemre. Épp ezért dd-zés vagy teljes lemez klónozás nem érdekelne de tisztában vagyok vele hogy ez lehet a legnépszerűbb módszer.

Van egy kis scriptem, ami néhány konfig fájlt, SSH kulcsot dconf beállításokat lementi, de ez elég instabilul működik valamint visszaállításra jelenleg alkalmatlan és annyi hibaüzenetet kapok, ami után úgyis végig kell néznem mindent újra , vagyis mindegy ha megcsinálok mindent manuálisan inkább. Ekkor elkeztem megírni ansible playbook verzióját a scriptnek, jelenleg a lementés nagy része készen van, visszaállítás még nincs és mielőtt nekiesnék inkább hozzátok fordulok az alábbi kérdésekkel:

* mik azok a dolgok, amiket oprendszer költözésnél le szoktatok menteni?
* milyen módszert használtok a mentéshez?
* milyen módszert hasznátok a visszaállításhoz?

Azt remélem, hogy van itt olyan aki - lehet nem is saját rendszernél, hanem mondjuk üzemeltetés miatt - jártas a témában és tud adni pár tippet, amit előre is köszönök!

szerk 0.: a hozzászólásokat elolvasva kezdtem át újragondolni a dolgokat. Egyelőre fájlok backupolása és visszaállítása van meg, egy rövid python script. A folyamat úgy néz ki, hogy tetszőlegesen a fájlrendszerben lehet lépkedni, és tag-elni egy paranccsal fájlokat backupra. A "tag"-elés annyit jelent hogy a teljes elérési útja a fájlnak vagy mappának beíródik egy listába.
Ezt követően a backup parancs (root-ként kell futtatni) annyit csinál, hogy:
1. a listát passzolja --file-list paraméterrel rsync-nek, amit -bavHUXA paraméterekkel hív, azaz tükrözi a fájlok jogosultságait, ownerét, időket, stb.
2. metastore lementi a metaadatokat egy fájlba ezekről a fájlokról
3. git commit, push

A visszaállítás a fordította, tehát git pull, sudo metastore-al visszarakni a metaadatokat majd rsync fordított irányba. VM-en tesztelgettem eddig, ott működik.

2024.06., szerk 1.: nagyjából másfél éve áttértem yadm-ra: https://yadm.io/. Ahogy látom ez egy git wrapper, olyan mintha a teljes fájlrendszered egy nagy repo lenne, de alapból nem trackel semmit. Amilyen fájlokat hozzáadsz, azokat onnantól trackeli (git add helyett yadm add, összes többi paranccsa is git szerű). Tud titkosítani is arra az esetre ha github/gitlab a remote és bizonyos fájlokat nem akarsz plaintext feltölteni még privát repóba sem. Új gép esetén van egy bootsrap parancsa, ami lefuttat fix helyen lévő scripteket, ezekbe lehet rakni a beállításokat meg olyan csomagok telepítését amik majd használják a konfig backupot. Főleg arra használom, hogy szinkronban tartsam a gépeimen lévő alkalmazások konfigját.

  • 1080 megtekintés

( _Franko_ v | 2022. 07. 25., h – 20:03 )

* mik azok a dolgok, amiket oprendszer költözésnél le szoktatok menteni?

Nagyjából a .ssh és a .bash_history tartalma, böngészőkből egy password export-import és semmi mást. Amióta szinte mindent default beállítással használok, sokkal kevesebb problémám van. Van egy kb. fél oldalnyi pár beállítás, amit megszoktam és eltér a default beállítástól, de csak azokat állítom be újra, amit tényleg használok, a többit lehúzom, ennyire meg teljesen feleslegesnek érzek bármi automatizálást, mert sokszorosan több idő.

Nyilván, ha mindent is custom beállítással használsz, az extra szopás, de szerintem nem tudsz mindent script-ből újra ugyanúgy beállítani.

https://iotguru.cloud

( Mobulla | 2022. 07. 25., h – 20:10 )

Fapados módszer, mentés könyvtárba szelektíven elmentem darálás előtt a /home/.*  /.config és  ./share alatt található különböző könyvtárakat, config fájlokat, majd ugyanez vissza. KDE-t használok, megkönnyíti a dolgokat, hogy az adott program ikonját állítom be a configját tartalmazó könyvtárra. A home főbb elemei különböző meghajtókra vannak symlinkelve, azokkal nem kell foglalkoznom, csak arra kell figyelnem, hogy telepítéskor minden a megfelelő helyre legyen csatolva. A mentés abban a szerkezetben történik, ahogy eredetileg is volt, így visszaállításnál egy könyvtár tartalmát kell a helyére másolnom.

( locsemege v | 2022. 07. 25., h – 22:16 )

Tudom, nem ez volt a kérdésed, de attól nagyon fázom, amit kérdezel. Nehéz eldönteni, hol a határ. Legyen a /home kompletten? A /etc mehet? Na jó, de akkor esetleg a félrekonfigurálások is megöröklődnek. Az ilyen öszvér megoldás szerintem nem jó. Két járható utat látok:

  1. Tiszta telepítés, aztán amit kell, állítsd be manuálisan. Szerintem sok munka és felesleges.
  2. Rendszer klónozása, én mindig ezt csinálom, ha a saját gépemről van szó. Nem szektorosan, hanem file-osan. :)

A 2-es pontról néhány szó. Kialakítom a target layout-ot, formázom, majd másolok rsync -avxHASX src dest módon. Nyilván pendrive-ról fut egy live telepítő rescue módban, nehogy a src filerendszeren bármi is változzék.

Utána kikalapálom a /etc/fstab tartalmát, illetve felteszem a grub-ot. Elsőre úgysem fog boot-olni, szinte biztos, hogy valamit elfelejtek, de megjavítom, aztán jó lesz. :)

Raktam már át így HDD-ről SSD-re oprendszert, cseréltem komplett hardware-t oprendszer alatt, raktam egészen más layout-ra. Például jelenleg Fedora 36 van a gépemen RAID1 SSD és szintén RAID1 HDD tömbbel, miközben ezt az oprendszert Fedora 18-ként telepítettem utoljára más hardware-en, egyetlen HDD-re. Azóta nem volt tiszta telepítés, s nem is tervezem. Olyan viszont volt, hogy betelt az rpm adatbázis filerendszere verzió upgrade alatt, meg volt olyan is, hogy megdöglött az SSD, de még read only elérhető volt. Mindkét esetben volt akkora szerencsém, hogy meg tudtam menteni az oprendszert.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Legyen a /home kompletten? A /etc mehet? Na jó, de akkor esetleg a félrekonfigurálások is megöröklődnek

Pont ezért sem csinálom/csinálnám ezt. Nameg lehet hogy az egymással jól viselkedő defaultsok ütköznek más disztró verziók között.

A fájl alapú klónozás valóban szebb megoldás mint szektoros, de nem látom hirtelen hogy kerülném el vele a hibás konfigok továbbörökítését :-) Minden esetre köszönöm a választ, maga az rsync ansible-el nem lenne rossz távolra periodikus backupok készítésére mondjuk.

Az első bekezdés alapján nekem úgy tűnik, disztrót akar váltani (X->Y). Mondjuk a "lemez klónozás" résznél már fogtam aztán a fejem, hogy most akkor mi van? Azzal nem nagyon tűnnének el egy disztró "idegesítő problémái", hacsak nem update lenne, de ahhoz meg ritkán kell "újratelepítés". :D Szóval egyelőre azt sem tudjuk, mi a terv!

Hülye kérdés, Windows-ból kiindulva, az a registry és/vagy a winsxs könyvtár sokszorosára növekedése  miatt lassulnak le brutálisan, vagy az ntfs töredezik? 

A Linux file rendszerek, ext4 vagy xfs, miket használnak mostanában? Ezek semennyire se vagy minimálisan dobálják szét 1 fálj darabjait a diszken?  Csak utóbbi esetén logikus a klonozás.

Az NTFS is töredezik, bár az az SSD-ken már nem probléma. A Windows szerintem mindig is a registry-től lassult be, ahogy az hízik, úgy lassul a rendszer.

A linuxos fájlrendszerek is töredeznek, de kevésbé. Egyrészt a kernel cache-elése jobb, mint a Windowsnál, másrészt a linuxos fájlrendszerek nem próbálják az adatokat teljesen sorba tenni, egymás utáni szektorokban, hanem igyekeznek minél nagyobb, de egyenlő távolságokra dobálni. SSD-nek mindegy, ennek HDD-n van haszna, hogy így kisebb hosszabb távon a töredezés. Az is igaz, hogy a modern HDD-knél is javult sokat, mióta azokban is sok hardveres cache van, meg a fizikai szektorméretet is 4K-ra növelték, ez is segített.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezek semennyire se vagy minimálisan dobálják szét 1 fálj darabjait a diszken?  Csak utóbbi esetén logikus a klonozás.

Nem szektorosan, hanem file-osan klónozok, tehát ami töredezett a forrás disk-en, az szektorfolytonos lesz a cél disk-en. Egyébként ext4-et használok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( dotnetlinux | 2022. 07. 25., h – 22:25 )

Ha ezt tobbszor meg kell csinalni, akkor javaslom az elejetol az ansible-t, ezzel mindig ujrahuzhatod az infrat. Már ha infra van es nem egy desktop geprol van szo. 

Van aki git-ben tarolja a /etc-t, az is egy modszer. 

Annyi köze hozzá, hogy az "etc" ugye az "et cetera" rövidítése, ami magyarul az "és a többi (hasonló)", a UNIX /etc és a K8s etcd is ugyanebből származik, csak K8s esetén a "d" azt jelenti, hogy distributed - elosztott.

De az etcd abszolút alkalmatlan a UNIX /etc bármilyen mentésére.

https://iotguru.cloud

Fedora nem kérdez semmit, eldönti maga. Ez nagyon kényelmes, nem kell idegtépő döntéseket hozni, s azon mélázni, melyik a jobb ötlet. Ha a régi mellett dönt. melléteszi az újat valami.rpmnew névvel, ha az új mellett dönt, a régiről csinál backup-ot valami.rpmold névvel. Ha nem volt módosítva a config file, akkor egyszerűen felülírja.

De mellesleg te nem Fedorát használsz?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Valóban, köszi hogy aláhúztad, itt most nem infráról lenne szó. Van egy desktop gépem, egy saját és egy munkahelyi laptopom, van amelyiket évi 1-2-szer újrahúzom ilyenkor mindig elmegy pár óra mire belakom, nem azért mert olyan sok egyedi, defaulttól eltérő konfogom van, inkább azért mert sok dolog nem jut eszembe egyből. Például Gnome bővítmények, ezek konfigja, stb.

Mégis mi a fenének húzod újra? 2013-ban telepítettem utoljára tisztán azt az oprendszert, amelyet most is használok számtalan system upgrade és hardware-eken átívelő költöztetés után. Ennek kilenc és fél éve. Vagy windows-os laptopról beszélsz? Mert akkor mindent értek. :D

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyik kollégám meg 97-ben telepített utóljára debiant, azóta azt upgradeli, miért kéne 25 évenél gyakrabban újat telepíteni? Köszönöm a válaszodat, de on-topic válaszok érdekelnek elsősorban.

szerk.: sajnos nem értek annyira a linux disztrókhoz, hogy ha valami elromlik, azt véges időn belül meg tudjam fixálni. Mostanában azért egyre ritkábban futok bele nagy hibákba, de például közel fél napot szívtam az alábbi problémákkal az elmúlt évben:
* egyik update behozta a pipewire-t de bugosan, hiányzó konfiggal. Aki ért a linuxhoz, semmi perc alatt fixálja, én viszont nem berhelem ezeket a dolgokat (hálózati dolgokra vagyok igényesebb, ott jó ideje nem akaszt meg szinte semmi, ami igen ott kernel kódból kiindulva fixálom) és soha nem hallottam előte sem a pipewire-ról, sem a pulseaudióról, hanem adottságnak vettem hogy van hang. Egy újratelepítés fél óra lett volna max + ha lenne valami ami a saját konfigjaimat behúzza, mondjuk kis átírogatással az megint fél óra, összesen is negyed annyi mint amit a fixálásra fordítottam
* egyik napról másikra virradóra nem jelenik meg a desktop. Gnome 3-at használok, mint került az frissült, de valami extension meg nem, ami elhalálozott úgy hogy vitte magával a desktopot. Debugolás után persze meglett a gond, de túl sok idő volt ahhoz, hogy ne legyen "olcsóbb" újrahúzni a gépet
* grub rescue fogad / BSOD fogad, mert újragenerálódott egy olyan GRUB bejegyzés ami megpróbálja betölteni (sikertelenül) az inteles microcode-ot. Előbb utóbb kiderült, hogy ez a baj, ismételten túl drágán.

Na, ez már érthetőbb.

1. Nyugodtan írd ki a disztrót, ha akarod (miattam nem fontos), aki fikázni jön, azt szard le, mert alapvetően hülye a linuxhoz. (Kurva gáz, hogy itt tart a HUP, hogy az ostoba idióták miatt már a disztrók nevét sem merik kiírni.)

2. Tiltsd le a picsába az automatikus frissítést, néha nézz rá, hogy van-e _értelmes_ biztonsági frissítés, amit telepíteni nagyon ajánlott (ritka). Ha valami számodra jól működik, azt minek frissíteni? Ha valami nem jól működik, esetleg azt frissítsd. Ha nagyon sok időd van, vagy unatkozol akkor frissíts, és akkor keresgélhetsz megoldást. Esetleg 2-3 havonta mentsd le a rendszert, ha jól működik, frissítés előtt (nyilván a felhasználói nem rendszer izék nélkül (filmek, zenék, izébigyók).

3. Nyilván nem kell azt tenned amit írtam, ha nem akarod, mert megszólnak miatta az update fetisiszták. ;)

(Egyébként én baromi rég találkoztam olyannal, hogy ne kérdezte volna meg az update, hogy lecserélje-e a config fájlt. Sosem hagytam neki! :D )

Fedora két dolgot csinál, nem egyszerre, hanem vagylagosan:

  • meghagyja az eredeti configot, létrehoz egy újat mellette *.rpmnew névvel
  • menti az eredeti configot *.rpmold névvel, majd létrehozza az új configot

Mindkettő esetben van lehetőség összenézni, összeollózni az új és régi configfile hasznos részeit.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszi a tippeket. Amúgy nem szégyellem a disztrót, igazából Ubuntu és Debian, bár tettem egy két éves kanyart Manjaro/Arch irányba is (2020-2022), de kicsit belefáradtam, hogy egyes obskúrusabb csomagokat vagy frissítik vagy nem, meg hogy pl. Manjaro kernelben sok debug funkció ki van kapcsolva.

Amúgy úgy használom a rendszert ahogy írod, mindig letiltom az automatikus frissítéseket. Apt helyett nala-t használok és úgy még látom is, melyik csomag mire fog frissülni, színes-szagos az egész :)

Ó, hát akkor bocs, így már akkor bőven van rálátásod, én meg beszélek feleslegesen. :)

Amúgy én MX linuxot (Debian 11 alap) használok, annak is a live telepítőjét alakítottam át magamnak, ami RAM-ból fut. Na ez pont arra (is) jó, hogy egy csak olvasható squashfs töltődik be a RAM-ba, illetve egy rootfs ext4 image file-ból tölthető rá bármilyen változtatás, és én döntöm el, mi kerül bele, nincs automentés. Ugye innentől az égvilágon semmi nem tud változtatni a rendszeren, csak én. Bebootoltam a telepítőt, feltelepítettem a számomra szükséges programokat, felkonfigoltam a rendszert magamnak, letöröltem minden számomra szükségtelen faszságot, és a benne lévő MXRemasterrel rögzítettem a rendszert, így lett belőle a legvégén egy 472MB-os (xz) squashfs file (gzippel 591MB). :) A remaster folyamat bármennyiszer ismételhető, pár perc, szóval alakítgatható tetszés szerint bármikor, bármi a rendszeren. És egy totál teljes rendszer fut a RAM-ból, akár upgradelhető, bármit csinálhatok vele, akkor is a következő bootnál ugyanaz a rendszer indul el, ami az olvasható squashfs-ben van. A Chromium böngészőt egy külön image fájlból töltöm be (107 MB), van néhány appimage ha kell (pl. FBReader, Popcorn-Time, Gimp, WPS) szóval ugyanezt a rendszert bebootolom egy 1 GB-os SD kártyáról, telefonról, bármiről (alapból notebook ntfs partíción van).

Csak azért írtam le ezt így, hogy látható legyen, hogy totál nem fontos függeni az updatektől sem, igaz, kis meló van benne, de az több lenne egy sima esetben, igaz a squashfs előtt ext4 image fájlokból futtattam utoljára Mintet. (Ja és minden oprendszert image fájlból futtatok, az XP-től a W11-ig (ezeket is RAM-ból), az X86 Androidtól az SSTR-ig, szóval az NTFS-es partíción a gyökérben 1 db könyvtár van. :D Jó, hát igazából az MX-en kívül ezek csak nagyon ritkán használtak, inkább csak kihívás volt.)

Szóval van ilyen bombabiztos linuxfuttatási módszer is, és ugye ezt lehet csinálni részletekben, ráérőidőben pl., de meg is maradhat mellette a telepített oprendszer is.

(Ja, és akár 1-2 perc alatt feltölthető az egész a netre mentésnek! :) )

Most hirtelen csak ezt a configot találtam meg, régen futtattam már (Grub4DOS title):

title Android6
kernel /HBCD/Android6/kernel androidboot.hardware=android_x86 quiet  SRC=HBCD/Android6  DATA=HBCD/Android6 CREATE_DATA_IMG=1
initrd /HBCD/Android6/initrd.img
 

Update:

Leszedtem az Android 9-et, az iso fájlból a gyökér szükséges részét bemásoltam egy Android9 könyvtárba, bebootoltam ezzel (Grub4DOS, de Grub2 is jó átírva a kernelt linuxra):

 

title Android9_X86
kernel /HBCD/Android9/kernel root=/dev/ram0 quiet SRC=HBCD/Android9
initrd /HBCD/Android9/initrd.img

 

Sajnos az egész egy bughalmaz, még a screenshotot is telefonnal csináltam, de még a google fiók login is elcrashel. :) LINK

Csak most körvonalazódik, mi a gondod, eddig ez nem volt világos.

Az a baj, nagyon más a szemléletünk, ezért nem nagyon tudok érdemben mit mondani. Ha valami nem működik, az ugyan frusztráló, de érdekel, mi lehet a probléma oka, s úgy vagyok vele, a megoldáshoz vezető útból is tanulni fogok. Tehát nekem eszembe sem jut a tiszta telepítés, mert nem a saját időmre optimalizálok, sokkal inkább az a szempont, hogy bármi áron megjavítom, s örülök, ha ezáltal bővül a tudásom.

Mondanám, valami backup lenne a megoldás a telepített csomagok listájáról, /home és /etc-ről, aztán jön a meglepetés, hogy a /var/lib/AccountsService tartalmát is menteni kellett volna. Ezért mondom, az ilyen öszvér megoldás gányolás, mert eredményez egy olyan rendszert, amelynek egy része nem lesz testre szabva, egy része igen, s egy része pedig nem fog működni, aminek következtében ugyanúgy bogarászni kell, miért nem működik. Az megint idő.

Nekem például ott van a Microchip fejlesztői környezet valahol a /opt alatt, nagyjából tudom, mit hova tesz, de ha csak egy valamit benézek, világvége van. Ezért mondom, hogy szerintem a munka nem spórolható meg, érdemes megjavítani azt, ami nem megy. Amikor újratelepíted, nincs olyan érzésed, hogy idegen a gép? Semmi sem ott és úgy van, mint annakelőtte?

Melyik disztribúció produkál ilyen fura hibákat? Fedorával nincs ilyen rossz tapasztalatom, csomagfrissítés nem szokta megpusztítani az oprendszert. Persze előfordulnak olykor hibák, legutóbb ebbe futottam bele, de mint látod, javították.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, ezt a hozzáállásbeli különbséget nem ártott volna korábban tisztázni :-) Szó sincs róla, hogy nem érdekelne bizonyos programoknál a megoldás, mert szeretek tanulni, meg időről időre belefutok abba, hogy amivel küzdök az már "deprecated" és létezik sokkal jobb alternatíva. Csak van hogy ezek a legrosszabbkor jönnek és egyszerűen nem tudok rászánni annyi időt amennyi a megoldáshoz kellene.

Szerintem nincs értelme 25 éves rendszert magad előtt görgetni. Mutatványnak jól hangzik, csak előnye nincs. 5-10 évenként akkorát változik a Linux világa, hogy nem érdemes túl régi rendszerekhez ragaszkodni. Jött az XFree86 helyett a X.org, a 64 bit, bejött a pulseadio, majd a systemd, most a pipewire és wayland van terjedőben. Gyorsan változó ökoszisztéma.

Amit én javaslok: tanulj meg érteni hozzá, hogy fixálni tudj magadnak egy rendszert. Nem ördöngösség, senki nem úgy jött a világra, hogy tudta. Szép apránként tanultuk, mindig mikor előjön egy probléma, akkor kell nyitottnak lenni, utánaolvasni, és nem lustának lenni, újratelepíteni, stb.. Hozzáállás kérdése, a tudás az majd jön idővel fokozatosan, ahogy észreveszel a problémák megoldásában általánosabb mintákat. Ez egy folyamatos fejlődési folyamat, amit nem lehet erőltetni, meg mindent azonnal tudni.

Gnome3/4x az ilyen, új verziókkal a korábbi webextensionök nem működnek, míg a fejlesztő nem update-eli őket az újabb Gnome-verzióhoz. Szopás, de ezzel nem tudsz mit csinálni. A GRUB mikrokódbetöltésnél jó lenne látni, hogy hogyan néz ki a grub configja, de lehet simán csak újra kellene telepíteni az inteles microcode csomagot, az post install scriptként megoldja a GRUB-ba kofigurálást.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Raynes v | 2022. 07. 26., k – 04:30 )

A /home/-ból szoktam a konfigokat lementeni, a /etc/-ből néhány extra conf fájlt. Illetve csomagkezelővel kilistázom a feltett csomagokat és elmentem. Most fogok a konfigfájloknak nyitni egy privát git tárolót, ahonnan leklónozhatom a konfigjaim, ez biztonsági mentésnek is jó, nem csak verziókövetésnek. Ehhez tudni kell azt is, hogy Archon és minimalista WM-en, terminálos alkalmazásokon kívül mást nem használok, semmi Ubuntu, meg komplett DE, így általában elég könnyen menthetők a konfigok. Eleve a /home/ mappám is megmarad, mert az külön partíción van. A /boot/-re szintén igaz ez, megmarad, általában a PARTUUID-k sem változnak, így változatlanul bootol UEFI-s systemd-boottal.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Kérdésem lenne, létezik Linuxon olyan program(ok) ami az alaptelepítés és a bekonfigurált rendszer között készít egy csomaglistát mi települt, és kikeresi azokat a konfig fájlokat amik módosultak az eredetihez képest? Majd ebből készít az adott disztró csomagkezelőjéhez egy csomagot? X naponként lefuttatni és készítene mindig új csomagot?

Hú, ez jó kérdés. A csomagkezelők általában tudnak olyat, hogy kilistázhatod azokat a telepített csomagokat, amik nem függőségként kerültek fel, később ezeket felteheted. Olyan viszont szerintem nincs, ami a módosult konfigokat is vizsgálja. Ha az utóbbi kell, arra inkább szerintem a NixOS való, ott az egész Linux telepítés egy nagy konfig fájl alapján megy reprodukálhatóan, bár egyedi konfigfájlokat később telepített alkalmazásnál nem tudom mennyire tud az is menteni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Megnéztem pár csomagot, és nem lehet arra támaszkodni hogy fájlként van benne egy config fájl, vagy legyen az bármi amit menteni kellene, mert scriptek hozzák létre, ez így nem jó irány. Viszont olvasgattam és az inotify vagy hasonszőrű társait biztos fel lehet úgy paraméterezni és kizárni bizonyos könyvtárakat hogy kiadja magából a telepítés folyamán létrejött vagy módosult fájlokat könyvtárakat. Le fogom tesztelni. Mondanám hogy létrehozok erre is egy topikot, mint az iRedMail backup, de kín keserves átvergődni az emberek hülyeségein.

Ezek voltak az érveid illetve ellenérveid? A magam részéről az rdiff-backup nevű csodát használom. Igaz, nem telepítés utáni config költöztetésre, hanem backup-ra.

Egyébként mi volt a gondod a felvetésemmel? Azért beszéltél inotify-ról, mert a változásokat akartad követni. Az inotify eseményvezérelt, lényegében a kernel adja az infót valós időben, ha valami változik. Az rsync ellenben a mentés pillanatában, pollingolás útján jut ahhoz az információhoz, volt-e változás. Ha igen, akkor másol, ha nem, akkor minek, hiszen a célhelyen ugyanaz van, mint a forrás helyen.

Ugyanakkor továbbra is az a véleményem, Linuxot nem kell újra telepíteni. Hardware-t is lehet alatta cserélni, ideértve a háttértárat, alaplapot, CPU-t, RAM-ot, illetve a háttértáron a layout-ot. Tapasztalatból mondom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én nem akarok semmilyen érvet vagy ellenérvet felhozni a felvetésedre. Nem nekem kell ebben a topikban segíteni. Én csak kérdeztem valamit és kaptam rá választ. A kérdésem nem volt jó, azt pedig leírtam miért. Erre gondoltam ki azt, hogy feltelepítek egy alap szerver Ubuntut, majd elindítom a megfelelően felkészített inotify-on alapuló scriptet ami addig figyeli a változásokat bizonyos helyeken, amíg mindent fel nem telepítek és be nem konfigurálok mindent. Nem fájlokat akarok másolni a inotify-al. Csupán egy listára van szükségem valós időben, amiből aztán egy Debian csomagot fogok készíteni. Hogy az ügyfélnek a Debian csomag tudjam átadni, ami ügyfélre van szabva. Továbbá a frissítéseket is így fogja kapni.

dpkg-t használó rendszereken a `dpkg --get-selections | awk '$2 == "install" { print $1 }'` kiadja a telepített csomagokat. ("install" helyett "deinstall"-lal pedig a korábban telepített, de eltávolított programokat írja ki, kivéve, ha purge-dzsel lettek eltávolítva.) yum/dnf-nél van `dnf history`, ami a korábbi dnf parancsokat mutatja meg, de közelebbről nem ismerem, így nem tudom, miket tud még. Ill. ott az `rpm -qa` a telepített csomagok listázására. Ebből már lehet építkezni. (Egyéb célzott megoldásokra én is kíváncsi vagyok.)

Nagyon hasonló az amit csinálok jelenleg, ansible összeszedegeti dconf-ból a saját bill. shortcut és gnome beállításaimat, telepített csomagok listáját, /etc/-ből pár releváns konfigot, home-ból pár releváns konfigot, csinál evolution mail kliens profilokból egy backupot és privát git repoba felrakja őket. A manuális visszaállítás az amire egyre kevesebb reményt látok hogy meg lehessen spórolni.

( golgota | 2022. 07. 26., k – 07:49 )

Szerkesztve: 2022. 07. 26., k – 07:49

en az appconfigokat/sshconfgot/.config alol dolgokat/barmit ami kell ugy ahogy van git-ben orzom es amikor kell az ansible-pull visszarakja oket. Akkor is ha elconfigolok valamit es visszaallnek amikor meg jo volt. :D

( dyra | 2022. 07. 26., k – 10:49 )

Az én módszerem, hogy minden a felhőben van. Így nagyjából tökmindegy mikor melyik rendszeremet használom. Nagyon jó bevált. Valami nem koser és nincs kedvem a hibát nyomozni reinstall aztán hajrá megint. Pár dolog van amit telepítenem kell pl a Insync amivel a felhős cuccokat szinkronizálom. Ezen kivűl kb mindent defaultban használok ahogy a jó isten adta.

hat ugye lehet snapshotolni a diskeket, aztan abbol egy uj gepet inditani, de ez csak egy megoldas. Aztan ha akarod akkor mondjuk aws ssm configjaban tarolsz dolgokat, vagy azure app configban, aztan bot idoben a cloudinit megcsinalja amit kell. Millio lehetsoeget el tudok kepzelni. Es az egesz hobelebancot lehet automatizalni a cloud sajat ci/cd-jevel vagy gitlab/hub-rol. 

Millio lehetoseg van disposable machines letrehozasara

"Az én módszerem, hogy minden a felhőben van."

Hát alapból az érdekelt volna, hogy honnan bootol oprendszert. :)

 

De amiket írtál, azok valóban jól hangzanak elsőre, de tapasztalataim alapján a minden automatizálása egy random desktop rendszernél addig jó, amíg nincs probléma. Ha meg van, akkor görgeti magával, és bonyolítja. Ugye alapból lealább 3 szolgáltatás hibáit is be kell kalkulálni (net, áram, felhő). Plusz disztrófüggő még az is, hogy mennyi snapshot keletkezne, mondjuk napi, vagy 2-3 napi, amit megcsinál, feltölt, konfigol. Vagy minimum napi? Mikor derül ki, hogy el van baszódva egy update, melyik snapshot induljon akkor? És mindezek közben még valamit kellene kezdeni a hibával is, vagy esetleg hetekig visszaállítgatni a bootot, vagy ezek variálása. A configok snapshottól független szinkronizálása meg megint necces, főleg visszaállításnál, ha több config file módosult. Tapasztalatom szerint van néhány app, pl. böngészők, amiknél pláne nem automatizálnék configváltozást, jó, mondjuk ez szubjektív. És akkor még a snapshotok helyigénye is kérdés.

Nem kétlem, hogy ezek jó dolgok, de személy szerint én maradok a lokális módszeremnél. :)

Egyébként meg ugye ezekhez a dolgokhoz - mind a local, mind a felhő esetében -, azért kell pici affinitás, tudás, szóval ez még hozzájön a "jól hangzáshoz", úgyhogy feltételez némi hozzáértést is, ami meg nem általános dolog. Szóval a fene se tudja, hogy nem rabol-e el az egész akár több időt, mint az alapproblémás újratelepítés utáni belakás. ;)

( zrubi v | 2022. 07. 26., k – 11:43 )

ahogy már előttem is írták:

Más disztribúcióra költözni desktopon az szívás. És a gyakorlatban csak a manuálisan újrakattingatás működik.

Ha ezt sokszor kell csinálnod, akkor ott a háttérben valami más probléma van, azt kellene megoldanod inkább ;)

 

Ha csak ugyan azt 'újrahúzod' - ahol megint nem mindegy miért! - akkor szimplán a /home 'megtartása' a leg egyszerűbb út.

Ha a rendszered egyik napról a másikra 'szétesik', akkor tényleg keres egy STABIL disztribúciót. pl: Ubuntu LTS.

 

Szüleimnek Ubuntu LTS van évek óta problémamentesen - pedig ők 0 hozzáértéssel használják.

Én Fedorát használok céges és provát gépen is - amibő 6 havonta jön ki újabb release! - mégsem találkoztam eddig olyan problémákkal amiket fentebb írtál...

 

 

szerintem.

zrubi.hu

Valóban, erre a részére nem is reagáltam. Ez a konfigmentés, csomaglista, stb. csak akkor biztos út, ha ugyanaz lesz a disztró. Ha másikat rak fel, az módosított konfigokat használhat, amibe bele kell szerkeszteni az egyéni változásokat. A /home/ mentése ilyenkor is járható lehet, de a /etc/, csomaglista már necces.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( solt87 | 2022. 07. 26., k – 12:30 )

Szerintem locsemegének igaza van, amennyiben ebben a dologban nem nagyon lehet megúszni a munkát. Neked kell összeszedned, hogy mit akarsz elmenteni. (Elvégre amit elfelejtesz belerakni a mentésbe, az értelemszerűen nem lesz ott a helyreállításkor.) Valószínűleg ez is egy hosszabb folyamat lesz, és nem árt némi szemléletváltás sem. Pl. ha telepítesz egy számodra új programot, és hasznosnak találod, akkor érdemes ennek a beállításait is felvenni a mentendő dolgok közé. (A programhoz tartozó cosmagok pedig mehetnek a telepítendő csomagok listájára.) Ugyanígy érdemes lehet új (al)könyvtárfa létrehozásakor minél hamarabb eldönteni, hogy kell-e menteni a belekerülő dolgokat.

Írtad, hogy Ansible-t is használsz, az hasznos lehet. (Nekem is van félkész játszóskönyv-gyűjteményem telepítés utánra.) Saját beállítófájlok kezeléséhez tudom ajánlani a GNU Stow-t (a mentendő beállítófájljaim a ~/etc alatt laknak, de linkelve vannak az "eredeti" helyükre), mentéshez pedig a borgbackup is jó lehet. (Ceterum censeo rejtett könyvtárbejegyzéseket esse delendam.)

Egyébként itt is fontos és hasznos a mentés tesztelése. Ha mondjuk VM-be vagy félreeső gépre telepítesz új OS-t, és azon kipróbálod a visszaállítást, kiderül, mit hagytál ki, mi nem működik, mi működik nehézkesen. Ha eleget csinálod, lehet egy tökéletes elég jó mentésed. :)

A GNU Stowról még nem hallottam de pont ez az az irány ami érdekes nekem, köszi a tippet! Megnéztem most pár videót és blogposztot róla, és tök jó. El tudnék még képzelni olyan Stow-szerű toolt, ami "tudja" hol a dotfiles mappa és tetszőleges helyen kiadva a parancsot fogja és átmozgatja oda a fájlt, meg létrehozza a simlinket. Például /etc/systemd/system mappában kiadnám a parancsot hogy "stoww tunnel.service" ekkor a home-omban a dotfiles mappámban létrejönne az /etc/systemd/system/tunnel.service fájl linkelve eredeti helyére.

Érdekes, ahogy nézelődök tucatjával bukkannak fel dotfile managerek, de home mappán kívül egyiket sem látom hogy használnák. Ami elég szimpatikus, a dotbot, tud shell parancsokat is futtatni meg fájlokat helyrerakni, lehet hogy az a pár dolog amit ansible-ből használok az tudná ez is. 

( mark7 | 2022. 07. 27., sze – 00:58 )

A böngésző(k) könyvjelzői ha vannak, azok kellenek, mivel ujratelepítés, ugyanazon diszken felülíródnak.

Ha használsz levelező programot, ami pop-on megy, akkor az is.

( tamas.hornos | 2022. 07. 27., sze – 12:00 )

Nem a configot érdemes menteni hanem az állapotot vagy az eljárást, szóval Ansible és társai.

( SPYFF v | 2022. 07. 30., szo – 23:50 )

Köszönöm a hozzászólásokat!

Beszerkesztettem az eredeti hozzászólásba, mire jutottam. Ez csak backup/visszaállítást oldja meg, ezt sem túl intelligensen, de amire nekem kell arra kényelmes.

Működőképesnek néz ki. Néhány gondolat: nem kell ehhez Python, elég lenne egy shell script. A másik, hogy ha az rsync úgy is menti a metaadatokat (jogosultság, owner, időbélyegzők), akkor minek ez a metastrore-ozás?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Polesz v | 2022. 07. 31., v – 18:04 )

A /home külön partíción, váltás előtt csinálsz a felhasználódból egy user.old könyvtárat és áthúzod az új rendszerbe ami kell menet közben.