It’s been a busy week so far. I finally got to all those web permission requests I’ve been needing to do; if you’re still waiting on one, please let me know, because it means your request has fallen through the cracks somehow. I also got a bunch of public_html websites fixed; I know I didn’t get all of them, so if yours still isn’t working, please let me know.

I made a bit of progress on the event calendar, but not as much as I would have liked. I think I can still get at least a basic version of it done, but it’s going to be close, considering I have one and maybe two meetings tomorrow and need to get the weekly FAQ ready.

Well, I was hoping to have it done sooner than this, but the event submission form is live. It feeds into the existing database (with a couple of extra fields kindly added by Summer.) Next I need to get the actual calendar display working from the database so they don’t need to code it by hand anymore. Plus I still have a stack of web requests I have to get to. Sorry, folks! I should be able to get to most of your stuff tomorrow.

OK, crunch time is starting to ease off, for me at least. I’ve still got a lot of random acount cleanup to do, including tracking down people whose V-numbers we can’t find.

Next week I get to work on the Public Relations event submission form and calendar display. That’s going to be interesting; I get to use the PHP scripting language, which I find a lot more fun to work with than the PL/SQL language that we’ve done a lot of our web development in. (My favorite programming language is still Perl… maybe I’ll talk about that sometime when I feel like really boring everybody. ;-} ) Another upside of PHP is that it’ll give the PR folks more control over the look and feel of the system without having to come to us for changes.

I have about a week’s window for that, and then I need to work on the Web migration. We’ve already got a new webserver running on a much faster box than the current one, and we need to get the website files moved over to it and its name changed so wou.edu leads there instead of the current server. The new server will feature an all-new search engine, which will hopefully be an improvement on the current one.

A bit of advance warning for the people who are reading this: we’re probably going to have to reset all the editing permissions on the website. They’ve gotten entirely too tangled over the last three years. I’m going to need to go to each department and find out who has permission to edit what, and make sure they are still able to do that on the new webserver. At least once that’s done, we’ll be able to get rid of thiose little batch files everybody has to run now to connect to the W: drive.

Anyway, I’ve worked my ten hours today, time to go enjoy my three-day weekend!

Bill asked us all to do an entry about training classes we’ve taken in the past year or so. I haven’t had time to do much of that, but I did do one: SunONE Directory Server LDAP Concepts. It was a mid-level summary of LDAP, and it taught me a lot that I’ve used ever since.

Wow, did I say it was crunch time before? I didn’t know what I was talking about. This is crunch time. Here’s what I’ve been working on:

• Cleaning up the LDAP database and making sure everybody has their ID numbers and other needed attributes added in (as of 3AM on Tuesday, only 19 people were missing ID numbers. Most of the ones I couldn’t find were because of multiple possibly matching records in Banner; if I call you and ask if your middle initial is L or J sometime next week; don’t be weirded out!)
• Entering newly registered students into LDAP. I need to automate this better, but I should be able to get a new batch in by Monday.
• A script to add new user accounts.

This last is the most interesting, not least because it’s actually something that doesn’t have to do with the migration! It replaces three old scripts that were needed to properly add user accounts on the old system, and does extra things like automatically creating a blog for each new user.
Anyway, I’ve been maxed out all week, so please accept my apologies if you’ve been waiting on a service request and I haven’t gotten back to you just yet. I have managed to get a fair number of individual requests don, but I just don’t have time to get each one of them done this week, unless I want to stay up after midnight every night. Next week I should be able to get to a few more, and the rest should hopefully be done soon after. I feel kind of bad about not giving the kind of service I wish I could, but at the moment there’s little I can do about it.

I’ve been talking a lot about LDAP here lately; as I promised, here’s more of an explanation.

LDAP stands for “Lightweight Directory Access Protocol”, which I’m sure makes it perfectly understandable right there (just kidding!) Strictly speaking, there isn’t any such thing as “an LDAP database”; any database could work, provided that it is tuned for very fast retrieval of information, and can be accessed using the standardized methods of LDAP. It is these standard methods that make LDAP special, and the data retrieval speed that makes it useful.

Because computers can’t do magic, a database has to give up something else in order to get very fast retrieval speeds; databases that work with LDAP generally sacrifice speed of updates. This is not really much of a problem since LDAP is designed to work with data that is not constantly changing. LDAP is ideal for storing lists of objects where each object has similar pieces of information that don’t change very often; for instance, all user accounts have a username, password, first and last name, ID number, email address, telephone number, etc. That’s where the name comes from:
Lightweight – it is quicker and easier to use than previous methods.
Directory – it works with information stored in lists, much like a phone directory.
Access – its primary purpose is to access data as opposed to changing it.
Protocol – it is a standard set of methods.
We use our LDAP database mainly to store user account information. Originally, only our email server stored accounts in the LDAP database, but as part of the migration, we are consolidating most of our user accounts for various systems into a few LDAP databases that synchronize with each other. Because LDAP provides standard methods to access data, many different programs and systems can use the same database of user accounts. This is what enables us to use the same password for email, network, FTP, forums, and other systems; they all refer to the LDAP database to check your password and other information.
LDAP provides good security as well; your password is encrypted so that even we can’t see it. That is why our account lookup system can only change your password, and not tell you what it is. Note that this system depends on your ID number being stored in the LDAP database as well, in order to verify that you are the owner of the account; a few people still don’t have their numbers in the system, so if you try the account lookup and it doesn’t recognize you, please contact the UCS service request desk and let them know your name and ID number so we can get your account fixed.
LDAP makes our jobs as system administrators easier, too; before, we had to create multiple accounts for every new person that came onto campus, but now things are much simpler. We don’t have to set up a separate login system for every web-database application anymore, since our Oracle database server can access the LDAP database for logins. And we don’t have to ask you quite as many questions if there’s some sort of login problem, because there are fewer user databases where a problem might exist.
As time goes by, more and more systems will be converted to use LDAP; for instance, this blog server, the purchase request system, and the Physical Plant service request system. Also, when we roll out our new WOU portal, it will also use the LDAP database, so you won’t have to create a new account and remember a new password in order to use it.
Hopefully this has cleared things up a bit! If you want to know more, please contact me or comment on this entry. As usual, Wikipedia has more, in this article.

Just today Summer, Travis, and I fixed the password synchronization between email and network logins. Well, not “fixed” exactly, because it wasn’t really broken; it just required someone to restart some software once or twice a day.

Now, when you go to the account lookup page, you will know for sure that your new password will work on both your email account and your network login. The only catch is that you have to wait (at most) five minutes for the change to take effect; we will make the change happen in real time as soon as we find a way to keep it from introducing a specific and sneaky little security hole.

Thanks to Summer for creating that account lookup system, by the way! I know there have been a few people who have had problems with it; almost all of those problems have been because we needed to enter information into the LDAP database, and not the fault of the account lookup system itself.

Once the domain migration is finished, I would like to convert more of our systems to use the LDAP account database. For instance, we could reprogram the blog server to look in the main LDAP database instead of its own separate one; this would mean that your email and network password would also get you into your blog administration page.

Thanks to the PL/SQL functions I’ve mentioned before, we could also do this with things like the UCS purchase request system, and the Physical Plant work request system. Ideally, you will only have to remember one or two passwords to do everything you need to do.

We would love to do this with Banner as well, but that would be hard. We would have to be pretty creative and/or sneaky to get that going, so for the time being, if you need to log in to Banner, you’ll need to remember a different password.

It’s getting down to crunch time here. Students will be back soon, and as UCS finishes up the migration for all those user accounts, I’ve been pretty busy programming scripts to automate parts of that process. (If we tried moving four thousand email accounts by hand, the migration wouldn’t get finished until next year!) So I’ve been setting up scripts for moving email accounts, changing entries in the email alias file (which is how our email system knows whether your mail needs to go to the old or the new system) and preparing user information so that unix accounts can be moved into an LDAP database.

I’ve also finished coding up a couple of generalized PL/SQL functions so our programmers can look people up in the new user database. This probably won’t mena much to most people, but if any of you programmers need more LDAP lookup functions, let me know. Want to be able to check if a user si faculty, staff, or student? Want to be able to do name or email address searches in LDAP? I can get you a function to do that kind of stuff.

When I have more time, I’ll post some more general blog entries about LDAP and other such topics, so everyone will have an easier time understanding the stuff I talk about here.

That’s it for now, though!

I haven’t been blogging much lately, as you can see. I’ve mostly been busy with the system programming side of my job. Here’s a brief list of the things I’ve done:

• Added LDAP server accounts for all students registered for Fall
• For all faculty and staff ccounts migrated so far, added some LDAP attributes that we missed in the migration (this is why the Account Lookup and Password Change feature didn’t work for some of you; hopefully this is all fixed now, but if it isn’t, please tell the Service Request Desk!)
• Worked on a procedure so that our Oracle web/database applications can talk to the LDAP database and easily use it for logins. (this means that more web applications that used to require their own logins will soon work with your email password, which is also now your network password.)
• Worked on a system to help us re-code our website. I’ll talk moreabout that later, but it’s a huge job! Once it’s done, though, it should make it easier for everyoen to create web pages with the WOU design.

I’ll try to come up with a more easily digestible explanation of some of this next week. Especially LDAP, since that’s becoming so important to my job lately. Hmmm, I should note that down as a possible FAQ topic for when I start sending those again….

Wow. It’s hard to remember to post here sometimes. I had a really busy week last week; mostly working on the new database system for the website.

On Friday, I came in for a meeting about the University Self-study that we need to do as part of our regular re-accreditation process. I’m one of the UCS representatives in the self-study group, and I expect I’ll have more to say about that later, but at the moment I need to get back to programming; I have some system administration scripts that need to be done by the end of the week.