MacOS X 10.7 Time Machine Backup to FreeBSD Server with Netatalk

UPDATE : This documentation still works, but it uses netatalk version 2 and is more complex than using version 3. Please consider using this documentation using netatalk version 3 instead. 

If you backup your MacOS X 10.6 machine to a netatalk server, then you may have found that MacOS X 10.7 cannot backup to the same machine. Apparently, the major reason why it's now broken is a lack of « replay cache » which was introduced in AFP 3.3. So what you need to do is upgrade netatalk to version 2.2.x.

UPDATE : I've successfully this setup with MacOS X 10.8 and 10.9.

Let's configure a FreeBSD machine to serve as a Time Machine target for MacOS X 10.7. I'm using FreeBSD 8.2 as this is the production version. If you prefer using a Linux machine, then take a look at this blog post by Steffen L. Norgren.

The Origin of the word Daemon

Here's an interesting short article on the origin of the word « daemon ». I've copied the entire article below. Enjoy!

How to increase ASM disk space on Linux with iSCSI using udev instead of ASMLib.

Today I'd like to explain how to add more disk space on an existing Oracle ASM diskgroup on Linux using udev(7) instead of ASMLib. 


There has been a few threads about ASM, AMSLib and udev on the oracle-l mailing list (see OCR / VD external vs. normal redundancy using NFS and High Availability Options for instance). I prefer using udev. So in this example, I will be using udev in order to add two new LUNs to the existing +FRA ASM diskgroup. 
This particular ASM setup has three diskgroups: +CRS, +DATA and +FRA. The +CRS diskgroup is used for the Grid Infrastructure (GI) files (i.e. OCR and ASM spfile), the +DATA is used for the database (RDBMS) data files while the +FRA one is the Fast Recovery Area. That's the one we need to increase.

What to look out for when changing old servers.

Last week I replied to a post from Marko Sutic on the oracle-l mailing list (Here's the thread on the mailing list archives). Apperently it was worth it as he wrote back saying « I'm astonished with the quality of your reply! » (thanks Marco, it's a good ego booster! :)

He suggested that this post should be shared because it can be useful to many people. And not just as an Oracle specific issue. He also asked if he could post it on his blog. Not a bad idea, I thought. So here it is. But first, let's see Marco's original question:

Manage Oracle 11gR2 ASM and RDBMS audit logs on Linux.

If you don't change anything after a new 11gR2 ASM and RDBMS installation, your system's local file systems will slowly fill up with several thousands of audit log files. To fix this problem, you can either:

1. Modify the system's crontab to clean the audit logs directory periodically
2. Configure both the ASM and the RDBMS audit parameters to use syslog.

The crontab solution is easy, but I prefer the syslog solution because:

Installing patch 11.2.0.2 to Oracle 11.2.0.1 when the Clusterware and RDBMS owners are different.

Today we will patch our Grid Infrastructure (GI) and database (RDBMS) homes from 11.2.0.1 to 11.2.0.2. Be ready, this is a relatively long process.

Oracle Grid Infrastructure and Database Patch from 11.2.0.1 to 11.2.0.2

Important changes to Oracle patches.

• Doc ID 1189783.1 - Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2
• Doc ID 854428.1 - Patch Set Updates for Oracle Products
• Doc ID 880782.1 - ALERT: Oracle 11g Release 2 (11.2) Support Status and Alerts
• Doc ID 1179474.1 - 11.2.0.2 Patch Set - Availability and Known Issues 
• Doc ID 1179583.1 - 11.2.0.2 Patch Set - List of Bug Fixes by Problem Type 
• Doc ID 1266978.1 - Potential security issue requires a new download of Oracle Database 11.2.0.2 and Grid Control 11.1.0.1
• Doc ID 10036834.8 - Bug 10036834 - Linux Platforms: Patches not found upgrading Grid Infrastructure from 11.2.0.1 to 11.2.0.2