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:

1

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.

This afternoon I received an email in my inbox from a group of people who had put together a website in a last ditch effort to save the Xserve. While I doubt it’ll have any effect on Apple’s decision to continue their Apple Xserve product line, it’s certainly worth a shot. I know I for one am a fan of the Xserve and would love to see it live on.

My name is Jesse and I’m the IT Manager for a small business with offices in Vancouver and Toronto. Over the years, I’ve managed to get Mac OS X Server machines used as the backbone of our IT infrastructure.

With the announcement by Apple that the XServe is being discontinued, I fear that any serious adoption of OS X Server as an enterprise OS will stall, if not recede entirely. I am personally and professionally frustrated, because while Linux and BSD are close to OS X, but I don’t particularly want to work with other OSes, because I think OS X is just great.

Some of us are starting a grassroots campaign to let Apple know how much they’ve let us down. I doubt it will change their minds, but we aim to try.

http://www.savethexserve.com/

Cheers,

- Jesse S

Let’s see if Apple hears the cries of those who enjoy their Xserve. I sure don’t want to try rack mounting the Mac Pro :)

Republished from makkintosshu with permission.

As of today, the Xserve’s days are officially numbered. 87, to be exact. Come January 31st, 2011, Apple will no longer be selling Xserves.1 What a shame.

As the transition guide (PDF; linked to from the Xserve Resources page) explains, the two options going forward will be the Mac mini with Snow Leopard Server and the Mac Pro with Snow Leopard Server. To me, the gap seems painfully wide, with the following completely lost:

• A powerful 1U option. Yes, you can fit 2+ Mac mini servers in 1U, but that’s not always the correct solution, nor will it yield the same raw processing throughput. Only being able to fit two Mac Pros in a whopping 12U of rack space is an astounding waste of space unless you actually need the internal storage & PCI Express expansion.
• Hot swappable internal storage. I won’t miss the price tag of Apple’s drive modules, that’s for sure, but they did an excellent job of ensuring they were actually enterprise-grade. It’s slightly painful to think that both their server options will require a power down and to be pulled out of the rack2 just to swap a drive.
• Redundant power supplies. I’m all for the lower power consumption of the Mac minis and Mac Pros, but the fact that Apple will have no server hardware that can be gracefully transitioned between power sources is very disappointing for those needing high availability.
• Lights-Out Management. I personally don’t use LOM, and I frequently hear complaints about Apple’s LOM implementation, but the number of times I could’ve used it and not had to send someone to the server room (or drive in myself) is way up there. So, not even having it as an option is an additional downer. Maybe someday the Mac Pro will get LOM.

That said, the Mac Pro is a far more formidable piece of hardware than the Xserve, and the pricing of the Mac Pro with Snow Leopard Server, much like the Mac mini with Snow Leopard Server, is pretty much just throwing in a copy of Snow Leopard Server. Also, as Brian Stucki of Macminicolo.net put it on Twitter, “WAY too many small business put money into [an Xserve] when a Mac mini would have been perfect.”

It’s clear that Apple is saying goodbye to “Enterprise” and honing in on the SMB market.

1 Of course, there may be some old stock available through Apple Specialists and Apple Authorized Resellers.

2 If you have two Mac Pros on a shelf in a four-post rack, you can probably, depending on the positioning of side panels & cross-members, pull the side off of _one_ of them to swap drives. Pain in the ass, though.

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.

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!

Back in 2008 I wrote an article which discussed how one can recover from a degraded mirror RAID-array. Unfortunately it looks like this issue may have popped backup within Disk Utility and still requires one to use the command line version of Disk Utility to correct the issue. One of our readers Matt S. of Panorama Productions & Digital Services found this out and was kind enough to allow us to re-publish his findings.

Unfortunately, my experience today does not support the conclusion that Apple has fixed the GUI in the Disk Utility included with OS 10.6.3.

I was forced to rely on the command line to add a replacement disk to a degraded RAID-1 because no amount of dragging and dropping in the DU window worked. The drag-and-drop would not place the replacement drive within the existing RAID set and the rebuild button never became active.

But the process was simpler than your prior description.

Wanting to take no chances with the data, I first cloned the data off the degraded RAID from the operating drive with Carbon Copy Cloner. In fact, I cloned it twice, to two different drives. Better safe than sorry.

I installed a new, replacement drive of equal capacity to the operating drive in my MacPro and initialized it as a single partition with a unique and easily identifiable name.

Using the command line in Terminal, I used the command “diskutil list” to get the disk numbers of all the disks installed in my MacPro.

Then, with no other commands necessary, I entered:

diskutil repairMirror disk4 disk0

Disk4 is the disk ID of the degraded RAID-1
Disk0 is the disk ID of the new drive

This command re-initialized the freshly initialized new disk I installed (called disk0), added it to RAID with the new name “RAID Slice disk0s2”, removed the name of the previously missing, failed member of the RAID-1, and automatically began rebuilding the array.

Much more efficient to type one command to do it all but I would rather that the GUI-based disk utility function as it should. It would be much more intuitive - and isn’t that what Apple products are supposed to be about?

Matt also followed up to my email to which I had asked a few questions.

The failed drive was NOT the boot drive.

I was NOT using the OSX 10.6.3 Install DVD as my boot disk. I was booted from my 10.6.3 normal boot hard drive.

And one other thing. I purposely and deliberately screwed up my RAID-1 just to see whether, in fact, Apple did fix the DU GUI. The drive itself did not go bad. I just wanted to experiment and I’m glad that I did. After the RAID rebuilt with the replacement drive perfectly in 4 hours, I deliberately failed the RAID again by removing the replacement drive and reinserting the original drive. I used the same command again and the original drive was reitialized and resynced to the still functioning drive just fine, only that took 7 hours. The only difference? My original drives are Seagate 1-TBs. The replacement test drive that I used was a borrowed WD RE3 1TB model. I think I’ll get four of those puppies! I guess there’s nothing like having two processing chips in a hard drive to almost halve the write times.

By all means, feel free to publish my comments. I wrote to you specifically to share my experience with you and your readers. The more all of us share our knowledge, the easier it becomes for other folks.

Best wishes,

Matt S.

That said, I’d like to myself try replicating the issue just to verify that once again the Disk Utility in 10.3.6 is broken. It’s too bad because it’s a lot easier to just drag and drop and new disk into Disk Utility rather then having to run through the command line.

ClamAV noted back in October that they were going to end-of-life ClamAV 0.94.x on April 15th, 2010, forcing it to be disabled during updates — yesterday, for those not paying attention. Of course, Mac OS X 10.4 Tiger Server includes ClamAV 0.88.5 through 0.94, so one is required to either disable the Mail Service’s virus scanning functionality or update it manually (I’d highly suggest Topicdesk’s instructions for 10.4.7-10.4.11).

While there have been recent reminders regarding Tiger Server, Mac OS X 10.5 Leopard Server and Mac OS X 10.6 Snow Leopard should be fine, right? Actually, prior to Security Update 2009-005, Leopard Server was running Clam AV 0.94, so you’ll need to make sure it’s fully updated — I managed to find one Leopard Server mail server that had not been updated yet. Snow Leopard Server is good to go, though.

So, make sure you check your ClamAV version on both your Tiger & Leopard Server mail servers.

If you hadn’t heard the fervent rumors over the past few weeks about Apple’s impending tablet computer, you’ll no doubt hear about the real deal: the iPad. It’s a mid-size, thin, fast, multi-touch tablet computer running an enhanced version of the iPhone OS and including Bluetooth, WiFi, and optional 3G connectivity. I’ll leave you to watch the video or drool over the specs & pricing.

Since I’m on-call 24/7 and must be ready to respond whether I’m on the couch or on a long trip, my primary workstation is the thin & light MacBook Air. I certainly wouldn’t mind carrying just an iPad with me wherever I went, but there are a few caveats for a server admin like me. While the iPhone OS’s copy & paste support is stellar and was worth the wait, the lack of multitasking could certainly make life more tedious in some cases or downright impossible in others. The iPad supports current iPhone/iPod touch applications at their existing resolutions (or at 2x size) and I have no doubt that the developers of SSH apps and such will update them to support the new resolution & keyboards quite quickly, but there are key apps missing. They’ve developed excellent new versions of the iWork apps for use on the iPad, but I’d need them to port Server Admin, Workgroup Manager, and Apple Remote Desktop for me to actually give up my MacBook Air.

It’s sexy. It has the potential. It certainly has the screen resolution and performance to take on such tasks. I’ll even guarantee that plenty of third-party tools will be developed for server admins using the iPad, but I hope Apple sees the light and brings over their own admin tools as well.

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:

1

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.

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.