Приветствую!
Имею шару на самбе, на которой лежит база не к ночи помянутой 1С. С этой шарой активно работают по локалке плюс некоторое количество терминальных пользователей - вайн@, nx. Последнее время повадились отдельные ответственные юзеры совершать там тягомотную операцию ерзания точкой актуальности. Да еще несколько раз подряд. Чтоб вы знали, в особо клинических случаях на перепроведение по сети уходит до сорока минут. И взмолились сотрудники ответственные и без-таковые: "Хотим быстрее!"
Это была мотивационная часть. Решением будет запуск 1С в терминальной сессии, где ее ИБ будет запускаться не с шары, а непосредственно с каталога файловой системы сервера. Организовать запуск - как два байта переслать. Но встает два вопроса. Первый - разогнать всех пользователей - решаем и средствами 1С. Со вторым сложнее. Надо сделать, чтобы в шару никто больше не сунулся, а то база пойдет лесом. Причем полностью самбу останавливать нельзя.
net SHARE DELETE не работает (наверное от того, что шара прописана в smb.conf).
Пока приходит на ум только правка в авт. режиме smb.conf с последующим service smb reload. Но как-то это некрасиво.
Кто нибудь решал подобные задачи? acl???
Регулировка доступа к smb-шарам на лету. (Начал танцевать самбу, продолжил пляской святого Вита)
Модераторы: SLEDopit, Модераторы разделов
-
dimbor
- Ведущий рубрики
- Сообщения: 1572
- Статус: Подвинутый участник
-
Bluetooth
- Сообщения: 4395
- Статус: Блюзовый
- ОС: Debian Squeeze amd64
Re: Регулировка доступа к smb-шарам на лету.
dimbor писал(а): ↑23.10.2011 19:55Приветствую!
Имею шару на самбе, на которой лежит база не к ночи помянутой 1С. С этой шарой активно работают по локалке плюс некоторое количество терминальных пользователей - вайн@, nx. Последнее время повадились отдельные ответственные юзеры совершать там тягомотную операцию ерзания точкой актуальности. Да еще несколько раз подряд. Чтоб вы знали, в особо клинических случаях на перепроведение по сети уходит до сорока минут. И взмолились сотрудники ответственные и без-таковые: "Хотим быстрее!"
Это была мотивационная часть. Решением будет запуск 1С в терминальной сессии, где ее ИБ будет запускаться не с шары, а непосредственно с каталога файловой системы сервера. Организовать запуск - как два байта переслать. Но встает два вопроса. Первый - разогнать всех пользователей - решаем и средствами 1С. Со вторым сложнее. Надо сделать, чтобы в шару никто больше не сунулся, а то база пойдет лесом. Причем полностью самбу останавливать нельзя.
net SHARE DELETE не работает (наверное от того, что шара прописана в smb.conf).
Пока приходит на ум только правка в авт. режиме smb.conf с последующим service smb reload. Но как-то это некрасиво.
Кто нибудь решал подобные задачи? acl???
Хм. Я так понимаю, база пойдет лесом по причине запуска локально и через шару одновременно? Предлагаю два варианта 1) скрипт на запуск платформы 1с на терминале, который бы сменял права на файлы таким образом, чтобы только 1 пользователь работать с ней мог. После перепроведения вручную запускался бы ярлычок на смену прав обратно. Костыльно, но вполне рабочий вариант.
Другой костыль, без дополнительных действий - на терминале монтировать шару с себя же с помощью etercifs, и работать с шарой. Тогда никаких проблем не будет, кроме меньшей производительности(что, видимо, в данном случае, принципиально. Но можно провести тесты - может, как раз тут все будет ок).
-
dimbor
- Ведущий рубрики
- Сообщения: 1572
- Статус: Подвинутый участник
Re: Регулировка доступа к smb-шарам на лету.
Спасибо, доктор! Про слона я и забыл. В смысле про юниксовые пермишенсы. Действительно, когда они не рубят, шара благополучно отдупляется сама. Выберу торопыгу и подарю право владения каталогом шары, а группе буду rw снимать-одевать. Единственно, как будет вести себя вайн@, хотящий sgid. Да еще он вроде именно 2770 хочет. Буду пробовать.
Дык так оно и работает сейчас. Понаехавшие работают по сети. Одновременно базу терминально мучают иногородние как раз через этеркифс, а как еще то? По этому поводу я уверенно иду к званию главного терпилы в некой известной в узких кругах баголовке. Благо реакция разработчика до сего момента была молниеносна и эффективна.
Принципиально до жути. Тесты проводить поленюсь, т.к. медленнее будет точно. А насколько, даже проверять не хочется. Понимаю, что может быть малосвязанно, но давеча пришлось по случаю мучить 1с каталог в ксеновской виртуалке vs etercifs там же. Добротная такая себе виртуалка, не с образа - на разделе. Так докладываю: разница в скорости значительная - чуть ли не на порядок. Можно конечно списать на кривые руки. Но ведь можно и не списывать
-
Bluetooth
- Сообщения: 4395
- Статус: Блюзовый
- ОС: Debian Squeeze amd64
Re: Регулировка доступа к smb-шарам на лету.
dimbor писал(а): ↑24.10.2011 03:03Принципиально до жути. Тесты проводить поленюсь, т.к. медленнее будет точно. А насколько, даже проверять не хочется. Понимаю, что может быть малосвязанно, но давеча пришлось по случаю мучить 1с каталог в ксеновской виртуалке vs etercifs там же. Добротная такая себе виртуалка, не с образа - на разделе. Так докладываю: разница в скорости значительная - чуть ли не на порядок. Можно конечно списать на кривые руки. Но ведь можно и не списывать
Можно тогда и на мои кривые руки списать - у меня такие же результаты
А можно не трогать права на каталог самой базы, а просто не давать другим юзерам читать каталог на уровень выше. Единственно, как будет вести себя вайн@, хотящий sgid. Да еще он вроде именно 2770 хочет. Буду пробовать.
-
McSim
- Сообщения: 419
- Статус: Экспериментатор
- ОС: заGNU/Linux Debian
Re: Регулировка доступа к smb-шарам на лету.
А вообще, если на шару при запущщенном samba задать параметр read only = yes, то все новые юзеры будут подключаться read only. А старых можно разогнать силами 1С. И перезапускать samba не нужно при изминении конфига ШАРов. Ибо самба читает конфиг при каждом новом подключении.