Записки IT специалиста

Не спеши, а то успеешь В начале нашей заметки я расскажу одну поучительную историю. В студенческие годы физрук подрядил нас почистить от снега спортплощадку. Срок – пара. Ну мы минут за 30 справились, пришли к нему гордые и довольные. А он отправил нас… обратно снег по спортплощадке разбрасывать. Ну бывший военный, что с него взять. Но, оказалось, в этом действе был заложен глубокий смысл. Который он нам наглядно продемонстрировал. Любые нормы на чем-то да основаны, проверены временем и т.д. и т.п. Сказали чистить снег пару – значит пару. Это сегодня снега пару сантиметров выпало, и вы за полчаса справились, а завтра его по колено наметет? А норма – штука такая, если ее регулярно перевыполнять, то ее обязательно поднимут (или сократят) и легче никому от этого не станет. Это правило я тогда запомнил, и оно сильно помогает по жизни. Вот есть работа, которая по нормам занимает два часа, а вы набили руку и делаете ее за час. Не спешите никого радовать. Два часа и точка! Иначе через некоторое время нормой у вас будет именно час и если что-то вдруг пойдет не так, то запаса по времени у вас не будет и никто даже слушать не захочет про два часа, потому что это было давно и неправда, а не справились вы сейчас. Ну ладно, это заказчик внутренний, а внешнему можно и сдать пораньше, получить денег и радоваться жизни. Оно, конечно, можно, но при условии, что вы этого заказчика видите первый и последний раз. Иначе он тоже запомнит, что эта работа занимает час и будет на этот час рассчитывать, а когда вы не справитесь, то будет недоволен и деньги вам заплатит не очень охотно. Ведь вы плохо работаете, не справляетесь. Еще хуже, если это проект с большим количеством этапов. На проекте самой большой ценностью является время. И если у вас указано, что данный этап занимает неделю – занимайтесь неделю, даже если справились за три дня. Не спешите сдавать этот этап, оставьте эти два дня себе, есть возможность – начните работу над следующим этапом или просто подготовьтесь к нему, что делать – всегда найдется. Но у вас будет запас времени. Сдали этап – такого запаса нет, приступайте к следующему. И далеко не факт, что, быстро взяв старт вы не упадете лицом в асфальт, потому что забыли завязать шнурки. На любом проекте, как его не прорабатывай, всегда что-то да всплывет и запас по времени тут будет настоящим спасательным кругом. Но даже если вы успешно «выполнили пятилетку за три года» ничего хорошего из этого не выйдет. Потому что заказчик поймет, что вы можете работать быстрее, а также то, что вы не умеете ставить и выдерживать сроки. А это значит, что можно на эту тему вас прогнуть и на следующий проект установить сроки самостоятельно. Итог – вы в цейтноте и бегаете в мыле по потолку, чтобы успеть выполнить все работы. Оно вам надо? На недостаток времени жалуются многие коллеги, но если копнуть поглубже и провести разбор полетов, то выясняется, что в эту ситуацию они загнали себя сами. Любую норму или план можно перевыполнить только один раз, в этом случае вас похвалят и дадут конфетку, второй раз вас просто одобрительно похлопают по плечу, а на третий сделают замечание, что плохо работаете, недорабатываете. Для себя я давно вывел некоторые эмпирические коэффициенты, любые материалы на проекте умножаем на 1,25, а время просто увеличиваем в полтора, а то и два раза. Запас карман не тянет, особенно если это такой ресурс, как время.

Облачный Сервис Деск — система управления поддержкой Представляем отечественный ИТ-продукт для компаний среднего и малого бизнеса - облачный Сервис Деск от платформы «Сфера»! Он позволяет удобно и эффективно управлять обращениями, запросами на обслуживание, инцидентами, услугами. Незаменимое решение для техподдержки. Преимущества Сфера Сервис Деск ✅Быстрое внедрение. ✅Безопасность данных. ✅Автоматические обновления. ✅Надежность и поддержка. ✨Оставьте заявку и получите возможность попробовать продукт бесплатно! Получить предложение #реклама 16+ sferaplatform.ru О рекламодателе

А можно мы сами? - А у нас тут 1С не запускается, пишет недостаточно места… - Значит недостаточно места, надо почистить. - А если вы подключитесь, то возьмете как за час работы? - Да, это минимальная такса. - Но там же просто место почистить. - Да какая разница, мы тратим свое время. Время – деньги. - А можно мы сами почистим? - Можно. На следующий день сообщают, что они почистили, место есть, но теперь 1С вообще не запускается. 😫 Наверное, вы уже догадались, они удалили самую большую папку в корне диска, с простым и понятным названием «СТ», в которой была база 1С. 🤦‍♀️ Сэкономили денег, однако. Последний бекап от марта месяца. Но документов немного, дня за два-три в пару рук внесут все обратно. Морали не будет. Каждый сам определяет, что дорого, а что нет. И несет последствия своего выбора.

Технологии, данные и инструменты для дилеров Без лишнего шума и сложных решений🚗 Подписаться #реклама О рекламодателе

Некоторые мысли по поводу организации 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 запросы более за пределы локальной сети не уходят.

Открытый воркшоп: учитесь созданию игровых механик для брендов На реальных кейсах разберёте, как игровые сценарии помогают бизнесу работать с вовлечением и удержанием аудитории. Узнаете о механиках и принципах, которые используют в проектах для Qiwi, Самоката, Okko, Ozon и других брендов. Что вас ждёт: ☑️ разбор реальных проектов ☑️ создание собственной механики ☑️ обратная связь от практикующего геймификатора Воркшоп проведёт практикующий геймификатор и автор более 30 проектов для российских брендов, Дмитрий Джаман. 28 мая | 19:00 | Онлайн в Zoom Зарегистрироваться #реклама О рекламодателе

Настраиваем 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: 192.168.3.0/24
    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.3.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-провайдера.

14 онлайн-курсов по Python с фокусом на практике Python по-прежнему остаётся одним из самых востребованных и в обучении, и в работе. Он подходит для самых разных задач: от аналитики до автоматизации и разработки сервисов. Если хотите системно углубиться в Python или попробовать новое направление, можно начать с любого из них. Переходите в наш канал Stepik, где мы делимся курсами от авторов-практиков, а также полезными материалами на актуальные темы. Подписаться #реклама 16+ О рекламодателе

Настраиваем цвета строки приглашения 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 выбранного пользователя.

Яндекс Музыка до 360 дней бесплатно Яндекс Музыка для вас и 3-х ваших близких. Кинопоиск и Яндекс Книги тоже в подписке. Попробуйте бесплатно❤️ Слушать #реклама 18+ music.yandex.ru О рекламодателе

Никогда такого не было и вот опять! Добрый вечер, с вами снова ваша любимая рубрика: как все завалить и ничего не понять. Не успели мы опубликовать заметку о Watchtower, как сегодня вечером нам написал один коллега и заявил, что это все полная фигня и Watchtower только что положит ему всю домашнюю лабу, ну может и не Watchtower, но как-то подозрительно совпало. Спрашиваем, читал ли логи? Вроде читал, вроде никакого криминала, нет, ИИ не давал почитать. Ну да ладно, просим эти самые логи прислать. Ну а там просто классика жанра, причем эталонная, хоть в палату мер и весов отправляй. В общем история проста и поучительна. А также очень типична. Мы не даром в заметке заострили внимание на то, что без меток Watchtower использовать в продуктивных средах крайне нежелательно, но кого и когда это останавливало? Мотивация обычно проста, мол сколько тех у меня контейнеров, ничего особо важного, пусть обновляет, разберемся. Хотя и важное никого особо не останавливает, мол чему там ломаться и т.д. и т.п. Хотя еще Чехов заметил, что если в пьесе на стене висит ружье, то оно должно обязательно выстрелить. Так и произошло в этот раз. Домашния лаба, руками давно не обновлялась, некогда, да и лень. А тут заметка про Watchtower – эврика, это то, что нам надо. Быстренько разворачиваем, все лишнее выкидываем и предвкушаем радость от полной автоматизации процесса, ну какие еще метки, зачем, будь проще и люди к тебе потянутся. И что же тут могло пойти не так? Читаем лог. Watchtower запустился и нашел обновления абсолютно ко всем контейнерам домашней лаборатории, что не удивительно. Но так совпало, что установленный вчера образ nickfedor/watchtower:latest сегодня тоже обновился. А затем он старательно остановил все контейнеры и перезапустился сам. При этом весь контекст задач оказался потерян и контейнеры остались остановленными. Ситуация на самом деле довольно редкая, но коллеге повезло выбить комбо. А это еще раз напоминает, что мелочей в деле системного администрирования нет и быть не может. Всегда держите в голове самый негативный сценарий и заранее подстелите, где это возможно соломки. В данном случае указанной ситуации не произошло бы, если бы коллега использовал метки и обновлял бы только то, что нужно. Либо добавил бы контейнеру с Watchtower метку, запрещающую автоматическое обновление. Но в любом случае это опыт, а за одного битого, как известно, двух небитых дают.

Команда из 5 ИИ-агентов, которые забирают рутину Эти 5 агентов работают 24/7 и снимают с вас повторяющиеся задачи. Собирается без единой строчки кода — просто описываете свои задачи: — Агент для почты отвечает на письма в вашем стиле (Fyxer AI или Lindy) — Исследователь собирает инфу о конкурентах (Perplexity или Manus) — Календарь сам назначает и переносит встречи (Reclaim AI или Motion) — Контент-агент пишет посты в вашем стиле (Taplio или Buffer AI) — Агент для личных сообщений общается с клиентами, пока вы спите (ManyChat или Lindy) Если хочется собрать всех агентов на одной платформе — Lindy или MindStudio делают все 5 типов. Подробное сравнение но-код платформ тут. Чтобы не упускать появление таких инструментов, подписывайся на @A1intelligence!

Следи за новостями мира искусттвенного интеллекта - полезные инструменты, апдейты моделей и полезные гайды.

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

RYBE — одежда с твоим языком программирования. Где два айтишника могут познакомиться? В офисе и на конференции. Нам этого мало. Мы захотели объединить людей, у которых одни интересы. Дать возможность узнать друг друга. В метро, на прогулке, в офисе, на конференции, в походе, в баре, в самолёте. В каком-то смысле это мерч для твоего языка программирования. А что еще? - отшиваемся в Москве; - плотный премиум-хлопок; - фичи: люверсы для крепления пропуска, карман для наушников и салфетка для очков внутри кармана Выбирай свой язык, заказывай, дари, носи сам: https://tglink.io/a0069bd1db713a?erid=2W5zFHq5J9o Наш tg: @rybe_store

Обратная сторона открытого кода   Убежденные адепты открытого кода одним из несомненных преимуществ данного подхода ставили неутомимое комьюнити: тысячи рук, тысячи глаз, которые должны были оперативно отыскивать ошибки и уязвимости и устранять их.   Но, как известно, человек – существо ленивое и пока гром не грянет, мужик не перекрестится. Вот как-то так оно и вышло. Жили в своем уютном мирке и не тужили…   А тут как снег на голову… Действительно неутомимые тысячи рук и тысячи глаз… В лице искусственного интеллекта… И понеслось…   Совсем недавно мы писали о том, как ИИ нашел древнюю уязвимость в ядре: 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-идентификатор не присвоен   При этом для каждой из них уже есть эксплойт или прототип.   В целом нет ничего удивительного, в любом проекте с большим сроком жизни есть легаси-код, есть технический долг и много других скучных и неприятных вещей, которые обычно проходят по классу: работает – не трогай.   И вот появился тот, кто может взять и потрогать, причем потрогать внимательно и вдумчиво. Со всеми вытекающими. Ну а как иначе, технический долг тоже нужно когда-то отдавать.   Только теперь это приходится делать в режиме загнанной лошади. Но даже это лучше, чем если бы эти уязвимости рано или поздно кто-то начал бы использовать по-тихому, без большой огласки.   А ИИ в очередной раз показал, что рынок ПО стремительно меняется и программирование уже никогда не будет прежним, старые подходы стремительно устаревают и становятся неэффективными.   Новые еще не выработаны. Отрасль, по сути, находится на распутье и сегодня важно не проспать новые тенденции, чтобы остаться в обойме и не оказаться за бортом. Так как изменится не только рынок программирования, но и все смежные отрасли так или иначе изменятся.   И этот процесс уже идет. Кто-то уже начал осваивать новые инструменты, кто-то только приглядывается, а кто-то пытается прятать голову в песок. Но отсидеться ни у кого не получится. Эпоха перемен началась и затронет она так или иначе каждого.

Получи грант до 1,35 млн руб. на обучение в магистратуре Хочешь развиваться в сфере ИТ и получить фундаментальные знания с практикой? Поступай в магистратуру Центрального университета! — 4 офлайн программы по востребованным направлениям ИТ — 2 онлайн-программы: машинное обучение и продуктовый менеджмент — 550 грантов до 75% — Вечерние занятия и учеба по выходным — удобно совмещать с работой — Обучение по модели STEM-образования: на стыке науки, технологий и бизнеса — Возможность стажировок и трудоустройства в ведущих компаниях — Государственный диплом за 2 года Магистратура в Центральном университете — это современный подход к образованию, сильный преподавательский состав и актуальные кейсы от индустрии. Оставляй заявку на грант уже сейчас! Зарегистрироваться #реклама 16+ cu.ru О рекламодателе

Watchtower – управляем обновлением контейнеров в Docker Инфраструктура на основе Docker – это удобно, особенно если вы используете подход «инфраструктура как код». Но вместе с плюсами появляются и минусы – все это хозяйство требуется поддерживать в актуальном состоянии и регулярно обновлять. Можно, конечно, делать это руками, но зачем, когда можно автоматизировать этот процесс. Для этого мы будем использовать Watchtower – простой и удобный инструмент, который будет отслеживать состояние ваших контейнеров и обновлять их по мере выхода новых версий. Для его использования вам потребуется еще один небольшой контейнер, который можно развернуть при помощи следующего docker-compose.yml:

services:
  watchtower:
    image: containrrr/watchtower
    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_LABEL_ENABLE – включает режим обновления по меткам Теперь для того, чтобы Watchtower отслеживал и обновлял контейнер к нему следует добавить метку:

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

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

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

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

WATCHTOWER_LABEL_ENABLE=false

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

Собственный ИИ-помощник за пару кликов c ohmyclaw Ohmyclaw — абсолютно новый на рынке сервис. Он сделан командой RetailCRM, платформы для управления клиентским сервисом, маркетинговыми рассылками и лояльностью 🤝 Ребята давно внедрили ИИ для своих пользователей: например, ИИ-помощники уже создают и запускают рассылки для интернет-магазинов, оценивают работу менеджеров и сами консультируют покупателей. Но на этом создатели RetailCRM не остановились — и выпустили ohmyclaw. С ним личного или корпоративного ИИ-агента запустит даже новичок без технических навыков 🔥 Больше никаких сложных настроек и интеграций, серверов, попыток вручную собрать код. Все сложные процессы уже сделаны 😎 Личный ИИ-агент: — Напоминает о встречах, задачах, важных датах — Находит любую информацию: например, дешёвые билеты в отпуск — Собирает презентации и доклады для жизни, работы или ребёнку в школу Корпоративный ИИ-помощник встраивается в бизнес-процессы: — Помогает разрабатывать продукты — Обеспечивает техподдержку в бизнесе — Ставит задачи и контролирует работу сотрудников — Готовит документы, отчёты и презентации Кстати, общаться с ним одно удовольствие — прямо в Телеграм-чате. Понимает даже голосовые 👌 Оцените сами — запустите личного или корпоративного ИИ-агента за пару минут по ссылке ⚡

Что такое запись 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 запись, то проверка по дереву прекращается и начинается проверка дерева домена на который указывает такая запись.