Pull to refresh

Comments 24

несколько лет назад мой знакомый рассказал мне историю:

под новый офис на чуть меньше 100 гребцов заказали компы, сетевые железки, мониторы, клавомыши, столыстульяпрочее.., ну и пара сервачков, в том числе файлопомойка с большим запасом. И пока это всё руками принесиподайуйдинемешаев расставлялось по местам и подключалось в сеть моим знакомым писались конфиги для того чтобы это всё дело быстро раскатать с PXE и уехать восвояси. по прибытии выяснилось что при закупке забыли самую малость - диски для рабочих станций. ну тоесть компы есть, а дисков в них нет. бяда. но гениальный (и немного упоротый) ум пока ручками ставились сервачки (ldap, freenas, radius, etc) родил решение - все компы грузятся с одного общего сетевого корня (загрузчик в PXE, корень на iscsi на freenas), и имеют общий NFS для /home и несколько шар (разделённых по hostname) для некоторых директорий отличающихся между ПК (например /etc) валяющийся там же на freenas.
из неочевидных преимуществ - экономия на накопителях и централизованное управление доставкой ПО и прочего. из очевидных недостатков - овернагрузка на сеть которая как бы не для того проектировалась (в последствии даже была идея кинуть вторую сеть для выхода в тырнеты а текущую оставить только для нужд работы системы, но в итоге просто докупили накопителей ибо скорость работы и некоторые ограничения NFS в хомяке не нравились разработчикам).

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

быть может это вам тема для следующего псто.

спасибо :) в прошлом веке я уже с этим наигрался. Была такая технология у Novell -- "бездисковые станции". Всё абсолютно также, загрузчик DOS-а по сети, маппирование дисков, стэк ipx (в то время намного легче, проще и быстрее чем tcp/ip), ну и когда сеть вешалась, а она вешалась довольно часто, или тормозила, а на хабах 10baseT это нормально, клиенты считали себя людьми второго сорта и мечтали о полноценных писюках

В современном мире всё по другому, в рабочих станциях вполне может быть больше одной сетевой карты, да и сетёвки есть на 100гиг (привет мелланокс). Я пробовал выносить хомяки пользователей на nfs, с хорошей сетью и файлопомойкой на u.2 дисках большинство пользователей не видят разницы с локальным ssd. Но мой эксперимент не был полноценной бездисковой рабочей станцией.

современный мир разнообразен. Например на некоторых энтерпрайзах, входящих в сотку мировых, до сих пор железо десяти-пятнадцатилетней свежести считается топичком. Цикл закупки нового - порядка 2-х лет от первой бумажки до реального получения. В течение этих двух лет генерация бумаги, обоснования, постоянные запросы коммерческих предложений, и чтоб из реестра... тяжёлая, бесполезная работа. но надо. А взаимодействие между структурными подразделениями это вообще песня - подключение компьютера к сети за неделю -- это норма, отработали все оперативно :). Впрочем всё вышесказанное к линуксу никакого отношения не имеет, за оффтопик можно минусить

К счастью я ещё "не дорос" до кровавого тырпрайза..

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

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

ну эмулятору однорукого бандита вообще врятли нужен шустрый доступ к диску...

да, однозначно рабочий вариант. Но я писал, что у меня особые выкрутасы с безопасностью и сетевое железо в зоне эксплуатационной ответственности связистов. Соответственно дотащить "домен коллизий" в виде различных броадкастов в каждый уголок сети не получится. И держать bootp-сервер в каждом сегменте удовольствие не дешёвое. Если есть -- пользуйтесь, вот даже виндовые сервера удалось задействовать. Ну и про безопасность писал выше, есть там такая аксиома: безопасность обратно пропорциональна удобству. Собственно больше и добавить нечего

Видимо ваши "связисты" и "безопасники" не слышали про DHCP relay и dhcp option 82

Автоматизация развертывания РЕД ОС
Графическая утилита system-config-kickstart

https://redos.red-soft.ru/base/server-configuring/other-utilites/setting-server-pxe/auto-deploy-pxe/

Установка ROSA 2021.1 по kickstart на сервер в ДЦ

https://www.youtube.com/watch?v=l7DfYSA3Bdw
Подробная инструкция здесь: http://wiki.rosalab.ru/ru/index.php/Anaconda
Образ ОС: https://abf.io/platforms/rosa2021.1/products/279

я это знаю, даже пущщал пару раз (в статье тоже есть упоминание). Но не практикую, т.к. всё что можно сделать без мыши должно делаться руками.

В году 2010 или 11 нужно было срочно развернуть Ubuntu на 30 железок.
Использовал UDPcast http://udpcast.linux.lu/index.html
Загрузочная флешка(одна или несколько) с образом http://udpcast.linux.lu/bootmedia.html
Эталонная машина(установлен софт, заведена в домен, сеть по DHCP, пользователь - только админ.)
Все рабочие станции в сети.
С флешки загружается эталонный компьютер в режиме sender. Вытаскиваем флешку.
С этой же флешки(или другой) загружаются все пустые рабочие станции в режиме receiver.
Эталон отправляет UDP-пакетом данные своего винта.
Приёмники получают пакет, записывают его на свои винты и рапортуют об этом передатчику.
Управился за полтора часа.
udpcast есть в дистрибах
https://pkgs.org/search/?q=udpcast

тоже отличный вариант. Вот только если бы "помедленнее" и отдельной статьёй, народ бы в карму отсыпал полными горстями плюсов :) В эпоху импортозамещения такая информация очень ценна

как-то обыгрывается отсутствие подтверждения получения пакета в голом UDP ?

Клиенты-приёмники(receiver) иногда отваливались при заливке. Надо было шаманить с параметрами --start-timeout и --max-bitrate setting

Exiting udp-receiver or reboot machine after a certain amount of time without transfer activity

Udpcast commandline options

Варианты использования - Setting up the bootloader on a media

Не ожидал, что прект еще живой.

У меня была как-то виртуализация на косарика машинок, замухался с рескью и отсутствием пакера, воткнул cobbler. Накидал конфиг, при загрузке с новым мак-адресом, автоматом стартует установка ОС, вторая загрузка стартует с диска с задержкой 5 секунд (можно спокойно успеть переключиться на рескью или перенакат). А ещё через веб-гуй можно указать коблеру следующую загрузку: рескью, накат, загрузка с диска. Естественно сид и кикстарт файлы на все случаи жизни.

а причём тут импортозамещение?

Заголовок взят из статьи, ссылка на которую фигурирует в первом абзаце. Собственно импортозамещение заключается в процедуре масштабной (не 3-4 машинки) замене операционной системы на рабочих станциях пользователей.

Три вопроса:

  1. Зачем флешка, если есть PXE?

  2. Зачем скрипты с установкой ПО и прочими завихрениями, если есть ansible?

  3. Как всем этим управляли в ходе жизненного цикла?

Оффтоп: Безопасность. Гора трудноконтролируемых флешек со всякими интересными конфигами и скриптами. Безопасность.

  1. pxe недоступно, причины как в статье, так и в ответах на комментарии. Вот просто нет и всё - какие ещё варианты?

  2. До ansible ещё дожить надо - разложить сертификаты, юзерга завести, ключи ssh сложить. Либо в какой-нибудь домен ввести. А потом ansible/chief/puppet/zen -- по вкусу.

  3. Не понял вопроса

    Безопасность ничего не имеет против. А вот к сети внимание излишнее - на портах портсекьюрити на один мак, не подключенные порты в дауне, информационные потоки переписаны на бумажку и утверждены генералом и это ещё не всё :) , а флэшка она стандартная установочная, без скриптов. Те, что используются в работе на установленных системах контролируются Касперским.

Занимаемся этим профессионально (перевод арм по контрактам), основная ОС заказчиков - Астра.

Используем две методики для развертывания.

1) Pxe+preceed+salt minion который при первом запуске подтягивает роль на основе имени компьютера, вводит в домен, настраивает софт и сзи, формирует окружение через skel итп - порядка 100 настроек в базовой роли.

2) Готовый образ с установленной ОС, установка клонированием / + создание boot/efi/swap скриптом + рефреш имени пк / uid-ов и солт миниона который дальше аналогично натягивает роль.

Второй способ сильно быстрей - но в больших объемах сложно версионировать, могут вылезать всякие моменты при обновлении пакетов - используем только для удаленных мест.

salt > ansible - так как клиента проще пускать в одно место чем обеспечивать доступность ко всем арм из точки управления. Бонусом наличие event bus - можно строить реакторы на события.

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

Супер. Пиши статью!!!

Не в курсе, как это отлаживать?
Пробую по kickstart развернуть установку, на этапе init он что-то там ждет и вываливается в maintenance mode

Sign up to leave a comment.