Что должен знать системный администратор linux junior

Вопросы на собеседовании младшему Линукс админу

Коллеги, подскажите, хочу уйти в линукс админство. Какие вопросы меня могут ожидать, какие бы вы задавали джуну? Мне 24 года, вроде еще не старик. Полагаю есть компании которые берут джунов. (Москва) Сейчас работаю шивой — и хелпдеск линукс и виндоус и свичи настроить и вай-фай. Но специализация вроде как решает. И по деньгам и по востребованности. По инструкции раскатывал рабочие места с chef-сервера, поднимал заббикс-прокси, добавлял oid итд, хосты, шаблоны итд. Настраивал оповещения. В процессе самообучения поднимал Gitlab, Zabbix. Сейчас активно изучаю Ansible. И какую ЗП писать в резюме? Сколько могут платить джуну?

Перемещено leave из job

Чтоб мне такие джуны попадались.
Ты скорее ближе к миддлу.

Приходили тут ко мне синьоры-помидоры, не слышиавших половину тобой перечисленных слов.

берешь свою ЗП, плюсуешь к ней 50-100к, и публикуешь.

У меня сейчас 60 000, судя по НН.ру я едва в джуны кажусь. (или это замысел корпораций завышать требования? :D) А уж 50-100 это вообще смешно. Или это троллинг(

У джуна больше оценивают желание работать и адекватность в целом (поэтому не стоит говорить, что зарегистрировался на лоре).
То есть, спрашивая «как настроить $featurename в $distroname» оценивают скорее общую толковость ответа, а не то, знает ли кандидат конкретно это. Ну а в целом кэп подсказывает, что спрашивают то, что актуально в конкретной компании.
Зарплату в резюме писать не надо вообще, её обсуждают на собеседовании. Опять-таки, в нормальных конторах понимают, что джун едва ли может дать оценку своим навыкам с учетом особенностей рынка, города и конкретной конторы и не будут ловить на недооценке/переоценке себя любимого.

Это даже не заговор корпораций — это как правило тупоголовость HR, которые вбивают в требования все когда-либо слышанные аббревиатуры.

160 — мало? в чем ты заподозрил троллинг?

Вот типичный пример https://hh.ru/vacancy/30974177 тут тебе и кубы и докер и базы данных и питон веб-сервера и все это 93 до налогов (

Какие вопросы меня могут ожидать, какие бы вы задавали джуну?

Подготовь парочку показательных примеров, что ты сделал интересного на своей работе за прошлые полгода.

Собеседующие обычно тыкают вопросами куда попало наугад. Если видишь что попадают не туда, вполне нормально сказать мол, занимался не этим, давайте лучше расскажу про то, чем занимался. Правда тогда уж эти темы действительно надо понимать, чтобы не получилось так что даже в той теме которую ты сам выбрал ты совсем не разбираешься.

Ну и имхо то что ты описываешь это не то чтобы джун уже. Так что не надо напирать на то что «Я только учусь» и «не судите строго», а стоит выбирать нормальные вакансии и собеседоваться по-взрослому, а дальше тебе при оценке зп скажут считают тебя джуном или как.

так это не по твоей области. там и программирование, и базы данных

Результат выполнения следующих команд

И будут искать мидла на джуниора

Собеседовался в Екате в Альфу, спрашивали очень много, по зп средне для города, офисное здание прям не вызывает желание работать. Может в Москве у них получше.

По инструкции раскатывал рабочие места с chef-сервера, поднимал заббикс-прокси, добавлял oid итд, хосты, шаблоны итд. Настраивал оповещения. В процессе самообучения поднимал Gitlab, Zabbix.

Самый лучший способ разобраться и научиться — сломать что-то, и починить, разобравшись в работе софта, или же воссоздать реальный функционал. Поднять заббикс нетрудно, однако писать шаблоны, знать его возможности и способы применения в работе, это уже сложнее.

Сделайте тестовую среду, ее и показывайте на собесе, мол, вот тут я применял это и то.

или это замысел корпораций завышать требования?

не слышиавших половину тобой перечисленных слов.

интересно как ты думаешь если админ юзал puppet, справится ли он с ansible ?

а тебе нужны пионеры?

В обратную сторону не сработает, а в эту вполне.

Иди на мида. Стандартный стек вопросов: показатель лоад авг, ввод/вывод, зомби, иерархия процессов. Это на каждом собесе спрашивают.

. И ещё в копилку: последовательность загрузки ОС с вариативностью по глубине допроса, malloc/fork etc, различия между nginx и apache, межпроцессное взаимодействие, устройство фс, устройство памяти (резидентная, виртуальная итд), что-нибудь сравнительно примитивное по сетям в разрезе администрирования, часто контейнеры/cgroups.

Это так, что на память пришло из собеседок прошлых лет. Вообще многое зависит ещё и от профиля. Кому-то нужен уклон в мониторинг, кому-то в инфру с опытом траблшутинга аппаратных проблем в линуксе, кому-то нужен виртуальщик, кому-то уклон в сети а кому-то в бд. От вакансии все-таки зависит.

Какие вопросы меня могут ожидать, какие бы вы задавали джуну?

Обычно спрашивают базу, а ля «если у меня load 5, это хорошо или плохо» и «пишет no space left on device, что делать?» и «df -h показывает дофига свободных гигов, и всё равно no space left on device, почему?» ну и прочая классика а ля «free -m показывает, что нет свободного рама»

Бывает говорят «у меня сервер не работает, почини» и смотрят на твои обьяснения. Такие вопросы задают, что бы посмотреть действуешь ли ты по шаблону который выучил в саппорте или пытаешься думать мозгой и прочими частями тела.

Потом просто углубляются в то, что у тебя написанно в резюме, дабы понять, действительно ли ты работал над тем, что у тебя там написанно или просто рядом стоял.

По инструкции раскатывал рабочие места с chef-сервера

Ожидай вростов на тему что такое шеф и с чем его едят. Если будешь знать что-то большее, чем как толкнуть конфиги на клиенты, тебе это будет бонусом.

Из джуна который делает все по инструкции и не интересуется большим, сложно вырастить толкового админа.

Если ты в девопсы метишь, помимо понимания шефоансиблей, от тебя будут хотеть знаний гита, а ля обьясни разницу между git merge и git rebase.

Вопрос на самом деле выявляет хреновых девов, но когда админ не отвечает на такое, общее впечатление всё равно портится.

Серьезно? Когда админ не отвечает на » объясни разницу между git merge и git rebase», то админу это в минус?

интересно как ты думаешь если админ юзал puppet, справится ли он с ansible ?

Потенциально любой может справиться с чем угодно.
Однако работать надо здесь и сейчас, а не когда-нибудь потом, когда справится. Если для джуна или миддла несоответствие заявленного в CV еще может считаться приемлемым, то для синьоров — нет.

А у меня общее впечатление портится, когда Senior DevOps понятия не имеет про tcpdump и strace.

И так, в итоге по моему вопросу подтвердите или опровергните/добавьте: — на джуна в принципе можно идти, если руками делал перечисленное и в теории могу рассказать что и как работает (хотя бы общие принципы) — писать в резюме то что реально делал (вопрос имеет ли смысл писать то что просто учил?) — если на собеседовании спросят про деньги и работодатель сам первый не назовут цифру, то 60-80 тысяч можно просить? — готовиться к основам, всевозможные флаги к типовым командам, типа ls, rm, netstat etc..

В Юбисофте было в минус.

ЗЫ: гитовые вопросы для девопсов. Если собеседуют админа на позицию админа, про гит спрашивать не будут.

угу. и про load ответить не могут)

в этой профессии 24 — уже много. я в 21 был джуном, кто-то в 18 начинает.

По инструкции раскатывал рабочие места

чтобы там господа выше не отписали. важно не то, сколько умных слов ты знаешь или какой софт смог настроить по инструкции, а насколько у тебя есть общетеоретические знания. меня бесят технари, которые все настраивали, но не в состоянии сразу назвать уровни OSI (ну можно где-то замяться, но идея применительно к tcp/ip+arp должна быть ясна), описать tcp хендшейк или работу arp-протокола. короче, будет зависить от того, куда ты пойдешь. пойдешь в торговую фирму — там всем пофиг. пойдешь к айтишникам, могут ожидать, что ты кроме рук имеешь еще и голову.

Подготовь парочку показательных примеров, что ты сделал интересного на своей работе за прошлые полгода.

Ну и имхо то что ты описываешь это не то чтобы джун уже.

ну да, то есть если у него полгода опыта настройки софта по инструкциям, то вы его к своим серверам на федоре пустите?) ну да, а че, всеравно ведь ломаются)

Источник

25 вопросов задаваемых на собеседовании системным администраторам Linux

Вопрос:2 Как узнать когда файловая система проверялась последний раз?

Вопрос:3 Как изменить срок действия пароля пользователя без изменения самого пароля?

Вопрос:4 Как заставить fsck проверить файловую систему ОС при следующей перезагрузке?

Вопрос:5 Каким инструментом анализируются дампы краха системы или файл vmcore в ОС CentOS 7 & RHEL 7?

Вопрос:6 Как установить все патчи за исключением патчей ядра в CentOS и RHEL?

Параметр ‘–exclude=kernel*’ команды yum позволяет установить все патчи кроме предназначенных для ядра. Например так:
# yum update –exclude=kernel*

Если добавить следующую строку в файл ‘/etc/yum.conf’ мы предотвратим любые обновления ядра навсегда:
exclude=kernel*

Вопрос:7 Как проверить, что вы работаете на физическом или виртуальном сервере?

Вопрос:8 Что такое automounter и для чего он служит?

Вопрос:9 Как принудить пользователя изменить пароль при регистрации?

Вопрос:10 Как узнать как завершилась последняя команда — успешно или нет?

Вопрос:11 Как узнать, установлен ли конкретный rpm-пакет?

]# rpm -q postfix –last
postfix-2.10.1-6.el7.x86_64 Saturday 27 February 2016 11:56:43 PM EST
[root@cloud

Для этих же целей мы можем воспользоваться командой yum:
[root@cloud

]# yum history package postfix

Вопрос:12 Как войти в режим одиночного пользователя (single user mode) в RHEL 7?

Вопрос:13 Какая команда позволяет изменить имя хоста навсегда в CentOS 7 & RHEL 7?

Команда ‘hostnamectl’ используется для задания или изменения имени хоста. Например, так:
# hostnamectl set-hostname «New_HostName»

Кроме hostnamectl могут быть использованы команда ‘nmtui’& ‘nmcli’, которые тоже могут изменять имя хоста в CentOS 7 и RHEL 7.

Вопрос:14 Как включить политики паролей (password policies) в Linux?

Вопрос:15 Как узнать, какие модуля ядра загружены в ОС Linux?

Вопрос:16 Какой командой можно проверить состояние ввода-вывода в Linux?

Вопрос:17 Каково назначение файлов ‘/etc/lvm/backup’ и ‘/etc/lvm/archive’?

Вопрос:18 Как просмотреть таблицу маршрутизации в Linux?

Вопрос:19 Что происходит на фоне когда вы заходите по ssh на сервер Linux?

/.ssh/known_hosts’ мы получим подсказку ssh.

Вопрос:20 Как изменить порт по-умолчанию для SSH на сервере Linux?

Вопрос:21 Как увидеть временные метки dmesg в RHEL7?

Вопрос:22 Как узнать модель физического сервера из командной строки?

С помощью команды dmidecode можно узнать производителя и модель физического сервера. Например:
# dmidecode -t system
…

Handle 0x0011, DMI type 1, 27 bytes
System Information
Manufacturer: HP
Product Name: ProLiant DL580 Gen8
Version: P79
Serial Number: CKX42926E0
UUID: 97387735-1541-238A-1B33-533850564430
Wake-up Type: Power Switch
SKU Number: 728551-B21
Family: ProLiant
…

Вопрос:23 Как узнать версию BIOS сервера из командной строки?

С помощью команды dmidecode можно получить версию bios:
# dmidecode -t bios
# dmidecode 2.12
SMBIOS 2.8 present.

Handle 0x0010, DMI type 0, 24 bytes
BIOS Information
Vendor: HP
Version: P79
Release Date: 04/01/2014
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 16384 kB
…

Вопрос:24 Как расширить существующую группу томов lvm?

Вопрос:25 Как посмотреть номер WWN на карте HBA на сервере Linux?

Существует как минимум, два способа с помощью которых можно узнать номер WWN для карты HBA.

Первый, с использованием команды systool. Например так:
# systool -c fc_host -v | grep «port_name»

Второй способ — просмотреть содержимое файла классов в файловой системе sys:
# cat /sys/class/fc_host/host*/port_name
0x7001639028cbeca0
0x7001639028cbefa2
0x7001639028cbf5d8
0x7001639028cbf6da

Источник

Что должен уметь Linux-администратор

Visitors have accessed this post 4781 times.

Linux — это та операционная система, с которой вы точно будете работать в любой современной IT-компании. Знание ее изнутри, навык работы с ней при помощи разных инструментов — это тот фундамент, который поможет вам в дальнейшем развиваться в любом направлении IT.

Давайте посмотрим, какие шаги проходит в своей работе, что должен знать Linux-администратор.

Итак, что же нужно знать начинающему Linux-администратору? Предлагаем рассмотреть сразу на примере.

Допустим, у нас есть проект – нам нужно создать с нуля инфраструктуру Digital-агентства.

К вам пришел друг и говорит: «Хочу открыть Digital-агентство! Умею делать сайты и рекламу, знаю, где искать клиентов, но помоги настроить инфраструктуру, чтоб все работало, как надо».

Ну что ж, поможем другу и прокачаем свои админские скиллы.

1. Создаем офис

Что такое офис? Принтеры, бухгалтерия, у которой вечно 1С не работает, секретарша Людочка, у которой факс не отправляется, тегание сетей везде и постоянно… Ну да, так бывает. Но мы же грамотные ребята, можем и виртуальный офис сделать (а сейчас это — ой как актуально).

Итак, для нормальной работы нам нужны:

— телефония с гибкими возможностями,

И чтобы все это было защищено, недоступно извне просто так.

Звучит как план. Арендуем железный сервер у надежного поставщика, ставим на него Linux и начинаем:

— Ставим OpenVPN для подключения к инфраструктуре, скидываем другу профиль и инструкцию по подключению. Теперь настраиваем так, чтобы снаружи никто ничего не получил!

— Ставим NextCloud — получаем хранение файлов, CRM систему, вебморду для работы с почтой и все, что нужно для работы.

— Ставим Asterisk, подключаемся к виртуальной АТС. Настраиваем ее другу на телефоне, чтобы он мог звонить через нее. А на прием звонков настраиваем приветствие и автоменю, чтобы выглядеть по-взрослому.

Отлично, теперь можно работать! Но как клиенты узнают о нас? Допустим, у нас есть сайт-визитка, но его надо куда-то выложить.

2. Выкладываем сайт

Файлы у него простые — HTML, CSS, JS, никакого хранения не требуется.

Это мы быстро — берем виртуальный сервер (не наш же суперзащищенный офис использовать!), устанавливаем nginx, закидываем файлы, проверяем по IP-адресу, успех. Но использовать IP-адрес для сайта – как-то не солидно. Покупаем домен, прописываем DNS записи на наш адрес, обращаемся по адресу — успех, красота, хоть продавай!

Но теперь Not secure в Chrome не нравится. Мы же все безопасно делаем. Настраиваем Let’s encrypt для домена, подключаем к nginx и получаем защищенный сайт, который обслуживает себя.

И пошли звонки, но общаться по почте с mail.ru – хммм, не серьезно как-то. Поэтому переходим к следующему шагу.

3. Настраиваем почту для домена

Подключаем домен и управление им к публичной почте (к примеру, Яндекс). Создаем адреса себе, другу, менеджерам, секретарше Людочке, белому медведю Валере и всем, кому требуется, – вот теперь все серьезно!

И вот наконец первые заказы. Но тут мы понимаем, что как-то каждый раз вручную закидывать в базу файлики с прайсами и бланками заказа не комильфо.

4. Автоматизируем выкладку

Сначала все просто — заказываем виртуальную машину, настраиваем на ней nginx, DNS домен клиента уже настроили, Let’s encrypt есть. Осталось главное – контент, который будем выкладывать.

Друг знает один путь — поправил инфу в файлике, отдал тебе, выложили. Изменилась информация – снова по этому же пути. Но вас терять на это время не прельщает.

Поэтому мы, как истинные (=ленивые) администраторы, делаем скрипт, который из директории с NextCloud через rsync синхронизирует файлы на сервер клиента каждую минуту. Проблема вроде бы решена, хотя и пахнет костылем. Казалось бы, что может пойти не так? Вот тут мы уже подходим к серьезной работе, той, что в первую очередь должен знать Linux-администратор.

Проходит время, и клиенту нужно сохранять и отдавать данные, а значит, их нужно где-то писать и хранить. Друг все данные собрал, но вот виртуальный сервер к этому не готов. Опять работа!

5. Делаем базу данных и PHP-FPM

Пока все просто — устанавливаем MySQL, PHP-FPM, настраиваем его на работу с нашим приложением. Затем настраиваем nginx на работу со всем этим добром и готово, живем, как прежде.

Но в какой-то момент друг случайно удалил файлы из хранилища и файлы с сервера пропали тоже (костыль-выкладка выстрелила в ногу. И снесла полголовы), оставляя клиенту голый сайт. Непорядок! Да, данные мы вернули (спасибо Next Cloud за это), но надо что-то менять в нашей системе.

Пожалуй, пора расти технически и нанять PHP-программиста, хорошо бы, чтобы он и в Git умел.

Но для этого нам нужно Git-хранилище – разворачиваем на своем сервере GitLab и переносим туда сайт. Но нужно еще сделать выкладку – теперь по-умному.

6. Автоматизируем выкладку. I’ll be back ©

Пишем через GitLab CI сценарий выкладки, чтобы по коммиту все синхронизировалось также по rsync. Теперь можем в любой момент вернуть старый код, нажав нужную кнопку. Красота!

И тут мы понимаем, что, кажется, чуток заступили на территорию DevOps. Вот это да! Раздуваемся от гордости и думаем, как и что сделать лучше. А тут – epic fail. Данные одного из клиентов в базе данных потерялись! Беда, стыд, позор! Срочно надо сделать так, чтобы данные не терялись или их хотя бы можно было вернуть.

7. Делаем бэкапы

Решаем, что для каждого клиента нужно делать бэкапы базы данных. Не забывай делать бэкапы — одно из правил, которые должен знать каждый Linux-администратор. Код у нас уже хранится в Git, а значит, его в случае чего восстановим. А вот с базой не все так просто.

Для этого арендуем сервер с большими дисками и настраиваем на него бэкапы, которые снимаются каждую ночь с каждого клиента и отправляются на сервер к конкретному пользователю по rsync с глубиной хранения в неделю.

Теперь данные будут в сохранности.

Но неправильно, что о проблеме мы узнали от клиента, а не увидели ее сами. Надо бы это исправлять.

8. Настраиваем мониторинг

Настроим на нашем сервере Prometheus сервер, который собирает доступность сайтов клиентов, сервера и, заодно, проверяет информацию о доменах клиента. С появлением бэкапов бдим и место на сервере. И для надежности делаем так, что в случае чего — в Telegram бот просигналил о беде.

Итак, после всех проделанных шагов мы получили систему, которая работает и принимает заявки клиентов, разработка идет, выкладка работает, мы за всем наблюдаем и спасение базы данных продумали.

То есть, мы сделали защищенный контур компании со всей требуемой инфраструктурой, возможностью подключения новых клиентов, автоматизированной выкладкой приложений, бэкапами и мониторингом доступности. И вполне заслужили звание системного администратора Linux. И конечно, получили базовое представление о профессии (или кто такой Linux-администратор).

От редакции

Если вам интересно посещать бесплатные онлайн-мероприятия по Linux, DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.

Источник