Portál AbcLinuxu, 3. května 2025 17:37
/boot/grub/grub.cfg
při některých aktualizací je podle mě naprosto běžná věc (nejen v Debianu), je to prostě automaticky generovaný soubor, tj. není to to správné místo, kde dělat úpravy.
/etc/grub.d
.
Tomu ja celkom chapem. Archlinux to ma vsak aj napriek tomu vsetkemu inac (a mne to tak vyhovuje viac) . A aby sme boli uplne dosledny, permanentna konfiguracia sa vykonava konkrektne iba v /etc/grub.d/40_custom a rucne vytvorenych (ostatne su tiez prepisane pri update).
Problem vsak je ten, ze takto napriklad neviem dosiahnut to, aby som mal jednu polozku v menu pod heslom a inu nie (pricom tieto moznosti su zdokumentovane aj v info stranke a mali by byt teda dostupne). Alebo je taka moznost, len som na nu neprisiel?
Naopak, je to presne to misto, kde delat upravy.Není, pokud nevypneš automatizaci a nerozhodneš se si toto řídit sám. Já osobně nevím, proč bych to dělal. Automatizaci zbožňuju. Používám Gentoo, které automatizuje skoro úplně všecko, a co neautomatizuje, proto si dopisuju automatizaci vlastní.
Ze si to v nekterych distrech obali vrstvou (nebo nekolika) abstrakceBejvávalo. Dnes je naštěstí ta abstrakce součástí upstreamu a tam se distribuce už nemusí nutně od upstreamu lišit. Sdílení kódu mezi distribucemi považuju za správnou cestu. Z mého pohledu, kdy automatizuju celý build a instalaci kernelu, považuju update konfigurace bootloaderu za zcela logický poslední krok před rebootem.
U Debianu je to az chorobne. Ten pro jistotu co par minut prepise i resolv.conf.Debian nepoužívám. Jaký nástroj tam bezdůvodně co minutu přepíše resolv.conf a z jakého důvodu toto chování vzniklo? Dost možná to půjde velmi jednoduše opravit. Jeden problém může být v tom, že /etc/resolv.conf není ani tak konfigurační soubor jako běhová konfigurace, akorát je omylem umístěný na disku.
Debian nepoužívám. Jaký nástroj tam bezdůvodně co minutu přepíše resolv.conf a z jakého důvodu toto chování vzniklo? Dost možná to půjde velmi jednoduše opravit. Jeden problém může být v tom, že /etc/resolv.conf není ani tak konfigurační soubor jako běhová konfigurace, akorát je omylem umístěný na disku.Přesně tak to je, a je to tam velice zřetelně napsáno.
$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1
/etc/network/interfaces
, pokud nepoužíváš nějaký extra tool jako NetworkManager. Jako napsat by to tam mohli, ale zase na druhou stranu co máš do toho souboru co vůbec lézt. :D
O některých věcech je lepší nežertovat - nebo aspoň ne veřejně.
Viz film Rozpuštěný a vypuštěný, věta "A moje boty by takhle nechtěl?"
Bejvávalo. Dnes je naštěstí ta abstrakce součástí upstreamu a tam se distribuce už nemusí nutně od upstreamu lišit. Sdílení kódu mezi distribucemi považuju za správnou cestu.Nanestesti je tu ale take tvrda realita. Mam tri ruzna distra ve virtualech. Chci spustit sit, provest X, a zase je vypnout. Kazde distro ma sit obalenou potencialne jinou vrstvou abstrakce, ale to je jedno, protoze bez ohledu na distro v konecnem dusledku neco spusti dhcp klienta a zapise nameserver, ktery znam, do resolv.conf, coz muzu provest rucne a funguje to, resp. ve dvou ze tri, protoze v Debianu "stejny" dhclient prepisuje resolv.conf za chodu, a spatne, protoze on ten nameserer nezna.
vim /etc/resolv.conf aha, hmmm, :q vim /etc/foo/bar.conf
nez mit proste konfigurak, je vec druhaRád si poslechnu nějaké lepší řešení. Nebo předpokládáš, že při updatu kernelu budu muset tento do konfiguráku ručně přidat?
U Debianu je to az chorobne. Ten pro jistotu co par minut prepise i resolv.conf.Nějaký server se staticky konfigurovanou sítí:
# cat /etc/debian_version 8.7 # l /etc/resolv.conf -rw-r--r-- 1 root root 72 Feb 21 2007 /etc/resolv.conf(což je nejspíš datum instalace) Desktop s DHCP:
# cat /etc/debian_version 9.0 # l /etc/resolv.conf -rw-r--r-- 1 root root 45 úno 23 18:02 /etc/resolv.conf(což je datum připojení k síti) Pro jistotu jsem se podíval i na úplně nový server, který jsem instaloval před měsícem, a mám tak v živé paměti, že jsem určitě neměnil nic oproti defaultu, a ani tam nemohu sloužit -- resolv.conf se od 20. ledna nezměnil. Nemám v něm ani ten komentář, co píše MMN níže, a balíček resolvconf vůbec nemám nainstalovaný.
Rád si poslechnu nějaké lepší řešení. Nebo předpokládáš, že při updatu kernelu budu muset tento do konfiguráku ručně přidat?Tak dříve jsem občas viděl, že někdo držel naopak fixní konfiguraci a výsledný kernel a initrd ukládal do /boot pod neverzovaným generickým názvem, například vmlinuz a initrd.img.
Nemám v něm ani ten komentář, co píše MMN níže, a balíček resolvconf vůbec nemám nainstalovaný.To bude asi tím. :)
To bude asi tím. :)Doufám, že se to vysvětlí nějak jinak, protože tohle by znamenalo, že si Nobody nainstaloval balíček, který přepisuje resolv.conf, a pak si stěžuje, že mu něco přepisuje resolv.conf.
Mne sa tiez zda, ze je to GTK3 zalezitost.
Ja tieto sipky velmi nepouzivam (bud tocim koleckom alebo supem posuvnikom, ked uz pouzivam mys), cize som si to velmi nevsimol. V Archlinuxe doma mi to nerobi (ide to podla ocakavania). Na Debiane ale napriklad tieto sipky vobec nevidim! Je tam skratka posuvnik bez sipiek - ked teda kliknem na okraj, je celkom jasne, ze dokument skoci na koniec / zaciatok.
Takuto kartu som dokonca aj mal v ruke - v praci sa to dakedy davno na nieco pouzivalo (ja vsak nie som az taky pamatnik). Kedze vsak bola iba jedna, ci dve (pricom sme si neboli isti funkcnostou) a nejake naklady na to neprichadzali do uvahy, HW riesenie sme zavrhli. A ako aj pise R - je to zbytocne, ked sa da vela veci riesit softwarovo.
Image - to je dobra pripomienka - nad tym som povodne tiez uvazoval. To by ani nebolo az take tazke... Ja vsak problem toho vidim ten, ze to skratka dlho trva - ovela dlhsie ako moje riesenie (vycistenie uctu trva skutocne len okamih - 2-3 sekundy - samozrejme zavisi od mnozstva faktorov, ale v principe to stroj v podstate nevyradi z cinnosti). Pri imagi by cistenie prichadzalo do uvahy tak raz za den (v noci), kym moje riesenie cisti balast aj niekolkokrat za den (v zavislosti, kolko sa na danom stroji pracuje).
Druhym problemom je to, ze pri nejakych upravach by sa muselo sahat na image a ten nejakym sposobom distribuovat (po sieti). Takto konfigurovat okamzite zive systemy je ovela pohodlnejsie. Skratka na nase potreby sa mi image nezdal vhodny.
Ten SW na ktory odkazujes je tiez zaujimavy - i ked ma jednu nepeknu vlastnost - vyzera dost mrtvo... . Ja som sa tiez povodne hral s nejaky session managerom, ktory vie vytvarat docasne "guest" ucty (asi dakde v /tmp) - teraz si nespomeniem na meno... Ale nakoniec som si povedal, ze spackam daco - jasne, ze kym sa to vymyslelo, urobilo a odladilo, tak to chcelo nejaky cas, ale clovek sa nieco naucil
.
Tmpfs by bolo fajn, ak je dost pamate - ono to vsak nemusi byt vzdy tak (a vieme kolko pamate zozeru dnesne prehliadace a web) - I ked by sa pamat zase mohla swapovat spat na disk . Uzivatelia u nas nemaju pristup ku pocitacu samotnemu - sahaju iba na klavesnicu a mys - stroj je zamknuty v skrinke, cize tie PC bezia viec-menej stale - museli by sme riesit planovany restart. Ale toto je skvela myslienka - v buducnosti, ked sa to vsetko postupne obmeni za novsie masiny s viac RAM by to stalo za zvazenie
.
Centralizovana predloha uctu niekde na servery je tiez zvadzajuca - na to som uz tiez myslel. Povodne som vsak nechcel miesat do toho server (ako pisem v blogu) - i ked by to samozrejme mnohe zefektivnilo.
Vdaka za skvele podnety.
Jednak to zrýchli aj starý počítač, pretože všetky zápisy sú smerované do RAM,které mívají staré počítače plný kotel.
btrfs subvolume
?
Pri prihlasovaní urobiť niečo takéto:
umount /home/guest mount /dev/kde_je_btrfs /mnt/btrfs btrfs subvolume delete /mnt/btrfsguest btrfs subvolume snapshot /mnt/btrfs/guest-template /mnt/btrfs/guest umount /mnt/btrfs mount /home/guest # v /etc/fstab nakonfigurovaný subvol=guest na pripojenieKeď bude treba niečo upraviť, tak si pripojiť
subvol=guest-template
-x, --ephemeral If specified, the container is run with a temporary "btrfs" snapshot of its root directory (as configured with --directory=), that is removed immediately when the container terminates. This option is only supported if the root file system is "btrfs". May not be specified together with --image= or --template=. Note that this switch leaves host name, machine ID and all other settings that could identify the instance unmodified.Šlo by to udělat tak, že by na počítači byl jen malý systém s ssh, rsyncem a systemd-nspawn kontejnerem. V kontejneru by byl celý desktop a při odhlášení by se kontejner prostě ukončil a s ním by automaticky zmizel i btrfs snapshot. Jako bonus je zde lepší oddělení uživatele od systému, což snižuje jeho šanci na provedení permanentních změn. Při troše snahy by se takto dal udělat i multiseat.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.