​​Видео или текст?

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

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

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

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

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

Даже в режиме быстрой перемотки на поиск интересующей нас информации ушло около двух часов. Потом еще где-то час на поиск уточняющих моментов и общее понимание всей структуры решения.

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

Что это? Лень написать документацию? Или современное поколение разучилось читать, и разработчики идут у него на поводу?

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

А как обстоит дело с этим вопросом у вас?

​​Балансировка и резервирование каналов на Mikrotik

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

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

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

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

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

🔹 Mikrotik и несколько провайдеров. Резервирование каналов

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

🔹 Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации

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

А еще в этой статье описано как быть если провайдер выдает вам динамический белый IP-адрес через PPPoE или DHCP, это пригодится вам при любом методе резервирования или балансировки.

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

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

Все это, включая правильную маркировку трафика есть в нашей статье:

🔹 Mikrotik и несколько провайдеров. Балансировка каналов

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

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

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

​​И снова про белок и колеса…

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

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

Начинаем разбираться что почем. Фирма небольшая, десяток ПК, два принтера, сервер. Админ работал на полставки за 25 тыс. руб. Приходил на полдня, решал насущные проблемы, остальное время был удаленно или на телефоне.

А чего, спрашиваем, ушел?

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

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

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

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

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

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

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

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

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

Причем их достаточно много как в мелком бизнесе, так и в бюджетной сфере.

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

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

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

А чего? Работает ведь? А если что – у нас есть мальчик, сейчас свистнем, прибежит, починит.

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

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

​​Прохождение пакетов через брандмауэр Linux и Mikrotik

Одна из вечных тем. Сколько не пиши про нее – вопросов меньше не становится. Как и ошибок.

Это равно касается как Linux, так и Mikrotik, что не удивительно, так как и там и там работает iptables.

В свежих дистрибутивах его сменил nftables, но в большинстве случаев он работает в режиме совместимости с iptables и использует синтаксис последнего.

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

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

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

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

Более подробно обо всем этом написано в нашей статье:

🔹 Основы iptables для начинающих. Часть 1. Общие вопросы

Крайне рекомендуем ознакомиться с ней и освежить свои знания.

​​TeraBox – гигабайт облачного хранилища от китайцев

Недавно коллеги подкинули наводку на облачный сервис TeraBox, который бесплатно предлагает 1 ТБ пространства, да не просто терабайт, а честный терабайт, т.е. 1024 ГБ.

Регистрация в TeraBox не составляет труда, достаточно электронной почты, русский язык в клиенте присутствует, а сам клиент есть под все распространенные мобильные и настольные ОС, включая Linux (DEB и RPM).

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

Для медиафайлов имеется встроенный плейер, однако в бесплатном варианте он ограничен качеством в 480p. Но это несущественный недостаток.

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

В среднем это где-то от 10 до 30 Мбит/с. Также было замечено, что скорость зависит от размера файлов, чем больше файл – тем ниже скорость.

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

⭐️ RHEL: создание локального репозитория-зеркала для просветленных🧘‍♂️

Делимся статьей инженеров из «Инфосистемы Джет». В материале они рассказывают, как создать локальный репозиторий в RHEL и при этом не потерять части функционала и данных. 

Какие возможности дает репозиторий, кроме основной функции:
🍭 устанавливать пакеты группами;
🍭 устанавливать пакеты по Eratta (не по именам);
🍭 устанавливать по конкретным патчам безопасности CVE (Common Vulnerabilities and Exposures);
🍭 синхронизировать репозитории не полностью, а «частично», с информацией по только добавившимся пакетам с прошлого раза.

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

​​systemd.path – реагируем на события файловой системы

Как мы уже рассказывали systemd предоставляет администраторам простые, но в тоже время мощные инструменты на все случаи жизни.

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

Создадим для примера юнит /etc/systemd/system/my_name.path

И внесем в него следующие строки:

[Unit]
Description= Path test

[Path]
PathExists=/a/b/c/filename

[Install]
WantedBy=multi-user.target

В общем и целом, стандартный юнит, ничего необычного, кроме секции Path, в директиве PathExists – путь, который мы отслеживаем.

Если секция Path не содержит директивы Unit, то будет найден и запушен одноименный сервис, т.е. my_name.service.

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

[Path]
PathExists=/a/b/c/filename
Unit=123.service

Для начала работы юнит нужно запустить и добавить в автозагрузку:

systemctl start my_name.path
systemctl enable my_name.path

Или одной командой:

systemctl enable --now my_name.path

В секции [Path] можно одновременно отслеживать несколько путей, запуск юнита произойдет при выполнении любого условия. Однако если хоть одно условие содержит пустую строку, то все директивы будут проигнорированы и юнит работать не будет.

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

▫️ PathExists= проверяет существование файла

▫️ PathExistsGlob= тоже самое, но позволяет использовать шаблоны подстановки

▫️ PathChanged= проверяет изменение файла, срабатывает по окончанию редактирования

▫️ PathModified= проверяет модификацию файла, срабатывает сразу, не дожидаясь окончания редактирования.

▫️ DirectoryNotEmpty= проверяет появление файлов в директории

Дополнительно с последней можно использовать:

▫️ MakeDirectory= при указании true каталог для отслеживания будет автоматически создан

▫️ DirectoryMode= права на созданный каталог, по умолчанию 0755

Еще две опции позволяют задать временные лимиты срабатывания.

▫️ TriggerLimitIntervalSec= юнит будет срабатывать не чаще указанного промежутка вермени, по умолчанию 2 секунды.

▫️ TriggerLimitBurst= количество активаций за указанное время, по умолчанию 200. Таким образом если произойдет более 200 срабатываний за 2 секунды, то юнит перейдет в режим сбоя не будет работать до перезапуска.


Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.

​​Qiwi Банк – всё…

Сегодня произошло то, что было в общем-то ожидаемо:

Банк России приказом от 21 февраля отозвал лицензию на осуществление банковских операций у КИВИ Банка, сообщается на сайте ЦБ.

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

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

Поэтому не удивительно что терпение ЦБ в итоге лопнуло, странно, что это не произошло раньше.

Ну а нам до этого какое дело? Казалось бы, помер дед Максим, да и … с ним. Но увы, последнее время Киви оставался одним из самых доступных и недорогих способов оплатить что-нибудь там, тот же Steam, или вывести деньги оттуда.

Теперь все будет гораздо сложнее и дороже.

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

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

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

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

​​Непростой выбор

Задумался тут поменять часы, сейчас на руке HONOR MagicWatch 2 купленные в феврале 2020. В целом с ними все хорошо, но батарея уже подустала и стекло со временем наловило царапин.

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

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

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

🔹 HUAWEI WATCH GT 4 – основной рассматриваемый вариант, четвертое поколение часов, что ждать – понятно, но по отзывам не сильно много отличий от второго поколения, которое сейчас на руке. С другой стороны – сюрпризов также быть не должно.

🔹 Xiaomi Watch S1 – именно S1, а не S1 Active. По описаниям лучше экран, как объективно (461 ppi против 326 ppi), так и субъективно. А также сапфировое стекло.

Не сказать, что стекло на HONOR / HUAWEI плохое, но за четыре года царапин насобирало. Но отзывы о модели неоднозначные и местами крайне противоположные. Кто-то в восторге, кто-то пишет, что они не стоят своих денег.

🔹 Amazfit GTR 4 – по отзывам и рейтингам лидер своей ценовой категории, все прямо хвалят. В целом по характеристикам тот же HUAWEI WATCH GT 4 плюс – минус. Но когда я поменял свои первые Amazfit STRATOS на HONOR MagicWatch 2, т.е. часы той же ценовой категории, то впечатления были сильно не в пользу Amazfit.

Причем нельзя сказать, что Amazfit был именно плох, нет, все вроде бы так, но общее ощущение от HONOR были как «цельно сделанная вещь», а STRATOS ощущался после него каким-то «недоделанным».

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

Как получить работу в крупной промышленной компании? 

😭 Можно отправлять отклики на hh, проходить этапы отбора и учиться на полученных отказах
😍 А можно сократить путь с помощью карьерного канала СИБУРа 

Тут ты найдешь:
— советы по составлению резюме и прохождению отбора;
— подборки свежих вакансий и стажировок;
— кейсы сотрудников и обмен опытом! 

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

Вот, например, карьерная история Дианы, ведущего инженера с пермского производства СИБУРа, которую она рассказывает сама, но… с небольшим подвохом: что же случилось дальше, тебе придется угадать самому. 

Готов проверить интуицию и познакомиться с реальной историей героини? Тогда подписывайся на канал и переходи к посту!

erid: LjN8K462F

​​Почему именно systemd?

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

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

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

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

Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.

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

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

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

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

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

До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.

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

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

Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.

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

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

Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?

​​Что такое хорошо и что такое плохо

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

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

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

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

Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.

Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.

Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.

Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.

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

- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…

Или:

- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…

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

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

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

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

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

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

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

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

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

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

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

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

​​И снова про отечественные сертификаты

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

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

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

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

За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.

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

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

Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.

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

Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.

Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.

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

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

Key exchange ECDHE_RSA with P-256

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

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

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

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

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

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

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

Привет!
Это команда Концепт-Разработка. Мы занимаемся развитием и внедрением продуктов в сфере больших данных, корпоративных хранилищ данных, BI и систем управления данными. У себя в канале развиваем сообщество бизнес и системных аналитиков, разработчиков и data-инженеров.
+ Актуальные вакансии;
+ Интересные разработки;
+ Проекты федеральных заказчиков;
+ Новости индустрии и многое другое.

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

Реклама. ООО "КОНЦЕПТ РАЗРАБОТКА". ИНН 7703471165. erid: LjN8KQu3R

​​Чебурнет

Еще одна любимая пугалка в среде IT-братии. Но многие, наверное, удивятся, потому что Чебурнет давно существует и не один.

Что такое сеть интернет? Это всемирное средство коммуникации и т.д. и т.п. Но давайте спустимся с небес на землю и посмотрим на это все с позиции рядового пользователя.

Возьмем условного дядю Васю, инженера на заводе и его жену тетю Клаву, учителя начальных классов. Ну и их детей, Ваню и Машу, класса так 5-го и 10-го.

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

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

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

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

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

Но это все доступно и в зоне RU. Точнее было доступно. Но сей контент сделался недоступным не по политическим мотивам и Товарищ Майор здесь не причем, большинство блокировок возникли по требованиям правообладателей, которые преследовали свои коммерческие интересы.

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

По сути, зона RU – это исторически сложившийся Чебурнет. Он не интересен западному пользователю, так как он вообще здесь ничего прочитать не может (другой алфавит, как никак), а западный сегмент также не интересен пользователю русскоязычному. Потому что языковой барьер.

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

Если брать те же соцсети, то VK/ОК закрыли практически всю нишу, и никто не страдает от отсутствия той же Мордокниги (Facebook).

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

В итоге за условный «железный занавес» будут бегать только за варезом и контентом 18+, хотя насчет последнего не уверен, так как основной его черно-оранжевый поставщик действует в России вполне легально, надо только подтвердить возраст через VK.

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

Если наша культура достаточно близка западной, то китайская крайне далека и непонятна нам, как и наша культура им.

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

Собственно, а вы сильно пострадаете, если вам вдруг закроют доступ к китайским ресурсам?

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

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

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