The only potential difficulty, IMO, is getting past the the whole "partitions vs. slices" thing. The BSD and Linux versions of those ideas are dangerously similar - close enough to make a clueful Linux user think they understand then, but different enough to hose that user's system. Even then, there's nothing particularly difficult there as long as you wipe your mind of what you think you know before beginning.
Once you get past partitioning/slicing, there's really nothing to the rest of the install.
Ebay's definitely the way to go. Good tape drives, being corporate-targeted fare, are built to last. And there are plenty of servers that came with a tape drive as a standard component that probably never saw more than a couple of dozen backups in their lifetime. That means a cheap, long-lasting tape drive for you.
To give you an idea, I got a Sony DDS4 (20G/40G tapes) about a year and a half ago for ~$275, IIRC. By looking at it, it was barely used, though eyeballs are admittedly pretty weak instruments here. In any event, it's been running weekly backups with no problems at all - no write errors, doesn't chew up tapes, test restores always work. Good enough deal for me...
Wouldn't be much of a problem with a halfway decent amount of RAM. A lot of perceived slowness is in load time, which is helped out by more file cache space. And shared libraries contribute some efficiency as well. Projects like Linux Terminal Server handle scores of simultaneous users with ~2GB of RAM. I'd think that, even in a low-cost market, this kind of machine would have enough RAM to handle 4 users.
Loosen up that tinfoil hat, man. This is a pretty natural project for Intel to invest in. Improved User Mode Linux leads naturally to more shared servers, as others have detailed. And, in the interest of efficiency, those shared server operators will be interested in nice, juicy processors to allow more virtual servers on the same piece of physical hardware.
Sounds like a simple business investment to me - no need to search for conspiracies here.
Except that patents were created to protect inventions, and there's a good bit of difference between an idea and an invention. Specifically, an "invention" implies some novel kind of implementation, and it's not clear in this case that there's anything to the implementation beyond simply using networking tools and protocols already available.
At least, that appears to be the issue here. I don't know enough about the technology here to say whether the implementation was actually novel or not. But the distinction is worth making regardless...
I agree. Contribute isn't going to give you the whole PHP-shebang of blogs, forums, private messages, newsfeeds, and coffee-makers. But for making basic web pages, it's dead simple. You can set up templates for them to use as well - photo album pages for specific topics would be sensible.
Until about a year ago my huge school system, which I will decline to name, had its most critical data running over an ancient serial terminal setup. Way before my time (working with computers, at least)... but I'd guess late '70's vintage. The 20 or so terminals (= monitor + keyboard) in the building all wired directly into a funky box in the main office, which then had some kind of connection downtown. I forget the name on the units, unfortunately. Pretty scary, though - if that box in the office had gone down, finding a replacement probably would've been a nightmare. I'd like to think that some thoughtful person downtown had a stockpile of replacements, but somehow I suspect that's wishful thinking.
I don't think we're disagreeing. What you're describing are the mechanics of the Windows client locating and authenticating against an AD controller. Yes, very challenging. Which is why I said "Once they have AD controller support..." at the beginning. That's a big, hairy issue that brings in LDAP as well.
I was only stating, perhaps incorrectly, that the OP's desire for a cross-platform directory service is not much of an extension provided that you have Samba mimicking an AD controller effectively. If you do, there's no reason you could not have that psuedo-AD controller pull its information from an OpenLDAP/Kerberos combo that provides authentication and account info for *nix clients as well.
Correct? Or not? You clearly understand the details better than I do...
pGina does essentially what you describe. It replace GINA and allows MS boxes to authenticate directly against an LDAPv3 server. But people who understand this stuff much better than myself tell me that this is not really a great solution. GINA is a fairly superficial authentication component, and replacing it doesn't make some of the more subtle bits fit together. Modifying the LSA (Local Security Authority) would be necessary to do the job properly. But, not surprisingly, documentation for it is not forthcoming.
"What I would hope to also see in the near future is support for creating a (Linux) directory heirachy based network using samba that will allow both MS and non MS clients."
Once they have AD controller support, that part is easy - and also not exactly Samba's job. Just create appropriate schemas for your LDAP server and have a Samba AD controller authenticate client requests via LDAP. What's not there yet is the ability to handle MS Kerberos properly - creating the Kerberos tokens in the proper format and passing them off to the client is more of a barrier than any LDAP protocol issue.
...besides the features is some absolutely outstanding documentation. The old 2.x docs were basically a really long HOWTO. The new docs are broken into self-contained chapters that start by laying out how a certain task or protocol work in general, and then how to configure Samba to take part in it. Considering that Samba can perform so many different roles, the mix-and-match method is a lot more sensible. Even if you don't use Samba, consider their docs as a reference for troubleshooting Windows problems - I've found they offer a far more complete and focussed discussion of Windows technologies for the sysadmin than any MS book or webpage.
I teach in one of the largest public school districts in the states, and in my experience this article is both irrelevant and incorrect.
First off, as others have pointed out, the price difference is far from inconsequential. Even under a Preferred Purchasing agreement for Wintel that, IMO, is a slimy ripoff, we would still pay $200+ more for a low end Mac.
Second, Macs are used in precisely the places the article points out as strengths - video editing and multimedia. While my district in general and my school in particular are pretty crude technologically, we do have two small labs of Macs for Graphic Design and Publishing courses.
As for losing other opportunities in the building, Apple's got no one to blame for themselves. As behind as I think we are, we've still got attendance and other functions running on an NT domain. Why? Not because we're close-minded and bought-out (well, maybe we are, but not in this context). But because Apple all but abandoned the educational market years ago. We had the NT domain long before we moved critical functions to it. If Apple had halfway reasonable pricing and a larger educational program four years ago, running those functions on NT might not have been as simple a choice. The argument that "we've got to teach MS because that's what's out there" is powerful, though not as much so as some Slashdotters may suspect. But combine that with a preexisting NT network assembled during years of Apple's educational neglect, and it makes buying Macs for the classroom foolish.
Slashdot Mirror
The only potential difficulty, IMO, is getting past the the whole "partitions vs. slices" thing. The BSD and Linux versions of those ideas are dangerously similar - close enough to make a clueful Linux user think they understand then, but different enough to hose that user's system. Even then, there's nothing particularly difficult there as long as you wipe your mind of what you think you know before beginning.
Once you get past partitioning/slicing, there's really nothing to the rest of the install.
Ebay's definitely the way to go. Good tape drives, being corporate-targeted fare, are built to last. And there are plenty of servers that came with a tape drive as a standard component that probably never saw more than a couple of dozen backups in their lifetime. That means a cheap, long-lasting tape drive for you.
To give you an idea, I got a Sony DDS4 (20G/40G tapes) about a year and a half ago for ~$275, IIRC. By looking at it, it was barely used, though eyeballs are admittedly pretty weak instruments here. In any event, it's been running weekly backups with no problems at all - no write errors, doesn't chew up tapes, test restores always work. Good enough deal for me...
Wouldn't be much of a problem with a halfway decent amount of RAM. A lot of perceived slowness is in load time, which is helped out by more file cache space. And shared libraries contribute some efficiency as well. Projects like Linux Terminal Server handle scores of simultaneous users with ~2GB of RAM. I'd think that, even in a low-cost market, this kind of machine would have enough RAM to handle 4 users.
Loosen up that tinfoil hat, man. This is a pretty natural project for Intel to invest in. Improved User Mode Linux leads naturally to more shared servers, as others have detailed. And, in the interest of efficiency, those shared server operators will be interested in nice, juicy processors to allow more virtual servers on the same piece of physical hardware.
Sounds like a simple business investment to me - no need to search for conspiracies here.
Mods - if you're going to mod something up as informative, isn't a cursory check of accuracy a good idea?
At least, that appears to be the issue here. I don't know enough about the technology here to say whether the implementation was actually novel or not. But the distinction is worth making regardless...
Here's a page by an educational consultant (a rare, useful one). There are references at the bottom.
I agree. Contribute isn't going to give you the whole PHP-shebang of blogs, forums, private messages, newsfeeds, and coffee-makers. But for making basic web pages, it's dead simple. You can set up templates for them to use as well - photo album pages for specific topics would be sensible.
Very, very easy.
Until about a year ago my huge school system, which I will decline to name, had its most critical data running over an ancient serial terminal setup. Way before my time (working with computers, at least)... but I'd guess late '70's vintage. The 20 or so terminals (= monitor + keyboard) in the building all wired directly into a funky box in the main office, which then had some kind of connection downtown. I forget the name on the units, unfortunately. Pretty scary, though - if that box in the office had gone down, finding a replacement probably would've been a nightmare. I'd like to think that some thoughtful person downtown had a stockpile of replacements, but somehow I suspect that's wishful thinking.
Actually, with a new version of Cyrus IMAP, you can have proper virtual domains with Sendmail - no virtusertable, no user accounts.
I was only stating, perhaps incorrectly, that the OP's desire for a cross-platform directory service is not much of an extension provided that you have Samba mimicking an AD controller effectively. If you do, there's no reason you could not have that psuedo-AD controller pull its information from an OpenLDAP/Kerberos combo that provides authentication and account info for *nix clients as well.
Correct? Or not? You clearly understand the details better than I do...
pGina does essentially what you describe. It replace GINA and allows MS boxes to authenticate directly against an LDAPv3 server. But people who understand this stuff much better than myself tell me that this is not really a great solution. GINA is a fairly superficial authentication component, and replacing it doesn't make some of the more subtle bits fit together. Modifying the LSA (Local Security Authority) would be necessary to do the job properly. But, not surprisingly, documentation for it is not forthcoming.
"What I would hope to also see in the near future is support for creating a (Linux) directory heirachy based network using samba that will allow both MS and non MS clients."
Once they have AD controller support, that part is easy - and also not exactly Samba's job. Just create appropriate schemas for your LDAP server and have a Samba AD controller authenticate client requests via LDAP. What's not there yet is the ability to handle MS Kerberos properly - creating the Kerberos tokens in the proper format and passing them off to the client is more of a barrier than any LDAP protocol issue.
...besides the features is some absolutely outstanding documentation. The old 2.x docs were basically a really long HOWTO. The new docs are broken into self-contained chapters that start by laying out how a certain task or protocol work in general, and then how to configure Samba to take part in it. Considering that Samba can perform so many different roles, the mix-and-match method is a lot more sensible. Even if you don't use Samba, consider their docs as a reference for troubleshooting Windows problems - I've found they offer a far more complete and focussed discussion of Windows technologies for the sysadmin than any MS book or webpage.
Great job, Samba team!
I teach in one of the largest public school districts in the states, and in my experience this article is both irrelevant and incorrect.
First off, as others have pointed out, the price difference is far from inconsequential. Even under a Preferred Purchasing agreement for Wintel that, IMO, is a slimy ripoff, we would still pay $200+ more for a low end Mac.
Second, Macs are used in precisely the places the article points out as strengths - video editing and multimedia. While my district in general and my school in particular are pretty crude technologically, we do have two small labs of Macs for Graphic Design and Publishing courses.
As for losing other opportunities in the building, Apple's got no one to blame for themselves. As behind as I think we are, we've still got attendance and other functions running on an NT domain. Why? Not because we're close-minded and bought-out (well, maybe we are, but not in this context). But because Apple all but abandoned the educational market years ago. We had the NT domain long before we moved critical functions to it. If Apple had halfway reasonable pricing and a larger educational program four years ago, running those functions on NT might not have been as simple a choice. The argument that "we've got to teach MS because that's what's out there" is powerful, though not as much so as some Slashdotters may suspect. But combine that with a preexisting NT network assembled during years of Apple's educational neglect, and it makes buying Macs for the classroom foolish.