I agree with you, it will be better if we found an alternative to (TERM) by changing the sudoers maybe .

Are you able to reproduce the issue with centos 6.6 ?

Following the result of the requested commands  :

sudo -l -U codendiadm :

Matching Defaults entries for codendiadm on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, !requiretty, !env_reset User codendiadm may run the following commands on this host: (gitolite) SETENV: NOPASSWD: /usr/bin/gl-auth-command, (gitolite) /usr/lib/tuleap/bin/restore-tar-repository.php sudo -l -U gitolite

sudo -l -U gitolite :

User gitolite is not allowed to run sudo on myhost

I don't find any obvious errors, the usage is just… weird. For many reasons:

• Execution of backend scripts should not depend on TERM env variable.
• There isn't any calls to sudo in existing Tuleap source code that depends on TERM
• Advice from sysadmins around me is "don't do that"

I prefer to find why our platforms, once again, differ.

What is the result of the following commands:

sudo -l -U codendiadm
sudo -l -U gitolite

Thanks

Why do you think that "TERM=xterm" could lead to an error ?

> getent passwd codendiadm | cut -d: -f7
/bin/bash
> getent passwd gitolite | cut -d: -f7
/bin/sh

What is the result of those two commands ?

getent passwd codendiadm | cut -d: -f7
getent passwd gitolite | cut -d: -f7

What's the error caused by "TERM=xterm" at your side ?

This the content of my /etc/sudoers.d/tuleap_gitolite2_http

# Gitolite smart http
Defaults:codendiadm !requiretty
Defaults:codendiadm !env_reset
codendiadm ALL= (gitolite) SETENV: NOPASSWD: /usr/bin/gl-auth-command, /usr/lib/tuleap/bin/restore-tar-repository.php

In my sudoers file I've :
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

Is it the right content ?

Thank you

[error] [Gitolite][Restore] Unable to extract repository from backup: [/tmp/apr1_test69_1431696346.tar.gz] error message : No entry for terminal type "unknown";

I've tuleap 8.1.99.53 running on centos 6.6.

I suspect that your sudoer file is misconfigured

Have you integrated gerrit #3969 in tuleap 8.1-3 ?

No, it will be in 8.2.

Yes, the systme event fail and in git log I've :

[error] [Gitolite][Restore] Unable to extract repository from backup: [/tmp/apr1_test69_1431696346.tar.gz] error message : No entry for terminal type "unknown";

I've tuleap 8.1.99.53 running on centos 6.6.

Have you integrated gerrit #3969 in tuleap 8.1-3 ?

We checked and we didn't encounters this issue. Do you have an error with the latest version of Tuleap ?

Hello Nicolas ,

Have tested restore feature before integrating gerrit #3969 ?

I think removing TERM=xterm will introduce a regression in restore , the system event will always fail (in centos 6) with the error 'No entry for terminal type "unknown";'

Could you please check asap ?

Thank you in advance
Amin

gerrit #3969 integrated into Tuleap 8.1.99.49

Merged in Tuleap 8.1.99.44. Thanks for your contribution !

In addition of that, I keep this open to check centos 5 behaviour.

I submitted a new patch set in gerrit, you can review again.

I'll try to reproduce the new issue with centos 5.9

Thanks

Ok so I tested this on my C6 instance (with your umask 027) and your patch solve the issue.

So please take in account my comment in gerrit and then I will merge this patch. We can keep this issue open to see what can be done for C5 instances.

Is that OK for you ?

Event logs:

2015-05-15T10:16:33+02:00 [info] Processing event #17215 SystemEvent_GIT_REPO_RESTORE(157)
2015-05-15T10:16:33+02:00 [info] [Gitolite]Restoring repository : nomoarbackend
2015-05-15T10:16:33+02:00 [debug] [Gitolite][Restore] sudo gitolite restore
2015-05-15T10:16:33+02:00 [error] [Gitolite][Restore] Unable to extract repository from backup: [/tmp/tuleap64-ad_nomoarbackend_1431677638.tar.gz] error message : tar: Cannot save working directory
2015-05-15T10:16:33+02:00 [error] [Gitolite][Restore] Unable to restore repository: nomoarbackend
2015-05-15T10:16:33+02:00 [info] Processing event #17215: done.

So I tested your patch and it does not work.

When it generates the archive, the 644 mode is given for the archive: -rw-r--r-- 1 codendiadm codendiadm 7046 May 15 04:14 tuleap64-ad_nomoarbackend_1431677638.tar.gz

And I got this error "Unable to restore repository : nomoarbackend" when restoring