Slashdot Mirror

"Imagine you tried having sysadmins work Agile ten years ago: you would have been seen as mental."

You don't know what you are talking about. Sysadmin has always been agile: it has always been about pipelining and automation. True: tools and mindset had a boom very recently among the masses (virtualization on x86 in the early 200x was key for this) but you can go to http://www.infrastructures.org... (back to 1994), or have a look at cfengine (back to 1993) to understand that agilism has been always the case.

Maybe your confusion comes from Windows *operators* that bastardized the term "system administration" so it looked like the kind of things they were doing back then (and even today, for the most part).

Sweet, I'm going to install Linux on all my systems. I didn't know that Linux could prevent natural and man made disasters as well as being a stable operating system. We've been wasting all this money on backup for all these years.

There's a mix of humor and catty vitriol here all around, but here is something that addresses the serious point made in Grandparent's statement about it being a "Windows" way of thinking.

Take a look at Infrastructures.org which describes a whole way of thinking about server reliability and configuration. Where I work we essentially use this approach. The fundamental concepts around this approach concentrate more on system configuration, ability to pick a random server and drop it out the window and have another one just like it online in moments. It's less about backups, and far more about a more comprehensive disaster recovery/prevention type of thing. The types of approaches described there are probably more easily implemented using Unix/Linux, but is probably also possible with Windows boxes.

http://www.infrastructures.org/

There's more, but it's a good start.

Is the open source solution close enough to the needs of the Ontario government that, as the article alleges, all you need to do is buy some servers and set it up and there are negligible other costs? I seriously doubt it. I would be willing to bet heavily against it. Anyone who thinks otherwise probably hasn't spent much time developing software for government.

I haven't, no...but what are said needs?

I'm assuming that the main component of a record system is going to be a database. You'll also need a usable system and interface for entering and retrieving said records into the DB. You're also going to want to do SQL dumps and periodic offsite backups, so that if anything goes wrong, you can get the data back.

Of course, it will also be very important to ensure that the operating system the database is hosted on, is as robust as possible, to minimise the possibility of crashes; as well as a strong filesystem for times when you need to make a lot of queries at once. Even though that system is meant for servers, you can still make it user friendly for your administrative staff as well, if you need to.

If you're going to want the records accessible from outside the hospital, you'll probably also want to make sure that they are protected by a couple of very secure firewalls, as well, since it could potentially mean the loss of someone's life if they get cracked.

Finally, they will need to make sure that whoever puts the network together does so according to sound administration principles, as well.

We do something similar with maintenance scripts (written in Perl) which generate configuration files (amongst other functions) based on the contents of a central management database (we're using PostgreSQL).

By default, we do client-pull. A cron-job fires periodically and re-runs all of the maintenance scripts configured for that time interval. (Some scripts run every 15 minutes, some only run overnight.)

In the event that a change needs to be pushed out rapidly, then we make the change the same way as before, then use a mass-trigger utility to trigger the scripts immediately by firing up parallel SSH connections to the subset of machines concerned.

You may also be interested in Bootstrapping an Infrastructure.

I use unique names for each host(star wars, lotr, greek myth, etc). Then I setup cnames for each function and point those at the host that serve them. For more info, check out: http://www.infrastructures.org/bootstrap/directory.shtml

> Desktop PC support is the lowest rung of the IT ladder. It's true. If you call the help desk, and the guy whose been there for years shows up, send him/her away. You only stay in desktop support if you don't have the skills to move up.

Not true.
Moving up requires both work skills, people skills, and opportunity to move up.

What if the work environment says "No, we're not promoting anyone, gotta keep costs down"?

What if the work environment says "We don't consider job B to be a promotion from job A; we hire job B people from outside the company".

What if you're skilled enough to handle higher level work, but so over qualified for the low level work that people think "Gee, if we hire this person, they'll just leave us for a better company, so we'll hire someone less qualified that will stay".

What if you have Asperger's, and react differently in social situations, such that at employment review times you are passed on promotion regardless of skill?

What if you feel that something like the http://infrastructures.org/ system for keeping systems under control is the right way to go, and management feels that the established system is superior, so you get canned for suggesting it?

Although I don't have direct experience with such things, the only thing I would offer is this site:-

http://www.infrastructures.org/

since it seems to describe setting up a very reliable open source-based network infrastructure in a lot of detail.
I also wish you luck with this. Although I have some knowledge which I had thought could help with such things, normally when I make suggestions here I get reprimanded for being impractical if I advocate doing anything other than going to a vendor and simply letting them take care of a given problem.

Our loaded cost for a Windows machine is cheaper than that for Linux. I'm a die hard linux evangelist, but the numbers don't lie.

Then go here and learn how to create your own system. You can also use such services as this and others in order to stay on top of security vulnerabilities. There is also this site which talks about designing network infrastructure.

You'll need to do some homework, and it might seem daunting at first, but the amount of money you could save surely makes this at least worth thinking about. I can't understand why this unique ability that FOSS gives you (to strike out completely on your own, independent of a vendor) isn't capitalised on by more organisations. There is absolutely no need to pay a Linux vendor a single cent if you don't want to...it is entirely a choice.

http://www.infrastructures.org/

Some of these essays are a bit dated especially with regards to the tools they are suggesting but the mindset is still quite sound.

In the meantime, you can get great technical insight about large scale IT management here

I can heartily recommend:

      Bootstrapping an Infrastructure.

It describes good design patterns for computer infrastructure design.

1) Immediately go here and read the whole thing. Then keep it near you throughout the entire process of developing your product. Although not as strictly necessary, reading this site definitely won't hurt you either.

2) Do not go near rpm.
3) Do not go near dpkg/apt.

I can safely say that there is no packaging system in existence for Linux which I anyway am completely happy with on all fronts. They all have egregious problems, and what is even worse, re-inventing the wheel tends to get virtual tomatoes thrown at you, because people think you're an idiot for trying to solve a problem that has already been solved...the only thing is, it hasn't been. The reasons for the above are similar for both package managers listed, but broadly speaking,

a) The use of subpackaging and package splitting can (and does) cause all manner of headaches.
b) Unsigned binary rpms/debs are horrible for security.
c) Although dpkg is worse, neither of these systems are particularly robust. I've had them go berserk and trash the entire host distro numerous times when I was trying to uninstall something and the program got the dependencies screwed up.
d) The spec/Makefile formats for both are hideous, and encourage false dependencies, and all manner of sloppiness and bad practice.
e) *Binary* packaging in general has been a practice adopted purely to satisfy the desires of Windows users, and was not originally a fundamental characteristic of Linux. This was because before people started trying to make Linux mainstream, they were aware that binary packaging was a really bad idea.

What I'm doing for my own system is an adaptation of ports, which isn't exactly the same as BSD's ports given that there are differences between the two operating systems...although I'm still intending it to be as portable as possible. For this reason I also do not recommend portage, because it is Gentoo specific.

4) If you default to runlevel 4 on bootup, (going straight into X Windows, with kdm or gdm) make sure the user is told somewhere how to switch to 3 so he can fix anything in xorg.conf that needs fixing. Yes, I know you're also going to want an automagic GUI element that sets such things up...but things at times can still go wrong.

5) Run an open beta, and give it to people with as many different hardware configurations as possible. You want to know about exotic/weird hardware that people are trying to use with it, so that you can find drivers for it and set up detection for it. The end user isn't going to be able to do that, and if you expect them to, they will simply throw your product away. (Unfortunately, they don't need to be able to do it; windows plug and play hardware detection is taken for granted by users of that system, to a large degree)

6) Figure out very early on what your revenue model is going to be, and realise that because you're using a GPLed system, whatever you're going to make money on, it isn't going to be IP. Either make money on support, or open source all of your unique elements (I'm going to be using the BSD license for anything I write myself which doesn't use GPLed code, and recommend that you do the same, for both widest possible circulation and PR points) and then sell integration of said individual elements as a service and convenience.

7) Focus on people who are entirely new to Linux as a target audience for your product, rather than the established userbase. The reason why is because if you try to sell to the existing userbase, you will attract the inevitable screeching, basement-dwelling, autistic FSF/GNU fanatics who if you try and make any money on the product at all, will endlessly whine that you're not doing enough to "give back to the community", (read: cult) irrespective of how much effort you actually do make on this score by open sourcing all of your product's unique elements. They will also complain if you use Gnome as a UI instead of KDE, if you us

Agree, looks like this package folows methodology described at http://www.infrastructures.org/bootstrap/pushpull. shtml. But collectd.org plugins has less features then net-snmpd + OpenNMS...

I have read through some of the material at http://www.infrastructures.org/. I think that to a considerable extent, this is what our IT management group has already in place. Of the second bullet point list on the home page, I think they have about 80%.

It definitely has its strong points, but in practice, it is less ideal than it seems. Perhaps it makes life easier for the IT department, at least in theory it should, but it often fails to do this for the users.

I can see several reasons for this mismatch between theory and practice.

A first one, which is quite possible to overcome if there is enough management support, is that a much higher investment in infrastructure would be necessary to realize the potential of this ideal also for the users. We would need higher-end PCs, much more spacious file servers, and far better performing networks than we have now. It is hard the quantify the burden imposed by a centralized approach, but in my experience it is quite high, and you would need to take at least one step up in all hardware to compensate for it.

But IMHO the biggest problem is more fundamental. As a management philosophy, it assumes that all systems are more or less equivalent, have the similar configurations and the same tasks. This is quite possible to achieve if we think of IT systems as a separate world, not interacting with other systems; so that they can grow unconstrained to their ideal configuration. IT systems that are growing in some gentle Garden of Eden.

But in many real-world environments the IT patch is a sloping, rocky, irregular piece of ground. The IT systems there are interacting with external systems and parties, and constrained by this interaction. They have to adapt to the requirements of the process, which are often enough imposed from outside IT or even from outside the company. It usually is inevitable that there will be a mix of different hardware configurations, operating systems, software packages; systems that are often dedicated to a special purpose with a lack of alternative solutions. Even the personal computing needs of two users sharing the same office may be too different to be met by similar systems.

To function adequately, the IT management systems need to be much more flexible than ours are now. And they also need to be flexible to grow. The remote management systems of our IT department are powerful; but they still cannot cope with Windows XP.

Sounds very reasonable, but doesn't work very well in practice, if only because IT usually doesn't show much interest in other people's requirements -- certainly our team has never asked for them.

Did _anyone_ bother to talk to IT about this? Or is your IT department so busy fighting fires that they don't have the time? How often has IT been given the option of actually participating in the decision making process?

If the IT department has to work properly, they need support. Right now, end users are generally capable of screwing up their systems, and IT has to take the shit. Responsibility without power.

IT would still be busy setting standards without being directly involved in, or even understanding, the business. Only they would no longer do any real work.

Actually, to set the standards, they would have to understand the business. Standards setting is _not_ a pure IT function, it is a managerial function.

What we need to do is dismember IT as a department, leaving only the most essential tasks there, and integrate the IT people with the other teams.

Who decides what an essential task is? One of the primary responsibilities of IT as I see it is to keep the entire network running. Yes, this might suck for the individual. But the benefit to the many outweighs the cost to the few. If that isn't good enough for you to be able to work, you need to talk to your management about this.

You come up with the requirements, IT comes up with the budgeting. Then your management decides if you can or cannot afford it.

Keep in mind that people intensive tasks don't scale. Automation does. Some of us are working out a formal theory of system administration. A good place to start would be the infrastructure management website at http://www.infrastructures.org/. Familiarise yourself with this, then sell the idea to your IT staff _and_ management.

http://www.infrastructures.org/

Pretty good stuff there.

Think about how the hell you're going to manage large numbers of desktops in a scalable manner.

Things to consider: Installing new apps, installing patches, managing users and home/shared directories. Managing printers, etc.

Sure, there are some slick tools such as apt and yum. But that's only part of the picture.

Check out Infrastructures.org to start down the path of enlightenment, Ed Gruberman. Or feel the wrath of a boot to the head.

He doesn't need "Linux from scratch" to set up one fucking server and some workstations. He's not a distro producer, he's an admin.

No, he might not be a distro producer, but a couple of points:
a) His life is likely to be a LOT easier as an admin if he has an intimate knowledge of the system he's using...where everything is, how it's set up, and so on. LFS will give someone that.

b) Having at least some kind of knowledge of shell scripting is not only a prerequisite for LFS, but also definitely for being a sysadmin, last I heard. Again, he can pick that up in preparation for building LFS.

c) If it is for only a single server machine we're talking about, then I'll grant you he might well be able to get by with SuSE etc...but the whole point of me advocating him learning what I did is because that knowledge in conjunction with say, what's on infrastructures.org will enable him to set up and handle a LAN on any size, whether we're talking one machine or a hundred. Granted, his current job doesn't require him to deploy a hundred machines...but for all we know, his next very well could.

Saying that RPM means Red Hat or SUSE or Mandrake are unusable is just fucking stupid.

I didn't say that they were unusable for an end user. Not all of them are unusable for development, either...I built my last LFS on Mandrake 10, simply because I'm on dialup where I am and am unfortunate enough not to live near Linux vendors, and Mandrake 10 Community was available on a magazine cover. A number of RPM-based systems have shown major problems for not only building LFS, but also often for building tarballs in general in my experience. If you know that the system you're on is sane because you've spent time looking at it, fine. What I primarily meant was though that all other things being equal, in my experience RPM-based systems genuinely do have a lot more problems for development use than non-RPM based do.

My point on replicating his Windows system was not to make Linux look like Windows, but to enable the office to continue doing what they're currently doing on Windows but in the Linux manner. Stop knee-jerking and understand that.

That's why I advocated that he initially only use Linux server side, and leave Windows on the desktop completely. Chances are that his users will want to use Office anyway.

Most organizations use these three main Linux distros as servers for a reason.

Organisations use Red Hat or Mandrake for the same reason that they used Microsoft before them; purely because all three companies are able to offer support contracts. Ass-covering and handholding are the most important things as far as the majority of organisations are concerned; actual technical quality generally has nothing to do with it. If quality had anything to do with what organisations use, Microsoft wouldn't have made anywhere near the amount of money they have.

Give...it...up. You just sound like a fool or a fanatic. You're an example of why people coming from Windows can't stand Linux people. You give Linux users a bad name.

No...In my observation anyway, the main reason why Windows migrants (or anyone else for that matter) can have issues with Linux users is RMS/the GNU crowd, which (despite what you might be thinking, given my tone in these two posts) I am most assuredly NOT a member of. I think it's a very safe bet that (as one example) pretty much every single one of the death threats or other forms of intimidation Laura Didio received a bit back came from people on the GNU side of the ideological/factional divide. RMS has the attitude that anybody using Linux is somehow therefore on his turf by default, and therefore compelled to adhere to whatever he decrees. His army of zombies (many of which I've seen on Slashdot) also try and enforce this. Considering that the main thing that a Windows migrant might be trying to get away from is feeling that they

Check out http://infrastructures.org/

You must have a distribution system for all of the existing applications you have on your machines. Just use that. Open Office and Firefox are no different from any other app.

Linux systems are simple. http://www.infrastructures.org/

http://www.infrastructures.org says it so much better :).

Enjoy.

Perhaps you need isconf? http://www.infrastructures.org

http://www.infrastructures.org

This is why the system won't collapse, and how to do the idea correctly.

One resource you should check out and possibly incorporate is the Infrastructures.Org practices for reproducable configuration management.

Infrastructures.org. Learn it, love it, be happy. It is an overall theory of administration pointing to the idea of keeping all software and configuration information for the entirety of your system in a central place and allowing changes to "emmanate" outward as necessary.

-Shane

If anything, the article's emphasis is on desktop support and the end-user experience.

Any seasoned sysadmin will have war stories to share regarding how servers drift out of sync (just the o/s, ignore anything else for now) over time, not just from a baseline, but from other servers which are meant to be identical. Read Steve Traugott's white paper on Turing Equivalence in Automated Systems Administration if you want to get a better feel for the issue.

If anything, the article's emphasis is on desktop support and the end-user experience.

Any seasoned sysadmin will have war stories to share regarding how servers drift out of sync (just the o/s, ignore anything else for now) over time, not just from a baseline, but from other servers which are meant to be identical. Read Steve Traugott's white paper on Turing Equivalence in Automated Systems Administration if you want to get a better feel for the issue.

Me too. Looks like people are finally taking cues from places like infrastructures.org.

Try this URL

This is how to design a scalable solution with Linux. And the code to do it.

Enjoy.

Debian. Cron apt updates installed packages on the schedule you specify. apt-proxy sits between you and the net and keeps a local mirror of the packages requested, so 100 requests = 1 outside request. Plus you can add your own custom packages to it so that your machines are configured properly. Upgrades? Well by hand it's apt-get -y dist-upgrade. The stable branch is just that, and the testing branch is really production ready for most definitions of production.

Seconded, with reservations. We have recently transitioned from a jumbled mess of Windows, Macs, Suns, Redhat to something more manageable; that includes Debian Woody PCs, installed by FAI. No apt-proxy but we already maintain a local mirror.

The process is not complete. We are just beginning to deploy cron-apt. And apart from the difficulty of making some "historical" sysadmins to think in terms of an infrastructure instead of installing machines every which way; and the fact that we can't transition all software away from Windows (CAD tools, electromagnetic simulators...) or rip Office and Macs away from the addicts (no, even MacOSX isn't ready for integration into an infrastructure IMHO); there are still technical gripes:

• Unattended package install and upgrades: it took us a while to silence some undisciplined packages which insist on being installed and asking questions such as "Change anything? [Y/n]" (lilo comes to mind); and a few days ago there was a security update of X, Debconf decided to take charge of /etc/X11/XF86Config-4 and broke it. We'll probably come to desynchronize our mirror and test all updates, that's a lot of work.
• Keeping systems up-to-date, not only for security but also which packages are installed, configuration files, and so on. Machines installed at different times tend to diverge quickly, as we adjust FAI configuration. The solution we are currently considering is to develop a special package with ad hoc dependencies and post-install scripts. Again, all this doesn't just happen by magic.
• Debian-stable is indeed stable, but is aging rapidly. Not only graphics card support is problematic (we had to make a xserver-xfree86-4.3 package and install it alongside the rest of XFree-4.1), but users (and I) want KDE-3, teTeX-2, Mozilla-1.4... Sure, we can recompile packages from testing or sid (I did that a lot before Woody's release), but then dependencies kick in; and if you're not going to enjoy Debian's polished packaging, you might as well use FreeBSD or even RedHat.
• Finally, you can't beat Solaris for serving NFS, which means we have to keep a Sun Enterprise server to store the users' home directories etc., and handle Samba and e-mail: at least the latter must run on the same machine which serves $HOME (think .forward, .procmailrc and so on; NFS just isn't reliable enough).

All in all, I'd recommend such a move, with Debian indeed, but it definitely isn't as easy as you make it sound...

Because most people can do some of these things, they can end up doing sysadmin work. Does that make someone a sysadmin? I have interviewed for sysadmin roles before and always been amazed at the people who have used an application, or watched and install, and then applied for the sysadmin job. It's not enough.

The problem is, lots of people doing this kind of work without the training and experience (and often, no mentor either - nontechnical boss) give the profession a bad name - hence the whole BOFH subculture.

This link describes some of the issues related to this job that isn't very mature at all ...

(Marc Andreesen)
I'm an egotistical, talentless hack who's latest
stupid idea, loudcloud, failed, so I sold off half
of the company to a bunch of Unsuspecting, good old boy rubes, since my status as "Internet Goldenboy" is in question.
(/Marc Andreesen)

I used to work for a rather lame start-up, which was run by a member of the aohell/nutscrape
cronie network of good old boys (that racist, ignorant, sexual harassing homophobic prick, The only person I know of to have a wired article about how much of a jerk he is. Opsware was
crap. It was slow, buggy, and caused us downtime
that wasn't really downtime according to loudcloud's incredible staff of marketing and law
employees. We were a startup with low funding, yet we spent $800k a month for service from them that we could have built ourselves at exodus or equinix for $200k a month.

If anybody wants information on a REAL movement
in automated systems administration, go to Infrastructures.org A movement based on Steve Traugott's Usenix presentation Bootstrapping the infrastructure.

(Marc Andreesen)
I'm an egotistical, talentless hack who's latest
stupid idea, loudcloud, failed, so I sold off half
of the company to a bunch of Unsuspecting, good old boy rubes, since my status as "Internet Goldenboy" is in question.
(/Marc Andreesen)

I used to work for a rather lame start-up, which was run by a member of the aohell/nutscrape
cronie network of good old boys (that racist, ignorant, sexual harassing homophobic prick, The only person I know of to have a wired article about how much of a jerk he is. Opsware was
crap. It was slow, buggy, and caused us downtime
that wasn't really downtime according to loudcloud's incredible staff of marketing and law
employees. We were a startup with low funding, yet we spent $800k a month for service from them that we could have built ourselves at exodus or equinix for $200k a month.

If anybody wants information on a REAL movement
in automated systems administration, go to Infrastructures.org A movement based on Steve Traugott's Usenix presentation Bootstrapping the infrastructure.

I recommend the paper, "Bootstrapping an infrastructure."

I recommend the paper, "Bootstrapping an infrastructure."

If you're a sysadmin who's convinced "there's got to be a better way", check out www.infrastructures.org

Our biggest issues were with printing - LPR just plain sucks. At the time, CUPS was still very new, so we used LPRng. I ended up writing a GUI front end for printer management (since printtool didn't work well, and editing printcap files by hand was unacceptable). The final "problem" was quotas - the NT admins were used to setting directory level quotas, while Linux/Unix uses partition level quotas. Simply put, we had to split /home and /shared while they were used to having just one partition. Quota management under Linux just isn't the same as NT (for better or worse), and you need to remember things like "if a user & group quota affect a directory, the MOST restrictive effects the user" (which is why you need to make two partitions).

With newer kernels, this is a more reasonable project. Linux really is "enterprise-ready" now (I hate that term). Previously, things like a journaled filesystem were missing, which was a big gripe with the NT guys (when a system goes down, it takes a long time to scan 100 GB of data!). Also, newer kernels support more than 32000 users and groups (usefulness depends on your company size).

Finally, make sure you consider backup systems, how the systems would be administered, etc. It's a big project, but manageable if your company is really interested.

If you need some fodder for the fight to help convince management that this will save a LOT of money, check out this business case. You might also be interested in this deployment plan. Infrastructures.org also has a number of useful (must read) documents. Finally, you may want some help designing the architecture, and making sure you've found any issues. Find someone who has done this before (shameless plug: US Linux Networks) and have them at least work through some fo the major points to make sure you've got everything covered - the cost for a few days of requirements, architecture, and design may save you a lot of wasted effort.

If your only worry is a single machine, IMO there is no fundamental difference with a home system, except that it has to be (even more) solid (think redundant power supply, UPS, RAID, backups...), scalable (think RAM, SCSI disks), and you have to pay (even more) attention to potential local root holes. And use a system that works, no fancy using the latest 2.5.1pre6 Linux kernel or 5.x-CURRENT BSD!

Think about how it will be accessed and don't cut corners on security (use SSL for POP/IMAP if possible, favor SSH/SCP/SFTP over telnet/ftp, use encrypted passwords for SAMBA). You may want to set up restrictions on local users - quotas, limits on CPU/RAM usage, etc. You will want to automate account creations: define different classes of users, standard configurations, but also groups, mailing lists - manual maintenance of those can be a major PITA.

OTOH, if you're also responsible for all the clients, then there's a must read: Bootstrapping an architecture. Resist any and all temptation, from yourself or others, akin to "100 users is not enough to bother with automating everything, we'll just handle it by hand", etc. I've been through this myself and regret all the time lost installing, reinstalling systems, spending hours opening batches of accounts, cleaning up old ones, and so on... Computers are good at repetitive tasks, and this one can and should be automated. Of course, keep solidity in mind; you don't want all your network to halt because your upgrade server is stopped for maintenance...

Finally, if you aren't starting from scratch, if you've just been "promoted" sysadmin for 100 users with an existing network, then good luck. Your best bet is to maintain the old infrastructure, set a new one in parallel, and migrate users and machines one by one. But make sure to interview many users and upset as little old habits as possible, otherwise I hope your asbestos suit is ready!

It's only hard if you don't know how to prepare the setup required to maintain $1 millon in PC hosts:

http://www.infrastructures.org

Computers are amazingly good at automatic repetetive logical tasks. 99% of all systems administration involves repetitive logical tasks. The trick is to make the machines do all the work of maintaining themselves that they can programmatically handle.

So if you're a clueless "paper" sysadmin, yep, it's impossible -- can't be done.

Still, I'd rather have the z-machine mainframe!

1) LinuxPPC
2) Debian, or
3) RedHat.

Of the two x86 distros, the feeling was that RedHat was for ordinary joes who wouldn't ask much from the system, and Debian was/is for people who want to make the system do backflips. Of course LinuxPPC had its own crowd.

No skin off my back though -- it would be amazing if someone working on Debian didn't already run it on a Netfinity 7000 or similar. They're great machines, the kind you'd expect a Debian maintainer to be working with ;-). Heheh...

(still waiting for my copy of Solaris 7 to show up so as to run Coda on Debian, Solaris, NT, and FreeBSD boxes)

That makes me wonder -- how is IBM going to respond to Coda, seeing as to how when Coda matures it will be a Better DFS?!? That may be the really interesting question... several of the Coda clients have BSD-style licenses.

An interesting paper comparing NFS, AFS, DFS, and Coda:
Bootstrapping an Infrastructure