Вся морока с опцией 224 как раз для этого. Опция 82 навешивается на нашем сетевом оборудовании. Даже если клиент как-то её подменит, до dhcp-сервера запрос придёт уже с нужным описанием. А дальше клиент идентифицируется через описание порта (которое контролируем мы), возвращает одноразовый токен (что исключает подбор) и только при запросе с ним возвращается уникальный сценарий автоустановки.
Тот же redfish от части указанных проблем позволяет избавиться. Да и в целом всё движется к тому, чтобы разворачивать ос на железе без PXE, DHCP, etc. Предполагается, например, что через API сразу преднастраиваются массивы и раскатывается образ.
Только процесс не быстрый, да и легаси какое-то время всё равно придётся поддерживать.
Ваши варианты ? :) Идеальным вариантом было бы что-то вроде ironic с драйвером redfish (отдельные вещи мы даже используем). Вот только что делать с серверами у которых нет bmc (или не все функции поддерживаются), как те же малинки ?
Речь про модуль rlm_rest ? Да, можно было бы на нём. Но он всё равно предполагает написание какого-то кода. Но создавать собственный модуль и переносить инфраструктуру на новый стек выглядит хуже, чем просто создание собственного модуля.
Да, проблема понятна, и, в общем-то, не новая. Тут единственный вариант - это принудительно "обнулять" платформу перед сдачей клиенту, в этом месте как раз файл recovery.bin становится актуальным.
Если непосредственно на Raspberry Pi 4, то, пожалуй никак. PCI-шина есть, только в данном форм-факторе не выведена. Есть варианты замены usb-контроллера https://mysku.ru/blog/china-stores/84533.html, но тут уже на свой страх и риск.
Поизучал подробнее, выглядит интересно. Хотя всё равно не очень понятно насколько она способна грузиться напрямую по сети, даже не смотря на наличие BIOS. Дальше уже вопрос экономической целесообразоности.
Аппаратно. После установки операционной системы, она начинает грузится с /boot раздела на SD-карте, к которому у клиента есть полный доступ. Поэтому для клиента нет никакой проблемы отредактировать файл config.txt и внести туда активацию нужного оверлея.
Для нас это тоже вопрос. Мы, конечно, износ закладывали, но адекватно судить можно будет только после некоторого опыта эксплуатации.
Маркетинг тоже имелся в виду. Но если бы решалась только эта задача, то не было бы необходимости настолько заморачиваться (насколько будет понятно по следующим статьям, сохраню интригу) с их интеграцией в автоматическую сдачу. С выгодой не так однозначно. В вашем сценарии лучше микро-vps, но если ресурсы виртуалки становятся сопоставимы с "малинкой", то уже не так однозначно.
Одноплатников всяких разных уже много, но вот информацию по поддержке PXE довольно сложно найти. Беглый поиск для ordorid-hc2, так чтобы не пришлось привязываться к SD-карте, ничего внятного по этой теме не показал.
Возможность заблокировать переписывание EEPROM есть, она описана в документации, но по ней же требуется небольшая модификация самой платы, а не только изменение конфигураци.
В крайнем случае всё ещё остаётся возможность восстановления через файл recovery.bin. В статье это явно не обозначено, но EEPROM - это уже вторая стадия, а первая - ROM на SoC (можно свериться по bootflow), что даёт некоторую гарантию, что восстановить всё равно можно.
Да, но нет. Указанный вами блок - использовался в первой партии на 10 штук, ещё когда это всё только тестировалось. Сейчас уже всё монтируется в готовый юнит по 12 штук. В этот раз не успели доделать нормальные фото как это выглядит в уже смонтированном виде, в следующей статье будет.
Цены приведены со страницы, указана цена, если брать лицензию именно у parallels, а не у партнёров. Минимально предлагаемый вариант в этом случае, Plesk Web Host без учёта кол-ва доменов, цена тогда как раз составляет $35 в мес.
У большинства партнёров, похоже, цены на различные варианты как раз будут соответствовать таблице.
Можете привести источник о поддержке powerdns и nsd? Честно говоря, я не нашёл информации о поддержке чего-либо помимо bind. А в практике даже намёка не было, что поддерживается что-то ещё.
Согласен, через mgrctl можно выполнять широкий круг задач, особенно если нужно что-то автоматизировать. Точно также у Plesk существует утилита /usr/local/psa/bin/admin, которая по возможностям не уступает.
Главная причина упоминания консольных утилит весты — позиционирование их использования как одной из особенностей и основного инструмента. Нельзя сказать, что информация о mgrctl или admin отсутствует или как-то скрывается. Но основным инструментом всё равно остаётся веб-интерфейс. А из-за того, что консольные утилиты позиционируются как основной инструмент, параллельно с веб-интерфейсом, не упомянуть о них было невозможно.
"товарищ МАЙОР" же
Вся морока с опцией 224 как раз для этого. Опция 82 навешивается на нашем сетевом оборудовании. Даже если клиент как-то её подменит, до dhcp-сервера запрос придёт уже с нужным описанием. А дальше клиент идентифицируется через описание порта (которое контролируем мы), возвращает одноразовый токен (что исключает подбор) и только при запросе с ним возвращается уникальный сценарий автоустановки.
Тот же redfish от части указанных проблем позволяет избавиться. Да и в целом всё движется к тому, чтобы разворачивать ос на железе без PXE, DHCP, etc. Предполагается, например, что через API сразу преднастраиваются массивы и раскатывается образ.
Только процесс не быстрый, да и легаси какое-то время всё равно придётся поддерживать.
Ваши варианты ? :)
Идеальным вариантом было бы что-то вроде ironic с драйвером redfish (отдельные вещи мы даже используем). Вот только что делать с серверами у которых нет bmc (или не все функции поддерживаются), как те же малинки ?
Выросли не только малинки, хотя на них это очень заметно.
Речь про модуль rlm_rest ? Да, можно было бы на нём. Но он всё равно предполагает написание какого-то кода. Но создавать собственный модуль и переносить инфраструктуру на новый стек выглядит хуже, чем просто создание собственного модуля.
Да, проблема понятна, и, в общем-то, не новая. Тут единственный вариант - это принудительно "обнулять" платформу перед сдачей клиенту, в этом месте как раз файл recovery.bin становится актуальным.
Если непосредственно на Raspberry Pi 4, то, пожалуй никак. PCI-шина есть, только в данном форм-факторе не выведена. Есть варианты замены usb-контроллера https://mysku.ru/blog/china-stores/84533.html, но тут уже на свой страх и риск.
Если действительно интересна эта тема, то смотрите лучше в сторону Raspberry Pi Compute Module 4 https://www.jeffgeerling.com/blog/2020/building-fastest-raspberry-pi-nas-sata-raid. Но пока это всё равно на уровне экспериментов.
закоротили антену
Поизучал подробнее, выглядит интересно. Хотя всё равно не очень понятно насколько она способна грузиться напрямую по сети, даже не смотря на наличие BIOS. Дальше уже вопрос экономической целесообразоности.
Аппаратно. После установки операционной системы, она начинает грузится с /boot раздела на SD-карте, к которому у клиента есть полный доступ. Поэтому для клиента нет никакой проблемы отредактировать файл config.txt и внести туда активацию нужного оверлея.
Для нас это тоже вопрос. Мы, конечно, износ закладывали, но адекватно судить можно будет только после некоторого опыта эксплуатации.
Маркетинг тоже имелся в виду. Но если бы решалась только эта задача, то не было бы необходимости настолько заморачиваться (насколько будет понятно по следующим статьям, сохраню интригу) с их интеграцией в автоматическую сдачу.
С выгодой не так однозначно. В вашем сценарии лучше микро-vps, но если ресурсы виртуалки становятся сопоставимы с "малинкой", то уже не так однозначно.
Всё упирается в хоть какую-то поддержку PXE.
Одноплатников всяких разных уже много, но вот информацию по поддержке PXE довольно сложно найти. Беглый поиск для ordorid-hc2, так чтобы не пришлось привязываться к SD-карте, ничего внятного по этой теме не показал.
Ну, за клиентов сложно говорить, человеческая фантазия иногда преподносит сюрпризы.
Если брать возможный типовой вариант, то "малинка" выглядит неплохой альтернативой виртуалке, только с "монопольным" доступом на все ресурсы железки.
На данный момент нет.
Возможность заблокировать переписывание EEPROM есть, она описана в документации, но по ней же требуется небольшая модификация самой платы, а не только изменение конфигураци.
В крайнем случае всё ещё остаётся возможность восстановления через файл recovery.bin. В статье это явно не обозначено, но EEPROM - это уже вторая стадия, а первая - ROM на SoC (можно свериться по bootflow), что даёт некоторую гарантию, что восстановить всё равно можно.
Да, но нет.
Указанный вами блок - использовался в первой партии на 10 штук, ещё когда это всё только тестировалось. Сейчас уже всё монтируется в готовый юнит по 12 штук. В этот раз не успели доделать нормальные фото как это выглядит в уже смонтированном виде, в следующей статье будет.
Таблицу поправил, спасибо.
У большинства партнёров, похоже, цены на различные варианты как раз будут соответствовать таблице.
Согласен, через mgrctl можно выполнять широкий круг задач, особенно если нужно что-то автоматизировать. Точно также у Plesk существует утилита /usr/local/psa/bin/admin, которая по возможностям не уступает.
Главная причина упоминания консольных утилит весты — позиционирование их использования как одной из особенностей и основного инструмента. Нельзя сказать, что информация о mgrctl или admin отсутствует или как-то скрывается. Но основным инструментом всё равно остаётся веб-интерфейс. А из-за того, что консольные утилиты позиционируются как основной инструмент, параллельно с веб-интерфейсом, не упомянуть о них было невозможно.