Запустить виртуальную машину в kvm или дать команду ядру на создание неймспейса - это и есть "высокоуровневое конфигурировпние".
Лопатить тысячи запросов в секунду с преобразованием их в запросы к бд и отдавать их за адекватное время - тут уже есть инструменты получше питона.
Одна сессия общения по ldap - это около 10 последовательных ldap-запрсов. И критически важно, выполняется один запрос за 10 мс или за 100. Потому, что в одном случае это 100 мс на ответ (считай мгновенно), а в другом 1 с (это уже ощутимые задержки).
Я не говорю уже про фоновые задания в БД. Обеспечение связности ldap-записей, например, по атрибуту member, здесь python прямо сильно хуже себя показывает по сравнению с плагинами непосредственно к БД.
Коллеги, всеми руками за ваше начинание и желаю вам только успехов. А теперь немного критики:
1) Можете спросить у коллег из Avanpost, они тоже начинали с бэкенда в виде postgres и перешли в итоге к специализированной БД. Postgres не подходит для задач ldap. Он не способен выполнять чтение и поиск данных с необходимой производительностью, сколько в него не влей ресурсов. Реляционные БД здесь не подходят.
2) Репликация и устойчивость к разделению - это главное требование к домену. Это не кластер. С точки зрения пользователя он не должен получить отказ в обслуживании, если интернет пропал. Поэтому БД должна быть под боком, в той же сети.
3) Python - это хорошо, когда это верхнеуровневое конфигурирование. Когда вы пытаетесь делать низкоуровневые операции на python - вы неизбежно наткнетесь на ограничения производительности. Одна и та же операция на go и на python отличается по времени на порядок.
Кстати, freeipa здесь хороший пример. Она тоже написана на python, но при этом низкоуровневые ldap-операции и работа с БД - это 389ds и c.
4) Структура данных, совместимая с MS AD - это главная ошибка тех, кто начинает писать свой каталог. Тут главный вопрос в том, а для чего вы пишите каталог?
Если для Linux, то почему берете структуру данных, не учитывающую posix и особенности Linux?
Если для Windows, то зачем вы ее пишите, если там есть MS AD?
Коллеги из Avanpost пошли тем же путем, а теперь у них всплывают последствия подобных решений. Например, их структура данных не учитывает модель доступа UGO (стандартную для posix). Все пользователи домена у них не имеют приватных групп, но имеют primary group (Domain Users) по аналогии с MS AD. Таким образом, после логина на рабочие станции все пользователи становятся членами одной приватный группы Domain Users и получают доступ ко всем конфиденциальным данным друг-друга
Правильно написали, географически распределенность и устойчивость к разделению. Условно, если у вас разоралась связь между филиалами, то контроллер в Новоосибе не сможет обслуживать пользователей, если его БД в Москве.
Да и гонять запросы между кд в Новосибе и бд в Москве через узкий канал между филиалами - такая себе идея, это очень большие потери пакетов = ошибки в бд и низкая производительность. Хотя у postgresql, в принципе, низкая производительность в задачах ldap (низкая частота записи, высокая чтения, и поиска)
Если вы про самовыпил salt-master, то нет, его нет и не будет. Схема со standalone миньонами показала себя во всех аспектах более надёжной и масштабируемой, поэтому останется она.
Если нужен функционал прямо связки мастер-миньон, то он вынесен в отдельный продукт "АСМ".
Это вы немного не понимаете ситуации. Да, серверов GGC стало меньше в РФ (примерно в 2 раза). Да, это вызывает некоторое замедление из-за более частых обращений к холодным серверам YouTube. Но это очень незначительное замедление. Но зато это значительный внешний трафик через западных магистралов, за что надо платить провайдерам денежку.
Поэтому да, любой обход DPI вернет практически всю старую скорость YouTube, но при этом сделает наших провайдеров чуточку беднее.
Вы сейчас путаете 2 механизма. HBAC относится к sssd и pam-стеку и определяет, может ли тот или иной пользователь выполнить логин на тот или иной клиент домена (т.е. хост, вход на который обслуживает sssd). RBAC определяет тоже самое, только через механизм ролей. RBAC - это надстройка над HBAC. Это не подмена понятий, а реализация одной и той же задачи разными подходами. В курсе говорится именно о классическом HBAC
Есть гораздо более простой путь. Например, водородные топливные ячейки. Технология, разработанная ещё для Апполонов в рамках лунного проекта. Для их производства нужна только вода и дешёвая энергия. Сейчас добычу водорода планируют на базе АЭС, но вполне можно использовать и такой тип генерации энергии, если он хотя-бы вполовину так хорош, как описано в статье. Зачем в транспорте что-то сжигать, вроде углеводородов или спирта? Есть вполне современные способы приведения чего-то в движение и без процесса горения.
Можно, просто для ненулевой классификационной метки действуют ограничения, в частности, на fuse. Подключать шары может только администратор, например, через /etc/fstub, pam_mount или autofs. Понятно, что писать на виндовые шары будет нельзя, у них всегда нулевая классификационная метка.
Вот только не надо тут. Союзы 2024 года совершенно не тоже самое, что Союзы 70-х. Это одноразовый корабль. С каждой новой итерацией его модернизируют, ставят актуальную начинку и электронику. Наглядный пример - Союз МС-20 долетает до МКС за пару часов, когда тому же Дракону нужно 2 суток. По факту , Союз - это КК под формфактор ракетоносителя Союз. Пока мы используем РН Союзы, нет никакого смысла менять КК. А Союз сам по себе очень удачный РН среднего класса, давно отработанный, надёжный как швейцарские часы, а потому очень дешёвый. Себестоимость запуска 60 млн. $, что даже Илону Маску с его возвращаемыми ступенями и не снилось.
Что касается Орла, это КК под формфактор Ангары 5. Это сверхтяжелый РН и под другие задачи. Орел, вообще, проектировался под полет на Луну.
Короче, начало использования Ангары и Орла не отменяет Союзы, их ниша ещё долго будет востребована.
Это не так. pdp-init-fs отрабатывает достаточно быстро.
Что касается бэкапирования, то ничего не затирается, метки не хранятся в parsecfs. Тут важно помнить о том, что метки безопасности файлов хранятся в расширенных атрибутах. Что-бы сохранить метки в бэкапе вы должны просто выполнять копирование с поддержкой расширенных атрибутов на файловые системы с поддержкой расширенных атрибутов. Или архивировать в форматы с поддержкой расширенных атрибутов (например, tar). Я не знаю, как у вас организовано бэкапирование. Для восстановления данных с метками нужно включить режим unsafe_xattr.
Короче, нормально с этим всем можно работать, и, в данном случае, нытье о том, какой отечественный линукс хреновый, только говорит о ваших кривых руках
Минимум 3 созвона в день. Каждый день дейли минимум на час (по 1 на отдел, к которому имею отношение). Сделал что-то прикольное, решил сложную задачу? Будь добр, продемонстрируй и доложись (в формате созвона), напиши статью и доку. Потратил 3 месяца на исследование технологии? Следующие 3 месяца ты будешь читать лекции аналитикам, архитектором и кодерам (В формате созвона). Собственно, а работать когда? Сложно работать, когда 4-6 часов в день - это созвоны (и это даже не у менеджера)
А какое отношение это поделие Oracle имеет к KVM? VirtualBox не использует kvm и qemu, а использует собственные проприетарные модули ядра, что, и это абсолютно логично, работает медленнее и с большим количеством багов.
Другой вопрос, что наличие kvm не позволит вам эмулировать на arm x86 архитектуру, это задача эмулятора, т.е. qemu. А, в общем, никаких проблем с запуском виртуальных машин с arm архитектурой на arm нет.
Очень хорошо описано в readme в репозитории bol-van/zapret на github. О том, что такое dpi, на чем основаны методы обмана, какие есть стратегии и прочее.
Выскажу свое мнение, потому как считаю, что автор не полностью раскрыл тему.
1) Официально вы можете поставить на любую машину (Только со встройкой от Intel, другие видеокарты не поддерживаются) только Chrome OS Flex без нативной поддержки Android. Сам Chrome OS распространяется по модели Apple, т.е. сразу на ноутбуках.
Неофициально есть такой проект на гитхабе, как Chrome Brunch, который позволяет накатить полноценную Chrome OS, а так же включает в себя драйвера wifi, фиксы тачпадов, аудио и разные полезные вещи. Но все так-же поддерживается только встройка от Intel.
Есть ещё китайский форк Fyde OS со своей реализацией поддержки Android через виртуальную машину. Там они запили драйвер AMD, что позволяет ставить ее на APU от красных или дискретное видео от AMD помимо все того же интела.
2) Система, как ни странно, очень удобна как для обычного пользователя, так и для разработчика. Для кого она неудобна - это для геймеров, несмотря на поддержку Android. Казалось бы, есть мобильный гейминг, огромное количество игр, но проблема в том, что ПК - это клавамышь, а андроид-игры заточены на тачпад. Разработчики хоть и пытаются сделать маппер клавамыши на события тачпада (arc input overlay), но пока эта технология ещё в преальфе и нигде не работает. А подобный софт для телефона весь собран на ARM64 и на x86 просто не работает.
3) Очень сильно расширяет возможности системы встроенная ВМ с Debian (сейчас 12-м). Реализована она как WSL в Windows, т.е. просто в виде отдельного приложения терминала, который запускаешь и попадаешь внутрь ВМ. Там можно поставить любые linux-приложения, даже с графическим интерфейсом (он будет нативной проброшен в основной рабочий стол), можно накатить докер и развернуть тот софт, которого не хватает в основной системе, например code-server (visual studio code) и пользоваться им через браузер, да в этой виртуалке можно хоть proxmox накатить и разворачивать там другие виртуалки и строить любые стенды.
4) Чтобы полностью удовлетворить мои потребности в качестве рабочей машинки не хватило только одного - ограниченная поддержка проброса usb внутрь ВМ с Debian. По сути, туда можно пробросить только usb mass storage и adb. Fastboot и предзагрузочные последовательные интерфейсы телефона пробросить уже нельзя, а софта, что-бы с ним работать в самой Chrome OS построенной на базе Gentoo нет. Аналогичная ситуация с созданием разделов и форматированием дисков и флешек (сделать можно только в хост-системе, где нет поддержки многих фс, вроде btrfs).
В итоге, система то крутая, но не без минусов и не всем подойдёт. У меня сейчас на ноуте домашнем стоит (Asus Zenbook 13).
Как это проверяется - Читается структура файлов и их хеши с base репозитория астры. После этого эти файлы и хеши сравниваются с текущей инсталляцией дистрибутива. Таким образом, если пакет присутствует в репозитории и он не совпадет по хешам с установленным то будет сразу забракован аттестатором.
И это логично, так как многие пакеты Астры пропатчены для работы с parsec, тот же postgresql, например. Так что вы не можете накатить 25-й докер в Астру или postgresql 17 и не потерять при этом сертификацию. Довольствуйтесь тем, что есть. В этой ветке речь про NUT, который в репозитории присутствует, так что любая новая его версия (с поддержкой snmp v3) ломает хеши.
Если же вы собрали свой пакет, которого нет в репозитории - тогда да, имеете полное право его ставить.
Проблема в том, что установка пакета, присутствующего в репозитории Астры, но из другого источника, другой версии и с другими хешами файлов сразу приводит к несовпадению хешей дистрибутива. На практике это означает, что любой регулятор перестает считать эту систему Aстрой, аттестат и сертификация становятся недействительными.
Проверка хеш-сумм дистрибутива выполняется встроенными средствами Астры с использованием эталонного диска с репозиторием. Это действие явно прописано в любой методичке любого аттестатора.
Забыли упомянуть, что это про часы от Huawei. Причем, про очень ограниченную линейку. Например, мои GT 2 не подходят, хоть и имеют nfc на борту.
Подгонка результата под ответ вышла на новый уровень?)
А если без шуток, поздравляю.
Запустить виртуальную машину в kvm или дать команду ядру на создание неймспейса - это и есть "высокоуровневое конфигурировпние".
Лопатить тысячи запросов в секунду с преобразованием их в запросы к бд и отдавать их за адекватное время - тут уже есть инструменты получше питона.
Одна сессия общения по ldap - это около 10 последовательных ldap-запрсов. И критически важно, выполняется один запрос за 10 мс или за 100. Потому, что в одном случае это 100 мс на ответ (считай мгновенно), а в другом 1 с (это уже ощутимые задержки).
Я не говорю уже про фоновые задания в БД. Обеспечение связности ldap-записей, например, по атрибуту member, здесь python прямо сильно хуже себя показывает по сравнению с плагинами непосредственно к БД.
Коллеги, всеми руками за ваше начинание и желаю вам только успехов. А теперь немного критики:
1) Можете спросить у коллег из Avanpost, они тоже начинали с бэкенда в виде postgres и перешли в итоге к специализированной БД. Postgres не подходит для задач ldap. Он не способен выполнять чтение и поиск данных с необходимой производительностью, сколько в него не влей ресурсов. Реляционные БД здесь не подходят.
2) Репликация и устойчивость к разделению - это главное требование к домену. Это не кластер. С точки зрения пользователя он не должен получить отказ в обслуживании, если интернет пропал. Поэтому БД должна быть под боком, в той же сети.
3) Python - это хорошо, когда это верхнеуровневое конфигурирование. Когда вы пытаетесь делать низкоуровневые операции на python - вы неизбежно наткнетесь на ограничения производительности. Одна и та же операция на go и на python отличается по времени на порядок.
Кстати, freeipa здесь хороший пример. Она тоже написана на python, но при этом низкоуровневые ldap-операции и работа с БД - это 389ds и c.
4) Структура данных, совместимая с MS AD - это главная ошибка тех, кто начинает писать свой каталог. Тут главный вопрос в том, а для чего вы пишите каталог?
Если для Linux, то почему берете структуру данных, не учитывающую posix и особенности Linux?
Если для Windows, то зачем вы ее пишите, если там есть MS AD?
Коллеги из Avanpost пошли тем же путем, а теперь у них всплывают последствия подобных решений. Например, их структура данных не учитывает модель доступа UGO (стандартную для posix). Все пользователи домена у них не имеют приватных групп, но имеют primary group (Domain Users) по аналогии с MS AD. Таким образом, после логина на рабочие станции все пользователи становятся членами одной приватный группы Domain Users и получают доступ ко всем конфиденциальным данным друг-друга
Правильно написали, географически распределенность и устойчивость к разделению. Условно, если у вас разоралась связь между филиалами, то контроллер в Новоосибе не сможет обслуживать пользователей, если его БД в Москве.
Да и гонять запросы между кд в Новосибе и бд в Москве через узкий канал между филиалами - такая себе идея, это очень большие потери пакетов = ошибки в бд и низкая производительность. Хотя у postgresql, в принципе, низкая производительность в задачах ldap (низкая частота записи, высокая чтения, и поиска)
Он никуда и не уходил.
Если вы про самовыпил salt-master, то нет, его нет и не будет. Схема со standalone миньонами показала себя во всех аспектах более надёжной и масштабируемой, поэтому останется она.
Если нужен функционал прямо связки мастер-миньон, то он вынесен в отдельный продукт "АСМ".
А в чем "некорректность" работы Kerberos?
Это вы немного не понимаете ситуации. Да, серверов GGC стало меньше в РФ (примерно в 2 раза). Да, это вызывает некоторое замедление из-за более частых обращений к холодным серверам YouTube. Но это очень незначительное замедление. Но зато это значительный внешний трафик через западных магистралов, за что надо платить провайдерам денежку.
Поэтому да, любой обход DPI вернет практически всю старую скорость YouTube, но при этом сделает наших провайдеров чуточку беднее.
Вы сейчас путаете 2 механизма. HBAC относится к sssd и pam-стеку и определяет, может ли тот или иной пользователь выполнить логин на тот или иной клиент домена (т.е. хост, вход на который обслуживает sssd). RBAC определяет тоже самое, только через механизм ролей. RBAC - это надстройка над HBAC. Это не подмена понятий, а реализация одной и той же задачи разными подходами. В курсе говорится именно о классическом HBAC
Есть гораздо более простой путь. Например, водородные топливные ячейки. Технология, разработанная ещё для Апполонов в рамках лунного проекта. Для их производства нужна только вода и дешёвая энергия. Сейчас добычу водорода планируют на базе АЭС, но вполне можно использовать и такой тип генерации энергии, если он хотя-бы вполовину так хорош, как описано в статье. Зачем в транспорте что-то сжигать, вроде углеводородов или спирта? Есть вполне современные способы приведения чего-то в движение и без процесса горения.
А 15 лет назад, после списания последнего шаттла у них не было ни одного КК. Очень относительная характеристика.
Можно, просто для ненулевой классификационной метки действуют ограничения, в частности, на fuse. Подключать шары может только администратор, например, через /etc/fstub, pam_mount или autofs. Понятно, что писать на виндовые шары будет нельзя, у них всегда нулевая классификационная метка.
Вот только не надо тут. Союзы 2024 года совершенно не тоже самое, что Союзы 70-х. Это одноразовый корабль. С каждой новой итерацией его модернизируют, ставят актуальную начинку и электронику. Наглядный пример - Союз МС-20 долетает до МКС за пару часов, когда тому же Дракону нужно 2 суток. По факту , Союз - это КК под формфактор ракетоносителя Союз. Пока мы используем РН Союзы, нет никакого смысла менять КК. А Союз сам по себе очень удачный РН среднего класса, давно отработанный, надёжный как швейцарские часы, а потому очень дешёвый. Себестоимость запуска 60 млн. $, что даже Илону Маску с его возвращаемыми ступенями и не снилось.
Что касается Орла, это КК под формфактор Ангары 5. Это сверхтяжелый РН и под другие задачи. Орел, вообще, проектировался под полет на Луну.
Короче, начало использования Ангары и Орла не отменяет Союзы, их ниша ещё долго будет востребована.
Это не так. pdp-init-fs отрабатывает достаточно быстро.
Что касается бэкапирования, то ничего не затирается, метки не хранятся в parsecfs. Тут важно помнить о том, что метки безопасности файлов хранятся в расширенных атрибутах. Что-бы сохранить метки в бэкапе вы должны просто выполнять копирование с поддержкой расширенных атрибутов на файловые системы с поддержкой расширенных атрибутов. Или архивировать в форматы с поддержкой расширенных атрибутов (например, tar). Я не знаю, как у вас организовано бэкапирование. Для восстановления данных с метками нужно включить режим unsafe_xattr.
Короче, нормально с этим всем можно работать, и, в данном случае, нытье о том, какой отечественный линукс хреновый, только говорит о ваших кривых руках
Минимум 3 созвона в день. Каждый день дейли минимум на час (по 1 на отдел, к которому имею отношение). Сделал что-то прикольное, решил сложную задачу? Будь добр, продемонстрируй и доложись (в формате созвона), напиши статью и доку. Потратил 3 месяца на исследование технологии? Следующие 3 месяца ты будешь читать лекции аналитикам, архитектором и кодерам (В формате созвона). Собственно, а работать когда? Сложно работать, когда 4-6 часов в день - это созвоны (и это даже не у менеджера)
А какое отношение это поделие Oracle имеет к KVM? VirtualBox не использует kvm и qemu, а использует собственные проприетарные модули ядра, что, и это абсолютно логично, работает медленнее и с большим количеством багов.
Другой вопрос, что наличие kvm не позволит вам эмулировать на arm x86 архитектуру, это задача эмулятора, т.е. qemu. А, в общем, никаких проблем с запуском виртуальных машин с arm архитектурой на arm нет.
Очень хорошо описано в readme в репозитории bol-van/zapret на github. О том, что такое dpi, на чем основаны методы обмана, какие есть стратегии и прочее.
Выскажу свое мнение, потому как считаю, что автор не полностью раскрыл тему.
1) Официально вы можете поставить на любую машину (Только со встройкой от Intel, другие видеокарты не поддерживаются) только Chrome OS Flex без нативной поддержки Android. Сам Chrome OS распространяется по модели Apple, т.е. сразу на ноутбуках.
Неофициально есть такой проект на гитхабе, как Chrome Brunch, который позволяет накатить полноценную Chrome OS, а так же включает в себя драйвера wifi, фиксы тачпадов, аудио и разные полезные вещи. Но все так-же поддерживается только встройка от Intel.
Есть ещё китайский форк Fyde OS со своей реализацией поддержки Android через виртуальную машину. Там они запили драйвер AMD, что позволяет ставить ее на APU от красных или дискретное видео от AMD помимо все того же интела.
2) Система, как ни странно, очень удобна как для обычного пользователя, так и для разработчика. Для кого она неудобна - это для геймеров, несмотря на поддержку Android. Казалось бы, есть мобильный гейминг, огромное количество игр, но проблема в том, что ПК - это клавамышь, а андроид-игры заточены на тачпад. Разработчики хоть и пытаются сделать маппер клавамыши на события тачпада (arc input overlay), но пока эта технология ещё в преальфе и нигде не работает. А подобный софт для телефона весь собран на ARM64 и на x86 просто не работает.
3) Очень сильно расширяет возможности системы встроенная ВМ с Debian (сейчас 12-м). Реализована она как WSL в Windows, т.е. просто в виде отдельного приложения терминала, который запускаешь и попадаешь внутрь ВМ. Там можно поставить любые linux-приложения, даже с графическим интерфейсом (он будет нативной проброшен в основной рабочий стол), можно накатить докер и развернуть тот софт, которого не хватает в основной системе, например code-server (visual studio code) и пользоваться им через браузер, да в этой виртуалке можно хоть proxmox накатить и разворачивать там другие виртуалки и строить любые стенды.
4) Чтобы полностью удовлетворить мои потребности в качестве рабочей машинки не хватило только одного - ограниченная поддержка проброса usb внутрь ВМ с Debian. По сути, туда можно пробросить только usb mass storage и adb. Fastboot и предзагрузочные последовательные интерфейсы телефона пробросить уже нельзя, а софта, что-бы с ним работать в самой Chrome OS построенной на базе Gentoo нет. Аналогичная ситуация с созданием разделов и форматированием дисков и флешек (сделать можно только в хост-системе, где нет поддержки многих фс, вроде btrfs).
В итоге, система то крутая, но не без минусов и не всем подойдёт. У меня сейчас на ноуте домашнем стоит (Asus Zenbook 13).
Именно.
=> "Не замещает системный".
Как это проверяется - Читается структура файлов и их хеши с base репозитория астры. После этого эти файлы и хеши сравниваются с текущей инсталляцией дистрибутива. Таким образом, если пакет присутствует в репозитории и он не совпадет по хешам с установленным то будет сразу забракован аттестатором.
И это логично, так как многие пакеты Астры пропатчены для работы с parsec, тот же postgresql, например. Так что вы не можете накатить 25-й докер в Астру или postgresql 17 и не потерять при этом сертификацию. Довольствуйтесь тем, что есть. В этой ветке речь про NUT, который в репозитории присутствует, так что любая новая его версия (с поддержкой snmp v3) ломает хеши.
Если же вы собрали свой пакет, которого нет в репозитории - тогда да, имеете полное право его ставить.
Проблема в том, что установка пакета, присутствующего в репозитории Астры, но из другого источника, другой версии и с другими хешами файлов сразу приводит к несовпадению хешей дистрибутива. На практике это означает, что любой регулятор перестает считать эту систему Aстрой, аттестат и сертификация становятся недействительными.
Проверка хеш-сумм дистрибутива выполняется встроенными средствами Астры с использованием эталонного диска с репозиторием. Это действие явно прописано в любой методичке любого аттестатора.