My personal opinion is that running php scripts as apache is outdated and insecure. Am I wrong?
That may be but I am a little nervous about changing to suphp on production servers. I don't see how it is insecure as the user apache has less privileges that the regular user. But where it is secure or not, or outdated or not, is not the point.
I just started testing a machine to see if I can do a customapache install and then change to custombuild and also make the httpd.conf file include all the other files custombuild generates. I hate having to have all the other files for apache. I am used to having everything in one file except for the user httpd.conf files
If I can do what I want I will then generate a list for myself of stuff that has to be done similar to what I use now for new installs.
I may even acquiesce to having multiple config files if I can get used to it. I am kinda old and set in my ways.
However all that being said I still have a bunch of servers running php as apache and any time I move an account it spells trouble for accounts that need apache to write to files.
DA staff recognizes that people still run php as apache and therefore changed the file manager to reset apache owned files. Also a php patch was provided so that the user and script name could be included in php sent mail header running as apache. I am asking for something similar in that I want the apache owned file to stay owned by apache during a server move.
To accomplish what I want now:
1. Suspend the account
2. Rename the domains directory to something else so the backup system does not waste time tar'ing something I cannot use. Perhaps domains.old
3. Run the backup
4. tar the domains.old directory preserving permissions.
5. Transfer the DA backup file and the tar file of the domains.old directory.
6. Run the restore
7. Untar the domains.old file
8. Rename domains.old to domains.
I guess the problem is that the uid of apache on one server might now be the uid of apache on another.
However the restore process could check to see what the uid is in the backup and match that against the uid of the new server.