[BlueOnyx:19995] Re: phpMyAdmin

[Michael Stauber]

Hi Dan,

>>> chmod 777 -R /var/lib/php/session/
> 
> FYI, This error has happened to us about three times in the last month.
> The chmod does fix things however I can't find a cron that fixes this.
> Just checking it hasn't been removed by mistake.

That cronjob got eventually wrapped into Swatch, which runs every 15
minutes. I just checked. Yeah, at the end of the Swatch run the script
/usr/sausalito/sbin/hotfixes.sh gets executed. Which has this in it:

# Fix PHP Session dir GID if needed:
if [ -d "/var/lib/php/session" ];then
        SESSPERMS=`ls -la /var/lib/php|grep session|awk '{print $1}'`
        if [ $SESSPERMS != "drwxrwxrwx" ];then
                chmod 777 /var/lib/php/session
        fi
fi

The problem there is that it doesn't do a recursive chown. So it'll only
chown the directory, but if a session file is re-used that had an
incorrect UID/GID, then that will cause a conflict.

OTOH: We don't really want to chown everything in that directory to 777,
as that would make all session files world readable. So I'm a bit torn
on how to approach this correctly. But I have a solution:

The permissions of /var/lib/php/session only get reset if the onboard
"php" RPMs are updated by upstream. If that happens, we end up with
incorrect permissions until the next Swatch run.

Now we do have a YUM plugin that runs at the end of any "yum update". So
far we only use that to see if we need to restart or rehash CCEd. I just
extended it to *always* run /usr/sausalito/sbin/hotfixes.sh, which will
immediately after a YUM update fix all those small annoyances that a YUM
update of certain OS components such as PHP, Apache, NSS or ImageMagick
brings with it.

So I just rolled up an updated base-swupdate module and will publish it
via YUM within the hour. That should then elegantly solve that issue in
a permanent fashion.

-- 
With best regards

Michael Stauber