Monthly Archives: September 2005

Using the W drive

As of mid-September 2005, most of the WOU domain migration is complete, except for the website files. This will be done in a month or so, but meanwhile any access to the W: drive is more complicated than usual. Since the website files are still on the old domain (“Aviation”), you will need to map the drive with your Aviation password (In other words, what your password was before the migration.)

Here’s how to do this:

If you use a Mac, the old instructions should still work, as long as you remember to use your old password. If you use Windows, you will have to set up a special command file on your machine and run it every time you want to use the W: drive. If you work with multiple computers, you will need to put this file on a floppy disk or USB drive or some other means of portable storage. The file itself is only two lines of text. It must be plain text; do not create it with Microsoft Word unless you know how to save files as plain text. The easiest way to make the file is to open Notepad (Start Menu – All Programs – Accessories – Notepad) and type the following:

NET USE W: \\maverick_nt\wou_website$ /USER:aviation\username

Be careful to type the text exactly, except that instead of “username”, you need to put in your own username. For instance, if your username is jdoe, the first line would be:

NET USE W: \\maverick_nt\wou_website$ /USER:aviation\jdoe

Once you have typed both lines in, save the file onto your desktop as “mapw.bat” (without the quotes, obviously.) Actually, you can use any name, as long as it ends with “.bat”. If Notepad insists on adding “.txt” after the “.bat”, go ahead and save the file anyway, but before you do anything else, right-click the file, choose “Rename” from the context menu that pops up, and delete the “.txt” from the end. If you have done this correctly, the icon for the file will be a blue and white square with a yellow gear inside it. If you want to use the file on multiple computers, drag and drop it from your desktop to the floppy drive or USB drive you want to use it from.

When you are ready to use the W: drive, double-click the file. It will pop up a black window and ask you for your password. Enter in your old password from before the migration. If you do not remember this password, email Ron at with your full name, V-number, username, and a new password; the password will be changed and you will receive confirmation by email. After entering the password, the window should wait a few seconds and then say “The operation completed successfully.” If you get an error message instead, email it to Ron at; also copy both lines of your file in the email. (Do NOT send the file as an attachment!) Whether or not you got an error, the window should also say “Press any key to continue . . . ” on the last line. When you press a key, the window should disappear, and if you didn’t get an error, the W: drive will be be available in “My Computer.”

This is only a temporary situation. In a month or so, we will be moving the web files to the new domain (“MASH”) and then the W: drive should come up automatically as it did before. In that process, we will have to re-enter everyone’s access permissions; to ensure the least possible disruption, please email me now and tell me what parts of the website you have access to. (If you are a student, this will need to be confirmed by your faculty or staff supervisor, or the advisor of your club is you work woth a club website.)

None of this will affect public_html websites! Those have already been migrated along with the rest of your H: drive, and you still edit them by chening files in your public_html folder. You still access them on the web at (where “username” is your username, not the actual word “username”.) However, if your public_html website still doesn’t work, please email me at and let me know. Include your username if you aren’t emailing from your email address.


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.

Holy blog creation, Batman!

Well, I guess that joke kind of dates me. I’m still amazed, though; I just ran the mass blog creation script, and our server created 5102 blogs in only 25 seconds. Do we have fast hardware or what?

So now everybody at WOU has a blog. Yes, this means you, too. You can start it up by going to; use your normal username, but for now the password is the last four digits of your ID number (unless you already had a blog, in which case the password is still whatever it was before.) Hopefully within a few days we’ll set up password synchronization so that when you change your main password via the account lookup page it will also set your blog password.

For help getting going on your blog, take a look at the general blogging FAQ, and the WOU blog server FAQ (Part 1, Part 2)

Turning the corner on trackback spam

I think I’m finally turning the corner on all the trackback spam I’ve been getting; banning IP addresses seems to help.

I found a nice little shortcut that makes this stuff easier to manage. In the trackback list, just click on the IP address in the Source column. (In the comment list, you can click the little magnifying glass icon in the IP column for the same effect.) This gives you a filtered list of all the trackback pings (or comments) posted from that address; it makes it easy to just click the “check all” button to select them all, then “Delete” to send them all to the bit-bucket.

Furthermore, when you have this kind of filtered view of trackbacks or comments from a single address, the blog server also gives you a button to “Ban this IP”, so you can do that without having to copy the address and enter it separately on the banning screen.

Just thought I’d share that little tip.

Crunch time!

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.

So what is an LDAP database, anyway?

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.

Improved password synchronization

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.