> ... intetd. Tento daemon řídí spouštění všech ostatních daemonů pro síťové služby, třeba i ftp.
opravdu všech? u mě teda ani to ftp ne, jinak třeba o ssh bych pochyboval (viz konec článku) ...
> Telnet je služba poněkud napadnutelná a odposlechnutelná, ...
což třeba telnet over ssl? (ale o upřednostnění ssh se psalo již ve starší diskusi)
> ... použijeme sshd, ale pro jednodušší ovládání teď použijeme telnet.
hm, to je ironie ... jednodušší? ... proč je zprovoznění telnetu věnován skoro celý článek a zprovoznění ssh jen odstaveček?
ad /etc/securetty
- není lepší tady nic neměnit, nalogovat se jako user a použít su?
- Slackware nezná vc?
ad netstat -a
- u mě má (právě teď) výpis 419 řádek, super počtení :-) - myslímže není od věci přidat parametr --inet, unixové sokety nás asi tak moc nezajímají
- můj oblíbený _špinavý_ trik je nmap localhost (zajímá mě obvykle tcp, jinak -sU)
ad restart (x)inetd
- třetí způsob: killall -HUP inetd
- Slackware neumí něco jako "/etc/init.d/inetd restart"? - minimálně bych čekal po zabití (x)inetd nějakou jeho opětovnou inicialisaci (jako nastavení en locales a spuštění démona ... aspoň v mdk to tak je, nevim, (x)inetd nepoužívám, na svém Gentoo-positive routeru se bez něj v pohodě obejdu :-)
poslední odstavec je fakt dobrej :o)
p.s. ale je to docela pruda, když člověk v noci nemůže spát, a přitom už nemá dost energie na to, aby dělal něco rozumnějšího, než blbě kecal :-/
>ad restart (x)inetd
>- třetí způsob: killall -HUP inetd
>- Slackware neumí něco jako "/etc/init.d/inetd >restart"? - minimálně bych čekal po zabití (x)inetd >nějakou jeho opětovnou inicialisaci (jako nastavení >en locales a spuštění démona ... aspoň v mdk to tak >je, nevim, (x)inetd nepoužívám, na svém Gentoo->positive routeru se bez něj v pohodě obejdu :-)
hehe, sorry, ale to fakt nema. Slack uz neni zadne "paci paci" ... jako ani nevidim duvod, proc by tam takovy shitecek a jemu podobne byly. Obvzlaste na routeru(heh, no tak ne no, i normalne). Snad zname prikazy, ne? :) Na druhou stranu to treba urychli praci :) Fakt to tam neni a jsem za to vdecny ;o)
A kdo tady podle vas zabiji inetd? Pokud dobre koukam, tak se tu posila signal HUP procesu(m) inetd, cimz se mu rekne, aby zreloadoval konfiguraci - funguje to i u spousty jinych slusne naprogramovanych daemonu.
Prikazy kill a killall neslouzi jen k zabijeni. Pokud neni receno jinak, posila sice TERM signal, ale muze poslat i jakykoliv jiny. Opravdovi zabijaci maji v oblibe kill(all) -9, ktery misto laxniho TERM posle smrtici KILL. Bohuzel na nemrtve zombie procesy to stejne vetsinou nefunguje...
pardon, nevěděl jsem, jak se inetd po přijmutí sighup chová ... nenapadlo mě nad tím přemýšlet, sighup je odpojení od terminálu, což obvykle znamená konec, ale jelikož je to daemon, nějaký terminál je mu ukradený ... no lehce mi to připomíná situaci, když LiteOn zneužije nějaký atapi příkaz (~ vyhrazený signál), který čtečka nepodporuje (~ daemon "nepodporuje" terminál), k "reloadu" :-) firmware...
schválně jsem se na to podíval na čtyřech systémech (Debian, Gentoo, IRIX64, Mandrake) a ani na jedné ze tří různých verzí manuálové stránky killu se nepíše o tom, jak se daemoni (nebo specielně inetd) chovají, obdrží-li HUP ... (dokonce v jedné verzi je u seznamu signálů poněkud matoucí sloupeček "action" a v řádku HUP je tam "exit")
hm, tak s man signals jsem uspěl jenom na IRIXu ... "SIGHUP The device has been disconnected." - taky nepříliš přesvědčivé ...
ale o to nejde, už jsem přeci dávno přiznal neznalost, nu což, stane se i po tolika letech s linuxem :-) dokonce jsem si i vygoogloval podrobnější informace ... jen mě štve, že někdo říká RTFM, i když v TFM relevantní informace nejsou (nehledě na to, že byl problém už objasněn)
