Системное администрирование *

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

Я пришёл из Яндекса
Я строил облака
Я знаю, как делать лидоген

А потом ты открываешь план, который он накатал, и читаешь:
Надо срочно повысить охваты и сделать event-маркетинг в партнёрстве с департаментом госсектора. Занавес.
Это даже не ахинея. Это скриншот из какой-то методички 2010 года.

Кто ты, воин?
Формально - новоявленный руководитель блока продаж и маркетинга.
По факту - всего навсего бывший аккаунт-директор. До этого вообще специалист по ИБ в системных интеграторах.

Он искренне считает, что понимает рынок.
Он не знает, кто покупает облака. Он не знает, зачем их покупают.
Он путает капексы с опексами. У него в голове до сих пор есть'облако' как магическое слово, которое должно продавать себя само. А если не продаёт — значит, виноват кто? Конечно, маркетинг.

Проблема даже не в нём
Люди не обязаны быть идеальными. Бывают разные.
Проблема в механике: его сюда спустили.
Он не вырос, не понял, не прошёл путь. Его просто назначили.

Сходу в кресло, сразу - с правом финального слова.
А ты теперь объясняй, почему твой roadmap не просто слайд. Почему у тебя нет 'горизонтальных альянсов'. Почему ты не пишешь статьи от имени продована по цифровой трансформации.

Идеи от него сыпятся каждый день
Давайте срочно делать холодные звонки
Нам нужно охватить весь SMB. Конечно, инфраструктуру же как пирожки на базаре продают.
Где у нас продажи через Telegram?'

Ты сначала смеёшься. Потом объясняешь. Потом просто перестаёшь говорить. Потому что бесполезно.

Он не слышит - он управляет. Или думает, что управляет.

Чем всё закончится?
Ты либо уйдёшь.
Либо адаптируешься.
Либо станешь таким же.

А он? Он - останется. Потому что его назвали Начальником начальника. Потому что кто-то где-то решил, что у него 'видение'. Потому что резюме с Яндекс.Облаком, казалось бы, всё ещё производит впечатление на тех, кто никогда туда не заглядывал.

Вывод?
Парашюты должны раскрываться до касания земли.
Иначе потом мы просто собираем обломки и делаем вид, что это было управляемое приземление.

Подключайтесь к трансляции митапа для инженеров и сисадминов

Сегодня на SelectOS OpenFix Day обсуждаем лучшие практики работы с Open Source, вспоминаем свои инженерные факапы и разбираемся с нестандартными инфраструктурными задачами. Начало трансляции в 18:30 (мск).

Программа

• Rust в ядре — прогресс или костыль в бронзе? Живая дискуссия про разный опыт работы с этим языком программирования.

• Как справиться с инфраструктурным хаосом: вредные советы.

• Честные истории о том, как падал и поднимался прод.

Ждем всех, кто не просто использует Linux, а вникает в код, фиксирует баги и патчит уязвимости. 

Смотреть трансляцию:

📱на YouTube

📱в VK

О возвращеніи къ истокамъ: почему дореволюціонная орѳографія можетъ стать новымъ трендомъ въ IT

Или какъ перестать писать "плиз" и начать писать "извольте"

Привѣтствую, уважаемые обитатели Хабра!

Сидѣлъ я намедни за терминаломъ, читалъ коммиты, и вдругъ осѣнило меня: отчего это мы всѣ пишемъ "фиксы", "фичи" да "релизы", когда у насъ есть прекрасный русскій языкъ съ богатѣйшей исторіей? И рѣшилъ я возродить старую добрую традицію — писать по-русски, да не просто по-русски, а какъ писали наши прадѣды до революціи 1917 года.

Что же это за звѣрь такой — дореволюціонная орѳографія?

Для начала развѣю главный миѳъ: это не "языкъ Пушкина" и не "древнерусскій". Это вполнѣ себѣ обычный русскій языкъ, только съ болѣе сложными правилами правописанія, которыя отмѣнили большевики въ 1918 году "для упрощенія".

Основныя правила, которыя должен знать каждый уважающій себя разработчикъ:

1. Твердый знакъ (ъ) въ концѣ словъ Послѣ всѣхъ твердыхъ согласныхъ ставимъ ъ: кодъ, багъ, коммитъ, пулъ-реквестъ.

2. Буква ять (ѣ) Самое сложное — запомнить корни съ ятемъ. Вотъ основные для IT:

• дѣло (дѣлать, передѣлать)

• мѣсто (помѣстить, размѣстить)

• сѣть (сѣтевой протоколъ)

• имѣть (имѣется багъ)

3. I десятеричное (і) Передъ гласными пишемъ і: компиляція, интеграція, документація.

4. Окончанія -аго/-яго Стараго кода, новаго релиза, хорошаго программиста.

Почему сіе было отмѣнено?

Большевики заявили, что упрощаютъ правописаніе для народа. На дѣлѣ же:

• Уничтожили связь съ исторіей языка

• Разорвали преемственность съ дореволюціонной литературой

• Сдѣлали невозможнымъ чтеніе старыхъ книгъ безъ "перевода"

Практическое примѣненіе въ IT

Представьте commit message въ старомъ стилѣ:

Исправилъ досадный багъ въ обработкѣ данныхъ
- Передѣлалъ функцію парсинга
- Добавилъ провѣрку на нулевыя значенія
- Обновилъ тесты подъ новую логику

Или документацію:

## О методѣ getUserById()
Сей методъ служитъ для полученія пользователя по его идентификатору.
Возвращаетъ объектъ типа User или null, если пользователь не найденъ.

Какъ начать писать въ старомъ стилѣ?

1. Установите правильныя шрифты — нужны шрифты съ поддержкой ѣ, і, ѳ, ѵ

2. Настройте раскладку — есть готовыя рѣшенія для всѣхъ ОС

3. Изучите основныя правила — начните съ ъ и постепенно добавляйте остальное

4. Практикуйтесь — пишите комментаріи къ коду въ старомъ стилѣ

Почему это лучше американизмовъ?

• Уникальность — ваши тексты сразу выдѣляются

• Культурный кодъ — показываете связь съ исторіей

• Дисциплина ума — сложныя правила тренируютъ вниманіе къ деталямъ

• Эстетика — старыя тексты выглядятъ солиднѣе

Заключеніе

Дореволюціонная орѳографія — это не просто "модный трендъ", это возможность вернуть красоту и глубину русскому языку въ IT. Вмѣсто безликихъ "окей" и "сабмитовъ" мы можемъ писать "извольте" и "представляю на разсмотрѣніе".

Начните съ малаго — поставьте ъ въ концѣ своего ника. Напишите одинъ коммитъ въ старомъ стилѣ. Создайте README съ ятями. И увидите — за вами потянутся другіе.

Ибо, какъ говорили наши предки: "Безъ корней дерево не стоитъ".

P.S. Если статья понравилась, могу написать туторіалъ по настройкѣ vim для работы съ дореволюціонной орѳографіей.

Целевая аудиторія: Системные администраторы (бородатые хранители серверовъ и блюстители традицій)

Хабы:

1. Системное администрированіе (ибо кто какъ не админы цѣнятъ традиціи)

2. IT-стандарты (старая орѳографія — тоже стандартъ, только забытый)

3. Ненормальное программированіе (писать съ ятями — это вамъ не Hello World)

4. История IT (а что, развѣ языкъ — не часть исторіи?)

5. Читальный залъ (для любителей изящной словесности)

ByteDance выпустили нейросеть Dolphin, которая перегоняет pdf в классический формат документов, не превращая их в кучу непонятных символов:

• выходе получаете тот же документ, но в другом формате.

• cохраняются все подписи, изображения, графики и таблицы в оригинале.

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

• весить очень мало и не требует жесткой производительности.

Код на GitHub лежит — тут. Онлайн-демка — здесь.

Уязвимость в протоколе REALITY XTLS/Xray-core: быстрый фикс уязвимости Aparecium

На прошлой неделе была обнаружена уязвимость в известном ПО для создания прокси соединений XTLS/Xray-core, а именно в протоколе REALITY, позволяющая выявлять работу этого протокола.

Для тех, кто не в курсе: REALITY — это уникальный протокол прокси, который позволяет маскировать прокси-трафик под легитимное посещение реальных сайтов (например, google.com или любого другого), при этом не требуя покупки домена и настройки TLS-сертификата на своем сервере.

Обнаружение уязвимости

В начале июня 2025 года исследователь под ником ban6cat6 опубликовал утилиту под названием Aparecium. Ее цель — находить серверы, использующие протоколы вроде REALITY.

В чем была суть уязвимости?
Утилита обнаружила, что серверы на базе OpenSSL после завершения основного TLS-рукопожатия (handshake) обычно отправляют клиенту один или два служебных сообщения NewSessionTicket. Это стандартное поведение, позволяющее возобновлять сессии. Протокол REALITY в своей реализации это поведение не имитировал.

Это тонкое различие позволяло Aparecium с высокой точностью отличать настоящий веб-сервер от сервера с REALITY, просто проанализировав последовательность TLS-сообщений.

Быстрый фикс

Информация об уязвимости была опубликована в виде issue #4778 в репозитории Xray-core. Разработчики, в частности RPRX, отреагировали практически молниеносно.

Вместо того чтобы добавить отправку фейковых NewSessionTicket, они пошли по более правильному пути. Уже через несколько дней в версии Xray-core v25.6.8 появилось «предварительное» решение:

Теперь при первом запуске сервер REALITY, используя отпечаток клиента Chrome, сам подключается к целевому сайту (dest), «подсматривает», какие именно post-handshake сообщения и какой длины тот отправляет, кэширует эту информацию и в дальнейшем идеально имитирует именно это поведение.

На это «зондирование» уходит около 30 секунд при первом старте сервера, но оно по большей части решает основную проблему. Вместе с этим был исправлен и неприятный баг с производительностью из-за неработающего аппаратного ускорения AES-NI.

Глубокий анализ

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

1. Загадка «лишнего пакета» от bilibili.com
   Один из разработчиков заметил, что при подключении к некоторым сайтам (например, bilibili.com) с отпечатком Chrome, сервер возвращает не только NewSessionTicket, но и еще один небольшой пакет. После анализа выяснилось, что это не TLS-сообщение, а кадр настроек HTTP/2 (settings frame). Это значит, что для идеальной маскировки нужно имитировать не только TLS-уровень, но и поведение прикладного протокола (HTTP/2), который был согласован в ходе рукопожатия.

2. Проблема разных отпечатков (fingerprints)
   Выяснилось, что один и тот же сайт может по-разному отвечать на ClientHello от разных клиентов. Например, на запрос с отпечатком Chrome он может отправить два NewSessionTicket и settings фрейм, а на запрос от Go-клиента — только один NewSessionTicket. Похоже, что статического зондирования недостаточно.

3. Идея «живого обучения»
   В ходе мозгового штурма родилась идея для долгосрочного решения, которое было оформлено в issue #4788. Суть в том, чтобы сервер REALITY, получив ClientHello от нового клиента, не просто использовал стандартный отпечаток для зондирования, а копировал отпечаток реального клиента и именно с ним обращался к целевому сайту. Это позволит динамически адаптироваться под любого клиента и достичь практически идеальной мимикрии.

Разработчики рекомендуют всем обновить сервера и клиенты, использующие Xray-core, до версии 25.6.8.

ping: permission denied (are you root?)

Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?

Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.

Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.

Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.

Если вы опытный DevOps и знаете, как решается эта «детская проблема» при работе с оркестратором, регистрируйтесь на спринт-оффер для девопсов. Сможете буквально играючи получить новую работу за 3 дня.

Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки → 

Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника

Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.

Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.

Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.

Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.

Чек-лист: как настроить мониторинг, который предупредит сбой до его возникновения

Шаг 1. Составьте карту сервисов и зависимостей

• Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).

• Зачем: чтобы понять, как падение одного компонента влияет на систему.

«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».

Шаг 2. Разделите симптомы проблем: срочные vs важные

Срочные (реагировать немедленно!)

• БД: connections > 90%, replica lag > 10 сек.

• Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.

• Kubernetes: pod restarts > 5/час, node CPU > 95%.

Инструменты: Grafana OnCall, PagerDuty.

Важные (требуют анализа)

• Рост ошибок 4xx > 5% за сутки.

• Увеличение времени ответа API на > 20% за неделю.

• Падение успешных сессий (Google Analytics).

Решение: алерты в Slack/Email.

Шаг 3. Автоматизируйте рутину

Сбор логов: стек EFK (Elastic + Fluentd + Kibana).

Kubernetes:

• Liveness-пробы → авто-перезапуск пода при сбое.

• Readiness-пробы → остановка трафика на проблемный под.

Redis: настройка политик очистки кэша.

Совет для ленивых:

«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»

Шаг 4. Тестируйте устойчивость

Chaos Engineering раз в месяц:

• Отключайте случайные ноды в кластере.

• Эмулируйте нагрузку в 10 раз выше обычной (Locust).

«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».

Подключайтесь к вебинару про производительность 1С 🔍

Ровно через час, в 12:00 мск, встретимся, чтобы обсудить тест Гилева и другие методики тестирования 1С. Ответим на главные вопросы:

✔️ как выбрать подходящий метод,

✔️ как настроить тестовое окружение,

✔️ как проанализировать результаты и провести оптимизацию на основе полученных данных.

Вебинар будет полезен администраторам 1С и системным администраторам, руководителям IT-отделов, разработчикам, а также специалистам по производительности. 

Подключайтесь к трансляции:
➡️ в VK
➡️ на YouTube

На GitHub опубликовали новый инструмент для обнаружения протоколов маскировки TLS Он получил название Aparecium и способен выявлять ShadowTLS v3 и REALITY, которые маскируют зашифрованный трафик под легитимный TLS 1.3.

Aparecium использует особенности реализации TLS, чтобы обнаружить аномалии в поведении протоколов маскировки. ShadowTLS и REALITY, например, часто не обрабатывают отправляемые сервером сообщения NewSessionTicket должным образом, что позволяет выявить их использование.

Серверы на базе OpenSSL отправляют два сообщения NewSessionTicket одинаковой длины в одном TCP‑пакете, что также является характерной особенностью, отсутствующей в протоколах маскировки.

IMPulse - менеджмент инцидентов. Интеграция с Google Calendar, вложенные цепочки эскалации.

Предыдущие публикации:
https://habr.com/ru/articles/865208/
https://habr.com/ru/posts/889768/

Мы продолжаем развивать нашу систему менеджмента инцидентов. И рады представить интеграцию с Google Calendar, благодаря которой вы сможете гибко настраивать график дежурств и цепочки эскалации для этих дежурств.

Помимо интеграции с Google Calendar, мы реализовали вложенные цепочки эскалации. Теперь в chain можно добавить другой chain (nested), благодаря чему размер конфигурационного файла уменьшится.

Мы хотим создать достаточно гибкую, но не перегруженную систему цепочек эскалации, чтобы на проектах разной величины вы могли использовать IMPulse так как вам удобно. Для этого в комментариях расскажите, какой самый сложный кейс уведомлений / эскалации вам необходимо было реализовать. Например: во вторник нужно дёргать Антона, через 5 минут Олега, а по средам - только дёргать Геннадия, в остальное время, если severity == 'critical', звонить Грише.
Будем рады почитать самые сложные варианты и предложить наше универсальное решение для них.

Остаёмся на связи в нашем Telegram канале - там можно общаться / задавать вопросы.

Как защитить данные без полных бэкапов: разбираем косвенную адресацию в СХД

Мгновенный снимок (снапшот) — это компактная с точки зрения дискового пространства копия данных, созданная в определенный момент времени. Снапшот способен моментально зафиксировать состояние тома, в отличие от резервной копии, создание которой при большом объеме данных может занять длительное время и требовать остановки записи для сохранения консистентности. Снапшот же не создает независимую копию данных, а лишь обеспечивает возможность обратиться к данным тома на момент создания снапшота.

В TATLIN.UNIFIED снапшоты создаются путем копирования карты блоков данных оригинального тома. Сами данные не копируются, поэтому снапшоты создаются очень быстро и не занимают дополнительного места в области данных.

Со временем в родительском томе заполняются новые блоки данных. Некоторые данные у родительского тома и снапшота начинают различаться, но данные, на которые уже ссылается снапшот, не перезаписываются и не освобождаются. Оригинальный физический блок данных считается занятым до тех пор, пока снапшот, который на него ссылается, не будет удален. После удаления снапшота блоки данных, которые он не разделял с другими ресурсами, освобождаются и могут быть использованы для последующих операций записи. Такой вариант реализации снапшотов называют Redirect-On-Write (RoW).

В своей статье Алексей Шушарин, главный эксперт по разработке ПО в департаменте СХД YADRO, подробно рассказал о снапшотах, клонах и всех процессах, связанных с косвенной адресацией. А также о том, как грамотно вписать эту функциональность в стек хранилища.

Порадуем вас обновами в Kubernetes

А новостей собралось действительно много:

➖ Добавили в маркетплейс дополнений ArgoCD и cert-manager Webhook, который дружит с нашим API. С ними можно автоматизировать деплой приложений и упростить выпуск и обновление TLS-сертификатов в Kubernetes
➖ Открываем новые локации — теперь можно создавать кластеры и во Франкфурте
➖ Обновили публичную документацию API и добавили доки для части аддонов Kubernetes + описание всех новых параметров API
➖ Плюсик к карме и к безопасности — read-only режим для API-токенов, которые выпускаются автоматически при создании кластеров. Никаких случайных изменений или удалений

Забрать все обновы в Kubernetes себе →

Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

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

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Привет, развил тему пропихивания стручков (pod'ов) в кубернетис, добавил в меню выбора типа объектов команду apply. Теперь kui'ем можно приколачивать мYAMLики, создавая любые типы объектов. По умолчанию предлагает создать стручок:

Но с помощью кнопки edit можно изменить мямлик, изменения сохранятся в файл ~/.kyml.

С удивлением обнаружил что хаб Кодобред переименован в Говнокод О_о Чтож, так даже интереснее.

Творите, выдумывайте, пробуйте!)

Настройка бекапа вашей Linux системы с помощью rsync: просто и со вкусом

Шаг 1: Подготовка сервера для бэкапов

Лайфхак: В Hostkey VPS с 4ТБ обойдется примерно в 2600₽/месяц

Настройка SSH-ключа для безопасного доступа:

# Создаем SSH-ключ
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_backup

# Копируем на сервер
ssh-copy-id -i ~/.ssh/id_rsa_backup.pub user@backup-server

# Создаем директории на сервере
mkdir -p /root/backup-{1,2,3}

Шаг 2: Настройка автоматических бэкапов

Добавляем три задания в crontab для ротации бэкапов по дням недели:

crontab -e

Вставляем три задания (замените SSH_USER, SSH_HOST и SSH_KEY_PATH):

# Бэкап в директорию backup-1 (воскресенье, среда, суббота)
0 */2 * * 0,3,6 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-1 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

# Бэкап в директорию backup-2 (понедельник, четверг)
0 */2 * * 1,4 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-2 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

# Бэкап в директорию backup-3 (вторник, пятница)
0 */2 * * 2,5 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-3 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

Что делает наш скрипт?

• Умное расписание: Каждый день недели система копирует данные в одну из трех директорий

• Защита от блокировок: Предотвращает запуск нескольких копий скрипта одновременно

• Безопасность: Использует SSH-ключи вместо паролей

• Исключения: Пропускает системные директории, которые не нужно бэкапить

• Мониторинг: Отправляет уведомление в шторку уведомлений, если что-то пошло не так

ОБЯЗАТЕЛЬНО сохраните SSH-ключ в надежном месте! Без него восстановление данных будет невозможно.

Рекомендации:

• Копия на USB-флешке (хранить отдельно от компьютера)

• Распечатка на бумаге в сейфе (для параноиков)Зашифрованная копия в менеджере паролей

Проверка работоспособности

Регулярно проверяйте состояние ваших бэкапов:

ssh -i SSH_KEY_PATH SSH_USER@SSH_HOST "ls -la /root/backup-1"

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

Скрипт очистки логов всех баз MSSQL

Изначально статья была выложена на своём сервере https://ast-1c.kz/almasoft/?p=1443

Ничего сверхъестественного, но может кому пригодится:)

В процессе работы с сервером 1С, который в качестве сервера баз данных использует MSSQL сервер, очень часто приходится решать задачу по очистке логов базы. Сама по себе задача достаточно тривиальная и решается исполнением скрипта (при полной модели восстановления):

USE база_данных;  
GO  
-- Изменяем модель восстановления базы данных на SIMPLE.  
ALTER DATABASE база_данных
SET RECOVERY SIMPLE;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  
-- Возвращаем модель восстановления базы данных на FULL.  
ALTER DATABASE база_данных
SET RECOVERY FULL;  
GO

либо же для базы использующей простой тип модели восстановления:

USE база_данных;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  

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

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

Declare @name varchar(100)
declare @qu as varchar(1200)
declare icur cursor fast_forward for

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'FULL'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Set @qu=@qu + ' ALTER DATABASE [' + @name + ']  SET RECOVERY FULL'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'SIMPLE'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur
deallocate icur

DBCC SHRINKDATABASE (TEMPDB);

Скачать готовый на GitHub Gist

Привет, приспичило создать тестовый стручек (pod), проверить кое-что. Создал и добавил это в kui, в секцию "быстрых" команд:

Тестовый стручек создается вот такой командой:

kube run $quick_pod_name $ns --image=$quick_pod_image --command -- $quick_pod_command 2>&1

Для изменения названия, образа или команды стручка подредактируйте вот эти переменные в начале скрипта:

quick_pod_name=busytest          # Pod name for simple test pod
quick_pod_image=busybox:1.32     # Pod image for simple test pod
quick_pod_command="sleep 3600"   # Pod command for simple test pod

Творите, выдумывайте, пробуйте!)

Приглашаем на вебинар, посвященный последним обновлениям IVA MCU — ведущей платформы видеоконференцсвязи на российском рынке*

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

Спикеры

• Дмитрий Журавлев, директор по продукту IVA MCU

• Дмитрий Чугунов, руководитель управления поддержки продаж

Что вас ждет

• Обзор ключевых функций новой версии IVA MCU

• Экскурс: как мы обеспечиваем безопасность платформы

• Примеры успешного внедрения

• Дорожная карта развития на 2025 год

• Ответы на вопросы

Зарегистрироваться прямо сейчас.

 _{*По данным CNews Analytics: Крупнейшие поставщики решений для видеоконференцсвязи 2023.}