loginctl - užitečný pomocník

8.10.2020 19:35 | Přečteno: 1906× | Za vším hledej Linux |

Člověk se stále učí. S nástupem systemd se objevily nástroje, o kterých mnoho administrátorů nic moc neví, protože se u distribucí bez systemd stejně musí obejít bez nich. O jejich možnostech se pak dozvídají víceméně náhodou, tak jak jsem se o možném využití loginctl dozvěděl já.

Nebudu zastírat, že mi současná situace vyhovuje a nebýt všudypřítomné buzerace spojené s adorací roušek, tak bych řekl: Sláva!

Díky tomu, že studenti byli vyhnáni z laboratoří, jsem mohl na jaře realizovat svůj dlouhodobý plán. Za normálních okolností jsem totiž omezen poměrně krátkým intervalem, kdy lze vrtat do laboratorních systémů, vymezeným koncem zkouškového období a začátkem dalšího semestru.

Nejprve jsem zkonsolidoval laboratoře po hardwarové stránce, o čemž jsem se zde zmínil v blogpostu o záhadném samospouštění počítačů. A pak jsem implementoval několik nových vrstev, kterými je základní disklessový systém modifikován tak, aby bylo (mimo jiné) možné pracovat na laboratorních desktopech vzdáleně. To sebou pochopitelně přineslo otázky, které je nutné řešit.

Problém je, že studenti po sobě neuklízí a opuštěné procesy pak dělají bordel a zbytečně degradují výkon stroje jiným uživatelům. Má to vliv také na konektivitu, protože nejde odpojit uživatelský adresář sdílený přes NFS, a tím že hrabou na stejné soubory, jako instance z jiných strojů vznikají další problematické situace.

Ideální by bylo po ukončení práce stroj restartovat, ale proč by měly ty stroje běžet a žrát energii, když na nich nikdo nepracuje? Ať tak nebo tak, ani jednu z těchto operací nelze provést, pokud na stroji pracuje ještě někdo jiný. Ovšem jak chcete zajistit, aby se ukončily všechny procesy které uživatel spustil pouze v rámci příslušné session? A jak naložit se vzdálenou plochou, kterou uživatel opustil? A co když na ní má rozdělanou práci, ke které se hodlá druhý den vrátit? A jak zamezit tomu, aby si uživatelé lezli na spuštěné plochy ale zároveň mohli stroj vypnout, pokud na něm nikdo jiný nepracuje?

To vše se dá vyřešit a nástroj loginctl je v tomto směru velmi užitečný. Podobně jako u nástroje systemd-analyze, jak uvedl Heron v diskuzi o k blogpostu který nedávno napsal debian+, lze i v tomto případě pomocí parametrů nejenom vytáhnout užitečné informace, ale také situaci řešit.

Do kterého USB portu je píchnutá klavesnice?

Pokud jste dočetli do konce můj březnový blogpost, tak víte jak taková blbost dokáže člověka potrápit. A teď si představte, moje zděšení, když mi v září přišel mail, že v jedné laborce jsou KOMPLET vytahané ze strojů všechny kabely – klávesnice, monitory, myši, napájecí kabeláž i UTP. Netušil jsem kdo a proč tohle zvěrstvo udělal – nehledě na to, že je směrnicí o používání IT laboratoří uživatelům výslovně zakázáno hrabat do kabeláže!

Nicméně jsem viníky zastihnul na místě činu, takže následující odstavec je určen všem co by snad chtěli v budoucnu někde udělat podobnou hovadinu:

Ve zmíněné laboratoři, původně dimenzované na 20 strojů je 40 počítačů, takže pokud se stane, že vypadne proud (jako se to stalo jim) udělají zdroje vypnutých(!) strojů po jeho nahození takový proudový náraz, že to okamžitě vyhodí jistič na chodbě. A přesně to se stalo jim. Chlapci – raději zapomeňme na to, že to bylo na elektrotechnické fakultě – si nevěděli rady, takže pro jistotu všechno vypojili a po nahození používali jen svoje notebooky.

Tak takhle ne!

Není jenom hlavní jistič. Taková situace se řeší tak, že se nejprve shodí všechny jističe v laboratoři. Teprve POTOM se nahodí hlavní jistič a pak se POSTUPNĚ zapínají jističe v laborce. S tím, že se jako první nahazuje jistič na kterém visí switch. Tomu trvá skoro 10 minut, než obživne, takže není kam spěchat.

I středoškolsky vzdělaná lopata jako já ví, že bez konektivity diskless fungovat nebude, takže pokud by nahodili nejprve zásuvky na kterých vidí laboratorní stroje, tak by jim stejně nenajely. Každopádně je to ale rychlejší a šetrnější postup, než znovu zapojit veškerou kabeláž!

Bohužel mnoha lidem nedochází, že dnes na USB visí kde co, takže pokud začne blbnout USB sběrnice, je stroj zralý do šrotu. Takže pokud potřebujete rychle na dálku zjistit do kterého USB portu je co píchnuté, stačí spustit:

$ loginctl seat-status seat0

Poznámka: Těch seat sezení by teoreticky mohlo být více, ale já nikde víc jak jedno u svěřených strojů zatím neviděl.

Kdo mimo mne na stroji straší?

Se dozvíte, pokud předáte parametr list-user, na jehož základě vám vyjede tabulka všech uživatelů, kterým na stroji běží nějaký proces.

A pokud vás zajímá, co má kdo zrovna spuštěné, předejte jeho username parametru user-status, který vypíše strom všech procesů, které si ten uživatel spustil.

Další zajímavé informace vám vrátí parametr show-user. Nejenom čísla všech sessions předaného uživatele (Sessions), ale také číslo session, přes kterou byl spuštěn X server (Display) a také aktuální stav (State). V případě, že je ten uživatel odpojen od plochy, má hodnotu 'closing'. Bohužel ale nemáte šanci v takovém případě zjistit jak dlouho. Více toho může prozradit samotná session.

Takže si to ukážeme na příkladu.

root@k23-187:~# loginctl list-sessions
SESSION    UID USER     SEAT  TTY  
    278 234567 aaaaaaaa       pts/0
    285 345678 bbbbbbbb       pts/0
    291 123456 cccccccc       pts/1
    298 456789 dddddddd       pts/1
    301 567890 eeeeeeee       pts/0
    309 123456 cccccccc            
    315 123456 cccccccc            
    319 678901 ffffffff       pts/2
    328 789012 gggggggg       pts/2
    330 123456 cccccccc            
    334 123456 cccccccc            
    342 890123 hhhhhhhh       pts/0
    346 123456 cccccccc            
    349 901234 iiiiiiii       pts/0
    352 900012 kkkkkkkk       pts/2
    354 123456 cccccccc            
    355 123456 cccccccc            
    363 234567 aaaaaaaa       pts/3
    367 901234 iiiiiiii            
    368 900123 jjjjjjjj       pts/4
    371 900001 llllllll       pts/5
    373 900001 llllllll            
     c1    105 lightdm  seat0      

23 sessions listed.

~$ loginctl show-user cccccccc
UID=123456
GID=10000
Name=cccccccc
Timestamp=Tue 2020-10-06 17:40:32 CEST
TimestampMonotonic=1151881781000
RuntimePath=/run/user/123456
Service=user@123456.service
Slice=user-123456.slice
Display=354
State=active
Sessions=355 354 346 334 330 315 309 291
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=no

~$ loginctl show-session 354
Id=354
User=123456
Name=cccccccc
Timestamp=Thu 2020-10-08 10:36:09 CEST
TimestampMonotonic=1299219108396
VTNr=0
Remote=yes
RemoteHost=192.168.136.200
Service=sshd
Scope=session-354.scope
Leader=1062713
Audit=354
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
LockedHint=no

~$ loginctl user-status cccccccc
cccccccc (123456)
           Since: Tue 2020-10-06 17:40:32 CEST; 2 days ago
           State: active
        Sessions: 355 *354 346 334 330 315 309 291
          Linger: no
            Unit: user-123456.slice
                  ├─session-291.scope
                  │ ├─ 298151 /usr/bin/python3 /usr/bin/xpra start
                  │ ├─ 298152 /usr/lib/xorg/Xorg-for-Xpra-S298141 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home.nfs/cccccccc/.Xauthority -logfile /run/user/483818/xpra/Xorg.S298141.log -configdir /run/user/483818/xpra/xorg.conf.d/298151 -config /etc/xpra/xorg.conf -depth 24 -displayfd 6
                  │ ├─ 298173 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
                  │ ├─ 298196 /usr/libexec/gvfsd
                  │ ├─1138246 /opt/WindRiver/workbench-3.3/dfw/x86-linux2/bin/dfwserver -protocol mi -io sockets -useregistry -session dfw-wb336-cccccccc -registryhost 127.0.0.1 -ls+ /home.nfs/cccccccc/WindRiver/workspace_new/.metadata/.plugins/com.windriver.ide.target/dfwserver.log -lt+ /home.nfs/cccccccc/WindRiver/workspace_new/.metadata/.plugins/com.windriver.ide.target/dfwstatus.log
                  │ ├─1139187 /opt/WindRiver/lmapi-5.0/x86-linux2/bin/wrlmproxy-5.0.2
                  │ ├─1169825 /bin/sh /opt/WindRiver/startWorkbench.sh
                  │ ├─1169826 /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/wrwb-x86-linux2.gtk
                  │ ├─1169827 /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/eclipse-x86-linux2.gtk -vmargs
                  │ ├─1169851 /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse//../../../../../jre/1.6.0_21/x86-linux2/bin/java -client -Xms40m -Xmx384m -Xverify:none -Dosgi.splashPath=platform:/base/../../../wrworkbench/eclipse/pictures -Declipse.log.size.max=1000 -Declipse.log.backup.max=10 -XX:MaxPermSize=128m -jar /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/p>
-jar /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/plugins/org.eclipse.equinox.launcher_1.3.0.wr.jar -os linux -ws gtk -arch x86 -showsplash -launcher /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/eclipse-x86-linux2.gtk -name Wind River Workbench --launcher.library /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.200.v20120913-144807/eclipse_1502.so -startup /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/plugins/org.eclipse.equinox.launcher_1.3.0.wr.jar --launcher.appendVmargs -exitdata 1760029 -vm /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse//../../../../../jre/1.6.0_21/x86-linux2/bin/java -vmargs -client -Xms40m -Xmx384m -Xverify:none -Dosgi.splashPath=platform:/base/../../../wrworkbench/eclipse/pictures -Declipse.log.size.max=1000 -Declipse.log.backup.max=10 -XX:MaxPermSize=128m -jar /opt/WindRiver/workbench-3.3/wrwb/platform/x86-linux2/eclipse/plugins/org.eclipse.equinox.launcher_1.3.0.wr.jar
                  │ ├─1170148 /opt/WindRiver/workbench-3.3/dfw/x86-linux2/bin/dfwserver -protocol mi -io sockets -useregistry -session dfw-wb336-cccccccc-0 -registryhost 127.0.0.1 -ls+ /home.nfs/cccccccc/WindRiver/workspace_new/.metadata/.plugins/com.windriver.ide.target/dfwserver.log -lt+ /home.nfs/cccccccc/WindRiver/workspace_new/.metadata/.plugins/com.windriver.ide.target/dfwstatus.log
                  │ ├─1170526 /opt/WindRiver/vxworks-6.9/host/x86-linux2/bin/vxsim -f /opt/psr/vxWorks-sim-shm -p 2 -d simnet_nat -size 536870912 -tn vxsim2_0 -add_dev serial0=telnet:40363 -l /home.nfs/cccccccc/WindRiver/workspace_new/.metadata/.plugins/com.windriver.ide.target/vxsim2_0.log
                  │ ├─1186847 /opt/WindRiver/vxworks-6.9/host/x86-linux2/bin/vxsim -f /opt/psr/vxWorks-sim-shm -p 2 -d simnet_nat -size 536870912 -tn vxsim2_0 -add_dev serial0=telnet:40363 -l /home.nfs/cccccccc/WindRiver/workspace_new/.metadata/.plugins/com.windriver.ide.target/vxsim2_0.log -cpu 1 -size 536870912
                  │ └─1186895 tgtsvr.ex -n vxsim2_0 -B wdbpipe -p 2 -V -R /home.nfs/cccccccc/WindRiver/workspace_new -RW -Bt 3 vxsim2_0
                  ├─session-309.scope
                  │ └─607303 /usr/bin/python3 /usr/bin/xpra _proxy :4
                  ├─session-315.scope
                  │ └─658870 /usr/bin/python3 /usr/bin/xpra _proxy :4
                  ├─session-330.scope
                  │ └─702564 /usr/bin/python3 /usr/bin/xpra _proxy :4
                  ├─session-334.scope
                  │ └─704052 /usr/bin/python3 /usr/bin/xpra _proxy :4
                  ├─session-346.scope
                  │ └─823369 /usr/bin/python3 /usr/bin/xpra _proxy :4
                  ├─session-354.scope
                  │ ├─1062713 sshd: cccccccc [priv]
                  │ ├─1062761 sshd: cccccccc@notty
                  │ └─1062762 /usr/lib/openssh/sftp-server
                  ├─session-355.scope
                  │ ├─1063783 sshd: cccccccc [priv]
                  │ ├─1063798 sshd: cccccccc@notty
                  │ └─1063800 /usr/bin/python3 /usr/bin/xpra _proxy :4
                  └─user@483818.service
                    ├─dbus.service
                    │ └─298003 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
                    └─init.scope
                      ├─297975 /lib/systemd/systemd --user
                      └─297976 (sd-pam)

No a tím jsme vyčerpali vše, co může s loginctl běžný uživatel dělat. A přiznám se, že největším zklamáním pro mne bylo, že s jeho pomocí nelze zjistit jak dlouho ta vzdálená plocha na stroji straší, bez toho že by tam někdo něco dělal.

Naštěstí existují i jiné nástroje. Kupř. přes last (součást instalačního balíku util-linux) si můžete zjistit, kdy se uživatel cccccccc hlásil na konzoli, a kolik na ní strávil času.

~$ last | grep cccccccc
cccccccc pts/0        192.168.136.200  Wed Oct  7 16:44 - 16:47  (00:03)
cccccccc pts/2        192.168.136.200  Wed Oct  7 14:05 - 14:06  (00:01)
cccccccc pts/2        192.168.136.200  Wed Oct  7 10:57 - 10:57  (00:00)
cccccccc pts/1        192.168.136.200  Tue Oct  6 17:45 - 17:47  (00:01)
cccccccc pts/2        192.168.136.200  Tue Oct  6 17:40 - 17:40  (00:00)
cccccccc pts/1        192.168.136.200  Tue Oct  6 17:40 - 17:41  (00:00)
cccccccc pts/4        192.168.136.200  Mon Oct  5 19:41 - 19:41  (00:00)
cccccccc pts/0        192.168.136.200  Mon Oct  5 16:48 - 16:48  (00:00)
cccccccc pts/0        192.168.136.200  Mon Oct  5 02:03 - 02:04  (00:00)
cccccccc pts/0        192.168.136.200  Mon Oct  5 00:45 - 02:01  (01:15)
cccccccc pts/0        192.168.136.200  Mon Oct  5 00:09 - 00:09  (00:00)
cccccccc pts/0        192.168.136.200  Sun Oct  4 23:46 - 23:47  (00:01)
cccccccc pts/0        192.168.136.200  Thu Sep 24 00:14 - 00:33  (00:18)
cccccccc pts/0        192.168.136.200  Wed Sep 23 17:07 - 17:10  (00:03)

Jen pro ilustraci uvádím, jak by to vypadalo, kdyby ten uživatel byl zrovna přihlášen:

~$ last -R | grep llllllll
llllllll pts/5        Thu Oct  8 16:31   still logged in
llllllll pts/0        Thu Oct  1 10:31 - 10:47  (00:16)

Jaké má páky root?

Tak především má root možnost prostřednictvím loginctl vraždit uživatele i jednotlivé sessions.

Kromě příkazu last má k dispozici také lastcomm, nástroj z instalačního balíku acct, takže může zjistit jakou operaci naposledy uživatel spustil a kdy. Bohužel to neloguje akce z prostedí X serveru, jen ty co byly spuštěny na konzoli.

Nicméně root také vidí procesy všech uživatelů a může se na ně i přepnout, takže lze napsat skript, který umí přes utilitu xssstate (u debianu je součástí instalačního balíku suckless-tools) zjistit, jak je to dlouho co uživatel naposledy v rámci spuštěné vzdálené plochy provedl nějakou akci (hnul myší, nebo něco napsal). Výstup pak vypadá takto:

~# remote-desktop list idle
:1 xpra     ffffffff     26
:11 xpra     llllllll    0
:2 xpra     gggggggg     23
:3 xpra     bbbbbbbb     44
:4 xpra     cccccccc     1
:5 xpra     dddddddd     46
:6 xpra     eeeeeeee     24
:7 xpra     hhhhhhhh     20
:8 xpra     iiiiiiii     2
:9 xpra     aaaaaaaa     4

Na základě uvedeného výpisu ihned vidíme, které plochy jsou určené k popravě: 1, 3, 5, 6, – za uplynulých 24 hodin na nich jejich uživatelé nehnuli prstem. Ale než je odděláme, zjistíme jestli náhodou tito uživatelé nemají puštěnou ještě jinou session.

~# for i in ffffffff bbbbbbbb dddddddd eeeeeeee ; do loginctl show-user -p Name -p Sessions $i; done
Name=ffffffff
Sessions=319
Name=bbbbbbbb
Sessions=285
Name=dddddddd
Sessions=298
Name=eeeeeeee
Sessions=301

Jak vidno, můžeme je bez obav přes loginctl sejmout. Musíte ale použít parametr kill-session, terminate-session na to není dostatečně silný. A druhá smyčka se postará od korektní odmountování sdílených adresářů popravených uživatelů. Těm co s adresářem pracují a mají v běhu ještě nějakou jinou session zůstane adresář připojen.

~# for i in ffffffff bbbbbbbb dddddddd eeeeeeee ; do loginctl kill-session $(loginctl show-user --value -p Sessions $i) ; done
~# for i in $(ls -1 /home.nfs/) ; do umount /home.nfs/$i ; done
…
~# remote-desktop list idle
:11 xpra     llllllll    0
:2 xpra     gggggggg     23
:4 xpra     cccccccc     1
:7 xpra     hhhhhhhh     20
:8 xpra     iiiiiiii     2
:9 xpra     aaaaaaaa     4

       

Komentáře

[trekker.dk]

nehledě na to, že je směrnicí o používání IT laboratoří uživatelům výslovně zakázáno hrabat do kabeláže!

Asi měli pocit, že to omezuje jejich svobodu, tak to ignorovali.

Každopádně je to ale rychlejší a šetrnější postup, než znovu zapojit veškerou kabeláž!

Uživatel nemá na jističe co hrabat. Skoro bych řekl, že kdo na to není explicitně proškolen, porušuje bezpečnost práce.

[prqek]

Tak nějak. I kdybych tomu všemu rozuměl sebevíc, tak na cizí jistič bez jasného povolení sahat nebudu. Zvlášť když problém vyřeší notebook, který mám s sebou. Všechno vypojit mi nepřijde jako zas tak zvláštní postup, když nevím, proč to vypadlo. I když vytahovat v takové situaci klávesnici je znakem neznalosti. Ovšem očekávat od někoh rozumnou manipulaci s jističema, když mu zakazuju manipulovat s kabelem od klávesnice, je taky zvláštní přístup.

[Aleš Kapica]

Uvažuješ stejně jako ti, co si myslí, že titul a praxe v oboru dávají automaticky patent na rozum.

To, že víš jak se věci mají dělat ještě neznamená, že to máš dělat. Což někteří lidé opravdu mají problém pochopit, takže se diví, když odmítám takové situace řešit vlastní iniciativou. Na druhou stranu není od věci upozornit "odborníka", když něco dělá tak, jak by dělat neměl. A bohužel dnes je doba, kdy ve stále větší míře platí, že co si neohlídáš, to ti ojebou. Čest výjimkám!

[prqek]

Uvažuješ stejně jako ti, co si myslí, že titul a praxe v oboru dávají automaticky patent na rozum.

V které části toho, co jsem napsal?

Že odmítám sahat na cizí jističe?

Že odpojení zařízení mi nepříjde jako úplně špatný nápad?

Nebo, že když někomu zakážu odpojit klávesnici, tak očekávat od něj iteligentní chování je nekonzistentní?

Nebo v něčem jiném?

[Aleš Kapica]

Uvažuješ stejně jako ti, co si myslí, že titul a praxe v oboru dávají automaticky patent na rozum.

V které části toho, co jsem napsal?

Myšleno tak, že automaticky předpokládáš, že povolaná osoba dělá věci správně.

Ve skutečnosti je vysoce žádoucí dávat pozor na to co a jak se kdo snaží udělat, protože stoupá procento těch co navzdory předpokladu a získanému vzdělání neví co dělají, případně mají zažité některé návyky za které by zasloužili přes prsty. Uvedu jen jeden příklad za všechny.

U kamarádky na baráku udělal jeden známý, starý, dlouholetý elektrikář zásuvku. Místo aby zazdil metrovou chráničku, kterou by pak protáhnul kabel, zazdil kabel, nachlup dlouhý. Mezi tím se na zeď nalepily keramické obklady, vyrobila linka a když pak teda přišel s tím, že tu zásuvku zapojí, ukázalo se, že je ten kabel mrtvý. A co teď? Čert ví, kam a jak to zapojil. Ale i kdyby se ukázalo, že jen špatně připojil jeden konec kabelu, jsou dráty tak krátké, že si při zapojení nemůže dovolit chybu, protože už nemá co uštípnout. Jenže co když je ten kabel někde zlomený?!

Kdyby nebyl vůl a zazdil tu chráničku, tak by se vytáhl a protáhnul jiný. Jenže takhle by se musela odmontovat linka, rozsekat dlaždice a udělat vše komplet znovu. Takže jak se zdá, bude muset kamarádka oželet zásuvku a natáhnout prodlužku odjinud. Jenže co s tou dírou, ve které trčí dráty?! Dát tam zásuvku jen proto aby to nevypadalo blbě?! To zkrátka nevymyslíš.

A takto bych mohl pokračovat různými dalšími "veselými" příhodami mých známých, napříč všemi profesemi hodiny a hodiny.

[prqek]

Předpokládám kde, v čem? To, že odmítám sahat na cizí jistič neznamená, že předpokládám, že ten někdo cizí by to vyřešil správně.

[Heron]

No někteří lidé jsou prostě nepoučitelní. Takhle známej "síťoval" svůj rodinnej domek, prostě utpčko přelil betonem. Bez chrániček. Když jsem se ho zeptal, co bude dělat, až mu ten Cat5e přestane stačit a bud to chtít vyměnit třeba za optiku, tak mi odpověděl, že stejně používá wifi. Jako ... wtf? Fakt by lidi ubylo, kdyby do každého místa přivedli dvě chráničky? Jednu plnou a druhou jako rezervu do budoucna? Nehledě na to, že se to potom mnohem lépe montuje a spravuje.

[Aleš Kapica]

No to je rodinný domek. Ale když stavěli UCEEB, tak nějaký dement měl výborný nápad tu plastovou chráničku předtím, než ji zalili betonem přišlápnout. Naštěstí to bylo hned u kraje, tak to pak nějak asi vyrubali, ale představte si za kolik mega betonu se takhle vyleje a vy pak zjistíte, že ta chránička není průchozí. A to jen proto, že někdo nemyslel.

[trekker.dk]

tak mi odpověděl, že stejně používá wifi

Tak to je gól. Na druhou stranu wifi s nárůstem rychlosti taky nelení

[OldFrog {Ondra Nemecek}]

Jistič má být proti nepovolané manipulaci zajištěn :) Stačí uklízečka a problém je na světě...

[Josef Kufner]

Třeba jako aby ho nešlo vypnout, když se něco stane?

[Aleš Kapica]

Souhlasím. Taky nikde nepíšu, že by měli na ty jističe hrabat ti studenti.

Jejich povinností je kontaktovat správu budov, a ta vyšle elektrikáře co to nahodí. Ale rozhodně není od věci, aby i laik věděl, co s tím lze v takové situaci dělat.

Když jsem dělal ještě na UMOb Ova-jih, tak tam býval stejný problém. Proto měli úředníci výslovně zakázáno vypínat počítače. Chodili na konkrétní hodinu a když by zapnuli ty svoje kompy naráz, tak by to vyhodilo jističe. Speciálně pro eko šetřílky je zde na místě zdůraznit, že počítač žere nejvíc při startu, takže pro vypnutí musí být důvod - v případě disklessu to znamená, že systém po spuštění bude zaručeně v "blank" stavu. Tj. nehrozí že by na něm přežil nějaký proces, co by odchytával hesla, nebo fungoval jako bot.

[j]

" Tak takhle ne!

Není jenom hlavní jistič. Taková situace se řeší tak..."

Ne, takhle se to vazne neresi. Jednak studenti (pripadne zamestnanci) nemaji vubec co lizt do elektrickych rozvodu, coz jistice jsou. Druhak se ma nakopat rit tomu debilovi (tobe?) kterej pripustil, ze zatizeni rozvodu je vetsi, nez kolik rozvod unese. A hned podruhy je treba nakopat toho (tebe?) kterej ma switch hozenej nekde na skrini/pod stolem a nema ho na UPS.

Jinak odpojeni/pripojeni USB zarizeni je ciste user vec, a zakazovat neco takovyho muze leda debil. Na druhou stranu pokud si nekdo mysli, navic jeste na elektrofaktulte, ze tim vyresi vypadly jistic, tak je debil dvojnasobnej a nema tam vubec co pohledavat (a presne takovyho vysledky nase skolstvi produkuje, tohle je krasna ukazka, jak elektrikar nema potuchy o elektrice).

A kdyz uz, tak i prumerne retardovana ovce vi, ze ma ten pocitac vytahnout ze zasuvky (ty elektricky), coz typicky je opet neco co udelat muze.

"speciálně pro eko šetřílky je zde na místě zdůraznit, že počítač žere nejvíc při startu"

Fakt? Takze o tom vis taky naprosty kulovy ze? Tvle jak takovyho lidi vubec muzou lizt sem. Spotreba pri startu pocitace je naprosto nezajimava, a naopak, rozhodne nizsi nez pri zatizeni nejakym provozem. Jistice vypadavaji v okamziku pripojeni zdroje (proto nezalezi na tom, jestli je PC vypnuty nebo zapnuty), protoze v tom zdroji jsou kondenzatory, ktery se nabijej, a i decko z matersky skolky vi, ze takovej kondenzator si proste veme to, co mu draty dovolej => z hlediska rozvodu to jde prakticky do zkratu.

U starsich zdroju tenhle problem samozrejme nastaval az v okamziku, kdy ho uzivatel fyzicky pripoji do site = prepnul ten vypinac. Novejsi jsou v siti trvale.

A takovyhle zdroje samo nejsou zdaleka jen v pocitacich, ale dneska uplne ve vsem.

To jestli jistic vypadne nebo ne pak primarne zavisi na tom jak je "rychlej" (charakteristika) (B/C/D), protoze ten proudovej naraz je jen kratkodobej. Coz by opet elektrikar mel vedet a mel zvolit vhodnou variantu, ze?

---

Dete s tim guglem dopice!

[Aleš Kapica]

Sorry, ale mám tisíc chutí nakopat řiť, komu? Tobě! Protože jenom retardovi uniká fakt, že jeden člověk nedělá všechno. Já neřeším ani sítě, ani umístění síťových prvků, ani silové zásuvky, a nikdo se mnou ani nekonzultuje jakým způsobem se budou místnosti využívat. Já řeším jenom a pouze operační systém. A každý normální člověk si také uvědomuje, že je tisíce faktorů proč jsou některé věci jinak než by měly být, a že mnohé postupy jsou vynuceny okolnostmi. Takže si strč svoje rozumy doprdele!

[ehmmm]

Tak to jo. Mam predstavu, ze az budu unavenej praci a vekem, tak taky pujdu nekam delat ajtaka. Nekam do statniho podniku, na duchod idealni. :)

[Aleš Kapica]

Představu mít můžeš.

[+1]

j jen "chytřejší" trdlo

[jiwopene]

Novejsi jsou v siti trvale.

K čemu tam je potom ten vypínač?

[MP]

10 minut nabihani switche? :D

[Aleš Kapica]

Juniper. Užil jsem si s ním za ten rok už spoustu legrace. Kupř. loni se dostával do takového zvláštního stavu, kdy část portů odešla do kopru, ale ty co už byly nahozené fungovaly normálně. To bylo žůžo, zjišťovat kde je problém a pak v průběhu cvičení harašit mezi stoly s vyjevenými studenty se štaflema a pak šátrat hluboko v racku po kabelu, aby bylo možné ten switch zrestartovat. Hučí to při startu jak Jumbo jet a nekecám, 10 minut trvá než obživne. Ten problém vyřešil až upgrade firmware. Řešil to s nimi kolega co má na starosti síťové prvky.

[Aleš Kapica]

Jo a kdybych to neudělal, tak by se mohli sbalit a jít místo výuky na pivo, protože nikdo jiný, kdo by s tím mohl něco udělat na baráku nebyl. Ten kolega mě instruoval co mám udělat po telefonu.

[ewew]

Nepoznám povahu týchto cvičení ale na čas vzdialenej vyuky by nebolo lepšie rovno urobiť hosting vps pre účel cvičení. Odpadla by práca s komplikovaným prístupom z vonkajšiej strany. Ďalšia výhoda je, že ak by vpsku pokazili jednoducho sa vytvorí nová z šablony. Odkladanie práce by bolo riešené pripojením mountu na inom servery s vytvorením UID pre daného užívateľa.

[Aleš Kapica]

Omlouvám, se, ale nemám chuť ale hlavně čas se dopodrobna rozepisovat o věcech, které si můžeš dohledat na internetu. Takže jen ve stručnosti.

Nepoznám povahu týchto cvičení ale na čas vzdialenej vyuky by nebolo lepšie rovno urobiť hosting vps pre účel cvičení. Odpadla by práca s komplikovaným prístupom z vonkajšiej strany.

Ten systém byl primárně určen pro fyzické laboratorní stroje, které z vnější sítě nejsou a nikdy ani neměly být přístupné.

Ďalšia výhoda je, že ak by vpsku pokazili jednoducho sa vytvorí nová z šablony.

A kdo by jako měl dělat kdo a kdy? Máš vůbec představu, kolik je těch studentů a strojů? A kolik by to žralo zdrojů na serverech?

K tomu, aby se "pokažený systém" dostal do výchozího stavu stačí pouhý restart – to si můžeš představit tak, jako kdyby někdo automaticky revertoval ten vps hosting.

Ale ten systém se používá, v různých kombinacích na různých strojích a k různým účelům. Záleží na aktuální potřebě. Kupř. pro lokální použití při zkoušce je k dispozici varianta 'isolate', kdy student má k dispozici veškerý software, ale dostane se pouze na server, přes který se odevzdávají úkoly. Tentýž systém se ale používá i přes wifi na turtlebotech, s nimiž se sice zrovna kvůli aktuální situaci nepracuje, protože mají studenti přístup do laboratoří zakázán, ale mohlo by! Stačilo by jen do příslušné laboratoře umístit kameru a osobu, která by na základě chatu reagovala na požadavky studentů, protože ty turtleboty je nutné fyzicky zapnout a přemístit do arény, kde se s nimi jezdí. A stejný systém obsluhuje i virtuální stroje, které fungují jako ssh proxy.

Požadavek byl aby všichni měli všude stejný systém. Kdybys to řešil přes vps, tak se v tom utopíš.

A co to znamená pro mne? – Řeším pouze jeden systém, na jednom místě a to aniž by to vyžadovalo mou fyzickou přítomnost. Stačí mi k tomu přístup přes ssh.

[ewew]

Z blogu nebolo zrejme o aký typ laboratoria ide. Predpokladal som čiste linuxové zaležitosti.

[Aleš Kapica]

To jsou skutečně čistě linuxové záležitosti. S přechodem na distanční výuku se Windows prakticky přestaly používat. Ne že by to nešlo, ale nedává to smysl, protože aplikace pro MS Windows si studenti instalují většinou k sobě. Diskless jim ale – tím jak je udělaný – zajišťuje prostředí, které mohou rozbíjet po libosti. A prakticky se nějak efektivně nedá hacknout, protože je všechno připojené pouze readonly a změny zapsané do RAM se po restartu zahodí. Lokální disk se využívá jen pro swap. Pochopitelně k sobě do profilu si nějakého trojana mohou zavléct, ale to jsou pouze pracovní profily, takže mohou v takovém případě všechno smáznout. A po přihlášení se jim potřebné soubory co se ukládají do sdíleného profilu založí znova.

No a pak to má i další výhody. Tím že je identické softwarové vybavení a sdílené profily, lze laboratorní stroje využít v případě potřeby i jako renderovací farmu, případně spouštět distribuované výpočty, atp. Využívá se také výhod kontejnerové virtualizace a vyučující si mohou upravovat kontejnery, aniž by hrozilo že tím nabourají systém jako takový. V případě chyby stačí změnit symlink. NFS ze kterého jsou sdílené jednotlivé vrstvy je nad Btrfs, takže se vrstvy před kritickými aktualizacemi snapshotují. Prostě to řešení je vysoce elegantní a jednoduše udržovatelné, ačkoliv se neznalému věci může zdát, že se něco dělá složitě. Osobně jsem hrdý na to, že jsem vytvořil podobnou a troufám si říct že i lepší infrastrukturu, kterou v případě CITRIXU, či RCI plácaly dohromady draze placené týmy programátorů. Pokud by se chtěl někdo pozastavit nad tím, proč to není dispozici podobně jako např. Proxmox mám jednoduchou odpověď – už několikrát jsem zmínil že jsem na tom s multitaskingem na štíru a nemám pod palcem nikoho, kdo by byl schopen uplácat grafická klikátka, jako má kupř. zmíněný CITRIX, která by administraci zpřístupnila i těm, co tomu nerozumí. A CITRIX má ještě jeden nástroj na který mohu jen závistivě koukat – ICA protokol.

[Michal Kubeček]

S loginctl jsem se zatím potkával hlavně v případech, kdy se nějakým způsobem zbláznil screenlocker, takže nešel odemknout a objevila se místo toho hláška, jak ho pomocí loginctl z textového terminálu odstřelit.

[jiwopene]

S loginctl jsem se setkal když mi záhadně padaly procesy po odhlášení.