Прекрасно масштабируется, если у вас Slackware Linux

он, как и генту, не масштабируется вообще.

и так 1000 раз, на разных хостах

и это не костыль? я бы еще понял ответ вроде "у меня все под паппетом". но вообще, при таких масштабах, кастомизация должна быть сведена к минимуму, а лучше чтоб ее вообще не было. потому что проблемы имеют тенденцию очень быстро нарастать и превращаться в общий [CENSORED], при котором надо быстро и без напрягов суметь развернуть все заново с нуля (так было в Цюрихском датацентре гугля несколько лет назад, кстати). И каждая кастомизация это риск помноженный на количество хостов как минимум.

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

Этот параметр будет с негодованием отвергнут. Так что...

Это проблемы кривого софта.

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

Прекрасно масштабируется, если у вас Slackware Linux

# grep "rc\.local" /var/log/{packages,scripts}/*
/var/log/packages/sysvinit-scripts-2.0-noarch-17:etc/rc.d/rc.local.new
/var/log/scripts/sysvinit-scripts-2.0-noarch-17:config etc/rc.d/rc.local.new

После обновления sysvinit-scripts новый rc.local не затрет старый, пока вы не сделаете

# slackpkg new-config

и не ответите на вопрос, что с файлом *.new сделать:

# slackpkg new-config         


Searching for NEW configuration files

Some packages had new configuration files installed.
You have four choices:

    (K)eep the old files and consider .new files later

    (O)verwrite all old files with the new ones. The
       old files will be stored with the suffix .orig

    (R)emove all .new files

    (P)rompt K, O, R selection for every single file
    
What do you want (K/O/R/P)?

Выберете Prompt, и вас спросят по каждому конфигу персонально.

Cruiser78 пишет:

Мне даже удобнее в rc.local свою инициализацию писать

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

Решение элементарно - я одной из первых операций в rc.local поднимаю доступ к файловому хранилищу на glusterfs'е. Там есть общий etc. В котором лежат нужные для этой тыщи компьютеров конфигурационные файлы и скрипты. Если хранилища еще нет - стоим, ждем пока не поднимется. И далее пользуюсь именно этой сетевой шарой для окончания инициализации хоста. Естественно (даже объяснять не стоит), что редактируются конфигурации только в одном месте, а не на всей тыще компьютеров. И там, в общих конфигах, можно даже устроить некую программную разбивку кода в зависимости от `hostname` или иных условий.

В результате имеем тыщу компьютеров с единой системой (вполне согласованной) конфигурационных файлов и скриптов. А теперь расскажи, как это всё можно реализовать в systemd, когда все service-файлы, все юниты должны быть локальными, так как считываются они при запуске этого systemd. Когда еще нет ничего... И как можно удобно актуализировать содержание тыщи локальных конфигов и скриптов? Ну и держать всю эту систему во взаимосогласованном состоянии? Особенно, когда периодически корявый апдейт стирает самодельный юнит...