Solaris 10 and above and Red Hat Enterprise Linux (RHEL) 5 and above have support for NFSv4. Unfortunately, how each OS handles the newest version is different, and the way it is mounted is drastically different.

How each OS handles NFSv3 and NFSv4

All Linux distros treat NFSv4 as a different filesystem. Solaris treats NFSv4 as a newer version, which is the sane, and sensible way of handling it IMO; thanks Linux…. To mount an NFSv4 filesystem in RHEL 5, you mount it the following way:

mount -t nfs4 <server>:<share> <mountpoint>

For NFSv3, you mount it the following way:

OS X has a somewhat non-standard VNC implementation in ARD, and I have problems with it locking up, and not letting me back in. Thankfully, this service can be restarted remotely if you can still SSH into the system.

The ARD service is controlled by launchd, and will restart automatically if killed. To relaunch the service, simply run the following command (you must be an admin, or root):

killall ARDAgent

Pat Patterson, from Sun Microsystems, has released a quick proof of concept of an OpenSSO authentication plugin for MediaWiki. This could be a really useful plugin for any organization that has decided to go the Web SSO route. If you aren’t familiar with OpenSSO, and you maintain a number of applications with some form of cookie trusted mess, or multiple logins, I highly recommend checking it out.

I was actually planning on writing this extension, and haven’t had time to get to it. I’ve asked Pat if I can test, clean up, and maintain his extension in Wikimedia’s SVN.

Recently, I deployed OpenSSO as a web single sign on service for a number of web servers, one of which was running MediaWiki. I haven’t yet written a SAML2 plugin for MediaWiki, so I am running an OpenSSO web agent for Apache, with the LDAP plugin doing auto-authentication.

After deploying the web agent, MediaWiki started parsing things incorrectly. Wiki-syntax like:

== Test ==
== Test2 ==
=== Test 3 ===

Was being corrupted, and turning into something like:

I’m a masochist, and subscribe to the entirety of Sun Microsystem’s blog feed. At least 90% of that content is completely worthless to me; however, the 10% that is worthwhile is usually really worthwhile.

This post about managing certificate trust flags in Network Security Services (NSS) databases is part of that 10%, and is the kind of thing everyone dealing with NSS should read. It is crazy that this information is missing from Mozilla’s documentation on certutil; this really makes the trust flags clear!

BarcampNOLA created a website for the New Orleans Recovery School District on their second day. This post is for tracking bugs related to that site.

Please leave any open bugs/issues/changes needed in the comments.

In part 1 of this series, I discussed basic password authentication for Active Directory (AD). In this article I will discuss enabling group restrictions and synchronization, and retrieving preferences for AD. I’ll first discuss group restrictions, then synchronization, then retrieving preferences.

Group restrictions and synchronization will require you to somewhat understand the LDAP structure that your AD environment is built upon. Don’t worry, this isn’t as scary as it sounds, and I’ll explain how to find all of the information you’ll require.

If, like me, you have had issues with replication in Sun Directory Server, maybe this post will help.

The dsadm list-certs -C command will show you what CA certificates you are trusting, but it won’t show you how it is trusting a certificate. If you are getting an error like “Bind failed with response: Failed to bind to remote (900).”, and you know SSL should be working properly, you probably want to check to see exactly how your CA certificates are being trusted.

To do this, use the certutil command:

For some corporate wikis, it is beneficial to allow anonymous edits; however, anonymous edits in MediaWiki track IP addresses, and in most corporate environments, it is simple to identify a user simply by knowing what IP address they came from. Also, most corporate environments are opposed to allowing non-authenticated write-access to any resource (for good reason).

So, if you wanted to have a wiki, like a wiki for polls, that needed some form of anonymity for users to trust using it, using the LDAP Authentication extension in a clever way can allow you to do this.

In part 1 of this series, I discussed basic password authentication for Active Directory (AD). In this article, I will discuss basic password authentication for LDAP domains with the posix schema.

For basic password authentication against an LDAP domain with the posix schema, you need to configure three or four things:

1. Domain name
2. Server names
3. How to bind to the LDAP servers
4. The proxy user used to find your user accounts (optional depending on your environment)

Prerequisites

Please see and complete the “Create a local sysop”, and “Enabling the plugin” sections of part 1 before proceeding.