Жаль что мы с Вами не в одном городе находимся - попросил-бы выполнить описанный Вами алгоритм на “бис” на базе CDS 10.0 Слишком много в вашем описании пропущено - и загрузчик на ДВА раздела писать нужно, и не забыть модуль raid1 подгрузить, и mdraid запустить и помочь при первой загрузке initrd, а то не сгенерится …
Единственное что пропустил - установка загрузчика на два раздела. Модуль raid1 у меня на CDS 10.0 подгрузился ЕМНИМ сам, а initrd трогать тоже не надо - только нужно прописать domdadm.
А что будет при обновлении системы - так даже думать не хочу… Так что на месте разработчиков я бы просто вписал данный пункт в “план полета”
Та ничего страшного не будет
Хотя в “план полета” таки не помешало бы, но далеко не в первую очередь.
Хорошо, только чуть освобожусь. Сейчас просто допиливаю до рабочего состояния CLD с Gnome (раз вы не успели ) и тестирую его в рабочей обстановке.
Отлично, это тоже можно будет описать
Что следует включить в app-misc/cldg-meta, а также профиль calculate/desktop/CLDG/amd64.
Т.к. на подбор софта и настройки уйдет прилично времени.
Сетевые ресурсы, монтируемые на клиента — не могу на 100% согласится с существующим решением. Объясню по какой причине - имея немаленький опыт эксплуатации “нехорошего ПО” (типа 1С 7.7) на SAMBA-серверах вывел для себя раз и навсегда правило - есть ПО, для которого самые лучшие право доступа на шару - это rwx:rwx:rwx. Да, секьюрность *nix воет волком от такого решения, но только в таком случае не приходится заниматься поиском блох от некоторых M$-воятелей.
Что предлагается в данном случае? - выставить в samba.conf все security и mask на /var/calculate/server-data/samba/share в 0777 и рулить дальше через ACL ? У меня только два вопроса к разработчикам - первый - все ли нюансы работы ACL они учли; и второй - что будет с безопасностью наших сетевых шар, если они не учли все возможные комбинации в ответе на вопрос первый Потому как я администратор вменяемый, и на остальных samba-ресурсах мне нужна НОРМАЛЬНАЯ реализация разграничения прав доступа, не зависящая от того, “кто-чем-и-как” туда ломится. А это, как показывает практика, получается только на связке прав с samba.conf и прав ФС (пусть даже с ACL). К сожалению, в нынешней реализации ACL на ФС не покрывает все потребности при контроле прав доступа к расшаренным ресурсам …
Мне видится более правильным и грамотным следующее решение - не ограничивать количество шар в samba, которые участвуют в работе Calculate, а добавить, например /etc/calculate/calculate.mnt, в котором прописывать - какие ресурсы samba и в какие точки монтируются на клиенте …
Мне видится более правильным и грамотным следующее решение - не ограничивать количество шар в samba, которые участвуют в работе Calculate, а добавить, например /etc/calculate/calculate.mnt, в котором прописывать - какие ресурсы samba и в какие точки монтируются на клиенте …
Так как здесь могут быть разные опции монтирования, проще добавить свой скрипт монтирования при входе в сеанс.
Файл /usr/share/config/kdm/kdmrc:
… можно конечно итак, вот только возникает несколько подводных камней …
1 - а как быть с идеологией централизованности Calculate ? - получается на каждом клиенте все “по своему”
2 - а как для этого скрипта выдрать логин/пас пользователя, который в настоящее время проходит авторизацию - нам ведь желательно монтировать от его имени ?
… не знаю, ИМХО единый конфигурационный файлик, в котором прописано какие шары в какие точки и с какими опциями монтировать - был бы оптимальнее. (можно еще “довернуть” его до структуры “пользователь-шары-точки_монтирования-опции_монтирования”) … Распарсить подобное утилитами Calculate не кажется проблемой, а гибкость системы существенно возросла-бы - с одной стороны единое место, где мы управляем монтированием, а с другой ушли-бы от существующего ограничения на количество монтируемых шар …
Подобные вещи должны выполняться plugin-ами или всевозможными расширениями. Именно над этим мы сейчас и работаем - документацией и переработкой кода.
В момент выполнения скрипта kdm, а также на протяжении работы пользователя, его пароль известен root-у и хранится в ключах ядра. Благодаря этому можно [[keyexec|выполнять Windows приложения]] с терминального сервера без ввода пароля. Извлечь пароль из ядра можно так:
И "да и “нет” - со старта заходим первым пользователем - да, keyctl list @us как и говорили - выдает нам имя нашего пользователя, но! система то у нас многопользовательская - не перезагружаясь завершаем сеанс текущего пользователя и логинимся под другим. И вывод все той-же команды уже выглядит как
спасибо за подробное описание
… только вижу разное поведение в CLD и CLDX - добавляю в скрипт /usr/share/calculate/xdm/cmd_login строку:
mount -v -t cifs -o user=$USER,iocharset=utf8,users,owner //server/new.share /media/new.share
в CLD - шара нормально монтируется от имени пользователя, а в CLDX - система на моменте монтирования просто зависает… Но то-же самое, только с явным указанием пользователя/пароля - работает и в CLD и в CLDX.
небольшое уточнение
/usr/share/calculate/xdm/login - скрипт выполняемый при входе пользователя
/usr/share/calculate/xdm/cmd_login - скрипт проверки на ошибки (если есть файл ошибок то выходим)
сорри, описался - естественно добавлял в /usr/share/calculate/xdm/login, перед строкой exit0. Такое ощущение, что в CLDX ядро в момент выполнения этого скрипта не знает (не захешело) пароль пользователя …