Что-то самого коробка (серверной стойки) я там и не увидел. А если говорить о плате, то она разработана под абсолютно другие задачи. Отсюда и разница в требованиях по внутренней начинке по сравнению с тем что мне нужно. Платы типа Linklt Smart 7688 делают сотни компаний, что называется — на любой вкус и цвет. А вот если из нее выкинуть все что не нужно для сервера, то она станет либо вполовину меньше, либо иметь в 2 раза больше памяти (что предпочтительней).
Нагляднее разницу в предназначении можно увидеть по Starter Kit. У всех плат подобного рода туда входят разнообразные датчики, сенсоры, сервоприводы и т.д.
А в моем случае Starter Kit это внутренний Ethernet switch, RAID массив из Micro SD, набор серверов и серверная стойка (тот самый спичечный коробок) куда все это добро втыкается.
Одной из задач данной группы серверов может быть и интеллектуальное управление десятками и сотнями устройств, например на основе Linklt Smart 7688, раскиданных по всему дому.
Я пока только начал вникать в мир подобного рада устройств и почему-то пока не удается найти ни готовых изделий серверного типа, ни описаний стандартов на малоразмерные серверные стойки. Неужели для этой цели все используют полноразмерные персоналки/серверные стойки/сервера?
Может кто подскажет нет ли в природе нечто подобного:
плата размером по длине и ширине примерно со спичечный коробок
на борту процессор, память, microSD, Ethernet не менее 1 Gb/s
помимо вышеуказанного не должно быть ничего лишнего, как и торчащих сбоку/сверху/снизу разъемов USB,HDMI и т.д. Общая высота платы порядка 2 mm
разъем находится на торце платы по типу PCI карты для обычного компьютера. Через него подается питание и Ethernet
отдельно есть коробочка, по сути играющая роль серверной стойки, в которую плата втыкается и через нее на плату подается питание и Ethernet
на коробочке ровно 2 внешних разъема: питание и RJ-45
таких плат в стойке должно помещаться скажем штук 5
на одной из плат реализован внутренний Ethernet свич
т.к. на таких серверах отсутствует видео в любом виде, то должна быть реализована поддержка PXE для инсталляции операционки на эти сервера по сети
Другими словами нужна серверная стойка размером со спичечный коробок и набор серверов к ней. На них мог бы разместить например WEB, DNS, DHCP, MySQL, медиа сервера для домашней сети, серверную часть управления освещением ну и всего прочего, что приято относить к «умному дому». На одной из плат можно было бы разместить набор microSD с тем чтобы она из себя изображала RAID массив и была доступна по сети как обычный NAS. Имея пару таких стоек можно было бы организовать отказоустойчивость и балансировку нагрузки на сервисы как на «взрослых» датацентрах.
Все что мне удалось найти либо специализировано на управлении оборудованием, либо пытается из себя изображать очень маленький десктоп с кучей торчащих не нужных мне разъемов. А мне хотелось бы именно серверное исполнение. Для большинства сервисов не нужны выдающиеся характеристики у процессора, поддержка видео им так и вовсе не к чему, не нужны гигабайты памяти и прочие USB и WiFi.
Был бы очень признателен, если бы кто что-нибудь подсказал бы по этой теме.
Бинарники можно и не трогать, тем более что это не совсем легально с юридической точки зрения. В публикации я давал ссылку на другой вариант (если бы я начинал это делать сейчас, то скорее всего пошел бы по этому пути).
Оставляем бинарники Microsoft вместе с их авторскими правами в покое, а вносим правки в ris-linux. Пакет написан на python, поэтому править его легко. Еще он сто лет не обновлялся и можно не опасаться того, что он будет обновляться на новую версию и снова придется думать, куда бы воткнуть свой код в случае его радикальных изменений.
У себя я тоже этот пакет меняю и пометил эти изменения как «Чтобы RIS не мешал инсталляции Win 7». А автор той статьи поступил умнее и у него RIS получив запрос на получение имени файла загрузочной информации Boot\BCD, обрабатывает его и возвращает нужный для данного варианта инсталляции.
У меня этот запрос игнорируется в binlsrv.py:
#p = p + chr(252) + chr(len('boot\\bcd')) + 'boot\\bcd'
а здесь обрабатывается:
mymac=[ord(x) for x in info['mac']]
mymacstr = ':'.join(['%02x' % x for x in mymac])
commandline='/work/bin/getbcdlocation.sh ' + addr[0] + ' ' + mymacstr
f = popen(commandline)
templateinfo = f.readline().rstrip().split(' ')
f.close
bootfile = 'pxelinux.cfg\\pxeboot.com'
bcdpath='pxelinux.cfg\\templates\\' + templateinfo[0] + '\\' + templateinfo[1] + '\\bcd'
hostname = myhostname + (NULL * (64 - len(myhostname)))
p = p + hostname # hostname
bf = bootfile + (NULL * (128 - len(bootfile)))
p = p + bf # Boot File
p = p + MAGIC_COOKIE
p = p + '\x35\x01\x05' # DHCP ACK
p = p + chr(54) + chr(4) + ip2byte(hostip) # Server ID
p = p + chr(97) + chr(len(info['guid'])) + info['guid']
p = p + chr(60) + chr(9) + 'PXEClient'
p = p + chr(252) + chr(len(bcdpath)) + bcdpath
p = p + chr(0xff)
decode_bootp('[S]', p)
#open('out', 'wb').write(p)
if s != -1: s.sendto(p, addr)
ищет по логам tftp сервера из какой папки произошла tftp загрузка wdsnbp.com и в результате RIS возвращает путь к BCD, который должен лежать к той же папке. А в BCD уже путь к нужному wim и т.д.
Логи tftp сервера, сейчас наверно нужно расковыривать при помощи journalctl. А вот с точки зрения Cobbler с его шаблонами по сути ничего не меняется.
Немного нужно еще поменять триггер Cobbler, что бы он вместо того, чтобы хакерски менять бинарники, создавал для каждого профиля отдельную папку и помещал туда оригинальные, неизменные загрузочные файлы Windows.
Это полностью, от начала и до конца автоматическая инсталляция OS по сети с возможностью быстро и гибко реализовывать свои сценарии такой инсталляции. Т.е. стандартная задача, которая возлагается на Install Server.
Прикручивать к роутеру не пробовал. Типичное его применение — иметь набор стандартизованных вариантов инсталляции с возможностью быстро разрабатывать новые и вносить изменения в старые. Например в учебном центре, где каждую неделю на компьютерах все сноситься и заново ставится для другого курса он очень хорош. А курсы могут быть на очень разных OS и версиях этих OS, поэтому в нем крайне не хватает штатной поддержки Windows.
Писал я это в основном для себя.Только раньше то, что хотел не забыть и что может когда-нибудь пригодится обычно оформлял в виде набора скриптов и отправлял сам себе через e-mail. Тут в виду множества задействованных компонент решил снабдить скрипты комментариями. Потом подумал что в таком виде это может пригодится кому-нибудь еще и часть скриптов связанных с инсталляцией для наглядности заменил на картинки.
Так мне и не удалось разобраться со второй DHCP public сетью кластера. То что он каждую секунду проверяет состояние интерфейса — это я понимаю. Но вот зачем он при этом перезапрашивает адрес у DHCP сервера? Ведь с первой DHCP public сетью он этого не делает, и со второй private DHCP не делает. Если кто-то сможет прояснить этот вопрос — буду очень благодарен.
Вот спасибо! Как-то с меня в одном учереждении для допуска потребовали справку с дома скорби не о том, что я там не зарегестрирован, а о том что я по их части абсолютно здоров. Когда я пришел туда с таким запросом, мне сказали что такую справку могут выдать только после месяца госпитализации и наблюдения у них. Тогда я отказался, а вот теперь благодаря Вашему предупреждению думаю, что нужно запланировать время на это. А что? место там тихое, никакой суеты, парковая территория ухоженная, по территории речка журчит, персонал заботливый и соседи душевные. Когда я тогда отказывался от их предложения, то делал это прям-таки с болью у душе (что еще раз доказывает Вашу правоту).
А если серьезно, то воспроизвести сложную систему простыми средствами с нужной степенью правдоподобия бывает довольно непросто. Особенно когда разбираешься с какой-нибудь сбойной ситуацией. Ковыряться в системе, в которой произошел сбой могут дать только если она совсем загнулась. Если же это не так и она еще как-то может обслуживать пользователей, то приходится быстро городить себе стендик из каких попало подручных материалов и воспроизводить ситуацию с максимальным количеством деталей…
Нагляднее разницу в предназначении можно увидеть по Starter Kit. У всех плат подобного рода туда входят разнообразные датчики, сенсоры, сервоприводы и т.д.
А в моем случае Starter Kit это внутренний Ethernet switch, RAID массив из Micro SD, набор серверов и серверная стойка (тот самый спичечный коробок) куда все это добро втыкается.
Одной из задач данной группы серверов может быть и интеллектуальное управление десятками и сотнями устройств, например на основе Linklt Smart 7688, раскиданных по всему дому.
Я пока только начал вникать в мир подобного рада устройств и почему-то пока не удается найти ни готовых изделий серверного типа, ни описаний стандартов на малоразмерные серверные стойки. Неужели для этой цели все используют полноразмерные персоналки/серверные стойки/сервера?
Другими словами нужна серверная стойка размером со спичечный коробок и набор серверов к ней. На них мог бы разместить например WEB, DNS, DHCP, MySQL, медиа сервера для домашней сети, серверную часть управления освещением ну и всего прочего, что приято относить к «умному дому». На одной из плат можно было бы разместить набор microSD с тем чтобы она из себя изображала RAID массив и была доступна по сети как обычный NAS. Имея пару таких стоек можно было бы организовать отказоустойчивость и балансировку нагрузки на сервисы как на «взрослых» датацентрах.
Все что мне удалось найти либо специализировано на управлении оборудованием, либо пытается из себя изображать очень маленький десктоп с кучей торчащих не нужных мне разъемов. А мне хотелось бы именно серверное исполнение. Для большинства сервисов не нужны выдающиеся характеристики у процессора, поддержка видео им так и вовсе не к чему, не нужны гигабайты памяти и прочие USB и WiFi.
Был бы очень признателен, если бы кто что-нибудь подсказал бы по этой теме.
Оставляем бинарники Microsoft вместе с их авторскими правами в покое, а вносим правки в ris-linux. Пакет написан на python, поэтому править его легко. Еще он сто лет не обновлялся и можно не опасаться того, что он будет обновляться на новую версию и снова придется думать, куда бы воткнуть свой код в случае его радикальных изменений.
У себя я тоже этот пакет меняю и пометил эти изменения как «Чтобы RIS не мешал инсталляции Win 7». А автор той статьи поступил умнее и у него RIS получив запрос на получение имени файла загрузочной информации Boot\BCD, обрабатывает его и возвращает нужный для данного варианта инсталляции.
У меня этот запрос игнорируется в binlsrv.py:
а здесь обрабатывается:
Скрипт getbcdlocation.sh:
ищет по логам tftp сервера из какой папки произошла tftp загрузка wdsnbp.com и в результате RIS возвращает путь к BCD, который должен лежать к той же папке. А в BCD уже путь к нужному wim и т.д.
Логи tftp сервера, сейчас наверно нужно расковыривать при помощи journalctl. А вот с точки зрения Cobbler с его шаблонами по сути ничего не меняется.
Немного нужно еще поменять триггер Cobbler, что бы он вместо того, чтобы хакерски менять бинарники, создавал для каждого профиля отдельную папку и помещал туда оригинальные, неизменные загрузочные файлы Windows.
Может быть и дойдут руки до таких изменений.
Так мне и не удалось разобраться со второй DHCP public сетью кластера. То что он каждую секунду проверяет состояние интерфейса — это я понимаю. Но вот зачем он при этом перезапрашивает адрес у DHCP сервера? Ведь с первой DHCP public сетью он этого не делает, и со второй private DHCP не делает. Если кто-то сможет прояснить этот вопрос — буду очень благодарен.
А если серьезно, то воспроизвести сложную систему простыми средствами с нужной степенью правдоподобия бывает довольно непросто. Особенно когда разбираешься с какой-нибудь сбойной ситуацией. Ковыряться в системе, в которой произошел сбой могут дать только если она совсем загнулась. Если же это не так и она еще как-то может обслуживать пользователей, то приходится быстро городить себе стендик из каких попало подручных материалов и воспроизводить ситуацию с максимальным количеством деталей…