2016-03-31 въпроси за админско интервю
by Vasil KolevОколо едно интервю, което правих тия дни и понеже един приятел иска да изпитва някакви кандидати при него, реших да измисля малко въпроси като за интервю за админи. Ползвайте на воля :)
(историята показва, че никой от кандидатите за работа не ми чете блога, та няма страшно, че ги публикувам тук)
Въпросите са отворени, донякъде не-напълно зададени – това е полезно, понеже показва как кандидатът мисли и какви уточняващи въпроси задава.
Как бихте реализирали система за backup, на която сървъра не може да прочете данните на клиента (т.е. са криптирани подходящо) и compromise на клиента не води до възможност за декриптиране на backup-ите му?
Ако имате 12 диска, кое е по-reliable – 2 raid масива в raid5 от 6 диска или 1 масив от 12те диска в raid6? Кое е по-производително?
(изобщо, какво е raid6?)
Имате дърво с директории и (много) файлове в тях, как ще намерите кои файлове се повтарят?
(задължително трябва да се знае какво е -print0)
Какви са трите типа ssh тунели? Какво е socat?
(ssh трябва да го знаят всички, socat-а почти на всички някога е трябвал)
Пак към ssh-а, защо не трябва да се логваме на чужда машина с agent forwarding и как точно се exploit-ва?
(това е забавна задача за практическо упражнение)
Защо не трябва да се сверява часовникът на машина с ntpdate, който се пуска от cron-а веднъж на ден/час?
При смяна на DNS запис с TTL от 3600 секунди, колко време отнема да се научи от 90% от internet? 95% ? 99% ? 100% ?
(същия въпрос за 60-секунден TTL. Bonus points, ако споменат на БТК/vivacom малоумните resolver-и)
Защо на натоварен linux сървър не трябва да има swap?
(не мисля, че е само за linux, но трябват малко тестове още за останалите)
Какво е rollback plan и кога трябва да имаме такъв?
(bonus points за “винаги”)
Защо не трябва да се смесват различни модели/производители на дискове в един и същи raid масив?
Каква е разликата м/у strace и ltrace?
Какъв е основният протокол за контрол/комуникация с мрежови устройства?
Защо не трябва да се филтрира цялото ICMP?
Как можем да сменим root паролата на linux-ка машина, като имаме достъп до конзолата?
Как можем да направим това трудно/невъзможно?
Защо не се ходи с къси гащи в datacenter?
Предимства и недостатъци на hardware и software raid?
Инструменти за анализ на натоварването на машина, кои в кои случаи се ползват?
Tags: работа
March 31st, 2016 at 09:22
Нищо не разбирам от админстване, но знам защо не се ходи с къси гащи в дейта център :)
March 31st, 2016 at 09:38
Веднъж ходихме на такова място и колегата ме пита защо си нося пуловер в раницата посред лято. После се зарече да си взима и той след като мръзна вътре 2 часа. :D
March 31st, 2016 at 14:18
Друг интересен въпрос, който може да се използва:
Защо setuid на shell скрипт (и въобще всичко със shebang) е глупава идея?
March 31st, 2016 at 14:34
@antfarmer, тук има измъкване, май shell-а винаги прави seteuid(getuid()), и реално няма начин да работи setuid-а… Същото е с perl и компания, та винаги интервюирания да каже “щото не работи” :)
March 31st, 2016 at 22:59
Бах, ако аз ти дойда на интервю няма ма земеш :)
March 31st, 2016 at 23:24
@drago, ми разбира се, ти сигурно и fizzbuzz не можеш да напишеш :P
April 1st, 2016 at 16:07
“Имате дърво с директории и (много) файлове в тях, как ще намерите кои файлове се повтарят?”
find ./ |xargs –replace=as basename as|sort|uniq -c|grep -v ‘\s1\s’|awk {‘print $2’}|xargs –replace=as find ./ -name as
Не знам какво е -print0, ама не е ли супер бързо и елегантно решение :)
April 1st, 2016 at 16:25
@gat3way, твоето решение намира файловете със същото име, не същите файлове :)
Иначе, -print0 на find предава аргументите разделени с \0, така че интервали, кавички и т.н. не правят проблем (например
find . -type f -name \*txt -print0 |xargs -0 rm
е правилния начин, защото ако нямаш -print0 и файл с интервал в името, ще се издъни).
April 1st, 2016 at 19:08
Ааааа уф аз не съм разбрал заданието :)
April 1st, 2016 at 20:38
https://github.com/jbruchon/jdupes
April 2nd, 2016 at 13:45
Добре, аз всъщност мога да отговоря на почти всички въпроси (значи ми е останало нещо в главата от годините в които админствах, старшият едно време обясняваше че нямало да стане така тая работа и щом веднъж си се хванал на хорото ти оставало доживот, прав е бил :) ). Единствено (и вероятно доста глупаво) ми е чуденето около това със синхронизацията на времето като cronjob, какъв точно е проблема с това? Имам някакви теории, ама знам ли. Всъщност вкъщи хостовете ми така се сверяват, аз ги админвам доста мърляво в интерес на истината, но и не се сещам да се е омазвало нещо по този параграф. Но като се има предвид колко време имам да им обръщам внимание…знам ли :) Не си спомням навремето как сме ги синхронизирали честно казано, което е малко странно.
Заради “коректността” на timestamp-овете в логовете ли е проблема?
April 2nd, 2016 at 13:58
@gat3way, проблемът е най-вече, че това мърда рязко часовника на машината, което в някои случаи може да доведе до пускане на някой cron два пъти,например. Виждал съм и доста софтуер, който се обърква от резки скокове на часовника (едно време wget-а crash-ваше при връщане на времето назад, например). Правилният начин е с някой ntp daemon (ntpd или нещо такова), който да бърника бавно скоростта на часовника и така да намества времето.
April 2nd, 2016 at 14:21
Това не трябва ли да има относително радикален drift за да се случи? Но пък това с повторното изпълнение на cronjob-ове ми се вижда доста вероятно и не ми се получава сигурно защото си сверявам времето веднъж на денонощие някъде по късните нощи и нямам други cronjob-ове schedule-нати за същото време, та затова и вероятно не съм го забелязвал.
Иначе и аз съм виждал неведнъж софтуер, на който не му понася смяната на системното време – струва ми се че навремето това се случваше по-често от сега, но точно това никога не ми е било особено интересно поле за ровичкане и проучване, та не знам. Доста таймаути по разни системни повиквания (примерно на select()) са реализирани на база сигнали (процесът получава SIGALRM след като изтече периода) и ако нещо в ядрото се помаже предполагам може и да не си получат сигнала и да увиснат…но не знам де, може би не е това причината.
April 2nd, 2016 at 15:52
Пък и ntpd-то след известно време работа хваща темпа на изоставане на RTC-то, и е способно дори при липса на мрежа да поддържа сравнително акуратен часовник с разни статистически анализи и прочие.
April 2nd, 2016 at 16:49
Ето ти още една задача, ок ли е да имаш такъв cron?
1 3 * * * ~/do_something.sh
April 2nd, 2016 at 17:35
@gfto, зависи какво ти пише в timezone-а на системата :))))
April 2nd, 2016 at 21:45
Което е правилния отговор ;) А всички знаем, че трябва да пише UTC, ама поне аз не го спазвам.
April 4th, 2016 at 17:09
“Защо не трябва да се смесват различни модели/производители на дискове в един и същи raid масив?”
А не трябва ли? Точки се дават ако измисли причина да отговори положително на това правило, или ако каже: “Всъщност, е тъкмо обратното.”? :-)
April 4th, 2016 at 17:20
@basstoon, проблемът е, че латентността на същото място за различните производители на дискове е различна, и това води до силно утрепан performance от raid масива. Представи си как четеш един stripe от няколко диска, и да seek-нат до същото място им отнема различно количество време – тогава ще дойде за по-дългото от времената. За това препоръката е да се взима същия тип/модел диск, но от различни серии на серийните номера (и дискове, които са мислени за raid контролер и имат предвидима/точна латентност).
April 4th, 2016 at 17:39
Не съм гледал данни от тестове, но ако сложиш половината дискове по-бързи, не вярвам това да направи масива по-бавен. Ако ще гледаме дали “чашата е наполовина празна”, е друг въпрос… В “марковите” машини масово идват смесени дискове в масивите. И не можеш да избираш модел. Обикновено е ентъпрайс диск от определен клас, където разликите между производителите са малки. Тунинговане на машина (еднакви дискове, разлини партиди) е леко overkill… Проблемът да се счупят всичките дискове “едновремено” е далече по-лош вариант от 5% разлика при 100% натовареност.
April 4th, 2016 at 17:51
@basstoon, трябва да хвана един приятел, който беше борил конкретно тоя проблем (особено с WD дисковете, които идея си нямаха за константна латентност) и който беше видял някакви разлики от типа на 50% разлика в performance заради такива неща. Иначе, аз от марковия хардуер, който съм пазарувал не съм виждал да има такива разлики (т.е. дисковете винаги са същите), но той и не е толкова много, а за останалите случаи и по-големите поръчки съм си специфицирал дисковете, и не е било особен проблем.
April 4th, 2016 at 20:33
Относно дисковете, трябва да се има предвид, че уж еднакви по размер дискове от различните производители, а често и от един и същи производител, но от различни типове/серии (hdd/ssd, черна/зелена серия, sata/sas…), имат малки разлики в броя на байтовете/секторите, които са несъществени при самостоятелна употреба, но могат да доведат до проблеми в масиви. Кой ще каже какво ще стане, ако в един масив заменим най-малкия диск с по-малък?
Ако се използва софтуерен масив и масивът се изгражда от дялове (sda1/sdb1), а не дискове (sda/sdb), могат да се оставят 100-ина MiB незаделени, които да служат като защита в такива случаи. При хардуерен масив се надяваш firmware-а да го направи вместо теб… А! Май тръгнах да засягам и предпоследния въпрос :)