These two nifty commands allow you to set separate permissions on files or directories within a document root on POSIX based file systems such as linux or Mac OS X with a single comment. They’re an invaluable tool in any web developers arsenal!
To reset the permissions on all files within a document root you can run from the command:
find . -type f -exec chmod 644 {} \;
Or for all directories (files) within the document root:
find . -type d -exec chmod 755 {} \;
I had a problem with a testing server earlier today where the kerberos database had become corrupt. For any users on my Open Directory Master the kerberos passwords were flagged as incorrect, and changing them from work group manager had no effect. Changing them from the command line was not an option as this relies on knowing the users original password – which was corrupt.
The kerberos service can be restarted by greping the output of the ‘ps aux’ command for the kerberos process, (usually named ‘krd5kdc’) and then issuing a kill command against its PID. The service will then automatically restart.
ps aux | grep krd
kill kerberos_PID
This slightly improved the problem as it allowed newly created users to use kerberos with their correct password.
Re-building the kerberos database is done with the following command:
slapconfig -kerberize -f diradmin
This needs to be run as root, either directly of via sudo. The -f flag forces the current set up to be over written.
I would recommend taking a full backup of your users and groups, as well as an archive of your Open Directory server from server admin. Stopping any services that rely on kerberos would also be a good idea.
If neither of the above options worked then it is possible to rebuild your kerberos database from scratch – nuking your old database. This would also be necessary if you are changing the the Kerberos Domain, however don’t forget that if doing this you would also have to change the search path in all your LDAM and Password Server databases.
To completely rebuild kerberos.
1) Stop the OD Service.
2) Log into a shell as root and run the following command:
sso_util remove -k 0a diradmin -p your_diradmin_password -r your_kerberos_realm
3) Remove the following files and directories from your system:
/var/db/krb5kdv/
/Library/Preferences/edu.mit.Kerberos
/etc/krb5.keytab
4) Run the following set of commands as root:
dscl 127.0.0.1
cd /LDAPv3/127.0.0.1/Config/
auth diradmin (and enter your diradmin password)
delete KerberosKDC
delete KerberosClient
quit
5) find and kerberos process (krb5kdc) and kadmind processed and kill them, (as shown above).
6) Re-build your kerberos database:
slapconfig -kerberize diradmin
You can check if the users’ passwords are now being accepted using the ‘kpasswd’ command. The ‘kinit’ command can also be used to test creating a kerberos ticket.
Every now and again when applying a quota change to a user on a Dovecot mail server the change will fail to be implemented. On a cPanel server in particular this will result in an error message being thrown back to the administrator. On other systems the change will often appear to have been applied, but in reality will have failed.
The result of this will either be that the old quota level remains active, or occasionally that the user’s mail box is permanently flagged as full. Obviously with the latter, this will cause emails being sent to the user being returned to the sender. Often this is the first clue that something has gone wrong.
The fix for this: Simply navigate to the user’s mail directory and delete the maildirsize file.
rm -f maildirsize
The next time the user receives an email the file will be recreated by the Dovecot process and the quoter system will be repaired. Once that’s done you’re able to re-a-sign the new quota level to the user.
Very occasionally it is just that the file gets corrupt. However thanks to Dovecot’s ‘self healing’ abilities this is normally resolved automatically the next time the user receives an email. A more likely cause is that the permissions on the maildirsize file have been altered, preventing the Dovecot process from being able to write to the file.
The most common cause however is that the quota was changed, and then before it was implicated by the server, (which happens on receipt of a new email), the quota was adjusted again. If this happens continuously this problem will arise.
© 2012 Oliver Helm · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
