LINUX.ORG.RU
ФорумAdmin

вопрос по бесдисковым станциям.


1

1

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

в голову пришла еще одна идея, нужен совет или просто мнение или хотя бы размышление на тему:

В общем есть один центральный сервер PXE и есть несколько удаленных офисов, каждый офис имеет один gateway, с внутренним диапазоном 192.168.x.x/26, планируется, что в каждой подсети будет пордка 20 - 50 станций, грузиться они будут все в примерно одно время, каждое утро в 7 - 8 утра, каждая грузит c гейта файл undionly.kpxe, дальше грузит vmlinuz и initrd, initrd, в свою очередь, загружает образ squashfs, который вести примерно 40 - 50МБ, трафик на голове получается примерно 10 - 20ГБ при наличии 100 удаленных офисов, если каждый офис будет получать один образ squashfs multicas_ом, то это как минимум в 50 раз меньше, то есть примерно 500МБ каждое утро, может и вообще всего 50 - 100 мб, только понадобится жестко синхронизировать все офисы

Вот собственно что меня интересует, можно ли каким-нибудь образом иметь нечто, что может вышеописанное, чтобы получать образ squashfs не unicast_ом, а multicas_ом??? Какие есть идеи??? Это вообще реально??? представить, как это может функционировать, в теории можно? есть ли нечто подходящее по функционалу на практике?

★★★

А не лучше будет выделить в удаленных офисах по машинке, которые будут локально отдавать образы?

xpahos ★★★★★
()

Реально. Только что будет если твой сервер pxe сдохнет?
Какие анальные кары тебя ждут от руководства?

kerneliq ★★★★★
()
Ответ на: комментарий от IvanR

Реально. Только что будет если твой сервер pxe сдохнет?

Какие анальные кары тебя ждут от руководства?

там будет пара резервных, сдохнуть все может

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

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

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

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

IvanR ★★★
() автор топика
Ответ на: комментарий от kerneliq

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

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

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

при наличии шифрованного раздела, где все будет лежать какие еще могут быть проблемы?

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

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

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

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

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

xpahos ★★★★★
()
Ответ на: комментарий от IvanR

А если на удаленных офисах эта машина будет сама после загрузки стягивать образ из центра к себе в рамдиск, а потом раздавать внутри локалки?

thesis ★★★★★
()

> уже решили централизовано грузить

получать образ squashfs не unicast_ом, а multicas_ом?

Atftp support multicast transfer. This feature allow the server to send a file to many clients at once. There is two ways of doing multicast TFTP. One is documented in RFC2090 and the other is known as MTFTP and documented in Intel's PXE specification. Atftp support both protocol.

Вам точно нужен мультикаст? Вот здесь http://forum.ipxe.org/archive/index.php/thread-3252.html недавно обсуждалось: In general, I would recommend using an efficient unicast protocol such as HTTP instead of multicast, unless you are planning to boot thousands of nodes simultaneously.

в общем это не очень безопасно

безопасно, будет же все внутри openvpn

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

openvpn доставкой занимается, потерь внутри vpn быть не должно.

Идеальный вариант - роутер + тупой свич + станции.

На роутер openvpn и всё для Chainloading iPXE http://ipxe.org/howto/chainloading . На станции после загрузки iPXE, мультикастом по mtftp забирать с atftp (который один и главный) всё остальное. На роутере разрешить и смаршрутизировать мультикаст трафик в openvpn.

Должно работать, но будет ли это юзабельно? Сомнения в скорость внутри openvpn, справится ли роутер с нагрузкой openvpn.

anonymous
()

это настолько глупо, что даже не смешно

redixin ★★★★
()
Последнее исправление: redixin (всего исправлений: 1)
Ответ на: комментарий от IvanR

в офисе не хочется вообще ничего размещать

А «бездисковые станции» на что? Добавь туда tftp-сервер, и пусть раздают друг другу.

DonkeyHot ★★★★★
()

ИМХО

Простите, но грузить все сателлиты (офисы) с 1го головного сервера - крайне ненадежно. Представляете, что будет, если в одном из офисов упадет интернет, скажем по вине провайдера. Все ваши 30-50 сотрудников не смогут даже войти на свой компьютер, чтобы просто поиграть в косынку, ожидая пока все починят, не говоря уже о том, что какая-то часть работы может быть выполнена и без интернета. Страшно представить даже, 50 человек пришедших на работу, и у всех комп не грузится.

electr0n1q
()
Ответ на: ИМХО от electr0n1q

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

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

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

IvanR ★★★
() автор топика

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

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

в офисе сейчас стоит tp-link с openwrt, в него не уместится 35-мегабайтовый сквошфс. В общем я попробую с torrent в initrd диске, может что-то получится.

IvanR ★★★
() автор топика

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

Само собой напрашивается два варианта.

1. Кеширование. Можно поставить кеширующий сервер. Если получать образ по HTTP, то внезапно, самый тривиальный squid. Абсолютно ничто не мешает тебе сделать его тоже бездисковым.

Можно сделать индивидуальный кеш для каждого компа.

Можно совместить оба подхода.

Сильная сторона в том, что кеш не является «единой точкой отказа». Т.е. офис в худшем случае будет медленно загружаться.

2. P2P. В твоем случае все чрезвычайно просто. а) загрузившийся комп регистрируется на центральном сервере (HTTPS GET по крону, например); б) сервер понимает такую штуку как «локальность» и умеет в соответствии с ней выдавать список адресов, откуда можно стянуть образ.

Сделать сервак можно с помощью связки nginx и CouchDB. А вот «локальность» - понятие крайне интересное. В самая простая метрика, которая приходит на ум - номер сети IP. Но вся проблема в том, что она слишком «простая».

BitTorrent все-равно потребует написание своего клиента. Да и трекер потребуется хорошенько пилить напильником.

Слабой стороной такого подхода является его полная недетерминированность. По-определению.

Macil ★★★★★
()

Насчет безопасности вей этой бадяги - тоже интересно.

Для начала нужно уяснить понятие «root of trust». Это такое место в схеме, где мы не можем проверить факт компрометации машины, и принимаем исходное состояние «на веру». Способов «задвижки» root of trust без привлечения дополнительного оборудования я вижу два:

1. TPM. Очень жалко, что сей девайс ставят далеко не всегда. Уже чего про него только не городили сгоряча... Но, чисто технически это самый обычный ICCID, правда в отличие от ISO'шных товарищей страдающий терминальной стадией NIH'а. Документация доступна, доступны, также, различные программные примитивы для работы с ним.

2. Гипервизоры. Гипервизор - это крайне страшная штука. И например, аппаратная поддержка оных во всех современных процессорах (даже в ARM) пугает меня больше, чем все инициативы TCG и Intel вместе взятые.

Стратегия проста и непритязательна. а) Грузимся из root-of-trust; б) овладеваем целевым устройством. Тема применения гипервизора (Xen) на интеловских машинах с целью обеспечения безопасности, широко и всесторонне раскрыта в CubesOS Ж. Рутковской сотоварищи.

Примитивнейшим root-of-trust является флешка внутри опечатанного корпуса.

«Готового решения», скорее всего, ты не найдешь. Но и не то чтобы нужно.

Macil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.