Wednesday, September 30, 2009

I have a degree in this stuff

I have a CompSci degree. This qualified me for two things:
  • A career in academics
  • A career in programming
You'll note that Systems Administration is not on that list. My degree has helped my career by getting me past the "4 year degree in a related field" requirement of jobs like mine. An MIS degree would be more appropriate, but there were very few of those back when I graduated. It has indirectly helped me in troubleshooting, as I have a much better foundation about how the internals work than your average computer mechanic.

Anyway. Every so often I stumble across something that causes me to go Ooo! ooo! over the sheer computer science of it. Yesterday I stumbled across Barrelfish, and this paper. If I weren't sick today I'd have finished it, but even as far as I've gotten into it I can see the implications of what they're trying to do.

The core concept behind the Barrelfish operating system is to assume that each computing core does not share memory and has access to some kind of message passing architecture. This has the side effect of having each computing core running its own kernel, which is why they're calling Barrelfish a 'multikernel operating system'. In essence, they're treating the insides of your computer like the distributed network that it is, and using already existing distributed computing methods to improve it. The type of multi-core we're doing now, SMP, ccNUMA, uses shared memory techniques rather than message passing, and it seems that this doesn't scale as far as message passing does once core counts go higher.

They go into a lot more detail in the paper about why this is. A big one is hetergenaity of CPU architectures out there in the marketplace, and they're not just talking just AMD vs Intel vs CUDA, this is also Core vs Core2 vs Nehalem. This heterogenaity in the marketplace makes it very hard for a traditional Operating System to be optimized for a specific platform.

A multikernel OS would use a discrete kernel for each microarcitecture. These kernels would communicate with each other using OS-standardized message passing protocols. On top of these microkernels would be created the abstraction called an Operating System upon which applications would run. Due to the modularity at the base of it, it would take much less effort to provide an optimized microkernel for a new microarcitecture.

The use of message passing is very interesting to me. Back in college, parallel computing was my main focus. I ended up not pursuing that area of study in large part because I was a strictly C student in math, parallel computing was a largely academic endeavor when I graduated, and you needed to be at least a B student in math to hack it in grad school. It still fired my imagination, and there was squee when the Pentium Pro was released and you could do 2 CPU multiprocessing.

In my Databases class, we were tasked with creating a database-like thingy in code and to write a paper on it. It was up to us what we did with it. Having just finished my Parallel Computing class, I decided to investigate distributed databases. So I exercised the PVM extensions we had on our compilers thanks to that class. I then used the six Unix machines I had access to at the time to create a 6-node distributed database. I used statically defined tables and queries since I didn't have time to build a table parser or query processor and needed to get it working so I could do some tests on how optimization of table positioning impacted performance.

Looking back on it 14 years later (eek) I can see some serious faults about my implementation. But then, I've spent the last... 12 years working with a distributed database in the form of Novell's NDS and later eDirectory. At the time I was doing this project, Novell was actively developing the first version of NDS. They had some problems with their implementation too.

My results were decidedly inconclusive. There was a noise factor in my data that I was not able to isolate and managed to drown out what differences there were between my optimized and non-optimized runs (in hindsight I needed larger tables by an order of magnitude or more). My analysis paper was largely an admission of failure. So when I got an A on the project I was confused enough I went to the professor and asked how this was possible. His response?
"Once I realized you got it working at all, that's when you earned the A. At that point the paper didn't matter."
Dude. PVM is a message passing architecture, like most distributed systems. So yes, distributed systems are my thing. And they're talking about doing this on the motherboard! How cool is that?

Both Linux and Windows are adopting more message-passing architectures in their internal structures, as they scale better on highly parallel systems. In Linux this involved reducing the use of the Big Kernel Lock in anything possible, as invoking the BKL forces the kernel into single-threaded mode and that's not a good thing with, say, 16 cores. Windows 7 involves similar improvements. As more and more cores sneak into everyday computers, this becomes more of a problem.

An operating system working without the assumption of shared memory is a very different critter. Operating state has to be replicated to each core to facilitate correct functioning, you can't rely on a common memory address to handle this. It seems that the form of this state is key to performance, and is very sensitive to microarchitecture changes. What was good on a P4, may suck a lot on a Phenom II. The use of a per-core kernel allows the optimal structure to be used on each core, with changes replicated rather than shared which improves performance. More importantly, it'll still be performant 5 years after release assuming regular per-core kernel updates.

You'd also be able to use the 1.75GB of GDDR3 on your GeForce 295 as part of the operating system if you really wanted to! And some might.

I'd burble further, but I'm sick so not thinking straight. Definitely food for thought!

Labels: , , , , ,


Friday, September 25, 2009

More thoughts on the Novell support change

Something struck me in comments on the last post about this that I think needs repeating on a full post.

Novell spent quite a bit of time attempting to build up their 'community' forums for peer-support. Even going so far as to seed the community with supported 'sysops' who helped catalyze others into participating, and creating a vibrant peer support community. This made sense because it built both goodwill and brand loyalty, but also reduced the cost-center known as 'support'. All those volunteers were taking the minor-issue load off of the call-in support! Money saved!

Fast forward several years. Novell bought SuSE and got heavily into Open Source. Gradually, as the OSS products started to take off commercially, the support contracts became the main money maker instead of product licenses. Just as suddenly, this vibrant goodwill-generating peer-support community is taking vital business away from the revenue-stream known as 'support'. Money lost!

Just a simple shift in the perception of where 'support' fits in the overall cost/revenue stream makes this move make complete sense.

Novell will absolutely be keeping the peer support forums going because they do provide a nice goodwill bonus to those too cheap to pay for support. However.... with 'general support' product-patches going behind a pay-wall, the utility of those forums decreases somewhat. Not all questions, or even most of them for that matter, require patches. But anyone who has called in for support knows the first question to be asked is, "are you on the latest code," and that applies to forum posts as well.

Being unable to get at the latest code for your product version means that the support forum volunteers will have to troubleshoot your problem based on code they may already be well past, or not have had recent experience with. This will necessarily degrade their accuracy, and therefore the quality of the peer support offered. This will actively hurt the utility of the peer-support forums. Unfortunately, this is as designed.

For users of Novell's active-development but severe underdog products such as GroupWise, OES2, and Teaming+Conferencing, the added cost of paying for a maintenance/support contract can be used by internal advocates of Exchange, Windows, and SharePoint as evidence that it is time to jump ship. For users of Novell's industry-leading products such as Novell Identity Management, it will do exactly as designed and force these people into maintaining maintenance contracts.

The problem Novell is trying to address are the kinds of companies that only buy product licenses when they need to upgrade, and don't bother with maintenance unless they're very sure that a software upgrade will fall within the maintenance period. I know many past and present Novell shops who pay for their software this way. It has its disadvantages because it requires convincing upper management to fork over big bucks every two to five years, and you have to justify Novell's existence every time. The requirement to have a maintenance contract in order for your highly skilled staff to get at TIDs and patches, something that used to be both free and very effective, is a real-world major added expense.

This is the kind of thing that can catalyze migration events. A certain percentage will pony up and pay for support every year, and grumble about it. Others, who have been lukewarm towards Novell for some time due adherence to the underdog products, may take it as the sign needed to ditch these products and go for the industry leader instead.

This move will hurt their underdog-product market-share more than it will their mid-market and top-market products.

If you've read Novell financial statements in the past few years you will have noticed that they're making a lot more money on 'subscriptions' these days. This is intentional. They, like most of the industry right now, don't want you to buy your software in episodic bursts every couple years. They want you to put a yearly line-item in your budget that reads, "Send money to Novell," that you forget about because it is always there. These are the subscriptions, and they're the wave of the future!

Labels: , ,


Tuesday, September 08, 2009

DNS and AD Group Policy

This is aimed a bit more at local WWU users, but it is more widely applicable.

Now that we're moving to an environment where the health of Active Directory plays a much greater role, I've been taking a real close look at our DNS environment. As anyone who has ever received any training on AD knows, DNS is central to how AD works. AD uses DNS the way WinNT used WINS, the way IPX used SAPs, or NetWare uses SLP. Without it things break all over the place.

As I've stated in a previous post our DNS environment is very fragmented. As we domain more and more machines, the 'univ.dir.wwu.edu' domain becomes the spot where the vast majority of computing resources is resolveable. Right now, the BIND servers are authoritative for the in-addr.arpa reverse-lookup domains which is why the IP address I use for managing my AD environment resolves to something not in the domain. What's more, the BIND servers are the DNS servers we pass out to every client.

That said, we've done the work to make it work out. The BIND servers have delegation records to indicate that the AD DNS root domain of dir.wwu.edu is to be handled by the AD DNS servers. Windows clients are smart enough to notice this and do the DNS registration of their workstation name against the AD DNS servers and not the BIND servers. That said, the in-addr.arpa domains are authoritative on the BIND servers so the client's attempt to register the reverse-lookup records all fail. Every client on our network has Event Log entries to this effect.

Microsoft has DNS settings as a possible target for management through Group Policy. This could be used to help ensure our environment stays safe, but will require analysis before we do anything. Changes will not be made without a testing period. What can be done, and how can it help us?

Primary DNS Suffix
Probably the simplest setting of the lot. This would allow us to force all domained machines to consider univ.dir.wwu.edu to be their primary DNS domain and treat it accordingly for Dynamic DNS updates and resource lookups.

Dynamic Update
This forces/allows clients to register their names into the domain's DNS domain of univ.dir.wwu.edu. Most already do this, and this is desirable anyway. We're unlikely to deviate from default on this one.

DNS Suffix Search List
This specifies the DNS suffixes that will be applied to all lookup attempts that don't end in period. This is one area that we probably should use, but don't know what to set. univ.dir.wwu.edu is at the top of the list for inclusion, but what else? wwu.edu seems logical, and admcs.wwu.edu is where a lot of central resources are located. But most of those are in univ.dir.wwu.edu now. So. Deserves thought.

Primary DNS Suffix Devolution
This determines whether to include the component parts of the primary dns suffix in the dns search list. If we set the primary DNS suffix to be univ.dir.wwu.edu, then the DNS resolver will also look in dir.wwu.edu, and wwu.edu. I believe the default here is 'True'.

Register PTR Records
If the in-addr.arpa domains remain on the BIND servers, we should probably set this to False. At least so long as our BIND servers refuse dynamic updates that is.

Registration Refresh Interval
Determines how frequently to update Dynamic registrations. Deviation from default seems unlikely.

Replace Addresses in Conflicts
This is a setting for handling how multiple registrations for the same IP (here defined as multiple A records pointing to the same IP) are to be handled. Since we're using insecure DNS updates at the moment, this setting deserves some research.

DNS Servers
If the Win/NW side of Tech Services wishes to open warfare with the Unix side of Tech Services we'll set this to use the AD DNS servers for all domained machines. For this setting overrides client-side DNS settings with the DNS servers defined in the Group Policy. No exceptions. A powerful tool. If we set this at all, it'll almost definitely be the BIND DNS servers. But I don't think we will. Also, it may be true that Microsoft has removed this from the Server 2008 GPO, as it isn't listed on this page.

Register DNS Records with Connection-Specific DNS Suffix
If a machine has more than one network connection (very, very few non VMWare host-machines will) allow them to register those connections against their primary DNS suffix. Due to the relative derth of configs, we're unlikely to change this from default.

TTL Set in the A and PTR Records
Since we're likely to turn off PTR updates, this setting is redundant.

Update Security Level
As more and more stations domain, there will come a time when we may wish to cut out the non-domained stations from updating into univ.dir.wwu.edu. If that times come, we'll set this to 'secure only'. Until then, won't touch it.

Update Top Level Domain Zones
This allows clients to update a TLD like .local. Since our tree is not rooted in a TLD, this doesn't apply to us.

Some of these can have wide ranging effects, but are helpful. I'm very interested in the search-list settings, since each of our desktop techs has tens of DNS domains to chose from depending on their duty area. Something here might greatly speed up resouce resolution times.

Labels: , ,


Thursday, August 20, 2009

On databases and security

Charles Stross has a nice blog post up about the UK DNA database, database security, and the ever dropping price of gene sequencing and replication. The UK has a government DNA database of anyone ever booked by anything by the police. Because of how these things work, lots of entities have access to it for good reasons. Like the US No Fly List, being on it is seen as a black mark on your trustability. He posits some scenarios for injecting data into the DNA database through wireless and other methods.

Another thing he points out is that the gear required to reproduce DNA is really coming down in price. In the not too distant future, it is entirely possible that the organized criminal will be able to plant DNA on the scene of a crime. This could result in pranks ("How'd the Prime Minister get to Edinburgh and back to London in time to jiz on a shop window?") to outright frame jobs.

Which is to say, once DNA reproduction gets into the hands of the criminal elements, it'll no longer be a good single-source biometric identifier. Presuming of course that the database backing it hasn't been perved.

Labels: ,


Tuesday, August 11, 2009

Non-paid work hours

Ars Technica has an article up today about workers who put in a lot of unpaid hours thanks to their mobile devices. This isn't a new dynamic by any means, we had a lot of this crop up when Corporate web-mail started becoming ubiquitous, and before that with the few employees using remote desktop software (PCAnywhere anyone?) to read email from home over corporate dialup. The BlackBerry introduced the phenomena to the rest of the world, and the smartphone revolution is bringing this to the masses.

My old workplace was union, so was in the process of figuring out how to compensate employees for after-hours call-out shortly after we got web-mail working. There were a few state laws and similar rulings that directed how it should be handled, and ultimately they decided on no less than 2-hours overtime pay for issues handled on the phone, and no less than 4-hours overtime pay for issues requiring a site-visit. Yet, no payment for being officially on-call with a mandatory response time; it was seen that actually responding to the call was the payment. Even if being on-call meant not being able to go to a child's 3 hour Dance recital.

Now that I'm an exempt employee, I don't get anything like overtime. If I spend 36 hours in a weekend shoving an upgrade into our systems through sheer force of will, I don't automatically get Monday off or a whonking big extra line-item on my next paycheck. It's between me and my manager how many hours I need to put in that week.

As for on-call, we don't have a formal on-call schedule. All of us agree we don't want one, and strive to make the informal one work for us all. No one wants to plan family vacations around an on-call schedule, or skip out of town sporting events for their kids just so they can be no more than an hour from the office just in case. It works for us, but all it'll take to force a formal policy is one bad apple.

For large corporations with national or global workforces, such gentleman's agreements aren't really doable. Therefore, I'm not at all surprised to see some lawsuits being spawned because of it. Yes, some industries come with on-call rotations baked in (systems administration being one of them). Others, such as tech-writing, don't generally have much after-hours work, and yet I've seen second hand such after hours work (working on docs, conference calls, etc) consume an additional 6 hours a day.

Paid/unpaid after hours work gets even more exciting if there are serious timezone differences involved. East Coast workers with the home-office on the West Coast will probably end up with quite a few 11pm conference calls. Reverse the locations, and the West Coast resident will likely end up with a lot of 5am conference calls. Companies that have drank deeply from the off-shoring well have had to deal with this, but have had the benefit of different labor laws in their off-shored countries.

"Work" is now very flexible. Certain soulless employers will gleefully take advantage of that, which is where the lawsuits come from. In time, we may get better industry standard practice for this sort of thing, but it's still several years away. Until then, we're on our own.

Labels: ,


Friday, August 07, 2009

Why aren't schools using open-source?

From http://blogs.techrepublic.com.com/opensource/?p=811

This article was primarily aimed at K-12, which is a much different environment than higher ed. For one, the budgets are a lot smaller per-pupil. However, some of the questions do apply to us as well.

As it happens, part of our mandate is to prepare our students for the Real World (tm). And until very recently, Real World meant MS Office. We've been installing Open Office along side MS Office on our lab images for some time, and according to our lab managers they've seen a significant increase on OO usage. I'm sure part of this is due to the big interface change Microsoft pushed with Office 2007, but this may also be reflective of a shift in mind-share on the part of our incoming students. Parallel installs just work, so long as you have the disk space and CPU power it is very easy to set up.

Our choice of lab OS image has many complexities, not the least of which is a lack of certain applications. There are certain applications, of which Adobe Photoshop is but one, that don't have Linux versions yet. Because of this, Windows will remain.

We could do something like allow dual-boot workstations, or have a certain percentage of each lab as Linux stations. Hard drive sizes are big enough these days that we could dual-boot like that and still allow local-partition disk-imaging, and it would allow the student a choice in environments they can work in. Now that we're moving to a Windows environment, that actually better enables interoperability (samba). Novell's NCP client for Linux was iffy performance-wise, and we had political issues surrounding CIFS usage.

However... one of the obstacles in this is the lack of Linux workstation experience on the part of our lab managers. Running lab workstations is a constant cat and mouse game between students trying to do what they want, malware attempting to sneak in, and the manager attempting to keep a clean environment. You really want your lab-manager to be good at defensive desktop management, and that skill-set is very operating system dependent. Thus the reluctance regarding wide deployment of Linux in our labs.

Each professor can help urge OSS usage by not mandating file formats for homework submissions. The University as a whole can help urge it through retraining ITS staff in linux management, not just literacy. Certain faculty can promote it in their own classes, which some already do. But then, we have the budget flexibility to dual stack if we really want to.

Labels: ,


Identity Management in .EDU land

We have a few challenges when it comes to an identity management system. As with any attempt to automate identity management, it is the exceptions that kill projects. This is an extension of the 80/20 rule, where 80% of the cases will be dead easy to manage, and it's the 20% that are special are where most of the business-rules meeting-time will be spent.

In our case, we have two major classes of users:
  • Students
  • Employees
And a few minor classes littered about like Emeritus Professors. I don't quite know enough about them to talk knowledgeably.

The biggest problem we have are how to handle the overlaps. Student workers. Staff who take classes. We have a lot of student workers, but staff who take classes are another story. The existence of these types of people make impossible having the two big classes as exclusive.

Banner handles this case pretty well from what I understand. The systems I manage, however, are another story. With eDirectory and the Novell Client, we had two big contexts named Students and Users. If your object was in one, that's the login script you ran. Active Directory was until recently Employee-only because of Exchange. We put the students in there (with no mailboxes of course) two years ago, largley because we could and it made the student-employee problem easier to manage.

One of the thorniest questions we have right now is defining, "when is a student a student with a job, and when is a student an employee taking classes." Unfortunately, we do not have a handy business rule to solve that. A rule, for example, like this one:
If a STUDENT is taking less than M credit-hours of classes, and is employed in a job-class of C1-F9, then they shall be reclassed EMPLOYEE.
That would be nice. But we don't have it, because the manual exception-handling process this kicks off is not quite annoying enough to warrant the expense of deciding on an automatable threshold. Because this is a manual process, people rarely get moved back across the Student/Employee line in a timely way. If the migration process were automated, certain individuals would probably flop over the line every other quarter.

This one nice example of the sorts of discussions you have to have when rolling out an identity management automation system. If we were given umpty thousand dollars to deploy Novell IDM in order to replace our home-built system, we'd have to start having these kinds of discussions again. Even though we've had some kind of identity provisioning system since the early 90's. Because we DO have an existing one, some of the thornier questions of data-ownership and workflow are already solved. We'd just have to work through the current manual-intervention edge cases.

Labels: ,


Monday, August 03, 2009

The obsolecence of Word

Ars Technica had a nice opinion essay posted today called, "The prospects of Microsoft Word in the wiki-based world." In case you didn't catch it, the actual page name for the link is, "microsoft-word-1983---2008-rest-in-peace.ars". Clearly, they're predicting the death of Word as a major force.

And it isn't OpenOffice that's doing it, it's the cloud. Google Docs. MediaWiki. Anything with a RichEditor text interface. And for those things that just aren't usable in those interfaces, there are specialized tools that do that job better than Word does.

The second page of the essay goes into some detail about how the author was able to replace an old school file-server with a MediaWiki. MediaWiki, it seems, is an excellent document-management product. Most people already know how to use it (thank you Wikipedia), anything entered is indexed with the built in search tools, and there is integrated change-tracking. Contrast this with a standard File Server, where indexing is a recent add-on if it exists at all, change tracking is done at the application level if at all, and files just get lost and forgotten. MediaWiki just does it better.

I never expected, "MediaWiki is the Word killer," to be made as an argument, but there are some good points in there. I do very little editing in any word processor at work. I do much more spreadsheet work, as that's still a pretty solid data manipulation interface. Tech Services has a Wiki now, and we're slooooly increasing usage of it.

And yet, there are still some areas of my life where I still use a stand-alone word processor. If I really, truly need better type-setting than can be provided by javascript and CCS driven HTML, a stand-alone is the only way to go. If I'm actually going to print something off, perhaps because I have to fax it, I'm more likely to use a word processor. There are some cultural areas where solidly type-set documentation is still a must; wedding invitations, birth announcements, resumes, cover letters. And even these are going ever more electronic.

The last time I seriously job-searched (back in 2003) I spent hours polishing the formatting of my resume. Tweaking margins so the text would flow cleanly from one page to the next. Picking a distinctive yet readable font. Fine tuning the spacing to help fit the text better. Inserting subtle graphic elements line horizontal lines. Inserting small graphics, such as my CNE logo. In the end I had a fine looking document! I even emailed it to HR when I applied. The cover letter got much the same treatment, but less focus on detailed formatting.

If I were to start looking today, it is vastly more likely that I'd attach the document (a PDF by preference, to preserve formatting, but DOC is still doable) to an online job application submission system of some kind. Or worse yet, be presented a size-limited ASCII text-entry field I'd have to cut-and-paste my resume into. The same would go for the cover letter. One of these two still encourages finely tuned type-setting like I did in 2003. The other explicitly strips everything but line feeds out.

Even six years ago there was no actual paper involved.

So I'll close with this. If you need typesetting, which is distinct from text formatting, then you still need offline tools for processing words. This is because you're doing more than simple word processing, you're also processing the format of it all. But if all you're doing is bolding, highlighting, changing text sizes, and creating the odd table, then the online tools as they exist now are well and truly all you need. It has been a SysAdmin addage for years that most people could use WordPad instead of Word for most of what they do, and these days everything WordPad can do is now in your browser.

Labels:


Wednesday, July 29, 2009

One of the perks of working here

Even though WWU is located smack in the middle of Bellingham, WA, it abuts an arboretum. Sehome Hill Arboretum. It so happens that the shortest-by-distance pedestrian route between my office and campus takes me through there on the foot-paths. Here is the trail guide.

Even though today is going to get very hot for up here, I stilled walked up and back this morning to do some work on printing in the labs by way of Microsoft/PCounter. Along the way, I ran into this:
Tree arch in the Sehome Arboretum
The trail I was on crossed this road.

The trail itself is one of the main paths between the Bernam Wood dorms and campus. During regular session there is a fair amount of traffic on this trail. I think I was the first one down it today, as I ran into more than a few spider webs. Also? Even though this route is hillier than the slightly longer one, it's a good 5-7 degrees F cooler under the trees than by the main road.

It was a nice walk. I'll do it again tomorrow to head up to a meeting on campus. I believe that meeting is in a building that currently lacks AC. That could be a very sweaty meeting.

Labels:


Wednesday, July 15, 2009

Where DIY belongs

The question of: "When should you built it your self and when should you get it off the shelf?" is one that varies from workplace to workplace. We heard several different variants of that when were interviewing for the Vice Provost for IT last year. Some candidates only did home-brew when no off the shelf package was available, others looked at the total cost of both and chose from there. This is a nice proxy question for, "What is the role of open source in your environment," as it happens.

Backups are one area where duct tape and bailing wire is to be discouraged most emphatically.

And now, a moment on tar. It is a very versatile tool, and is what a lot of unixy backup packages are built around. The main problem with backup and restore is not getting data to the backup medium, it is keeping track of what data is on which medium. Also in these days of the backup-to-disk, de-duplication is also in the mix and that's something tar can't do yet. So while you can build a tar-and-bash backup system from scratch without paying a cent, it will be lacking in certain very useful features.

Also? Tar doesn't work nearly as well on Windows.

Your backup system is one area you really do not want to invest a lot of developer creativity. You need it to be bullet proof, fault tolerant, able to handle a variety of data-types, and easy to maintain. Even the commercial packages fail some of these points some of the time, and the home brew systems fall apart much more often relative to these. The big backup boys have agents that allow backups of Oracle DBs, Linux filesystems, Exchange, and Sharepoint all to the same backup system, a home-brew application would have to get very creative to do the same thing; the problem gets even worse when it comes to restore.

Disaster Recovery is another area in which duct tape and bailing wire are to be discouraged most emphatically.

There are battle-tested open-source packages out there that will help with this (DRBD for one), depending on your environment. They're even widely used so finding someone to replace the sysadmin who just had a run in with a city bus is not that hard. Rsync can do a lot as well, so long as the scale is small. Most single systems can have something cobbled together.

Problems arise when you start talking Windows, very complex installations, or money is a major issue. If you throw enough money at a problem, most disaster recovery problems become a lot less complex. There is a lot of industry investment in DR infrastructure, so the tools are out there. Doing it on a shoe-string means that your disaster recovery also hangs by a shoe-string. If you're doing DR just to satisfy your auditors and don't plan on ever actually using it, that's one thing. But if you really expect to recover from a major disaster on that shoe-string you'll be sorely surprised when that string snaps.

Business Continuity is an area where duct tape and bailing wire should be flatly refused.

BC is in many ways DR with a much shorter recovery time. If you had problems getting your DR funded correctly, BC shouldn't even be on the timeline. Again, if it is just so you can check a box on some audit report, that's one thing. Expecting to run on such a rig is quite another.

And finally, if you do end up cobbling together backup, disaster recovery, or business continuity systems from their component parts, testing the system is even more important. In many cases testing DR/BC takes a production outage of some kind, which makes it hard to schedule tests. But testing is the only way to find out if your shoe-string can stand the load.

Labels: , ,


Wednesday, July 08, 2009

Google and Microsoft square off

As has been hard to avoid lately, Google has announced that it's releasing an actual operating system. And for hardware you can build yourself, not just on your phone. Some think this is the battle of the titans we've been expecting for years. I'm... not so sure of that.

What the new Google OS, called Chrome to make it confusing, is under the hood is Linux. They created, "a new windowing system on top of a Linux kernel." This might be a replacement for X-Windows, or it could just be a replacement for Gnome/KDE.

To my mind, this isn't the battle of the titans some think it is. Linux on the net-top has been around for some time. Long enough for a separate distribution to gain some traction (hello Moblin). What google brings to the party that moblin does not is its name. That alone will drive up adoption, regardless of how nice the user experience ends up being.

And finally, this is a distribution aimed at the cheapest (but admittedly fastest growing) segment of the PC market: sub-$500 laptops. Yes, Chrome could further chip away at the Microsoft desktop lock-in, but so far I have yet to see anything about Chrome that could actually do something significant about that. Chrome is far more likely to chip away at the Linux market-share than it is the Windows market-share, since it shares an ecosystem with Linux.

Microsoft is not quaking in its boots about this anouncement. With the release of Android, it was pretty clear that a move like this was very likely. Microsoft itself has admitted that it needs to do better in the, "slow but cheap," hardware space. They're already trying to compete in this space. Chrome will be another salvo from Google, but it won't make a hole below the water-line.

Labels: , ,


Monday, June 29, 2009

Changes are coming

Due to technical reasons I'll be getting to in a moment, this blog will be moving off of WWU's servers in the next few weeks. I have high confidence that the redirects I'll be putting in place will work and keep any existing links to the existing content still ultimately pointing at their formal home. In fact, those of you reading by way of the RSS or Atom feeds won't even notice. Images I link in will probably load a bit slower(+), and that's about it.

And now for the technical reasons. I've been keeping it under my hat since it has politics written all over it and I so don't go there on this blog. But WWU has decided (as of last September actually) that they're dropping the Novell contract and going full Microsoft to save money. And really, I've seen the financials. Much as it pains this red heart, the dollars speak volumes. It really is cheaper to go Microsoft, to the tune of around $83,000. In this era of budget deficits, that's most of an FTE. Speaking as the FTE most likely to get cut in this department, that makes it kind of personal.

Microsoft? The cheap option?

Yes, go fig. But that's how the pricing is laid out. We were deep enough into the blue beast already (Exchange, MS-SQL, SharePoint is embryonic but present and going to grow, there is Office on every Windows desktop) that going deeper wasn't much of an extra cost per year. To put it even more bluntly, "Novell did not provide enough value for the cost."

The question of what's happening to our SLES servers is still up for debate. We could get those support certificates from Microsoft directly. Or buy them retail from Novell. I don't know what we're doing there.

Which means that we're doing a migration project to replace the WUF 6-node NetWare cluster with something on Windows that does the same things. NetStorage is the hardest thing to replace (I know I'm going to miss it), but the file-serving and printing are challenging but certainly manageable. The "myweb" service will continue, and be served by a LAMP server with the home directories Samba-mounted to it, so it will continue as Apache. It could have been done with IIS, but it was an ugly hack.

As soon as we get hardware (7/1 is when the money becomes available) we'll be hitting the fast phase of the project. We hope to have it all in place by fall quarter. We'll still maintain the eDirectory replica servers for the rest of the Novell stuff on campus that is not supported (directly) by me. But for all intents and purposes, Technical Services will be out of the NetWare/OES business by October.

OH MY GOD! YOU'RE LEAVING! THAT'S WHY YOU'RE MOVING THE BLOG!

No, no. That's not the reason I'm moving this blog. Unfortunately for this blog, there was exactly one regular user of the SFTP service we provided(*). Me. So that's one service we're not migrating. It could be done with cygwin's SSH server and some cunning scripting to synchronize the password database in cygwin with AD, if I really wanted to. But... it's just me. Therefore, I need to find an alternate method for Blogger to push data at the blog.

Couple that with some discrete hints from some fellow employees that just maybe, perhaps, a blog like mine really shouldn't be run from Western's servers, and you have another reason. Freedom of information and publish-or-perish academia not withstanding, I am staff not tenured faculty. Even with that disclaimer at the top of the blog page (that you RSS readers haven't seen since you subscribed) that says I don't speak for Western, what I say unavoidably reflects on the management of this University. I've kept this in mind from the start, which is why I don't talk about contentious issues the University is facing on any term other than how they directly affect me. And also why this is the first time I've mentioned the dropping of the Novell contract until it is effectively written in stone.

So. It's time to move off of Western's servers. The migration will probably happen close to the time we cut-over MyWeb to the new servers. Which is fitting, really, as this was the first web-page on MyWeb. This'll also mean that this blog will no longer be served to you by a NetWare 6.5 server. Yep, for those that didn't know this blog's web-server is Apache2 running on NetWare 6.5.

(+) Moving from a server with an effective load-average of 0.25 to one closer to 3.00 (multi-core, though) does make a difference. Also, our pipes are pretty clean relatively speaking.

(*) Largely because when we introduced this service, NetWare's openssh server relied on a function in libc that liked to get stuck and render the service unusable until a reboot. MyWeb was also affected by that. That was back in 2004-06. The service instability drove users away, I'm sure. NetStorage is more web-like anyway, which users like better.

Labels: ,


Friday, June 19, 2009

End of an era

From internal email:
As some of you may know, the WWU dial-up modem Student and Faculty/Staff pools are being discontinued on Monday, June 29, 2009.
That's right. We're getting out of the modem business. We still had a couple regular users. If I remember right, the modem gear we had was bought with student-tech-fee money a LONG time ago and was beginning to fail. And why replace modem gear in this age? We're helping the few modem users onto alternate methods.

Like many universities, we were the sole ISP in town for many years. That changed when the Internet became more than just the playground of universities and college kids, but it was true for a while. The last vestige of that goes away on the 29th.

Labels:


Wednesday, June 10, 2009

Outlook for everything

Back when I worked in a GroupWise shop, we'd get the occasional request from end users to see if Outlook could be used against the GroupWise back-end. Back in those days there was a MAPI plug-in for Outlook that allowed it to talk natively to GroupWise and it went rather well. Then Microsoft made some changes, Novell made some changes, and the plug-in broke. GW Admins still remember the plug-in, because it allowed a GroupWise back end to look exactly like and Exchange back end to the end users.

Through the grapevine I've heard tales of Exchange to GroupWise migrations almost coming to a halt when it came time to pry Outlook out of the hands of certain highly placed noisy executives. The MAPI plugin was very useful in quieting them down. Also, some PDA sync software (this WAS a while ago) only worked with Outlook, and using the MAPI plugin was a way to allow a sync between your PDA and GroupWise. I haven't checked if there is something equivalent in the modern GW8 era.

It seems like Google has figured this out. A plugin for Outlook that'll talk to Google Apps directly. It'll allow the die-hard Outlook users to still keep using the product they love.

Labels: ,


Friday, May 29, 2009

Behavior modification

First off, this isn't sparked by anything in the office. We're pretty mellow around here.

Praise in public, correct in private

Simple words, yet we've all run into violations of it. Such as the following from a hypothetical manager:
We've been having some problems lately with people using their cell-phones excessively during working hours. We need to try and do better.
Which everyone knows that We actually means [person], and manager is too gutless to talk to [person] about their excessive cell-phone use. Instead preferring to issue a semi-anonymous dictate from on high. In my opinion, this is probably the most common manifestation of failing to follow this. Less common are the outright public criticisms, as most people realize that isn't a winning strategy (unless the manger intends to rule by fear, which some do).

That said, there are some circumstances in which a public correction is called for. Such as when the behavior requiring correction was highly public, highly sensitive in some way, or if failure to address the problem in public will significantly impact morale. In a sense, this is a failure on the part of the errant party to keep their transgressions reasonably private. Excessive local-call abuse? Pretty private, worthy of a mangerial talk in person. Surfing porn during working hours? Pretty private until you get caught, then it gets public real fast (at least in America).

If your transgression was big enough that the manager has to save face, you will not get a private rebuke.

As I said, this office is pretty mellow and this hasn't come up. But I still hear stories of other places.

Labels:


Wednesday, May 27, 2009

A new addictive site

The site ServerFault has just gone public. This is a new project from the folks that brought you StackOverflow. It is a place for SysAdmin types to ping each other for questions, in a format that's very google-friendly. Handy when you're googling for a strange issue. It has a reputation management system that looks pretty good as well. Very nifty.

Labels:


Wednesday, May 13, 2009

Thinking of an Atom-based netbook?

Anandtech is running a review of an Atom based motherboard from NVidia right now. What grabbed my attention was Page 5 of the review where Anand compares Atom performance against and old-school Pentium 4 processor. It was very interesting! This particular motherboard has a pair of Atom processors, but the review also included benchmarks from a single-cpu Atom motherboard of the same kind used in most netbooks.

If you're thinking about an Atom-based netbook, this should give you a fair idea about how it should perform.

Labels:


Tuesday, April 28, 2009

LinuxFest Northwest: gender imbalance

I went to LinuxFest Northwest this weekend. It was interesting! OpenSUSE, Ubuntu, Fedora, and FreeBSD were all there and passing out CDs. I learned stuff.

In one of the sessions I went to, "Participate or Die!" the question was asked of the presenter, a Fedora guy, about whether he is seeing any change in the gender imbalance at Linux events. He hemmed and hawed and said ultimately, 'not really'. I've been thinking about that myself, as I've noticed a similar thing at BrainShare.

Looking at what I've seen in amongst my friends, the women ARE out there. They're just not well represented in the ranks of the code-monkeys. Among closed source shops, I see women many places.

I have known several women involved with technical writing and user-factors. In fact, I don't know any men involved in these roles. Amongst all but the largest and well funded of open-source projects, tech-writing is largely done by the programmers themselves or by the end-user community on a Wiki. Except for the Wiki, the same can be said for interface design. As the tech-writers I know lament, programmers do a half-assed job of doc, and write for other programmers not somewhat clueless end-users. At the same time, the UI choices of some projects can be downright tragic for all but fellow code-monkeys. This is the reason the large pay-for-it closed-source software development firms employ dedicated Technical Writers with actual English degrees (you hope) to produce their doc.

I've also known some women involved with QA. In closed-source shops QA is largely done in house, and there may be a NDA-covered beta among trusted customers towards the end of the dev-cycle. In the land of small-project open-source, QA is again done by developers and maybe a small cadre of bug-finders. The fervent hope expectation is that bug-finders will occasionally submit a patch to fix the bug as well.

I also know women involved with defining the spec for software. Generally this is for internal clients, but the same applies elsewhere. These are the women who meet with internal customers to figure out what they need, and write it up as a feature list that developers can code against. These women also frequently are the liaison between the programmers and the requesting unit. In the land of open-source, the spec is typically generated in the head a programmer who has a problem that needs solving, who then goes out to solve it, and ultimately publishes the problem-resolution as an open source project in case anyone else wants that problem solved too.

All of this underlines one of the key problems of Linux that they've been trying to shed of late. For years Linux was made by coders, for coders, and it certainly looked and behaved like that. It has only been in recent years when a concerted effort has been made to try and make Linux Desktops look and feel comprehensible to tech-shy non-nerds. Ubuntu's success comes in large part due to these efforts, and Novell has spent a lot of time doing the same through user-factors studies.

Taking a step back, I see women in every step of the closed-source software development process, though they are underrepresented in the ranks of the code-monkeys. The open-source dev-process, on the other hand, is almost all about the code-monkey in all but the largest projects. Therefore it is no surprise that women are significantly absent at Linux-conventions.

I've read a lot of press about the struggles Computer Science departments have in attracting women to their programs. At the same time, Linux as an ecosystem has a hard time attracting women as active devs. Once more women start getting degreed, or not scared off in the formative teen years which is something Linux et. al. can help with, we'll see more of them among the code-slingers.

Something else that might help would be to tweak the CompSci course offerings to perhaps partner with the English departments or Business departments to produce courses aimed at the hard problem of translating user requirements into geek, and geek into manuals. Because the Software Engineering process involves more than just writing code in teams, it involves:
  • Building the spec
  • Working to the spec
  • Testing the produced code against the spec
  • Writing the How-To manual against the deliverable code
  • Delivery
This is an interdisciplinary process involving more than just programmers. The programmers need to be familiar with each step, of course, but it would be better if other people gave the same focus to those steps as the programmers have to focus on producing the code. Doing this in class might just inspire more non-programmers to participate on projects in such key areas as helping guide the UI, writing how-tos and man-pages, and creatively torturing software to make bugs squeal. And maybe even inspire some to give programming a try, some who never really looked at it before due to unfortunate cultural blinders. That would REALLY help.

Labels: ,


Friday, April 03, 2009

Open-sourcing eDirectory?

The topic of open-sourcing eDirectory comes up every so often. The answer is always the same, it can't be done. Novell NDS and the eDirectory that followed it uses technology licensed from RSA, and RSA will not allow their code to be open-sourced. And that's it.

However... it isn't the RSA technology that allows eDirectory to scale as far as it does. To the best of my knowledge, that's pure Novell IP, based on close to 20 years of distributed directory experience. The RSA stuff is used in the password process, specifically the NDS Password, as well as authenticating eDirectory servers to the tree and each other. The RSA code is a key glue to holding the directory together.

If Novell really wanted to, they could produce another directory that scales as far as eDirectory does. This directory would be fundamentally incompatible with eDir because it would have to be made without any RSA code, which eDirectory requires. This hypothetical open-source directory could scale as far as eDir does, but would have to use a security process that is also open-source.

This would take a lot of engineering on the part of Novell. The RSA stuff has been central to both NDS and eDir for all of those close to 20 years, and the dependency tree is probably very large. The RSA code even is involved in the NCP protocol that eDir uses to talk with other eDir servers, so a new network protocol would probably have to be created from scratch. At the pace Novell is developing software these days, this project would probably take 2-3 years.

Since it would take a lot of developer time, I don't see Novell creating an open-source eDir-clone any time soon. Too much effort for what'll essentially be a good-will move with little revenue generating potential. That's capitalism for you.

Labels: , ,


Tuesday, March 31, 2009

When perfection is the standard

The disaster recovery infrastructure is an area where perfection is the standard, and anything less than perfection is a fault that needs fixing. It shares this distinction with other things like Air Traffic Control and sports officiating. In any area where perfection is the standard, any failure of any kind brings wincing. There are ways to manage around faults, but there really shouldn't be faults in the first place.

In ATC there are constant cross-checks and procedures to ensure that true life-safety faults only happen after a series of faults. In sports officiating, the advent of 'instant replay' rules assist officials in seeing what actually happened from angles other than the ones they saw, all as a way to improve the results. In DR, any time a backup or replication process fails, it leaves an opening through which major data-loss can possibly occur. Each of these have their unavoidable, "Oh *****," moments. Which leads to frustration when it happens too often.

At my old job we had taken some paperwork steps towards documenting DR failures. We didn't have anything like a business-continuity process, but we did have tape backup. When backups failed, there was a form that needed to be filled out and filed, explaining why the fault happened and what can be done to help it not happen again. I filled out a lot of those forms.

Yeah, perfection is the standard for backups. We haven't come even remotely close to perfection for many, many months. Some of it is simple technology faults, like DataProtector and NetWare needing tweaking to talk to each other well or over-used tape drives giving up the ghost and requiring replacement. Some of it is people faults, like forgetting to change out the tapes on Friday so all the weekend fulls fail due to a lack of non-scratch media. Some of it is management process faults, like discovering the sole tape library fell off of support and no one noticed. Some of it is market-place faults, like discovering the sole tape library will be end-of-lifed by the vendor in 10 months. Some of these haven't happened yet, but they are areas that can fail.

If the stimulus fairy visits us, backup infrastructure is top of the list for spending.

Labels: ,


Friday, March 27, 2009

Computer labs in a ubiquitous computing world

Ars Technica has an article up called, When every student has a laptop, why run computer labs?

It's a good question. But before I go into it, I should mention something. What I do for WWU doesn't have a lot to do with our labs. The biggest interaction I have with them is for printing and maybe some Zen or GPO policies. I also know some of the people who support them, and I sit in meetings where other people gripe about them. So I'm speaking as someone who works around people who deals with them, not as someone who deals with them or has any decision making power.

Why run computer labs?

In the beginning it was to provide computers to students who didn't have one.
Then, it was to provide on-campus computers to students who didn't have a laptop.

Now that almost every student has a computer, and most of those laptops, it makes a less sense. Centralized printers where they can print off assignments from their own hardware? Yes. 60 seat general computing labs? Um.

The point is made in the Ars Technica article that specialized software that students generally wouldn't have, such as SPSS or the full Adobe Acrobat suite, are a good reason to have them. This is true. We have not only the general computing labs run by ATUS, but we also have special purpose labs run by ATUS and the various colleges. We now have a lab that has a large format printer, something I guarantee no student has in their dorm or apartment, and a flat-bed scanner. One non-ATUS lab has VMWare Workstation installed on all the workstations. Some of the general computing labs are actual classrooms some of the time.

In our specific case, we have one software package in universal use that greatly encourages the existence of the general computing lab.

The Novell Client.

In order to get drive-map access to the NetWare cluster, you need that. This is not a package you want to inflict on a home machine without the victim knowing what they're in for. So we need to provide computers with the client installed so students can get at their files simply. WebDav through NetStorage goes some of the way, but it can be tricky to set up.

If we were a pure Windows network, it wouldn't be so bad. Both OSX and all the major Linuxes come with Samba pre-installed, which eases access to Windows networks. Printing isn't quite as convenient, but at least you can get at your files easy enough once you're inside the firewall.

In the end, except for our NCP dependencies, we could possibly close some of our GC labs to save money. However, we do track lab utilization, and those numbers may tell a different story. I know some students don't bother hauling their laptop to campus so long as they can use a lab machine for a quick social-networking fix. If we start closing labs those students will start hauling their gear to campus and we can save money. I still think we need to provide general access printers at various spots, which is something that Novell iPrint is rather good for. We also need to provide access to the special software packages that are needed for teaching, things like SPSS and MatLab.

The role of the computer lab has changed now that all but a few students have laptops. We still need them for specialized teaching functions, but general access to computing is no longer a primary function. The convenience factor of simple internet access drives some usage, and it may even be a majority. But the labs aren't going away any time soon. Their printers, even less so.

Labels: ,


Tuesday, March 24, 2009

Budgetary efficiency

As I've mentioned, there is a major budget shortfall coming real soon. In the past two weeks various entities have gone before the Board of Trustees discussing the effects of budget cuts on their units. The documents submitted can be found here. The Vice Provost of Information and Telecommunication, my grand-boss, also had a presentation. Which you can view here. The especially nosy can even listen to the presentation here, the 12:45 file and starts about a minute-plus in.

There were some interesting bits in the presentation:
"In 2007, our central IT staff (excluding SciTech & Secretarial) totaled 73 persons. The average for our peer group (with greater than 10,000 student FTE) was 81 people. While a difference of 8 FTE may not seem great, it has a significant impact on our ability to support our users. This is compounded if we consider that student FTE grew a cumulative 16% in the past decade; faculty and staff FTE grew at a cumulative 14% while ITS staff declined 3% "
So, our supported environment grew, and we lost people. Right. Moving on...
"Similarly the budget numbers reveal the same trend. Western's 2007 operating budget for ITS was 6.65 million. The average for our peer institutions (with greater than 10,000 student FTE) was 8.17 million. Total budgets including recharge and student technology fees were 7.8 million for Western and 10.3 million for our peer group."
And we're under-resourced compared to our peer institutions. Right.

This can be spun a couple of ways. The spin being given right now, when we're being faced with a major budget cut, is that we're already running a very efficient operation, and cutting now would seriously affect provided services. A couple years ago when times were more flush, the spin was that we're under resourced compared to our peer institutions, and this is harming service robustness.

Both, as it happens, are true. We are running a very lean organization that gets a lot done for the dollars being spent on it. At the same time, the very same shoe-string attitude has overlooked certain business continuity concerns that worry those of us who will have to rebuild everything in the case of a major disaster. Like the facilities budget, we also run a 'deferred maintenance' list of things we'd like to fix now but aren't critical enough to warrant emergency spending. Since every dollar is a dear dollar, major purchases such as disk arrays or tape libraries have to last a long, long time. We still have some HP ML530 servers in service, and that is a 9 year old server (old enough that HP lists Banyan Vines drivers for the server).

This is continually vexing to vendors who cold-call me. Even in more flush times, anything that costs more than $3000 required pushing to get, and anything that cost over $20,000 was pretty much out of the question. Storage arrays that even on academic discount cost north of $80,000 require exceptional financing and can take several years to get approved. In budget constrained times such as these, anything that costs over $1000 has to go before a budget review process.

It is continually aggravating to work in an organization as under resourced as we are. Our disaster recovery infrastructure is questionable, and business-continuity is a luxury we just plain can't afford. Two years ago there was a push for some business continuity, but it ran smack into the shoe-string. The MSA1500 that I've railed about so long was purchased as a BC device, but it is fundamentally unsuited to the task. Getting data onto it was a mish-mash of open source and hand-coded rigging. We've since abandoned that approach as it looks like 2012 may be the earliest we can afford to think about it again.

As a co-worker once ranted, "They expect enterprise level service for a small-business budget."

You'd think this would be the gold plated opening for open source software. It hasn't been. Our problem isn't so much software as it is hardware. If we can GET the hardware for business continuity, it'll probably be open source software that actually handles the data replication. Replacing Blackboard with Moodle will require new hardware, since we will have to dual-stack for two years in order to handle grade challenges for classes taught on Blackboard. Moodle would also require an additional FTE due to the amount of customizations required to make it as Blackboard-like as possible. And these are only two examples.

It was very encouraging to see that the top level of our organization (that Vice Provost) is very aware of the problem.

Labels: ,


Tuesday, March 17, 2009

Stimulus fairy wish list

There is a list on my whiteboard. It is the wish list of infrastructure projects I'd really like to see if the stimulus fairy decides to pay WWU a visit. We're higher-ed. And the stimulus bill includes funding for higher-ed. It could happen! Heck, I have two coworkers who are in the Seattle area right now listening to a demo just in case aforementioned fairy does drop by.

Anyway, the wish-list (or Santa! Give me hardware!)
  • 2 more enclosures for the existing EVA6100
  • A new EVA4400 with all eight enclosures
  • HP EVA replication software, so we can mirror the 6100 to the new 4400.
  • Data Protector licensing for everything we need
  • A new tape library, the one we have is creaky
  • New 64-bit servers for the main file-serving cluster
These would make me a happy, happy geek. Said coworkers are working on something else above and beyond these. But I'm not saying what that is. If the fairy does drop by, I will.

However, and there is always one, there is a problem with air-lifting big wads of cash into an IT environment and then spending it all. When it comes time to replace the existing EVA6100, we will have to pay for something equivalent. Since it would have had the EVA replication software on it, it is now about twice as expensive as a simple hardware replacement would suggest. The replication software would quickly become line-of-business with significant future expenses deriving from its purchase.

Maintenance has to be factored in to anything we spend fairy-money on. There is a certain amount of money we can spend on catching up our IT deferred maintenance backlog, like that creaky tape library I just mentioned, but that won't come close to the fairy-money numbers being bandied about. As hard as leaving big piles of cash laying by the side of the road there on the road-side is, there is some money that it is safer not to touch. Such as anything with a yearly maintenance fee. Or version upgrade fees for the upgrade we'll need to do in 3-6 years.

Those organizations who live on grant-money know this very well. However, here at ITS at WWU, other than Student Tech Fee funds we don't live on grant-money. The stimulus-fairy counts as grant money that could leave behind a future liability that STF can't come close to being able to cover.

We'll see what happens.

Labels: ,


Friday, February 27, 2009

Implications of the Internet SAFETY Act, part 4

[This is a short series I'm doing about this act. This is my opinion, and in no way represents the opinion or stance of WWU as a whole or in part, nor does it imply anything about our lobbying efforts. This is editorial.]

Part 4: Court cases to expect

The law itself is pretty non-specific, which means that it'll be up to the courts to determine the exact limits. There are several cases I can think of that'll need to be had early in order to flesh out who is responsible for what, and what the limits of enforceability are.
  • Does this apply to home users or not? Does that wireless router sitting next to your cable modem qualify as, "A provider of an electronic communication service"? I'm guessing not, but I expect this very question to be asked as soon as a case gets to the point where a leeching neighbor sucked down some files he really shouldn't have, and the access-point owner can't prove it.
  • Does the ISP have to distinguish between individual adults on a contract? The test case for this one would be the room-mate problem. Say I have an apartment I share with 3 friends, none of whom are married (i.e. 4 separate legal entities). If I pay the internet bill, but gas-bill paying roomie has been sucking down kiddy porn, the ISP has my billing info on file. Is this good enough, or do they also have to be able to audit roomie's discrete access patterns? This also applies to hotel rooms shared by adults.
  • The NAT gateway problem. In theory, once everyone is on IPv6, NAT isn't a serious concern anymore. Riiight. My ISP has one IP address for our connection, and yet... there are eight IP-consuming devices in my house. Who is responsible for auditing the true originating IP address? Resolution of this question will go a long way towards answering whether or not home installs also need to keep a two year audit trail of IP/UID.
  • Active vs. Passive authentication barriers. Active authentication (you must log in) versus passive authentication (jack location and inductive logic). This will determine what the 'good enough' line is for identifying information.
  • Intranet vs. Internet. Is the need to keep an IP/User audit trail only for access off of the local network, or does it have to be kept for on-network access as well? A test case here at WWU would be if a group of students were swapping files they should not swap purely on our own WLAN. To my knowledge, we don't restrict access on the WLAN subnet itself, just off that network. If the students don't try to access off network resources, we'll never have an audit trail. Is this a problem under the act?
If this act does come before Congress, I expect the above issues to come up for debate. We'll see what ultimately passes, if it passes.

Labels:


Thursday, February 26, 2009

Implications of the Internet SAFETY Act, part 3

[This is a short series I'm doing about this act. This is my opinion, and in no way represents the opinion or stance of WWU as a whole or in part, nor does it imply anything about our lobbying efforts. This is editorial.]

Part 3: Trade Shows and Conventions

Perhaps the most visible area to be impacted by this act would be trade shows and conventions. Conventions like DEFCON, TechEd, VMWorld, BrainShare, and the like all have wireless access as part of the show. It allows journalists to mail their impressions of the event to their editors, bloggers to blog, fliker photo updates, IM-based event coordination among attendees, and a billion other things.

Wireless access at these events is not going away. It is far too critical for correct function for it to go away. Instead, they'll have to adapt. What'll most likely happen is that you'll get a uid/pw on the back of your convention badge that you'll need to enter to get access out of the local network. It'll just be a fact of life.

At conferences like DEFCON where network perversion is a game, you can guarantee that the auth mechanism will come under extremely heavy attack.

Unlike your local coffee shops or the hotel you're staying at for the convention, the big convention centers have wireless access as a core business need. They will solve this problem. The interesting court cases will be about who is the custodian of the user/IP audit data for these conferences.

Labels:


Wednesday, February 25, 2009

Implications of the Internet SAFETY Act, part 2

[This is a short series I'm doing about this act. This is my opinion, and in no way represents the opinion or stance of WWU as a whole or in part, nor does it imply anything about our lobbying efforts. This is editorial.]

Part 2: Coffee Shop Access

Coffee Shop Wifi is axiomatic. IF Coffee THEN Wifi. It just works that way. Coffee shops were among the first public hotspots out there. It just goes with the business model.

Getting wifi in your independently owned coffee shop is very simple. Get a business internet connection of some kind, an off-the-shelf wifi router/AP of some kind, set it to open, and go. Done! Very little maintenance needed. Just the kind of low margin value-add needed to keep butts in seats and swilling coffee, while nibbling on high margin baked goods.

The big boys of the coffee business, Starbucks, Dunn Brothers, and their ilk, tend to partner with the big wifi providers like T-Mobile. Their internet isn't free, but at least the home office doesn't have to track umpty thousand individual broadband connections and troubleshoot wireless equipment failures; they just pay the national company to do that.

The Internet SAFETY Act would force the free-access shops to sign with one of the big boys of wifi. Coffee shops are pretty clearly commercial interests, and they really do use the internet connection as a key value-add to keep customers. Your average independent coffee shop doesn't have the technical moxy to even try and handle the authentication problem. It would be far simpler to sign a contract with a T-Mobile, and let them handle the problem. The internet wouldn't be free, but at least it wouldn't be absent which is worse.

The Internet SAFETY Act would be the final death of free wifi in coffee shops. One of the ways the independents distinguish themselves from the large chains is that their internet is free, where you have to pay to access in the Starbucks down the street. This act would remove that small business incentive.

Labels:


Tuesday, February 24, 2009

Implications of the Internet SAFETY Act, part 1

[This is a short series I'm doing about this act. This is my opinion, and in no way represents the opinion or stance of WWU as a whole or in part, nor does it imply anything about our lobbying efforts. This is editorial.]

Part 1: Hotels

In my first piece yesterday, I brought up Hotels as one area that would be affected by this act. The details of that can be obscure to a first glance, but they are there. The Hospitality Industry as a whole would be affected by the need to authenticate end-users to IP addresses.

I recently stayed at a hotel in another part of the US that would have to change how they handle their internet connection in the rooms. As with so may hotels, they used wifi for their connection rather than a wire in the room. As with so many hotels, you had to click through an Acceptable Use Policy screen to get access to the internet from their wireless segment. Some hotels have a username and password to get past this screen, and this uid/pw combo has never been individualized to the room and has always been either generic to the hotel or rotating on a daily basis for all guests.

Were the Internet SAFETY Act to become law, this would have to change. Hotels that use Wifi connections, and they are very much preferred by travelers as it means one less cable to carry around, would have to find some way to associate IP to the credit card used for the hotel room. The obvious way would be to provision a unique userID and PW when the room-keys are generated on check-in. This technology exists, but is not in use because it is inconvenient to the user; something the hospitality industry tries to avoid if at all possible. It would also require hotels to redesign how they offer internet service.

Yet even this has some problems. Take the case of a college football team bussing to another state for a Bowl game. That'll be a room block of anywhere from 15-30 rooms all on the same purchasing instrument, and yet there could be as many as 60 unique IP addresses requested by various devices on the team members and associated staff and adults. Is it good enough that there are 60 addresses associated to one name? Would the hotel have to issue a uid/pw for each person staying in the room block? The courts will have to decide what constitutes 'good enough' identity-glue in cases like these.

It is also possible that Hotels will start 'partnering' with the big Wifi providers out there like T-Mobile, and just use that authentication method. Internet will no longer be complimentary, but at least the Hotels would be out of the ISP business. The audit requirement would be outsourced to the same companies that can provide WiFi at every Starbucks in the land.

The big caveat here is wired access. Port 34A-423 (SW08/02/32) is in room 322, and IP address 192.168.202.33 was last seen on that port. This kind of data is pretty simply gathered, and can be associated with a specific room. Hotels with a significant wired internet installation wouldn't have to go with an extensive uid/pw setup, as they can already isolate network access to physical (paid for) location. Hotels like these would be able to migrate to SAFTEY Act compliant complimentary internet more cheaply than their wireless brethren. But who uses wired internet anymore?

This bill would change the nature of business travel. In my opinion it would make it more expensive, as internet access would be encumbered with an audit requirement that is significantly more expensive than the base network infrastructure. Complimentary access would more and more be a benefit only at the most expensive hotels.

Labels:


Monday, February 23, 2009

The Internet SAFETY Act

I'm sure this has made the rounds, but I've been out sick for the past week and thus not as caught up on my tech media as I normally would be. But a bill has been introduced to the US Congress that would:

SEC. 5. RETENTION OF RECORDS BY ELECTRONIC COMMUNICATION SERVICE PROVIDERS.

    Section 2703 of title 18, United States Code, is amended by adding at the end the following:
    `(h) Retention of Certain Records and Information- A provider of an electronic communication service or remote computing service shall retain for a period of at least two years all records or other information pertaining to the identity of a user of a temporarily assigned network address the service assigns to that user.'.
    At minimum this means keeping DHCP records for 2 years. What's a bit more unclear is whether or not just IP address is sufficient to meet the standard of, 'identity of a user'. I don't think it is, though the courts will have to clarify this. This tells me that we'd have to retain records associating IP address with authenticated user.

    For commercial ISPs this is an easier bar to pass, as you need a username and password or some such equivalent to get on their networks in the first place and be provisioned with an address. For entities like us who are sort-of ISPs for our students, and have very permissive usage policies for our faculty (sex-researchers have a legitimate business need to search for, you know, sex), it's a bit less cut and dried. What isn't yet clear, but is getting a lot of internet buzz, is whether or not home users fall under this requirement as well.

    Bills such as these make a fundamentally false assumption about the internet:
    The end points always require authentication prior to usage.
    So long as vendor-neutrality holds, anyone who can get on the network at all can pass traffic over it. The Internet's protocols have no header value for signifying whether the originating node is an authenticated access or anonymous access, they just don't care. Authentication is optional on the Internet, not mandatory.

    This bill would indirectly require mandatory authentication for network access. Yes, this is a trend in the business world these days (google term: NAC), but there are whole classes of network users out there that aren't even looking into this. The locally owned independent coffee shop, with the commercial DSL line and free WiFi, the Hotel with 200 guests sharing the same business Comcast line, these are the sorts of 'anonymous' network access where NAC solutions aren't likely to ever be in place.

    Ultimately, by the time I'm 50 I expect the Internet to have converted to a mandatory-auth scheme for access. However, we're not there yet, not even close. This bill needs to be fought.

    Labels: ,


    Thursday, February 19, 2009

    $8.3Bn

    A new budget forecast is out. It's now up to $8.3Bn for next biennium. Back when we thought it was just a $5.8Bn deficit, the governor handed the legislature a $33.5Bn budget. That now gets to be pared down to $31Bn somehow. Earlier, the $5.8Bn number was cited as 20% of the discretionary budget. Which would make $8.3Bn about 28.6% of the discretionary budget, of which Higher Ed is a part.

    Ouch.

    But then, we kind of expected the forecasts to get worse. Alas.

    The Legislature doesn't have a lot of options. Cutting is the easiest thing to do from a procedural point of view, as any new taxes have a large process they have to go through before being approved; thanks to the Washington State initiative process. However, any time you try to cut any of the unprotected sacred cows, such as childhood healthcare or public education there will be phone calls. Lots of phone calls.

    I expect the 2010 initiative process to include more than one attempt to roll back a cut made this year. We'll see.

    Labels:


    Tuesday, February 10, 2009

    Budget jockying

    Today in the Seattle PI was this headline:

    UW may face hundreds of job cuts

    In short, the University of Washington may have to lay off quite a bit of staff if the budget rumors going around are true. Rumors that say that the higher-ed budget cut would be 50% above what has already been proposed.

    As it happens, this is in line with an email that President Shepard sent last week. The higher-eds have dispatched lists of what they'll have to cut if the higher cut targets are passed. And they're doing their best to scare people. I don't know exactly what was in our package, but it was grim. On purpose.

    Monday, the same day the above news was released, WWU announced the creation of an Outplacement Center in HR. This is to assist those staff that are given a layoff to find new jobs. I checked, and for Salaried Exempt Professionals like myself, they are required to give me either a sliding scale of warning (based on years of service, in my case 5 months notice) or a check equivalent to the same amount of salary. So if there are layoffs in the non-Union ranks, these people will need the Outplacement Center.

    This is a tacit admission that our budget woes are deeply unlikely to be addressed without a reduction in force of some kind.

    Labels: ,


    Monday, January 26, 2009

    Software install and maintenance contracts

    In this modern era, it is becoming more an more common for vendors in the Windows world to either require, or strongly suggest that the vendor perform a software install on a server. In the past this required either sending a physical body out to the location, or using something like PC-Anywhere to do the install. Now, a wide variety of web-based remote-control packages are on the market that greatly simplify getting the knowledgeable install-geek onto the server in question.

    More and more often, vendors are offering maintenance and update contracts contingent on console access. While these greatly simplify maintaining a package for small offices who don't have the IT oomph to really do it themselves, these are a great pain for those of us who manage the servers themselves. What's really bad is when web software (typically IIS and .NET based) is subject to these sorts of contracts.

    We have a small number of IIS-based web-servers that are shared with a variety of departments. ATUS and ADMCS are the biggest consumers, of course, but other departments have their own stuff on there. This also includes several 3rd party apps we've put in over the years. These servers have a lot on them.

    What happens when we get more than one software package with this sort of contract attempting to run on these IIS servers? It means that, at least in theory, multiple vendors have nearly unrestricted access to these web-servers. As these servers are general-purpose servers and not dedicated to this one application, this is a pretty major data-security issue.

    This isn't quite as big a problem when the application is a more traditional client/server app, or the app resides on its own dedicated server. We don't like that kind of app-server running with AD credentials on console, but we can work around that. Web-servers, though, run a lot of apps.

    In the UNIX world, I have heard of vendors requesting the ability to SSH into a server in order to do installs. The context of this was humor, as in, "look at the stupid vendor." In general, if a vendor asks for local root to a server for a simple install, the answer will be a resounding no way. So what makes the Windows world different, that they'll permit a third party root-access to their own servers? Perhaps because it takes a lot less skill to do Windows administration at least half-way right, so vendors have to compensate for less comprehensively trained system administrators. Unfortunately, it makes them less nimble when they do run into shops with strict controls on what runs on the web servers, and who is allowed console access to them.

    Labels: ,


    Friday, January 23, 2009

    SeaMonkey 2.0 and SSL

    Yesterday I downloaded a nightly-build of SeaMonkey so I could see how things are going. It's functional, I think most of the updates are on the mail side which I haven't tried. I like it as a browser anyway.

    Looking at the what's new list there are a few things that stand out:
    • Making the Extension environment more Firefox like
    • Making the rendering engine more Firefox like
    • Migration from Thunderbird
    • Add-On notification, like Firefox
    And something they didn't point out...
    • Complain about un-chained SSL certificates like Firefox.
    I could have sworn I've griped about this before, but I can't find the post. Here in the land of IT, vendors of all kinds ship web interfaces with self-signed SSL certificates. Generally speaking this is just fine, since these are appliances/applications/interfaces that a VERY small group of people have access to, and any SSL is better than none. Chaining to a trusted CA isn't as important since I very likely manage the box/widget/app myself and trust it. But Firefox (and now SeaMonkey 2.0) gripes about it, since it is, technically, unsafe.

    Yes, I can add exceptions. This works for things with a static file. But for certain other things, such as HP Integrated Lights Out boards, regenerate their SSL certificates every time they power-cycle, forcing you to re-add the exception every time that server reboots. For these, adding exceptions doesn't work. In my line of work, I must have umpty hundreds of little SSL-enabled web-pages all over the place.

    NetWare, at least last time I checked, defaulted to using the IP-certificate instead of the DNS-certificate for the Novell Remote Monitor. Since I never access that with an IP address, this will trigger a gripe from Firefox as the Subject doesn't match what's in the URL bar. For this reason, and others, one of my post-install tasks is to change that to load the DNS certificate (and disable the Xserver, nfs, and afp servers).

    When I'm doing a lot of work on systems with funky certificates, this can get downright aggravating. When I was doing work in the Novell Beta for OES2-SP1, I had a lot of test trees set up, with their own Certificate Authorities, and PKI environment. If I had been using Firefox for all of that, by now I'd have had A LOT of "Organizational CA" certificates in my browser root-cert store. Instead, I was lazy, used SeaMonkey, and just clicked past the gripes.

    Since I have legitimate reason to be regularly hitting web-sites with bad SSL certificates, it would be really nice if there was some way to turn off the hard-stop warning FF (and now SM 2.0) come with, and go back to an earlier mode.

    Also on my List? Vendors who don't allow anyway to update their pre-shipped SSL certificates. Grrrr.

    Labels:


    Wednesday, January 21, 2009

    Website stats

    We purchased Urchin's web stats package before Google bought them. We're still using that creaky old software, even though its ability to interpret user agent string is diminishing. I'm not in the webmaster crew for this university, I'm just a client. But I do track the MyWeb stats through Urchin.

    I also track our MyFiles (NetStorage) stats. This became more interesting the other day when I noticed that just over 40% of the bandwidth used by the Fac/Staff NetStorage server was transferred to user agents that are obviously WebDav. This is of note because WebDav clients are not javascript enabled, and thus will not register to things like Google Analytics. If I had been relying on Google Analytics for stats for NetStorage, I'd have missed the largest single agent-string.

    Even though Google bought Urchin, it makes sense that they dropped the logfile-parsing technology in favor of a javascript enabled one. Google is an advertising firm with added services to attract people to their advertising, and it's hard to embed advertising in a WebDav connection. It used to be the case that RSS feeds were similar, but that's now a solved problem (as anyone who has looked at slashdot's feed knows).

    In my specific case I want to know what the top pages are, which files are getting a lot of attention, as well as the usual gamut of browser/OS statistics (student myweb has a higher percentage of Mac hits, for one). One of the things I regularly look for are .MP3 files on the Student MyWeb service getting a lot of attention. For a while there the prime user-agents hitting those files were flash-based media player/browsers embedded on web pages, just the sort of thing that only logfile-parsing would catch.

    One thing that the NetStorage logs give me is a good idea as to how popular the service is. Since apache logs will show the username if the user is authenticated, I can count how many unique user ID's used the service over a specific period. That can tell me how strong uptake is. I may be wrong, but I believe Google Analytics wouldn't do that.

    The Urchin we have is still providing the data I need, but it's still getting stale. It's OS detection is falling apart in this era of Vista and 64-bit anything. But, it's still way better than Analytics for what I need.

    Labels: , ,


    Thursday, December 11, 2008

    Bad weather

    We're due for a storm up here. On Monday, the forecast discussion from the National Weather Service said that all of the computer models were unusual agreement about the Fri-Sun environment. The jet stream had dipped out in the Gulf of Alaska, and that meant we were on the express lane for an arctic low.

    The description is one I'm familiar with since I grew up in the American Midwest. This is what's called an Alberta Clipper, since in the Midwest the weather pattern described above has the jet-stream dip over the Rockies instead, which meant the weather systems came out of Alberta. Only, this system is, you know, 1500 miles West of where it should be.

    Whatcom County is in a special weather enclave itself. If you go to the Google Maps page of Blaine, WA and click Terrain, you can see what I mean. Bellingham is at the south end of the Fraser River valley. That river valley acts as a corridor for cold wind when the weather is right, and it'll be right this weekend. When the low passes over the Cascades, it'll park over eastern Washington and the wind direction will change. This is where the wind will start roaring down the Fraser.

    The forecast for the next week is unusually cold, with highs expected to be in the 20's. If we get much snow before that, it'll be a bad thing with all these hilly streets; we'll get a lot of iced up streets. On the good side it should be sunny, so road that gets sun should melt.

    The one time I had a friend with a GPS at my house we figured it was around 650 feet. A bit lower than I expected, since we usually got snow when the snow-level dropped to1000ft. There must be something in the microclimate around my house, because we seem to have a virtual elevation of between 900-1200ft. Since the only way to the country road from my house involves three very steep, and shady, hills, it is entirely possible I'll be snowed in until Monday. We'll see.

    Labels:


    Wednesday, December 03, 2008

    Infiltrating the market

    Over on The Open Road there is a very interesting blog post. It talks about how Microsoft and Red Hat approach the market, and touches on Novell.
    Microsoft offers a full ecosystem of software to would-be buyers, but its greatest success may actually result from its strategy to present customers with an "and" decision when initially purchasing Microsoft technology, rather than a difficult "or" decision.
    And I really see this. The argument has been made internally that what you get from a Microsoft Enterprise CAL is worlds above what we can get from a Novell academic seat license, which follows into cost-effective discussions (and not good ones). It is soooooo easy to go all Microsoft, whereas a pure Linux solution requires a lot of stitching, and translation-glue.

    The article goes on to point out that Red Hat's targeting people looking to do forklift upgrades from Unix to Linux. And then points out that Microsoft wins more of that traffic than Red Hat does, by a good margin. Largely because the Microsoft family of products is very complete.

    As it points out, Novell figured this out a few years ago when they launched their collaboration with Microsoft. The fruits of which arrived today with OES2 SP1, and the Novell CIFS stack and Domain Services for Windows. This allows OES2 to do something you can't do with Samba (yet), pretend to be a full up AD Domain Controller.

    And yeah, Novell's current marketing slogan is, "Making IT work as One," which is a clear embracing of the "and" concept described. If they could make DSfW work on plain SLES, it may make it an even more attractive product for people.

    Labels: , ,


    Saturday, November 29, 2008

    10,000 hours

    I read an excerpt of a book a week or so ago. Always dangerous, as it lacks context. But the general principal of the book was the observation that to get really really good at something requires about 10,000 hours of practice. There are no 'naturals', just people who are naturally more pig-headed than others who can get to 10K hours.

    10K hours is 2-4 hours a day for 10 years.

    The studies were about things like child prodigies, or top tier athletes who get Olympic gold at age 22, and retire by 30. That sort of thing. It seems that almost all of these people started their thing by age 6, and by age 8 there was already a break between the kids who'd ultimately reach the peak of their field and those who'd merely be very good. The ones destined for peak were giving 2-3 hours a day at age 8, where the other group had cut back.

    I believe this also applies to technical expertise. As anyone who has done any job searching in my field knows, there are real breaks for experience levels; 1-3 years, 4-6 years, 10+. Those of us in the 10+ area (and by now I am there with NetWare, and by the end of December I can claim that with Windows) are pretty much technical experts. We've put in the time over the years to get good.

    However, we work in a field where, "Change or Die," is an accurate mantra. The IT industry of 2008 is markedly different than it was in 1998. Windows NT installs right now are laughed at. Very, very little of the operating systems and software in active use in 1998 is still able to be on a support contract. It is hard to be a 10K-hour expert in something in our field, you have to put in 8 hours a day for 5 years.

    My first real exposure to NetWare was in a class I took for my CNA back in the Autumn of 1996. That was on NetWare 4.0, so at least my first experience was with NDS. In fact, my first job with NetWare was with 3.x, so I had to learn bindary on-the-job.

    I consider myself to be an expert in NetWare. I've been actively administering it for 11 years now, so if I'm not across the 10K line I'm really close to it. This is only possible because the 'change or die' mantra has not applied to NetWare over the years. Lets take a look at the biggest disruptions of how things work in NetWare (kernel). This isn't incremental changes, this is fundamental re-learnings of how things work. Sort of like what all the Windows engineers had to go through when Active Directory came onto the scene.
    1. The move to TCP/IP. This by far is the biggest disruption since 1996. NetWare 5.0(?) introduced the ability to do NCP over TCP/IP natively, and not tunneled IPX-over-IP. This required replacing IPX SAP, something the routers just did, with SLP, a service that needed configuration and setup.
    2. The NSS file-system. This was a much lesser move than the TCP/IP one, as it worked on a general level (trustees, quotas, etc) the same as TFS did. Tweaking it for performance, however, was a dark art for many years and much learning was derived out of this.
    3. Protected memory. A concept familiar to anyone who has used Windows or Linux, and all NetWare admins are by now administering one or both of these OS's. While some modules can't use it for whatever reason (iPrint, NetStorage) others (GroupWise) could.
    4. Native File Access Pack. NetWare could do AFP since the NW3 days, the same for NFS. SMB was another story. It was with NetWare 5.1 that NFAP came on to the scene, and NetWare 6.0 where it came built in and performed much better. The ability to use protocols other than NCP for your Windows clients was embraced by many shops.
    There were more changes, but in my mind these are the biggest four. You will note the complete lack of OES in this list. That's because this is a list of the changes to NetWare, and OES-Linux is not NetWare. OES-Linux represents the sort of "change everything you expect" that the rest of the industry does, that the Novell ecosystem hasn't had.

    Over the last 12 years NetWare has remained markedly static. This has allowed enough time for people who don't do this every waking moment to achieve a high level of expertise with NetWare. While this is good for NetWare, it unfortunately shows how NetWare has lagged behind the rest of the industry.

    It is my opinion that OES-Linux represents a decade of pent up change that needed to happen in NetWare but didn't. This is why old time NetWare admins are having such trouble moving to Linux, they're being asked to support an Operating System that they don't have anywhere near the same level of expertise in and that is uncomfortable. I know I'm moving from an OS that I know exceedingly well to one where there are still, "here be monsters," marked out on my mental map. I'm also having to give up, "10+ year experience with NetWare," in favor of, "2-4 years of experience with Linux," and that doesn't feel good professionally.

    But... that is the nature of our field. Just when we get really good at something, it's time to throw it out and learn something new. That something may be an incremental change from what we know (Windows 2003 vs Windows 2000) or a complete break (NT Domains vs AD Tree). But, learn we must. Us NetWare wonks have just been sheltered from it for some time.

    Labels: , , ,


    Monday, November 24, 2008

    Budget 2009-11

    Sounds like the last analysis, the $5.1Bn number did not include, "caseload analysis." Or, analyzing increased case-loads to state agencies due to really bad economy. It sounds like when that is factored in, the projected deficit is closer to $5.8Bn.

    Why is Washington State racking up the deficits? It's simple, we're more vulnerable to economic downturns than other states. That's because Washington has no Income tax, so most of the income for the State government comes from Sales Taxes. Sales Taxes are different from Value Added Taxes in that the taxed entity is the terminal consumer rather than the whole supply chain as a whole, so it is your average citizen that bears the full responsibility for the 8.3% tax on that new car. Consumer spending is projected to drop way off, and that in turn creates a major budget shortfall for the State government.

    The Washington State sales tax is 6.5%, but Counties and Cities can add to that. Here in Bellingham, the sales tax rate is 7.8%, and down in downtown Seattle the rate is 9.0%. Counties and Cities also earn income through Property Taxes, which are less vulnerable to declining economic times (i.e. dropping house prices) due to how the taxes are calculated.

    Here's hoping that the projections have been overly pessimistic.

    Labels: ,


    Thursday, November 20, 2008

    Budget numbers revised again

    To $5.1Bn. That number includes the $4.6Bn for the next biennium, but the $0.5Bn deficit for THIS year. Joy.

    Labels: ,


    Wednesday, November 19, 2008

    The revised budget is out

    As predicted, $4.6Bn instead of the $3.7 they were talking about earlier. What does that mean for me and Western? In the words of two of my bosses today:
    For our state, revenues are currently projected to fall around 10% short of projected state expenditures. The magnitude of the shortfall is estimated to be about $4.6 billion. Since about half the state"s budget is protected from reductions through constitutional or other means, to make up the 10% shortfall would require an average of a 20% reduction in the rest of the state agency budgets. We are in that latter category of state agencies whose budgets, on average, would have to be reduced by 20%.

    Just what does that mean for Western? The 20% reduction is in the 60% of our budget that comes from state support. So, it"s 12% of our operating budget.
    So, expect a 12% cut to the budget. Right. Can't we just raise tuition?
    If tuition were raised to the maximum currently allowed by law (7% per year) for resident undergraduates, the additional funds would reduce the magnitude of the cut to something in the neighborhood of 8.7% of our operating budget.
    Still pretty hefty. However, the Legislature still has a full session to go over the budget, and it still has to be signed. Who knows what'll change between now and when Session ends. However, the prudent fiscal planner will be looking for cuts up to 12% of operating budget.

    More close to home:
    Second, [the President] has asked us to prepare scenarios about how we might respond to a 2%, 3.8%, and 5% permanent reduction for the next biennium.
    So it isn't terribly likely that ITS, much less Technical Services, will be asked to whack 12% of operating budget. This is a good thing to this selfish person. 12% of operating budget for Tech Services would be people, since I'm pretty sure the sum total of our non-salary expenses is less than 10% of our budget. Whew.

    Still, this is going to put a major lid on purchases for the next 3 years. Within that period our blade servers fall off warranty, which is going to incur certain replacement expenses (almost definitely for new ESX cluster nodes). On the other hand, it gives me a really good line to use for cold-calling vendors...

    Labels: ,


    Thursday, November 13, 2008

    Bad budget predictions

    Quoth one news source:
    Dunshee expects the state budget deficit will balloon to as much as $4.6 billion after next week’s revenue forecast.
    You can guarantee that I'll be looking for next week's revenue forecast. $4.6 billion, for those keeping track, is a lot larger than the $2.7bn they were saying earlier. The measures I talked about earlier would have to be added to, if things really are as bad as that article lets on. The share of the $2.7bn WWU was allotted this year could be handled through use of reserve funds and other high finance things, or so said the President in September. A 70% larger deficit is another story, and that could lead to program cuts and/or lay-offs.

    Lay-offs are a worry. I'm "professional" so there is no union behind me when the axe starts swinging, so positions like mine involve less paperwork and get more return in the case of termination. Unlike the Classified employees I don't have bump-back rights. In their case, if a, say, Fiscal Technician III gets terminated who previously held the title Fiscal Technician II, that FT-3 could bump-back into an FT-2. That bump-back is a displacement, so the FT-2 that got bumped would then exercise any bump-back rights she had, and on down the line until someone actually gets laid off. In my case, if they terminate me, I'm gone. Period. Much less paperwork.

    But then, I don't know if that's how it works around here. The last really serious round of lay-offs was long enough ago that only two people in my department were around back then, and that's a lot of time for a management culture to change. However, if Technical Services gets handed an axe to apply to a position, my read of the lay of things is that I'm in the top 3. Also, we have no Classified employees in my department.

    So, yeah. The budget forecast is something I'll really be paying attention to.

    Labels: ,


    Tuesday, October 28, 2008

    The gift of security

    Last Christmas my parents bought me a 4GB IronKey. This is a nifty little device! And really, the gift of data security is rather thoughtful. And yesterday, it finally got the new firmware that enables Linux support!

    Between then and now I haven't really been able to use it at work. And since transporting files between work and home is one of the nicer features of it, it has largely sat unused. But right this moment it is mounted to my openSUSE 10.3 workstation. This beats a floppy disk for transporting pgp/gpg keys.

    Labels: , , ,


    Tuesday, October 14, 2008

    Office

    OpenOffice has released version 3.0 in the last few days.

    This naturally brought me to think about how uptake is going. WWU does offer OpenOffice as an option on our ATUS Lab machines, along side MS Office, but I have zero idea how often it is used by the student body. I have OO installed on my primary work machine, which is no surprise considering that's a Linux machine.

    What is the future of OO? Will it ever supplant MS Office?

    It seems to me that Microsoft is really pushing for SharePoint to take over from plain old file-serving. This is evident in the extent that SharePoint is integrated into Office 2007. I have to expect that the next version of Office will be even more tightly coupled to some web-based platform.

    This is a problem for OO. While it may be possible to shim SharePoint integration into OO, perhaps through cunning uses of Mono, it means that OO will of necessity be one to three versions behind Microsoft in terms of features. Alternate platforms like Novell Teaming and Conferences are SharePoint-like, but they're not, you know, SharePoint.

    Unfortunately, it looks like you can only go so far being able to read and create 100% MSO-compatible files. There's this other stuff that needs to be able to be done. WordPerfect learned this lesson in the years between MSO's ascension and the coming of age of OpenOffice as the, "Office package that is not Microsoft's," first choice. WordPerfect had the ability to save to PDF for years, and from what I hear is still the default choice in Law offices. However, WordPerfect is now the #3 behind OO and MSO.

    OpenOffice has a difficult road ahead.

    Labels: ,


    Thursday, October 09, 2008

    More on the budget

    The budget crunch I mentioned the other day has made the local paper. This is not that surprising, since we're one of the bigger employers in the area, and 20K students make a noticeable economic impact to the area.

    Labels: ,


    Wednesday, September 10, 2008

    That darned budget

    This is where I whine about not having enough money.

    It has been a common complaint amongst my co-workers that WWU wants enterprise level service for a SOHO budget. Especially for the Win/Novell environments. Our Solaris stuff is tied in closely to our ERP product, SCT Banner, and that gets big budget every 5 years to replace. We really need the same kind of thing for the Win/Novell side of the house, such as this disk-array replacement project we're doing right now.

    The new EVAs are being paid for by Student Tech Fee, and not out of a general budget request. This is not how these devices should be funded, since the scope of this array is much wider than just student-related features. Unfortunately, STF is the only way we could get them funded, and we desperately need the new arrays. Without the new arrays, student service would be significantly impacted over the next fiscal year.

    The problem is that the EVA3000 contains between 40-45% directly student-related storage. The other 55-60% is Fac/Staff storage. And yet, the EVA3000 was paid for by STF funds in 2003. Huh.

    The summer of 2007 saw a Banner Upgrade Project, when the servers that support SCT Banner were upgraded. This was a quarter million dollar project and it happens every 5 years. They also got a disk-array upgrade to a pair of StorageTek (SUN, remember) arrays, DR replicated between our building and the DR site in Bond Hall. I believe they're using Solaris-level replication rather than Array-level replication.

    The disk-array upgrade we're doing now got through the President's office just before the boom went down on big expensive purchases. It languished in the Purchasing department due to summer-vacation related under-staffing. I hate to think how late it would have gone had it been subjected to the added paperwork we now have to go through for any purchase over $1000. Under no circumstances could we have done it before Fall quarter. Which would have been bad, since we were too short to deal with the expected growth of storage for Fall quarter.

    Now that we're going deep into the land of VMWare ESX, centralized storage-arrays are line of business. Without the STF funded arrays, we'd be stuck with "Departmental" and "Entry-level" arrays such as the much maligned MSA1500, or building our own iSCSI SAN from component parts (a DL385, with 2x 4-channel SmartArray controller cards, 8x MSA70 drive enclosures, running NetWare or Linux as an iSCSI target, with bonded GigE ports for throughput). Which would blow chunks. As it is, we're still stuck using SATA drives for certain 'online' uses, such as a pair of volumes on our NetWare cluster that are low usage but big consumers of space. Such systems are not designed for the workloads we'd have to subject them to, and are very poor performers when doing things like LUN expansions.

    The EVA is exactly what we need to do what we're already doing for high-availability computing, yet is always treated as an exceptional budget request when it comes time to do anything big with it. Since these things are hella expensive, the budgetary powers-that-be balk at approving them and like to defer them for a year or two. We asked for a replacement EVA in time for last year's academic year, but the general-budget request got denied. For this year we went, IIRC, both with general-fund and STF proposals. The general fund got denied, but STF approved it. This needs to change.

    By October, every person between and Governor Gregoir will be new. My boss is retiring in October. My grandboss was replaced last year, my great grand boss also has been replaced in the last year, and the University President stepped down on September 1st. Perhaps the new people will have a broader perspective on things and might permit the budget priorities to be realigned to the point that our disk-arrays are classified as the critical line-of-business investments they are.

    Labels: , , , , , , , , , , , ,


    Monday, September 08, 2008

    Web-servers

    Looking at usage stats, the amount of data transferred by Myweb for Students has gone down somewhat from its heyday in 2006. I blame Web 2.0. Myweb is a static HTML service. We don't allow any server-side processing of any kind other than server-side includes. This is not how web-development is done anymore. This very blog is database backed, but Blogger publishes static HTML pages to represent that database, which is why I'm able to host this blog on Myweb for FacStaff.

    If we were to provide a full-out hosting service for our students (and staff), I'm sure there would be a heck of a lot more uptake. A few years ago there was a push in certain Higher Ed circles to provide a, "portfolio service", which would host a student's work for a certain time after graduation so they could point employers at it as a reference. We never did that for a variety of reasons (cost being a big one), but the sentiment is still there.

    If we were to provide not only full-out hosting, but actual domain-hosting for students, it could fill this need quite well. Online brand is important, and if a student can build a body of work on "$studentname.[com|org|net|biz]" it can be quite useful in hunting down employment. Several of the ResTek technicians I know have their own domains hosting their own blogs, so the demand is there.

    I've never worked for a company that did web-hosting as a business item, so I've only heard horror stories of how bad it can get. First of all, we'll need a full LAMP stack server-farm to run the thing. That's money. Second, we'll need the organizational experience with the technology to prevent badly configured Wordpress or PhpBB installs from DoSing other cohosted sites from resource-exhaustion by hackers. This is a worker-hours thing.

    Then we'd have to figure out the graduated problem. Once a student graduates, do we keep hosting for them? Do we charge them? Do we force them off the system after a specific time? Questions that need answers, and these are the kinds of questions that contributed to the killing of the portfolio-server idea.

    Personally, I think this is something we could provide. However, someone needs to kick the money tree hard enough to shake loose the funds to make it happen. Perhaps Student Tech Fee could do it. Perhaps it could be a 'discounted' added-cost service we provide. Who knows. But we could probably do it.

    Labels: , , , ,


    Wednesday, September 03, 2008

    A history of browsing

    With Google Chrome now out and about, it got me thinking about my own browsing habits.

    I first heard about this new 'www' thing back in college. I had been on the Internet for a couple years by that point, but http-free. Telnet and FTP were my friends. And so was Gopher. The very first browser I ever used was NCSA Mosaic, which was running on a DEC graphical station in one of the computer labs. It was a whonking big piece of software, so I didn't use it much. But use it I did.

    Then someone installed a Netscape Navigator version to one of the CompSci machines and that somehow changed things. If I'm remembering right, it was version 0.97, and had the, "pulsing throbbing N" in the upper right corner (in a readme.txt: "And remember, it may be spelled "Netscape", but it's pronounced, "Mozilla."). After the 1.0 version it changed to the 'comet over the earth' logo that would stay with Netscape for the next many years.

    The first browser I installed on a machine I owned was a package that I've forgotten the name of. It was a rather cunning use of telnet and the lynx text browser to emulate a graphical browser. This was before my university allowed SLIP or PPP dialups, of course. Once they did that, I could get my own version of Netscape. And did so.

    And there I sat for a long number of years. I flirted with Opera a few times. Tried out IE. But, in the end, I stuck with Netscape. Opera just didn't feel right, or render things the way I expected. IE was the evil Microsoft, and I avoided it where possible.

    And then... Netscape Communicator got stale. It hung in version 4.7something for aaaaaages. IE started eating Netscape's lunch. And things just got too annoying. At work I started using Opera, version 4.0 IIRC. It worked for the most part, but was still unsatisfactory.

    I stuck with Opera for maybe 3 months before moving over to... sigh.... IE. IE5.5 was at the time significantly better than the alternatives. I moved to it exclusively at home, finally ditching Communicator. I believe the reason I moved had to do with IE's 'security zone' architecture, which made a lot of sense for me. Certain sites I wanted to grant 'trusted' status to, and it would just work with no popups. For the rest of the internet I could set different settings. It worked great.

    And then I heard about an open-source version of Netscape called Mozilla. I kept an eye on it for a while, waiting for it to become more stable. I installed it on the home Linux machine since obviously IE wouldn't work there. In time, Mozilla matured to the point where it was stable enough for me, and I figured out how to make its security features do what I wanted them to do. I think I formally moved everything to Mozilla shortly after the 1.0 release.

    And there I stayed, right up to the point where Mozilla killed Mozilla in favor of Firefox (formerly Firebird). I dutifully switched. And over the course of the next year I got steadily more annoyed with Firefox. Some of which I complained about here. I don't remember how I found out about it, but I learned of the SeaMonkey project that was recreating the Mozilla experience in a fully community-supported way. And that's where I am now.

    Unfortunately, SeaMonkey is beginning to look as dated as Communicator was. Firefox 3 may be less annoying than earlier Firefox versions, so I probably have to try it out. Opera is pretty good, and I've spent time using 9.5 already, but the plugin community is weak and it doesn't do exactly what I want when it comes to privacy settings. IE8 is out of the picture since it's Windows-only. And so is Chrome, though I hear that'll be changing.

    Labels:


    Monday, August 25, 2008

    Dynamic partitions in Server 2008 and Cluster

    It would seem, and I've yet to trace down definitive proof of this, that Windows Server 2008 Clustering still has the Basic Partitioning dependency in it. This limits Windows LUNs to 2TB, among other annoyances. Such as the fact that resizing one of those puppies requires a full copy onto a larger LUN rather than extending the one you already have. How... 1999.

    Labels: , , , ,


    Tuesday, August 19, 2008

    IPv6 uptake

    Not too long ago I asked the question about what our plans were about IPv6. While the telecom guys didn't actually laugh at me, it was clear the question was considered a bit silly. After all, we are the proud owners of a full out class B (140.160.0.0/16) so IPv4 address exhaustion is not something we're likely to run into very soon. Certainly not by 2014 when we should be 'out' of IPv4 address space on the internet. Will IANA repossess our 'unused' spaces? Don't know, probably not.

    That said us moving to IPv6 will require a few things, none of them internal processes:
    • A bill by the State Legislature mandating IPv6 uptake by all State agencies. We're not subject to the already existing Federal rule.
    • Enough of the general internet is routing IPv6 that the IPv4-over-IPv6 tunneling causes enough headaches we need to move due to user revolts.
    • Some new widget, be it server tech or some kind of net-attached device, only supports IPv6 and we need to get it running.
    Of course, if the powers that be here decided that it must be done, and our telecom people fail to talk them out of it, it could still happen.

    Labels: ,


    Monday, August 18, 2008

    My favorite compiz plugin

    Screenshot

    I love that plugin. Ad-hoc screen captures. I use it all the freaking time. It has managed to engrain itself into my expectations about how computers should work to the extent that I started swearing at XP the other day since I couldn't do that. Such a simple thing, but my how effective it is at capturing a quick snippet of what I want. No more do I have to...
    1. PrtScrn the application I want
    2. Open Paint
    3. Paste the screencap
    4. Copy the section I need
    5. Create new canvas
    6. Paste the copied section
    7. Save to file
    That's a lot of work. This widget? Much faster and easier.

    Labels: ,


    Thursday, August 07, 2008

    Budget crunch update

    The University President has just sent out an email describing what the university plans on doing in light of the Governor's memo. Unfortunately, there isn't a lot in there.
    • There WILL be a hiring freeze.... and this will manifest by having newly vacant positions have to go before a Provost/Vice-Provost review before being filled.
    • Salary increases will still be given per negotiated contracts.... for classified people, which I'm not. We don't know what us Professional types will get. And won't know until the State passes the next budget during the coming winter.
    • Out of state Travel WILL be restricted.... and this will manifest by having travel requests go before a Provost/Vice-Provost review before being approved. Like they always do.
    Almost all of this comes down to, "we'll be looking even harder at expense requests, so be careful." We really won't know how bad it'll get until the Legislature convenes and starts working on bills. They open, if I remember right, just after the new year.

    So, I may yet get to BrainShare 2009, but it may require my boss to talk a lot faster than normal. We just won't know until we get a feeling for how much pressure the Provosts and Vice-Provosts are under to contain costs.

    On the plus side, the SAN upgrade is pretty clearly critical to the function of this university, so that'll get approved. Or there will be riots in the halls outside my office.

    Labels: , ,


    That's backwards

    On this article is this phrase:
    Between following comment threads, checking in with friends on Twitter, reading a few blogs with RSS feeds, and conquering a mountain of e-mail, we have plenty of conversations to keep track of.
    Considering how my friends use these sorts of technology, it should read...
    Between following comment threads, checking in with friends on Twitter, reading a few emails, and conquering a mountain of blogs with RSS feeds, we have plenty of conversations to keep track of.
    Email is now the back-channel of social intercourse. Of course, mailing lists like bugtraq or knitty are still around, but are easily handled through very simple filtering in your email program. But, most of this sort of thing is done over http[s] somehow. I'll use email for unicast asynchronous conversations with someone that I want kept semi-private (i.e. not googleable by the general public). But for the most part, the only email I get is mailing list traffic and comment notifications for my blogs, tracked threads, and whatnot.

    Labels:


    Monday, July 21, 2008

    Overthrowing Blackboard

    The most recent Western Front, our Student newspaper, ran an article about looking for a replacement for Blackboard. You can read the article online here.

    And now, a warning.

    This is my personal opinion, it in no way reflects the official view of this department or any WWU entity.

    There.

    The Computer Science department is apparently evaluating Moodle as a possible Blackboard killer. I personally cheer this research, since I don't particularly like Blackboard. Plus, it could shave a few months off of any replacement project that may come of this. That said, there are a few bits of the article that need some amplification or clarification.
    Western’s computer science department is in the process of testing a new e-learning software this summer quarter that could potentially replace Blackboard sometime next year.
    Eh, not really. And the reason for this is actually alluded to in the next paragraph:
    “I think students tend to find [Blackboard] more frustrating especially when it goes down and they have something due for a class and cannot access it,” said David Bover, chair of the computer science department.
    If Blackboard goes down for even a single day, mayhem ensues on campus. Blackboard is, for lack of any other way to put it, critical path for us. If it goes down, the learning function of this University is significantly negatively impacted. Any instabilities are noticed, as Dr. Bover pointed out. This is a system that has to be rock stable, and always there when you need it. We have very few systems in that class of service, and SCT Banner (our ERP solution) is one of the others.

    What this means is that any replacement for Blackboard has to be at least as stable as Blackboard, and provably so. It needs to come with Enterprise level support with a rapid response option, something I'm not sure Moodle has. It also needs to support the load we throw at it, and provide at least Blackboard-equivalent functionality for the exact same or less in resource costs.

    Our Blackboard infrastructure right now includes 7 physical servers (only three of which are VM candidates) and 2 network load-balancers. Also involved are a large number of people on the back end to handle the Banner integration stuff that happens behind the scenes to do things like create new courses, manage enrollments in courses, and maintain the user accounts inside Blackboard. This second group, the Banner integration, is where the second largest engineering challenge will be for any presumed Blackboard-to-Moodle migration project. This second group is also the one that is hardest for the CompSci group to evaluate work-flow for.

    What's more, due to various requirements, we need to have the ability for students who challenge grades to have access to course-work and grade-book for the class in question. We need something like 3 years of archive for this, so we will have to be dual-stacked for up to 3 years after migration go-live in order to handle challenges to courses done while still on Blackboard. This archival blackboard install will require us to have software and at least 2 servers to support it.

    Moving to Moodle will also require us to be a bit more nimble in responding to user requests. As the article says:
    With Moodle, professors will be able to install plugins or create their own to fit specific needs for their course.
    This will ultimately require a dedicated Moodle programmer somewhere within ITS. That's a staff position, which means budget. Due to how WWU's accounting works, we can't just take the hardware and software savings from Blackboard and convert it into a new FTE. Whether or not this FTE is a lateral transfer from somewhere within ITS already, is up to the migration project people whoever they may ultimately be.

    In short, any Blackboard-to-Moodle project will not be run to completion by Fall 2009 even if CompSci comes up with a Moodle config that reaches feature parity with Blackboard, and looks to be just as stable. The Banner integration alone will require significant engineering on the part of ITS departments, and to be blunt the group who 'owns' Blackboard is seriously short-staffed right now and can't even think of a migration project yet. Load testing and sheer re-education on the part of Blackboard users will take a lot of resources and time all by itself.

    The somewhat ironic part of this is that Moodle was brought to my attention a couple of Brainshares ago. At the time we were having serious stability problems with Blackboard, so several of us got kinda wistful-eyed at the thought of giving Blackboard the ole heave-ho. Since then I've heard that Moodle is beginning to eat into Blackboard's installed base, especially in cash-strapped Community Colleges. One can hope.

    And in closing, a few hints to any of those CompSci people working on this project:
    • For the love of Richard Stallman, make sure the database behind Moodle is either MSSQL2005 or Oracle. We already run two RDBMS's, we will not be running a third *cough*mysql*cough*. No matter how politely you ask. Asking us to add a brand new RDBMS onto the critical path is simply too much to ask for. There is a slight preference for Oracle since that's what Banner runs in and that eases certain integration tasks.
    • Please answer the question of, "The system is in flaming ruins, and we're all flummoxed. Who do we call?" Because the reply we give to irate Professors wondering why they can't report grades matters a lot, "We're working closely with the vendor right now," sounds way better and more professional than, "We've asked some people in the community who know this stuff better than we do, and hope to have some answers soon." We have way more Professors (and students for that matter) who don't give a wet noodle for the ethics behind their software, just so long as it work right.
    • Please account for a test environment that functions identically to production. Since Blackboard is critical path, we actually have a test environment we do things like work through upgrade problems, validate configs, and troubleshoot errors out of production. This right now is a single box with MSSQL2005 and Blackboard installed on it, compared to Production where the web-servers, content servers, and database server roles are all on different machines. Blackboard allows this, but not all software plays nice like that.
    Thank you. And remember, this is just me blowing wind, it doesn't represent anything like an official viewpoint of this university, this department, or this office.

    Labels: ,


    Twitter & https

    One thing that twitter has done right is the use of HTTPS. If you go to the secure version of their login page, https://twitter.com/login, your session will stay SSL. Unlike certain other sites that bump you back to http, twitter will keep the whole session, and the all important login cookies, secure end to end. I like this.

    On insecure wireless networks, or even secure ones with malicious people legitimately on it such as the type you find at any Security conference, it is possible to side-jack those cookies with simple network tools. And with those credentials, all too many sites allow you to impersonate the person that logged in with those credentials. Some sites, like Livejournal, offer the ability to bind a log in to an IP address but that only works if you're not behind a NAT gateway such as you find at ye-olde-coffee-hut.

    By allowing users to keep their entire twitter-web session in SSL, twitter does security right. Yes it is an expensive operation to terminate, especially as user uptake increases. But that they offer it at all is a very good thing.

    Labels:


    Wednesday, June 18, 2008

    Firefox3 and IT laziness

    I'm just now loading FF3. Like IE8, they got a lot more paranoid about bad SSL certs. They've gone beyond just coloring the toolbar orange, and are now fully blocking bad SSL sites..

    This is a bad thing for us IT wonks. Every appliance and web-ap comes with an SSL functionality these days, and all too many of these use a self-signed cert. Unfortunately, FF3 blocks access to these sites by default and you have to add an exception (a multi-click, "are you SURE you want to do this"? procedure) for each one. All but about 5 of our HP servers have iLO cards with certificates are self-signed, so that's A LOT of sites that'll need to get added.

    I'm sure there is a, "Don't be paranoid about SSL Certs," setting somewhere in about:config, but I haven't looked.

    Like IE8, this will push the IT administration industry to be less lazy about SSL compliance. We need that, but it'll be 5 years before we really get there. As that's how long it'll take to phase out old "self-signed is good enough for internal use" software and widgets.

    Labels: ,


    Monday, May 05, 2008

    Linux @ Home

    My laptop at home dual-boots between openSUSE and WinXP. There are a few reasons why I don't boot the Linux side very often, some of them work related. And, what the heck, here are the two reasons.

    1: Wireless driver problems
    I have an intel 3945 WLAN card. It works just fine in linux, well supported. What throws it for a loop, however, are sleep and hibernate states. It can go one, two, four, maybe five cycles through sleep before it will require a reboot in order to find the home wireless again. If it doesn't lock the laptop up hard. Since my usage patterns are heavily dependent upon Sleep mode, this is a major, major disincentive to keep the Linux side booted.

    I understand the 2.6.25 kernel is a lot better about this particular driver. Thus, I wait with eager anticipation the release of openSUSE 11.0. This driver is currently the ipw3945 driver, and will eventually turn into iwl3945 driver once it comes down the pipe. What little I've read about it suggests that the iwl driver is more stable through power states.

    2: NetWare remote console
    I use rconip for remote console to NetWare. Back when Novell first created the IP-based rconsole, they also released rconj along side ConsoleOne to provide it. As this was written in Java, it was mind bogglingly slow. This little .exe file was vastly faster, and I've come to use it extensively. Unless I get Wine working, this tool will have to stay on my Windows XP partition. It works great, and I haven't found a good linux-based replacement yet.

    Time has moved on. Hardware has gotten faster, and the 'java penalty' has reduced markedly. RconJ is actually usable, but I still don't use it. Plus, it would require me to install ConsoleOne onto my laptop. It's 32-bit, so that's actually possible, but I really don't want to do that.

    The Remote Console through the Novell Remote Monitor (that service out on :8009) has a nice remote-console utility, but it also requires Java. I'm still biased against java, and java-on-linux still seems fairly unstable to me. I don't trust it yet. It also doesn't scale well. When I'm service-packing, it is a LOT nicer looking to have 6 rconip windows up than 6 browser-based NRM java-consoles open. Plus, rconip will allow me access to the server console if DS is locked, something that NRM can't do and is invaluable in an emergency.

    Once the wireless driver problems are fixed, I'll boot the linux side much more often. Remote-X over SSH actually makes some of my remote management a touch easier than it is in WinXP. And if I really really need to use Windows, my work XP VM is accessible over RDesktop. There are a few other non-work reasons why I don't boot Linux very often, but I'll not go into those here.

    So, oddly, NetWare is partly responsible for keeping me in Windows at home. But only partly.

    Labels: , , , ,


    Monday, April 28, 2008

    The GPL in a software-as-a-service world

    Just this last weekend I went to Linuxfest Northwest, which is held here in Bellingham. This is nice! It's just a short drive.

    One of the talks I went to was held by Ted Haeger, currently of Bungee Labs. The topic of the talk was one he had just posted to his blog, "Sharing Source Code In The Cloud".

    One point he brought up that I hadn't heard of before is that the GPL triggers when you 'convey' the software to someone else. And that the GPL specifically excludes where the software is hosted on a server and users just use the software there, so long as the software itself never leaves the company in question. This is exactly what Google did and still does. All of their search IP was built on an OSS platform, but is still held as the crown jewels of their company; all because they haven't given the software to anyone else.

    Apparently, this 'loophole' is being exploited by a LOT of new companies trying to get in on the software-as-a-service market. Such as Bungee Labs, as it happens. What effect will this have on the state of GPLed software? Hard to say, the market is still in its early days.

    It makes you think.

    Labels: ,


    Thursday, April 17, 2008

    NetWare and Novell, changing a company

    A couple days ago Richard Bliss had a long blog entry about, "Novell's Cash Cow - How NetWare almost killed the company". It had some very interesting points. Some we knew:
    We are all familiar with NetWare, the dominate Network Operating system of the 1980s and 1990s. We are all familiar with Microsoft's tactics of penetrating the NOS market with Windows NT by focusing on using Windows as an application platform.
    Apparently Richard worked for Novell around 2001. I find that interesting since my first BrainShare was 2001, and that was when they announced the release of NetWare 6.0. While there he saw what seemed to be an outright denial that NetWare had been passed up by Windows and something new needed to be done.

    In 2001 I knew that Windows had for all intents and purposes won. The only place you ever really saw NetWare servers were as file-servers, or running GroupWise or the small handful of apps that used NetWare as an application server. The stalwart loyalists among us saw this as annoying, but not a major problem.

    It was also good for Novell's bottom line. NetWare still accounted for a large percentage of their revenues. Even though the writing was on the wall, they were still making real money on it so didn't see a need to change. This is why NetWare 6.0 introduced the AMP stack to NetWare, as a way to better make NetWare an application server and to slow the loss of customers. At BrainShare 2001 there was open speculation about "NetWare 7.0" and what it would look like.

    And there still was until 2005 when Novell announced what the next version of NetWare would be. This being after the SUSE and Ximian purchases, it would be based on Linux. This move had been rumored, and alternately derided and lauded, for some time. There was a great wailing and gnashing of teeth on the part of the stalwart NetWare loyalists. It also started an exodus of customers, as Novell's financial reports at the time point out.

    Fortunately for the company, they started actively promoting (for certain values of 'active' that are higher than they were previously, but still in the theme of Novell Stealth Marketing) and developing their other products, like GroupWise, Novell Identity Management, ZenWorks, and most especially their Linux business. It took them until last quarter to turn in a quarter in the black, and NetWare revenues are under 20% of total now. So, they've turned the corner and are no longer dependent on the NetWare cash cow. They have a couple of them in the field now, which is a MUCH healthier place to be.

    It's a funny thing, but one of the reasons why NetWare is such a kick-butt file-server compared to everything else is why it's a challenging environment to develop in. Had Novell seen the light earlier and bought SUSE (or rolled their own Linux distro) in... 1999 instead, right after the NW5.1 release, they still would have run into the fundamental architectural problems in 32-bit linux that make it an inferior file-serving platform for large environments. By 2008 their server could have been a LOT more mature, and perfectly poised to take advantage of 64-bit Linux.

    Novell in the 1990's is not an example of a 'nimble' company. It is trying to get there now through diversification. Not many companies (especially tech companies) have survived the loss of their prime money earner; Apple has done it through OSX, which required a fanatically loyal fan base to survive the dark years. This is the prime reason people kept predicting the imminent demise or buyout of Novell. Now that they're earning profits again, and have diversified away from just the OS sector, they're not going to be going out of business any time soon.

    Now if only they had better SMB packages and programs. I hear repeatedly from peers who support SMBs that Novell's packages and programs in that space are lacking or exploitative. Significant revenue, and more importantly mindshare, are in the SMB market. Plus, today's SMB is tomorrow's large or global enterprise.

    Labels: , ,


    Tuesday, April 15, 2008

    Beta attitudes

    One thing I've noticed while working on this beta is a change in attitude. Specifically, attitude regarding problems. I've run into problems so far that would have had me throwing things across the room by now. Yet, instead I get that 'ahah!' feeling and proceed to figure out how it went poink exactly like that. And then report it. That feels good.

    All of my prior bug-hunting has been post-release, when we ran into issues in production. Now, it's in pre-release and the bugs and issues I find now will be fixed by release (or at least documented so people know to expect it to break that way).

    It's an interesting change in attitude.

    Labels: ,


    Thursday, April 10, 2008

    Generations

    My boss pointed us at an article this morning, about a topic near and dear to managers everywhere. Boomers are retiring, and for every 2 boomers leaving, 1.2 workers are entering the workforce. I know I've been watching a steady drum-beat of retirements the last few years.

    In the article is this sentence:
    Statistically, Millennials are the most pluralistic, integrated, high-tech generation in American history—traits that make them ideally suited to our increasingly demanding, diverse and dispersed global workplace.
    I had to snort. Not 10 years ago you could replace the word "Millennials" with "GenX" and it would have been true. And before that the, "tweeners," the folk between GenX and the Boom, got the same treatment. And the boomers before them got it too. Each new generation is the most puralistic, integrated, high-tech generation in American history. Whatever the people being born right now get called will be the same and the Millennials will get to feel a bit fuddy duddy.

    My boss is a boomer, and our chief Unix admin is a boomer. That's it for Technical Services, so it doesn't apply as much to us as other groups. We're all GenX here, with one Millennial shared with Telecom who is moving on to something else soon. It's a bit different across the hall in ADMCS, but not a lot.

    Labels:


    Wednesday, April 09, 2008

    Protecting against Cosmic Rays

    Apparently Intel filed a patent for a system to protect chips from cosmic rays.

    This makes a lot of sense. I've explained to many people over the years just why it is that the computers that run the Space Shuttle are so much less capable than what they have on their desk. Part of that reason is due to cosmic rays. The smaller the transistor feature size, the more vulnerable the transistor is to charge flipping from things like cosmic rays. NASA has to deal with this any time it puts hardware in space.

    The Cassini Probe around Saturn regularly goes into safe-modes due to Galactic Cosmic Rays that twiddle bits they aren't supposed to. Again, NASA expected these and engineered around them. Of scientific interest, they've run into different concentrations of these galactic cosmic rays during the cruise to Saturn and while in orbit around Saturn.

    So why is Intel worrying about this here on the surface of the Earth? Because we also get cosmic rays down here too. Not nearly as many, but we get them. For years I've used the phrase, "Must have been a cosmic ray strike," when something computer-like breaks in truly weird ways. Only partially am I being flip about it.

    In a more wider scope, these 35nm feature size chips they're now coming out with are designed to work in very low radiation environments. Such as the type humans can live in unsupported. So when NASA/ESA/JAXA/Proton send laptops to the ISS, they're probably running older CPU's that are more radiation tolerant. Space is not a good place for supercomputing clusters.

    Labels:


    Stupid user tricks

    I had a case of this the other day. I was minding my own business, when suddenly one of my monitors starts going wonky. This is an LCD monitor, but an older one, so it isn't inconceivable that it could be going bad. How else would I explain the weird spots that were showing up on it? They looked like this:

    Pretty spots

    Which looks like weird hot-spots in the screen. So I started to muttering. Plus, the screen was noticeably dimmer. Futzing with the brigthness and contrast settings didn't do a thing for it either. Plus it seemed to follow no matter which window I put on the hot spots.

    Then, I realized what the problem was.

    Pretty stars

    Compiz. Somehow, the rdesktop window that represents had been made slightly transparent, and the wall-paper was showing through. This screen shot is with the transparency fully down, you can barely make out the ConsoleOne icon in it.

    So no, I didn't have a monitor going bad, I had a mouse mis-cue somewhere that caused that rdesktop window to go a bit transparent. No worries!

    Aie.

    Labels: ,


    Wednesday, April 02, 2008

    From Slashdot: Should users manage their own PC's?

    Should IT Shops Let Users Manage Their Own PCs?

    It's a very Web 2.0 concept. And there is some merit to it. Back in the day when workstation lock-downs were getting common in workplace settings (ZENworks was good for that), there was a debate about some of this. At my old job one thing we wanted to lock down was the wall-paper. That one thing would help reinforce the idea that this was a WORK Pc, not a home PC. The counter argument to this is that such user environment things are mostly harmless, so permitting them allows the lock-down to be less intrusive on the user.

    This is another step in that direction. Workplaces have PC configuration standards for a variety of good reasons. You want all machines plugged into your network to not be festering hives of scum and malware, and these sorts of standards can prevent that. On the other end of the scale, high end users know the tools of their field better than your general IT desktop support person does and in theory can do more with the tools they know versus the tools forced upon them.

    On the control end of the spectrum, you keep IT costs down by standardizing the configs in your enterprise. This keeps the Total Cost of Ownership down, a big thing for companies with the right internal costing controls (*nudge nudge*). One tech can support many more end users that way, since the range of things they support is kept to a minimum.

    On the freedom end of the spectrum, the end user gets exactly the tools they want to do their job. They're happier that way. And since they support themselves, IT costs are controlled. One tech can support many more end users that way, since the bits they're supporting are significantly reduced.

    The 'freedom' end of things runs smack into some standard industry practices, such as volume licensing and big-buy discounts. Dell, for instance, sells PCs cheaper if you buy them by the gross rather than in singles as users are onboarded. Specialized packages like AutoCAD also come cheaper if you buy them in packs of 10 rather than one at a time. Licenses all too often these days are timed and enforced, so you could have end users forgetting to renew the license on their Scrivener install and being non-productive for a few days while purchasing gets them a renewed license. The big 'endpoint management suites', what they seem to be calling the AntiVirus/Firewall package these days, all assume enterprise central control.

    On the other hand, users liked being treated like reasoning, intelligent people who are capable of making choices about their work environment. This makes for happier workers.

    Also working in this favor is the trend to webify everything in the workplace. The days when you have a whonking big file-server to store all the company data on are slowly going away, and being replaced with things like SharePoint (which can get just as big, don't get me wrong). The fights we've had in the past about how to roll out a new Novell Client to all our desktops would be moot in such an environment as the 'client' is called 'Firefox' (or Gnome, or Office 2007).

    On the downside of the 'freedom' end of things is piracy. Tools like Zen Asset Management are there to make sure that the software in use is actually legal. In this freedom environment there is the significantly increased probability of someone bringing their 'backup' copy of something from home to install on their work machine and creating legal liability for the company if they get audited.

    Another downside is interoperability problems. The Microsoft Office users create document-macros that the WordPerfect Office users can't run, and the OpenOffice users can't read the WordPerfect files. The Microsoft Office users publish things to SharePoint, where the OpenOffice users drop their stuff onto a handy WebDAV server somewhere. Office peer-pressure will still work on software selection to a point, even if you absolutely love Package Q for your day-to-day work you won't use it if the software everyone else in the office uses can't do a thing with it.

    The trade-off here is balancing the chaos and increased direct costs 'freedom' will introduce to the IT environment versus the productivity bonuses and intangible benefits (morale). That will decidedly depend on the culture of the office, and what it is that they do. I know some people who would leave their current jobs just to get the freedom to order the machine they want and use the software they want to use, even if it means somewhat less benefits.

    A friend of mine recently changed jobs. The old job was was Microsoft. Since Microsoft is a software development firm of some significant size, they try to dog-food their own stuff wherever possible; even if the tool is a poor fit for the task at hand. She spent a lot of time clubbing her software to do what it didn't really want to do, all the while knowing that there were two non-Microsoft packages that did exactly what she wanted. The new job is not with Microsoft, and the first day there they gave her an order sheet to order the software she wanted; they wanted results and trusted her to turn them in in an understandable format. Thus, the joys of freedom.

    So, to answer the question, it depends. It depends on corporate culture to a significant degree, as well as the sector the company is in, as well as the work being done. In highly creative areas such as design, the benefits can be great. In highly regimented areas such as accounting, perhaps not so much or at least a high degree of freedom won't be worth the ultimate costs.

    Labels: ,


    Thursday, March 06, 2008

    More HP annoyances

    They've recently revised their alert emails to be even more badly formatted. The below slug of text contains a critical alert. Somewhere.


    Your alerts
    Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DSeQ.1Lki.DKEbf000 Priority:
    Critical; Products: All-in-One Storage Systems,Disk-to-disk Backup,HP Integrity
    Entry-level Servers,HP Integrity High-end Servers,HP Integrity Mid-range Servers;
    OS: not applicable; Release Date: Feb 26 2008; Description: Advisory: (Revision)
    FIRMWARE UPGRADE or WORKAROUND REQUIRED to Prevent Rare Scenario of Potential
    Logical Drive Failure on HP Smart Array Controller Attached to Multiple Drive
    Arrays if Drive Failure or Incorrect Drive Replacement Occurs After Power Loss
    (c01232270) Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgW.1Lki.ccEcI000 Priority:
    Recommended; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP
    ProLiant ML Servers,MSA Disk Arrays,Server Controllers; OS: not applicable; Release
    Date: Feb 28 2008; Description: Advisory: FIRMWARE UPGRADE RECOMMENDED for Certain
    HP Smart Array Controllers to Avoid False SAS and SATA Hard Drive (c01382041)
    Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTf8.1Lki.DeBcEbI0 Priority:
    Routine; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP ProLiant
    ML Servers,HP ProLiant Packaged Cluster Servers,Server/Storage Infrastructure
    Management Software; OS: not applicable; Release Date: Feb 20 2008; Description:
    Advisory: HP Systems Insight Manager (HP SIM) Running in an Environment with a
    Large Number of WBEM Managed Nodes May Experience Task Page Interface Slowdown or
    Out of Memory Errors (c01371984) Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgo.1Lki.DAMEdA00 Priority:
    Routine; Products: HP ProLiant BL Server Blades,Server Management Software; OS: not
    applicable; Release Date: Feb 28 2008; Description: Advisory: Virtual Connect
    Enterprise Manager (VCEM) 1.0 May Not Be Able To Add Virtual Connect (VC) Domains
    to a Virtual Connect Domain Group After Updating the VC Domain Group on a ProLiant
    Server (c01382035) Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgi.1Lki.CPQEca00 Priority:
    Routine; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP ProLiant
    Packaged Cluster Servers; OS: not applicable; Release Date: Feb 28 2008;
    Description: Advisory: ProLiant Essentials Virtual Machine Manager (VMM) Displays
    Incorrect VMM Warning Message on FireFox Browser for ActiveX Controls (c01382044)
    Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgQ.1Lki.MAEcC000 Priority:
    Routine; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP ProLiant
    ML Servers,HP ProLiant Packaged Cluster Servers; OS: not applicable; Release Date:
    Feb 28 2008; Description: Advisory: (c01382042) Document: Customer Advisory;
    Link: http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgg.1Lki.CJcEcY00
    Priority: Routine; Products: HP ProLiant DL Servers,HP ProLiant ML Servers,HP
    ProLiant Packaged Cluster Servers,Server Network Interface Cards; OS: not
    applicable; Release Date: Feb 28 2008; Description: Advisory: Novell NetWare
    Teaming Driver (QASM.LAN) May Fail to Load After Upgrading to ProLiant Support Pack
    for Novell NetWare 7.80 (or later) (c01382039) Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgU.1Lki.XIEcG000 Priority:
    Routine; Products: All-in-One Storage Systems,HP Integrity Entry-level Servers,HP
    Integrity High-end Servers,HP Integrity Mid-range Servers,HP ProLiant BL Server
    Blades; OS: not applicable; Release Date: Feb 28 2008; Description: Advisory:
    (Revision) HP ProLiant Smart Array SAS/SATA Event Notification Service Version
    6.4.0.xx Does Not Log All Events to the Windows Registry (c01177411) Document:
    Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTgk.1Lki.CVEEcc00 Priority:
    Routine; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP ProLiant
    ML Servers,HP ProLiant Packaged Cluster Servers,ProLiant Essentials Software; OS:
    not applicable; Release Date: Feb 28 2008; Description: Advisory: SmartStart
    Scripting Toolkit Reboot Utility May Not Respond Or May Display a Segmentation
    Fault Error On a ProLiant Server Running SUSE LINUX Enterprise Server 10 Service
    Pack 1 (SP1) (c01382031) Document: Customer Notice; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DTh2.1Lki.DdWYEbE0 Priority:
    Routine; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP ProLiant
    ML Servers; OS: not applicable; Release Date: Feb 28 2008; Description: Notice:
    Linux System Health Application and Insight Management Agents (hpasm),
    Lights-Out-Driver and Agents (hprsm), and NIC Agents (cmanic) Are Now Delivered as
    a Single rpm Package for all Supported HP ProLiant Linux Servers (c01382040)
    Document: Customer Advisory; Link:
    http://alerts.hp.com/r?2.1.3KT.2ZR.xl4lg.C0m3Bi..T.DU7I.1Lki.DbNQEaL0 Priority:
    Routine; Products: HP ProLiant BL Server Blades,HP ProLiant DL Servers,HP ProLiant
    ML Servers,HP ProLiant Packaged Cluster Servers; OS: not applicable; Release Date:
    Feb 28 2008; Description: Advisory: Virtual Machine Manager (VMM) 3.1 May Cause a
    (c01383032)


    This is a plain-text email, no HTML->Plain formatting weirdness. It COMES this glommed together. Time to send a cranky-gram.

    Labels: ,


    Tuesday, February 26, 2008

    The future of the IT career path

    There was an article in Computerworld a week or so ago that just caught my eye.

    IT career paths you never dreamed of

    The short of it is that IT as we've known it, a separate stack, is being integrated into the general business functions. Things like software-as-a-service, outsourcing, and freakishly fast WAN pipes mean there is less call for people like internal application developers, systems analysts, and system administrators. Those that remain, have a decided focus on project management, and focus on the business.

    I see some truth to this. I've known for years now that the kind of job I fit best in, only exists in organizations larger than a certain size. Organizations smaller than a certain size tend to be subject to, "the computer guy," being in charge of everything computery. WWU is large enough that I can specialize in one field, file-server maintenance and upkeep, without having to be 'the computer guy' to a bunch of people.

    This also means that my desktop support skills have atrophied from where they once were. Since everyone thinks that, "working in computers," means in reality, "desktop support," I have a hard time convincing family that I only know a little more than they do about why their Thunderbird broke in just that way. Doctors have this problem too, I hear.

    Anyway. The article mentions that newer job titles are including the word, "architect," in them. And I really agree with this, since any company needs people with an enterprise view of their IT infrastructure. I'm one of those people for Western, especially when it comes to the file servers. It is people like us who sheepdog consultants hired to implement new technologies.

    Which brings up another thing about the article. The article is rather .COM centered, which I understand. Us .EDU types really do live in a different world (where ELSE are you going to get 4000 people pounding the exact same file server at the exact same time?). The idea of hiring consultants (very expensive temp workers) to do the heavy lifting during upgrades is something we laugh ourselves silly over, since we barely have the money to BUY the new upgrade (even with our hefty .EDU discounts) much less pay someone else to put it in for us. Something simpler like outsourcing 90% of our on-site helpdesk work through a SE Asian call-center and remote-control apps is something we could possibly do, but the union those helpdesk techs belong to would pitch a fit. The same thing applies for a contract service to manage printers. Similar sorts of things apply to the non-profits of the world (the .ORG world), though perhaps not the union angle.

    But out there in the for-profit world, and the for-profits larger than SOHO or SMB, that's another story entirely. I don't know how much longer there is going to be a call for file-server jocks.

    Labels: ,


    Tuesday, February 12, 2008

    OpenID and eDirectory

    A friend asked me a few months ago if eDir 8.8 supported openID.

    The answer to that is, "not natively." At its very base, openID is a method of granting foreign security principals access to resources. There will have to be some form of middleware that translates 'joebob.vox.com' into 'ext-1612ba2.extref.org.tree' (or even "joebob.vox_com.extref.org.tree") in eDirectory, but once that translation is in place eDirectory will support openID just fine. Now that openID is getting serious traction this becomes more interesting. But natively? Not really.

    That said, eDirectory is very well suited for being the identity store for an openID-enabled database. It scales freakishly far. This is exactly the sort of 'distributed identity' idea that Novell has pointed out at the last few BrainShares. Through this sort of distributed identity system is would be possible for two Universities to grant members in other organizations, with their own eDirectories, access to a web-server based collaboration system.

    Labels: , ,


    Monday, February 04, 2008

    Today's 18 year olds...

    Over the time I've been here there has occasionally been a list posted in the break-room. This list is the, "Incoming freshman today...." list of things they know, experience, or haven't experienced. It contains things like:
    • Were born in 1990
    • ...have never known life without cable or satellite TV.
    • ...probably have never seen a rotary dial phone.
    • ...have had internet access for most of their school life.
    And other such things. Ostensibly this is to help foster an understanding of where incoming freshman are coming from, but generally they just cause faculty and staff to just feel a bit old. In tech circles this sparks conversations about the first computers we used.

    Which got me thinking about a few things. One of the items that is frequently put forth about Kids These Days (tm) is that they don't KNOW anything, they just know how to FIND things. There is some debate about this, but it is a common sentiment. I believe that kids these days (KTD) have figured out keyword based searching, and the search engines have gotten good enough at mind-reading that arcane search incantations aren't needed nearly as often as they were in the past.

    Before Google, there was AltaVista. This was an era of the internet where boolean search incantations were needed to really narrow down to what you wanted. I didn't switch to Google for a long time because Google didn't have the NEAR search term, which I used on AltaVista as a way to narrow results to be more relevant. I didn't know at the time that Google effectively threw that term in on every search.

    Those of us who lived through that era of the internet built up searching skills. I remember some searches I did back then that were pretty complex. I can't remember the exact terms used, but they looked like this:

    bootes AND (antaries OR proxima) AND (fulcrum NEAR pinnacle)

    I had a logic class in college, so these sorts of parenthetical statements made sense to me. Still do, I just don't end up needing to uncork the boolean logic to find what I need anymore as the search engines have gotten good enough that I don't NEED to do it. I know google allows much of the above, but I haven't had to do it so I don't know the syntax for it.

    So I posit that yes, KTD don't know anything, but neither are their search skills robust.

    Which brings me to Novell. I got to thinking what a NetWare administrator in 1990 had to know to do their job, and how I could fit into such a hypothetical time.

    Right now if I don't know the answer to a problem I have a few methods to figure it out.
    1. Hit the online Novell Knowledge Base over at novell.com/support
    2. Hit the peer-support forums over at forums.novell.com (or nntp://forums.novell.com/ if you prefer old-school)
    3. Pay for a support incident
    4. Ask around the office
    In 1990 the options were similar, but a key player was missing:
    1. Hit the peer-support forums over on CompuServe, which required a modem and a CompuServe account.
    2. See if the problem is mentioned in the book-shelf of manuals, which was a big investment to own.
    3. Pay for a support incident.
    4. Ask around the office.
    When I first started this Novell Administrator gig in 1997 most of the admins I knew had CompuServe accounts, even though the support forums had officially moved to NNTP. There was still plenty of traffic on the CS servers, though those died out fairly quickly. The office I started in had a subscription to a monthly publication from Novell of their support knowledge base, which I made extensive use of. Somewhere in there Novell made the archives web-searchable and I stopped using the CD's.

    As I see it, a NetWare admin of 1990 was on average more knowledgeable about their product than the NetWare admin of 2008. Such administrators avoided the cost of paying for support incidents by having the manuals in hard-copy form, and plonking down real money for CompuServe accounts. If I have a weird problem I'll hit up the Novell KB to see if there is a TID on it, then check the support forums to see if it is mentioned there, before I'll expend an incident on the thing. In time I've managed to teach myself how NetWare works in some very basic ways, simply by troubleshooting oddball problems. This is why I typically end up talking to backline support when I call in, unless the problem is a known issue in the private KB. My skills are probably on par with what was normal 'back in the day'.

    I think this holds true for a lot of the tech field. Back then there was a lot of stuff you just had to KNOW. Or failing that, have spent the money to get the backup resources in place (manuals, support contracts). These days a base understanding of how things work is the key to phrasing the right search queries in the online knowledge bases, and less rote memorization (training) can be effective in solving a greater list of problems.

    Prosthetic memory! Prosthetic training! The tools of geeks everywhere.

    Labels: , , ,


    Friday, January 25, 2008

    BrainShare social networking

    I am going to BrainShare this year!

    It has been interesting to watch the social networking thingy related to BrainShare over the years.

    Two years ago, and for many years before that, the primary social group for BrainShare was novell.community.brainshare. This was an NNTP (you remember Usenet?) group hosted on the same servers that host the Novell Support Forums. BrainShare 2006 saw an increase in a certain kind of anti-Novell traffic that was already fairly common in the lead up to BrainShare 2005. The denizens of the group tend to be old time Novell hands, and as you can imagine they were pretty upset about Novell's plans for NetWare. A few very vocal people managed to raise enough of a stink that there wasn't a lot going on in the group for 2006. Unsurprisingly, novell.community.brainshare was removed from the NNTP servers around May 2006 (though the google-groups version of it is still around, see the link).

    Last year Novell came up with BrainShare Connect as the social networking thingy. It had forums, blogs, and various other things to try and get attendees hooked up with each other and interacting. It got a reasonable amount of traffic, but many folks who had been regulars of the NNTP group were not there. I checked in every few days to see if anything new was up. For 2006 and 2005 I had checked the NNTP group daily, since there really was that much going on.

    This year BrainShare Connect is back, but... they didn't do it right. The same outsourced firm is handling it, but even though it has Web 2.0 stamped all over it the interface is markedly worse than last year. There are no blogs. There are no polls. The interest finders are... weak and obfuscated. The forums are implemented on PhpBB, but done wrong. As an example of the wrong, take a look at this screen shot of me Replying to a thread:

    Reply pop-over obscuring everything

    What am I replying to? I can't tell. That window can't be moved or resized. I better hope my memory is good. I don't know if this is a new PhpBB feature, a new version came out a while ago, or some customized mod from WingateWeb. Whatever it is, it isn't a good thing. The ability to see what you're replying to greatly eases the flow of conversation.

    And the logout screen is particularly interesting, too.

    The logout window with weird buttons

    What ever happened to "Cancel/OK"? Hasn't that been a de facto standard since, like, the Mac Classic came out 24 years ago? Proceed? I think that's the first time I've ever seen that particular word in that particular spot in an application developed by professionals.

    The NNTP group had plenty going for it, but it was spoiled by a few vociferous critics. In the last few months Novell has released a brand new HTTP interface for the support forums that is worlds better than what was there before. Novell could bring this function back in-house if they really wanted to, and I'd support that decision. That said, I do understand why they need/want WingateWeb to handle that function. I just wish they did it better.

    Labels: , ,


    Tuesday, January 22, 2008

    Distributed Identity (such as OpenID) and security

    Distributed identity systems are hot these days. Open-ID has been around for a while, and Yahoo! just jumped on that bandwagon. Possibly to stick it to Microsoft, who is deploying LiveID. Blogger just started allowing non-Google logins for things like comments.

    These systems work by splitting apart authentication (verify who you are) and authorization (what you're allowed to do). Single-Sign-On systems work this way as well, but these systems take that to a much greater scale. Once you've been authenticated by the trusted third party, you are authorized to access the specified resources. In the web domain this is easily handled through cookies.

    I noticed this text on the LiveID page I linked to:
    Microsoft's Windows XP has an option to link a Windows user account with a Windows Live ID (appearing with its former names), logging users into Windows Live ID whenever they log into Windows.
    I did not know that. Shows what I pay attention to. What this tells me is that it is possible to synchronize your local WinXP login with a LiveID. This causes me to glower, because I inherently trust my local system differently than I do miscellaneous web services. Yes, the authenticator is the piece I need to worry about as it is how I get to prove I'm me, and that's just in one spot. But still, one compromised account (my LiveID account) and everything is shot.

    Lets take it a bit further. It would probably be easy to get LiveID working inside of SharePoint. Especially since a developer SDK has been released to do just that. This would permit LiveID's access into SharePoint. Handy for collaborating with colleges working for other companies or universities.

    Now what if Microsoft managed to kerberize LiveID? That would make it possible to use LiveID to log in against any Kerberos enabled service, as well as almost anything ActiveDirectory enabled. It'd probably take a tree-level (or maybe domain-level) trust established to the foreign tree (LiveID in this case) to make it work, but it could be done. Use LiveID to log into Exchange with Outlook, or map a share. Use your corporate login to work on your Partner's ordering system.

    This scares me. In principle, not just because it's Microsoft I'm talking about here. Yes, it can be a great productivity enhancer, but the devil lurks in the failure modes. Identity theft is big business now, and anything that extends the reach of a single ID makes the ID that much more valuable. Social Security Numbers to us Americans are big deals since we can't renumber those, thus we have to protect them as hard as we can. Until we get a better handle on identity theft, these sorts of "One ID to rule them all," systems just make me wince.

    Labels: , ,


    Wednesday, January 02, 2008

    Where NetWare Fits

    NetWare 6.5 still holds top honors in one server niche. Even though it is a 32-bit operating system. That niche is the "large file-server" segment. I define "large" as, "lots of data, way-lots of concurrent users". Yeah, that's highly scientific. But "way-lots" means "over 1000 concurrent" to my thinking.

    We regularly run between 1200-6000 concurrent connections on our cluster nodes. This is a density that just doesn't happen all that often in the market. If you have 6000 users close enough together to all talk to the same file-server at LAN speeds using a protocol designed for file-serving (such as NCP, SMB/CIFS, or AFP), you're a big organization. 6000 is a large corporate campus, a large governmental entity of some kind, or a larger .EDU like us. Nationally, the number of 'large' file-servers like that is peanuts compared to the number of 'workgroup' (i.e. under 300 concurrent users) servers out there.

    It is therefore no surprise to me that Novell is not devoting a lot of engineering to supporting the top end of this market. While it may pay well, there just isn't enough revenue coming from these customers to try and handle the hardest-to-test use-case: very high concurrency. I find it disappointing because I AM one of those customers (a larger .EDU), but I understand the business drivers supporting the decision.

    For the moment, NetWare 6.5 (32bit) is the top-dog performance wise for our environment. That isn't going to stay true for much longer. It would not surprise me to find out that a Windows Enterprise Server (x86_64) with 16GB of RAM can out-perform a NetWare 6.5 (32bit) server with 4GB of RAM, simply due to the added room for a file-cache. What I don't know is how CPU-bound file-serving I/O is on a Windows Enterprise Server, that's the one area that could keep NetWare 6.5 (32bit) on top. I already know that OES2-Linux out-performs NetWare for NCP traffic, so long as you stay within CPU bounds.

    For high-concurrency applications, as far as I know NetWare still wins.

    Labels: , , , ,


    Tuesday, November 13, 2007

    NAT resets

    It turns out that the connection problem I reported earlier wasn't due to DHCP. The timing is just a coincidence. It seems to happen every 60 minutes. Yesterday I spent a lot of time on the phone with Linksys support working through their fault tree. Eventually they told me to RMA it. During that time I had several more captures that show the resets happening no where near DHCP-time. NTP traffic seems to be more closely associated on yesterday's sniffs, and is absent from the sniff from Friday.

    The resets are quite clear...
    Wireshark with lots of [tcp retransmit]
    As you can see. Jabber (gchat in this case) is the one that took it on the nose for this particular NAT table reset.

    Another example:
    Wireshark with lots of [tcp retransmit]
    Note the continued "guys? You still there guys?" from the AIM server. When the resets happen the TCP Retransmits are the best way to see it in the capture. In order to get a meaningful (and small) capture I used a Wireshark capture syntax like this:

    host [ip] and not (port 80 or port 443 or port 53)

    That captures just traffic to my IP, that isn't web or DNS. None of that is terribly stateful, so I don't care about it. Also, by not capturing web traffic, an hour of capture is generally under 2MB. We are not biiiig IM folk at our household. This made the capture a lot easier to read.

    Anyway, some of what I saw. It may be useful, or not.

    Labels:


    Sunday, November 11, 2007

    The mystery of the resetting connections

    Thursday I mentioned a bit of home network troubleshooting I was looking in to.
    At home I've been noticing some persistent connections have been getting resets. A couple of times now I'll be VPNed into work here, and the connection will drop. Other times I've noticed telnet connections to weird ports will get reset sporadically. What's going on?

    At home I'm on that network that's gotten some grief about discriminating against BitTorrent users, which I won't name here but you probably know.
    I now have a high quality network sniff, and there is plenty of gun-smoke.

    It ain't Comcast.

    The problem is the Linksys router.

    Looking at the network trace a particular pattern is repeated five times over the course of six hours. The Linksys router (a BEFSR41 v4.2 model) renews its DHCP lease, which it does every hour since Comcast sets the leases to last 2 hours. Immediately afterwards there is a slew of various Instant Messaging service login traffic, and more particularly the other application also re-logs in. Those connections were not FIN/ACKed, they were just plain dropped. In one case after the DHCP renewal there were a series of TCP retransmits from the internet that went unACKed by the router.

    What is clearly happening is that the Network Address Translation (NAT) table is being reset whenever the DHCP lease renews. I can understand that happening if the address it receives from the DHCP server is different than the one it already has, but clearly it is resetting whenever it gets ANY address from the DHCP server.

    What this means is that it is impossible for me to maintain a persistent connection to anything longer than 60 minutes. This is VPN, IM, IMAP, IRC, you name it. Several of those protocols have reconnection logic in them which can hide this sort of network instability, but others (VPN) aren't so lucky.

    Problem solved. Looks like I'll be in the market for a new home router! Something that isn't Linksys, since I need this problem solved NOW not in a few months when they get around to issuing a firmware update. A friend has already said that this could explain why some of his network gaming sessions always seem to crash after about an hour.

    Labels:


    Thursday, November 08, 2007

    Connection resets

    At home I've been noticing some persistent connections have been getting resets. A couple of times now I'll be VPNed into work here, and the connection will drop. Other times I've noticed telnet connections to weird ports will get reset sporadically. What's going on?

    At home I'm on that network that's gotten some grief about discriminating against BitTorrent users, which I won't name here but you probably know.

    Calling in to their Customer Support was pointless as they wanted me to go through fault isolation methods to see where the problems was. My router, their cable-modem, or what? Right, then.

    As I no longer have a working 10Mb hub, I can't just drop a laptop in the unprotected segment between the cable-modem and my router and do some sniffing. So I have to get creative. I remembered yesterday that the new desktop gaming system has two ethernet ports on the back. Ahah. A bit of googling brought me to the 'brctl' command in Linux for creating ethernet bridges.

    This is exactly what I wanted. Turn the (w-a-y more powerful than this function needs) gaming machine into a simple ethernet bridge, just so I can sniff traffic. I downloaded the latest Knoppix DVD ISO in the hopes that it'd have ethernet drivers for my motherboard. You see, this is a gaming PC that I built for Windows gaming. I did not build it for anything resembling Linux compatibility, so I had real fears that the LAN ports wouldn't be supported. Happily, Knoppix had a module for my ethernet ports and away we go.

    ifconfig eth1 0.0.0.0
    ifconfig eth2 0.0.0.0
    brctl addbr whitehat
    brctl addif eth1
    brctl addif eth2
    ifconfig whitehat up
    ifconfig eth1 up
    ifconfig eth2 up


    In my case, eth0 is the Firewire "lan" port that seems to be on every new machine these days. Once the bridge is up, I can run Wireshark on it with a ring-buffer. Once I see a spurious connection reset, I can stop the sniff and see what exactly happened to the connection. I didn't get any resets last night when I was monitoring, but I may tonight. We'll see where things are going. Did see some RSTs come in, but it wasn't clear if that was normal or not, as it was almost always on HTTP traffic. This machine has 2GB of RAM in it, so the Knoppix RAMDisk is quite large. I don't have to worry about having my ring-buffers starved for space and having the reset fall off the back of the buffer.

    If I can prove that the RSTs are coming from the ISP end of the connection and not my router I can go to customer service and tell them so. They'll try and tell me that since the RSTs are coming from the internet IP that the server there must be issuing it. Then I'll tell them that I have multiple internet IPs showing the exact same behavior, and all this started around the same time, and really, I find the possibility that all three (or so) servers got updated to exactly the same buggy TCP stack at the same time to be much less likely than this particular ISP's traffic shaper catching my traffic as collateral damage.

    They'll just shrug and say, "oh well," and that'll be that. It won't get fixed. But my call will be logged! My own minuscule vote will be in their tracking system by golly. Maybe it'll be the straw that causes them to tweak their shaper to be less aggressive.

    Labels:


    Wednesday, October 31, 2007

    It's that time of year

    It's Combined Campaign time! As WWU is officially a state agency, we get to give through the centralized web page for that.

    This is a login and password I use once a year. This is a login and password I forget every year, since the 'usually your userID is' thing is wrong for me. So I have the needed info squirreled away somewhere.

    This is EXACTLY the kind of thing that a distributed identity federation would fix. However, as anyone who has attempted to integrate umpteen bajillion different ID systems knows, that's a heck of a lot of work. So far as I'm aware there is no "State Employee ID Number" to index everyone on.

    Labels:


    Thursday, October 25, 2007

    Virtualization and security

    I've known for a while now that virtualization as it exists in x86 space is not a security barrier. Heck, it was stated outright at BrainShare 2006 when Novell started pushing AppArmor. The Internet Storm Center people had an article on it a month ago. And now we have an opinion from the OpenBSD creator about it, which you can read here.

    It sounds like the main reason virtualization isn't a security barrier is because of the CPU architecture. Intel is making advances with this, witness the existence of VT extensions. Also, as virtualization becomes more ubiquitous in the marketplace Intel will start making their CPUs more virtualization-friendly. Which is to say that they're not very VM friendly now.

    And as Theo stated in his thread, "if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system." Process separation is its own form of 'virtualization', and is something that is handled in software right now. Anything in software can be subverted by software, so having a hardware enforceable boundary makes things stay where they are put.

    Which is why I hold the opinion that you should group virtual-machines with similar security requirements on the same physical hardware, but separate machines subject to different regulations and requirements. Or put another way, do not host the internal Time Card web-server VM on the same hardware as your public web-server, even if they're on completely different networks. Or, do not host HIPPA-subjected VM's on the same ESX cluster as your Blackberry Enterprise Server VM.

    Virtualization as it exists now in x86-space does provide a higher barrier to get over to fully subvert the hardware. Groups only interested in the physical resources of a server, such as CPU or disk, may not even need to subvert the hypervisor to get what they want; so no need to break out of jail. Groups intent on thievery of information may have to break out of jail to get what they want, and they'll invest in the technology to do just that.

    Warez crews don't give a damned about virtualization, they just want an internet-facing server with lots of disk space they can subvert. That can be a VM or physical server for all they care. They're not the threat, though the resource demands they can place on a physical server may cause problems on on unrelated VM's due to simple resource starvation.

    The threat are cabals looking to steal information for resale. They are the ones who will go to the effort to bust out of the VM jail. They're a lot harder to detect since they don't cause huge bandwidth spikes the ways the warez crews do. They've always been our worst enemy, and virtualization doesn't do much at all to prevent them gaining access. In fact, virtualization may ease their problem as we group secure and unsecure information on the same physical hardware.

    Labels: , ,


    Saturday, October 13, 2007

    Student email

    Another piece on Slashdot today was about how GMail is increasing its limits since some users are going past what is already there. What's more, it points out that the two other biggest freemail systems have gone past GMail in terms of storage. Well, they kind of have to as gmail is something of the gold standard and if you're going to compete you have to be better then them. No biggie.

    But it does underline the sheer difficulty in providing email service these days. End users, thanks in large part to the work Google has done in gmail, expect the following in their mail service:
    • No significant mail quota
    • A fast, easy to use web interface
    • A fast, easy to use search function for mail inside the web client
    • Very effective spam filters
    • The ability to do everything you want without having to use a mail-client like Thunderbird
    That's a lot to live up to, so it is no wonder that .EDUs are actively considering forking over their student email to the commercial services. It is possible to do all of the above, but it is very expensive. The big enterprise email products (Exchange, GroupWise, Lotus Notes) all fall down on at least one of the above points. It is possible to cobble together something out of opensource components, but as we've learned the Achilles heel of the OSS mail stack is spam. Plus, the OSS stack has a tendency to fall apart when scaling to the levels we're at. And we soooo can't afford to serve student email out of the enterprise systems, so rock, meet hard place.

    As a side note, I know of at least one .EDU larger than us that serves student email out of Exchange. That's 50,000 accounts all told. So it can be done. But they're a private university, unlike WWU which is publicly funded.

    Yet, there are still problems with 'outsourcing' student email to Google or Microsoft. First and foremost, if our internet connection bombs students on campus are out of email. Second, data mining on usage patters by this highly desirable demographic run contrary to the spirit of .edu mail. Third, single-sign-on may be hard to impossible to accomplish, forcing students to have *shudder* more than one password to manage. Fourth, it may not be possible to 'skin' the interface with our official WWU web standards. Er brand.

    In the end, we could up our student mail quota to 2GB and students STILL wouldn't use it. Good email service is so much more than sheer quota these days.

    Labels:


    Monday, September 17, 2007

    Email encryption

    The last time I seriously took a look at email encryption was at my old job, using GroupWise 5.5. I did some poking around here with Exchange/Outlook and made it work, but it wasn't a serious look. Back then there was still real doubt about which standard would reign supreme: PGP (or GPG) vs S/MIME. PGP had been around for ages, where S/MIME used the same PKI infrastructure used by banks for secure online banking.

    Outlook and GroupWise both had S/MIME built in. Both used the Microsoft crypto API. Remember, this was GW 5.5 so there was no Linux version yet.

    If you look at posts on Bugtraq, clearly PGP is reigning supreme. A lot of posts there tend to be signed, and almost all of the signatures are GPG (the GnuPGP) or PGP. So that would tend to suggest that PGP-style stuff is winning. Except... bugtraq is primarily a Linux list that also bashes Microsoft, so the preference for the old school secure email (PGP) is easy to understand.

    Yet why are the major email systems shipping with S/MIME built in?

    There are several reasons why digitally signed email hasn't caught on. First and foremost it requires active use on the part of the user, in the form of explicitly stating "I trust this user and their certificate". Second, managing certificate renewals and changes adds work. Third, certificates for S/MIME are subject to the same SSL problems web-site certificates are, price. Fourth, the certificates (be it PGP or S/MIME) generally are only usable on a single operating system instance, which makes portability challenging.

    Thawte.com still offers free email SSL certificates for personal use. I haven't read the details, but I suspect that 'professional use' is invalidated, which would prevent WWU from going to them whole-sale. I'll have to look.

    The very nature of secure email makes it something only people who want it will strive for. This is not something that can be pushed down from On High unto the masses for enterprise deployment. Like sites with bad SSL certificates, Outlook will throw a Warning! message when it receives an email signed by a certificate it doesn't trust or know about. End users are notorious for being annoyed by pop-ups they view as superfluous. As with SSL certificates we have the Trusted Certificate Authority problem, which means that any external signed communication needs to be signed with a certificate already known by everyone (i.e. VeriSign, or similar).

    And ALL of this doesn't look at the problem of digitally signed email in web clients like gmail. I have many friends who use their web browser as their primary email interface. AJAX can do a lot, but I don't know if it can do secure decryption/validation of email. I'm pretty sure AJAX can do insecure decryption/validation, which sort of violates the point. Right now, in order to do actual secure email you have to use a full mail client with support for the relevant protocol(s). Which means that, as above, only people serious about email security will take the steps to do email securely; it can't be mandated and invisible to the user.

    So, things haven't changed much in the 4-5 years since I last looked at it.

    Portability could be solved through creative use of a directory-service. I know for sure that eDir can store SSL certificates just peachy, the trick is getting them out and integrated into a mail client by way of LDAP. Active Directory has similar capabilities, but even Microsoft hasn't implemented AD/SMIME integration.

    That said, directory integration provides its own problems. I, with my god like powers, can create and export private keys for generic users and through that securely impersonate them. This creates a non-repudiation problem, and is the reason that Microsoft's SecureAPI has a setting to require a password to be entered before using a certificate for signing. That password is currently set on the local machine, not in AD, which is how god-like-me can be foiled in my quest to forge emails.

    Still, email security remains the purview of those to whom it is important. Lawyers and security professionals are the groups I run into most often that use it. I know some hobbyists that use the technology between themselves, but that's all it is, a way to prove that they can make the technology work in the first place. It still isn't ready for "the masses".

    Labels: , ,


    Monday, September 03, 2007

    The RIAA and us

    Ars Technica had another article out lately about the RIAA and Universities. Ars posits that Universities are just like ISPs like Comcast, Qwest, or more locally CSS Communications. To a certain extent that is true, we hold very little central control over our users.

    However, there is one key difference between us and the likes of CSS. We're a closed-access ISP. In order to have an account with us, you have to be a user of specific status with WWU. The rules are long and complex and buried in Banner, but the short version is that in order to have an internet connection with us you have to be staff, student, or faculty. How does that impact the DMCS 'safe harbor' provisions? I don't know. I do know that K-20, our upstream provider, doesn't get RIAA take-down notices.

    What if WWU and/or ResTek went 'open access', in that anyone who forked over the $39.99/mo could get an internet account with us? Would that impact who got the 'pre-settlement letters'? Way back in the day, Universities were the only ISP's in a lot of areas so there is some history here.

    What if WWU separated the telecom/network function into a fully 'self supporting' entity, where WWU was the soul customer? Would the Telecom org get the take-down notices, or would WWU? Or would the "John Doe at 140.160.129.43 @ 11:43am, September 21st, 2009, you are going to get sued" letters still come?

    Hard to say. I don't think we'll become an open access ISP, as there are some security concerns there that need to be address. Right now our WLAN/LAN interface isn't quite robust enough for that sort of access from Joe Public. Also, our Telecom section is a 'self supporting' entity already, and they also field RIAA notices. ResTek has been an independent agency the whole time I've been here, and they do their own RIAA/MPAA notice handling.

    Labels:


    Wednesday, August 29, 2007

    When ads are ironic

    I was browsing my feeds at lunch, when I see this gem:
    Apropo ad
    That's right. On the Slashdot article about the extensive point-and-click wiretap network the FBI has built for wireless providers, is an ad for a wireless provider. I REALLY love the tag line, "Your world. Delivered."

    Should that be, "Your world. Delivered to the FBI."? Heee!

    Labels:


    Patent trolls

    I see that Polaris IP is suing several large companies over patent infringement. The patent? Email auto-responders. I wonder why Novell wasn't included in the suit since I was doing JUST THAT with GroupWise 4.1 in 1997.

    Oh wait. That's not infringement, that's prior art. My bad.

    Labels:


    Saturday, August 25, 2007

    Measuring sysadmin productivity

    There was another thread on Slashdot today that caught my attention:

    http://ask.slashdot.org/askslashdot/07/08/25/1753220.shtml

    The asker asked:
    RailGunSally writes "I am a (strictly technical) member of a large *nix systems admin team at a Fortune 150. Our new IT Management Overlord is a hardcore bean-counter from hell. We in the trenches have been tasked with providing 'metrics' on absolutely everything from system utilization to paper clip recycling. Of course, measuring productivity is right up there at the top of the list. We're stumped as to a definition of the basic unit of productivity for a *nix admin. There is a school of thought in our group that holds that if the PHBs are simple enough to want to operate purely from pie charts and spreadsheets, then we should just graph some output from /dev/random and have done with it. I personally love the idea, but I feel the need for due diligence, so I put the question to the Slashdot community: How does one reasonably quantify admin productivity?"
    I don't have a "bean-couter from hell" boss, but this is a topic I've spent a bit of time thinking about at my last job. How to you measure productivity of a sysadmin? The question at previous job was how do you determine which employee holds more value than another. This is not an easy thing.

    Productivity at its most abstract is the rate at which an employee adds value to an organization. The tricky part is determining how to measure that rate and the value itself. In manufacturing, it is easier as 'widgets-per-hour' is generally OK. IBM and Microsoft attempted to do this to programming back in the development phase for OS/2, and the infamous "KLOC", or, "thousand lines of code."

    System Administration is something that doesn't lend itself well to such quantification. A significant part of our job is quite literally, fire-watch; do nothing until something breaks and then spring into action to contain and correct the damage. While we're waiting for something to break, we're also working on projects to get new or upgraded systems online.

    What I have seen done is to have to account for every minute of my day. Every moment of my day has to be chargable against something; a project, a department, or other time-tracking tool. It is also my experience that such managers take a dim view of entries such as these:

    9:50-10:00 Bathroom
    11:45-12:00 Time-sheet entry
    15:45-16:00 Time-sheet entry

    The questioner asked, "what is the basic unit of productivity for an *nix admin?"

    I could come up with a funny name for this fictional unit, but in essence there isn't one. To fully quantify an admin's productivity requires fully quantified metrics for:
    • The impact of server and service downtime.
    • The value gained from meetings.
    • The seasonal variations in business (in our case, when are classes in session? When are finals? When do grades need to be reported? When are parents on campus? Things like that.)
    • Bureaucratic friction (how much 'process' is required to get things done?)
    I have yet to run into a business where the above are fully quantified. Through knowledge of the above you can determine the prodtivity of any single cog in the while mechanism. This is the best way to determine these things.

    Trying to reduce the complexity of the problem to certain 'proxy' metrics, metrics that are easy to track but also tend to mirror the much more complex metric, is the method of choice in these circumstances. Yet what proxy metric will do? Trouble-tickets resolved per week is one method, but it overlooks the differing complexity of some trouble-tickets (misplaced file versus install BlackBoard 9.4). Projects completed is another way, but as with trouble-tickets the complexity of some projects differs and projects can be canned from on-high without notice.

    It is for reasons like this that Unions really like seniority. It is a simple supposition:

    IF (timeAtCompany($NAME)) > (timeAtCompany($OTHERNAME)) THEN moreValuable($NAME)

    Plus, it is hard for managers to game. Time of service is easy!

    Yet every single tech-worker I've spoken with hates this system because we've all seen the flaw of it. If you've spent any amount of time at a company with more that 4 IT workers, there will be at least one of them that is not very good, just marking time until retirement, or is there for some reason besides to do a good job. These people have a tendency to have a lot of years of service, so are hard to get rid of. Just because you've been at a company in one general role is no guarantee of increased knowledge, skill, or value.

    Sysadmin productivity is not something that can be measured easy. It is similar to trying to measure the productivity of a department-level Project Manager. It can be done, but it is a very squishy measurement.

    Which just means we'll end up justifying every minute we're at work, and have the boss decide what productivity means through intuition.

    Labels: ,


    Thursday, July 12, 2007

    Mmm. Needed reviews.

    AnandTech is going to be reviewing power-supplies!

    This is nifty because:
    • Power supplies are HARD to test right. Much harder than measuring frame-rates in an FPS for vid-card performance.
    • Getting details about what the efficiency label on the side of the box really means is very good
    • Getting an idea as to what power-supply manufacturers build good supplies, and which are fly-by-nights with lots of bling is very good
    While it won't affect my job a whole lot (probably very little in fact), having these out there will be good all-around knowledge. Google was famous a few months ago for their push for higher efficiencies in server-class power-supplies. I don't think AnandTech will be testing server-class, OEM supplies but I may be surprised. And who knows, perhaps having this testing out there will spur a bit of good innovation in the industry as a whole.

    Labels: ,


    Thursday, June 28, 2007

    Back from vacation, part 2

    The downside to these vacations, especially ones with lots of other people, is the age old one Doctors know all to well.

    "Oh, you work in computers?"

    Those of you in the industry know the dread that phrase incurs. It means that you will shortly be asked a question about a computer problem, usually software. Or a strange error messages. Or a thingy that worked last week but just suddenly stopped. Any ideas? And in this age of laptops everywhere, even on vacation when there is zero WiFi coverage, the offending hardware can be whipped out for some on the spot troubleshooting.

    The real demon of it is that while I do work "in computers", 95% of the questions I get from friends and relatives are for the part of "in computers" I don't do. Specifically, desktop OS and application support. I used to be able to do that sort of thing, but at the time I worked on a helpdesk doing that every day. Not any more.

    What I do every day could be called "enterprise". One question I did field this weekend actually WAS near my area of speciality, someone wanted to know how to connect to a service hosted on a desktop machine behind their NAT router from the internet. For the rest, especially the Vista questions, I was singularly unhelpful.

    For the OSS advocates out there, one guy did ask me about linux. His son had set him up with linux on a desktop system he gave him. Very nice, shows advocacy. Unfortunately, printing mysteriously stopped last week and did I know how to get it back? Um.... no. He didn't know what distribution he was using, or even if it was KDE or Gnome. How do you explain THAT? As with all things linux there are three completely different ways to set printing up, and each distro seems to configure it, or skin the configuration, its own way. It is much much harder to troubleshoot these things from the remove of a user who doesn't know the interface trying to describe it. In this case I'm pretty sure it was Ubuntu, and I've never used that distro.

    So I'm considering revising my answer to the statement, "oh, you work in computers?" To, "no, I work in networks. Not the same thing." They'll still pitch their problems at me, but perhaps the expectation of getting a resolution will go down.

    Labels: , ,


    Tuesday, June 05, 2007

    Quiet lately

    The reason I haven't been posting much is that I haven't been up to much here at work. Most of my projects are waiting on other people to get done before I start. I found a really nifty tool that I want to try out a few times before I proclaim it to the heavens, so that's waiting on the right error condition before I do so.

    In other news, there was a Slashdot article yesterday along the lines of, "What RAID, JBOD, or Whatnot should I use for my home storage center?"

    There are two questions that drive my answer to this overall question:

    1) Is the capacity you are shooting for larger than a single drive?
    2) How important is write speed?

    If you're looking at 1TB of space, you can do that several ways:
    • Buy a 1TB drive
    • Buy 2 500GB drives and use RAID0 to span them
    • Buy 3 500GB drives and use RAID5 to span them
    • Buy 2 1TB drives and RAID1 them
    • Buy 4 320GB drives and use RAID5 to span them
    • Buy 4 500GB drives and use RAID0+1 to span them
    How important write-speed is to you will determine whether or not RAID5 is a good fit for you. As I've shown in previous benchmarks, even on enterprise SAN hardware the parity calculation limits how fast data can be committed to disk. I don't have benchmarks that compare, say Linux LUM RAID5 versus a hardware RAID5 controller to see which writes faster with a fast CPU so that will depend. In general, it is better to parallelize that where possible, which means a separate controller that performs the parity computation independent of the main CPU. For a media-center PC this means you can use your whole CPU to transcode that incoming raw video stream into MPEG4, without having to worry about CPU contention for writing to disk.

    That said, the PCI-Express SATA RAID controllers that I can find on NewEgg all use software Raid5 through the storage driver when they support it. If you go PCI-X, that changes and you have several options in the $200-$400 range that will do true hardware RAID5.

    Newegg puts a Seagate Barracuda 7200.10 500GB drive at $124, the 320GB of the same product line at $90, and the 1TB Hitachi Deskstar drive at $400.
    • ($400) Buy a 1TB drive
    • ($250) Buy 2 500GB drives and use RAID0 to span them
    • ($375+$250 = $625) Buy 3 500GB drives and use RAID5 to span them
    • ($800) Buy 2 1TB drives and RAID1 them
    • ($360+$250 = $610) Buy 4 320GB drives and use RAID5 to span them
    • ($500) Buy 4 500GB drives and use RAID0+1 to span them
    In the above case, it is actually cheaper to get 4 500GB drives and use software RAID0+1 than it is to purchase an additional RAID controller with RAID5 offload, at least for the 1TB size. The down side is you're installing 4 drives in your case and that may push the limit to what you can fit. This is probably why the hardware RAID controllers don't really exist in the PCI-Express market, which is predominantly a desktop bus not a server bus.

    Whether or not write performance is a big issue for you will tell you whether or not spending $375 for a software RAID5 makes sense over spending $250 for a non-redundant RAID0. How disastrous a hard-drive crash will be will tell you whether or not to spend the extra $250 for a redundant RAID0+1 setup.

    Labels: ,


    Tuesday, May 29, 2007

    Web site statistics

    We use Urchin 5.6 for our web site statistics. This works better for us than Google Analytics for a number of reasons, which is why it is somewhat irksome that a newer version of the Urchin software hasn't come out. I hear reports that Google, who bought Urchin a while back, is working on a new software based version of their statistics software but I haven't heard much.

    I hope it comes out.

    Google Analytics is unabashedly designed around advertising-related statistics. No surprise, since that's where the money is to be made. And for that, it works great.

    What it doesn't do is tell me a few, very key things:
    • How many total bytes did this web-server serve in this time period? Network monitoring will give me the whole server, but this will give me the specific web-server itself.
    • What are the top 10 hit files?
    • What are the top 10 files generating traffic?
    These are things I'm concerned about as a webmaster. This is stuff you can only get by parsing web-server logs.

    Of the top 10 hit files on student MyWeb, 6 of them would be revealed with Google Analytics.
    Of the top 10 files on student MyWeb generating traffic, which consists of 81% of total data transfer, not a single one would be revealed by Google Analytics.

    The top file last week for student MyWeb is an MP3 file generating 31% of total data transfer traffic. After digging into the actual log-files to see what is referring that traffic, I learned that there is a new flash-based music search service out there. While Analytics would track the loading of the flash file itself on those not-WWU servers, it won't track the transfer from my server. That Flash prog definitely doesn't execute custom Javascript.

    Google Analytics and server-log parsing programs serve different market segments. Google, understandably, is only interested in the ad-driven segment. I just wish they'd get off their butts and release a new version of the log-parsing Urchin software.

    Labels: , ,


    Thursday, May 17, 2007

    A peeve

    I've ranted previously about why I don't like Firefox. I use Seamonkey.

    I'm also using openSUSE 10.2 for my work desktop.

    OpenSUSE has compiled Seamonkey as a 64-bit package, rather than 32-bit. This made flash a rather dodgy thing until Adobe released v9 for Linux. Unfortunately, Adobe has yet to release a 64-bit version of flash so I'm stuck using NSPluginwrapper to get flash. And since flash is on about, oh, 80% of commercial web pages it gets loaded a lot.

    Something, somewhere causes nspluginwrapper to hang in such a way as to consume 100% CPU. I have a dual core, so this is livable. It also happens often enough that I've modified my seamonkey launcher to "nice" the seamonkey process to as low priority as I can get it. I don't know what causes it to spike like that, but cnn.com seems to trigger it, and YouTube vids are very likely to trigger it too. I've taken to using Firefox, 32-bit on 10.2, to view that sort of thing if I have to.

    Once adobe gets off their butts and released a 64-bit flash plugin for Linux I'll be a very happy camper.

    Labels: ,


    Thursday, May 10, 2007

    Editorial: patch Tuesday.

    From Slashdot:

    http://searchsecurity.techtarget.com/columnItem/0,294698,sid14_gci1254457,00.html
    http://it.slashdot.org/article.pl?sid=07/05/10/1652200

    In specific, an opinion that Microsoft should get rid of their regularly scheduled patch release and go to opportunistic patch releases. The argument stems from the damage the MS-DNS flaw has caused. Microsoft had a patch for it, why didn't they release it or some such.

    He closes with the statement:
    The value of the predictability of the monthly schedule simply doesn't outweigh the danger to customers posed by the flaws that go unpatched for three or four weeks between cycles.
    There is a problem with this. I bring to your attention a post on Bugtraq yesterday from iDefense about the Exchange 2000 IMAP vulnerability. I quote the key piece, which is in section 7:
    VIII. DISCLOSURE TIMELINE

    01/10/2007 Initial vendor notification
    01/22/2007 Initial vendor response
    05/08/2007 Coordinated public disclosure
    Note the times there. The disclosure was done to Microsoft in January, and it was in May before the fix was released. The time spent between 'initial vendor response' and 'coordinated public disclosure' was spent by Microsoft developing a fix, testing the fix, and integrating the fix into the patch release pipeline. This is part of 'responsible disclosure', which is telling the vendor about a problem, and not telling anyone else about it until the vendor has produced a patch.

    Some people quibble about how long it takes MS to come up with a patch after disclosure (responsible or otherwise), but that's not quite relevant to this particular discussion. Because it DOES take a while for the Microsoft patch pipeline to produce production-quality code, doing a staged release schedule like what they do right now makes all the sense in the world. They can do short-cycle patches, but even then it STILL takes weeks to produce a patch.

    I've been at this game long enough to have been around for the opportunistic patch schedule Microsoft followed before they started regulating when they released. And let me tell you, having a schedule for these things helps immensely. We know patches from MS come out on Tuesdays, so we've built into our schedule a 'change management' window Tuesday night expressly for that. This is pre-arranged with our users, we don't have to go to them to take their systems down so long as we do it Tuesday night. (As a side note, our NetWare servers also benefit from this time window).

    Under the old regime we'd get a hot patch from Microsoft on Wednesday morning. It is a patch that fixes a problem that is being actively exploited. I go to my management and explain the situation, and I'd have to convince them that the pain experienced by not patching exceeds the pain of downtime in order to get a patching window approved. Or I have to wait for the next change-management window to get the code in, which may be too late.

    One thing that is exceedingly clear these days is that when patches from MS are released, the black-hat community falls on them with glad cries to reverse engineer them. Once they have the underlying flaw, which may even be disclosed by the reporting party on release-day such as what happened with the Exchange iCal flaw this time around, Bad Stuff can be coded up to exploit vulnerable systems, a new Metasploit plugin developed, all that fun stuff. In short, waiting for a week or so after a patch is released is becoming more and more a vulnerability in and of itself.

    Microsoft's claim that doing it on a release schedule increases the patch uptake rate is a very valid one. Because so many of those patches require downtime to apply, patch application has to be built into the IT management environment. Microsoft is getting better about no-reboot patches, Windows 2003 is better than Windows NT ever was, but there is still a ways to go. Until it becomes possible to patch a live system with no downtime, a static release schedule IS the main way to go. An opportunistic schedule practically guarantees that major IT systems (I'm ignoring home systems for this, that's a very different management regime) won't get the patch for several days to weeks after release. The black-hats have been forcing us to ever shorter lags between patch-release and "too bad, you're hacked".

    Also, doing is opportunistically may very well mean MORE patches from Microsoft. This month's batch included 19 CVN numbers for 7 patches. Clearly, some patches bundle more than one fix. I approve of this, since it means less patches I have to apply, and the risk of multiple patches stepping on each other is reduced.

    Windows is a horrifically complex system. Microsoft has had a very long history with providing security patches, and they've had problems with:
    • Patch order
    • Service Packs removing in place patches
    • Patches applied simultaneously stepping on each other
    • Patches not applying the way they were intended
    • Feature or bug regressions
    • Patches causing problems in seemingly unrelated programs
    • Patches changing 'undocumented behavior' exploited by legitimate 3rd party applications (and sometimes, other Microsoft applications)
    So the extensive QA each patch candidate goes through has to be validated against all of the above list. That takes time. As I said at the beginning, if Microsoft is going to take that long to produce a patch in the first place, at least release the patches on a predictable schedule. It makes my life a lot easier.

    Side note: This morning I booted to the openSUSE partition on my home laptop for the first time in a while. Once it got done parsing the list of updates, I had something like 79 packages to update including a kernel update. Just the Security-flagged patches took 20 minutes to apply and that didn't include the reboot. In contrast, this month's Windows patches took under 5 minutes to apply. But then, I don't have MS Office on my Windows partition.

    Labels: ,


    Monday, April 16, 2007

    Recent events & disaster preparedness

    Recent events in Virginia sparked discussions today about if something like that happened to us. All that national attention is akin to getting www.wwu.edu slashdotted, especially any emergency page we may think to prepare. This is why even in this day and age old fashioned media is the best way to get a specific message to LOTS of people. The wwu front page as it exists RIGHT NOW would melt the web-server should something that nationally recognized occur.

    That said, given warning we could put together a server that can handle slashdotted loads. We know how. A static page works best, and we have enough web-servers scattered about that running the page through the BigIP to fork loads over 12 servers will allow us to keep up to loads. Heck, I still maintain that the MyWeb servers could handle those loads if given the go-ahead to run by itself.

    Running a server with a database of all the students, staff, campus visitors, and Bellingham residents who are confirmed to be Not Dead, the sort of information most in demand by those concerned about aforementioned people, is a lot more work and a lot more resource intensive. Anything database driven has orders of magnitude more resources required to support that level of load.

    This isn't something we've felt the need to prepare for, though. We do have an emergency page that can be hosted off site, somewhere, but it isn't designed for this type of disaster. It was designed with a Katrina-level (or more likely in our case, a &*!$ big earthquake in the area) disaster, where the school is closed and the whole region is suffering. Something like the previous paragraph could be hosted in town, even. Heck, even Mt. Baker popping wouldn't do us in because:
    1. We're up wind, so the ashfall wouldn't hit us.
    2. WWU is not in any of the historic lahar paths.
    3. Baker has no history of 'catastrophic flank collapse' eruptions (Mt. St. Helens in 1980).
    Who knows. These sorts of events are the type that change disaster planning nation-wide.

    Labels: , ,


    Wednesday, March 28, 2007

    The ".xxx" top-level domain returns

    I read a post on Arc Technica that the top-level domain ".xxx" is back under consideration. From the article:
    To find an explanation for resilience of the .xxx TLD proposal, one need only follow the money. The only organizations advocating the creation of the .xxx TLD at this point are the domain registrars, who would be able to generate considerable profits by selling .xxx domain names.
    Which is very true. They won't be reaping the big bucks by signing over the seamy side of the internet, they'll be making the big bucks from reputation protection buys from the likes of us. Higher Education domains like ours, WWU.EDU, are PRIME PICKINGS for .XXX. You can fully imagine that "WWU.XXX" will be full of ***Hot CoEd Action***, if we don't get it first. So you can further guarantee that our Telecom group will dilligently pick up "WWU.XXX" in order to maintain our reputation. So whoever is granted the authority to register ".XXX" domains will be getting our money, and most other .EDU domains as well.

    Back in the early years of the internet I heard of a proposal to have pornographers use "xxx" instead of the then-ubiquitous "www" at the start of URLs. It has the added advantage of not requiring regulatory approval, and is opt-in. It never went anywhere, but I thought it served the need better than a new top-level domain. Back then I didn't even consider the idea that "fbi.xxx" would be an attractive target for pornographers, heh.

    Labels:


    This page is powered by Blogger. Isn't yours?