Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
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ť:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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 strojesystemd.unit=multi-user-rungetty.target, ktorá je predvolená a má parameter --unrestrictedDebian (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:
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.
Tiskni
Sdílej:
/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.
19.2.2017 19:35
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
/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?
23.2.2017 21:18
pavlix | skóre: 54
| blog: 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) 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.
23.2.2017 21:37
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
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
23.2.2017 23:40
pavlix | skóre: 54
| blog: pavlix
24.2.2017 10:34
pavlix | skóre: 54
| blog: pavlix
/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
23.2.2017 23:12
Josef Kufner | skóre: 70
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?"
24.2.2017 10:35
pavlix | skóre: 54
| blog: pavlix
24.2.2017 13:51
pavlix | skóre: 54
| blog: pavlix
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.
24.2.2017 00:44
Josef Kufner | skóre: 70
vim /etc/resolv.conf aha, hmmm, :q vim /etc/foo/bar.conf
23.2.2017 23:08
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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ý.
23.2.2017 23:42
pavlix | skóre: 54
| blog: 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. :)
23.2.2017 23:49
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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.
Každopádně díky za článek!
20.2.2017 14:05
pavlix | skóre: 54
| blog: pavlix
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 .
20.2.2017 19:48
Josef Kufner | skóre: 70
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.
. Zase netreba prehanat a hadzat adminovi polena pod nohy v krizovych situaciach - ale chapem, ako to myslis a viac menej suhlasim.
. Aj ked musim uznat, ze mi sprvu trocha stislo rit. Ale s tou slovencinou by sa bolo treba troska este posnazit .
. 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.
22.2.2017 14:35
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
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.
22.2.2017 15:16
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
.
25.2.2017 12:42
Josef Kufner | skóre: 70
25.2.2017 17:35
Josef Kufner | skóre: 70
23.2.2017 15:03
Josef Kufner | skóre: 70
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
24.2.2017 13:20
Josef Kufner | skóre: 70
-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.