Tag: ldap

Is Ubuntu Ready for the Enterprise?

rthomson 1 Comment

Yep, the title is click bait intended to grab attention… well as much of click bait as anything on techslaves.org can be (which is decidedly not very much) but I’ve just been pretty frustrated with Ubuntu as a client OS recently.

There are two really annoying and critical bugs that have been sitting around, unresolved for too long. One revolves around the NFS client. Apparently there was a regression in the mainline kernel at version 2.6.27 that causes NFS lockup/freeze. Both 10.04 and 10.10 have been affected but Ubuntu has yet to release the fix although it’s been available since august in the mainline kernel. The second bug revolves around Network Manager and autofs maps in LDAP. Basically, you have to get Network Manager to “autofs reload” every time it brings up or down the network interface. No big deal as this can be scripted, but I would really expect an official fix for this.

Ok, so it’s not Ubuntu’s fault there was a mainline kernel regression regarding NFS client code and it’s not Ubuntu’s fault that Network Manager behaves the way it does. However, I do expect a Linux vendor that considers themselves ready for the Enterprise to be able to backport critical kernel fixes so that their users don’t have to sit around waiting with their thumbs up their asses until the fix makes it’s way into an official kernel release and then into an Ubuntu kernel update. As for the autofs maps in LDAP/Network Manager issue, I would not only expect an enterprise ready distribution to have tested this functionality before release but also that once it’s reported that a real, official fix released quickly that everyone can use instead of having to follow bug report comment suggestions to get things working.

I realize Ubuntu is mainly a desktop OS. That’s ok. But all this “Ubuntu is ready for the Enterprise!!! GO CANONICAL!!!!” stuff simply can’t be justified when two official releases in a row come up with show-stopping bugs and there still isn’t a fix nor an official recommended workaround.

</rant>

wxPython is Kicking my Ass!

rthomson Leave a comment

Let me preface by saying that I’m not a programmer nor software developer nor anything of the sorts. I’m a sysadmin with scripting skills to solve automation problems, for the most part. I took all the C++ classes in High School but I never pursued software development as a serious academic interest or career. I know “about” software development and it’s practices but I don’t feel that I have any particularly interesting skills in the field.

Now that I want to write a site-specific GUI-based LDAP management tool as referenced in a previous post, I’m jumping back into software development a little bit. I’ve decided to use wxPython for a few reasons. We already use it within our group, we have in-house expertise in the form of an actual developer and the GUI-builder tools seem to work best with wxPython (wxGlade was producing bad wxPerl code, go figure).

Let me also say that I’ve never been a big python guy. I’m really a perl kind of dude, so this learning a new object oriented API while learning python at the same time is a challenge… but I’m making progress! Basically, wxPython seriously kicked my ass for about 3 days but now I’m gaining speed and things are moving faster than I expected. Python and wxPython are starting to make more sense and behave.

So far I have a frame with menubar, statusbar and a three-tabbed notebook with a grid on each tab of the notebook. The program is able to connect to an LDAP server (with TLS) and query the directory for all the users, groups and autofs information and then display that information in the grid… and that’s about it so far. I need to build in new user, group and autofs functionality as well as basic editing of existing entries (in place editing with wx.Grid looks really nice but I haven’t tried it yet!).

Although my ass has been kicked for the last few days, I’m actually feeling pretty optimistic about it now.

Hopefully I can share the kludge code at some point, though it will never be easily transportable to different environments since I’m not building this to be the end-all-be-all LDAP user/group/autofs management tool, just one tailored for our environment.

Migration Weekend: Success

rthomson Leave a comment

It was a long weekend of watching tape restores and restarting them as necessary but it’s finally over and everything appears to be mostly hunky dory!

I did discovery yet more small misconfigurations and strange behaviour along the way:

  1. OpenLDAP’s syncrepl using “refereshAndPersist” wasn’t working how I expected it to, no new changes were replicating to the slave LDAP server! I changed the directive to “refreshOnly” and set a 10 minute interval. I made several changes and monitored the slave LDAP server. Changes propagated in about 10 minutes, every time.
  2. Despite iSCSI’s maturity and the maturity of QLogic’s HBAs I still noticed strange, unexplained target drop outs. Two HBAs per server, two controllers in the IBM DS3300 and just one target out of four was dropping. At first, I couldn’t figure out how to properly reconnect the target on a live system so I rebooted. Later, I discovered you can “disable” and then “enable” the specific target in SANsurfer or iscli, which worked to bring back the dropped target on a live system. Multipath picked up the “new” path right away, as expected.
  3. Always remember to leave free physical extents in any LVM Volume Group in which you are taking snapshots of the Logical Volumes. It’s freakin’ obvious but I forgot and when I went to do snapshot backups, the snapshots were failing. Now I’m growing some LUNs on the DS3300 so that my VGs have room for snapshots.

All in all, a good weekend that was mostly filled with success.