​​Где-то пол года назад я делал обзор сервиса getscreen.me - https://serveradmin.ru/otzyv-na-getscreen-me/ У меня его заказали и оплатили. Условно это аналог teamviewer и подобных программ, только работает все через браузер. Вам, чтобы подключиться, не нужно ставить ничего себе на компьютер. Подключаетесь из личного кабинета веб сервиса.

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

Я подготовил с помощью этого сервиса свой бинарник, который пользователь должен запустить у себя, чтобы я к нему подключился. Он может запустить его разово или установить на постоянку. Все доступы там уже зашиты. Чтобы подключиться к компу, я просто захожу в личный кабинет и там же через браузер подключаюсь. Не нужно ничего себе на комп ставить.

Функционал там обычный для такого рода программ. Стоимость очень доступна. 2 компа можно добавить бесплатно, за 300 р. в месяц будет 10 компов, за 1400 - 50 компов. Дешевле я просто не видел, хотя специально и не сравнивал. Мне лично понравилась именно простота подключения через браузер. Зашел в ЛК и подключился. Никаких программ, адресных книг хранить не надо.

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

❗️После публикации этой заметки со мной связались разработчики этого сервиса и предоставили промокод SERVERADMIN, по которому у вас будет не 2, а 3 бесплатных компьютера для управления в личном кабинете.

#программа #remote

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

Иду в панель управления хостера и вижу, что сервера там просто нет 😱. Смотрю тикеты, а там последние 2 тикета с интервалом в неделю о том, что надо продлить сервер, иначе мы его удалим. С ним была особая история месяц назад. Из-за майских праздников не успел дойти очередной платеж и на продление этого сервера денег не хватило. Через тех. поддержку его вручную активировали, потом пришли деньги на счет и на этом все закончилось.

А оказалось, что не закончилось. Надо было после поступления денег зайти в настройки этого сервера и жмакнуть там кнопку оплаты. Без этого оплата автоматически не прошла, а ТП сама не могла это сделать. Вообще, странная история, так как раньше такие ситуации уже были и всё как-то обходилось без ручных действий с моей стороны.

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

Сижу жду час, другой, третий. Заподозрил неладное 🙄 Пошел, проверил бэкапы. Все на месте, но пока не развернешь, наверняка не узнаешь, что с ними 100% все в порядке. Начал переживать. Пишу хостеру, спрашиваю, когда сервер будет готов. Я его уже вижу у себя в панели, но не могу включить.

И тут как гром среди ясного неба. Мне сообщают, что ошиблись. На самом деле сервер уже обнулен, с дисков все удалено ☠️. Извините, но ничего сделать не можем. Пиздец, короче. Тут я уже запереживал немного, но сразу был готов отсечь все претензии, так как моей вины в этой ситуации нет вообще. Бухгалтерия задержала платеж, заказчик не обратил внимание на тикеты. Я в панель управления каждый день не лазию их проверять.

В общем, пошел смотреть бэкапы, искать, где всё разворачивать. С этим больше всего проблем, так как сервак был с 6 Тб данных на борту в рейде 10. Все это рассовать не так просто. Они даже обнуленный сервер не смогли мне запустить, ждал весь день, но так и не дождался. Аналогичного сервера не было доступно.

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

Предвещая комментарии о том, что надо было делать кластер, репликацию, HA и т.д. Этот сервер был в аренде около 5-ти лет. Если бы его дублировали, то потратили бы тонну денег. Простой в течении дня допустим, так что я спокойно восстановил бэкапы предыдущего дня.

Такая вот поучительная история. Со мной случается не первый раз. Я уже терял безвозвратно полностью сервера, поэтому бэкаплю не только данные, но и всё, что сопровождает сервер. Скрипты и конфиги храню в git. Рисую схемы, пишу описания хотя бы для себя, чтобы в тот момент, когда ничего не будет, хоть немного вспомнить, что там вообще было настроено и как. В идеале, конечно, бэкапить виртуалки целиком, но часто это невозможно. Про само наличие бэкапов ничего говорить не буду, и так все знаете - делаем, мониторим, проверяем.

Если дочитал до конца, ты молодец. У тебя наверняка все в порядке с бэкапами.

#история #цод

​​Если вы не очень хорошо знакомы с git, или даже вообще его не знаете 😱, то рекомендую попробовать обучалку LearnGitBranching. Это опенсорсная песочница для обучения основам git с визуализацией всех действий - https://github.com/pcottle/learnGitBranching

Я немного потестил ее, выглядит симпатично и удобно. Хороший русский язык. Обучение разбито на уровни с теорией и заданиями, которые запускаешь в консоли и видишь визуализацию действий. Задумка очень крутая, так как гит немного замороченная система и так просто взять и объять её не получится. Ничего удобнее по гиту лично я не видел.

Сервис можно развернуть у себя, либо воспользоваться готовой платформой - https://learngitbranching.js.org. Если метите в DevOps и не знаете, с чего начать, можете смело начинать с GIT. Без него никуда.

#сервис #обучение

​​Думаю, большинство уже знакомы с реализацией VPN в виде WireGuard, код которой включён в ядро Linux. В том числе поэтому wireguard работает быстрее многих других реализаций.

Существует open source проект WireGuard Easy, с помощью которого можно легко управлять пользователями сервера через веб браузер. То есть это простая панель управления для vpn сервера на базе wireguard.

Запускается и устанавливается в докере в несколько кликов. Я проверил на Centos 8 и в Ubuntu 20. На Centos по какой-то причине не завелось. В контейнере падал сетевой интерфейс wg0, который создавал wireguard и контейнер из-за этого уходил в вечный reboot. А вот в Ubuntu все сразу завелось:

docker run -d \
--name=wg-easy \
-e LANG=en \
-e WG_HOST=🚨YOUR_SERVER_IP \
-e PASSWORD=🚨YOUR_ADMIN_PASSWORD \
-v ~/.wg-easy:/etc/wireguard \
-p 51820:51820/udp \
-p 51821:51821/tcp \
--cap-add=NET_ADMIN \
--cap-add=SYS_MODULE \
--sysctl="net.ipv4.conf.all.src_valid_mark=1" \
--sysctl="net.ipv4.ip_forward=1" \
--restart unless-stopped \
ghcr.io/wg-easy/wg-easy

Указываем свои IP сервера и пароль админа.

После этого идем через в браузер в админку по порту 51821 и добавляем пользователей. Там же скачиваем для них конфиги. После этого качаем под свою систему клиент и импортируем настройки из скачанного конфига.

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

#wireguard #vpn

Понравилась частушка одна, закинул ее в текстовом виде в мой канал с подборкой юмора на it тематику @srv_admin_humor.

Сквозь пайплайн проплыл коммит,
"Simlpe fix" (c) Kukueva.
Весь продакшн уложила,
Одна строчка x*ева.

Один подписчик прислал озвучку этого текста. По-моему, получилось прикольно.

#юмор

​​Решил понемногу переезжать на Debian там, где относительно безопасно можно обновлять версию релизов. Например, в файловых серверах. Создал виртуальную машину с диском на 4Tb и поставил туда Debian.

Сделал дефолтную установку с автоматической разбивкой диска, когда только один корневой раздел. Перезагружаюсь и попадаю в grub rescue. Удивился. Подумал, что наверное установщик не добавил раздел bios_boot. Выполнил еще раз установку и убедился, что раздел на месте, а grub установлен на диск. Но после установки система все равно не грузится с диска, хотя на вид все было сделано правильно. Начал разбираться.

В целом, я понимаю, что надо делать в grub rescue, так как много раз сталкивался и успешно решал проблемы загрузки системы. Есть статья на эту тему. Проверяем список разделов вручную и пытаемся загрузиться с раздела, где живет grub. Выполняю в консоли:

> ls
> ls (hd0,gpt2)/
Вижу, что это системный раздел, где живет в том числе и /boot. Указываю его загрузочным и пытаюсь с него загрузиться.
> set boot=(hd0,gpt2)
> set prefix=(hd0,gpt2)/boot/grub
> insmod normal
Получаю ошибку:
error: attempt to read or write outside of disk hd0

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

Запустил еще раз установку, сам разбил диск, отдав под /boot первый гигабайт диска, остальное в единый раздел 4Tb под корень / . Система успешно установилась и загрузилась после установки.

Сейчас не буду придумывать, что в Centos такой проблемы нет с автоматической разбивкой, не проверял. Я не помню, делал ли там большие диски одним разделом. Такие виртуалки не так часто нужны. А еще я частенько делаю системный раздел небольшого размера, а уже потом отдельно монтирую большой диск под данные. Но то, что Debian автоматически не разруливает эту ситуацию, для меня странно. Фикс этой ошибки не такой уж и очевидный и требует уверенных знаний Linux для быстрого решения.

#grub #ошибка

​​Небольшой мотивирующий пост в начале трудовой недели. Пишу в воскресенье вечером, но вы прочитаете в понедельник утром 😊.

Так получилось, что на прошлой неделе было много задач по настройке чего-либо. Была авария и переезд сервера, были другие технические задачи и проблемы. Появился новый коллектив разработчиков, с которыми надо выстраивать рабочий процесс. И несмотря на то, что задач было много, пару раз сидел допоздна за ноутом и что-то донастраивал, я прям кайфанул.

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

И дело не в том, что я не люблю советов, критики и т.д. Если мне нужно советоваться и обсуждать что-то с технически грамотными и компетентными людьми, то такие разговоры мне нравятся. Я люблю учиться и перенимать чужой опыт. В том числе поэтому веду канал и сайт. Но иногда получается так, что приходится что-то обсуждать и договариваться с теми, кто не очень-то разбирается в теме. А это пустая трата времени и сил. Особенно если руководство не разбирается в теме и его надо долго уговаривать и убеждать. С такими вообще не сотрудничаю.

Я к чему всё это написал. Ищите всегда то, что вам нравится и приносит удовольствие. Если чувствуете, что вам неуютно на своем месте, решите для себя, что конкретно вам не нравится и убирайте это. Кому то нравится видеть перспективы роста и развития в крупной корпорации, а он сидит в конторе на 50 человек. Кто-то любит сидеть один и молча делать свое дело на протяжении многих лет. Кому-то, как мне, нравится все делать самостоятельно, принимать решения и нести ответственность в одно лицо. Кто-то любит собирать команды и мутить какие-то проекты. Постоянно про таких на vc.ru читаю :) Люблю предпринимателей читать.

В общем, не сидите на месте, а стремитесь к улучшению своей жизни. Не терпите руководство, которое вас раздражает и не делайте работу, от которой тошнит. Её невозможно делать хорошо, так как раздражение закрывает творческий подход. А без творчества уныние и скука. Сейчас уникальное время, когда все дороги и границы открыты (пока немного призакрылись). Реализуйте эти возможности.

#мысли

​​Ранее я делал заметку про текстовый редактор Atom, который иногда использую для редактирования скриптов и конфигов. В комментариях было очень много отзывов о том, что Visual Studio Code (VSCode) удобнее и лучше. Мне знаком этот продукт, потому что он у всех на слуху, но сам я им не пользовался, потому что нет нужды. Решил все же посмотреть на него.

VSCode достаточно большой и универсальный редактор (тормозной, написан на Electron 😩). Он подходит как для написания скриптов и кода под Linux, так и под виндовый PowerShell (расширение ms-vscode.PowerShell). При первом запуске в Windows предложил настроить интеграцию с WSL, чтобы запускать код сразу в Linux окружении.

Я попробовал на примере python скрипта. Просто и удобно. Понравилось больше, чем бесплатный PyCharm. Он интерпретатор в винду ставил и настраивал интеграцию. Но вариант с WSL мне понравился больше. Настроил и разобрался сразу же, никаких проблем.

В VSCode удобная интеграция с git (странно, что мастер ветка все еще называется master, а не main 🤦🏾‍♂️), которая позволяет работать с репозиторием даже если вы не особо хорошо разбираетесь в этой системе контроля версий. Для bash есть подсветка синтаксиса и автодополнение кода.

Существует огромное количество расширений, которые устанавливаются из самого редактора через отдельный раздел. Например, можно поставить расширение для интеграции с docker, который будет поставлен в тот же WSL. Можно будет докер файлы править и проверять прямо в винде. Удобно, если винда ваша рабочая система.

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

#программа #редактор

​​Вчера внимательно изучал утилиту для бэкапов Borgbackup или просто Borg.

https://github.com/borgbackup/borg
https://www.borgbackup.org/

Я не просто так уделяю внимание именно бэкапам и постоянно тестирую новые для себя инструменты. Для меня это очень актуальная тема, как и мониторинг, потому что бэкапам уделяю очень много внимания и постоянно с ними работаю.

Чем привлек конкретно Borg и почему обратил на него внимание:

◽ Простая установка и настройка. По сути это просто один бинарник. Ничего дополнительно, типа базы данных, ставить не надо. Работает на всех системах Linux, MacOS. Поддержки винды нет.
◽ Эффективная и честная дедупликация, ну и сжатие до кучи разными алгоритмами.
◽ Работает по ssh. Соответственно, не надо ничего настраивать на хостах, ставить агент и т.д. Ssh чаще всего есть везде.
◽ Гибкий в плане автоматизации с помощью скриптов. Отлично подходит для любителей костылей и велосипедов, как я.

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

Хочется избавиться от своих велосипедов, но найти что-то, что на 100% меня устроило, не получается. Я внимательно посмотрел на Borg, попробовал. В целом, все круто и удобно. Дедупликация отлично работает, diff бэкапы делаются очень быстро.

Но всплывает одна особенность всех бинарных бэкапов с дедупликацией, типа borg. Допустим, у вас есть большой архив данных, ну скажем на 1-2 Тб с 500 000 файлов. Чтобы просто сделать листинг файлов в таком бэкапе уйдет очень много времени. Если же у меня обычный бэкап данных через rsync, я делаю это практически мгновенно.

И еще один минус конкретно Borg. Он сохраняет права файлов, когда вы делаете полный бэкап. Но потом, если вы восстановите отдельный файл, его права не будут восстановлены, так как они хранятся условно в полном бэкапе. Чтобы восстановить и права файлов, надо сделать полное восстановление. Где-то не не принципиально, а где-то создаст много неудобств.

Моё резюме такое. Borg отличный консольный инструмент для бэкапов с честной дедупликацией и сжатием. Очень хорошо экономит место на дисках. Но имеет описанные выше минусы. Если вам они не критичны, можно пользоваться. Я для себя в итоге решил не использовать его. Пока останусь с rsync.

Если вас реально заинтересовал Borg, то посмотреть, как он работает, можно тут - https://www.borgbackup.org/demo.html Сразу получите практически полное представление о его работе. Я начал с того, что посмотрел все 4 demo ролика.

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

#backup

​​Хочу немного порассуждать о Docker. Сейчас появились тенденции отказа от него в пользу других решений. В первую очередь это:

▪ podman от Red Hat
▪ containerd, отпочковавшийся в независимый проект от Docker

Слышал мнение, что Docker типа всё, от него отказываются и заменяют. "Даже Kubernetes объявил Docker deprecated". Дальше расскажу свое мнение, как всё это понимаю я сам. Не обязательно, что прав. Для того, чтобы собрать более широкую картинку по теме, пишу эту заметку. Рассчитываю на ваши содержательные комментарии.

Никуда Docker как инструмент для разработки не уйдет в ближайшее время. Сейчас только наметилась его замена непосредственно в эксплуатации на продуктовых серверах. Докер в первую очередь удобен разработчикам для быстрого разворачивания готового окружения под свое ПО.

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

У Докера хорошая обвязка, которая позволяет очень просто с ним работать разработчикам. Херак, херак и у тебя на машине для разработки все нужные контейнеры подняты. Никакие веб сервера, базы данных, сети настраивать не надо, связывать все это как-то, с dns разбираться. Контейнеры всё делают сами. Скачал готовый докер файл, что-то поправил и запустил. Много видел такого подхода у молодых разработчиков. Они буквально все запускают в докере, потому что ничего не умеют сами настраивать. В таком качестве докер и продолжит свое существование.

А уже в эксплуатации будут думать, чем и как удобнее запустить те же самые приложения в контейнерах. Возможно, появятся некоторые несущественные различия между средой разработки и эксплуатации, но с ними будут мириться.

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

#docker

​​Небольшая подборка моих команд в bash, которыми регулярно пользуюсь. Не претендую на уникальность и идеальный код. Просто беру примеры из своих шпаргалок. Специально ничего не оптимизировал. Если кто знает более удачные реализации того же функционала, делитесь в комментариях.

Удаляем дубли строк (для анализа логов помогает):
awk '!seen[$0]++' file.txt > file_new.txt

Вывести строки, начиная с третьей (в костылях с мониторингом помогает):
awk 'NR > 3' file.txt

Вырезаем первую и последнюю строки (тоже самое, для мониторинга обычно надо):
cat file.txt | awk 'NR > 1' | head -n-1

Выполняем команду cat file.txt 5 раз (в консоли пригождается):
for n in {1..5}; do cat file.txt; done

Удаление последнего или двух последних символов в строках (какой-то мусор в строках удобно убирать):
sed 's/.$//' file.txt
sed 's/..$//' file.txt

Удаление первого или двух первых символов в строках (то же самое):
sed 's/^.//' file.txt
sed 's/^..//' file.txt

Находим все строки с hello=какое-то значение и меняем на hello=1000:
cat file.txt | sed 's/^hello=.*/hello=1000/g' > file_new.txt

Находим все строки с admin: и удаляем их (часто пригождалось, когда менял права доступа на линуксовых шарах, предварительн выгрузив их):
sed '/admin:/d' file.acl > file_new.acl

Заменяем все вхождения строки search на replace:
sed 's/search/replace/g' file.txt > file_new.txt

Удаляем все пробелы и символы табуляции в начале каждой строки файла (помогает чистить конфиги):
sed 's/^[ \t]*//' extensions.conf > extensions.conf.new

Удаляем строки, где знак комментария ; стоит в начале строки (то же самое, помогает чистить конфиги, особенно астериска):
sed '/^;/d' sip.conf
grep -E -v ';|^$' php.ini

Удаляем пустые строки:
sed '/^$/d' file.txt

Заменить рукурсивно текст во всех файлах:
grep 'надо поменять' -P -R -I -l * | xargs sed -i 's/надо_поменять/меняем_на_это/g'

Считаем количество процессов nodejs:
ps ax | grep "nodejs" | wc -l

Считаем количество процессов в системе и выводим 5, которые запустили больше всего экземпляров:
ps -ef | awk '{ print $8 }' | sort -n | uniq -c | sort -n | tail -5

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

Рекомендую забрать в закладки. Никогда заранее не знаешь, где и что пригодится. Я все записываю. Bash по-моему невозможно выучить, постоянно все по своим записям собираю. Понятно, что с опытом это становится проще. Кто-то может и пишет по памяти, но точно не я. Списываю обычно.

Написал и сам себе в закладки добавил, чтобы проше найти было 😎

#bash

​​Небольшая заметка-напоминание на основе своего опыта. Сам регулярно забываю то, о чем ниже напишу. Иногда настраиваешь какой-то сервис. Вроде все сделал правильно, firewall настроил, убедился, что на сервере порт открыт и слушает соединения, а извне нет коннектов.

Плёвое дело для опытного сисадмина. Начинаешь разбираться. Проверяешь еще раз все правила фаервола, убеждаешься, что они применились. Смотришь на счетчики, а пакеты по ним не бегают. Извне коннекты не идут. Разбираешься и начинаешь раздражаться, так как не понимаешь, в чем проблема. Отключаешь полностью firewall, а коннектов все равно нет.

Еще раз проверяешь запущенный сервис и убеждаешься, что порт все же открыт. У тебя дедик, внешнего фаервола нет и проверять нечего. Но коннектов нет. Думаешь, думаешь и тут вспоминаешь, что этот порт может быть заблочен хостером из-за того, что через него могут эксплуатировать какие-то уязвимости. Пишешь запрос хостеру и убеждаешься в этом.

По моему опыту, чаще всего для подключения извне закрывают следующие порты:
25 - smtp протокол для работы почты
123 - для подключений по протоколу ntp
445 - smb подключения виндовой службы шаринга директорий
137, 139 - виндовый NetBIOS протокол

Собственно, я последний раз и наткнулся на блок 445 порта, когда хотел через инет с виндовой шары данные забирать. Разумеется, настроил ограничение по белым спискам ip. Но не тут то было. Хостер не дает подключаться по этим портам извне. Не стал разбираться и писать к нему запросы. Забрал файлы другим способом.

25-й вообще много где закрыт. Например, в DO или Linode. Там даже через запрос в тех. поддержку порт не открывают. Просят кучу дополнительных действий сделать. Зарегистрировать домен, настроить dns, привязать их к серверу и т.д. Я даже разбираться не стал, слишком муторно. Приходится сторонние сервисы отправки использовать.

❓Сталкивались еще с какими-то неявными блоками портов у хостеров?

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

https://mmonit.com/monit/
https://bitbucket.org/tildeslash/monit/

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

Например, есть готовый конфиг, который проверяет, работает ли postfix. Если видит, что не работает, выполняет команды на перезапуск сервиса. При этом конфиги удобочитаемые. Настраивать можно сразу же, без изучения документации. Вот пример с тем же postfix.

 check process postfix with pidfile /var/spool/postfix/pid/master.pid
  start program = "systemctl start postfix"
  stop program = "systemctl stop postfix"
  if cpu > 60% for 2 cycles then alert
  if cpu > 80% for 5 cycles then restart
  if totalmem > 200.0 MB for 5 cycles then restart
  if children > 250 then restart
  if loadavg(5min) greater than 10 for 8 cycles then stop
  if failed host INSERT_THE_RELAY_HOST port 25 type tcp protocol smtp
    with timeout 15 seconds
   then alert
  if 3 restarts within 5 cycles then timeout

Управляется Monit через веб интерфейс и конфиги. Для работы нужна база данных. В простом варианте это может быть SQLite. Для одиночного хоста хватает за глаза. Например, для веб сервера, чтобы автоматом поднимать упавший apache или php-fpm.

Мониторинг для тех, кто устал (это про меня) от всяких модных штук, yaml конфигов, докеров, jsonoв и вот этого всего хипстерского. Кто просто хочет мониторить свой локалхост, получать алерты, перезапускать сервисы, когда они падают. И при этом тратить минимум ресурсов. Писать понятные конфиги без учёта отступов, пробелов, скобок.

Есть еще те, кто использует Monit?

#мониторинг

У меня есть такая привычка, что-то вроде бзика, всегда выделять виртуальным машинам память кратно 1024. То есть не 2000 Мб, а 2048, не 4000 Мб, 4096 и т.д. Принципиальной разницы нет, сколько памяти будет выделено, но я абсолютно всегда придерживаюсь этой схемы. Подключаю калькулятор, если в голове не могу правильно сосчитать. Даже была идея распечатать лист бумаги и наклеить на стену, чтобы не тратить время на вычисления.

С процессорами другой бзик. Я их всегда выделяю четное число, либо 1. Никаких 3, 5, 7 процессоров для виртуальной машины. Только 1, 2, 4, 6, 8 и т.д. Логического объяснения этого у меня в голове нет. Просто делаю так и всё.

Диски подключаю как попало.

Мне интересно, много таких же людей? Делаю опрос только по памяти. Выделяете память для виртуалок как попало или тоже кратно 512, 1024 и т.д.?

​​На днях прочитал англоязычную новость, которая мне показалась важной. В переводе не видел нигде, хотя не факт, что нету. Тезисно решил перевести.

https://blog.devgenius.io/lets-encrypt-change-affects-openssl-1-0-x-and-centos-7-49bd66016af3

История затрагивает тех, кто использует бесплатные сертификаты Let's Encrypt и Centos 7. Я уже не раз говорил, что в современных реалиях использовать Centos 7 становится проблематичным из-за устаревших пакетов, которые уже не собираются обновлять. И вот еще одно тому подтверждение.

Let's Encrypt использует цепочку корневых сертификатов, в которой парочка скоро протухнет. Конкретно Cross-Signed Let’s Encrypt R3 29 сентября 2021 года и DST Root CA X3 30 сентября 2021 года.

Проект стартовал в 2015 году и чтобы ему сразу начали доверять уже существующие устройства и системы, где зашиты корневые CA, ему пришлось сделать cross-sign (не знаю как правильно перевести термин) с одним из таких сертификатов. Сделали они это с помощью промежуточного сертификата сроком на 5 лет, который протух в прошлом году.

Это не стало большой проблемой, так как к тому времени родной CA от Let's Encrypt ISRG Root X1 разошелся по системам и стал доверенным. Но тем не менее, для поддержки старых Android систем LE еще раз сделали cross-sign с хитрой замутой, которая сработает даже при условии протухания DST Root CA X3. Не буду вдаваться в технические подробности, чтобы не раздувать заметку.

Проблема возникла следующая. Все эти cross-sign манипуляции поддерживают не все версии OpenSSL. В Centos 7 используется версия OpenSSL 1.0.2 и она не может корректно распознать получившуюся цепочку сертификатов, чтобы проверить серт от Let's Enrypt и организовать безопасное TLS соединение. Обновление на более свежие версии openssl может сломать совместимость со многими приложениями.

Есть различные способы решения этой проблемы. Не буду их сейчас приводить, так как по мере приближения к часу икс, возможно появится что-то еще. В любом случае, просто будьте в курсе, что могут случиться проблемы и в начале сентября подумайте, что будете предпринимать на своих Centos 7. Я тоже буду думать, у меня много таких систем.

В статье больше подробностей и примеров, так что если тема заинтересовала, можете там все посмотреть со ссылками, картинками и т.д.

Очень жизненный юмор 😁 Прям улыбнулся, когда прочитал. Я часто смотрю history, когда подключаюсь к чужим серверам. Зачастую это может помочь решить проблему. Всякое там вижу. Иногда смешное, иногда грустное.

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

Предлагаю попробовать угадать, что это за способ.

#юмор

​​Недавно сделал заметку про выделение памяти для VM, кратной 512Мб, а так же чётное количество процессоров. Оказывается этому есть вполне осмысленное обоснование и отражено оно в блоге vmware - https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-thumb.html

Материал большой и насыщенный. Приведу только конечные выводы по оптимальному распределению RAM и CPU между виртуалками. Там есть нюансы, о которых лично я не знал. Рассматривается в том числе вопрос с сокетами. Части вижу вопросы на тему того, как распределить процессоры и сокеты в VM.

На основе статьи рекомендации будут следующие. Для примера взят хост:
▪ 2 сокета
▪ 10 ядер на сокет
▪ 40 логических процессоров
▪ 256 GB памяти, по 128 GB на сокет

Разбираем сначала виртуалки с количеством памяти меньше 128 GB. В
этом случае мы добавляем 1 сокет и максимум 10 vCPU. Как только процессоров нужно больше, чем есть на одном сокете, дальше мы добавляем только по чётным числам и делим на 2 сокета поровну. То есть должно быть 2 сокета, 6 vCPU на сокет, в сумме 12. Это будет оптимальная конфигурация для 12 vCPU. И так дальше до 20 ядер добавляем, деля их поровну между сокетами. Напоминаю, что это для виртуалок с памятью меньше чем 128 GB.

Если в виртуальную машину надо выделить более 128 GB памяти, арифметика будет другая. Нечётное количество ядер не используем вообще. Сокетов всегда добавляем два. То есть надо виртуалке 2 vCPU и 192 GB памяти. Делаем два сокета, в каждом по ядру и сколько надо памяти, кратно числу ядер.

Я не знаю, актуально ли это для всех систем виртуализации или только для vmware. Специально не узнавал, но подозреваю, что актуально везде, так как исходит из архитектуры самой платформы хоста.

Краткий вывод такой. Если на одну виртуальную машину условно приходится ресурсов не более, чем в рамках одного сокета (vNUMA, cpu + ram), то процессоров ставим любое число, сокет всегда один. Если на vm уходит больше ресурсов одного сокета, то надо делить процессоры равномерно по сокетам. Причем даже если процессоров всего 2, а памяти больше, чем достанется сокету, все равно vCPU разделяем на сокеты.

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

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

#виртуализация

Заметка про блокировку хостерами некоторых tcp/udp портов вызвала некоторую дискуссию. На мое удивление, что в TG, что в VK нашлись люди, которые одобряют такой подход. В частности, блок на отправку почты по 25 порту. Переведу его на более простой язык.

Вы регистрируетесь и сразу же считаетесь спамером. Вам тут же блокируют отправку сообщений, хотя потребность в этом есть достаточно большая. Например, я иногда настраиваю отправку почты прямо с сервера на свои ящики, не используя внешние smtp сервера. Не вижу в этом ничего криминального. Никакие ptr и dns записи мне не нужны. Это моя личная почта, адресованная тоже мне. Это может быть локальное дублирование каких-то критичных событий мониторинга. Не суть важно, зачем мне может быть нужно. Отправка почты актуальный в наше время функционал.

Так вот, нормальная блокировка должна выглядеть следующим образом. Вы начали рассылать спам и это заметили по активности вашего публичного трафика на выходе из инфраструктуры провайдера. Например, количество smtp пакетов, потоков превышено. Если вы выходите за рамки каких-то разумных лимитов, вам блокируют 25-й порт и просят пояснить, что вы там рассылаете.

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

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

❓А вам какой подход больше нравится? Наказание сразу всем, а потом доказательство невиновности, или наказание только тех, кто реально виновен?

В пятницу был юмор на тему bash_history. А вот уже не такая смешная история, как бывает на практике. Я не знал пароль root от mysql, но очень быстро его выяснил.

Так что следите за своей history в терминале. Не надо там светить пароли. По аналогии иногда можно пароль root посмотреть в логе авторизаций ssh. Если открыт доступ по паролю, то не редко бывает так, что вместо имени пользователя туда копируют пароль и он оседает в логе.

#безопасность

​​У меня было несколько заметок на канале про различные mysql клиенты. Я не знаю, с чем это связано, но их очень активно обсуждали, сохраняли в закладки, vk активно показывал эти посты, так что они набирали до 10к. просмотров. Походу все любят юзать mysql клиенты 😃

Держите еще один, которым я сам иногда пользовался. Речь пойдет про Adminer - https://www.adminer.org Это небольшой php файл (~500к, где треть объема переводы), который можно положить на любой php хостинг, чтобы использовать его как панель управления mysql сервером. Очень удобно для различных php хостингов, где по какой-то причине нет хостеровской панели управления базами, либо она неудобная.

Рассказывать про эту утилитку особо нечего. Она просто работает. Можете демку глянуть - https://demo.adminer.org/adminer.php. Пользователя и пароль указывать не обязательно. Для типовых операций у неё примерно тот же функционал, что и у phpmyadmin, но последний просто монстр, а тут только один файл.

#mysql