Как работает cron и зачем он нужен?

Если вы хоть раз хотели, чтобы скрипт запускался сам — без вашего участия — скорее всего, вам пригодится cron. Это системный инструмент (ДЕМОН), который позволяет выполнять команды/скрипты по расписанию.

Сфер применения достаточно много, но суть технологии - автоматизировать рутинные задачи: очистка логов, обновление данных и т.д. Как говорилось в одной из статей выше cron — демон, который выполняет команды в запланированное время.

Дополню, что он каждую минуту проверяет свое расписание, наступило ли время начинать выполнять задачу. Расписание хранится в специальной таблице — crontab и задается в формате:

* * * * * команда
┬ ┬ ┬ ┬ ┬
│ │ │ │ └── День недели (0–7) — где 0 и 7 — это воскресенье
│ │ │ └──── Месяц (1–12)
│ │ └─────── День месяца (1–31)
│ └──────── Час (0–23)
└────────── Минута (0–59)

0 4 * * * /home/user/backup.sh

Этот скрипт будет запускаться каждый день в 4:00. Звёздочка означает «каждое значение»:

* * * * * — каждую минуту, каждый час, каждый день...;
30 9 * * * — каждый день в 9:30;
0 0 * * 0 — каждое воскресенье в полночь;

На старте может быть непонятно, поэтому пользуйтесь: crontab.guru

Практический пример

Допустим у нас в какой-нибудь папке (например, /var/log/myapp) копятся логи и мы хотим удалять раз в неделю старые. Сначала создадим простой bash-скрипт clear_logs.sh:

#!/bin/bash

LOG_DIR="/var/log/myapp"
DAYS_TO_KEEP=7

find "$LOG_DIR" -type f -name "*.log" -mtime +$DAYS_TO_KEEP -exec rm -f {} \;

Этот скрипт ищет ".log" файлы в указанной директории (LOG_DIR) и удаляет те, что старше 7 дней (DAYS_TO_KEEP). Делаем файл исполняемым и добавляем cron-задачу:

chmod +x /home/user/noscripts/clear_logs.sh

0 0 * * 0 /home/user/noscripts/clear_logs.sh >> /var/log/clear_logs.log 2>&1

"0 0 * * 0" — каждое воскресенье в 00:00;

">> /var/log/clear_logs.log" — всё, что скрипт напишет в stdout (обычный вывод), попадёт в лог;

"2>&1" — перенаправление потока ошибок stderr в поток stdout, чтобы они тоже записывались в лог;

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

Важные команды:

Чтобы посмотреть список задач (расписание), можно использовать команду "crontab -l". Создание и изменение задач, команда "crontab -e". Удаление всех задач "crontab -r".

LinuxCamp | #cron

Новое ядро подъехало "Linux 6.15"

В новую версию принято 15945 исправлений от 2154 разрабов, размер патча - 59 МБ (добавлено 739608 строк кода). Около 41% всех изменений связаны с драйверами устройств.

Из ключевого:

— многочисленные апгрейды драйверов для AMD и Intel;

— дальнейшая интеграция Rust в ядро (язык всё активнее применяется в кодовой базе, где критична безопасность);

— стабилизация файловой системы Bcachefs (близка к полноценному применению в продуктивных сценариях);

— новая подсистема FWCTL (предназначен для управления прошивками);

— доработка поддержки Apple Silicon (архитектура ARM постепенно получает стабильные драйверы и поддержку в ядре);

— улучшения планировщика задач (положительно скажется на общей отзывчивости систем под высокой нагрузкой);

— расширение поддержки игровых контроллеров через драйвер XPad;

Подробнее о нововведениях можно прочитать тут.

LinuxCamp | #news

Продвинутый просмотр размера каталога: du

Вы сейчас можете подумать, есть же команда "ls -l", которая показывает расширенный список атрибутов... Размер каталога значит тоже должна выводить. Ну, нет) Для этого нам нужно использовать утилиту du, которая для этих целей подойдет отлично.

Размер каталога

В качестве примера возьмем папку Downloads и выведем ее размер:

$ sudo du -sh ~/Downloads
96M /home/parallels/Downloads

Для лучшего понимания вкратце пройдемся по задействованным опциям:

-s - выводить только общий размер самой папки и не отображает информацию о ее вложенных ресурсах. Тем самым, не захламляя stdout;
-h - выводить информацию в привычном виде. Речь о единицах измерения (K – килобайт, M – мегабайт и т. д.);

Размер файлов на верхнем уровне

Также можно глянуть общий размер только файлов на самом верхнем уровне каталога. Для этого добавляем опцию "-S". Тут мы не пойдем вглубь и не станем проверять ресурсы внутри образного "~/Downloads/dir1" и т.д:

$ sudo du -sSh ~/Downloads
92M /home/parallels/Downloads

Размер вложенных каталогов

$ sudo du -h ~/Downloads

В результате отобразится сначала размер вложенных каталогов, а потом и самого "Downloads" С помощью опции --max-depth можно задать максимальную глубину вложенности. Если вам интересен только верхний каталог, то глубина == 0, если еще и вложенные в нее, то >= 1:

$ sudo du -h --max-depth=1 /etc
16K /etc/lighttpd
8.0K /etc/python3
56K /etc/iproute2

Это будет особенно полезно, когда директория сильно разрослась, и нужно ограничить область действия для утилиты.

Размер файлов с учетом вложенности

Также можно увидеть размер целевого каталога и всех ресурсов внутри (с учетом вложенности). Для этих целей нужно приписать флаг "-a":

$ sudo du -ah ~/Downloads
96M ...Downloads/code_1.99.3-1744760597_arm64.deb
4.0K ...Downloads/file-part_2
4.0K ...Downloads/file-part_1

Если данных на выходе получается слишком много, то может иметь смысл их отсортировать по размеру:

$ sudo du -ah ~/Downloads | sort -rh
96M .../Downloads/code_1.99.3-1744760597_arm64.deb
96M .../Downloads
20K .../Downloads/test

LinuxCamp | #utils

Шпаргалка по ufw для базовой настройки фаервола

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

ufw (Uncomplicated Firewall) - простой способ настроить фаервол на Linux. Работает как обёртка над iptables, но не требует глубоких знаний сетевого стека.

Зачем вообще нужен фаервол?

Когда ты поднимаешь сервер (особенно публичный), он сразу становится видимым всему интернету. И даже если ты не настраиваешь ничего «опасного», какие-то сервисы по умолчанию могут слушать порты.

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

$ sudo apt install ufw

Перед включением стоит задать основные правила, иначе можно случайно отрезать себя от SSH-доступа (особенно на VPS). Начнем с самого важного:

$ sudo ufw allow ssh

Теперь можно активировать фаервол:

$ sudo ufw enable

Просмотр статуса и активных правил:

$ sudo ufw status verbose

Отключение при необходимости:

$ sudo ufw disable

Базовые правила, которые стоить задать

Одно правило по разрешению ssh-доступа мы уже добавили, также будет правильно разрешить веб-траффик (http/https):

$ sudo ufw allow 80,443/tcp

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

$ sudo ufw default deny incoming

$ sudo ufw default allow outgoing

Полезные команды:

Удалить правило:

$ sudo ufw delete allow 80/tcp

Разрешить доступ по конкретному IP:

$ sudo ufw allow from 192.168.1.10

Это может понадобиться, например, чтобы открыть порты для веб-траффика только Cloudflare или ServicePipe и закрыть для всего остального:

$ ufw default deny incoming
$ ufw default allow outgoing

# пердположим что 192.168.1.10 - IP нашего ServicePipe
$ sudo ufw allow from 192.168.1.10 to any port 22

Сбросить все правила и начать с нуля:

$ sudo ufw reset

После настройки рекомендую протестировать сервер из другого устройства или использовать онлайн-сервисы вроде portquiz или nmap для сканирования портов. Также полезно мониторить логи:

$ sudo less /var/log/ufw.log

Если ufw работает - ты увидишь записи о заблокированных соединениях, особенно на нестандартные порты. Даже минимальные настройки ufw — это уже огромный шаг вперёд в безопасности. Он не требует глубокого понимания iptables и легко вписывается в ежедневный рабочий процесс. Один раз настроил — и забыл.

LinuxCamp | #utils #devops

Почему docker compose logs -f спасает на проде

Когда что-то ломается в проде — время идёт на секунды. Не всегда есть доступ к графическому лог-серверу, и не всегда хочется копаться в docker exec, чтобы что-то вытащить. В таких случаях спасает простая команда:

docker compose logs -f

Она показывает живые логи сразу всех сервисов которые описаны в docker-compose.yml в данной директории.

В какой ситуации это может быть мастхев? Допустим что-то не стартует. Можно сделать быстрый дебаг ошибок конкретного сервиса:

docker compose logs -f backend

И ты моментально видишь stack trace, ошибку подключения к БД или криво прокинутую переменную. Кроме этого можно следить за цепочкой событий. Если сервисы завязаны друг на друге удобно запускать:

docker compose logs -f

И ты видишь весь «разговор» между фронтом, беком и базой, в одном терминале. Полезный флаг для просмотра логов:

docker compose logs -n 50 -f

"-n" - помогает просмотреть только последние N строк. Нужная и простая команда в арсенале, может спасти в самый ответственный момент.

LinuxCamp | #utils

ncdu — лучший способ быстро очистить место на сервере

Когда на сервере внезапно заканчивается место, первое, что хочется — понять, что его съело. Вместо того, чтобы долго ковыряться в du и find, просто поставь ncdu.

Это интерактивная утилита для анализа диска в терминале. Работает быстро, показывает размеры папок/файлов и позволяет удалять ненужное прямо из интерфейса:

$ sudo apt install ncdu

Для сканирования нужно просто ввести команду и передать целевой каталог. Чтобы промониторить корень:

$ sudo ncdu /

Нужные кнопочки:

Навигация - стрелками вверх/вниз.
Удаление - клавиша d.
Обновить - g.
Выйти - q.

В отличие от "du -sh *", ncdu не только показывает вес директорий, но и позволяет разобраться в них быстрее. Особенно полезно, если забит логами /var/log, кто-то накатил 100500 .tar.gz или забыли почистить кэш в home. Утилита очень выручает, когда каждая секунда важна. Установил - посмотрел - удалил - освободил.

LinuxCamp | #utils

Базовая настройка Nginx и подключение домена: как я это сделал

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

Шаг 1: Покупка домена

Я купил домен на reg.ru - обычная регистрация, ничего необычного, правда с верификацией по паспорту. После покупки нужно было настроить DNS-записи, чтобы домен знал, на какой сервер ему "смотреть".

Шаг 2: Настройка DNS

В панели управления reg.ru я прописал A-записи для поддоменов. Примерно через 5–10 минут домен уже начал резолвиться (хотя может и сильно дольше):

@ → IP моего сервера
www → тот же IP

Шаг 3: Установка Nginx

На сервере я поставил Nginx:

$ sudo apt install nginx -y

Шаг 4: Bash-скрипт для настройки проксирования

Чтобы не ковыряться руками в /etc/nginx/sites-available, я написал простой скрипт, который:

1) Создаёт конфиг для твоего домена
2) Проксирует запросы на нужный порт
3) Автоматически подключает SSL через certbot (сертификат безопасности, то самое "s" в https)

Запрашиваем данные, вводим домен и порт приложения, на который будет проксироваться nginx:

#!/bin/bash
read -p "Домен: (например, example.ru)" DOMAIN
read -p "Порт (например, 9003): " PORT

Задаем стандартные директории для конфигов и логов Nginx:

SITES_AVAILABLE="/etc/nginx/sites-available"
SITES_ENABLED="/etc/nginx/sites-enabled"
CONF_FILE="$SITES_AVAILABLE/$DOMAIN"
LOGS_DIR="/var/log/nginx/$DOMAIN"

Создаём папку для логов:

$ sudo mkdir -p "$LOGS_DIR"

Генерируем конфиг:

sudo tee "$CONF_FILE" > /dev/null <<EOF
server {
    listen 80;
    server_name $DOMAIN;
    location / {
        proxy_pass http://127.0.0.1:$PORT;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
    }
    error_log $LOGS_DIR/error.log;
    access_log $LOGS_DIR/access.log;
}
EOF

Включаем сайт

$ sudo ln -s "$CONF_FILE" "$SITES_ENABLED/$DOMAIN" 2>/dev/null

Проверка и перезапуск:

if sudo nginx -t; then
    sudo systemctl reload nginx
else
    exit 1
fi

Получаем SSL-сертификаты:

$ sudo certbot --nginx -d "$DOMAIN"

Финальная проверка и reload

if sudo nginx -t; then
    sudo systemctl reload nginx
else
    exit 1
fi

SSL-сертификаты от Let's Encrypt. Certbot сам всё сделал: прописал listen 443 ssl и нужные директивы, плюс настроил редирект с HTTP на HTTPS. Если хочешь, можешь вручную добавить в конфиг ssl_protocols, ssl_ciphers, HSTS и другие фишки безопасности, но базовая настройка уже работает.

В итоге после запуска скрипта твой сайт по HTTPS работает на нужном порту, все логи идут в /var/log/nginx/имя_домена/, и весь трафик проксируется на нужное приложение. Готовый скрипт:

#!/bin/bash

read -p "Домен: (например, example.ru)" DOMAIN
read -p "Порт (например, 9003): " PORT

SITES_AVAILABLE="/etc/nginx/sites-available"
SITES_ENABLED="/etc/nginx/sites-enabled"
CONF_FILE="$SITES_AVAILABLE/$DOMAIN"
LOGS_DIR="/var/log/nginx/$DOMAIN"

sudo mkdir -p "$LOGS_DIR"

sudo tee "$CONF_FILE" > /dev/null <<EOF
server {
listen 80;
server_name $DOMAIN;
location / {
proxy_pass http://127.0.0.1:$PORT;
proxy_set_header Host \$host;
proxy_set_header X-Real-IP \$remote_addr;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto \$scheme;
}
error_log $LOGS_DIR/error.log;
access_log $LOGS_DIR/access.log;
}
EOF

sudo ln -s "$CONF_FILE" "$SITES_ENABLED/$DOMAIN" 2>/dev/null

if sudo nginx -t; then
sudo systemctl reload nginx
else
exit 1
fi

sudo certbot --nginx -d "$DOMAIN"

if sudo nginx -t; then
sudo systemctl reload nginx
else
exit 1
fi

echo "Готово."

LinuxCamp | #devops #nginx #bymaga

Как очистить сервер от мусора

Со временем сервер обрастает мусором: логи, временные файлы, старые кэши. Разберем команды по удалению всего этого добра. Бонусом в конце будет готовый файл для запуска скрипта с логированием, который будет каждый день удалять все ненужное 🙂

Команда для удаления .log-файлов старше 7 дней:

$ find /var/log -type f -name "*.log" -mtime +7 -delete

find - команда поиска файлов
/var/log - папка, где хранятся логи
"-type f" - ищем только файлы
-name "*.log" - по шаблону *.log
"-mtime +7" - старше 7 дней
-delete - сразу удалять

Очистить systemd-журналы:

$ journalctl --vacuum-time=7d

Эта команда удаляет внутренние журналы системы, которым больше 7 дней. Такие журналы хранят события: старты, ошибки, перезагрузки, службы — всё, что происходило в системе. Обычно занимают много места, особенно если сервер работает давно.

Очистить временные файлы:

$ rm -rf /tmp/* /var/tmp/*

Удаляет всё из временных директорий. Будь осторожен, если на сервере кто-то работает прямо сейчас.

Очистить кэш и мусор после установки пакетов:

$ apt clean && apt autoremove -y

"apt clean" - очищает кэш установленных .deb файлов
"apt autoremove" - удаляет больше не нужные зависимости
"-y" - выполнять без лишних вопросов

Ниже прикладываю готовый файл. Его нужно будет сделать исполняемым и можно добавить в crontab с запуском в каждое воскресенье в 0:00. Все результаты будут сохраняться в файл "/var/log/server-cleanup.log":

#!/bin/bash

LOG_FILE="/var/log/server-cleanup.log"
echo "[$(date)] Очистка начата" >> "$LOG_FILE"

find /var/log -type f -name "*.log" -mtime +7 -delete >> "$LOG_FILE" 2>&1
journalctl --vacuum-time=7d >> "$LOG_FILE" 2>&1
rm -rf /tmp/* /var/tmp/* >> "$LOG_FILE" 2>&1
apt clean && apt autoremove -y >> "$LOG_FILE" 2>&1

echo "[$(date)] Очистка завершена" >> "$LOG_FILE"

$ sudo chmod +x /usr/local/bin/clean-server.sh

$ sudo crontab -e

0 0 * * 0 /usr/local/bin/clean-server.sh

LinuxCamp | #devops #utils

Systemd Timer - альтернатива cron

Если ты используешь cron для запуска скриптов по расписанию - пора бы взглянуть в сторону systemd timer. Это часть системы systemd - более новый и с фишками, которых нет в cron. Разберёмся, зачем он нужен и как с ним работать.

Что умеет systemd timer

systemd timer позволяет запускать задачи по расписанию вместо или в дополнение к cron. Отличается он несколькими вещами:

1) Привязан к сервису systemd (можно логировать, отслеживать статус, перезапускать);
2) Логирует всё через journalctl (никаких потерянных логов). Можно быстро проверить, когда скрипт реально запускался и с каким результатом;
3) Флаг "Persistent=true" позволяет выполнить задачу после включения сервера, если она была пропущена во время выключения;
4) Можно задавать зависимости, например, чтобы очистка выполнялась только после поднятия сети, или после других сервисов;
5) Более гибкое расписание такого вида "OnCalendar=Wed 09:44";

Пример запуска скрипта.

Возьмём тот, что был в прошлом посте. Создадим юнит для сервиса:

$ nano /etc/systemd/system/clean-server.service

[Unit]
Denoscription=Автоматическая еженедельная очистка сервера

[Service]
Type=oneshot
ExecStart=/usr/local/bin/clean-server.sh

Создаем таймер:

nano /etc/systemd/system/clean-server.timer

[Unit]
Denoscription=Таймер для еженедельной очистки сервера

[Timer]
OnCalendar=Sun 02:00
Persistent=true

[Install]
WantedBy=timers.target

Активируем:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable --now clean-server.timer

Можем проверить статус:

systemctl list-timers | grep clean-server

И посмотреть те самые автоматические логи:

systemctl status cleanup-server.timer
# или
journalctl -u clean-server.timer 

Короч, systemd timer - более современный способ управлять задачами по расписанию. Он не заменяет cron полностью, но стоит внимания в большом количестве случаев.

LinuxCamp | #utils #cron

Пацаны, биг дроп на канале!

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

1) без английского у меня ничего не получится;
2) обязательно нужно высшее образование;
3) я не потяну эту науку;
4) смысл мне начинать, если AI через пару лет всех заместит;

И это на самом деле может демотивировать. Человек, вместо того, чтобы репу чесать и сомневаться, способен заспидранить обучение и через год выйти на первую работу)

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

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

Смотреть на YouTube

Что такое Ansible - и как обновить пакеты сразу на 10 серверах

Ansible - это инструмент для автоматизации. Он позволяет управлять сотнями серверов как одним: обновлять, настраивать, перезапускать сервисы - всё с помощью простого playbook (набор команд в YAML-файле).

Для начала нужно скачать Ansible:

sudo apt install ansible -y

Вот минимальный пример update.yml:

- name: Обновление пакетов
  hosts: all
  become: yes  # получаем root-доступ
  tasks:
    - name: apt update && upgrade
      apt:
        update_cache: yes
        upgrade: dist

Как это работает:

hosts: all - применяем ко всем серверам из инвентаря
become: yes - выполняем от имени root
apt: - встроенный модуль Ansible для Debian/Ubuntu

Запуск:

ansible-playbook -i inventory update.yml

Для подробностей можно добавить -v или -vvv:

ansible-playbook update.yml -vvv

А если хочешь сначала посмотреть, что бы изменилось, но не выполнять, используй режим dry run:

ansible-playbook update.yml --check

LinuxCamp | #utils

Caddy - замена Nginx с авто-TLS и минимальной настройкой

Ты наверняка используешь Nginx как прокси-сервер или для выдачи статики. Но есть более свежий и удивительно простой веб-сервер - Caddy. Он сам получит HTTPS, сам перезапустится при изменении конфига и вообще просит к себе минимум внимания. Разбираемся, чем он крут.

Caddy — это современный веб-сервер, написанный на Go. Его главная фишка — всё работает из коробки:

1) Автоматический HTTPS от Let's Encrypt
2) Перезапуск при изменении конфига
3) Встроенный reverse proxy
4) Простая конфигурация (Caddyfile)

Установка:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy.gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

sudo apt update
sudo apt install caddy

Минимальный пример Caddyfile:

example.com {
  reverse_proxy localhost:3000
}

- Заменяешь "example.com" на свой домен
- localhost:3000 (твой сервис);

Запуск сервера

Caddy работает как systemd-сервис. Чтобы запустить или перезапустить:

sudo systemctl restart caddy

После этого caddy сам проверит домен, получит HTTPS-сертификат от Let's Encrypt, настроит прокси и всё заработает)

Почему это удобно

- Не нужно возиться с SSL — HTTPS работает из коробки
- Конфигурация проще, чем у Nginx
- Отлично подходит для pet-проектов, демо, VPS-серверов

Когда лучше остаться с Nginx

1) Если у тебя уже сложная конфигурация с множеством rewrite, map, ssl_params
2) Если нужна кастомная сборка модулей
3) Если используешь stream (TCP/UDP proxy)

LinuxCamp | #utils #devops