Feeling lots better now 
Here's a freakiness.
I need a way for admins, in a controlled way, to write to a specific file owned by root.
All website scripts run as the user 'apache' (since we don't run mod-suid).
So one sensible way would be to create a script to do the job, and allow apache to run that script (and nothing else) as root.
To do this, we add a line to /etc/sudoers as follows:
apache ALL=(root) NOPASSWD: /usr/bin/file_writing_script
That means: user "apache" from "ALL" machines, can run, as user "root" and without needing a password, the /usr/bin/file_writing_script,
This works 100% fine on our test server. On our live server, it doesn't: it will prompt apache for a password. Any OTHER name in that line, it works FINE. Just not apache.
In the end I got around it using a script that was sgid wheel, owned and executable only by apache. But, sheesh and criminy, some days I feel that there's black magic that's out to deliberately prevent this project from completing by throwing up hurdles that specifically block its path, and nothing else.
This is not the first, there've been many. I seem to spend a crazy amount more time jumping through stupid and pointless hoops while working on this project than any other.
A lot of the time it's the case that the problems are caused by slightly naughty "simplifying" shortcuts (like using sudo), so the hoopjumping has often just been that I had to be not-lazy and do stuff The Right Way. So in a lot of cases, I've ended up happier with the final solution than I would have been.
But in some cases, it's just been pure, bloodyminded black magic that's out to get me!
Incidentally, I just found the reason, and hence have managed to dispel the magic. There was another user with the same uid in the passwd file of the main server, with the entry preceding that of apache. So, "su - apache" made me be seen by the system and hence by sudo as that user rather than as "apache".
