CAcert System Admins discussion list

[Bernhard Fröhlich <bernhard AT cacert.org>]

Am 11.01.2010 15:32, schrieb Ian G:
> Switching across to sysadm list.  Story so far:  test1 got messed up 
> because it ran out of space.
>
> On 10/01/2010 15:51, Jan Dittberner wrote:
>
> > > /chroot/var/lib/php4:
> > >
> > > root@muley:/chroot/var/lib#
> > >  ls -la
> > > total 80916
> > > drwxr-xr-x 3 root root     4096 Jul 21  2006 .
> > > drwxr-xr-x 6 root root     4096 Aug 14  2008 ..
> > > drwxrwxrwx 2 root root 82763776 Jan  5 14:18 php4
> >
> > looks like a LOT of old session data. Something like tmpreaper or a 
> > job which
> > uses find to cleanup old unused files from php's session store would 
> > be a good
> > idea.
>
> Last night, Jan cleaned out the directory, first with a find and then 
> with a rename/mkdir.  Reduced space to 52% used :-)  Big thanks!
>
> Philipp G confirms that this directory is for session data only.  I 
> suspect the old one can be safely removed (although maybe we need to 
> look at the sessions in there to see if there was some sort of 
> repeated attack).
>
> Jan has a potential cron job.  PG suggests that any cron job to clean 
> it out is a sysadm issue not a software issue.
>
> I suggest we make Jan a test1 sysadm.  Any objections?  Who else is on 
> the list?
>
> For all test1 sysadms:  it seems that both Apache and Mysql do not 
> start up properly on reboot.  Maybe as a result of chroot and run 
> level changes made in the past?  Perhaps we need another go at this, 
> some reboot testing?
>
> For critical team:  this is the sort of thing where test1 and other 
> test machines should be aligned with the critical setup, and there 
> should be some sort of doco we could follow from them?
>
> Wytze, do we have any writings in place that talks about cron jobs and 
> process start ups on reboots?
>
>
>
> iang

Running out of space seems to be not the only problem of test1.cacert.at.
It was already mentioned that apache did not start automatically, though 
an entry "S91apache2 -> ../init.d/apache2" is present in rc2.d.

The bigger problem was that the php scripts could not contact the mysql 
database. Jan's (probably correct) opinion was that the chrooted apache 
process coult not access the mysql socket at 
/var/run/mysqld/mysqld.sock. So with some trial and error I replaced all 
references to /var/run/mysqld with /chroot/var/run/mysqld in 
/etc/mysqld/my.cnf and /etc/mysqld/debian.cnf.
Then the mysql user did not have write access to /chroot/var/run/mysqld 
which probably prevented the creation of the socket. Therfore I chowned 
/chroot/var/run/mysqld to mysql.

After some restarting of mysqld the connection now seems to work again. 
I've no idea if my changes are how it should have been done, so probably 
someone more acquainted with debian and mysql configuration thould have 
a look at it. And I wonder why the system did run in the past at all...

Hope this helps
Ted
;)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature