I just looked and it's been over a month since my last post. Christmas and some vacation consumed some of that time, along with various projects.
A lot of software had security bulletins so I have been QAing upgrades and getting them installed. Firefox, Java, Flash and Acrobat Reader all got updates and they have been pushed into production and are working fine. Upgrade churn makes me really appreciate being able to upgrade from one centralized server. Pushing updates to workstations this often would consume many more hours.
I appreciated the comments and ideas from my last post, but we are going to continue with using OpenLDAP. All of the software we use has been tested with and support using this directory server. I kind of had to make the rounds on all of the places we are going to use LDAP and make sure that I got all of the fields that will be required. For instance, some software packages require that the first_name and last_name be split into unique fields, so I had to add them to the database. I believe now it's nearly finished and things are working as expected. Now to begin reaping the benefits of this data as noted in our other projects.
Both our nearly retired Evolution email software and the upcoming Zimbra software have the ability to search the address books for City employees. And both software packages allow for advanced searches. However, it's been my experience that unless it's one or two clicks, there won't be success with end users. They don't want to have to write commands to search for users, and won't even with clear instructions. Sometimes they want to search for job titles, and sometimes they want to quickly get a listing of all users in one particular department. Because users were not having success doing this with software, there were pockets of users creating their own paper copies of our City Directory/Address Book and manually doing updates. Obviously this isn't efficient. So to show off the LDAP data, I wrote a quick City Directory application to allow for quick and easy searches of the data, and to display employee photos. It's finished and we're seeing that it's already being used by a lot of people and usage is growing. Clearly this was an improvement area. The shot below shows the appearance: From the main screen you can enter a users first name, last name or job title and a search will be performed. You can also display all users in one particular department. Clicking on the user button brings up the detail screen (BLACK). The user screen shows all of their information, and also allows you to enter your own note (PURPLE) for this particular person. You can also check to see if they are online (RED) and if you so wish, send them a request to remote control their screen (BLUE). Very often we have employees who are supporting their own software systems or doing training, and it's been invaluable to offer the ability to remote control sessions from any City workstation in our multiple buildings.
In thinking how this would work, I decided against this doing a query to LDAP directly. Instead it loads the source LDIF files once at startup and loads all of the users into one big array. That way people aren't hammering LDAP with queries and response is immediate. It's not a big deal if their data is a few hours old. Possibly I'll add a few lines of code to rescan the data from time to time and build a new array, but I don't think it will be a problem.
** Yup, the screens need some UI love, as time allow. :)
Support Portal Creates LDIF Files
As mentioned in my last blog, we aren't going to get a "LDAP Administrator" employee, so we have to make due with our current staff. The best way to handle this in my view is to have multiple avenues of backup so that if something is errant, it can easily be repaired. There will be lots of us doing entries, and the possibility exists that mistakes will be made. The design is that our support portal creates LDIF files, which are stored on the server. There is a button (BLUE) which compares this data to the LDAP information and alerts them that fields need to be updated. At that point, a button will be clicked and the information will be logged and then inserted into LDAP (PURPLE). Having open source tools like python and Glade make these customized screens a snap. We can mold them to our current staffing size and skills, which is the case here.
PDFMod And MIME Helpers
PDFMod is a great software, but has gotten a bit crusty because it's not being maintained. It's not able to read in newer PDF files, of which we are getting more and more from outside contacts. We started to get an increase of support calls about PDF files that failed to import. I made a small change to the MIME help applications that open when you double-click on files, and we now offer a checkbox which allows the users to "downgrade PDF" before opening in PDFMod. This seems to solve the problem and our users were happy with the work around. PDFMod sure would be a top notch Linux application with just a small amount of love.
After a long process, we were able to purchase Zimbra and I literally got the final license key as I was typing this blog. The production server was built with Ubuntu Linux and was patched, Zimbra was installed and I'll put this key on today to eliminate the nag messages. I'm working with the Zimbra people on the best way to authentication and provision from LDAP and once that's done we'll start a wider beta testing process. It's exciting to have new email and calendaring and I think the users will be happy with the ability to gain access with any browser.
Testing LibreOffice 4.0; found and submitted several bug reports..many of which are already fixed. Starting to look over Alfresco again...this project will kick off again in a few months. Trying to get my head around GNOME 3 with thin clients, it doesn't support remote X as does GNOME 2...are we going to be moved in the direction of MATE?