... /etc/shadow and /etc/gshadow broken ... Well, I was blessed by this bug today also From what I was able to ascertain it seems that writeconf.php was somehow interrupted while writing out /etc/passwd, /etc/shadow, /etc/group and /etc/gshadow. The end result was an incomplete /etc/shadow (6k instead of 30k) and a completely empty /etc/gshadow. Fixed it by rebooting and restoring the files from a backup (lost a few users passwords in the process, but still better than nothing). I am not sure how ISPConfig 2.x writes out these files, but might I suggest that they be written to .ispconfig first and then just copied over to their real counterparts, so in case the process of writing out is interrupted only the .ispconfig bit is broken, and there is no headache involved. Of course if these files are written out with system calls this approach is not feasible. To explain what I mean ... 1) writeout to /etc/passwd.ispconfig, /etc/shadow.ispconfig, /etc/group.ispconfig, /etc/gshadow.ispconfig (depending on the amount of users this could take a few seconds, where an interruption would be rather critical and system breaking). After this process is done: cp /etc/passwd.ispconfig /etc/passwd cp /etc/shadow.ispconfig /etc/shadow cp /etc/group.ispconfig /etc/group cp /etc/gshadow.ispconfig /etc/gshadow These 4 copies should take a lot less than the process of writing out the .ispconfig files themselves. Be it as it may ... wrote a short backup script that I run several times a day now to save me any further headaches :] Code: #!/bin/bash # # Short backup of ETC - run 4 times daily - keep 120 copies # export DATUM=`/bin/date +%Y-%m-%d-%H%M` echo `/bin/date` - Started >> /var/log/etc-backup-log cd /data0/backups/etc mkdir $DATUM cd $DATUM tar czvf etc.tgz /etc echo `/bin/date` - Ended >> /var/log/etc-backup-log cd /data0/backups/etc let BACKUPS=`/bin/ls -dlt /data0/backups/etc/????-??-??-????|/usr/bin/wc -l` while [ $BACKUPS -gt 120 ]; do ERASING="`/bin/ls -1dt /data0/backups/etc/????-??-??-????|/usr/bin/tail -1`" /bin/echo `/bin/date` - Erasing $ERASING >> /var/log/etc-backup-log /bin/rm -f $ERASING/etc.tgz /bin/rmdir $ERASING let BACKUPS=`/bin/ls -dlt /data0/backups/etc/????-??-??-????|/usr/bin/wc -l` done Might be a bit on the quick and dirty side, but it does what I want it to I run it 4 times daily and keep 120 copies (so for 30 days back). On my server this amounts to approximately 1 GB of storage for the full 120 copies. To use it, please check the paths for: ls, rm, rmdir, echo, date, wc and change the script if necessary to reflect the right paths for your system. The data is stored to /data0/backups/etc/ under timestamped directory names. (change the path accordingly in the script above if you keep it in a different place - there should be 5 changes involved - that's just because I'm lazy and didn't use a variable to store the path ). If you want to keep less than 120 copies, change the -gt 120 to -gt <copies>. Copy the script to /bin/backup-etc.sh, chmod +x /bin/backup-etc.sh, put it in crontab: Code: 15 3,9,15,21 * * * /bin/backup-etc.sh &> /dev/null and save a headache D.
I´ve had a few of this file corruptions, even with other files (postfix or apache2). I think the problem is the ispconfig_server startup script because it runs a kill -9 to the ispconfig_wconf process I´ll be doing further testing. The thing I don´t know is, when removing the -9 does the process finish writing files correctly?
