Вопросы новичка про установку системы

Крутил я вертел кальку и возникло несколько вопросов . Скорее всего глупых, но мне непонятных.

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

Предположим что в системе чтото поломалось и есть необходимость загрузится с носителя и переустановить
cl-install просит указать параметром раздел куда и успешно и ставится . раздел с профилями нужно монтировать руками ?

Если я делаю обновление с сервера то как я понял эти настройки нормально переносятся . Возможно-ли сделать чтоб обновление у клиента шло в автомате если выложен свежий образ ? если да - то как ?

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

3. Лет пять назад я пользовался Калькой и линуховая рабочая станция умела рисовать при логоне список пользователей домена . От этого отказались , или меня подводит память ?

4 . Есть на сервере unix пользователь test
я хочу чтоб он на всех клиентах попал в группу wheel . как это реализовать ?

5 . Так-же непонятка с самбой . я создал группу в самбе . в группу включил пользователя . Хочу теперь в самбе сделать папку куда будет иметь доступ только эта группа . как ? как раздавать эти права ?

С третьим пунктом разобрался . Нужно комментарии писать при создании пользователей ))

4 . Есть на сервере unix пользователь test
я хочу чтоб он на всех клиентах попал в группу wheel . как это реализовать ?

группа wheel должна быть основной . Не очевидно совершенно .

# На втором разделе как раз удобно иметь резервную копию рабочей системы, чтобы иметь возможность загрузиться если что-то поломалось не используя носитель. Его так же можно использовать и для обновления из образа, в этом случае резервной рабочей копией останется система с которой вы обновляетесь. В файле /etc/calculate/calculate.env прописывается значение переменной cl_install_dev_from, указывающее на раздел, с которого выполнено обновление. Переменная прописывается если вы ставите систему с одного раздела на другой или с носителя, указав два раздела под систему используя авторазметку. В этом случае достаточно просто выполнить cl-install без параметров. В противном случае нужно перечислить разделы. По умолчанию будет форматироваться только раздел подкачки и системный раздел.
# Тут описана процедура обновления из ISO образа. Вы можете скопировать файл бэкапа в другую систему, например в CDS запущенный в виртуалке и проверить.
# Это была особенность kdm не поддерживаемая в других менеджерах входа в сеанс. В данный момент разработка kdm прекращена и в KDE используется sddm. При большом кол-ве сотрудников это уже становится не актуально. Посмотреть список пользователей на любой машине можно выполнив ‘getent passwd’.
# Группа wheel обрабатывается по другому. Вы можете на локальной машине добавить пользователя в группу, чтобы появились права. Изменения настроек ldap на локальной машине поведет к излишней нагрузке на сеть.
# Используя ACL вы можете управлять правами доступа на сервере. Пути, к которым доступ запрещён по умолчанию скрыты от пользователя.

Группа wheel НЕ ДОЛЖНА быть основной. Просто wheel вы через ldap не введете (к сожалению). Придется локально это делать: usermod -a -G wheel

Валерий Скочилов wrote:

Группа wheel НЕ ДОЛЖНА быть основной. Просто wheel вы через ldap не введете (к сожалению). Придется локально это делать: usermod -a -G wheel

А в чем проблема ввести через ldap? Есть замечательный модуль pam_group. Вводишь пользователя test в специфическую группу на ldap сервере, скажем “Testers” и в /etc/security/group.conf указываешь что-то типа:

*;*;%Testers;Al0000-2400;wheel

Таким образом доменный пользователь test получит права группы wheel на всех машинах домена.

Поправка: на всех машинах домена, только если pam_group будет настроен на всех машинах домена, что тривиально для утилит.

я группу wheel привел для примера . Просто это классическая задача для администрирования . На рабочей станции некий ресурс на который нужно назначить права . Разрешаем или запрещаем его группе , а саму группу уже формируем на сервере

Роман Тутов wrote:

я группу wheel привел для примера . Просто это классическая задача для администрирования . На рабочей станции некий ресурс на который нужно назначить права . Разрешаем или запрещаем его группе , а саму группу уже формируем на сервере

Отлично, у меня группа Domain Users получает следующие локальные группы:

 # add domain users to some local groups
*;*;%domain users;Al0000-2400;adm,cdrom,dip,plugdev,lpadmin,sambashare

Так-что, мне кажется я ответил на ваш вопрос.

Речь шла о стандартных средствах CDS. Понятно, что при желании сделать можно все, даже штаны через голову надеть. А надо ли вообще в сети использовать группы Linux? Есть Domain Users, есть Domain Administrators. Этими группами (и любыми другими группами Samba) и надо пользоваться. Впрочем, вольному воля.

Ну как, если у вас клиент CLD, то права этих групп будут использоваться пользователем. Wheel - как раз исключение.

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

Логично обьединить админов в группу и группе на рабочей станции раздать права . Разве нет ? Здесь это как-то по другому решается ? Какой способ кошерный ?

На данный момент такой поддержки нет, потому что wheel созданная на локальной машине конфликтует с wheel, созданным в ldap, если её удалить из groups, то будет работать. Но похоже решение есть. В ldap сервера можно завести группы su и sudo, а в десктопах добавить правила. Если такое решение устраивает, то мы можем добавить поддержку уже в следующую ночную сборку.

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

Валерий Скочилов wrote:

А надо ли вообще в сети использовать группы Linux? Есть Domain Users, есть Domain Administrators. Этими группами (и любыми другими группами Samba) и надо пользоваться.

Область действия модуля pam_group строго локальна, и не влияет на “сеть”. Таким образом, если доменный пользователь хочет получать права sudo на всех компьютерах домена, этот модуль должен быть настроен на всех компьютерах домена, либо сразу в установочном образе, либо через шаблоны утилит.
Вы же не хотите полностью избавиться от linux групп, в пользу доменных? Мне кажется решение должно быть симбиотическим, когда одно дополняет другое. Linux way.

Alexander Tratsevskiy wrote:

В ldap сервера можно завести группы su и sudo, а в десктопах добавить правила. Если такое решение устраивает, то мы можем добавить поддержку уже в следующую ночную сборку.

Верно! Файл /etc/sudoers уже поддерживает в своих правилах доменные группы. Так-что завести специфическую в ldap, и прописать её в sudoers, дело одной команды и одного шаблона. Но нужно ли делать кнопочку - это вопрос. Или я не прав? )

Какую кнопочку?

Alexander Tratsevskiy wrote:

Какую кнопочку?

Мне просто не понятно, что подразумевается под выражением “добавить поддержку”. Все ведь уже поддерживается. Другое дело, что это может быть не очевидно, и не описано в документации Calculate.

Alexander Tratsevskiy wrote:

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

Не понял как это .разверните мысль пожалуйста

Группу wheel нельзя использовать в ldap для su, т.к. она есть в системе и конфликтует. Если ее удалить из /etc/groups, доступ у пользователей с правами wheel прописанными в ldap работать будут. Может это и к лучшему, мы не будем её использовать, а вместо этого создадим две группы sudo и su, прописав их в правилах в CLD в /etc/sudoers и в /etc/pam.d/su. В системе таких групп нет, если понадобится раздать права, то можно будет создать их в ldap и добавить в них администраторов. У нас в компании ПК имеют имена исходя из внутреннего номера телефона (надеюсь когда-нибудь мы перенесем настройки asterisk в утилиты), например pc500. Почему бы в правила не добавить и группу, имя которой будет сздано автоматически исходя из имени машины, например su-pc500 и sudo-pc500, тогда можно очень быстро используя ldap прописывать права администратору к определенной машине, создав такую группу и дав на нее права. Домен можно было бы тоже прописать, может удалив точки, получится что-то типа su-kiev.calculate.ru и sudo-kiev.calculate.ru, тогда командируя администратора в другой офис можно в ldap прописать ему доступ к сети. Что вы на это скажете?

Скажу что нравится . Но я в калькулейте еще новичок , так-что прошу не опираться сильно на мое мнение )))