Macintosh-Admin » Tips & Tricks

iCal Server: Broken Web Interface

jimmy — Tue, 31 May 2011 21:24:48 +0000

I’ve been using the built-in calendar server OS X Snow Leopard Server offers since day one. Paired with the address book service it saved me from spending another $99/yr on the MobileMe service. However, for the past month or so, the web interface hasn’t been working and will continually sit at the ‘Getting Events’ screen. Today I finally got around to checking through some error logs, specifically /var/log/caldavd/error.log. The following was the error I was getting:

2010-02-01 22:26:59-0600 [-] [caldav-8010] vobject.base.ValidateError: 'VEVENT components cannot contain both DTEND and DURATION components'

After searching around I came across this post on the Apple Discussion Forums. Something interesting to take note of is, the event was added/modified from the web interface (the product id):

PRODID:-//Apple Inc.//Web Calendar Client//

So that seems to lead me to believe there’s actually a bug within the web interface that isn’t setting the right parameters in the events. The fix is to remove the DURATION and replace it with DTEND (if it doesn’t already exist). What I did to find any events with DURATION was a simple grep:

sh-3.2# grep -ir DURATION /Library/CalendarServer/Documents/calendars/__uids__/

Then you can use your favorite editor to remove the DURATION line. Before making edits, I recommend stopping the calendar service, edit, then start it back up.

This resolved my issue, so hopefully it can assist anyone else with a broken web iCal interface.

Fixing the Delete Key In Terminal/SSH Sessions

jimmy — Sat, 31 Jul 2010 05:50:54 +0000

I administrate a variety of servers and while most of them don’t have issues when I connect from my Mac, one of our Debian servers has an issue with the ‘delete’ keyboard. Instead of deleting to the left it will do a forward delete and delete the character to the right of the cursor. This is behavior expected of the ‘delete’ key near the ‘home’ and ‘end’ buttons. Fortunately there’s a quick fix for this. Just open Terminal’s preferences. Locate the Advanced tab for the Terminal ‘profile’ you use and check off the ‘Delete sends Ctrl-H’ checkbox. Doing this will restore normal functionality.

Creating a Subversion Repository on OS X Server

jimmy — Tue, 08 Jun 2010 08:56:59 +0000

I often find myself creating subversion repositories on my OS X Server. I’ve actually designated my OS X Server to be my Subversion server since Apple has been kind of enough to include the necessary software right out of the box. This applies to both OS X Leopard and Snow Leopard Server. I also find that each time I find myself going back to this one website which includes instructions on how to get it all working. Rather then write our own guide I figured it would be just as easy to link you all to the site I use instead:

Subversion on OS X Leopard Server

It’s pretty simple to follow, basically you just use the svnadmin command to create the actual repository, then you need to activate a couple modules for Apache via Server Admin, then create a realm, and voila! One thing I do different from the guide, is that I create all my repositories in /usr/local/svn/ instead of /usr/local/. This is really just a personal preference thing, however my main reason is for neatness. I like to keep things organized. You of course can create the repositories where ever you’d like, even in your home folders if that’s your thing!

Cleaning Up MySQL Binary Logs

morgant — Mon, 18 Jan 2010 19:02:52 +0000

While Jimmy has previously covered disabling MySQL’s binary logging for those who don’t need it and don’t want to worry about the unexpected disk space usage, others prefer to merely purge older binary logs to reclaim disk space. MySQL’s binary logs live in /var/mysql and appear as mysql-bin.000001. Some of my servers merely hosting a few weblogs have bin logs taking up 4K-1MB, but others hosting large web applications have bin logs in the 1GB range. The last thing you want is for the drive hosting your MySQL databases to fill up unexpectedly.

Here’s a one-liner for removing all MySQL bin logs older than 30 days:

sudo find /var/mysql -name "mysql-bin.0*" -mtime +30 -exec rm {} +

Obviously, any command like this that automates deletion of potentially needed data could be disastrous, so make sure you have a good backup of your data before you try it. The benefit of the above command is that you can remove ‘-exec rm {} +‘ from the end of it to do a dry-run without actually removing any files and it’ll merely list the file names. Also, if you want preserve all bin logs newer than 60 days, simply change to read ‘-mtime +60‘, or whatever best fits your needs.

Depending on your usage & backup setup, you could certainly automate this using cron or launchd.

How to Kill Orphaned launchd Jobs

morgant — Thu, 31 Dec 2009 13:27:16 +0000

Have you ever accidentally edited, moved, or deleted a launchd daemon/agent plist file without stopping the job first and then found you couldn’t unload it? I’ve done this on a few occasions and learned the following trick from the launchctl man page, just run `sudo launchctl remove `. The should be the job’s ‘Label’ specified in the plist file (the reverse domain notation used in the plist filename, e.g. ‘tld.domain.job’ if the filename is ‘tld.domain.job.plist’) or you can look it up using `sudo launchctl list`.

A little background in case you’re interested: the ‘remove’ subcommand is there to counteract jobs added manually/programmatically using the ‘submit’ subcommand, hence it working when the plist file is not there for you to use the ‘unload’ subcommand (which requires a plist file).

Open Directory Replication and SSH Service ACLs

morgant — Tue, 15 Dec 2009 18:15:54 +0000

While configuring a Mac OS X 10.5 Leopard Server as an Open Directory Replica of a Leopard Open Directory Master I got “Open Directory Replica Error value = 1255" when it tried to start creating the replica. This error has to do with not being able to establish an ssh connection with the OD Master, but the server in question had Remote Login enabled and, while I was using service level ACLs to limit ssh access, the admin user had ssh access.

However, although the root user and admin user share the same password by default, they’re not the same user and I couldn’t ssh in as root. Oddly, the root user isn’t an option to add to service level ACLs in Server Admin (at least for that Leopard Server installation). A quick search pulled a knowledge base article regading being unable to add the root user to service-based ACL for SSH which tells you to run the following command to add it manually:

sudo dseditgroup -o edit -a root -t user com.apple.access_ssh

Sure enough, it worked like a charm and now root shows up as “System Administrator” in the SSH service level ACLs in Server Admin:

Naturally, I was then able to ssh in as root and the Open Directory Replica creation went off without a hitch.

Swamped by ServicesInformation Errors

morgant — Mon, 30 Nov 2009 22:29:58 +0000

Here was a new one for me. A Mac OS X 10.5 Leopard Server file server had been unresponsive to Apple Remote Desktop and wouldn’t display video for about a week. I could still SSH in and the AFP services it hosted were functioning normally, so I left it for a “later” project. Well, this morning I was notified that some of the AFP shares were no longer listed due to a power outage affecting the RAIDs connected to it.

No worries, restarting the AFP service or rebooting should resolve that. Only it didn’t. There was high usage by syslogd and I found tons of the following messages in /var/log/system.log:

Record of type dsRecTypeStandard:Config named ‘ServicesInformation’ already exists in /Local/Default. Trying with new name: ServicesInformation1

Others have run into this before, and it seems to be a corruption of /var/db/dslocal/nodes/Default/config/ServicesInformation.plist. In my case, there was some file system corruption, so I did the following:

Booted from another drive w/Disk Utility and SuperDuper!
Verified the disk using Disk Utility (which failed.)
Backed up the drive with SuperDuper! (Just in case.)
Repaired the volume with Disk Utility (successfully.)
Booted into Single User Mode.
Backed up /var/db/dslocal/nodes/Default/config/ServicesInformation.plist and removed all the extra ServicesInformation*.plist files.
Rebooted from the original boot drive.

What I found while fixing this:

The ServicesInformation.plist was corrupted and contained text regarding a disk full error, so that’s likely the cause of the corruption.
I was able to just delete ServicesInformation.plist and let it regenerate without detrimental effects, but be dubious.

Stripping All ACLs

morgant — Wed, 18 Nov 2009 16:14:14 +0000

I’ll admit it: I rarely ever work with Access Control Lists. Most of my time is spent in web server land where POSIX permissions are more than adequate, so I just fire up Server Admin if I have to add an ACL.

However, a co-worker recently ran into an ACL mess after a client converted their server from Standalone to Open Directory Master and back again. So, how to strip all ACLs so you can start over? It’s probably dangerous or some command I’m not familiar with, right? Nope.

The following call to chmod will recursively remove all ACLs:

chmod -RN /path/to/directory

Voilà!

Flush Your Firewall

jimmy — Tue, 17 Nov 2009 20:32:45 +0000

The other day I was having some issues with my VPN and Mail server working correctly. After narrowing down the issue to it being my firewall blocking the issue, I went out on a hunt to locate the possibility to be able to flush out the current rules from the firewall. OS X Leopard Server uses ipfw as it’s firewall implementation. Even OS X Leopard client uses ipfw! Fortunately it’s pretty similar to iptables which we also use on our Linux servers so there was a way to flush out the current rules. Simply using the following command will remove all the rules that haven’t been saved (which can be done either via the command line or through that nice Server Admin GUI tool):

sudo /sbin/ipfw -f flush

Once that’s run, you have have a peek back inside the Server Admin tool and you’ll notice under the Active Rules there should be none or only a couple. You can also show the list from the command line (which you’ll probably want to do under client since it doesn’t work with the Server Admin tool. Use this command to do so:

bash-3.2$ sudo /sbin/ipfw list 65535 allow ip from any to any

As you can see, I allow everything on my client machine, but on the server:

palomino:etc jimmybrancaccio$ sudo /sbin/ipfw list 00001 allow udp from any 626 to any dst-port 626 00010 divert 8668 ip from any to any via en0 03885 deny ip from 58.251.59.9 to any 03890 deny ip from 89.96.140.154 to any 03895 deny ip from 211.143.101.226 to any 03900 deny ip from 212.222.147.130 to any 03905 deny ip from 58.185.182.212 to any 03910 deny ip from 76.17.182.127 to any 03915 deny ip from 202.102.245.109 to any 65535 allow ip from any to any

There’s currently some blocks in place. Anyways, just a couple useful ipfw commands!

Colors In Terminal!

jimmy — Tue, 03 Nov 2009 20:06:55 +0000

Looking for a way to jazz up your Terminal.app? Here’s a quick and easy way to do so! Open up Terminal first, then type in nano -w ~/.bash_profile This will open a command line-based text editor. The file you’re editing is one that gets loaded every time you open a new Terminal window (or tab). Paste or type in the following at the end of the document:

export CLICOLOR=1

Then hit Ctrl+O and Ctrl+X. These key commands save the file and exit the editor. Now, open a new Terminal window and type in ls. This will list the contents of the folder you’re in (which should be your home folder) and the titles of the folders should be colored as shown in the above screenshot!