Installation where scripts run with different user name

[crb11]

I'm trying to install CMSMS on a UNIX server which is set up in the following way:
[*] My user is crb11, in two groups: www-data and site-admin
[*] Scripts run as www-data, which is only in the www-data group.
[*] The main document root directory is owned by root with group site-admin.

This has the following consequences: if I install CMSMS via the install script, it creates its files as (generally) 644, which means I can't do anything to them (since I don't have the www-data password) and in particular can't update it as I would need to change permissions on config.php.

I tried copying the CMSMS files (so they go into my own name) and chgrp them to www-data. In this case the 2.1.5 upgrade fails at stage 7 saying it can't write to docroot. I don't understand how this can be, since it successfully wrote to docroot under a clean install.

What I've had to do for now is copy the CMSMS files into a subdirectory (so the root directory is www-data group). In this case things appear to work, but obviously when the update process creates new files they will be uneditable by me.

Some questions and thoughts:

1. This setup looks daft to me, and I'm trying to get it sorted out. Has anyone else faced similar problems and are there good workarounds?

2. Is there any way of running the CMS install script as a different user? It doesn't run from the command line alas.

3. Wordpress, which is officially supported on this server, does things differently. Its standard install script creates everything under my username (despite being run from the browser apparently identically). Is there anything we can learn from it?

At least the admins of a major university now know what CMSMS is!

[calguy1000]

You are right... there is no CLI support in the phar installer at the moment. We're going to look at that after CMSMS 2.2 comes out. (more info at Geekmoot).

Wordpress install works in this environment (just as CMSMS 1.x did) because you physically uploaded all of the files for the package and the installer just created a few files and directories, checks permissions and sets up the database. You would only potentially have problems with the config file, and any directories that the application had to write to.

In the mean time. If you are comfortable working with the shell, here's what you can try:
a: Upload the 'expanded' installer to a subdirectory beneath your destination directory. let us call this 'installer' for the sake of simplicity.
b: Expand the installer/data/data.tar.gz file into your destination
c: Browse to <root url>/installer/?nofiles=1 in your browser and proceed.

[calguy1000]

Followup:

Note: The config.php will still have a permission of 644 (this is set explicitly in the installer for security purposes). and will be owned by the www-data user. You will need to chown this file to your user account (or have an administrator do it).

Additionally, any files you upload to the server using the File Manager, some other module, or by installing modules will still be owned by www-data and you will not have write access to them.

The workaround to this is to make sure your umask is set to 002 or something that will ensure that they are group-writable. This is technically a security risk though.

By far the best solution is to configure the server to use some php environment like fastcgi etc. where the php process runs as the owner of the directory.