Всплывающие предупреждения в Mikrotik

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

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

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

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

При этом мало кто знает об одном простом, но удобном инструменте Mikrotik – заметках. Найти их можно в System – Note. Вы можете написать туда все, что угодно и этот текст будет отображаться при каждом новом входе в систему.

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

Что такое запись DNS CAA (Certificate Authority Authorization) и зачем она нужна
 
DNS CAA  - это ресурсная запись DNS, которая позволяет владельцу домена явно указать, какие удостоверяющие центры (CA) имеют право выпускать TLS-сертификаты для этого домена и его поддоменов.
 
Это важная часть инфраструктуры безопасности, предупреждающая несанкционированный выпуск сертификатов третьей стороной.
 
Позвольте, но чем это отличается от проверки владения? Сегодня, перед выпуском сертификата любой удостоверяющий центр попытается выполнить проверку владения доменом: через HTTP-файл, DNS-запись или email.
 
Но как быть, если ваша инфраструктура оказалась скомпрометированной? Или трафик был перехвачен и подменен на этапе проверки? В этом случае злоумышленник может выпустить сертификат в стороннем CA и спокойно использовать его для MiTM или фишинга.
 
Да, есть Certificate Transparency, но это уже постреагирование и не все мониторят эти журналы. Поэтому был разработан способ проактивной защиты, а именно DNS CAA. С сентября 2017 года проверка CAA-записей является строго обязательной для всех публичных CA согласно требованиям CA/Browser Forum.
 
Таким образом вы можете указать кто именно имеет право выпускать сертификаты для вашего домена и таким образом сузить поверхность возможной атаки. Теперь ни один публичный CA не выпустит сертификат без вашего разрешения.
 
👉 Общий формат записи выглядит как:
 

example.com. IN CAA <флаг> <тег> "<значение>"

 
🔹 Флаг (Flag) Принимает значение от 0 до 255, но на практике сейчас активно используются только два:

▫️0 (Non-critical): Если CA не понимает или не поддерживает встреченный тег в записи, он может проигнорировать его и продолжить выпуск сертификата.

▫️128 (Critical): Если CA встречает незнакомый тег в записи с этим флагом, он обязан отказать в выпуске сертификата.

🔹 Тег (Tag) Определяет поведение и тип разрешения. Существует три стандартных тега:

▫️ issue: Разрешает указанному CA выпускать любые типы сертификатов (как обычные, так и wildcard) для данного домена.

▫️issuewild: Разрешает выпуск только wildcard-сертификатов (*.example.com). Если этот тег задан, то для wildcard-запросов правила из issue игнорируются.

▫️ iodef (Incident Object Description Exchange Format): Указывает URL (обычно mailto: или http/https), куда CA должен отправить отчет, если кто-то попытается запросить сертификат в обход правил CAA.

🔹 Значение (Value) Строка в кавычках, содержащая доменное имя разрешенного CA (например, "letsencrypt.org", "digicert.com") или параметры для iodef.
 
👉 Несколько примеров:
 
Разрешаем выпускать сертификаты только для Let's Encrypt, а в случае нарушений — слать отчеты на почту:
 

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

 
Разрешаем DigiCert выпускать только обычные сертификаты, а Let's Encrypt — только wildcard:
 

example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"

 
Отдельная возможность – это полный запрет выпуска сертификатов для домена, например, это служебный или временно не используемый домен и выдача сертификатов дня него не предусматривается:
 

example.com. IN CAA 0 issue ";"

 
👆 Записи CAA мы можем создать как для домена, так и для любого поддомена, проверка идет по снизу вверх по дереву DNS. Если CA проверяет поддомен sub.dev.example.com, поиск записей происходит по следующей цепочке до первого совпадения:
 
🔸 Выполняется поиск CAA для sub.dev.example.com.
🔸 Если записей нет, проверяется dev.example.com.
🔸 Если снова пусто, проверяется корневой example.com.
 
Если на корневом домене example.com установлена запись CAA, она автоматически распространяется на все поддомены, если для конкретного поддомена не создана своя, переопределяющая запись CAA.
 
Исключение – записи CNAME, если для них не установлена CAA запись, то проверка по дереву прекращается и начинается проверка дерева домена на который указывает такая запись.

Watchtower – управляем обновлением контейнеров в Docker

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

Можно, конечно, делать это руками, но зачем, когда можно автоматизировать этот процесс. Для этого мы будем использовать Watchtower – простой и удобный инструмент, который будет отслеживать состояние ваших контейнеров и обновлять их по мере выхода новых версий.

Для его использования вам потребуется еще один небольшой контейнер, который можно развернуть при помощи следующего docker-compose.yml:

services:
  watchtower:
    image: nickfedor/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_REMOVE_VOLUMES=true
      - WATCHTOWER_POLL_INTERVAL=86400
      - DOCKER_API_VERSION=1.40
      - WATCHTOWER_LABEL_ENABLE=true
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Коротко пробежимся по некоторым опциям:

🔹 WATCHTOWER_CLEANUP - удаляет старые образы после обновления

🔹 WATCHTOWER_REMOVE_VOLUMES - удаляет старые анонимные тома

🔹 WATCHTOWER_POLL_INTERVAL - интервал проверки обновлений, в нашем случае - сутки

Перед включением этих опций, особенно второй, убедитесь, что вы понимаете что делаете.

Но обновлять все подряд без разбора – плохая идея. Поэтому мы рекомендуем в продуктивных средах использовать включенным параметр:

🔹 WATCHTOWER_LABEL_ENABLE – включает режим обновления по меткам

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

labels:
- "com.centurylinklabs.watchtower.enable=true"

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

Кстати, для них есть другая полезная метка:

labels:
- "com.centurylinklabs.watchtower.enable=false"

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

WATCHTOWER_LABEL_ENABLE=false

В этом случае автоматически обновляются все контейнеры, кроме имеющих метку enable=false, что служит надежным предохранителем от нештатной ситуации.

Обратная сторона открытого кода
 
Убежденные адепты открытого кода одним из несомненных преимуществ данного подхода ставили неутомимое комьюнити: тысячи рук, тысячи глаз, которые должны были оперативно отыскивать ошибки и уязвимости и устранять их.
 
Но, как известно, человек – существо ленивое и пока гром не грянет, мужик не перекрестится. Вот как-то так оно и вышло. Жили в своем уютном мирке и не тужили…
 
А тут как снег на голову… Действительно неутомимые тысячи рук и тысячи глаз… В лице искусственного интеллекта… И понеслось…
 
Совсем недавно мы писали о том, как ИИ нашел древнюю уязвимость в ядре: https://t.me/interface31/6086
 
Но ладно бы одну! Свежие новости заставляют вздрогнуть, количество уязвимостей позволяющих локально поднять права до суперпользователя за счет изменения страничного кеша плодятся со страшной силой:
 
1️⃣ Copy Fail - CVE-2026-31431

2️⃣ Dirty Frag - CVE-2026-43284

3️⃣ Dirty Frag - CVE-2026-43500

4️⃣ Fragnesia - CVE-2026-46300

5️⃣ PinTheft -  CVE-идентификатор не присвоен

6️⃣ DirtyDecrypt -  CVE-идентификатор не присвоен
 
При этом для каждой из них уже есть эксплойт или прототип.
 
В целом нет ничего удивительного, в любом проекте с большим сроком жизни есть легаси-код, есть технический долг и много других скучных и неприятных вещей, которые обычно проходят по классу: работает – не трогай.
 
И вот появился тот, кто может взять и потрогать, причем потрогать внимательно и вдумчиво. Со всеми вытекающими. Ну а как иначе, технический долг тоже нужно когда-то отдавать.
 
Только теперь это приходится делать в режиме загнанной лошади. Но даже это лучше, чем если бы эти уязвимости рано или поздно кто-то начал бы использовать по-тихому, без большой огласки.
 
А ИИ в очередной раз показал, что рынок ПО стремительно меняется и программирование уже никогда не будет прежним, старые подходы стремительно устаревают и становятся неэффективными.
 
Новые еще не выработаны. Отрасль, по сути, находится на распутье и сегодня важно не проспать новые тенденции, чтобы остаться в обойме и не оказаться за бортом. Так как изменится не только рынок программирования, но и все смежные отрасли так или иначе изменятся.
 
И этот процесс уже идет. Кто-то уже начал осваивать новые инструменты, кто-то только приглядывается, а кто-то пытается прятать голову в песок. Но отсидеться ни у кого не получится. Эпоха перемен началась и затронет она так или иначе каждого.

DoT и DoH - в чем разница?

🔹 DNS-over-TLS (DoT) - специальная реализация протокола DNS c TLS защитой. Согласно стандарта для этой службы выделен отдельный порт 853. Технически это инкапсуляция стандартных DNS-запросов в TLS.

🟢 Из плюсов - лучшая управляемость, так как благодаря отдельному порту системные администраторы могут контролировать использование этого протокола.

Еще один плюс - хорошая обратная совместимость, не нужно переписывать софт, так как используются стандартные запросы, нужно только реализовать поддержку TLS.

🔴 Из минусов - обратная сторона плюсов, DoT трафик легко перехватить и заблокировать (но не расшифровать).

🔹 DNS-over-HTTPS (DoH) - принципиально иная реализация защиты DNS, когда поставлена цель сделать DNS-запросы неотличимыми от обычного HTTPS-трафика.

В DoH для передачи DNS-запросов используется протокол HTTP/2 и по сути это некое веб API для передачи DNS данных. Поэтому отличить DoH от обычного HTTPS трафика решительно невозможно.

🟢 Из плюсов - невозможно отличить от HTTPS трафика и осуществлять выборочный перехват и блокировку DNS-запросов

🔴 Из минусов - серьезные затруднения для системных администраторов, которые не могут выделять и контролировать DNS-запросы пользователей.

Второй минус - необходимость серьезной доработки софта, так как вместо стандартных запросов требуется реализовать поддержку работы с HTTP/2

Никогда такого не было и вот опять!

Добрый вечер, с вами снова ваша любимая рубрика: как все завалить и ничего не понять.

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

Спрашиваем, читал ли логи? Вроде читал, вроде никакого криминала, нет, ИИ не давал почитать. Ну да ладно, просим эти самые логи прислать.

Ну а там просто классика жанра, причем эталонная, хоть в палату мер и весов отправляй. В общем история проста и поучительна. А также очень типична.

Мы не даром в заметке заострили внимание на то, что без меток Watchtower использовать в продуктивных средах крайне нежелательно, но кого и когда это останавливало?

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

Хотя еще Чехов заметил, что если в пьесе на стене висит ружье, то оно должно обязательно выстрелить. Так и произошло в этот раз. Домашния лаба, руками давно не обновлялась, некогда, да и лень.

А тут заметка про Watchtower – эврика, это то, что нам надо. Быстренько разворачиваем, все лишнее выкидываем и предвкушаем радость от полной автоматизации процесса, ну какие еще метки, зачем, будь проще и люди к тебе потянутся.

И что же тут могло пойти не так? Читаем лог. Watchtower запустился и нашел обновления абсолютно ко всем контейнерам домашней лаборатории, что не удивительно. Но так совпало, что установленный вчера образ nickfedor/watchtower:latest сегодня тоже обновился.

А затем он старательно остановил все контейнеры и перезапустился сам. При этом весь контекст задач оказался потерян и контейнеры остались остановленными.

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

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

Но в любом случае это опыт, а за одного битого, как известно, двух небитых дают.

Настраиваем цвета строки приглашения Bash

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

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

За формат строки приглашения отвечает переменная окружения PS1 и по умолчанию она имеет значение:

PS1='\u@\h:\w\$ '

Где u – имя пользователя, h – имя хоста, w – текущий путь, а $ - символ приглашения.

В результате строка будет выглядеть так:

user@host:/home/user$

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

Формат может принимать три значения:

▫️Нормальный текст – 0
▫️Жирный текст – 1
▫️Подчеркнутый текст – 4

Цвета текста / фона:

▫️Черный 30/40
▫️Красный 31/41
▫️Зеленый 32/42
▫️Желтый 33/43
▫️Голубой 34/44
▫️Фиолетовый 35/45
▫️Бирюзовый 36/46
▫️Белый 37/47

Для того чтобы задать цвет отдельных элементов применяется специальное форматирование, использующее символы \e в начале и m в конце.

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

PS1='\[\e[01;32m\]\u@\h\[\e[m\]:\[\e[01;34m\]\w\[\e[m\]\$ '

Сам цвет задает конструкция:

\[\e[01;32m\] 

Формат текста задает 01, а его цвет – 32, т.е. жирный зеленый. Если мы хотим еще изменить фон, то добавляем туда еще одно значение:

\[\e[01;32;43m\] 

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

Конструкция

\[\e[m\]

Сбрасывает цвет и формат элементов на дефолтные.

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

PS1='\[\e[01;32m\]\u@\h:\[\e[01;34m\]\w\[\e[m\]\$ '

Проверить что получилось можно сразу, введя указанную строку в консоль и нажав Enter. Таким образом можно тонко настроить цвета в соответствии со своими потребностями.

Если же вы люто накосячили, то не отчаивайтесь, введите

PS1='\u@\h:\w\$ '

И все снова станет как было. Либо просто выйдите из консоли.

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

Настраиваем DNS-резольвер Unbound для работы с DNS over TLS

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

Поэтому современный DNS также требует TLS-защиты, наиболее просто и прозрачно для администратора использовать DNS over TLS (DoT). Да, эта технология не маскирует себя под HTTPS-трафик, но в большинстве случаев это и не нужно.

Для реализации нашей задумки мы будем использовать популярный DNS-резольвер Unbound, который присутствует в репозиториях всех основных дистрибутивов Linux.

Установить его можно командой:

apt install unbound

Затем откроем основной конфигурационный файл /etc/unbound/unbound.conf и приведем его к следующему виду:

include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

server:
    use-syslog: yes
    username: "unbound"
    directory: "/etc/unbound"
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    verbosity: 2

    do-ip6: no
    interface: 192.168.100.53
    port: 53
    prefetch: yes

    root-hints: /usr/share/dns/root.hints
    harden-dnssec-stripped: yes

    cache-max-ttl: 86400
    cache-min-ttl: 900

    aggressive-nsec: yes
    hide-identity: yes
    hide-version: yes
    use-caps-for-id: yes

    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8

    #control which clients are allowed to make (recursive) queries
    access-control: 127.0.0.1/32 allow_snoop
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.100.0/24 allow  

    num-threads: 4
    msg-cache-slabs: 8
    rrset-cache-slabs: 8
    infra-cache-slabs: 8
    key-cache-slabs: 8
    rrset-cache-size: 256m
    msg-cache-size: 128m
    so-rcvbuf: 8m

forward-zone:
    name: "."
    forward-ssl-upstream: yes
    forward-addr: 1.1.1.1@853#one.one.one.one
    forward-addr: 1.0.0.1@853#one.one.one.one

forward-zone:
    name: "nalog.ru."
    forward-ssl-upstream: yes
    forward-addr: 77.88.8.8@853#common.dot.dns.yandex.net

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

Мы же разберем настройки непосредственно DoT. Так как Unbound не DNS-сервер, а именно резольвер, то он на все запросы либо отдает данные из кеша, либо запрашивает их у вышестоящих серверов.

Где именно это делать мы указываем в секциях forward-zone, таких секций может быть несколько и тогда Unbound ищет среди низ наиболее точное совпадение.

В нашем примере таких секций две: "." и "nalog.ru." – обратите внимание, что имена зон всегда должны заканчиваться на точку, точка обозначает корень системы DNS.

И именно поэтому в одном из имен зон пересылки у нас стоит точка, это обозначает, что сюда следует посылать все DNS-запросы, которым не нашлось иного совпадения. Вторая зона у на нас отвечает за домен nalog.ru.

В нашем примере для nalog.ru мы используем сервера Яндекс.DNS, для всех остальных запросов будут использоваться Cloudflare DNS.

Опция forward-ssl-upstream: yes включает DoT для указанных зон, ниже перечисляются сервера, к которым следует делать запросы. В записи мы указываем адрес и порт, по умолчанию это 853.

А вот запись после # - это не комментарий, это доменное имя, на которое выписан сертификат сервера. Что позволяет выполнить проверку сертификата на стороне клиента. Даже если кто-то перехватит наш трафик и направит на поддельный DoT-сервер, он не сможет предъявить клиенту валидный сертификат.

Данная часть записи не является обязательной, но крайне желательна, так как защищает от подмены сервера и атак класса MitM. Нужные имена доменов вы можете узнать в документации вашего DNS-провайдера.

Некоторые мысли по поводу организации DNS-трафика в сетях с Mikrotik

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

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

Ой, да что там думать, скажет иной читатель, включаем DoH и понеслась! Но не все так просто. При включении DoH перестают работать записи типа FWD, что во многих случаях неприемлемо, поэтому нужно искать другое решение.

Завернуть DNS-запросы в трубу… Ну такое себе решение, скажем честно. Труба в наше время может отвалиться в любой момент, и тогда вся ваша сеть вообще окажется без DNS.

Поэтому работать надо через основное подключение, но исключительно по защищенным протоколам.

Сегодня в домашней сети был опробован данный вариант и результат его можно считать отличным.

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

Для разрешения запросов мы подняли дополнительный кеширующий DNS-сервер Unbound, но вы можете использовать любое иное решение, главное, чтобы оно умело использовать в качестве апстрима сервера DoT/DoH.

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

Почему DoT, а не DoH? DoT проще в настройке и позволяет четко определять такой трафик, что полезно если вы используете сложные правила фильтрации. С другой стороны, это делает видимым такой трафик для провайдера, но доступа к нему он все равно не имеет.

Смысла прятать факт наличия DNS-трафика в зашифрованном виде особо нет, но если вы хотите скрыть такую активность, то лучше использовать DoH. В общем – на ваш выбор.

После чего в качестве используемого DNS-сервера для Mikrotik указываем адрес нашего Unbound. Для клиентов сети основным DNS как был Mikrotik, так и остался, это нужно для того, чтобы работали FWD записи и разные другие правила.

Этот режим показан на диаграмме зелеными стрелочками. DNS-запрос приходит на Mikrotik и если его не нужно перенаправлять на какой-либо специфический сервер, то он уходит на Unbound, а с него по DoT/DoH на выбранный вышестоящий DNS-сервер.

А что будет, если клиент явно укажет на своем устройстве другие DNS-сервера? Все просто, решаем при помощи правила на Mikrotik:

/ip firewall nat
add action=dst-nat chain=dstnat comment="SAFE DNS" dst-address=!192.168.1.0/24 dst-port=53 protocol=udp to-addresses=192.168.1.53

Где 192.168.1.0/24 – адрес вашей внутренней сети, а 192.168.1.53 – адрес сервера Unbound.

После чего ваш роутер будет перехватывать все транзитные DNS-запросы и отправлять их на ваш Unbound-сервер. Этот режим показан на схеме голубыми стрелочками.

Также для контроля возможной утечки DNS советуем вам на первых порах добавить в брандмауэр, на самый верх, еще два правила:

/ip firewall filter
add action=passthrough chain=output dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp
add action=passthrough chain=forward dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp

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

Сразу дадим одну наколку, если у вас используются коммутируемые подключения или вы получаете настройки по DHCP – обязательно снимите галочку Use Peer DNS.

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

А можно мы сами?

- А у нас тут 1С не запускается, пишет недостаточно места…

- Значит недостаточно места, надо почистить.

- А если вы подключитесь, то возьмете как за час работы?

- Да, это минимальная такса.

- Но там же просто место почистить.

- Да какая разница, мы тратим свое время. Время – деньги.

- А можно мы сами почистим?

- Можно.

На следующий день сообщают, что они почистили, место есть, но теперь 1С вообще не запускается. 😫

Наверное, вы уже догадались, они удалили самую большую папку в корне диска, с простым и понятным названием «СТ», в которой была база 1С. 🤦‍♀️

Сэкономили денег, однако.

Последний бекап от марта месяца. Но документов немного, дня за два-три в пару рук внесут все обратно.

Морали не будет. Каждый сам определяет, что дорого, а что нет. И несет последствия своего выбора.

Не спеши, а то успеешь

В начале нашей заметки я расскажу одну поучительную историю. В студенческие годы физрук подрядил нас почистить от снега спортплощадку. Срок – пара. Ну мы минут за 30 справились, пришли к нему гордые и довольные.

А он отправил нас… обратно снег по спортплощадке разбрасывать. Ну бывший военный, что с него взять. Но, оказалось, в этом действе был заложен глубокий смысл. Который он нам наглядно продемонстрировал.

Любые нормы на чем-то да основаны, проверены временем и т.д. и т.п. Сказали чистить снег пару – значит пару. Это сегодня снега пару сантиметров выпало, и вы за полчаса справились, а завтра его по колено наметет? А норма – штука такая, если ее регулярно перевыполнять, то ее обязательно поднимут (или сократят) и легче никому от этого не станет.

Это правило я тогда запомнил, и оно сильно помогает по жизни. Вот есть работа, которая по нормам занимает два часа, а вы набили руку и делаете ее за час. Не спешите никого радовать. Два часа и точка!

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

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

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

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

Не спешите сдавать этот этап, оставьте эти два дня себе, есть возможность – начните работу над следующим этапом или просто подготовьтесь к нему, что делать – всегда найдется. Но у вас будет запас времени.

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

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

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

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

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

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

Для себя я давно вывел некоторые эмпирические коэффициенты, любые материалы на проекте умножаем на 1,25, а время просто увеличиваем в полтора, а то и два раза. Запас карман не тянет, особенно если это такой ресурс, как время.

Новый формат DEB822 для источников APT

Так уж пошло, что многие привычные вещи воспринимаются нами чем-то незыблемым, а попытка нарушить текущий ход вещей часто воспринимается в штыки. Новый формат источников APT - DEB822 не исключение, он появился начиная с выпуска Debian 13, а пользователи Ubuntu познакомились с ним немного раньше, начиная с Ubuntu 24.04. В данной статье мы подробно разберем новый формат, его основные отличия и преимущества перед привычным старым.

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

Статья серьезно расширена и дополнена, кроме подробного разбора опций в ней есть новые разделы, которых не было в заметке.

✅ Читать: https://interface31.ru/post/novyj-format-deb822-dlya-istochnikov-apt/