Администрирование

В наше время растет популярность децентрализованных альтернатив современным подходам к маршрутизации трафика в вычислительных сетях (например, для обхода санкционных блокировок недружественных стран и анонимизации трафика). Одним из примеров такого подхода является Yggdrasil. Новые подходы обещают нам инновации, децентрализации и конечно же гарантии безопасности. Но так ли это на самом деле? И хотя многие опытные пользователи и так знают о проблемах безопасности подобных сетей, мне бы хотелось подсветить их сильнее на одном конкретном примере, не претендуя на звание создателя rocket science.

ПРЕДУПРЕЖДЕНИЕ. Все совпадения вымышлены. Автор не ставил своей целью просканировать весь Yggdrasil и проэксплуатировать все уязвимости безопасности.

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

Усиление защиты ядра Linux — это задача, предполагающая постоянную работу сразу по нескольким направлениям. И иногда эта работа может быть выполнена даже не в самом ядре, а с помощью других инструментов, или даже в компиляторах. На конференции 2023 GNU Tools Cauldron Цин Чжао (Qing Zhao) рассказала о работе, проделанной в компиляторе GCC для укрепления ядра, а также о работе, которую еще предстоит проделать.

Проект Kernel self-protection является отправной точкой для львиной доли работ по укреплению ядра, — начала она. Усиление защиты может быть выполнено несколькими способами, начиная с исправления известных ошибок безопасности, которые могут быть обнаружены с помощью статических анализаторов, фаззеров или инспекции кода. Однако исправление ошибок — это задача, не имеющая конца, и гораздо лучше, когда у нас есть возможность полностью исключить целые классы ошибок. Таким образом, большая часть усилий по укреплению ядра была направлена на устранение таких проблем, как переполнения стека и кучи, целочисленные переполнения, инъекции форматных строк, утечки указателей, использование неинициализированных переменных, use-after-free уязвимости и т.д. Также ведется работа по блокированию разных методик эксплойтов, включая возможность перезаписи текста ядра или указателей функций.

Запуск своего Linux-сервера многие до сих пор видят как работу для владельцев свитера, бороды и толстого тома с инструкциями по Unix/Linux и набором команд в bash/sh-консоли. Возможно вы также считаете работу с командной строкой в терминале чем-то архаичным и неудобным, и вам сложно подключаться, поскольку вы нередко забываете команды и их параметры. Если да — то все нижеперечисленное вам будет интересно. В любом случае вы можете поделиться своим опытом и замечаниями в комментариях.

Мы расскажем, как с нуля развернуть полноценный Linux-сервер на базе Ubuntu 20.04, не вписывая ни единой строчки кода в терминале. Весь процесс будет выполнен исключительно через веб-интерфейс панели управления ispmanager.

Данная инструкция подойдет для виртуальных и обычных выделенных серверов с предустановленной панелью управления ispmanager. 

Вносить изменения в код приложения и тут же автоматически получать задеплоенные изменения, чтобы быстро тестировать его, — мечта разработчика. В этой статье мы посмотрим, как реализовать такой подход для небольшого приложения с фронтендом и бэкендом: организуем два варианта локального стенда на базе minikube или Docker с автоматическим развертыванием всех изменений или только закоммиченых в Git.

Бэкенд приложения напишем на Go, а фронтенд — на Vue.js. Все это позволит быстро запускать проект для тестирования прямо во время разработки, что, несомненно, повысит удобство работы с приложением.

Недавно в своих ежедневных чтениях я наткнулся на явление, о котором думал уже много лет: феномен утечки информации людей, использующих SSH. Этот тип утечки информации не является новым явлением. Я давно предупреждал об этой опасности своих друзей, использующих SSH, но мой голос услышали лишь несколько человек. Поэтому я решил дать пояснения по этому поводу, потому что я считаю, что необходимо понимать этот риск в ИТ-сообществе, особенно в нынешней ситуации. Я буду исходить из предположения, что у вас, дорогой читатель, есть опыт работы с SSH.

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

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

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

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

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

Виртуальная машина eBPF, работающая в ядре Linux, приближается к десятилетнему юбилею своего включения в состав Linux; за это время она успела превратиться в инструмент, имеющий целое множество применений в этой экосистеме. Алексей Старовойтов (Alexei Starovoitov), который является создателем eBPF и занимался ее развитием, особенно на начальном этапе, выступил на открытии Linux Security Summit Europe 2023 с докладом о взаимосвязи BPF и безопасности. В нем он поделился с нами интересными историческими моментами в несколько иной перспективе, нежели они обычно раскрываются. Среди прочего, он рассказал, как BPF на протяжении всего своего пути была одновременно и проблемой безопасности, и ее решением.

История начинается в 2017-м году - когда мне потребовался самодельный почтовый сервер на связке Postfix + Dovecot + Roundcube + LDAP-каталог (AD на тот момент). Сказано - сделано - времени ушло прилично (делалось для FreeBSD), но зато много в чем получилось досконально разобраться. И естественно была составлена приличная статья-портянка в личной DokuWiki.
В 2021-м году адаптировали под Debian 11. В 2022-м был написан Ansible Playbook, который все делал автоматически, экономя пару часов времени ))) и нервов тоже изрядно экономил.

И вот наконец, неделю назад, была поставлена задача попробовать адаптировать данный Playbook к отечественным ОС (к 3-м самым распространенным, как видно из темы).
Если не хочется читать и погружаться в детали - все результаты выложены по ссылке (текущая версия Wiki + 4 архива Ansible Playbook): https://github.com/Dorlas/mailserver-ansible/

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

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

Привет, меня зовут Максим Качинский, я ведущий DevOps-инженер в компании RocketData. Более 6 лет мы развиваем одноимённую платформу для управления репутацией — за это время она выросла с монолитного MVP на единственном сервере до 15+ микросервисов с пятью разными видами баз данных. И всё это в гибридной инфраструктуре. 

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

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

Привет! Я управляю подразделением VoIP в группе компаний Dyninno — международном холдинге, который предоставляет услуги и продукты в сфере туризма, финансов, развлечений и технологий в 50 странах. Важнейшей составляющей нашего бизнеса является продажа авиабилетов. Мы работаем по гибридной схеме: привлекаем клиентов онлайн, а тревел-агенты совершают продажи — созваниваются с клиентом, уточняют пожелания и формируют наиболее выгодное предложение от авиакомпаний. Сейчас у нас свыше 4200 тревел-агентов, и как раз-таки их работу и обеспечивает наш внутренний кол-центр. 

В этой статье я расскажу о разных сценариях работы территориально распределенного кол-центра на базе Asterisk, Kamailio и rtpengine. 

Как работает кол-центр 

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

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

Статья подготовлена на основе доклада Владимира Дроздецкого о вопросах, методах, практиках и в целом подходе к Observability для инфраструктурной платформы Magnit Online Services. Внутри — о том, как пришли к идее нового процесса, о настройке мониторинга от helm upgrade до gitops-подхода, опыте интеграций с Grafana в работе с визуализацией и метриками и политике алертов, которая не пропускает критичные угрозы.

Статья будет полезна инженерам платформенных команд и эксплуатации, а также всем, кто внедряет у себя DevOps-практики.

Как убедиться в том, что коммиты в продуктовых репозиториях «настоящие»? То есть отправлены тем человеком, имя которого указано в коммите. Мы с коллегами из команды DevOps задались целью построить процесс, который будет давать нам полностью прозрачную картинку, и у нас это получилось. Эта статья довольно практическая, и решение, о котором я, Рамазан Ибрагимов, вместе с моим коллегой Александром Паздниковым пишу в этом материале, — лишь часть большой схемы по обеспечению безопасности. В качестве хранилища кода будем опираться на инстанс GitLab On-Premise внутри компании — вендора ПО.

Привет, Хабр! Меня зовут Евгений Кузьмин, я Java‑разработчик в CDEK. Надеюсь, все знают, что это за компания и чем занимается. Давайте представим, что вам нужно отправить посылку с гостинцами родственнику в Москву из Новосибирска. Вы приходите в ближайший пункт приёма посылок и оформляете услугу доставки. Что же происходит дальше? Казалось бы, всё очевидно: посылка сразу летит или едет из Новосибирска в Москву. Но всё не так просто...

Думаю, все согласятся, что не рационально гнать отдельную фуру с одной коробочкой для каждого заказа. Наша задача выстроить логистику таким образом, чтобы по пути загрузить и выгрузить как можно больше посылок и поехать дальше. В этой статье я поделюсь с своим опытом оптимизации задачи по редактированию и поддержке в актуальном состоянии огромного количества данных типа «куда направить товар». Классическая задача программирования на практике логистики. При этом мы не будем выходить за рамки стандартного стека Java Springboot и Postgres. Статья будет полезна разработчикам (от джуна до сеньора), которым интересно погрузиться в трудовые будни разработчика в сфере транспортной логистики.

При написании бэкенда работа с базой данных зачастую составляет большую часть кода в проекте. Но несмотря на то, что в го стандартная библиотека для тестирования довольно удобная, она требует написания большого количества кода. Поэтому иногда вместо того, чтобы писать тесты разработчики могут ограничить тестирование при помощи какого-либо клиента (например, при помощи tableplus или другого sql-клиента), либо тестируют уже конечные точки API используя postman. С одной стороны, это, конечно может быть быстрее для первого тестирования, но с другой — такие методы не обеспечивают должного покрытия тестами приложения.

Решить проблему с написанием большого количества кода может помочь библиотека testify, которая позволяет писать тесты более выразительно и с меньшим количеством кода. В testify есть пакеты require и assert, в первом случае выполнение теста будет прервано, а во втором — продолжено. В статье будет использоваться пакет assert. Для облегчения понимания кода можно использовать табличное тестирование, которое поможет определить, какие случаи проверяются даже при беглом взгляде на код.