Open LDAP
All records and data have been loaded and are working. After reviewing Alfresco, Zimbra, WiFi and proxy device, I believe we worked out all of the required information and it's all ready to go. We always knew this would reduce work, but normally would need a specialized employee to run the infrastructure. Since we aren't getting more staff, we have to get creative in solving these types of problems; how best to deploy technology that really should have additional IT staff?
LDAP Portal Integration
The solution as I touched upon last blog was to write some code so it's maintained from our Support portal software. Our Support group enters the information and it's verified and formatted consistently and then required fields are uploaded to OpenLDAP. In order to have multiple levels of fallback, all information is stored in LDIF files, staged and then uploaded. If something happens to a user record, we can always recover the data.
The shot below shows the portal screen information is entered and saved in LDIF files, it's then compared against LDAP and allows for update when data has changed. This code is live and seems to be working.
With the contact information working, the next step was to make it very simple to grant permissions to various authentication functions. So under the Licenses tab a small section was added with checkboxes. Click them and update LDAP and everything else is handled automatically. Available options are Zimbra, Firefox (Proxy), WiFi and Alfresco. We are enabling auto-provisioning on the various sub-systems on our network. No more having to maintain hundreds of user accounts, efficiencies gained.
City Directory
As mentioned in my last blog, the first use of the LDAP/LDIF data was a quick "City Directory" screen that allows users to search by name and job title. This information was already available in a less user friendly way via Evolution and in Zimbra, but they just aren't locating the data. The support portal tracks software usage, and this application has been used 678 times already in about 2 months. This tells me that people were really struggling to find this information and were probably maintaining their own phone number documents. Very happy to see this much usage for a few hours of coding.
LibreOffice 4.0: I did not install 4.0.0, and wanted to let others find any major bugs that might exist. 4.0.1 is just a few days away, and I'll install when it's released. It will be nice to have initial CMIS, and additional document filters. I don't expect any significant issues.
NX and Mac Clients: We have been struggling with the fact that production NX doesn't have Mac clients for Lion/Mountain Lion. More and more users are getting this operating system and no user friendly solution is available in the short term. This issue will be resolved with NX 4, which is still a beta product. What we are going to do is create a virtual copy of our GNOME server and install the 4.0 beta server piece and use that for Mac users until the product is officially released. Unfortunate loss of man hours for me having to do this, but Mac usage seems to be increasing all the time for home users and we need to get them working.
Zimbra Email: 800 accounts were created automatically with Auto Provision and LDAP, which is simply wonderful. Within a few minutes of the connection forming, they were all done. This would have taken days to do by hand. We're testing the infrastructure right now with web browsers, phones, tablets and pushing email and everything seems to be working. We're targeting a mid-April deployment.
Quick Updates: Patches and QA for Java, Firefox, Flash and Adobe Reader. At least one of these 4 products seem to have a security update every week. HP discontinued the t5745 thin client and released a new 64bit model, will have to find some time to check it out and look at how to get our code installed. Never enough hours in the day sadly.
3 comments:
Why are you building GUI applications when the direction for this sort of thing are web apps. The organization I work for has the exact same stuff you just built only it is a web app so then we're not limited to what device we can run it on. Just seems like you're doing things in a very 1999 sort of way.
@anonymous: I understand that point of view, but there are some different dynamics here. Developing GTK applications for client/sever (whereby each users has their own computer) is very labor intensive. In the case of client/server one would write a web application and reduce development costs and time. In our case though, GTK applications run thinly to any device and operating system via remote X or NX. When it works for me, it works for everyone. Web applications have a higher level of support. Multiple browsers and operating systems come into play. Even if we do write only for Linux/Firefox, I get new versions of browsers every few months with nuances that have to be tested. GTK applications that I write are done very quickly and can literally run years without ever being touched again. No part of the GNOME/desktop server is upgraded in a way that affects how they work. So there are considerations about our network design, and staffing size.
PS: and I should note too that browser applications have been a nightmare to maintain. We have some inhouse and cloud applications from various vendors; and it's very common that a Firefox upgrade will break something. And also, they have different levels that have been certified. One vendor is only certified to run on Java 1.6.24. Very often dialogs that they have written open in different positions and in different sizes when FF is upgraded. It's really been kind of a nightmare for us. So I guess it didn't seen pleasant at this time to also have to fight internal web based software :)
Post a Comment