Centos для новичка, простые вопросы.

"Vascom" написал:

Плохо без systemd, да.

Будто тут он что-то сделает лучше, ога. Глупости.
Параметр _netdev, который уже поминали здесь, решает проблему. При указании этого параметра в соответствующем поле (поле параметров), init вызывает mount, когда сеть поднимется, не раньше и не позже.
Пруф:

man mount(8)
...
_netdev
The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).

_netdev
               Файловая система, находящаяся на устройстве, требующая доступа в сеть (используется для предупреждения попыток системы примонтировать эту файловую систему пока сеть не будет включена).

Лукавите, господа системдевцы.

"Vascom" написал:

rc.local вроде одним из первых грузится и не обращает внимания ни на что другое.

Опять враки. Грузится, как уже сказали, последним, и выполняет в точности то, что в нем записано. Это же скрипт, а не глупый юнит systemd.

"Cruiser78" написал:

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

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

yars написал:

[quote="Vascom"]rc.local вроде одним из первых грузится и не обращает внимания ни на что другое.

Опять враки. Грузится, как уже сказали, последним, и выполняет в точности то, что в нем записано. Это же скрипт, а не глупый юнит systemd.[/quote]
Признаю, ошибался.
Юнит системд может быть глупым, только если его глупый человек написал.

yars написал:

Параметр _netdev, который уже поминали здесь, решает проблему. При указании этого параметра в соответствующем поле (поле параметров), init вызывает mount, когда сеть поднимется, не раньше и не позже.

Да, это справедливо, но при одном условии. Что соответствующий mount знает про этот параметр. А именно - попробуйте в том же центосе применить _netdev к томам glusterfs. Этот параметр будет с негодованием отвергнут. Так что...

dyasny написал:

[quote="Cruiser78"]Мне даже удобнее в rc.local свою инициализацию писать

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

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

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

"dyasny" написал:

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

Прекрасно масштабируется, если у вас 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" написал:

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

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

"yars" написал:

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

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

"yars" написал:

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

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

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

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

Предлагаю завершить обсуждение, раз вопрос решён.

Согласен, а то открыл волну волнений и споров

В общем опять я)) Такая проблема: не могу дать права на сетевой ресурс пользователю, ставил и 777 на папку и подпапку. Давал юзверу полные права и вносил его в группу root, пытался сделать его владельцем. В общем в папке все, кроме нужной папки, работает. Там висит значок замка и все(( Ну эта же и папка есть сетевой диск((( Помогите пожалуйста ламеру!

NFS?

Прости, не понял..
Шара от сервера 2012, если это имел ввиду.

Ну что за "сетевой ресурс"?
Что за шара? samba, nfs или ещё что-то?

Ну...обычный сетевой диск от Майкрософт, думаю nfs

Если от микрософта, то самба.
Создавай отдельную тему с этим вопросом в соответствующем разделе форума Администрирование и настройка сетей.

Спс!

Пришлось опять сюда писать. При монтировании диска, пользователь ни чего не может сделать((( Монтирование диска осуществляется только с командой su иначе он будет говорить, что не установленна mount.cifs ..

Это не дистрибутивоспецифичный вопрос. Создай новую тему в разделе по администрированию и настройке сетей.