Jenkins Linux доступ к файлу или проблема с группой

Question

У меня возникла проблема с доступом к файлу.

система Linux является RedHat 5.5

На этой машине, когда я войти, как данный пользователь: deploy_user, я вижу, что у меня есть право на доступ к/путь/к/в/папке/подпапке/файла. TXT

Ls -l/путь/к/шоу/папка (это означает, Шифрование до этого пути я могу видеть содержимое):

13:50:53 drwxr-x--- 2 root dbgroup 4096 Apr 27 14:38 subfolder 

и в папке подкаталоге, file.txt имеет followin Доступ к г (Ls -l выход)

13:50:53 -rwxr----- 1 root dbgroup 1620 Dec 9 15:28 file.txt 

На сервере в $ подскажите, если я: идентификатор deploy_user Я вижу, я (будучи deploy_user) в dbgroup (т.е. любой в Группа dbgroup может изменить каталог на вложенную папку) и может читать файл file.txt.

Когда я бегу те же команды в свободном стиле Дженкинс работы и выполнения задания на этой Linux машине в качестве узла/ведомый (где Дженкинс подключается только к этому узлу/Ведомый, как пользователь deploy_user, используя его SSH ключи успешно), я не могу cd (изменить каталог) и список или ls и прочитать или cat этот файл.

ПРИМЕЧАНИЕ: Я ограничиваю задание jenkins работать на конкретном подчиненном устройстве (используя метку), то есть он будет запускать задание только на данной машине (как я уже упоминал выше).

В работе Дженкинс, все я бегу следующие команды:

echo "I'm `whoami`" 
echo "I'm in: $(id `whoami`)" 
echo 
groups 
echo 
echo "Again, my groups for: $(groups `whoami`)" 
echo 
cat /etc/group | grep "^dbgroup" 
echo 
echo 
cd /path/to/the/folder 
pwd && echo "It works! upto /path/to/the/folder path in Jenkins job." 
echo 
echo 
cd /path/to/the/folder/subfolder || echo "cd to subfolder - didnt work" 
echo 
ls -l /path/to/the/folder/subfolder/file.txt || echo "ls on file.txt - didn't work" 
echo 
echo "Sleeping for 60 seconds ..." && sleep 60 

Основной выход из Дженкинс работы является:

13:50:53 I'm - deploy_user 
13:50:53 I'm in: uid=3000(deploy_user) gid=3000(deploy_user) groups=4000(deployer),6001(dba),6081(osinstall),10121(dbgroup) 
13:50:53 
13:50:53 deployer dba osinstall 
13:50:53 
13:50:53 Again, my groups for: deploy_user : deployer dba osinstall dbgroup 
13:50:53 
13:50:53 dbgroup:x:10121:user1,user2,appuser3,svcuser4,deploy_user 
13:50:53 
13:50:53 
13:50:53 /path/to/the/folder 
13:50:53 It works! upto /path/to/the/folder path in Jenkins job. 
13:50:53 
13:50:53 
13:50:53 /tmp/hudson58581.sh: line 7: cd: /path/to/the/folder/subfolder: Permission denied 
13:50:53: cd to subfolder - didnt work 
13:50:53 
13:50:53 ls: /path/to/the/folder/subfolder/file.txt: Permission denied 
13:50:53 ls on file.txt - didn't work 
13:50:53 
13:50:53 Sleeping for 60 seconds ... 

Любая идея, почему выход групп и групп deploy_user различны. команда groups по умолчанию работает для текущего пользователя в журнале (это whoami, и он показывает, что я deploy_user).

Я также проверил идентификатор_группы в низкоспиновое -l выход как для подпапок/file.txt и это 10121

Спасибо.

Answer 1

ОК, проблема заключалась в том, что кто-то добавил пользователя dbgroup недавно, но он был добавлен после того, как узел был создан/настроен/запущен. Для того чтобы узел мог прочитать новые настройки, его пришлось перезапустить.

Именно поэтому на самой машине все работало нормально в $ prompt, но в работе Дженкинса это было неудачно.

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

Теперь обе команды группы и группы `whoami` показывает тот же # групп.

Answer 2

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

Проверьте, что groupIds для обеих машин имеют одинаковый номер «id». Если это не так, то вы можете ввести в заблуждение «dbgroup» на главном узле с «dbgroup» на подчиненном устройстве, что является совершенно другой группой. Linux действительно использует только номер.

Вы также можете снова проверить параметр «print groupID», а не по умолчанию «имя группы печати». ls -ln

Кроме того, имейте в виду, что работа Jenkins (запущенная в /tmp/hudson58581.sh может работать как другой пользователь). Сценарии предварительной сборки, скрипты сборки и сценарии после сборки все получают свои собственные оболочки, что означает, что мало что можно почерпнуть из одного, как известно, можно применить к другим.

Кроме того, Дженкинс управляет своим «на главном» рабе совсем по-другому, чем удаленные мастера. Если вы строите на подчиненном устройстве мастера, я рекомендую вам сразу перейти на удаленный подчиненный. Это связано с тем, что дистанционные ведомые устройства масштабируются, и не стоит аккумулировать логику, которая не будет.