Month: April 2012

Like many people, I am a big fan of Google’s mail and calendaring tools.  I run all my personal mail and calendaring through Google Apps Personal Edition as well as many of the other domains that I host and/or support.

The Zeta Gamma chapter of Phi Mu Alpha Sinfonia, of which I am a member, also uses Google calendar to keep up with the different events that we plan for the chapter.

This semester I noticed something different about the chapter’s calendar – the times were all off!  They weren’t off by a few minutes, but by several hours.  I talked to our chapter president, who is in charge of the calendar, about it and he said that it was working fine for him and that he didn’t see any issues with the times.

Turns out that it is an issue with the setting of the time zone for the Google calendar in conjunction with a setting in iCal on my Mac.  I connect iCal up to my Google account using CalDav so that I can have my personal calendars appear nicely without resorting to a browser.  Using iCal also lets me get, and set, alarms for events.

Well, I noticed after logging into the Google web interface that my personal calendars are set to GMT -5:00 (aka America/New_York aka Eastern Time), whereas the fraternity calendar has a set time zone of GMT +0:00 (aka GMT).  It just so happens that I also have timezone support enabled in iCal.

The timezone support feature of iCal allows you to set a time zone for each appointment on any calendar (local or not) that you have editing access for.  It just so happens that with timezone support turned on all the events on the fraternity calendar actually show the time using the timezone of the Google event, not my local timezone.  If I turn timezone support off in iCal, then like magic all the times are listed accurately.

So, if you use a shared Google calendar, get the owner to set the timezone correctly for their location, then your events in iCal will be automatically updated to reflect the timezone that your Mac is currently in.

During the migration of a production system from Solaris 10 to RedHat Enterprise Linux 5, I discovered that I had a problem with a couple of my LDAP scripts.  The commands being run were standard ldapsearch and ldapmodify commands in a format similar to the following:

ldapsearch -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password cn=foobar

ldapmodify -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password -f updates.ldif

Each time I ran the commands I got the following error:

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available:

It turns out that the versions of the ldapsearch and ldapmodify commands that comes with RHEL5 are based on the standard OpenLDAP code.  The OpenLDAP code defaults to expecting an SASL authentication mechansim on the server-side.  Given that the LDAP server I am connecting to is a iPlanet 5.1 LDAP server, it is not configured to understand the SASL authentication types.

The solution is to add the -x option to the commands:

ldapsearch -x -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password cn=foobar

ldapmodiy -x -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password -f updates.ldif

This command option specifies that the command should be executed using simple authentication instead of SASL.

During the migration of a production system from Solaris 10 to RedHat Enterprise Linux 5, I discovered that I had a problem with a couple of my LDAP scripts.  The commands being run were standard ldapsearch and ldapmodify commands in a format similar to the following:

ldapsearch -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password cn=foobar

ldapmodify -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password -f updates.ldif

Each time I ran the commands I got the following error:

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available:

It turns out that the versions of the ldapsearch and ldapmodify commands that comes with RHEL5 are based on the standard OpenLDAP code.  The OpenLDAP code defaults to expecting an SASL authentication mechansim on the server-side.  Given that the LDAP server I am connecting to is a iPlanet 5.1 LDAP server, it is not configured to understand the SASL authentication types.

The solution is to add the -x option to the commands:

ldapsearch -x -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password cn=foobar

ldapmodiy -x -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password -f updates.ldif

This command option specifies that the command should be executed using simple authentication instead of SASL.

One of the standard methods of configuring Mac OS X in the enterprise has become known as the magic triangle or golden triangle. This is generally described as a setup involving Active Directory (AD) for authentication of the clients and services and Open Directory (OD) for managing the client preferences.  The triangle comes from the fact that you have the Mac clients talking to AD, the clients also talking to OD, and the Mac server talking to AD. (Apple officially calls this the magic triangle setup in the Snow Leopard Server Open Directory Administration documentation.)

One of the issues I ran into was granting a non-admin in AD the ability to perform administrative functions on the clients bound to AD.  The way this is handled with the Windows clients is for the particular AD user to be a member of a group that grants local administrator privileges.

Unfortunately there is no simple equivalent on the OD side of the equation to allow this for the technicians working on the Mac OS X clients.  If you add an AD user to the system level group Open Directory Administrators using Workgroup Manager (WGM) this has no effect on whether a user is granted local administrator privileges to a connected client machine.

The solution to this involves:

1. creating a group in OD to hold the members of AD that should have local administrative privileges,
2. adding this OD group to the requisite local workstation groups to mimic the standard administrative privileges, and
3. adding the OD group to the sudoers file

Continue reading

While setting up Apache for Windows to use SSPI so that I could implement Alain O’Dea’s method of combining Active Directory authentication with SVN I ran into an interesting path problem.

After following Alain’s instructions I kept receiving the following error:

SSLSessionCache: Invalid argument: size has to be >= 8192 bytes

After some investigation it runs out that this is due to the way the path in the configuration file was being parsed.  This is partially due to my environment.  On Windows Server 2008 when installing a 32-bit application, the installer drops the files into C:\Program Files (x86)\… unless otherwise directed.

It turns out that the extra set of parenthesis was causing Apache to bomb out.  I tried wrapping the path in quotes, as well as falling back to the Windows 98 naming scheme of using C:\Progra~2\Apache Software Foundation\Apache2.2\… but that didn’t work out either.  What I ended up doing was making a shortcut on the root of the C: drive called apache that pointed to the contents of C:\Program Files (x86)\Apache Software Foundation\ making the final path in the configuration file:

C:/apache/Apache2.2/logs/ssl_scache(512000)

References

While setting up Apache for Windows to use SSPI so that I could implement Alain O’Dea’s method of combining Active Directory authentication with SVN I ran into an interesting path problem.

After following Alain’s instructions I kept receiving the following error:

SSLSessionCache: Invalid argument: size has to be >= 8192 bytes

After some investigation it runs out that this is due to the way the path in the configuration file was being parsed.  This is partially due to my environment.  On Windows Server 2008 when installing a 32-bit application, the installer drops the files into C:\Program Files (x86)\… unless otherwise directed.

It turns out that the extra set of parenthesis was causing Apache to bomb out.  I tried wrapping the path in quotes, as well as falling back to the Windows 98 naming scheme of using C:\Progra~2\Apache Software Foundation\Apache2.2\… but that didn’t work out either.  What I ended up doing was making a shortcut on the root of the C: drive called apache that pointed to the contents of C:\Program Files (x86)\Apache Software Foundation\ making the final path in the configuration file:

C:/apache/Apache2.2/logs/ssl_scache(512000)

References

While setting up Apache for Windows to use SSPI so that I could implement Alain O’Dea’s method of combining Active Directory authentication with SVN I ran into an interesting path problem.

After following Alain’s instructions I kept receiving the following error:

SSLSessionCache: Invalid argument: size has to be >= 8192 bytes

After some investigation it runs out that this is due to the way the path in the configuration file was being parsed.  This is partially due to my environment.  On Windows Server 2008 when installing a 32-bit application, the installer drops the files into C:\Program Files (x86)\… unless otherwise directed.

It turns out that the extra set of parenthesis was causing Apache to bomb out.  I tried wrapping the path in quotes, as well as falling back to the Windows 98 naming scheme of using C:\Progra~2\Apache Software Foundation\Apache2.2\… but that didn’t work out either.  What I ended up doing was making a shortcut on the root of the C: drive called apache that pointed to the contents of C:\Program Files (x86)\Apache Software Foundation\ making the final path in the configuration file:

C:/apache/Apache2.2/logs/ssl_scache(512000)

References

While setting up Apache for Windows to use SSPI so that I could implement Alain O’Dea’s method of combining Active Directory authentication with SVN I ran into an interesting path problem.

After following Alain’s instructions I kept receiving the following error:

SSLSessionCache: Invalid argument: size has to be >= 8192 bytes

After some investigation it runs out that this is due to the way the path in the configuration file was being parsed.  This is partially due to my environment.  On Windows Server 2008 when installing a 32-bit application, the installer drops the files into C:\Program Files (x86)\… unless otherwise directed.

It turns out that the extra set of parenthesis was causing Apache to bomb out.  I tried wrapping the path in quotes, as well as falling back to the Windows 98 naming scheme of using C:\Progra~2\Apache Software Foundation\Apache2.2\… but that didn’t work out either.  What I ended up doing was making a shortcut on the root of the C: drive called apache that pointed to the contents of C:\Program Files (x86)\Apache Software Foundation\ making the final path in the configuration file:

C:/apache/Apache2.2/logs/ssl_scache(512000)

References

Well, over the weekend some of the other sysadmins of the world provided the solution to the Office 2007 file download problems.

It’s all about the mime types. For those of you not in the know, a MIME type is an Internet Standard that is used to help webservers and e-mail servers know what kind of files are being served up and sent out. Check out the Wikipedia article for more.

So on an Apache webserver you need to add the following to your mime types file:

application/vnd.openxmlformats docx pptx xlsx

Thanks goes out to Vlad Mazek and his post on this one.

Now if only it was so easy for a Windows webserver running IIS. For the process on updating IIS, surf on over to the entry on David Oberton’s blog at a href=”http://uksbsguy.com/”>UK SBS Guy.

Tonight’s feature is a video of one of my favorite artists, Diana Krall.  This particular performance is from the live concert at the Paris Olympia Theatre in 2002.

Julie London’s performance of this Arthur Hamilton torch song was my favorite until I heard the sultry tones of Diana Krall performing it.

At work we currently use version 3.3.3 of the Luminis III platform by SunGard Higher Education.  This product handles our mail and portal needs for the time being.  While it is definitely not the best web-based mail client in the world I have seen worse.

Recently I had received a notice from a friend that he couldn’t read my signed e-mail in the web-client.  After having him forward the message to me as an attachment, I determined that the problem had to do with my digital signature.

I use Apple’s Mail client for OS X 10.5.  Currently I also have GPGMail by Stéphane Corthésy installed so that I can seamlessly use my GPG keys to sign and encrypt my e-mail.  After sending an unsigned message and finding out that it went through with no problems, I started investigating the options provided by GPGMail.

It turns out that I had checked the option to use OpenPGP/MIME by default.  Apparently this creates an message body that the Luminis III web-mail client can’t read.  So if you are running into this problem with a web-based client, check to see if your messages are going out as OpenPGP/MIME.