Úprava systému pre nasadenie do internetovej kaviarne.

19.2.2017 18:00 | Přečteno: 1830× | poslední úprava: 19.2.2017 17:54

Sem-tam je treba upraviť operačný systém, aby na jednom užívateľskom účte pracovalo viacero ľudí, ale zároveň sa tento účet efektívne čistil od balastu jednotlivých používateľov. V práci som sa svojho času venoval niečomu podobnému, nuž som si povedal, že sa podelím zo skúsenosťami.

Ako som myslím písal v niektorom z predchádzajúcich blogov, pracujem na štátnej univerzite. Na chodbách prevádzkujeme verejné počítače, ktoré slúžia študentom na mail, web, prístup ku rôznym univerzitným systémom a podobne. Používame na to výsluhové počítače z nášho pracoviska, ktoré takto doslúžia (zamknuté v takých "špeci" skriniach) pekne v teplúčku obalené vrstvou prachu. S takýmito strojmi je však vždy problém - nikto do nich nechce čokoľvek investovať. Preto sa jedná častokrát o staré šunky, o ktoré sa nikto veľmi nestará a ktoré akosi prežívajú zo dňa na deň. O tom, že by sme pretlačili cez nášho nadriadeného network boot a tým pádom by sa do nich investoval aj strojový čas nejakého servera ani neuvažujeme. (Náš riadieľ je veľký byrokrat, ktorý s obľubou dlho na "poradách" vysvetľuje ako sa veci nedajú urobiť.) Preto som sa svojho času rozhodol, že urobíme experiment s Linuxom (v silne M$-positive prostredí) a uvidíme, čo a ako.

Riešil som samozrejme aj morálnu stránku toho, či zverejňovať tieto veci tuná na blogu (nakoľko som to robil v zamestnaní) - z viacerých dôvodov, ktoré priamo v blogu nebudem detailne rozoberať, som sa však rozhodol, že to nebudem považovať za problém - stručne: štátny sektor (peniaze daňových poplatníkov), nedocenenie zo strany zamestnávateľa, zamestnávateľovi z toho neplynú žiadne finančné zisky, nadriadený je riadny k***t, takto to prinesie viac úžitku a vo finále to nie je nič prevratné - je to skôr sumár myšlienok a tipov, ako upraviť systém, nič viac. Tiež upozorňujem, že je to miestami riadne prasácke a je to iste riadna lamerina - primeraná k mojim (vtedajším) vedomostiam a k investovanému času. Veľmi rád však privítam nejaké návrhy v komentároch - zvlášť nápady ako vylepšiť (alebo skôr úplne zmeniť) tie najprasáckejšie časti. Mne osobne to už je v podstate jedno, lebo plánujem z univerzity v dohľadnom čase odísť, ale snáď to prospeje iným.

Požiadavky na systém, výber systému a inštalácia

Operačný systém by mal byť relatívne nenáročný na železo. Mal by to byť kompletný desktopový systém s bežnými GUI aplikáciami (web prehliadač, kancelársky balík, prehliadač obrázkov a PDF, správca súborov, správca archívov, textový editor, kalkulačka, prípadne aj multimédiá a flash). Užívateľ si prostredie môže modifikovať, zmeny však nesmú byť permanentné. Takisto dáta užívateľov sa nesmú ukladať permanentne. Systém by tiež mal fičať autonómne bez potreby ručne do neho nejako zasahovať čo možno najdlhší čas. Užívatelia by nemali pracovať s heslami (autologin). Tiež je dobré mať možnosť robiť zmeny v nastavení lokálne, ale aj vzdialene (SSH, VNC). To, že užívateľ by nemal možnosť dostať stroj do stavu, aby ho nemohol používať iný užívateľ snáď ani netreba uvádzať.

Pri výbere systému som šiel cestou najmenšieho odporu - Debian. Je to univerzálny a dobre prispôsobiteľný systém a navyše sa s ním celkom priatelím. Prostredie som zvolil Xfce - pekné, ľahké a kompletné prostredie s konzervatívnou ergonómiou. Debian som však inštaloval bez prostredia (X-ká, Xfce a užívateľské aplikácie som doinštaloval dodatočne), lebo ak človek zvolí pri inštalácií pracovné prostredie, inštalátor doinštaluje kopu zbytočností (ako napríklad session manager), ktoré sú v tomto prípade zbytočné. Je dobré tiež doinštalovať kadejaké ovládače a moduly pre obsluhu všakovakého HW, lebo u nás to beží na rôznom HW - potom stačí bez problémov systém klonovať a funguje to bez potreby ďalších zásahov. Ďalej som použil následovné balíky, ktoré vo východzej inštalácií nie sú: rungetty, openssh-server, tightvncserver a xprintidle.

Užívateľské účty a ich konfigurácia

V systéme používame priamo účet root pre administratívne zásahy do OS (sudo a podobné veci mi prišli zbytočné) a dva užívateľské účty (user a guest). Účet user slúži ako šablóna (čistý nakonfigurovaný účet) a na účte guest pracujú študenti, ktorý rozbabrú a ktorý treba potom vyčistiť. Účtu guest môžeme pre naše potreby pokojne zamknúť heslo (ako uvidíme neskôr, nie je potrebné sa na neho prihlasovať heslom).

Účet user máme patrične nakonfigurovaný - v súbore ~/.profile máme doplnený následovný kód, ktorým si zisťujeme názov rodiča procesu bash a nasledovne spustíme X-ká (ak sa prihlasujeme lokálne) alebo VNC server (ak sa prihlasujeme vzdialene). Je to v podstate drobnosť, ktorá by nemusela byť, ale je to pohodlnejšie.

ps -o ppid= -o comm= | grep bash | sed -e "s/ *//1" -e "s/ .*$//" | tr -d "\n" > /tmp/procidenv
PARENTID=$( cat /tmp/procidenv ) ; rm -f /tmp/procidenv

ps -o comm= -p $PARENTID | tr -d "\n" > /tmp/procnameenv
PARENTNAME=$( cat /tmp/procnameenv ) ; rm -f /tmp/procnameenv

case "$PARENTNAME" in
"login" ) exec startx ;;
"sshd" ) vncserver -localhost -geometry 1024x768 -depth 16 :1 ;;
* ) exit 0 ;;
esac

Keďže toto chceme robiť iba pri účte user, ktorého konfigurácia sa prenáša na účet guest (a pri účte guest by toto mohlo byť dokonca nežiaduce), máme ešte jeden súbor ~/.profile.guest, kde namiesto spomínaného kódu máme iba obligátne exec startx, nakoľko s účtom guest sa pracuje iba lokálne. Poriadok s týmito dvoma súbormi sa vykoná vždy pri automatickom logine účtu guest, ako uvidíme neskôr.

Tiež máme v účte user nakonfigurovaný VNC server (heslo, spustenie Xfce sedenia a zastavenie VNC servera po odhlásení z Xfce). Neskôr (pri autologine na guest) si opäť ošéfujeme, aby sa táto konfigurácie nedostala do účtu guest.

Konfigurácia systemd a zavádzača

Ako som písal v požiadavkách na systém, potrebujem tri veci: 1. autologin na guest, 2. vzdialené prihlásenie na user a root, 3. lokálne prihlásenie na user a root. Riešil som to tak, že v menu zavádzača si môžem vybrať, či chcem nabootovať "štandardne" a mať k dispozícií login prompt (a ručne sa prihlásiť) alebo či chcem nechať systém nabootovať do autologinu (pochopiteľne, predvolená možnosť). V starších verziách Debianu som to mal poriešené cez dva runlevely. Neskôr bolo treba situáciu vyriešiť v systemd . Riešenie mi príde dosť krkolomné, ale snáď to bolo systémové riešenie. (Musím priznať, že som lenivý naštudovať si systemd naraz do hĺbky a tak sa spolieham, že keď dačo bude treba urobiť, naučím sa to. Dúfam tiež, že dovtedy nič nepojebabrem žijúc v klamných domnienkach.)

Mám vytvorený nový target /etc/systemd/system/multi-user-rungetty.target s týmto:

[Unit]
Description=Multi-User System with rungetty
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

K tomu patrí priečinok /etc/systemd/system/multi-user-rungetty.target.wants, kde sú symlinky presne ako v adresároch /lib/systemd/system/multi-user.target.wants/ a /etc/systemd/system/multi-user.target.wants/ (čiže je to vlastne skoro ten istý target). Vynecháme iba link getty.target, ktorý nahradíme novým service súborom /etc/systemd/system/multi-user-rungetty.target.wants/rungetty.service, kde bude asi toto:

[Unit]
Description=rungetty
[Service]
Type=idle
ExecStart=/sbin/rungetty -u root -g root -w /root/ tty1 /usr/local/sbin/homedircp.sh user guest
Restart=always

Tento nový runlevel na konci namiesto klasického login promptu spustí skript s dvoma parametrami - názvami účtov, ktorý nám zmaže obsah domovského adresára účtu guest a nakopíruje nám tam čistý domovský adresár účtu user. Ďalej tu máme poriešené niektoré detaily, ktoré som spomínal vyššie a aj jednu drobnosť, ktorá sa ešte vysvetlí neskôr. Následne sa logneme na účet guest. Skript obsahuje:

#! /bin/bash

rm -rf /home/$2/*
rm -rf /home/$2/.[!.]*
rm -rf /home/$2/..?*
cp -rP --preserve=mode --no-preserve=ownership --remove-destination /home/$1/* /home/$2/
cp -rP --preserve=mode --no-preserve=ownership --remove-destination /home/$1/.[!.]* /home/$2/
cp -rP --preserve=mode --no-preserve=ownership --remove-destination /home/$1/..?* /home/$2/

rm -rf /home/$2/.vnc/
rm -f /home/$2/.profile && mv -T /home/$2/.profile.guest /home/$2/.profile
mv -T /home/$2/.config/autostart/exvar.desktop.guest /home/$2/.config/autostart/exvar.desktop
chown -R $2:$2 /home/$2/

login -f $2

No a samozrejme máme nakonfigurovaný zavádzač patrične k tomu. S konfiguráciou Grubu sa detailne nebudem zapodievať, len zhrniem, na čo všetko treba myslieť:

• GRUB_DISABLE_RECOVERY=true - recovery kraviny sú zbytočné
• GRUB_DISABLE_LINUX_UUID=true - UUID by len komplikovalo veci pri klonovaní systému na ďalšie stroje
• heslo
• dve položky v menu: jedna pre normálny boot systému a druhá s parametrom jadra systemd.unit=multi-user-rungetty.target, ktorá je predvolená a má parameter --unrestricted

Debian (a odvodené distrá) majú jednu nepríjemnú vlastnosť - pri update sa súbor /boot/grub/grub.cfg svojvoľne prepisuje. Je to (asi) preto, lebo tento súbor nie je určený na ručné úpravy. Bohužiaľ, niektoré veci sa v Grube dajú nastaviť iba tak, že sú natvrdo zapísané do tohoto súboru (napríklad to, pre ktoré položky v menu má platiť heslo a pre ktoré nie). Archlinux má tento problém poriešený, ale v Debiane to vidím ako problém. Preto mám tento súbor skopírovaný (pri update ho nahrám späť). Tiež ešte odporúčam nastaviť práva na konfigy zavádzača: /boot/grub/grub.cfg na 0600 a /etc/grub.d/40_custom na 0700 (lebo hash hesla).

Ďalšie (blbuvzdorné) nastavenia systému

Ešte máme aplikovaných pár nastavení, ktoré by mali brániť tomu, aby užívateľ postláčal nejaké tlačidlá a niečo tým pobabral. Nebudem to rozpisovať podrobne, iba sumár:

• v systemd povypínať viaceré TTY (stačí jeden) a funkciu ACPI tlačítok;
• v systemd tiež používam KillUserProcesses=yes (vysvetlím nižšie);
• v X-kách vypnúť klávesové skratky ctrl+alt+backspace a ctrl+alt+fn;
• v kerneli vypnúť čarovné SysRq klávesové skratky;
• systemd má ešte klávesovú skratku ctrl+alt+delete (myslím, že pre reštart).

Konfiguračnú možnosť KillUserProcesses=yes používam kvôli VNC serveru. Pri vzdialenom prihlásení na účet user sa spustí VNC. Ak odhlásim Xfce sedenie, VNC server sa vypne (je to tak v jeho konfigurácií - viď vyššie). Takto je to žiaduce, lebo keď sa ukončí Xfce sedenie, VNC server už nemá prečo bežať. Ak by som ho teda chcel znova použiť, musím ho ručne spustiť (resp. sa to udeje pri novom logine). Preto namiesto toho neodhlasujem Xfce sedenie, ale iba odpojím VNC klienta (môžem sa hocikedy opäť pripojiť) - rátam však s tým, že pri odhlásení sa VNC server vypne - keby sa tak nestalo, pri novom logine by mi to pyskovalo chyby, ze VNC server už beží a podobne. Skrátka chcem, aby VNC bežal iba vtedy, keď je účet user prihlásený vzdialene.

PolicyKit trampoty

Veľkým problémom je PolicyKit. Umožňuje totiž aj bežným userom vypnúť alebo reštartovať systém. Nastaviť toto mi príde rovnako krkolomné ako vytvárať nový target v systemd.

Najprv si treba prejsť nainštalované PK "akcie" v /usr/share/polkit-1/actions a premyslieť, ktorých nastavenie chceme zmeniť a podľa nich potom vytvoriť konfiguračné súbory /etc/polkit-1/localauthority/50-local.d/*.pkla. Tieto konfiguráky by mali obsahovať niečo ako toto:

[Configuration]
Identity=unix-user:guest
Action=   # doplniť podľa zdrojových akcií
ResultAny=   # doplniť no | yes | auth_admin
ResultActive=   # doplniť no | yes | auth_admin
ResultInactive=   # doplniť no | yes | auth_admin

Položky Identity a Action môžu obsahovať zoznam oddelený bodkočiarkou. Viac na man 8 pklocalauthority.

Pravidelné čistenie užívateľského účtu

Účet guest je dobré pravidelne vyčistiť. Manuálne sa to dá urobiť asi tak, že odhlásime užívateľa guest (resp. odhlásime Xfce sedenie) a o sekundičku sa zase prihlási, čistý ako novorodenec (o to sa postará skript reštartovaný systemd). Toto máme zautomatizované následovne.

V crone spúšťam každú minútu skript, ktorý si overí, ako dlho užívateľ nepoužíva počítač - ak táto doba presiahne patričný počet minút (prvý parameter skriptu), skript odhlási Xfce sedenie. Skript tiež kontroluje, či nie je prihlásený aj iný užívateľ, lebo nie je veľmi žiaduce, aby riešil tieto veci, kým je tam prihlásený správca. (Pôvodne sa totiž uvažovalo o tom, že po vyčistení účtu sa počítač uspí. Neskôr sa toto ukázalo ako nežiaduce - preto mám patričné riadky zakomentované.) Tuná je príslušný skript:

#! /bin/bash

LOGIN=$( w -hs | sed -e '/^guest.*$/d' )
TIMEMS=$( DISPLAY=:0 XAUTHORITY=/home/guest/.Xauthority xprintidle )
TIMEM=$( echo $(( $TIMEMS / 1000 / 60 )) )

if [ -z "$LOGIN" ]
then
	if [ $TIMEM -lt $1 ] || [ -z $TIMEM ]
	then exit 0
	else
		su guest -c "DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=$( cat /tmp/guestvar ) xfce4-session-logout --logout"
		#sleep 5
		#/bin/systemctl suspend
	fi
else exit 0
fi

Komplikácia je zariadiť, aby sa odhlásilo správne sedenie pod správnym účtom. Táto časť je riadne prasácka. Mne to fungovalo iba za predpokladu, že sa zadali riadne premenné $DISPLAY a $DBUS_SESSION_BUS_ADDRESS (a ešte sa použilo aj su). S prvou premennou nie je problém. Druhú som vypľul do súboru /tmp/guestvar pri prihlásení účtu guest - ako vidieť, táto sa následne načítava v skripte.

Problém je nastaviť účtu guest, aby tú premennú do toho súboru vypľul. Ide o to, že sa to musí diať iba pri účte guest (ale nie pri účte user) - no účet guest preberá nastavenia účtu user). Riešil som to nasledovne. Mám drobný skriptík s nasledovným obsahom:

#! /bin/bash

rm -f /tmp/guestenv
echo -n $DBUS_SESSION_BUS_ADDRESS > /tmp/guestvar
exit 0

Cez klikátko v Xfce v účte user som nastavil, aby sa tento skript spúšťal po štarte. Zároveň som však príslušný konfigurák /home/user/.config/autostart/exvar.desktop premenoval na /home/user/.config/autostart/exvar.desktop.guest. Tento súbor sa potom pre účet guest premenuje späť - to je posledná z drobných "opráv", ktoré vykoná skript čistiaci domovský adresár.

Záver

Celé to funguje viac-menej spoľahlivo. Je to určite stabilnejšie a z dlhodobého hľadiska udržateľnejšie ako iné riešenie - nainštalovať Windowsy, naplácať tam kadejaký freeware (s pochybnou licenciou) aby si tam študent ani neprdol (ktorý ale zároveň nahádže polená pod nohy aj správcovi) a prestať sa starať. Ako výhodu tiež vidím plnohodnotné desktopové prostredie, na rozdiel od všelijakých komerčných kioskov bežiacich na prastarých verziách IE a Windows XP, ktoré okrem prehliadania webu (a kopec reklám) neposkytujú nič viac. Tiež si myslím, že prípadné zmeny v konfigurácií sú veľmi pohodlné a je možné ich vykonať bez ohľadu na to, či študent pracuje alebo nie.

V závere ešte zhrniem chyby, ktoré to má a ktoré by chcelo vyladiť.

Export premennej $DBUS_SESSION_BUS_ADDRESS do súboru pre použitie v skripte, ktorý odhlasuje Xfce sedenie. Stačilo by napríklad, aby študent zmazal súbor s premennou (alebo ho zmenil) a celé čistenie účtu zlyhá, pretože už nedôjde k automatickému odhláseniu. Opraví sa to samo pri ručnom odhlásení, ale to si už vyžaduje manuálny zásah.

Druhá vec je spúšťanie skriptu pre čistenie účtu cez rungetty - takto som to používal pri starších verziách Debianu spred čias systemd - vtedy sa to dalo ľahko nastaviť v /etc/inittab - je to teda také dedičstvo, ktoré by sa iste dalo urobiť priamo cez systemd.

Ak dôjde k výpadku elektrickej energie a študent bude svedkom menu zavádzača pri reštarte, ľahko môže stlačením klávesy nechať vysieť stroj v menu zavádzača, pričom k bootu nedôjde (vďaka heslu našťastie neurobí nič iné).

Konfigurácia hesla zavádzača je ďalšia slabina, lebo treba na to myslieť pri aktualizáciách - Debian si prepisuje /boot/grub/grub.cfg a teda môže dôjsť k stavu, že po aktualizácii (a reštarte) zostane boot vysieť a čakať na zadanie hesla (nehovoriac, že menu bude iné ako človek očakáva).

Nuž to by bolo všetko. Vďaka všetkým, čo to vydržali do konca. Verím, že niekto využije moje nápady a myšlienky a zároveň sa teším na podnetnú diskusiu.

       

Komentáře

[tom62]

Přepisování /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.

[⧠ A = 0]

Tak. Pro úplnost se sluší dodat, že (trvalé) úpravy nastavení grub2 se provádějí v /etc/grub.d.

[figliar0]

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?

[smazáno]

Hele, ani se moc nedivim, ze to nefunguje, maintainer grubu na cely grub totiz velice z vysoka kasle.

[Nobody]

Naopak, je to presne to misto, kde delat upravy. Ze si to v nekterych distrech obali vrstvou (nebo nekolika) abstrakce, protoze jim mit konfigurak, ze ktereho se vygeneruje konfigurak, ze ktereho se vygeneruje konfigurak, ktery teprve neco skutecne konfiguruje, pripada jednodusi, nez mit proste konfigurak, je vec druha. Bezna, ale zvrhla.
U Debianu je to az chorobne. Ten pro jistotu co par minut prepise i resolv.conf. A co na to radi kolektivni mozek lidstva na internetu? Chattr +i!!!

[pavlix]

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) abstrakce

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

[⧠ A = 0]

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

[pavlix]

Jasně, takže to tam je popsáno i pro blbce a samozřejmě je tam i informace o tom, který konkrétní nástroj to dělá. Na druhou stranu je otázka, zda to přepisuje tak často, zda je to potřeba a jestli je správný způsob použít chattr nebo prostě vypnout či překonfigurovat tu službu.

[smazáno]

jen misto rtfm "resolvconf(8)" by tam melo byt napsano jak to mas teda editovat

[pavlix]

Vzhledem k tomu, že používáš Debian a jistě jsi četl aspoň základní dokumentaci ke konfiguraci sítě, tak víš, že konfigurace sítě je v /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

[Josef Kufner]

Ono by bylo docela smutné, kdyby se ten soubor neměnil, když se DNS servery mění každou chvíli.

[smazáno]

tak ... a proc trvat na archaickem resolv.conf, kdyz uz je vlastne k nicemu :) ... chtelo by to do glibc zadratovat zavislost na systemd-resolv :P

[Michal Kubeček]

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?"

[pavlix]

Proč ne, já jsem pro, glibc je stejně zkostnatělý projekt, který si zaslouží už jenom umřít. Aspoň by to trošku nakoplo alternativy. :)

[Michal Kubeček]

Já už bych si dneska ale nebyl jistý tím, že by po takovém kroku umřela glibc.

[pavlix]

Já jsem přesvědčený o tom, že by Alpine a Gentoo neumřely, když neumřely doposud. :)

[Nobody]

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.

[Josef Kufner]

Tak si oprav DHCP server.

[Nobody]

DHCP server je virtualni v QEMU, ale tim se nebudeme zatezovat, protoze i kdyz resolv.conf, ktery nejak funguje, je lepsi, nez resolv.conf, ktery nefunguje, podstata problem je v tom, ze Debian prepisuje konfiguraky, coz QEMU nespravi.

[smazáno]

Pritom by stacilo kdyby deb do resolv.conf napsal ... "radeji to uprav tady" misto "rtfm" a nebyl by problem

vim /etc/resolv.conf
aha, hmmm, :q
vim /etc/foo/bar.conf

[Jendа]

nez mit proste konfigurak, je vec druha

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?

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

[pavlix]

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. :)

[Jendа]

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.

[sigma]

On se ten balíček ve výchozím non-expert režimu instalátoru tuším nainstaluje automaticky. Já obvykle debian instaluju přes debootstrap s mininální sadou balíčků, a tam to není.

[Aleš Kapica]

Přijeď se podívat na InstallFest 2017. Třeba zjistíš, že to jde mnohem elegantněji.

[sad]

Zrovna v Debianu 8 (64bit) s xfce mám problém s PDF prohlížečem a Synapticem. Když myší kliknu na horní šipku posuvníků, abych se v dokumentu posunul pomalu nahoru, skočí mi dokument na začátek, šipkou dolu zase skáče na konec dokumentu, takže musím používat klávesnici.

Nicméně by bylo vhodné, pokud linux používáš veřejně, abys podobné chyby vychytal.

[chrono]

Nebude to skôr štandardným správaním sa Gtk3 pri posuvníkoch? (ak ten program používa Gtk3)

[sad]

Standardní chování to nebude. Abych to upřesnil, po kliknutí na šipku posunu buď dojde k takovému skákavému, pomalému posunu, anebo ke skoku na začátek dokumentu. Takové chování jsem zatím zaregistroval jen u Evince a Synapticu, například v Thunaru nebo Firefoxu šipky fungují normálně, prostě dojde k pomalému, plynulému posunu. Zřejmě nějaký konflikt mezi gtk2 a gtk3, ale už jsem našel nějaké návody, tak snad to časem vyřeším.

Mám však takový pocit, že Debian i Ubuntu jsou při určitých operacích nějaký pomalejší (například kopírování souborů z úložných míst, kopírování delšího textu do LibreOffice). Obě distribuce s XFCE byly před pěti lety rychlé jako blesk (rychlejší než KDE4 i než to, co přišlo po GNOME2), proto jsem je používal. Nevím, zda za to může přechod na gtk3, anebo tolik zmiňovaný systemd, nejsem programátor, ale linux se začíná nějak kurvit. Chtělo by to superrychlé, hezké, vyladěné, stabilní, plně nastavitelné, přehledné, funkční, jednoduché grafické prostředí, které by se už neměnilo. Je velký problém něco takového napsat?

[figliar0]

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.

[sad]

Záleží na stylu, jaký používáš, a zrovna ten po instalaci je, myslím, bez šipek. Styl změníš ve Správce nastavení -> Vzhled.

[figliar0]

Nuz zmenil som styl, mam sipky a funguje mi to normalne. Synaptic aj Evince.

[sad]

Tak gratuluju

[Pan_Filuta]

Zdravím, mám trochu OT. Jak se kavárenské počítače řešili třeba přes 10-15 lety? (Třeba i Windows) Mám matnou vzpomínku, že jsem viděl nějaké HW řešení (kartu?) která zajišťovala, že se po každém restartu nahraje čistý image. Hádám že později se přešlo na SW řešení využívající obnovení stínové kopie atd.

Jaké jsou argumenty proti řešení cestou image, případně třeba (https://www.howtogeek.com/59839/how-to-reset-any-changes-to-your-ubuntu-computer-and-add-kiosk-mode/ ) Laicky mi přijde, že popsané řešení muselo dát hrozně práce Každopádně díky za článek!

[R]

Ta HW karta nerobila nic, len obsahovala BIOS, ktory vedel ten image prepisat. Uplna zbytocnost.

S modernym OS je image nezmysel - staci nepustit pouzivatela zapisat nic mimo svojho home adresara, ktory sa po kazdom odhlaseni vymaze.

[pavlix]

Tím už bych se dnes nezabýval. Ten image se klidně může dát na disk, na flashku nebo bootovat ze sítě. Nebo může být nainstalovaný normální systém a všechno potřebné mountované do tmpfs.

[figliar0]

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 .

[Honz]

A co na to Pražská kavárna...?

[...]

je zacyklená - celou noc čumí na cnn co dělá Trump a vymýšlí jak to co nejhůř (pro něj) okecat a ve dne jim nezbývá u síla sledovat co podle nich dělá špatně Zeman - a jak už to takhle trvá skoro měsíc, tak už jsou z toho tak mimo, že to jejich třídním bojem oslabená tělíčka prostě nedávaj :(

zatracenej časovej posun :(

[Josef Kufner]

Asi bych šel spíš cestou tmpfs v /home (jako overlay přes defaultní profil) a /tmp, vše ostatní pak nechat read-only. Docela slibně vypadá overlayroot. Na tlačítko reset bych pak přidal cedulku "Start here", takže by čištění systému bylo velmi spolehlivé a rychlé (se systemd to nabootuje za pár sekund).

Docela se mi líbí myšlenka dvou účtů, kdy je možné se do předlohy přihlásit a upravit ji. Na druhou stranu mi přijde, že by to nemělo být nikdy potřeba. Ty počítače by měly sdílet nějakou centralizovanou předlohu, která by se do nich automaticky nakopírovala. Přihlášení by tedy bylo přímo na účet guest, ale na jiném (virtuálním) počítači. Tím by také odpadlo šaškování s "run-levely" a zobrazování nabídky Grubu (rychlejší boot). Možná by mohlo být zajímavé si pohrát se secure bootem, aby studenti nemohli nabootovat něco jiného.

[figliar0]

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.

[Kate]

Pokud vím, pokud tmpfs nemá místo v paměti, swapuje se prioritně a RAM tak neubere aplikacím.

[R]

Tiez by som tam nenechaval ziadne moznosti v grube ani moznost ineho prihlasovania. Akekolvek upravy by som robil cez SSH - a kedze je tych PC viac, tak skriptom.

[figliar0]

Ale zase niekedy nie je odveci mat zadne vratka, keby sa daco pototo . Zase netreba prehanat a hadzat adminovi polena pod nohy v krizovych situaciach - ale chapem, ako to myslis a viac menej suhlasim.

[šéf]

Stavte se zajtra u mňa v kancelárii a probereme si toho kokota.

[figliar0]

Fu. Tak ten bol dobry . Aj ked musim uznat, ze mi sprvu trocha stislo rit. Ale s tou slovencinou by sa bolo treba troska este posnazit .

[Michal Kubeček]

Tohle byl podle všeho vtip, ale na vašem místě bych se nad tím zamyslel. Už jsem se bohužel setkal s tím, že se našli lidé, kteří si dali práci s dohledáním kontaktu na nadřízeného někoho, s kým se na nějakém fóru nepohodli, aby mohli nabonzovat, že dotyčný pravidelně píše příspěvky v pracovní době a případně i co tam o tom nadřízeném napsal.

[figliar0]

Hej, hej - to my povedala aj priatelka . Uplne to chapem - ale nasho sefa by bolo treba zazit. A ja mam taku filozofiu - ked je dakto k****, tak je k**** - ziadnym inym slovom sa to nazvat neda. A ja za to nemozem - za to aky je si moze sam (a tuto moju filozofiu a svoj nazor na neho som mu aj naznacil). (A uvedomujem si aj fakt, ze s touto filozofiu v dnesnom svete daleko nezajdem.) Ale diskusia o nasom sefovi vlastne nema vyznam, ak ho tuna nepoznate - na univerzite sa drzim zatial iba preto, lebo som riesil ine veci v zivote a na riesenie novej prace mi uz nezostavala energia - ale aj to raz pride . Ale aj tak vdaka za dobre mierenu radu.

[Jardik]

Co kdyz uzivatel soubor /tmp/guestvar smaze?

[figliar0]

Vtedy sa to pototo. Spominam to v zavere ako jednu z chyb. Tuto cast by bolo dobre este doladit (resp. mozno prerobit).

[filodendron]

Než si zlepil toto svoje riešenie, vyskúšal si napríklad fsprotect? (... alebo bilibop)? Možno by si potom prišiel na to, že do internetovej kaviarne je najlepší nejaký overlayfs... Jednak to zrýchli aj starý počítač, pretože všetky zápisy sú smerované do RAM, a jednak sa systém dostane do pôvodného stavu po každom resete.

[⧠ A = 0]

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.

[Aleš Kapica]

Ehm. Při použití disklessového linuxu na prohlížení webu někde v kavárně 1GB paměti stačí. A to už by byla opravdu pravěká herka, aby to mělo míň. I když samozřejmě - čím víc paměti, tím lépe! Optimální je NFS diskless, na stroji co má 8G RAM a na disku pouze swapovací oddíl.

Instalovat cokoliv rovnou na stroje je konina!

[⧠ A = 0]

Příloha:

• firefox-RAM.png (5951 bytů)

S linksem možná .

[Aleš Kapica]

Příloha:

• screenshot_2017-02-22_21-06-40.png (1315 bytů)

Opera 12.16 sestavení 1860 Linux x86_64, 4.8.0-1-amd64

Otevřených 27 listů, mailový klient s cca 17 tisíci zprávami (nejstarší z dubna 2001).

[radix]

To je 4 roky stary browser. Uz ted na tom nepojede spousta webu, davat to ted do pocitacu (kde to bude dalsich X let) mne prijde jako blbost.

[Aleš Kapica]

Nejedou na tom akorát weby, které dělají prasata. A na takové ani nemám potřebu chodit. S korektními weby není absolutně žádný problém.

[Josef Kufner]

Myslíš například trojrozměrné mapy? Nebo cokoliv, co používá nějakou z novějších technologií, ať už multimediálních, tak bezpečnostních — např. CSS3, videa, CSP, PKP?

[Aleš Kapica]

99% času trávím čtením webů, kde nic z toho není zapotřebí. A na to zbylé 1% nemám problém použít jiný browser. Osobně nechápu jaký reálný smysl má použití 3D map, když to stejně funguje jen na mizivém území. Podobně to vidím i s ostatními technologiemi. K čemu to, když většina lidí má problém pochopit a správně použvat i základní atributy CSS.

[Josef Kufner]

To mizivé území je mnohem větší, než se zdá. Použití jiného browseru v kontextu internetové kavárny je poněkud mimo.

[neasi]

Napleš Kapuca je mimo skoro vždy, takže to není nic nezvyklého.

[Aleš Kapica]

Tos mi to teda nandal babráku.

[Aleš Kapica]

Do systému pro internetovou kavárnu bych samozřejmě dal Firefox. K takovému účelu bohatě postačí. Ovšem do komfortu původní Opery mají všechny browsery pekelně daleko.

[Käyttäjä 11133]

640kB paměti musí stačit každému.

[JS1]

Pokud mas Beowulf cluster tak rozhodne!

[figliar0]

Musim sa trocha s hanbou priznat, ze overlayfs ma vobec pri tom nenapadol (pritom mam v podstate podobnu vec doma na routri a casto som o tom rozmyslal, aky je to skvely vynalez). Ked tak rozmyslam nad tym, ako by sa to dalo cele vylepsit, najlepsia sa mi zda kombinacia overlayfs pre /home a predloha uctu centralne niekde na servery, ako navrhoval Josef Kufner. Vdaka za tie typy - fsprotect vyzera aj velmi jednoducho na implementaciu (co som az prekvapeny).

[Josef Kufner]

Predlohu udělej pro celý systém, nejen /home, abys mohl snadno aktualizovat.

[čavo]

A čo tak skúsiť 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 pripojenie

Keď bude treba niečo upraviť, tak si pripojiť subvol=guest-template

[Josef Kufner]

man systemd-nspawn:

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