Вопрос ребром о правах суперпользователя

[almasvas]

Здарвствуйте, прошу помочь, направить или хотя бы выслушать.
Такая ситуация.
ubuntu 14 x64 + 1c8.2 server x64 + postgreSQL

Все работает за исключением регламентных заданий, которые распихивают файлы по сетевым папкам.
Есть еще один сервер на windows 2003, где вообще все работает. Была проблема, когда у пользователя, под которым запускается служба сервера 1с, было не достаточно прав на этой машине (не на сетевом каталоге, там все открыто полностью для всех). Почему то тогда файлы в сетевых папках не создавались. Но в windows эту проблему легко решить.

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

Но вот с Ubuntu загвоздка. Не могу дать эти права.

ни usermod -aG 4,24,27,30,46,109,124,sudo usr1cv82
ни root:x:0:usr1cv82 в /etc/group
ни usr1cv82 ALL=(ALL:ALL) ALL в /etc/sudoers

не дают результата. Все равно чтобы я не делал от имени пользователя usr1cv82 получаю "отказано в доступе" , "вы уверены что вы суперпользователь?"
Конечно это дало возможность выполнять любые действия введя перед командой слово sudo, но я то могу его ввести, а вот служба нет.

Внимание вопрос:
Как сделать, чтобы пользователь мог выполнять элементарные вещи, типа монтирования размонтирования, без дополнительных su, sudo, запросов пароля и т.д. как root.

[Peter_I]

Во-первых, где находятся эти сетевые каталоги, на дисках с какой файловой системой?
Во-вторых, как они монтируются - через /etc/fstab или иначе? Покажите.
В-третьих, для любых каталогов, чтобы к ним проще было получить доступ по записи,
надо, чтобы они имели права 775, а пользователь с таким доступом должен входить
в группу, которой эти каталоги принадлежат.

[almasvas]

Сетевые каталоги находятся на другой машине под управлением windows XP, NTFS, доступ полный, т.е. из самой убунты я могу спокойно зайти, создавать и удалять файлы (под тем самым пользователем usr1cv82).
Путь к этим каталогам указывается в настройках 1с, через клиента на windows, в виде "\\ftpserver\ftp\".
Как с этим путем работает служба 1с на убунте, я не знаю. Может монтирует может нет.

Исходя из этого, я так понимаю, проблема не с доступом к каталогу, а с доступом к инструментам в ubuntu. Т.е. если предположить, что служба 1с сперва монтирует сетевой каталог, то понятное дело получает отказ, так как действует она не от имени root.

Поэтому и встал вопрос дать пользователю полный доступ суперпользователя.
Это решало проблему на windows и на CentOS

[AnrDaemon]

чтобы к ним проще было получить доступ по записи,
надо, чтобы они имели права 775,

Может, ещё 777 предложите? А заодно +t и suid root, чего мелочиться…

almasvas, посте ваших экспериментов никто не возьмётся разбираться, что у вас творится.
А на будущее запомните, запишите или просто вбейте себе в голову молотком:
1. Права суперпользователя ни одному демону не нужны. Практически. (Исключения есть, но это отдельный разговор.)
2. Права суперпользователя распространяются на локальную систему и только на неё.

[almasvas]

Каких экспериментов? Не нужно ни в чем разбираться. Я задал конкретный вопрос.
Оговорюсь еще раз. Сервер 1с работает. До него было настроено, либо взято готовых образов еще 3 штуки. Но ни на одном из них регламентное задание не смогло записать в сетевую папку файлы, не смотря на открытый доступ к ней. Проблема была решена только на CentOS сделав usr1cv82 суперпользователем. С операционной системы windows это работает тоже с условием что у пользователя службы есть все права. Такие дела с этой 1с, не может она нормально работать как все остальные службы.Факт.

1. Я столько форумов обрыл, и везде вместо того, чтобы сказать "нет возможности", говорят "вам это не нужно". Вопрос ребром именно потому, что сейчас и есть то исключение, когда советы - что нужно, а что нет, уже не уместны, нужно просто сказать как это сделать, либо сказать что это не возможно. Хотя не думаю что есть что то невозможное для системы с открытым кодом.

2. Я не уверен что сами разработчики 1с до конца понимают, как оно у них там работает. С доступом к сетевой папке под этим пользователем все в порядке, поэтому очевидно что проблема именно в локальной системе, где под пользователем usr1cv82 я не могу даже папку создать в /mnt/ , не говоря уже других вещах.

PS Еще раз вопрос:
Как сделать, чтобы пользователь мог выполнять элементарные вещи, типа монтирования размонтирования, без дополнительных su, sudo, запросов пароля и т.д. как root.
в Centos и старых версиях ubuntu это сделать точно можно было, какая проблема с этим сейчас, я не понимаю.

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

[peregrine]

almasvas, надо было начинать не с запуска демонов от рута, а с изменения прав на проблемные сетевые каталоги (либо локально, либо на удаленных машинах, ХЗ что там в 1C).

[almasvas]

а с изменения прав на проблемные сетевые каталоги

И это логично. Сам не верил ни во что другое, кроме этого. Но к сожалению отпадает. Права доступа полные для всех, настройки безопасности папки - разрешено все для всех. Файрволы отключены, антивирусов нет, паролей нет. В эту сетевую папку может записать абсолютно любой с любого устройства. Даже этот пользователь usr1cv82 из графического интерфейса убунты может просто зайти в нее и создать файл или удалить все. Т.е. "проблемной" эту папку уже не назовешь, и права ей добавлять уже некуда, все и так открыто и работает.

Что же происходит в тот момент, когда служба srv1cv82 пытается выполнить задание по записи файла в каталог? не знаю. в логах ничего нет. Опыт говорит о том, что служба хочет что то сделать перед записью файла, на что у нее нет прав. Так что теперь то самое время подумать над тем, как дать ей права.

[AnrDaemon]

Как сделать, чтобы пользователь мог выполнять элементарные вещи, типа монтирования размонтирования

Это НЕ элементарные вещи, и простому пользователю не должно быть нужно их выполнять.
Если до вас не доходят слова - посидите и вдумайтесь.
Когда вернётесь, надеюсь, вопросы вы начнёте задавать более вменяемые.

[almasvas]

Нет, видимо это вы меня не услышали. "Не должно быть нужно" и "я не знаю как это сделать", разные вещи.

Эти НЕ элементарные вещи вполне могут делать суперпользователи в других *nix операционных системах. Так уж вышло, что сейчас нужно разобраться, как это сделать именно в ubuntu.

З.Ы. Для тех кому трудно понять мои намерения, или он не знает что это за гремучая смесь 1с с ubuntu, пусть для него это будет чисто принципиальный вопрос. Из спортивного интереса.

[Yuriy_Y]

Все работает за исключением регламентных заданий, которые распихивают файлы по сетевым папкам.

Вот тут подробнее, что за задания и что они куда пихать пытаются?

Я не уверен что сами разработчики 1с до конца понимают, как оно у них там работает.

Вот тут соглашусь.

Что же происходит в тот момент, когда служба srv1cv82 пытается выполнить задание по записи файла в каталог? не знаю. в логах ничего нет.

А точно все логи покурены?

Эти НЕ элементарные вещи вполне могут делать суперпользователи в других *nix операционных системах.

В этом плане бунта ничем от них не отличается.

Сама 1Ска ничего не должна монтировать. Потому ошибка и вылазит. Она лишь пытается записать файл по пути "\\ftpserver\ftp\". А вот уже админу надо заранее примонтировать этот путь в каталог, к примеру, /home/1csrv82/ftp. Только и всего. Тогда 1С будет пытаться писать файлы именно в свой домашний каталог, для чего ей не нужны права рута.

[almasvas]

Вот тут подробнее, что за задания и что они куда пихать пытаются?

Регламентное задание "выгрузка номенклатуры" формирует файлы goods.txt и записывает их в отдельные каталоги сетевой папки \\ftpserver\ftp\*. Другое задание собирает из этих папок файлы report.txt, чего тоже не происходит.

Если зайти в выгрузку справочников в клиенте 1с и там нажать кнопку "выгрузить" для какого-нибудь магазина, то по тому же пути все запишется нормально.

А точно все логи покурены?

Не все, есть еще один 1свский, когда то я его прикручивал, но не помню, вроде толка от этого не было. Могу заморочиться еще раз, но я надеялся что меньше сил потрачу на то, что бы просто дать права пользователю и проверить. Должно сработать полюбому.

Сама 1Ска ничего не должна монтировать. Потому ошибка и вылазит. Она лишь пытается записать файл по пути "\\ftpserver\ftp\". А вот уже админу надо заранее примонтировать этот путь в каталог, к примеру, /home/1csrv82/ftp. Только и всего. Тогда 1С будет пытаться писать файлы именно в свой домашний каталог, для чего ей не нужны права рута.

Вроде я уже проходил это, пытался в настройках задания указать не "\\ftpserver\ftp\shop1\" , а монтировал и указывал "/home/1csrv82/ftp/shop1" эффекта не было, но это все было давно и на CentOS, может здесь и сработает, попробую вечером еще раз этот вариант. Но лучше от этого не станет. Эти пути так же используются из клиента, где они работать перестанут, так как путь /home/1csrv82/ftp/shop1" c рабочей машины не доступен и должен выглядеть в формате "\\ftpserver\ftp\shop1\".

В этом плане бунта ничем от них не отличается.

На CentOS я долго не мог понять в чем дело. 1сник не мог сказать конкретно почему так происходит, сказал лишь что проблема, так же как и на windows должна решаться добавлением прав пользователю (не помню точно, там вроде учетку в группу админов добавили и все), под которым запускается служба. Я не особо верил, т.к. и не понимал зачем, но все остальное попробовал, так что пришлось. Дал права, файлы стали записываться.
Но так как все это вертелось на виртуалке, дров к которой нормальных небыло да и образ был скачан готовый в интернете, все это зависало каждые три часа.

Вот я снова все настроил, но уже на убунте и без виртуалки. Снова приходится проходить весь этот путь заново. Заново экспериментировать, заново менять пути, прикручивать логи.
Я понимаю, что у пользователей и разработчиков убунты сложились свои заветы, типа "ни в коем случае не давайте простому пользователю права root", не знаю на чем они так обожглись, и зачем усложнять и без того нелегкую жизнь пользователя, но теперь это табу. Задача этого сервера просто вертеть на себе один сервис с полными правами, и все. Если он этого не может, я найду другую систему. Я надеюсь что проблема эта только психологическая и второй день пытаюсь вытянуть из людей как нарушить их страшный завет)))

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

[peregrine]

almasvas, вы админите Windows? Так зачем тяните дурные привычки и неправильные способы решения проблем за собой?

[almasvas]

Я работаю на результат. Привычка добиваться результата.
Раз уж обо мне, я далеко не профессионал. Настраивал множество smb, ftp, squid, openVPN и др. серверов, глубоко не вникая в процесс, потому что был важен результат и он был. Вероятность того, что система заработает с полными правами пользователя 90%, вероятность того, что вы поможете мне найти другое решение 10%. По вашему, профессионализм заключается в том, чтобы избегать нестандартных решений?

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

[peregrine]

almasvas, по теме - логиньтесь под рутом уж тогда сразу. Чего мелочиться?

[almasvas]

Почему бы и нет, если будет результат?
Логиниться нужно не мне, а службе. Но могут быть негативные последствия. Если логинить её от рута, сменятся домашние каталоги и много чего ещё может пойти не так. Если окажется что дать права рута пользователю невозможно, тогда можно попробовать..

Но невозможно ли?

Может перенести тему в "безопасность"?