Штошь, не ждун.
В ИТ уже 18 лет.
Локация МО.
Вакансии на 95% составлены из нереальных требований, где ты и жнец и кузнец (эникей, админ, сетевик). Это удручает. Компании экономят.
В нашем мире выгодней быть узким, нежели универсалом (почтовый админ, админ по виртуализации, сетевик). К сожалению.
Ого-го-шечки, подержите мой чаёк...
Вот, например, мои умения и опыт в IT:
Операционные системы:
от Microsoft любые (DOS, Windows, Mobile), Linux любые (в т.ч. МСВС), также работал с Free(Net|Open)BSD, OS/2, AIX, Solaris и прочей теперь уже экзотикой. С продукцией Apple не работал, но, при необходимости, освою без труда. Имею опыт администрирования и поддержки серверов размещенных на colocation (более 20 лет).
Программное обеспечение:
HTTPD(Apache), Nginx, MySQL, PHP/PHP-FPM знаю очень хорошо. Почта на Postfix, Exim, Dovecot хорошо. PostgreSQL хорошо (с Oracle плотно не работал но понимание имею). Прикладное графическое ПО типа Photoshop/Corel хорошо, но без креатива (к сожалению не художник). Для масс задач умею и предпочитаю применять command-line решения, например, ImageMagic и FFmpeg. Unix shell знаю, но для задач автоматизации предпочитаю использовать PHP (мне так быстрее и проще).Программирование:PHP+Smarty, MySQL, SQLite, JS+JQuery, HTML – владею профессионально.
Какие либо фреймворки не использую (ибо есть свои наработки), но, при необходимости, освою быстро. Знаю Java, Perl но без практического опыта. Модный Python и прочее, уверен, освою за пару недель.
Прочее:
Имею опыт выполнения и оформления результатов НИР, НИОКР и ОКР (участвовал в разработках в интересах МО РФ), опыт разработки технической документации, в т.ч. по ГОСТ (ТЗ, проектная документация и т. д.), есть многолетний опыт сопровождения ПО, опыт руководства коллективом.
Знание языков:
Русский - родной. Английский - техническую документацию читаю свободно, разговорный и письменный - слабо (нет практики). Немецкий - читаю со словарем.
Ну что, гожусь я на джуна?
А вот хуй. Мне 56 лет и поэтому иду я нахуй везде, на мои резюме просто не отвечают.
Как мне пройти собес?
Менеджер паролей — это программа для хранения логинов и паролей в зашифрованном виде. В результате данные будут защищены, а вам достаточно запомнить 1 пароль.
Глобально, менеджеры паролей можно поделить на 2 вида: облачные и локальные. Облачные хранят пароли у себя на серверах и поэтому очень удобны; локальные же менее удобны, зато их нельзя взломать. Я использую KeePass уже 7 лет и не представляю, как жить по-другому. В этой заметке я расскажу о 3х менеджерах паролей, которые использовал сам.
Созданный в 2003 году, бесплатный KeePass с годами завоевал множество почитателей. Работает предельно просто: база данных — это зашифрованный файл, открываемый мастер-паролем. Файл можно хранить на флешке или в облаке, типа Яндекс.Диска, тем самым обеспечивая кроссплатформенность. Есть улучшенная версия — KeePassXC, использующий такую же базу данных, но более красивый. Рекомендую попробовать его.
➕Бесплатно; локальная база данных (paranoid mode); доступно множество плагинов
➖Не особо удобен — из коробки нет интеграции с браузером и кроссплатформенности. Нет общих сейфов и немного устаревший интерфейс.
Сравнительно новое решение на рынке — бесплатный менеджер паролей с открытым кодом. Пароли хранит у себя на серверах, но можно сделать собственный. Параноики ликуют. Интерфейс поприятнее чем у KeePass, но всё ещё не очень удобный. Платные тарифы дают доступ к дополнительным функциям. Есть семейный тариф за 40$ в год.
➕Бесплатно, опенсорсно, кроссплатформенно. Есть общие сейфы.
➖Неинтуинивный интерфейс, пароли хранятся в облаке.
Настоящее интерпрайз решение для хранения паролей. Тут тебе и удобный интерфейс и синхронизация всего со всем и шеринг паролей. Всё красиво и современно. На мой взгляд — лучшее, что есть на рынке. Можно купить семейный тариф за 5$ в месяц.
➕Удобно, красиво, современно. Кросплатформенно и есть общие сейфы.
➖Довольно дорого стоит, не работает в России. Код закрыт и пароли хранятся в облаке.
Заведите менеджер паролей. Это реально удобно и безопасно. Только выбирайте тщательно. Например, сервис LastPass взламывали 4 раза и я вам не рекомендую (запрещаю) его использовать.
Хочу настроить себе сервер для Bitwarden. Всё-таки автозаполнение в браузере и кроссплатформенность делают своё дело. Ставь лайк, если хочешь почитать про настройку своего сервера :)
В телеграме — еще больше контента.
Вопрос кто сталкивался с таким что возникает ошибка при добавлении пользователей в biz.mail.ru, он же VK Workspace.
Дано порядка 70 пользователей на старой почте, при импорте ошибка у пяти штук - невозможно добавить. Начал вручную и понял что если в имени есть admin то ни в какую не добавит. А так же если urist2oz, urist3oz и urconsul. А вот urglav и urdelo спокойно добавляются.
Техподдержка не отвечает.
Что за алгоритм такой который не даëт на своём домене заводить пользователей?
Привет.
Я уже пару лет являюсь тимлидом команды DevOps, проводил несколько десятков собеседований и хотел бы поделиться опытом.
Данным постоя я хочу "закрыть гештальт" и написать о том, на что обычно обращаю внимание при собеседовании кандидата на позицию джуна, что именно "идёт в зачёт". Ппост возможно будет интересен тем, кто только пробует себя найти в IT и задумывается "а как ещё улучшить навык проходить собеседования"? Ну и составлен он будет в виде короткого списка правил, которого придерживался бы я, если бы пытался найти работу на должность начинающего специалиста в IT.
Факты - важнее тысячи слов. Огромное количество людей указывают в навыках то, что они знают буквально никак. Речь именно о навыках и я приведу пример. У нас был кандидат который описал в навыках "Протокол DHCP". На резонный вопрос - "а как происходит получение реквизитов клиентом, опиши схему?" я услышал что кандидат просто настраивал получение реквизитов на Linux и Windows машинах. Ну и зачем ты указывал как навык то о чем не имеешь представления? Ты можешь описывать свой опыт любыми прекрасными словами, самыми красочными выражениями, но стоит понимать что если компании не плевать кого они возьмут (а ведь есть и такие конторы, когда нужно скинуть кучу работы на того кто работает за еду и туда могут взять), впечатление о тебе составят на основании того как ты ответишь на конкретные вопросы и сможешь "ответить за базар" - за то что указано в резюме. Отсюда совет - указываешь технологию в резюме - расскажи её сперва кому то из окружения. Тут и польза и перепроверка себя. Хотя конечно всегда есть шанс что не спросят.
Во время собеса при решении задач - рассуждай вслух. Казалось бы зачем? Ответ прост - задача джуна в перспективе стать мидлом и тд. Для этого нужно уметь решать задачи самостоятельно (по факту это на 80% и отличает джуна от остальных позиций). И если ты перед сложностями просто останавливаешься, пытаясь накидывать какие то предполагаемые ответы к которым пришёл каким то образом в голове - это не всегда хорошо. Есть вероятность что в затруднительных ситуациях тебя придётся вести за руку, доводя до решения. Возможно есть сложности с построением логической цепи от задачи до решения при недостатке исходных данных.
А если ты рассуждаешь, показывая как именно происходит мыслительный процесс, то во первых - тебя могут поправить на какой то стадии решения задачи, что позволит дать правильный ответ если решение в голове складывалось не так. Во вторых - рассуждающий кандидат располагает к себе намного больше стеснительного молчуна. Данный совет можно использовать как хитрость - если даже известен точный ответ, но ситуация располагает к разговору - можно рассказать как прийти к ответу, а не просто выдать его. Это 100% сыграет в плюс.
Улыбайся. Чаще всего люди любят когда их не боятся. Умеренная улыбка и шутки (в меру) располагают к себе. Улыбающийся кандидат заставляет подсознательно снимать риск что будут проблемы с коммуникациями в команде, что сыграет в плюс. Кроме того - улыбка прямо влияет на то, каким тоном ты говоришь - сложно говорить зажато не улыбаясь. Речь конечно не о том чтобы хохотать на собеседовании, просто стоит хотя бы вежливо улыбаться.
Формулировки - очень важны. Я бы сказал крайне важны. Если я ведя диалог с кандидатом услышал что то, что он сказал не подумав и ошибочно - я обязательно зацеплюсь за сказанное и постараюсь конкретизировать вопросы именно на ошибке, чтобы понять "как глубока кроличья нора". При этом я не скажу что кандидат ошибся до того момента, пока не проясню все что интересует. В эту ловушку попадаются очень многие, когда одно - два слова брошенных необдуманно там, где важна чёткая формулировка заваливают весь ответ. Дело не в том что я плохой, дело в том что зачастую у кандидатов отсутствует база. И вот такие ошибки это выдают. А моя задача как интервьюера эту базу прощупать со всех сторон. Отсюда вывод - если вопрос формата "а как работает эта штука" или "как сделать вот это" - подумай секунду-две перед тем как отвечать, сформулируй ответ из тех фактов, в которых ты уверен на 100%. Это не даст тому кто проводит собеседование "цепляться" за пробелы в знаниях.
Техническое обеспечение. В 99,9% случаев у нас собеседования - это удалённый формат, созвон по зуму например. Если ты идёшь на собеседование в IT компанию - не надо подключаться с телефона, открой собес на компьютере. Нет камеры? Включи камеру на телефоне одним сеансом и поставь его на стол, а с компа подключись вторым и смотри на тех с кем разговариваешь. Невозможно давать какие то задания на собеседовании когда кандидат с трясущегося телефона в руках зажимая микрофон что то рассказывает. Жутко бесит.
Ну и последнее сейчас что приходит в голову, но наверно это не про то как пройти собес, просто на что стоит обратить внимание уже тебе - адекватная уважительность. Раскрою что имею в виду - с одной стороны ты пришёл искать работу в компанию и тебя собеседуют специалисты которые чаще всего знают и умеют больше тебя, возможно намного. С другой стороны - лично тебе сейчас эти люди вообще никто. Вы собрались поговорить о тебе, твоих навыках, перспективах и о том что может дать их компания опять же лично тебе (на вопрос что ты можешь дать компании ты не сможешь ответить, идя на позицию джуна). Не надо в общем относиться к интервьюерам с опаской или чрезмерным уважением, но и фамильярничать не стоит. Чаще всего в нормальных компаниях стараются выстроить диалог так, чтобы поставить на один уровень всех участников собеседования, и я считаю это один из показателей нормальной команды.
В противовес хочу сказать - даже если ты готов работать за еду, выстраивай рамки общения уже на собеседовании. Если к тебе совсем пренебрежительно обращаются или допускают обидную критику твоих навыков - а так ли нужна такая команда для старта?
Если что извиняюсь за возможный сумбур, выгрузил то что было в голове, не продумывая пост заранее, спасибо за внимание :).
Всем привет. Напитонировал небольшого помощника для себя. Занимаюсь администрированием большого количества веб-серверов и бывает, что либо я косячу, либо по каким-то еще причинам не срабатывает автопродление LetsEncrypt сертификатов, либо владелец просто забыл продлить купленный на год.
Бот точно будет работать бесконечно, никаких денег, рекламы не будет. На данный момент хостинг обходится в 400 рублей/мес, что совсем не много.
Оповещение происходит за 14 дней, а затем каждый день с последних 7 дней сертификата. Проверка происходит около 7 утра. Так же бот оповестит, если по домену не получилось вообще ничего получить. Можно запускать ручную проверку.
В общем если кому актуально, пользуйтесь. Без претензий и "как есть"
Действительно хорошие и целеустремлённые DevOps-инженеры обязаны уметь писать скрипты как минимум на sh/bash. По крайней мере стремиться освоить этот навык.
Эта статья представляет из себя краткое руководство (с рядом рекомендаций, и ссылок на полезные ресурсы), которое как поможет вам решать ежедневные задачи, так и поможет давать более корректные ответы на собеседовании.
Никогда не лишним будет заметить, что в любом обучающем процессе, особенно когда дело касается самообучения, очень важно иметь терпение и обладать должной самодисциплиной, чтобы не бросить на полпути.
Это руководство именно для тех, кто хотел бы разобраться в фундаментальных процессах. Для тех кому нужно решать задачи "по-быстрому" здесь и сейчас - есть stackoverflow и google.
1.Shell-скриптинг для DevOps
Первый вопрос, которым вы возможно задаётесь. А насколько действительно важен этот навык для DevOps-инженера? Этот вопрос абсолютно нормальный как в среде новичков, так и матёрых специалистов (да-да, такое тоже встречается).
Ответ прост: Да, это важно.
Картинка ниже хорошо иллюстрирует исследование stackoverflow, где 27% респондентов ответили, что пишут на shell.
Тут в догонку может прилететь второй вопрос.
Но у нас же полно различных средств автоматизации на любой вкус и под совершенно разные задачи? Может Shell всё таки того? Не нужен?
Ответ аналогичный первому: Shell всё еще жив, и всё еще очень нужен.
Да, может сейчас и не очень нужно создавать огромные портянки сценариев оболочки для автоматизации всего и вся, но для специальных задач для использования с инструментами автоматизации нам всё еще нужен Shell.
Например, если вы используете AWS user data, то весьма велика вероятность, что внутри него вы будете использовать скрипты на Shell. Другой пример, для создания образов AMI с помощью packer вы в конечном итоге будете применять Shell для конфигурации AMI. Также умение писать на баше может пригодится и при работе с системами управления конфигурацией, с контейнерами, и с многими другими системами.
Кроме того, сценарий оболочки пригодится для повторяющихся задач разработки. Например, это может быть развертывание Vagrant VM с необходимым программным обеспечением или настройка самой среды разработки.
Что наиболее важно, практическое написание сценариев и программирование становятся обязательными на предварительных собеседованиях в рамках собеседований DevOps. Так что это еще одна важная причина, по которой вам следует изучать сценарии оболочки.
2. Как начать писать на Shell?
Предварительное условия для начала - иметь опыт работы с Linux(или Unix). Следовательно прежде всего нужно убедиться, что вы комфортно себя чувствуете в командной строке Linux, и умеете работать с командами из пакета coreutils.
Если мир Linux для вас пока чужд, то стоит какое-то время потренироваться в виртуальной среде. Например развернув у себя локально абсолютно любой Linux в VirtualBox. Либо, воспользовавшись предложениями облачных провайдеров. Важно выбрать для начала широкоиспользуемый дистрибутив (ubuntu, fedora), так будет проще найти людей в сети, которым можно задать вопросы, и обсудить всплывающие проблемы. Если интересно копнуть глубже, и разобраться во внутренностях системы, то можно попробовать "продвинутые" дистрибутивы типа Arch или Gentoo (для особо упорных LFS). Но что совершенно точно не нужно, так это брать в руки всякую маргинальщину вроде KaliLinux или AstraLinux (во первых они основаны на более популярном и широко используемом дистрибутиве, а во вторых не во всяком линуксовом сообществе вас встретят с распростёртыми объятиями при упоминании таких поделок).
Если вы считаете, что достаточно хорошо умеете работать с Linux, то тогда сделайте следующее.
Создайте репозиторий на Github, создайте в нём каталог для каждого изучаемого вами аспекта, и коммитьте туда все ваши рабочие скрипты. Не имеет значения, будет репозиторий открытый или закрытый (хотя открытый обязывает более ответственно подходить к наполнению).
Заведите собственную документацию. Вы можете например оставлять в README ссылки на полезные источники. Поверьте - фиксирование информации в репозитории поможет вам сохранить знания, а также может помочь другим.
3. Какие есть бесплатные ресурсы для изучения программирования на Shell?
Вам совершенно точно не нужно платить за какие-либо расширенные курсы по изучению Shell-скриптинга, хотя на рынке есть достаточно предложений самых разных курсов для инженеров DevOps. Курсы (если они качественные) - это не плохо, и если вам комфортно обучаться в таком формате, то пожалуйста. Однако программирование на Shell - это тот навык, который вполне можно освоить самостоятельно.
Ниже представлен список бесплатных ресурсов для начала обучения. Некоторые ресурсы пересекаются по рассматриваемым темам. Поэтому выберете наиболее приемлемые по содержанию именно для вас, и начинайте работать с выбранным материалом от начала и до конца. Труд и самодисциплина, как уже упоминалось выше, здесь имеют самую важную роль.
Ссылки на сайты с интерактивными туториалами, бесплатными курсами, и pdf материалами (так как все ресурсы на английском, то тут у нас всплывает побочный квест - оттачивание навыка чтения технических текстов).
Shell Scripting tutorial [Web]
Bash Guide [web]
Shell Scripting Free Course [Udemy]
Bash Academy [Web]
Bash Reference manual [PDF]
The Linux command line [PDF]
4.Применение навыков Shell-скриптинга на практике.
Предположим вы уже изучили все основные концепции программирование на Shell, возможно написали несколько солидных скриптов в обучающих целях. Следующий справедливый вопрос у вас возможно будет "Ну и где мне теперь это всё применять?"
В первую очередь имеет смысл посмотреть существующие проекты автоматизации в своей компании. Особенно если компания не маленькая, и не решается одна точечная задача, то весьма вероятно, что в проектах найдётся не мало мест, где применяется Shell-скриптинг.
Если в вашей компании нет таких проектов, и вы как раз хотите заняться чем-то подобным, но не знаете с чего начать, то например можете посмотреть Git-репозитории с наиболее популярными образами контейнеров для Docker (например контейнер с Nginx).
Попытайтесь разобраться и понять как работают найденные Shell-скрипты. Попутно понимая работу базовых коцепций, и отмечая для себя нестандартные, но интересные пути решения, которые могут быть использованы в этих скриптах.
Не стоит конечно зацикливаться только на скриптах из контейнеров, вы можете найти скрипты во множестве других репозиториях open-source комьюнити.
5. Некоторые примеры для тренировки
Ниже приведены сценарии, которые вы можете реализовать с помощью Shell. Не каждый из них может пригодиться в реальной жизни, но вот на собеседовании они могут встречаться довольно часто. Так что будет полезно потренироваться над решением этих задач.
Найдите 10 самых больших файлов в системе, и перенаправьте вывод в файл.
Напишите скрипт для безопасного извлечения накопителей.
Напишите скрипт, отправляющий уведомление на почту.
Напишите скрипт для мониторинга загрузки CPU, памяти и дисков. Перенаправьте вывод с собранными данными в виде таблицы в файл, и уведомление в stdout если один их них превышает определённый порог.
Напишите сценарий для поиска созданных файлов и их размеров. Он должен принимать количество дней в качестве входных данных. Или формат от и до даты в качестве входных данных.
Напишите сценарий для автоматизации процесса создания новых учетных записей пользователей на сервере Linux и настройки их разрешений и доступа по SSH.
Напишите скрипт для создания списка пользователей, вошедших в систему по дате, и запишите его в выходной файл.
Напишите скрипт для рекурсивного копирования файлов на удалённую машину.
Напишите скрипт который отображает количество неудачных попыток входа в систему по IP-адресу
Создайте скрипт, который анализирует системный журнал, и пересылает в выходной файл выборку событий по конкретной службе, с отметками времени (в человекочитаемом формате).
Напишите скрипт, автоматизируйщий процесс архивирования системного журнала в каталог с резервными копиями, с последующей очисткой текущего журнала.
Напишите сценарий, проверяющий доступность списка URL, и отправляющий уведомление на почту, если какой-то из них не доступен.
Напишите скрипт для автоматизации процесса обновления нескольких серверов.
Напишите функцию, которая находит и убивает все зомби процессы в системе (задание со звёздочкой)
Не забывайте использовать в скриптах изученные понятия:
Переменные.
Подстановка команд, назначение результата переменным.
Использование cut, awk, и grep.
Перенаправление stdin/stdout/stderr.
Обработка условий с помощью if/elif/else.
Работу с оператором выбора (switch).
Циклы for/do-while)
Коды завершения (exit codes)
6.Вопросы по навыкам написания сценариев на собеседовании DevOps инженера.
Вопросы инженерам разнятся от компании к компании.
Например некоторые компании будут просто заинтересованы в ваших базовых знаниях Linux и сценариев оболочки. Другие компании будут рассчитывать на высокий уровень знаний командной строки Linux и сценариев оболочки.
Ниже приведены несколько примеров вопросов на собеседовании инженера DevOps.
Можете ли вы объяснить, как сценарии оболочки вписываются в более широкий рабочий процесс DevOps?
Зачем нужны сценарии оболочки, если есть другие инструменты автоматизации?
В решении каких задач вы предпочтете использовать Shell, а не Python/Golang?
Как провести статический анализ скрипта Shell?
Как вы можете гарантировать, что сценарий оболочки не содержит ошибок в CI/CD pipeline?
Как вы будете обрабатывать ошибки и исключения в своих сценариях?
Напишите простой скрипт, который принимает в качестве аргументов имена двух файлов, объединяет их и записывает вывод в третий.
Найдите дублирующиеся строки в файле, и замените их другой строкой.
Найдите все уникальные IP адреса в логе, и запишите их в отдельный файл
Как бы вы отлаживали сценарий оболочки, который работает неправильно?
Какая разница между циклами for и while?
7. Заключение
Разумеется этот пост не претендует на исчерпывающее рассмотрение темы (очень уж она большая, чтобы уместиться в один пост), но надеюсь, это краткое руководство по изучению сценариев Shell будет как минимум небесполезным для вас.
Неприятная ссылка на канал сообщества в телеграме
Импортозамещение,становится ближе к пользователю, хуе-моё. Давеча импортозамещаю, для прокачки скиллов, чтобы с 1С работало.На Hyper-V, на неиспользуемой станции, у клиента, чего бы не развернуть, не ощутить, так сказать, тут же заодно 1С, можно проверить.
Проблемы начали вылезать откуда и не ждал. Используем Mesh для удаленного доступа, местами RMS от тектонита. В качестве теста ставил на виртуалку mint и предлагаемый MS в HV Ubuntu. Проблемы начались после установки сразу. Оказывается, корректно передавать в виртуалку через удаленное подключение ни та, ни другая система удаленного доступа не может. В Mesh вообще нормально ничего не написать, даже в терминале в гостевой, а в RMS только частично, знаки типа вопроса, запятой, тильда, вызывают непонятную реакцию типа вызова скриншота. В общем, работать невозможно, перенабирать длинные команды вручную такое себе. Да почему это вообще может не работать, обычное нажатие кнопок же, етить-мадрить! В виндовых гостевых все норм, что характерно.
Ладно, зависимости для 1с поставил, шрифты тоже. Ставим 1с... А можно как то проще запускать инсталлер, а не через перетаскивание инсталлера в терминал, где до того было набрано sudo su? например ПКМ и там в менюшке запуск от root? Это концепт такой, чтобы пользователь испытал максимальные трудности? Я предполагаю, что наверняка есть какие то проги, которые могут в контекстное меню эту фичу добавить. Но это же жопа для обычного пользователя, вздумавшего поставить что-то, отличное от содержимого стандартных репов. В дополнение к установке того же Mesh- там некислая такая строчка для выполнения на баше, которая, как мы помним, просто так не копируется в виртуалку. Бля, я всего лишь хочу запустить 1с на лине, что тут такого? Но на этом приключения не кончаются, мои дорогие читатели! Вздумал я невиданный разгул учинить- меня виртуалка предупреждала, что места мало (13г всего при штатной инсталяции бубунты от МС), а я проигнорировал, проказник. И получил в результате несоответствие количества суперблоков и размера дисков, которое ни gparted,ни fsck, устранить не смогли, в результате чего я получил рабочую только в "сейфмоде" виртуалку. Это эпик фейл, на мой взгляд, ибо та же самая винда при 13Мб свободного на диске, позволит загрузиться и вычистить хоть что-то для ее запуска.
К чему я этот пост то собственно. Да, есть вещи, которые есть только под линь и они там хорошо работают при условии выполнения требований к ним. Но бля, какого геморроя можно в лине огрести, если чуть вправо-влево от браузер-мессинджер-офис, то ну его нахуй (это я про рабочие места),лучше винды все же нет.
