> С одной стороны вы подумали немного над изложенными мной идеями и даже
> заметили некоторые недостатки, но тем не менее не поняли что предложенное
> составляет цельную системуBMC тоже являет собой цельную систему. Только еще это может быть с сильно меньшими допущениями относительно свойств железок. И при нормальном подходе (опенсорсная доверяемая фирмвара) ничем таким не плохо. Всякие гуглы и фэйсбуки подтвердят.
А фирма AMI как всегда проприетарный "благодетель", который "решает проблемы" для тех сам вон так не может, с характерным AMI_SW в результате. И куда их проприетарное нечто ни сунь, одно и то же получится.
> Сетевые карты по стандарту умеют в защищённую передачу пакетов,
По какому еще стандарту? Чтоб вот прямо произвольную сетевку?
> а хорошие серверные карты ещё и в их анализ небольшой глубины.
> Не думаю что добавление проверки цифровой подписи пакета WoLsec их сильно усложнит.
Я не понимаю чем фирмварь проца на сетевке будет лучше фирмвари BMC кроме того что навязана конкретная архитектура. Видимо, чтобы у имплементеров было меньше гибкости в том как это делать. Почему это станет секурнее - черт знает. И нет, делать _железку_ для счета RSA или даже эллиптики скорее всего не станут. Нагрузят на вспомогательный сервисный проц который в чипе уже был, допишут фирмвару еше пожирнее, добавив еще и это. Чтобы чип не переделывать, юзанув существующие, и не увеличивать его площадь. Операция же редкая. Часто вы на BMC логинитесь?
> Обычай блокировать экзотические пакеты связан с отсутствием в ранних протоколах и службах
> сетевой безопасности как понятия, причин блокировать пакеты секюрных протоколов нет,
Вы пойдете по всему глобусу объяснять всем бизнесам, транзитным роутерам и чему там еще какие они нехорошие и что дескать фаеры, наты или что там у них надо перенастроить? Без этого вон тот хмырь внезапно обнаружит что доступа - нет. Именно в тот момент когда он потребуется. И стало быть - ехать в ДЦ.
> могли бы заметить что чтобы WoLsec включился в сетевую карту надо
> заливать сертификат).
Весь этот WoLsec удобнее всего имплементить как BMC смотрящий на траф в фоне и - врубающий основную систему. По произвольным программируемым критериям. А то что фирмвар мутный и кривой, так он и у этих такой же будет. Даже хуже - BMC бывают и открытые, а ЭТО будет confidential proprietary на уровне фирмвари.
> Во вторых админы датацентра знают какие службы и пакеты используются для удалённого
> администрирования и будут разрешать доступ пакетов WoLsec
Осталось еще все системы по пути которые процессят пакеты убедить. Потому что если оно заткнется на каком-то корпоративном нате, домашнем роутере, фаере или чем - таки это поездка в ДЦ. Вы же не попросите скажем вон того сотового оператора перенастроить для лично вас их NAT в темпе вальса? Значит доступа не будет - опа, едем в ДЦ.
> Если вы внимательно читали то ядро и initrd грузятся по FTPs с
> удалённого сервера, и ни что не мешает так же грузить и
> menu.lst в котором вы можете прописать всё что вам нужно.
В этом месте возникают вопросы наличия этого сервера, его доступности, кто его содержит и проч. Это +1 точка отказа, а система получается не самодостаточная. И в комплект к серверу надо докупать другой сервер, после чего возникает вопрос - "а что если он помрет?". Сейчас некоторые BMC - тот же линух только зашитый в флешке, что как-то более удачно чем вгрузка по сети. А то что проприетарщики опять все поняли по своему - они и вон то поймут так же. Даже хуже имхо.
> Но вы правы, это может быть удобно админам кластеров и ДЦ, но
> не удобно владельцам локалхостов в арендованных у ДЦ ячейках.
Кроме того я не понимаю как обеспечивается живость сервера сервирующего initrd и проч. А если он помрет, целая толпа серверов курнет бамбук пока его не заменят? Конечно можно redundancy нарулить, но в этом месте мы начинаем хотеть по сути целую ОС в качестве загрузочной фирмвары... и почему она будет лучше чем то что сейчас? Предпосылки какие?
> Если GRUB заработал то сложно представить обстоятельства при которых он вдруг перестанет
> работать, особенно если он стоит на отдельном носителе.
Да мало ли, апдейт на него приехал - и оказался кривой. А поскольку он тоже мини-операционка, в нем вулны бывают или неприятные баги. И я могу вспомнить штуки три апдейтов на оный за последнее время. И среди кучи машин, на 1 таки пошло кое-что не так и оно таки перестало грузиться. Это наполовину мой факап - конфиг не failsafe был. Но от этого ехать в ДЦ нифига не радостнее.
> Но вы правы, тут я не последователен, протоколы DNSsec,FTPs и DHCPsec должны
> быть интегрированы в БИОС(сейчас для удалённой загрузки используются их несекюрные версии,
> причём DNS в БИОС нет вообще)
DNSSec вообще фуфельный (RSA-1024 врядли долго осталось). FTPs это вообще нечто мало кем используемое, он вообще сочетает минусы всех мыслимых технологий и застрянет на первом же фаере и нате. Да и DHCPsec это нечто экзотическое. Сразу +20 к граблям администрирования. Оно админам надо?
>>И чем это будет отличаться от - внезапно - BMC?
> Тем что этот блок будут ставить только те, кому для контроля сервера
> по какой-то причине нужен аппаратный отладчик, остальным имхо хватит и удалённого
> включения с перезапуском по WoLsec.
Как вы уже поняли будет соблазн интегрировать все в фирмвару сетевки или чего там и получится тот же BMC только похабнее. Чем WoL вообще помогает от "система не грузится" черт его знает.
> Но вы правы, я предложил не самое оптимальное решение и этот вопрос
> натолкнул на правильное решение, которое в своё время и следовало сделать.
Как вариант - нечто типа coreboot/uboot с (относительно) неизменным Linux в системной флехе и вот он может грузить ... в принципе что угодно как угодно. Даже и покруче GRUB. В принципе такой сетап и без BMC может обойтись и довольно сложно убить. Но апдейты и на это иногда надо будет, с тем же риском кирпича. И таки low power проц способный и включить основную систему и перекатать образ оси независимо от живости основного - по своему гибкое и красивое решение. С минимумом ограничений. Единственный реальный критерий с которым затык - опенсорсность фирмвары, пожалуй. Вон те, толстые, так себе и сделали. И это неплохо для них работает. Просто они не продают свои сервера на публику, они для себя это все.
> Я отлично понимаю что такое устройство по сути есть внешний BMC, про
> главный недостаток которого вы не указали: ему нужен дополнительный порт, что
> и стало причиной столь лёгкого внедрения BMC интегрированных в компьютер.
Ну как бы если есть внешнее устройство - всегда возникает идея сэмулировать его функции тем что уже было. Результат тот же но дешевле и сердитее.
> На сетевой карте просто надо сделать отдельный порт на который отправлять все
> предназначенные для BMC паеты, для отличия которых помечать IP пакет особым образом.
Это к сожалению накладывает еще больше лимитов на архитектуру железа. А вон то вообще никак особо не лимитирует структуру основной системы.
> 1. WoLsec не нужен, просто на сетевой карте делается отдельный внутрикорпусный порт
> на который отправляются все пакеты имеющие пометку BMC и дублируются пакеты
> DNS,DHCP и их секюрных версий.
Собссно у BMC часто и есть отдельный порт, по примерно тем же соображениям. Зачем ему на пути основного трафика стоять вообще хз. Хотя из экономии соблазнительно через 1 порт все и вся делать, так получается какой-нибудь гаденыш типа ME и vPro/AMT... основная проблема в том что это напрочь прориетарная фирмвара, от интеля, жестко подписаная их ключами и незаменяемая. А доверять тем господам под дулом пистолета^W^W ключа в efuses - такое себе.
> 2. А там пользователь сам решает какой BMC ему использовать, такой что
> умеет только нажимать кнопки Powe/Reset и поддержку последовательного COM порта для
> взаимодействия с БИОСом.
Собссно и сейчас никто не запрещает что-то такое делать. Вон та идея похожа на BMC только с кучей допущений и почему-то завязаный на именно сетевку. Для менеджмента много трафа не надо, так что быть частью крутой сетевки ему вообще опционально.
> Или такой что ещё умеет в эмуляцию монитора,клавиатуры и блюрея.
Это как-то сложно уж очень. И зачем блюрей? Можно просто usb mass storage device + usb hid. Дофига одноплатниов на линухе такое на раз изобразит.
> Или такой что имеет на борту софт для отладки программ и оборудования
> и умеет в шины JTAG, SMBus, IPMI и что там есть ещё.
Любой одноплатник с линем. И получится BMC очередной :)
> Или не использовать BMC вообще(например сервер размещён не в ДЦ, а локально)
Вообще вы меня навели на мысль: загрущчик не трогать, им стартить "readonly" linux а оттуда уже что угодно и как угодно наруливать а потом kexec(). В принципе даже есть похожие штуки. Но для сохранности ЭТОМУ лучше таки в флешке жить, а не в основном стораже. На всякий случай.
> 3. Поддержка удалённой загрузки в БИОС не нужна так как соответствующий функционал
> делается соответствующим внешним BMC, всё что должен уметь БИОС это только
> грузить GRUB с отдельного небольшого накопителя(возможно эмулируемого BMC).
Если уж эмулировать накопитель можно с него не BIOS а что поприличнее бутануть типа линуха небольшого. А для мазохистов - BMC может и JTAG в принципе сносно GPIO изобразить но подывать через него x86 вы точно не захотите. Дебажнуть совсем непонятки еще может быть, но не более.
> Всё получается максимально просто, не дорого, и разделённым на понятные и подбираемые
> под нужды пользователя функциональные блоки.
На самом деле BMC открытых есть - просто вон тем неймется, как же это без них и их проприетари то :)
> И вот если бы так сделали то это было бы нормально и
> вызывало минимум вопросов и обвинений в создании бекдоров, так как не
> давало возможностей для их создания и навязывания.
Вообще ряд похожих штук есть. Но есть и вот сабж, с каким-то самоназваным "стандартом" чтобы под его эгидой проприетару всучивать.
