ServerAdmin.ru
31.3K subscribers
674 photos
55 videos
22 files
2.87K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Регистрация в РКН: https://vk.cc/cG1Urj
Download Telegram
Существует популярная панель для управления сервером с прицелом на персональное использование в качестве некоего домашнего сервера. Речь пойдёт про CasaOS - популярный open source проект. Ставится поверх обычного дистрибутива Linux. Я установил на Debian и попробовал его для решения некоторых задач. В частности своего личного WireGuard сервера в связке с AdGuard Home для блокировки рекламы на компьютерах или смартфонах.

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

Можно было бы предположить, что это продукт для тех, кто не умеет и не хочет уметь работать с консолью Linux, ничего не знает, а хочет просто мышкой потыкать и получить настроенный сервер. Но на самом деле с CasaOS это так не работает. Без знаний особенностей работы Docker контейнеров настроить нормальную работу всех сервисов скорее всего не получится. В консоль ходить не обязательно, но некоторые настройки контейнеров после установки нужно будет делать.

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

◽️big-bear-casaos
◽️CasaOS-LinuxServer-AppStore
◽️CasaOS-Coolstore
◽️CasaOS-HomeAutomation-AppStore

Получается внушительный набор. Для личного сервера есть всё необходимое: FileBrowser, Nginx Proxy Manager, WireGuard, AdGuard Home, Syncthing, Transmission, Nextcloud и многое другое.

Установить CasaOS очень просто. Берём чистый сервер и ставим:

# curl -fsSL https://get.casaos.io | sudo bash

На выходе получаем работающий веб интерфейс по IP адресу сервера. При первом входе нужно будет создать учётку. Дальше я настроил и потестировал прикладную связку из WireGuard + AdGuard. Сначала установил AdGuard Home. Первый вход из админки запускает стандартный установщик AdGuard, который в том числе настраивает доступ к веб интерфейсу. По умолчанию это будет 80-й порт, но он уже занят интерфейсом самого CasaOS. Поэтому после установки контейнера, надо зайти в настройки AdGuard Home и добавить проброс ещё одного порта к уже существующим: 8080 ⇨ 80. Теперь по IP адресу сервера и порту 8080 можно попасть в веб интерфейс AdGuard.

Потом установил WireGuard Easy. После установки зашёл в настройки приложения и отредактировал некоторые параметры. В переменной PASSWORD установил свой пароль. В переменной WG_HOST указал IP адрес сервера, в WG_DEFAULT_DNS указал IP адрес контейнера с AdGuard Home. Так как он устанавливался первым, IP адрес у него 172.17.0.2.

Ну и всё. Дальше зашёл в веб интерфейс WG-Easy, создал пользователя. Импортировал конфиг в смартфон и подключился. Смартфон автоматом весь трафик завернул в туннель, а в качестве DNS сервера стал использовать контейнер AdGuard Home. А в нём можно настроить различные блокировки как по спискам рекламы, так и целые сервисы. Например, можно заблокировать полностью Youtube или VK. Таким же образом WG можно подключить на компьютере (проверил, работает) или на роутере. Причём на роутере не обязательно весь трафик заворачивать в туннель. Можно использовать только DNS сервер от AdGuard Home для блокировки рекламы.

Эту связку можно использовать для различных задач. Не буду подробно на этом останавливаться, так как за это уже начали наказывать. Пока в виде предупреждений. Авторы сайтов и ютуб каналов уже получают уведомления от Роскомнадзора. Так что если вы автор контента, имейте ввиду.

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

Сайт / Исходники / Demo (casaos / casaos)

#linux
2👍108👎4
Уважаемые сисадмины, у меня для вас очень интересная и полезная система удалённого управления - Rport. А точнее её форк - OpenRPort. Сам Rport был куплен коммерческой организацией, которая закрыла исходники, а OpenRPort остался open source.

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

Кратко, что такое OpenRPort - клиент-серверная система для управления компьютерами, серверами и прочим оборудованием. Похожа немного на MeshCentral и Apache Guacamole вместе взятые, но со своими особенностями. По возможностям OpenRPort понравилась больше этих программ. Она предназначена не только для удалённых подключений к экранам.

📌 Особенности OpenRPort:

◽️Сервер может быть установлен как только в локальной сети или с доступом по VPN, так и с доступом через интернет напрямую или проброс портов.
◽️Для управления клиентами на них ставится агент.
◽️Аутентификация пользователей может быть двухфакторной с отправкой токенов на email, пушами на смартфон или использованием TOTP.
◽️Доступ к экрану клиентов осуществляется через проброс портов с сервера OpenRPort до клиента. Для подключения используются встроенные инструменты самой системы, типа RDP и SSH, либо какое-то стороннее ПО.
◽️Доступ по RDP возможен как через RDP клиент с загрузкой .rdp файла для подключения, так и через браузер непосредственно из веб интерфейса OpenRPort.
◽️На клиентах можно выполнять различные консольные команды или скрипты, делая выборку по разным группам или тэгам. Команды и скрипты можно запускать регулярно через планировщик.
◽️Для клиентов осуществляется простой мониторинг основных метрик (CPU, Memory, Network, Disk) и отображается список запущенных процессов.
◽️Для каждого клиента можно настроить несколько разных туннелей от сервера. Например, пробросить RDP порт и HTTP для доступа к какому-то локальному сервису.

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

Отдельно расскажу про систему туннелей к клиентам. Мне эта возможность особенно понравилась. Реализована она следующим образом. Администратор системы может настроить туннель от сервера (10.20.1.36) к клиенту (10.20.1.53). Например, указывает локальный порт сервера 20011 и порт клиента 3389. На сервере будет поднят туннель 10.20.1.36:2001110.20.1.53:3389. И отдельно можно указать, что этот туннель доступен только пользователю с IP адресом 10.8.2.2 или всей подсети 10.8.2.0/24.

Вы можете подключиться по этому туннелю как через веб интерфейс, так и любой другой софт. Туннель может быть постоянным, с ограничением по времени, то есть выключится, к примеру, через 2 часа принудительно. Либо его можно отключить после 5-ти минут неактивности. Для каждого клиента может быть много подобных туннелей с разными параметрами и доступом. Туннели открывает на сервере служба rportd. Они все видны через ss или netstat.

Установить и настроить OpenRPort легко. У меня сходу получилось по инструкции. Ставил на чистый Debian 12:

# curl -o rportd-installer.sh https://get.openrport.io
# bash rportd-installer.sh \
 --email [email protected] \
 --client-port 8000 \
 --api-port 5000 \
 --fqdn 10.20.1.36 \
 --port-range 20000-20050 \
 --no-2fa

В консоли увидите адрес для подключения и учётку админа. Без fqdn с IP адресом нормально работает. Будет выпущен самоподписный сертификат.

В веб интерфейсе создаёте клиента, получаете cli команду для установки агента, ставите его и клиент автоматически появляется в системе.

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

Сайт / Исходники

#remote
3👍283👎5
Наглядный пример, почему не стоит сохранять пароли в браузерах. Их оттуда очень легко утянуть незаметно для пользователя. Я что 10 лет назад видел, как это просто сделать, что сейчас.

До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.

Пример для ОС Windows. Идём в репозиторий:

⇨ https://github.com/ohyicong/decrypt-chrome-passwords

Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.

Установил зависимости:

> pip install pycryptodomex sqlite sqlite

Запускаю скрипт. Перед этим специально сохранил пароль от одного сайта:

> python decrypt_chrome_password.py

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

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

#security
👍148👎10
Небольшое предупреждение для тех, кто администрирует сайты и получает на них Abuse от РКН. Если на сайтах открыта регистрация пользователей и есть возможность публиковать текст, то это только вопрос времени, когда вы получите требование удалить ту или иную информацию, нарушающую закон. Боты или реальные люди будут пытаться оставить ссылку на запрещёнку везде, где это возможно: комментарии, отзывы, сообщения на форуме, поля для комментариев в профиле и т.д.

Уведомления приходят сначала провайдерам, а они уже уведомляют владельцев сайтов. Даются сутки на удаление противозаконной информации. Вот точная информация на этот счёт:

Провайдер хостинга или иное лицо, обеспечивающее размещение информационного ресурса в сети «Интернет» (далее – иное лицо, разместившее информационный ресурс), с момента получения настоящего уведомления обязаны:
- незамедлительно проинформировать владельца информационного ресурса о необходимости незамедлительного удаления распространяемой с нарушением закона информации;
- по истечении суток ограничить доступ к информационному ресурсу в случае отказа или бездействия владельца информационного ресурса в удалении распространяемой с нарушением закона информации. 

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

На днях получил подобное уведомление. Информацию удалил. Решил прочитать исходный текст уведомления от РКН. А он существенно изменился в сравнении с тем, что я получал ещё в сентябре. В заявлении указан уникальный идентификатор. Используя этот идентификатор, необходимо отчитаться об удалении либо по email, либо через специальную форму на сайте 398-fz.rkn.gov.ru. В уведомлении есть ссылка с зашитой информацией об основных данных по этому уведомлению.

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

❗️И ещё дам небольшой совет, который может сэкономить ваше время. В требовании может прийти ссылка как со слешом на конце, так и без. Я не знаю, кто и как её формирует, но сталкивался не раз. На веб сервере может быть не настроен редирект ссылок без слеша на слеш и наоборот. Речь вот о чём. Ссылки https://398-fz.rkn.gov.ru/toproviders/ и https://398-fz.rkn.gov.ru/toproviders по сути разные.

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

#webserver
1👍123👎20
Несмотря на то, что сейчас существует очень много современных решений по сбору и обработке логов, старый текстовый формат syslog не потерял полностью актуальность. Причин тому несколько. Перечислю то, что сам вспомнил:

◽️Формат популярен для сетевого оборудования, IPMI серверов.
◽️Нетребователен к ресурсам железа.
◽️Нет необходимости изменения конфигурации сервера для приёма новых логов.
◽️Это стандарт для ведения логов в POSIX-совместимых системах.
◽️Много софта поддерживают формат syslog, нет необходимости устанавливать дополнительное ПО на клиентах.
◽️Легко ротировать логи с помощью logrotate.

Я использую syslog регулярно, несмотря на то, что для глобального хранения логов устанавливаю ELK Stack. Использую его, если нужна какая-то аналитика по логам, а не просто хранение текстовых данных.

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

Второй пример использования - быстро собрать логи для анализа содержимого с помощью Zabbix. Для анализа обычных текстовых логов не нужны никакие костыли и дополнительные настройки. Zabbix встроенными средствами может их читать и анализировать с помощью regex. Это позволяет очень просто и быстро настроить какие-нибудь уведомления на события. Например, аутентификацию по SSH.

Соответственно, если вам нужно что-то быстро связать с системой мониторинга Zabbix и это что-то умеет писать логи в формате syslog, настройка мониторинга очень сильно упрощается. Можно прямо на Zabbix Server настроить rsyslog на приём логов по сети. Для этого необходимо в /etc/rsyslog.conf раскомментировать:

module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

И перезапустить службу:

# systemctl restart rsyslog

Проверяем, слушает ли rsyslog входящие подключения:

# ss -tulnp | grep rsyslogd

Если слушает 514 порт, то можно отправлять на него логи. Обычно в настройках оборудования или софта достаточно просто указать IP адрес сервера с rsyslog, чтобы потекли данные на сервер. Дополнительно можно задать порт, если используете не стандартный, facility (категория), severity (важность).

Если больше не менять настройки, то все логи будут писаться в общий syslog файл. Обычно это /var/log/syslog. Удобно их разделять либо по IP адресам отправителей, либо по приложениям, которые их отправляют. Я чаще по хостам разделяю логи. Для этого надо задать шаблон формирования лог-файлов. Добавляем в rsyslog.conf:

$template FILENAME,"/var/log/syslog/%fromhost-ip%.log"
if $fromhost-ip != '127.0.0.1' then ?FILENAME
& stop

Данное правило будет автоматически раскладывать все логи с удаленных устройств по файлам в директории /var/log/syslog с именами в виде IP адресов. При этом мы исключаем туда запись локальных логов, иначе они появятся под адресом 127.0.0.1, и предотвращаем их запись в системный syslog файл. По шаблонам наглядные примеры есть в документации.

Для удобного просмотра подобных логов можно использовать какой-то простенький веб интерфейс. Я описывал некоторые из них:

▪️tailon

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

Можно взять тот же Webmin. Там неплохой раздел для просмотра локальных логов. Похожая возможность есть и в Cockpit.

☝️ Кстати, кто-то может не знает, что rsyslog агент есть и под Windows. Он формат виндовых логов преобразует в syslog и отправляет на rsyslog сервер.

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

#logs
👍159👎3
Для построения распределённого файлового хранилища наиболее популярной и зрелой технологией является Ceph. Это программная объектная отказоустойчивая сеть хранения данных. Минимальное количество нод для построения кластера - три. При этом максимальное количество может исчисляться десятками и возможно сотнями. Ceph сложен и в установке, и в эксплуатации.

Компания Canonical, авторы Ubuntu, создали проект MicroCeph, который позволяет очень быстро и просто развернуть небольшой кластер Ceph. Для обучения или тестовых задач его можно развернуть даже на одной машине. MicroCeph по своей сути тот же Ceph, только уже преднастроенный и упакованный в пакет snap.

Покажу, как быстро развернуть кластер из трёх нод на базе виртуальных машин Ubuntu 24. У нас будут 3 идентичные виртуалки, в каждой по два диска: системный sda, чистый sdb под ceph. Все три ноды видят друг друга по именам node-1, node-2, node-3, которые добавлены им в файлы /etc/hosts.

Устанавливаем microceph и сразу запрещаем обновление на всех трёх нодах:

# snap install microceph
# snap refresh --hold microceph

Теперь на node-1 инициализируем кластер и создадим токены для добавления двух других:

# microceph cluster bootstrap
# microceph cluster add node-2
# microceph cluster add node-3

Идём на node-2 и node-3 и добавляем их в кластер, используя полученные выше токены:

# microceph cluster join <token node-2>
# microceph cluster join <token node-3>

На каждой ноде добавим диск sdb к хранилищу:

# microceph disk add /dev/sdb --wipe

Смотрим, что получилось:

# microceph status

MicroCeph deployment summary:
- node-1 (10.20.1.34)
 Services: mds, mgr, mon, osd
 Disks: 1
- node-2 (10.20.1.35)
 Services: mds, mgr, mon, osd
 Disks: 1
- node-3 (10.20.1.36)
 Services: mds, mgr, mon, osd
 Disks: 1

Дальше с кластером можно работать, как с традиционным ceph. Смотреть статус:

# ceph status

Активировать модуль статистики для Prometheus:

# ceph mgr module enable prometheus

Метрики появятся по адресу https://10.20.1.34:9283/metrics. Смотрим использование кластера:

# ceph df

Он пока пустой, без данных. Нет ни одного пула. Создадим пул с распределённой файловой системой cephfs:

# ceph osd pool create cephfs_meta
# ceph osd pool create cephfs_data
# ceph fs new newFs cephfs_meta cephfs_data

Смотрим список пулов:

# ceph fs ls
# rados lspools

Смотрим ключ пользователя admin, который создан автоматически:

# ceph auth get-key client.admin

Этот ключ нам нужен для того, чтобы получить доступ к файловой системе по сети. Я это показываю для теста. В проде так делать не надо. Надо создать отдельную директорию, создать для неё пользователя с правами к этой директории. И использовать его. Всё это подробно описано в моей статье на сайте про ceph:

Установка, настройка и эксплуатация Ceph

Теперь мы можем подключить эту файловую систему на любую машину Linux. Для этого туда надо установить пакет ceph-common:

# apt install ceph-common

Подключаем cephfs:

# mkdir /mnt/cephfs
# mount.ceph 10.20.1.34,10.20.1.35,10.20.1.36:/ /mnt/cephfs -o name=admin,secret='AQB8nRpn7MBLAxAANpLgc8UxrLhT487Tt9Y4DA=='

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

Помимо распределённой файловой системы вы можете использовать ceph для создания RBD дисков, которые можно монтировать индивидуально каждому клиенту, в отличии от общей cephfs, которая одна на всех. Также можно создать совместимое с S3 хранилище с помощью отдельного компонента RADOS Gateway (RGW). Инструкций в сети много, так как продукт популярный. Можно самому во всём разобраться.

Документация и примеры эксплуатации MicroCeph описаны в документации продукта. Она краткая, ёмкая и легкая для восприятия. Там монтируют немного по-другому, передавая файлы ключей из директории /var/snap/microceph/current/conf. Но общий смысл тот же самый.

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

#ceph #fileserver
👍194👎8
Media is too big
VIEW IN TELEGRAM
Я тут на днях видео посмотрел, которое заставило задуматься о будущем:

▶️ Как найти работу в ИТ после 45 лет?

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

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

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

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

Ещё один совет автора - вести какую-то публичную деятельность по своему профессиональному профилю. Хоть немного, но писать о том, что делаешь, что изучаешь. В блоге, соцсетях, telegram канале, тематических порталах. Где угодно, лишь бы аудитория была. Это будет помогать в трудоустройстве.

Что думаете по этому поводу? Сами ощущали, что с возрастом с работой становится сложнее? У меня тут аудитория возрастная. Недавно видел в чате с названием что-то типа Деды-Программисты, ссылку на свой канал, где его упомянули в контексте канала для дедов админов. Даже не знаю, как к этому относиться :) Дедом себя пока не ощущаю, хотя по меркам IT уже возрастной человек.

Я по собеседованиям лет 8 не ходил. Вообще не знаю, что там с наймом сейчас и как к нему готовиться. Для меня это уже, наверное, проблема. Меня работа находит сама из-за публичности, но это исключение. На этой неделе приходили 2 запроса по работе: развернуть кластер ceph под S3 (я поэтому про ceph вспомнил и заметку написал) и локальный сервер Asterisk. Работу не взял, так как и так трудоустроен. Времени свободного нет. Посты сюда по вечерам да ночам пишу.

#разное
👍173👎5
Некоторое время назад я упомянул игру Симулятор системного администратора. Посмотрел запись игрового процесса, который мне показался необычным и приближённым к реальности.

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

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

Во время игры вы можете менять конфигурацию системных блоков. Запускать их, садиться за монитор, проверять сетевые настройки, что-то пинговать. В распоряжении у вас будет LAN-тестер, патчкорды.

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

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

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

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

🎮 Steam / ▶️ Видео

#игра
1👍140👎8
На прошлой неделе гремела новость с исключением русских мэйнтейнеров из числа ответственных лиц, принимающих изменения в код ядра Linux. Я особо обсуждения не читал, потому что их слишком много, а новости все довольно сухие. Фактуры там не так много.

Скажу своими словами, как мне видится эта ситуация. С одной стороны вроде ничего особенного не случилось, потому что код ядра всё равно открыт. Бери и пользуйся. Копируй ядро и вноси туда свои изменения.

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

Ядро Linux по факту является основой нашего импортозамещения на уровне операционных систем. Практически все они сделаны на нём. Теперь вырастет стоимость развития и поддержки.

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

С ядром Linux в России вряд ли наберётся ресурсов на самостоятельное развитие. Вот если бы с Китаем объединиться, думаю, результат бы был. Может и будет. Поживём - увидим. Всё идёт к тому, что интернет, как и весь мир, сегментируется. Уже и Linux скоро у каждого свой будет.

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

'It's really hard to find maintainers...' Linus Torvalds

#разное
2👍103👎24
Рекомендация — два полезных ресурса для ИТ-специалистов и опытных пользователей:

🧑‍💻 NetworkAdmin — автор канала делится полезной информацией про Windows/Linux, актуальными уязвимостями, а также историями основанными на личном опыте в IT.

⚙️ EasyTools — сервис содержит набор инструментов для решения повседневных задач прямо в мессенджере, не покидая его.

Инструменты: Загрузчик видео, Генератор паролей, DNS Lookup, Проверка SSL, Whois, Geo IP, Сканер портов, Vendor Lookup.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍74👎7
Предлагаю вашему вниманию ping нетрадиционной графической ориентации - gping. Ну а если серьёзно, то эта заметка будет про две пинговалки, дополняющие стандартный ping.

1️⃣ Про gping я уже писал несколько лет назад. Она умеет строить график времени отклика пингуемого хоста или группы (❗️) хостов. В целом, ничего особенного в этом нет, но тот, кто формирует списки пакетов к дистрибутивам решил, что утилита достойна внимания и включил её в стандартные репозитории Debian и Ubuntu. В Убутне она уже есть, начиная с 23-й версии. В Debian появится в 13-й. Она уже там.

Ставим так:

# apt install gping

Пингуем несколько хостов и смотрим отклик:

# gping 1.1.1.1 8.8.8.8 8.8.4.4

1.1.1.1 отвечает заметно быстрее. Есть версия и под Windows. Скачать можно в репозитории. Gping скорее нужен для побаловаться в личном терминале. Я себе в WSL поставил. А вот следующий пример будет более востребован на серверах и прикладных задачах.

2️⃣ Fping позволяет быстро пинговать списки узлов. Это старя программа, которая давно живёт в стандартных репозиториях. Мониторинг Zabbix с самых первых версий именно её использует для своих icmp проверок (icmpping, icmppingloss, icmppingsec).

Ставим так:

# apt install fping

Fping удобен для массовых проверок. Например, быстро находим активные узлы в локальной сети:

# fping -g 192.168.13.0/24 -qa
192.168.13.1
192.168.13.2
192.168.13.17
192.168.13.50
192.168.13.186

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

# fping -s -g 192.168.13.1 192.168.13.50 -qa

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

# fping 10.20.1.2
10.20.1.2 is alive

Можно скрыть вывод, а результат отследить кодом выхода:

# fping 10.20.1.2 -q
# echo $?
0

Успех, то есть хост ответил.

# fping 10.20.1.3 -q
# echo $?
1

Хост не ответил, код выхода 1. Удобно, что нет лишнего вывода. Ничего обрезать и скрывать не надо.

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

#linux #terminal
2👍214👎4
Прочитал очень интересную техническую статью на хабре, в которой много просто любопытных и прикладных моментов. Зафиксирую некоторые их них в заметке для тех, кто не захочет читать весь материал. Он объёмный.

Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза

1️⃣ Кто-то заезжает в облака, кто-то выезжает. Автор построил Kubernetes кластер на Bare Metal, снизив затраты по сравнению с Google Cloud в 4 раза, увеличив производительность в 4 раза! Так что не стоит полностью забывать железо и жить в облачных абстракциях. В каких-то случаях стоит спускаться на землю и не терять навык работы на ней.

2️⃣ Очень объёмный и насыщенный материал по тестированию дисковой подсистемы с конкретными примерами для fio. Если не хочется сильно вникать, то можно сразу брать готовые команды для линейного чтения, линейной записи, задержки случайного чтения и т.д. Там для всех популярных метрик есть примеры.

3️⃣ Автор собрал свой Docker контейнер, который выполнят весь набор тестов и выводит результат в формате CSV для удобного экспорта в табличку с графиками.

# docker run -it --rm --entrypoint /run.sh --privileged maxpain/fio:latest /dev/nvme0n1

❗️Тест fio с записью на диск деструктивный. Нельзя запускать этот тест на диске с данными. Они будут уничтожены. Это для чистых блочных устройств. Я попробовал эти тесты. Удобно сделано. Рекомендую забрать к себе. Там всё самое интересное в скрипте /run.sh. Можно сохранить к себе на память только его:

# docker create --name fio maxpain/fio:latest false
# docker cp fio:/run.sh ~/run.sh

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

4️⃣ Производительность дисковой подсистемы в Talos Linux по сравнению с обычным Debian была в 1,5-2 раза ниже. Причина была в разных параметрах ядра.

5️⃣ Настроек ядра очень много. Сравнение настроек в разных дистрибутивах вручную очень трудоёмкая задача. Автор сгрузил diff файл параметров ядра указанных систем в ChatGPT и он сразу же выдал ответ, какой параметр приводит к снижению производительности:

В Talos Linux включен параметр CONFIG_IOMMU_DEFAULT_DMA_STRICT=y, в то время как в Debian используется CONFIG_IOMMU_DEFAULT_DMA_LAZY=y. Режим strict в IOMMU заставляет ядро немедленно выполнять сброс кэшей IOMMU при каждом связывании и отвязывании DMA (то есть при каждом вводе-выводе), что приводит к дополнительной нагрузке на систему и может значительно снизить производительность ввода-вывода при интенсивных операциях, таких как тестирование IOPS.

6️⃣ Разница в производительности может быть значительной между разными версиями ядра Linux. Это связано с патчами безопасности, которые снижают производительность. Для каких-то старых ядер, которые уже не поддерживаются, этих патчей может не быть. На них производительность будет выше (а безопасность ниже).

7️⃣ Благодаря множественным манипуляциям над системой Talos Linux автору удалось подтянуть её производительность до оригинального Debian. Но всё равно она была ниже. Из этого можно сделать вывод, что различные альтернативные дистрибутивы Linux стоит использовать осторожно и осмысленно. Изначальная разница в производительности в 2 раза как-бы не мелочь.

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

☝️ Отметил для себя полезность ИИ. Надо начинать пользоваться.

#linux #perfomance
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍117👎10
Тема тестирования производительности диска непростая. Если есть время и чёткая задача, то с помощью fio и продолжительного времени на тесты, можно добиться стабильного результата. А если хочется быстро оценить работу диска и сравнить результат, то возникают вопросы даже с самым простым тестом на последовательную запись.

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

1️⃣ Если просто писать данные на диск с уровня операционной системы Linux, то она будет их кэшировать, пока у неё достаточно оперативной памяти для этого. Если не учитывать этот момент, то результаты будут разными в зависимости от объёма оперативной памяти и размера записываемых данных.

2️⃣ Если речь идёт о виртуальных машинах, то там есть слой кэширования гипервизора.

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

На практике это выглядит так. Берём виртуальную машину на Proxmox с 1G оперативной памяти и виртуальным диском без кэширования. Пробуем тесты на запись с помощью dd и разных флагов:

# dd if=/dev/zero of=/tempfile bs=1M count=512
259 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000
247 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=direct
240 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=dsync
123 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=sync
123 MB/s

Используются флаги:

▪️direct - прямая запись в обход файлового кэша и синхронизации
▪️dsync - запись данных с синхронизацией каждого блока, то есть ждём подтверждение диска об успешной записи
▪️sync - запись данных и метаданных с синхронизацией

Результаты меня удивили. Я всегда был уверен, что запись dd по умолчанию будет вестись в кэш ОС, если хватает оперативной памяти. Я провёл много тестов на разных виртуалках, в разных гипервизорах, с разным количеством памяти в VM. И везде запись нулей из /dev/zero на диск в кэш не попадала. Из-за большого количества тестов глаз замылился, и я не мог понять, в чём причина. Подумал уже, что по дефолту dd работает с флагом direct, но это не так.

Причина вот в чём. Если файл /tempfile уже существует, то запись ведётся напрямую, а если отсутствует и оперативы достаточно, то в кэш. Проверяем:

# dd if=/dev/zero of=/tempfile bs=1M count=200
231 MB/s
# rm /tempfile
# dd if=/dev/zero of=/tempfile bs=1M count=200
635 MB/s

Если взять ещё меньше файл, то скорость будет ещё больше:

# rm /tempfile
# dd if=/dev/zero of=/tempfile bs=1M count=100
1.6 GB/s

Если вы будете писать с помощью dd обычный файл, который полностью помещается в оперативную память, то тоже при первичной записи файл попадёт в кэш:

# dd if=/tempfile of=/tempfile2 bs=1M count=128
910 MB/s

Всё было записано в кэш. Скорость диска мы вообще не увидели. Для тестирования линейной скорости записи на диск обязательно используйте флаг direct или sync. Значения вы получите разные в зависимости от флага, но они точно будут без использования кэша ОС.

А теперь я включу кэширование диска (Write back) на уровне гипервизора и выполню тесты с direct:

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=direct
1.0 GB/s

Скорость нереальная, так как файл не влезает в оперативку. Работает кэширование с уровня гипервизора, так что из VM измерить реальную скорость невозможно. Как зачастую невозможно и на арендованных VDS.

Интересная тема. Пару часов проковырялся с тестами, документацией, статьями. Забыл упомянуть, что погонял тесты с помощью sysbench, используя те же размеры блока и их количества. Результаты полностью совпадают с dd.

❗️Если при тестах диска вы видите очень большой разброс в значениях, у вас 100% где-то что-то залетает в кэш. Я не раз слышал от знакомых и читателей замечания по этому поводу. Люди получают сильно разные результаты тестов и не понимают, как их интерпретировать. Могут из-за этого ошибочно посчитать одно хранилище или формат диска быстрее другого.

#linux #disk
2👍91👎4