Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787 Заявка: 8137718351
Show more📈 Analytical overview of Telegram channel Библиотека девопса | DevOps, SRE, Sysadmin
Channel Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) in the Russian language segment is an active participant. Currently, the community unites 10 325 subscribers, ranking 11 845 in the Technologies & Applications category and 61 294 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 325 subscribers.
According to the latest data from 08 November, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -46 over the last 30 days and by -2 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 8.96%. Within the first 24 hours after publication, content typically collects 4.67% reactions from the total number of subscribers.
- Post reach: On average, each post receives 925 views. Within the first day, a publication typically gains 482 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 1.
- Thematic interests: Content is focused on key topics such as devops'a, навигация, скрипт, docker, git.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Заявка: 8137718351”
Thanks to the high frequency of updates (latest data received on 09 November, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
user@dev:/$ su john
Будет запрошен пароль, нужно ввести пароль именно от учетной записи john, а не от user.
А вот пример с sudo:
user@dev:/$ sudo -u john whoami
А здесь нужно ввести пароль от учетной записи user, а не от John или рута. Но для этого случая сперва необходимо добавить пермишены для пользователя user в файл /etc/sudoers.
user ALL=(ALL:ALL) ALL
Редактировать этот файл можно по средствам команды visudo. А свалидировать конфиг можно командой visudo -c. Редактирование этого файла через visodu хорошо тем, что если вы допустите ошибку, то при сохранении, оно сообщит о ней.А для чего нужен дефис после su? Для очистки переменных и чтобы пользоваться чистой оболочкой при переключении на другого пользователя. Авторизуемся под пользователем user и экспортируем переменную:
ssh user@pc
export a="test"
Теперь у пользователя user есть переменная "a" которая = test.
Переключаемся на пользователя John и смотрим переменную "a"
su john
echo $a
Вывелась строчка test. То есть все что мы задали под user, перекочевало в оболочку john. А теперь добавим дефис:
su - john
echo $a
Переменная $a больше не выводится. Чистая оболочка. Кстати с этим дефисом часто косячат и потом долго не могут понять в чем причина. Переменные вроде были заданы, а потом куда-то пропали.
su (с дефисом) — сначала переключается пользователь, а затем запускается shell, зачищаются все переменные.
su (без дефиса) — переключает пользователя, оставляя переменные окружения старого пользователя.У sudo есть подобные ключи -s -i
user@pc:/$ sudo -s
Запустится оболочка с правами root
user@pc:/$ sudo -i
Запустится оболочка, но уже с чтением файлов root/.profile/.bashrc и т.п. Можно попробовать добавить экспорт переменной в .profile, сделать sudo -s/-i и увидеть что с ключом -i переменная выведется на экран.
По сути sudo -i = команде sudo su -. Но обычно за sudo su - в приличных местах можно получить по шапке. Это плохая практика! Так как это порождает дополнительный процесс и больше гемора с набором самой команды.
log_format nginx_json escape=json '{"time_local":"$time_local", "cloud_ip":"$http_x_real_ip", "ip":"$http_cf_connecting_ip", "connection":"$connection", "request_completion":"$request_completion", "status":"$status", "rtime":"$request_time", "rlenght":"$request_length", "content_type":"$content_type", "content_length":"$content_length", "bytes_sent":"$bytes_sent", "body_bytes_sent":"$body_bytes_sent", "raddr":"$remote_addr", "ruser":"$remote_user","upstream_addr":"$upstream_addr", "upstr_resp_time":"$upstream_response_time", "upstr_cache_status":"$upstream_cache_status", "upst_status":"$upstream_status", "gzip_ratio":"$gzip_ratio", "http_x_forwarded_for":"$http_x_forwarded_for", "proxy":"$proxy_host:$proxy_port", "proxy_int_body_length":"$proxy_internal_body_length", "server_proto":"$server_protocol", "rmethod":"$request_method", "uri":"$uri", "args":"$args", "http_referer":"$http_referer", "uag":"$http_user_agent"}';
access_log /var/log/nginx/access.log nginx_json;
error_log /var/log/nginx/error.log;
Получаем максимальную информацию о клиенте в json формате, которую пробиваем средствами nginx. И теперь все это можно легко скармливать всяким эластикам и т.п. без парсинга и прочего.
Хранить логи в файлах не айс — хорошо бы запихать их в system journal.
Добавим пару строк в nginx.conf и всё логирование будет перенаправлено в system journal.
error_log syslog:server=unix:/dev/log;
access_log syslog:server=unix:/dev/log nginx_json;
А можно комбинировать, писать одновременно логи в файл в дефолтном шаблоне nginx’а и параллельно писать в system journal в json:
log_format nginx_json ...
log_format nginx_default ...
access_log /var/log/nginx/access_json.log nginx_json;
access_log /var/log/nginx/access_default.log nginx_default;
Чтобы посмотреть логи в system journal, воспользуйтесь командой: journalctl -fCONFIG_ZSWAP_DEFAULT_ON=N
Но чтобы применить эту опцию, нужно пересобрать ядро. Пойдем легким путем и выключим zswap через загрузчик grub.
Редактируем файл /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="zswap.enabled=0" loglevel=3 quiet "
Не забываем перегенирировать конфиг grub:
grub-mkconfig -o /boot/grub/grub.cfg
Перезагружаем машину и проверяем отключение zswap:
cat /sys/module/zswap/parameters/enabled
Если вывелась буква N — значит все правильно.
Ну и наконец включаем zram. Для этого пишем bash скрипт и кидаем его в автозагрузку:
#!/bin/bash
modprobe zram
mkdir /sys/block/zram0
echo lz4 > /sys/block/zram0/comp_algorithm
echo 1G > /sys/block/zram0/disksize
echo 2 > /sys/block/zram0/max_comp_streams
mkswap --label zram0 /dev/zram0
swapon --priority 100 /dev/zram0
1. Загружаем модуль zram
2. Выбираем алгоритм сжатия lz4 (либо zstd)
3. Объем zram 1гиг физической оперативки
4. 2 это количество потоков сжатия (потоки процессора)
5. Создаем блочное устройство и включаем его
Запускаем скрипт и проверяем включение командой: zramctl. Если на экран что-то вывелось, значит всё хорошо и сжатие начало работать.
Если заморачиваться с bash скриптами не хочется, ставим утилиту которая будет работать через systemd.
apt install systemd-zram-generator
Правим конфиг /etc/systemd/zram-generator.conf
[zram0]
zram-size = ram
compression-algorithm = lz4
Активируем и запускаем:
systemctl daemon-reload
systemctl start /dev/zram0
Всё! Теперь оно само будет запускаться без лишних движений.