SVN automatic updates generate files with wrong ownership.

[GoogleCodeExporter]

SVN automatic updates rely on an URL being called by the repository server upon 
each commit. This URL, depending on the node, makes a call to another URL, 
which calls a shell script via SUDO. 

While proper permisions have to be created for this script to run, current 
architecture make it run as root. I do not believe this is a desireable 
outcome. 
Consequently, all files updated by a SVN automatic update are owned by root 
user. 
-----------------------------------------
Files should be owned by the user designated by the system administrator to own 
the files for opencaching-pl application. On a single hosting architecture, 
this could be the same as the webserver runs as. 
On hosting with multiple virtualhosts, this should be a designated user, with 
permissions for the webserver user to access the files properly. This 
designated user may also have FTP access to those same files. (ie to edit 
settings.inc.php, etc)

Currently, due to root ownership of the files, the latter described features 
are non-functional. 
Also, a rogue execute or suid bit set may introduce potential security risks 
for the hosting server. 

Original issue reported on code.google.com by andrixnet on 12 Sep 2014 at 7:33

[GoogleCodeExporter]

I am currently working on devising a proper way to handle this situation.

Original comment by andrixnet on 12 Sep 2014 at 7:34

• Changed state: Started

[GoogleCodeExporter]

The main problem lies in post-commit.php: 
print shell_exec("sudo /var/www/ocpl-update.sh 2>&1");

This line makes a call to ocpl-update.sh as root user. 

This working as a single consistent call across nodes, with different hosting 
architectures, different administrative conventions, different user ownerships, 
is practically impossible under this configuration. 

Original comment by andrixnet on 12 Sep 2014 at 7:51

[GoogleCodeExporter]

Once the script is being exected as root, the root may execute any of its 
commands as any other user ("sudo -u<some-user> <command>").

Isn't it sufficient in your case? You can either chown or "svn up" as other 
user.

Original comment by rygielski on 12 Sep 2014 at 10:37

[GoogleCodeExporter]

@rygielski: Yes, indeed. That is the way. 

I have added in r6320 /docs/svn with an improved ocpl-update.sh and 
accompanying documentation on how to use it. No changes to the actual code was 
required. 

Individual node administrators may choose to keep their existing configuration 
(no change), take advantage of the logging feature I've added, or implement the 
proper file ownership with/without logging. 

Please notify OCPL server administrator. 
I will notify OCNL server administrator.

Original comment by andrixnet on 20 Sep 2014 at 12:11

• Changed state: Fixed

[GoogleCodeExporter]

Logging ability enables node administrators to track how SVN automatic updates 
are deployed on their node and identify the exact revision where a conflict may 
have occured. 

Original comment by andrixnet on 20 Sep 2014 at 12:14

[GoogleCodeExporter]

Updated ocpl-update.sh script to automatically resolve conflicts in favour of 
local changes and log conflicts so that sysadmin can resolve them manually. 

This assumes the sysadmin is the only one who can make local changes and has 
the responsability of maintaining the website.
Also it is assumed that changes made by sysadmin are important for the 
particular node under his/her reponsability.

--------------------------
This script is a template. Copy it to /var/www and edit it with your site name, 
your local path to site files and your logging option.

Original comment by andrixnet on 7 Nov 2014 at 12:27

[GoogleCodeExporter]

What kind of local changes you need to have? As far as I know, none of the 
other nodes need to have any local changes (config variables should be enough).

Original comment by rygielski on 7 Nov 2014 at 12:38

[GoogleCodeExporter]

Very simple, actualy only one: .htaccess
Current .htaccess is significantly customized to opencaching.pl site and those 
settings, and several others, are more suitable in server config because of 
their specific nature. 
I have solved the non-node specific conflicts myself, yet from SVN point of 
view, .htaccess remains in conflict.

On the other hand, changes in repository regarding .htaccess have broken svn 
updates on OCRO. With these modifications to the update script I can log 
conflicts (and solve them as admin), and at the same time have all the rest of 
the code updated correctly. 
Otherwise, at each automatic update I would have to do a manual cleanup.

See also issue #105

Original comment by andrixnet on 9 Nov 2014 at 7:09

[GoogleCodeExporter]

I would rather classify this as bug in .htaccess file, not the update script. 
You could try to edit .htaccess in such a way, that it would work correctly in 
all the nodes - e.g. by adding proper RewriteConds.

Original comment by rygielski on 9 Nov 2014 at 8:08

[GoogleCodeExporter]

I think it's quite neat to have all the .htaccess directives for all the nodes 
in one place. (Every developer who has the need to edit this file SHOULD be 
aware of all the peculiarities present at ALL the nodes.)

Original comment by rygielski on 9 Nov 2014 at 8:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Conflicts on OCRO have been partially solved. 
Issue #105 is still work in progress, but now there is a consistent solution.

Developers have to be extra careful when implementing in .htaccess because they 
have to generalize sufficiently.

However, I continue to stand by the method implemented in this sample script. 

I agree, local modifications on production should never happen. 
If they happen, the update will take notice of the conflict, log it, keep local 
version of file until sysadmin intervenes. 

The advantage is that the local copy of the repository doesn't remain locked 
preventing ALL further updates. 

Original comment by andrixnet on 10 Nov 2014 at 1:13