The server out at Shannon-point has been replaced with a NW6.5 server on new hardware. I used the Migration Wizard to complete this migration, and as before I am really impressed with this tool. Back in the NW4.11 days I got the task of migrating a server to new hardware. In those days, pre-PKI, this was doable... if you worked at it. I've lost the TID, but I do remember that the TID itself had 93 steps to follow to ensure the migration of identity worked as planned.
Then I got to do the same thing (on the same server, no less) in NW5.1. By then Novell had released their first Migration Wizard tool, and wow. They automated all of the scut-work, and all you had to do was click things and rotate a few floppies when it came time for the NICI migration.
The NW6.5 version of it doesn't even have the floppy migration bit anymore. I had to be sure I had the right license-files in place so the users could connect once the identity was migrated, but it worked very well.
So here I was, trying to make myself a NW6SP5 build. I get it all built, I patch the server, the server reports all modules I installed in the patch installed as I expected. All is great! Except...
Novell NetWare 6
Support Pack Revision 04
(C) Copyright 1983-2003 Novell Inc. All Rights Reserved. Patent Pending.
Server Version 5.60.04 December 12, 2003
Novell eDirectory Version 8.7.3.2 SMP
NDS Version 10551.13 May 26, 2004
Wha? I check NWCONFIG and it shows the service-pack is installed alright. Then I get a thought. I check the date-stamp of SERVER.EXE. It most definately was not 5/27/2004. I check the CD I burned, and it isn't there. I check my directory that I built the CD from, and it isn't there.
Grumbling, I expand the patch again from the source-file and it isn't there. Watching the unpack I see a possible error and see that "server.exe" had some error associated with it. Curious, I go to a cmd-prompt and manually attempt to extract the file (nw6sp5e -e \nw6sp5e\startup\server.exe
for the curious) and get an "Access denied" error on extraction. This, unfortunately, looks familiar.
So I disable my virus-scanner, VirusScan Enterprise 8.0i, and try again. Comes right out. I turn the scanner back on, recreate the CD-project and get told that someone is using SERVER.EXE and it can't be added to the project. Sensing the pattern again, I turn off the scanner, put SERVER.EXE back in the project, burn the new CD, and turn the scanner back ON again.
I then patch server #2 and it comes up like it should.
Novell NetWare 6
Support Pack Revision 05
(C) Copyright 1983-2003 Novell Inc. All Rights Reserved. Patent Pending.
Server Version 5.60.05 May 27, 2004
Novell eDirectory Version 8.7.3.2 SMP
NDS Version 10551.13 May 26, 2004
Right, then. That's all good. I then manually copy SERVER.EXE to the server I patched yesterday and get it rebooted. Now it also comes up with the correct SP-revison.
It seems that McAfee VirusScan Enterprise 8.0i thinks server.exe is some form of malware from the name. This will need noting, as I routinely expand service-packs on my local machine.
I just had what looks to be my first successful attempt at creating a SP build with patches slipstreamed in. One of the cluster servers is now at NW6SP5 and that's where printing is located. My hope is that this will minimize one of the annoyances we've been experiencing of late.
Specifcally, one of the print-agents will throw a message of the sort:
"Life sucks. I'm stopping this agent for no reason"
Which works just like a circuit-breaker. The status still shows on, but it doesn't do anything. To get the printer-agent working again, you need to stop the agent then restart it. At which point things start processing again. This behavior could be the result of using post-SP5 NDPS modules (needed for PCounter to work right) with an SP4 machine. Hard to prove, so that's what I'm about to do.
Today we finally solved a mystery that had been plaguing us since we started moving some accounts from the old Exch2000 to the new Exch2003 servers. Suddenly some users were no longer able to "Send as" other users, even when they had full rights to the other user's box. This was sub-optimal.
I won't go into the troubleshooting steps because its embarrassing. But what we discovered is that in order to "send as" without having "on behalf of" show up in the From line, you need to grant the relevant group the "Send As" right in object-security. The Exchange rights have no bearing here at all, which is what threw us.
I can understand why this is the case. It is my experience that the higher up in an organization you get, the less direct interaction you have with your own mail and calendar. There is a 'people filter' in place to prioritize what you need to even notice. In order to facilitate that, groupware provides the ability to allow other users into your mailbox. No biggie. What is also needed is that even if they have 'full' rights to everything, they can't send mail AS you and thereby steal your identity. This is why there is a separate right for this feature.
For things like group mailboxes (e.g. "alumni", or "NewStudents") this is something we needed to know, since we do that far more often than the executive kind. No we'll get to see how many of our 'group' accounts have been using "send as" all along.
I was told to investigate moving our DHCP services from the current Microsoft system and into our Netware cluster. It turns out that DHCP is really easy to set up in a cluster.
Unfortunately, in order for DHCP to actually work it requires a replica containing the DHCP-objects on the local server. Since this is a cluster, that'd be on all DHCP-configured servers. And since cluster-nodes do good yoyo imitations, we're leary of doing that. Because of this, we may keep DHCP in MS or perhaps think about putting it on our Replica boxes. We'll see.
It would seem that myweb.students is being used in a class:
140.160.106.34 - - [14/Oct/2004:15:55:09 -0700] "GET /~usrname/cs101 HTTP/1.1" 404 303
Complete with click-on instructions. There are a couple of other accesses that have real usernames and not just a placeholder. But the "CS101" sort of gives this away as a beginners guide to making web-pages. I'm glad they're using it, I just wish I knew about it yesterday. We had some 'fun' between 3-4pm yesterday that took myweb.students out of whack for about an hour.
I've been banging on our student printing infrastructure for a few days now trying to get a handle on the kinks we've been experiencing. While I was doing this yesterday I came across an oddity.
One one printer-pool, we had 10 jobs queued up. One of the printers was having paper-jams all day, so the other printer was having to handle the load. I look at the printer in question and I get:
COPY 40 OF 50
Dur? I check the queue itself to see what, pray, that could be. I find a job sized about 5.2MB, with 5 pages. Quick math tells me that should result in 250 pages, and would really explain why there was a backup in the queue. Such jobs should never hit printer since we set our PCounter to drop jobs with more than 50 pages in 'em. Unfortunately, the job clears before I can grab the spool-file. PCounter records exactly 1 page as printed. One?? HOW!
Since the pcounter log recorded the URL of the PDF involved I knew the original document to use. So I headed to that particular computer lab early this morning and grab the same workstation to see if I can reproduce this fun feature. No go. No matter what permuation of driver and driver-settings, the NDPS queue correctly identifies how many pages are emerging. The only thing I can think of is that it was set to print four-up, duplex for the first eight pages of the document. That would create a spool file about the right size. But the copy 40 of 50 thing still throws me. That sort of thing IN GENERAL is supposed to be frowned upon. Also unfortunately, the PCounter logs for that printer before this job went through show no obvious big stuff.
So either someone has figured out a way to print off way too many jobs and defeat our accounting, or the status reported was really old somehow. Most odd.
I saw this morning in a national weekly magazine an ad that made me shake my head. It featured text, "virus that erases your hard-drive", in amongst the rest of the ad. And the ad had lots of yellow in it. Just so you know.
Stuff like this makes me twitch. I realize that readers of this particular magazine aren't as sophisticated with regards to viri as readers of Information Security are, but still. Some things just grate no matter what they are. Like the violation of the Space Is Big principal in movies.
Computer viruses follow, unsurprisingly, epidemiological trends when it comes to 'lethality'. To take a real world example, lets look at Syphilis. When syphilis was first introduced into the human population it was much more lethal than the form we know of today. One of the ways it changed was to lengthen its incubation (i.e. prime infectious time) and reduce the percentage of death amongst people who contract it. In the beginning, the lethality rate was 100%. These days the survival rate of untreated syphilis is pretty high. This is because killing your host is not a good survival strategy for viruses; if you are going to kill them off, at least make the incubation time long enough to infect lots of others (AIDS) or be infectious enough that anyone that comes within so far of the dead body is likely to be infected too (Ebola).
Computer viruses follow these trends too. Successful viruses do not nuke (format the hard-drive of) their hosts, they lay dormant and spew copies of themselves. Some do perform data modification on the infected host, but these are relatively rare. Worms such as Nimda and Slammer had their own ways of causing annoyance; Slammer clogged networks, Nimda replaced image files with copies of itself. The last well known, wide spread format-your-hard-drive virus was back in the days when floppy-disks were a prime infection vector for viruses. I.e. the dark ages.
The idea behind them was simple. Release a bug that infects by boot-sector (or .exe/.com infector). Time-bomb it so that if the system-date is a specific date, the payload delivers and Bad Things Happen. There were scares from these, but I personally haven't heard of any wide-spread damage from them. Like I said, virus-writing in those days was pretty primitive.
That kind of thing is a lot harder to get away with these days. As worms such as Nimda and Slammer have proven, mass propagation as fast as possible is a very good way of defeating the Antivirus-vendor definition cycle. With pressures like that, the AV companies are getting better and better at identifying infectious material and deploying countermeasures pretty quickly. If the theoretical virus-writer writes a timebombed payload that includes "format c:", the AV community will know about the virus as soon as it gets widely spread enough, and the AV community will reverse-engineer it to find out what it does. Said virus-writer has to be very sure of his infection vector working well enough to get enough hosts infected before the major vendors get definitions out that clean up the bug. Too long, and only the badly managed systems (home users typically, these days) will get nailed by it. Too short, and critical mass wouldn't have been reached and the virus kills itself off.
A far more effective campaign, in my opinion, would be to put the fear into the reader that their PC might be part of the SPAM problem. It is proven that some viri turn infected hosts into spam-relay stations. And heck, everyone hates spam. And it'd cause my teeth not to grind as much.
Current Time: Tuesday, 05-Oct-2004 11:11:52 PDT
Restart Time: Wednesday, 22-Sep-2004 10:09:23 PDT
Parent Server Generation: 3
Server uptime: 13 days 1 hour 2 minutes 28 seconds
Total accesses: 21832 - Total Traffic: 5.6 GB
.0194 requests/sec - 5.2 kB/second - 268.4 kB/request
All in all, not that busy so far.