Какие вопросы вам задавали на собеседованиях на должность линукс админа, помощника админа и т.п., всё что связано с линуксами?
Собираю базу вопросов с собеседований, думаю, будет полезно новичкам, да и в целом интересно почитать. Вопросы выложу в открытый доступ по ссылке. Просьба также указывать должность, на которую подавали.
Мой любимы вопрос на собеседовании обычного одмина: при попытке создать файл (#cat /dev/zero > /root/newfile , например) получаем ошибку "No space left on device", при этом #df - h бодро рапортует о том, что метса на разделе, где лежит /root ещё дофига. Что проверить, где искать, как фиксить. Это более узкое изложение вопроса 6 по ссылке.
Имхо, правильно будет проверить количество свободных инод по #df -i и тогда все сразу станет на свои места. Да и вопросы, кстати, не совсем по девопсу. Так... по системному администрированию. Если пойдут вопросы по CI/CD, AWS, K8s, ELK и так далее - тогда да, девопс.
Боюсь, что годы профдеформации и приобретенная мизантропия не самый лучшие помощники в планомерном наставничестве. Да и круг моих знаний наверняка поменьше, чем у присутствующих тут пикабушников :) Но помочь в меру сил, времени и желания - эт можно.
написал - обычный одмин. да, подразумевались иноды и #df -i покажет. С моей точки зрения - без минимального фундамента нет никакого будущего ни в инфраструктурном сисадминстве, ни девопсе, ни в облаках. Дальше - уже идут более высокоуровневые вопросы - админам про бекап и права, девопасм про кубершифты и ci/cd, облачникам - про золотые образа и постнастройку, хоронителям - про дедуп и мультипафинг, хэпэцэшникам про тороидальные сети и латенси. итд итп от профиля емплоя и емплояра
Кто все эти люди? О_О Не, я конечно допускаю мысль, что где-то в крупных корпорациях такое узкое разграничение и существует... в моих реалиях - это все один человек, максимум два... Которые и сисадминят, и девопсят, бекапируют и т.д.
Ну у нас, например, три сисадмина (каждый со своим уклоном), три сетевых инженера, и это ещё не считая программистов, техподдержки и прочих околопричастных.
Контора не очень большая, узкоспециализированный провайдер.
Круто когда так.. Специализация всегда хорошо. А мне вот чаще приходится цеплять только основное со всех направлений и доучиваться уже в ходе процесса либо необходимости.
Ну, в SMB и не-IT ынтырпрайзах многостаночники это вполне себе выход - автобусное число >=1, нолаж шаринг итп работают как надо. Если сеть растет - то начинается делёж - вот эти 2+ человека лучше шарят в этом направлении - вот они пускай и занимаются им, другие - чем-то другим (т.е. появляются группа по сетям, группа по микросервисам, группа по корпоративному софту). Если речь идёт о IT-компаниях, требуется хорошая специализация - где-то нужны хайлоады и дба, где-то нужны адские хэпэцэ чтоб считать погоду и сворачивать белки в головах материаловедов. Иногда доходит до того, что группы разрастаются до отделов и дальше выделяют уже внутри отдела шарящих в конкретной теме. На экстенсивном развитии, как мне кажется, сильно далеко не уедешь - лучше оттачивать один удар миллион раз, чем миллион ударов - по одному разу.
О, я такой глюк ловил, когда отвалилась на время сетевая шара, куда бэкапы складывались, и они некоторое время валились в /mnt/backup :). Потом шара подмонтировалась, и опаньки :). Место вроде есть, но его нет :))).
Я попробовал сформулировать вопрос так, чтоб не оставалось поля для других вариантов. Отвал /mnt/backup происходит если используешь СРК от производителей дендрофекальных наколенных скриптов. Не делайте так, пожалуйста.
Представьте ситуацию вы заходите на какой то сервер, корень занят на 100%, "No space left on device", inode полно свободных. Начинаете искать тяжелые файлы, но их не находите. Что будете делать? Куда делось место?
lsof | grep deleted
Если файл был удален, но все еще открыт каким-либо процессом, он будет продолжать занимать место, пока процесс не будет перезапущен
О, на субботнем дежурстве с таким столкнулся. Уже удалённый atop писал лог в удалённый файл
Ну, такая команда за пару секунд создаёт файл гиг на 5-6, секунд за 30+ вытопчет жесткий диск любого размера.
Файл из /dev/zero надо делать командой dd
окей, немного поправим изначальную команду #touch /root/newfile.txt Тут смысл вопроса был в исчерпании файловых дескрипторов, а не в реальной нехватке места.
Но в реально мире вы, скорее всего, будете получать файл через ^C :wq! Или всякий curl/wget. А touch практически точно покажет окончание именно инод
В реальном мире с этим можно столкнутся либо на системах с офигенно большим количеством мелких файлов либо на VPSках с ограничением inodes. Причем второе наиболее вероятно. Я пока еще встречал "железных" серверов, где они заканчивались, а на VPS - бывало.
В реально мире, такое видал и на физике (какая-то поделка на похапе генерила файло и не удаляло, аптайм уже не помню), потом посыпались сервера, хорошо, под рута было зарезервировано 5% места и инод. Find-delete помог.
Q: Does the filesystem have an undelete capability?
There is no undelete in XFS.
However, if an inode is unlinked but neither it nor its associated data blocks get immediately re-used and overwritten, there is some small chance to recover the file from the disk.
photorec, xfs_irecover or xfsr are some tools which attempt to do this, with varying success.
There are also commercial data recovery services and closed source software like Raise Data Recovery for XFS which claims to recover data, although this has not been tested by the XFS developers.
As always, the best advice is to keep good backups.
Официально - нет. Но можно попытаться с помощью photorec, xfs_irecover или xfsr
GNU/Linux
1.2K постов15.6K подписчиков
Правила сообщества
Все дистрибутивы хороши.
Будьте людьми.