According to the Xerox website the Phaser 6120 is not supported in Snow Leopard. However if one downloads the custom PPD file from the OpenPrinting database the printer works perfectly.

Full instructions follow:

On the 6120 page:

http://www.openprinting.org/show_printer.cgi?recnum=Xerox-Phaser_6120

Right click on Custom PPD to the right of Recommended driver and choose Download Linked File As….

In System Preferences -> Print & Fax click the + to add a new printer. Select your printer, wait for the system to choose “Generic PostScript Printer” under Print Using. Change Print Using to Other… and browse to the file you downloaded. The value in Print Using will change to Phaser 6120 PS. Click Add, check any options you have installed on your printer, click Continue and you are done.

On my system everything works correctly when printing over the network. I didn’t test USB but I have no reason to doubt that this driver will work for USB as well.

Be sure that you don’t have any pending changes in your workspace before executing these commands.

$ cd ~/my-git-repo
$ git symbolic-ref HEAD refs/heads/docs
$ git rm –cached -r .
$ rm -fr *
$ git commit –allow-empty -m “Initialized docs branch.”
$ git push origin docs

From: https://www.dns-oarc.net/oarc/services/porttest

$ dig @4.2.2.3 +short porttest.dns-oarc.net TXT

Replacing 4.2.2.3 with the IP address of your DNS server(s).

So I decided that for my needs the software RAID supplied by OS X would be sufficient. Off to Disk Utility to build the set. Disk Utility allows you to create a mirrored RAID array in a degraded state (preserving any data on the drive) and then add members to the array and rebuild. I created the initial array with a single partition member and then attempted to add the second partition only to receive Unrecognized Filesystem.

I guessed that this was an issue with the Disk Utility interface and not the underlying software RAID so I decided to give it a try from the command line. Sure enough it worked right away. Here are the commands to add a disk or partition to an existing software RAID array:

Be very careful when running these commands! If the wrong device is selected you can easily destroy an entire disk of data!

Get a list of device names with:

# diskutil list

Next find the Unique ID for your RAID array:

# diskutil checkRAID

Finally, add the new member to the array. Replace AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE with the Unique ID obtained above and diskXsX with the appropriate device:

# diskutil addToRAID member /dev/diskXsX AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE

The array should automatically begin to rebuild itself. You can check by re-issuing the diskutil checkRAID command. The rebuild status will automatically be shown if Disk Utility is launched.

I fully realize that this is very hackish and should not be used as a long term solution but it works in this case to eliminate user confusion until a real fix is found. All instructions assume file paths and conventions in CentOS but should work with minor modifications anywhere else this problem is encountered.

A bit of searching turned up xdotool, a command for simulating keyboard and mouse input using the X11 XTEST module.

I created an RPM spec file that will download and build and xdotool package, available here: http://pastie.textmate.org/162710

Once xdrtool is installed do the following:

1. Edit your /etc/X11/xorg.conf, add Load "xtest" to the Module section
2. Copy /etc/gdm/Init/Default to /etc/gdm/Init/:0
3. Edit /etc/gdm/Init/:0 to include something similar to this towards the bottom: 
   

   (sleep 1 ; xdotool mousemove 0 0 ; sleep 1 ; xdotool mousemove 640 450) &

This will cause the pointer to jump to the upper left corner of the screen and then back to the center just after GDM starts. At the moment this appears to reliably work around the problem.

I installed mod_auth_kerb and configured apache with the following directives in the /svn location:

AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbSaveCredentials On
KrbAuthoritative on
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP
KrbVerifyKDC On
Krb5KeyTab /etc/apache2/apache2.keytab

The /etc/apache2/apache2.keytab file contains the HTTP/servername@EXAMPLE.COM principle.

With the appropriate AuthZ configuration I was able to preform all operations as expected from Linux and OS X 10.4 (Tiger) clients. However on Leopard clients all operations resulted in:

svn: PROPFIND request failed on '/svn/reponame'
svn: PROPFIND of '/svn/reponame': 207 Multi-Status (https://example.com)

In the web-server logs everything seemed fine:

[client xxx.xxx.xxx.xxx] Access granted: 'princ@EXAMPLE.COM' PROPFIND reponame:/

So I set the neon-debug-mask = 138 in the [Global] section of ~/.subversion/servers and attempted the update again. Right at the end:

Running post_send hooks
ah_post_send (#1), code is 207 (want 401), WWW-Authenticate is Negotiate [output snipped]
gssapi: Not a Negotiate response!
Request ends, status 207 class 2xx, error line:
207 Multi-Status
Running destroy hooks.
Request ends.
svn: PROPFIND request failed on '/svn/reponame'
svn: PROPFIND of '/svn/reponame': 207 Multi-Status (https://example.com)

A bit more googling turned up a patch. So I downloaded the Apple sources form http://www.opensource.apple.com/darwinsource/tarballs/other/neon-8.tar.gz, decompressed them and applied a simple 1 line patch to src/ne_auth.c:

--- ne_auth.c.orig	2007-11-22 00:37:54.000000000 -0600
+++ ne_auth.c	2007-11-22 00:37:38.000000000 -0600
@@ -520,5 +520,5 @@
     int ret;

-    if (strncmp(hdr, "Negotiate", ptr - hdr) != 0) {
+    if (strncmp(hdr, "Negotiate", ptr - duphdr) != 0) {
         NE_DEBUG(NE_DBG_HTTPAUTH, "gssapi: Not a Negotiate response!\n");
         ne_free(duphdr);

After a quick compile and install (to a temporary root) I copied the new usr/lib/libneon.26.0.3.dylib file into /usr/lib [making a backup of the original of course] and now subversion works perfectly.

Bug is radr://5610623

conn = PGconn.open( 'host'    => 'host.domain.com',
                    'options' => 'sslmode=require' )

results in PGError: FATAL: invalid command-line arguments for server process. After digging at some forums and the ruby-postgres source code I found that one needs to prepend the options string with -o, so a working example is:

conn = PGconn.open( 'host'    => 'host.domain.com',
                    'options' => '-o sslmode=require' )

Quicken cannot create a copy of your file to upload to .Mac

Check to make sure you have sufficient free space on your hard drive and that you have permission to read and write files. Please try again later.

(014)

Apparently a previous run of the backup agent crashed and it left behind a temporary file that was preventing any further runs of the agent from completing. Simply removing the temporary file (which is automatically done on reboot) fixes the issue.

To fix the issue without rebooting just remove the Quicken Data.qdfm.dmg file from /private/var/tmp/folders.XXX/ where XXX (may be more than 3 digits) is your user id number.

For people not comfortable working with the command line you can reach this folder by:

1. Choosing Go to Folder… from the Finder Go menu (⇧⌘G)
2. Enter /private/var/tmp
3. Open the only folders.XXX folder that you have access to
4. Delete the Quicken Data.qdfm.dmg file

To get around this problem one can install SSL certificates that employ the subjectAltName extension.

To be deployed properly you will need to either be running your own certificate authority (beyond the scope of this document) or using commercially signed certificates. If you are purchasing certificates you should check with your CA first to see if they are willing to sign certificate requests that employ the subjectAltName extension.

Generating the Certificate Signing Request (CSR)

First edit the openss.cnf file (location may vary depending on OS) and add the v3_req extension. Locate the [ req ] section and add

req_extensions = v3_req

Next find the [ v3_req ] section and add a subjectAltName line containing the appropriate DNS names (in this case I will be using server1.example.com, ldap-1.example.com and directory.example.com):

subjectAltName = “DNS:server1.example.com, DNS:ldap-1.example.com, DNS: directory.example.com”

Generate a Private Key

To generate a CSR we need a private key, generated with the following command. This file should never be world readable and needs to be carefully protected.

# ( umask 077; openssl genrsa 2048 > server1-ldap-key.pem )

Generate the CSR

# openssl req -nodes -new -key server1-ldap-key.pem -out server1-ldap-req.pem

Answer the question prompts. When prompted for your Common Name enter the primary host-name of the system.

Signing the CSR

In order to include the extensions in the signed certificate the CA must be configured to copy extensions from the CSR. This is potentially dangerous if you do not fully trust the source of the CSR! You may want to enable it on a per-signing basis.

Locate the openssl.cnf file on your CA. Find the appropriate CA section (usually [ CA_default ]) and add or un-comment the following line:

copy_extensions = copy

Copy the server1-ldap-req.pem file to your CA and sign it with the following command:

# openssl ca -keyfile [path to CA private key] -in server1-ldap-req.pem -out server1-ldap-cert.pem

The presence of the subjectAltName extension can be verified using this command:

# openssl x509 -in server1-ldap-cert.pem -noout -text

Look for the X509v3 Subject Alternative Name: section.

Now just install the certificate and private key as you would with any other certificate/key pair.

A Few File Locations

• openssl.cnf:
  • Debian Linux: /etc/ssl/openssl.cnf
  • Mac OS X: /System/Library/OpenSSL/openssl.cnf
  • Solaris 10: /etc/sfw/openssl/openssl.cnf