I’m terribly disappointed that I won’t be able to make it, but I wanted to pass it on: There’s an Alfresco/Liferay Meetup in Ontario, California on July 18th. The format will be a collection of small roundtables. It should be a great opportunity for people who are exploring Alfresco and Liferay (together or separately) to learn more and for others to share their knowledge and experiences. If you are on or near the West Coast you should check it out. Learn more and sign up at http://web.meetup.com/44/.
Today the Optaros web site has a press release announcing that Alfresco has made us a Platinum partner of theirs. We’re obviously very excited to earn this distinction and we look forward to continued delivery of critical solutions built on Alfresco. The press release also briefly mentions a solution we built for the Swiss Federal Court.
You can read more about how we work with Alfresco here.
Getting Alfresco to authenticate against LDAP is a pretty straightforward task that’s documented on the Alfresco wiki. But this week I’ve had to play around with a few specific implementation details beyond just users in a directory with plain-text passwords and simple authentication. Here are some rough notes that might save others some time.
- If “admin” is still your administrative user, don’t forget to set up a corresponding entry for the admin user in your LDAP directory.
- “Simple” authentication works when OpenLDAP stores either plain text passwords or MD5 passwords (Base64-encoded). If your MD5 passwords happen to be in hex you can convert them to Base64 using your favorite programming language. I used perl.
- “DIGEST-MD5” authentication works when OpenLDAP stores plain text passwords but I could not get it to work when using MD5 passwords.
- “DIGEST-MD5” authentication only works when OpenLDAP is configured to support DIGEST-MD5 as a SASL mechanism. Query the LDAP server’s “Supported SASL Mechanisms” property to see if DIGEST-MD5 is listed.
- If you are compiling OpenLDAP from source, you must configure it with the –with-cyrus-sasl flag. In order to be able to do this, you must already have Cyrus SASL installed.
- There are two ways user home folders can get created: (1) When a user logs in for the first time, but before a user sync has occurred or (2) When a user sync occurs. How the user folder gets created is configured differently in each case. In the first case, the bean referenced by the defaultProvider property of the homeFolderManager bean configured in authentication-services-context.xml is used. For the sync, the cm:homeFolderProvider key value in the ldap authentication context XML file references the HomeFolderProvider bean. If you want the behavior to be consistent, you’ll need to make sure to point to the same HomeFolderProvider bean in both places.
- There are several HomeFolderProvider beans configured OOTB. For example, the userHomesHomeFolderProvider bean creates the user’s home folder as a folder under User Homes named using the user’s user ID.
- If you want to store a password in SASL’s database, use saslpasswd2 -c
- If a user does not exist in SASL’s database it will look for the userPassword attribute in the LDAP directory.
- You must add authz-regexp entries to slapd.conf to map the SASL authorization requests to actual LDAP entries.
- Once your openldap server is running with SASL enabled, you may need to use the -x command-line switch when using things like ldapsearch, ldapadd, and ldapmodify if you still want to use simple authentication.
If I get some time I may reorganize these rough notes into an easier-to-follow step-by-step setup guide.
From a post McGee’s Musings, a link to an interesting-looking design tool called DENIM.
While my laptop remains and has always been Ubuntu, my two home machines are Windows XP. On the older box, the one I’ve surrendered to the kids, there’s really no excuse. They really only use the internet at this point and they could easily adapt to the change in interface so its days are numbered.
The newer XPS box has a bit more longevity due to some of the apps we use. I’ve been using Windows Movie Maker a lot, but I’d easily give it up for Kino or Cinelerra. The current sticking point is Media Center. The XPS box is our DVR which we connect to from our XBox 360. I hate to give up that setup (Yes, I know about MythTV).
Anyway, a week ago the XPS box started showing symptoms of the MSBlast worm. It went from bad to worse very quickly and ultimately became totally unusable. It couldn’t even stay up long enough for me to troubleshoot the problem.
At that point it was Ubuntu to the rescue! I booted off the Ubuntu live CD, mounted the Windows partition, rsync’d everyone’s data directories to my LaCie drive, and then used Dell’s built-in Symantec disk restore to put the disk drive in the exact state it was in when the machine was delivered. After copying the data back to the machine I’m up-and-running and no worse for the wear. Thanks, Ubuntu!
GAIM, the multi-protocol, cross-platform instant messaging client has changed its name to Pidgin. If you’re looking for the “Jabber” entry in the protocol list, it’s been replaced by the name of the protocol that Jabber speaks, XMPP.
According to CMS Wire, Java-based blog server Roller has graduated from the Apache incubator. At Optaros, we’re doing some work for a client right now that involves implementing Roller as one component of the company’s Enterprise 2.0 initiative. Their Enterprise 2.0 stack includes Liferay for portal/presentation services, Alfresco for portal content, documement, and web content management, Roller for internal and public-facing blogs, and Confluence for internal wiki.
So far, Roller has been relatively straightforward to integrate with Liferay, but in the initial phase we’re doing very light integration. It essentially involves skinning the Roller UI so that the experience will be fairly seamless as portal users move from the RSS portlet to Roller (for example, when they comment on a blog post). In a later phase we hope to implement a much tighter integration, perhaps through Roller-specific Liferay portlets.