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

Список прошлых публикаций с бесплатными курсами на Stepik:

- Курсы на тему основ Linux
- Программирование на Python
- Курсы по SQL и Golang

Ещё один хороший курс про Docker в копилку:

⇨ Docker для начинающих + практический опыт

Мне его посоветовал читатель. Автор курса, если я правильно понял, основатель небольшого обучающего портала с несколькими курсами, которые он написал сам, будучи техническим специалистом. На Степике есть ещё бесплатный курс от него:

⇨ Ansible для начинающих + практический опыт

И несколько платных за небольшие деньги. Попробуйте, может это будет хорошим вариантом научиться чему-то новому за 5000 - 8000 т. р. У курсов хорошие рейтинги и отзывы. В сравнении с курсами от популярных он-лайн школ это почти бесплатно. Дешевле в 10-20 раз.

#обучение #бесплатно

На прошлой неделе была рассылка от Zabbix. В ней анонсировали запуск Zabbix Cloud. Я сразу предположил, что они запустят свой облачный сервис после недавней замены лицензии GPL на AGPL. Так и случилось. Решил проверить, что это такое и как работает.

После регистрации ждал примерно день, пока активируют учётную запись. Судя по всему, вручную это делают. После подтверждения на email создания личного кабинета, зашёл в него и активировал trial на 5 дней. Выбрал ноду во Франкфурте и развернул её.

По своей сути я получил обычный Zabbix Server, развёрнутый на серверах облака. Мне дали адрес веб интерфейса, логин, пароль. Внутри самый обычный Zabbix Server, к которому я могу подключать агентов. Он ничем не отличается от такого же, который я могу развернуть на арендованном сервере.

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

В таком виде вообще не увидел никакого смысла в saas. Развернуть голый Zabbix Server - дело 10-ти минут. Возможно в будущем появятся какие-то дополнительные возможности и удобства. Например, какой-то механизм автоматического обновления шаблонов. Это прям тяжёлая для меня тема, когда нужно обновить стандартный шаблон на новую версию. Нет простого способа это сделать без удаления старого, очистки всех метрик и добавления нового шаблона. Не хватает какого-то механизма сравнения и склеивания шаблонов для обновления до свежей версии.

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

#zabbix

На днях на одном из серверов VPN с IP 175.115.158.81 заметил странные строки в логе:

ovpn-server[3742533]: TCP connection established with [AF_INET] 95.145.141.246:58560
ovpn-server[3742533]: 95.145.141.246:58560 Connection reset, restarting [0]
ovpn-server[3742533]: 95.145.141.246:58560 SIGUSR1[soft,connection-reset] received, client-instance restarting

Внимание привлекло то, что 95.145.141.246 это мой IP адрес ещё одного VPN сервера. Я не припомнил, чтобы настраивал на нем клиента для подключения к серверу 175.115.158.81. На всякий случай сходил туда и убедился в этом:

# ps axf

Никакого openvpn клиента тут не было запущено. Да и настроек для него тоже нет. У меня настроена разветвлённая система VPN туннелей с маршрутизацией, так что иногда начинаю в ней путаться. Надо схему рисовать.

Я немного напрягся и стал разбираться, в чём тут дело. Решил посмотреть на сервере с IP 95.145.141.246 исходящие сетевые соединения:

# ss -ntu

Соединения разные были, но к указанному VPN серверу ничего не было. Стало ещё интереснее. Расчехлил tcpdump и стал смотреть им:

# tcpdump -nn 'dst host 175.115.158.81'

Подождал, когда в логе на VPN сервере 175.115.158.81 опять появится запись о неудачном соединении. Вернулся в консоль сервера 95.145.141.246 и увидел запись:

14:29:38.706375 IP 172.17.0.4.58700 > 175.115.158.81.1778

1778 - порт VPN сервера. Смотрю на адрес 172.17.0.4 и тут до меня доходит, что это Docker контейнер. Проверяю IP адреса контейнеров:

# docker ps -q | xargs -n 1 docker inspect --format '{{ .NetworkSettings.IPAddress }} {{ .Name }}' | sed 's/ \// /'
...........
172.17.0.4 gatus
...........

А там мониторинг Gatus. И тут я вспоминаю, что настроил мониторинг VPN канала через проверку доступности порта, на котором он принимает подключения. Всё встало на свои места. Не думал, что проверка порта будет такими записями в логе отмечаться. Хотя на самом деле с таким встречаюсь иногда, когда через Zabbix порты проверяю через simple check.

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

#linux #terminal

Очень простой и быстрый способ измерить ширину канала с помощью Linux без установки дополнительных пакетов. Понадобится только netcat, который чаще всего есть в составе базовых утилит. По крайней мере в Debian это так.

Берём условный сервер 10.20.1.50 и запускаем там netcat на порту 5201:

# nc -lvp 5201 > /dev/null

Идём на другую машину и запускаем netcat в режиме клиента, передавая туда 10 блоков размером 10 мегабайт:

# dd if=/dev/zero bs=10M count=10 | nc 10.20.1.50 5201

Когда измерял так скорость, немного усомнился в достоверности результатов. Решил провести одинаковые тесты с помощью netcat и iperf3. На скоростях до 1 Gbits/sec замеры показывают одинаковые числа, плюс-минус в районе погрешности измерений. Можно смело использовать netcat. Это реально работает для быстрой проверки канала до какой-то VPS.

А вот в сетях в рамках гипервизора, где скорости значительно больше, идут большие расхождения. Iperf3 показывает раза в 4 больше скорость (~15.0 Gbits/sec), чем netcat (~4.0 Gbits/sec). Гипервизор объявляет скорость своего бриджа в 10 Gbits/sec. И тут уже трудно судить, кто ближе к истине. Корректно выполнить замеры на реальных данных затруднительно, так как много факторов, которые влияют на итоговый результат.

Напомню, что у меня есть хорошая заметка про netcat с различными практическими примерами применения этой утилиты.

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #network

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

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

Я ко всем командам добавляю ключ -nn, чтобы не резолвить IP адреса в домены и не заменять номера портов именем протокола. Мне это мешает.

📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:

# tcpdump -D

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

📌 Слушаем все интерфейсы:

# tcpdump -nn -i any

Или только конкретный:

# tcpdump -nn -i ens3

📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:

# tcpdump -nn -i any port not 22

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

📌 Пакеты к определённому адресату или адресатам:

# tcpdump -nn dst 8.8.8.8
# tcpdump -nn dst 8.8.8.8 or dst 8.8.4.4

Комбинация порта и адресата:

# tcpdump -nn dst 8.8.8.8 and port 53

Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,

📌 Смотрим конкретный протокол или исключаем его и не только:

# tcpdump arp -nn -i any
# tcpdump not arp -nn -i any
# tcpdump not arp and not icmp -nn -i any

На этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:

# tcpdump -nn -i any > ~/tcpdump.txt

На основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:

# tcpdump -nn -i tun4 src 10.1.4.23 and dst 10.1.3.205 and port 5060

Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:

IP 10.8.2.2.13083 > 10.8.2.3.8118

Протокол IP, адрес источника и порт > адрес получателя и его порт.

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#network #tcpdump

Немного информации для тех, кто имеет дело с обычными веб серверами под php сайты. Вчера провозился несколько часов с одним сайтом, который передали разработчики для публикации. Причём провозился из-за ерунды. Это был немного навороченный мультиязычный сайт на базе Wordpress, но с полностью самописной темой.

Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.

В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.

Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами <?xml.

В коде этого сайта были конструкции типа <? вместо <?php, а для их корректной работы как раз и нужен параметр short_open_tag. Есть проекты, где явно пишут, что надо включить этот параметр. А тут мне никто ни слова насчёт него не сказал. Включил параметр и всё заработало.

Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:

<?xml version="1.0"?>

Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.

#webserver #php

Периодически в комментариях возникают вопросы на тему личного хранилища информации. Кто, как и где хранит. Я сколько веду свою трудовую деятельность, столько и делаю записи по различным темам. Начинал всё с простого сохранения html страниц. Они, кстати, до сих пор у меня хранятся. Упаковал в архив, так и лежат с тех пор. В конце будет ссылка на один подобный архив по теме. Может кому интересно будет поностальгировать по прошлым временам. Там будет цикл статей по настройке почтового сервера на Freebsd, по которому я учился.

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

В дополнение к этому, я в Joplin веду все свои проекты, не только по работе, но и личные, типа стройки, ремонта, сайта и т.д. Когда делаю что-то значимое, что хочу сохранить для использования в будущем, делаю заметку по этой теме в свободной форме. Покажу на конкретных примерах.

Есть компания, где используются сайты на Битриксе. У меня там в том числе есть такие записи:

◽️Bitrix. Тут хранится общая информация обо всём, с чем сталкиваюсь. Например, была ошибка, я записал текст ошибки и тут же решение текстом или ссылку на материал, который использовал. Не занимаюсь никаким особым оформлением. Просто записываю, чтобы потом найти.
◽️Переезд веб сервера. Тут пишу всё, что касается переезда. Уже не раз меняли провайдера, сервера, услуги. Каждый раз кажется, что это в последний раз так переезжаем масштабно, но на деле, каждые 2-3 года что-то случается. Заметка очень помогает быстро составить план переноса.
◽️Заражение. Тут описана история заражения одного сайта. Что пролезло, какие признаки были, как лечил.
◽️Ошибки обновления. Сайты периодически обновляют, пишу, с чем сталкиваемся, чтобы потом быстрее обсудить с разработчиками очередное обновление.

❗️Важный момент. Я не трачу много времени на эти записки. Просто копирую информацию и всё. Если оформлять, дополнять, то на это тратится время, будешь лениться или откладывать. В итоге забудешь. А так всё записано. Потом это пригождается и в других проектах, так как с Bitrix приходится много где работать. Даже такие отрывочные данные сильно упрощают решение задачи, когда с ней повторно сталкиваешься.

По личным делам всё то же самое. Вот несколько примеров записей по даче:

◽️Техника. Записываю модели всей купленной техники и всё, что с ней связано.
◽️Обслуживание инженерки. Пишу, что, где, когда и как надо делать: проверить расширительный бак, заменить фильтр, закрыть уличный кран на зиму и т.д.
◽️Строительные компании. С какими компаниями работал, кто что делал.
◽️Серверная. Оборудование в серверном шкафу.
◽️Спросить у специалиста. Список вопросов, на которые мне нужен совет специалиста.
◽️Перед отъездом. Список того, что надо проверить перед отъездом: закрыть окна, отключить насос, выключить тёплый пол, забрать мусор и т.д. Не нужно каждый раз ломать голову и вспоминать, ничего ли я не забыл. Этот список, кстати, распечатан и висит перед выходной дверью.

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

Как вы можете увидеть, снизу есть тэг. По нему вы найдёте все мои записи по этой теме. Например, как планирую свои дела и какой планировщик использую.

Обещанный архив: postfix.7z

#заметки

Если обратиться к веб серверу на базе Nginx по IP адресу, то увидите либо первый виртуальных хост в конфигурации, либо тот, где указана директива default в параметре listen. Показывать виртуальный хост не очень хочется, поэтому обычно на IP адрес ставят какую-то заглушку. Например, так:

server {
    listen 80 default_server;
    server_name _;
    return 404;
}

С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:

server {
    listen 443 ssl default_server;
    server_name _;
    return 404;
}

То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.

Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:

# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/certs/nginx.key -out /etc/nginx/certs/nginx.crt

Используем его:

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_certificate /etc/nginx/certs/nginx.crt;
    ssl_certificate_key /etc/nginx/certs/nginx.key;
    return 404;
}

Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
    return 404;
}

Объединил для удобства оба протокола. Ключевой момент тут в настройке ssl_reject_handshake on. Когда она включена, веб сервер отклоняет все попытки соединения, где адрес сервера не совпадает с тем, что указано в директиве server_name. Тут у нас в этой директиве _, так что все соединения будут сразу отклоняться. Пользователь сразу увидит ошибку без необходимости выполнять какие-либо действия.

Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#nginx #webserver #angie