No, non-AD Krb5 servers can be used for authentication of users on Win2k / XP boxes just fine. Just won't be able to emit the AD-specific user *authorization* data -- essentially the network-group/role memberships ala the NTLM doman-wide group membership info.
You can sortof work around that using machine-local groups.
Check out this paper from M$FT [microsoft.com) for more info. This was helpful in getting my old uni's Windows XP realm to defer to the exising MIT K5 for authentication (go UNCC Mosaic!)
> Just look what happened (is happening) to Kerberos.
I'd say that Microsoft's 'extension' to Kerberos is ultimately perfectly fine and valid, just unfortunate that they did not make it completely valid to reimplement. They used a field in the ticket exactly how it was meant to be used -- for vendor-specific authorization data. Remember, Krb5 was designed to be an authentication protocol, and you can use either AD for authentication of plain-*NIX-boxen just fine or can use, say, MIT or Heimdal K5 for authentication of users on Win2K / XP client boxes w/o too much (relative) trouble.
AD's implementation of Krb5 genuinely strives to be per-spec, and the spec defines the authorization field to be used as the vendor sees fit.
Can someone explain why I would choose XML-RPC or SOAP for an xplat / xlang distributed app as opposed to CORBA?
Is the main purpose for using HTTP as the transport just a way to make it traverse firewalls and/or to traverse proxy servers?
AFS makes great sense for Web server farms and/or
mirrors of the same site across a WAN such as
the Internet (think an east coast site and a
west coast site). Just edit the file and pow, a
server -> client callback notifies any clients
caching the file that they need to refetch.
Couple this with having the content in a read-only replicated volume, then go ahead and update many files, get your new site look-and-feel
redone, then once your happy with it, release
the read/write volume for replication, and pow --
one atomic transaction to all of the mirroring
servers on the WAN!
Mabye this is why AFS is a major component
of IBM's Websphere platform.
All of this, currently working like a champ, and
it'll be free and open source!
AFS is a very stable, tested, enterprise filesystem. It offers the following features:
Cross platform: Many UNIXen as well as NT as either client or server.
Secure: Uses Kerberos IV for user authentication.
Client-side caching: client machines use disk or virtual memory to cache MRU files, greatly reducing # trips down the wire on reads.
Unified naming scheme: names of files don't indicate what file server they're on. Makes moving of volumes from one fileserver (or drive on the same fileserver) to another a cinch, since no client-side changes need to happen.
Read-only replication: Make your application install directories replicated in each building on campus.
Now, it's not a perfect product, but it is
way cooler than vanilla NFSv2 or NFSv3,
especially on the server-side management side
of things. It doesn't do disconnected operation
(which CODA strives to do), byte-range locking,
strict UNIX file semantics (data most recently
written == data viewiable by all file handles
to that file), or Kerberos 5, but it is a far
simpler system to get running than DCE, which does
address some of those issues.
One would hope to see the following things
from this open sourcing:
*BSD client / servers.
MacOS X client (at least!)
Millineum / Win2K clients (NT clients exist currently).
If the MacOS X client happens, then there will
be a secure, scaleable enterprise filesystem for the three
major computer platforms -- Wintel, UNIX, and Mac, and it'll even be freely available! I don't believe that there are any
products available today that offer secure,
robust support for all three platforms (and no, I don't consider protocol translators, such as Samba or CAP, which require you to set up the clients to use cleartext passwords over the wire to authenticate (not to downplay in any way the role of either technology -- it's not their fault that you've got to set up the clients in that fashon to interoperate with AFS as it is now), or
using NFSv2 or v3 on the UNIX end to talk to something like Novell 5 (which, AFAIK, doesn't
talk at all to Macs anymore)).
This will give us one protocol on the wire,
multiple server-side implementations (interoperable in the same cell!), multiple client-side implementations, WAN scalability, and
secure authentication. A good day for the world!
Sortof cute, in a ed(1) sort of way, to see that sort of machine being UUCP capable.
Ethernet == high latency for PVM-ish clustering
on
IP Over SCSI?
·
· Score: 2
One big problem with PVM over Ethernet is that the majority of (at least naievely coded) PVM programs want to pass relatively small messages (not nearly filling an Ethernet frame) -- you know -- pass 10 ints here, 20 floats there, and ultimately the latency of TCP->IP->Ethernet gets you, even over 100mbit. IP over UltraSCSI on a dedicated bus would most likely reduce the latency introduced by Ethernet, but wouldn't help the latency tax induced by the IP + TCP processing.
The coolness factor would be high, as would keeping from having a secondary Eth-switch to host the message-passing traffic to keep it off of the primary gen-purpose network.
TCP/IP as well as Ethernet are general purpose networking solutions, real workhorses. However, high-performance cluster-based parallel programming is not a general purpose use -- it benefits the most from a communications path that is optimized for a constant stream of high-volume, relatively small messages from any one node to any other. Sortof a networking nightmare, eh? Sortof like how a usenet feed is a general filesystem's worst nightmare -- uses the underlying mechanism (transport mechanism in PVMs case: TCP/IP/Ethernet; filestore mechanism in usenet's case: ufs, ext2) in a manner that goes against the grain of the optimization assumptions made by the underlying layers.
I maintain our department's 8-node Sparc PVM cluster. We use hand-me-down machines that get displaced from other upgrades. We use it for teaching parallel programming, so performance isn't a great concern for the future of humanity, but when the students write code that doesn't use the message passing medium effectively (currently a dedicated 100mbit switch), then they get a bit discouraged when their code runs better on a single machine as opposed to the cluster. Oh well -- part of the learning process!
Simply splitting the Office group away isn't going to stop Microsoft from playing dirty tricks in the client/server OS space, just as they've done here.
Not directly, but by creating a separate company that markets Office which may be well inspired to sell their Office product(s) to more than one OS, one can hope that one would have less of a need for the other company's client OS products, then significantly lessening the desire to own the other company's server OS products, including the ugly red-headed mutant bastard child of K5 servers.
I've an Apex DVD/MP3 player and love popping in a burned CD containing 10-15 hours of my self-ripped CDs, hitting shuffle, and not worrying about variety for days. However, this gives me little above having purchased a big-honkin' CD-changer. What would make my life complete would be the ability to take the same CD of MP3's, pop it into the car deck, and have it grok it. I could care less 'bout a hard disk on the in-dash player -- use that space for an ATAPI cdrom or DVD drive (yum -- how many MP3s would fit on a burned DVD ???). And then it'd also be a piece of cake for the thing to be able to play standard CDs too!
When I taught our (UNC-Charlotte's CSCI) graduate operating systems course, assmuming that the students had already received an undergraduate OS course (sadly, sometimes too hopeful of an assumption) which covered the core basics of memory management, process management, context swtching, and introduces the two-layer device driver approach (our undergraduate course uses the XINU book), I picked up where that course left off, covering more about device drivers, I/O descriptors and their interaction with system calls, the filesystem (on-disk implementations, kernel implementations, different implementations at different mountpoints), then finishing off with distributed systems. One large component of the course was reading the Linux kernel source code in order to see a "real world" implementation of the coding concepts discussed in class. I have aways been a critic of how too many CSCI courses focus solely upon writing projects, yet don't spend enough (or any) time having the students read non-trivial code. We wouldn't ask novelists-in-training, essayists-in-training, or poets-in-training to write more than we've asked them to read, would we?
Anyway, two series of projects accompanied the lectures and assigned code readings. The first was to design and implement a basic interactive shell, first with basic file redirection and piping, later adding redirection to TCP sockets. This project aimed at giving the students a taste of systems programming that they may not have otherwise received, plus hammering in the UNIX concept that read() / write() will work on any sort of descriptor, be it pipe, file, or socket; even without the knowledge / cooperation of the process doing the I/O. At the time of writing the projects, the students were to read though the kernel code which implements the major system calls that they were using in order to see what was really going on (or at least to get a general idea that it all wasn't magic -- it all boiled down to "C" source code somewhere).
The second project suite was the implementation of an inode-based filesystem, starting from the ground up. First write a simulated mini-SCSI bus that supported two types of devices (one with 512-byte sectors, the other with 4096-byte sectors, just to ward off assumptions at the inode/block management layer). Once that works, add an inode manager that can use one of the virtual SCSI disks. Lastly, add a directory services module on top of the inode manager, so that we can manipulate files, directories, and symbolic links.
Ultimately, the projects asked a good deal from the students, as that the majority of them had not written any multi-threaded OO systems that made use of message passing (over the SCSI "bus"), so not only did they get to simulate some kernel components, they also had to come up to speed with some relatively advanced programming designs. The folks who used C++ learned the hard way that (at the time) debugger support for multithreaded programs was, um, challenged. Folks who wrote in Java had a bit of an easier time. Depending upon the level of knowledge in your undergraduates, I would not recommend the filesystem project. The shell project, OTOH, would be applicable to either 3'rd/4'th year undergraduates or graduate students, as that it hits home on the core UNIX datastructure -- the I/O descriptor. If the students were to have root access to the boxes, then I would have them perhaps extend an existing kernel subsystem or to write a new driver given an existing one. What about a thorough examination of the Linux scheduler / context switching algorithm. Could they cut any fat from it, as the IBM JDK folks did? What about examining the timer system? What about implementing a new "toy" virtual device driver, such as/dev/random (not that it is a toy, but that it doesn't correspond to any single piece of hardware, per se), such as a simple message passing port? One process opens it up, writes to it, then closes, followed by another process opening it and reading from it. That would demonstrate upper-layer device driver interfaces, plus the issue of passing bulk data to/from user space, and why time spent memcpy'ing becomes a factor in I/O bound systems.
Oh yeah, one other thing. You might want to think about obtaining the source code for more than one OS kernel (say also a *BSD kernel or the Solaris kernel -- being at an institution of higher learning, you should be able to get the Solaris source code w/o charge) in order to have the students compare / constrast the different approaches taken.
Slashdot Mirror
No, non-AD Krb5 servers can be used for authentication of users on Win2k / XP boxes just fine. Just won't be able to emit the AD-specific user *authorization* data -- essentially the network-group/role memberships ala the NTLM doman-wide group membership info.
You can sortof work around that using machine-local groups.
Check out this paper from M$FT [microsoft.com) for more info. This was helpful in getting my old uni's Windows XP realm to defer to the exising MIT K5 for authentication (go UNCC Mosaic!)
> Just look what happened (is happening) to Kerberos.
I'd say that Microsoft's 'extension' to Kerberos is ultimately perfectly fine and valid, just unfortunate that they did not make it completely valid to reimplement. They used a field in the ticket exactly how it was meant to be used -- for vendor-specific authorization data. Remember, Krb5 was designed to be an authentication protocol, and you can use either AD for authentication of plain-*NIX-boxen just fine or can use, say, MIT or Heimdal K5 for authentication of users on Win2K / XP client boxes w/o too much (relative) trouble.
AD's implementation of Krb5 genuinely strives to be per-spec, and the spec defines the authorization field to be used as the vendor sees fit.
I have the FreeBSD 1.0 CD :-)
Speedier / lighter weight, at least on the older hardware (IPC -> SS20). Reminds folks of the good old SunOS 4.1.3 days :-).
Can someone explain why I would choose XML-RPC or SOAP for an xplat / xlang distributed app as opposed to CORBA? Is the main purpose for using HTTP as the transport just a way to make it traverse firewalls and/or to traverse proxy servers?
Couple this with having the content in a read-only replicated volume, then go ahead and update many files, get your new site look-and-feel redone, then once your happy with it, release the read/write volume for replication, and pow -- one atomic transaction to all of the mirroring servers on the WAN!
Mabye this is why AFS is a major component of IBM's Websphere platform. All of this, currently working like a champ, and it'll be free and open source!
Now, it's not a perfect product, but it is way cooler than vanilla NFSv2 or NFSv3, especially on the server-side management side of things. It doesn't do disconnected operation (which CODA strives to do), byte-range locking, strict UNIX file semantics (data most recently written == data viewiable by all file handles to that file), or Kerberos 5, but it is a far simpler system to get running than DCE, which does address some of those issues.
One would hope to see the following things from this open sourcing:
If the MacOS X client happens, then there will be a secure, scaleable enterprise filesystem for the three major computer platforms -- Wintel, UNIX, and Mac, and it'll even be freely available! I don't believe that there are any products available today that offer secure, robust support for all three platforms (and no, I don't consider protocol translators, such as Samba or CAP, which require you to set up the clients to use cleartext passwords over the wire to authenticate (not to downplay in any way the role of either technology -- it's not their fault that you've got to set up the clients in that fashon to interoperate with AFS as it is now), or using NFSv2 or v3 on the UNIX end to talk to something like Novell 5 (which, AFAIK, doesn't talk at all to Macs anymore)).
This will give us one protocol on the wire, multiple server-side implementations (interoperable in the same cell!), multiple client-side implementations, WAN scalability, and secure authentication. A good day for the world!
Sortof cute, in a ed(1) sort of way, to see that sort of machine being UUCP capable.
The coolness factor would be high, as would keeping from having a secondary Eth-switch to host the message-passing traffic to keep it off of the primary gen-purpose network.
TCP/IP as well as Ethernet are general purpose networking solutions, real workhorses. However, high-performance cluster-based parallel programming is not a general purpose use -- it benefits the most from a communications path that is optimized for a constant stream of high-volume, relatively small messages from any one node to any other. Sortof a networking nightmare, eh? Sortof like how a usenet feed is a general filesystem's worst nightmare -- uses the underlying mechanism (transport mechanism in PVMs case: TCP/IP/Ethernet; filestore mechanism in usenet's case: ufs, ext2) in a manner that goes against the grain of the optimization assumptions made by the underlying layers.
I maintain our department's 8-node Sparc PVM cluster. We use hand-me-down machines that get displaced from other upgrades. We use it for teaching parallel programming, so performance isn't a great concern for the future of humanity, but when the students write code that doesn't use the message passing medium effectively (currently a dedicated 100mbit switch), then they get a bit discouraged when their code runs better on a single machine as opposed to the cluster. Oh well -- part of the learning process!
Not directly, but by creating a separate company that markets Office which may be well inspired to sell their Office product(s) to more than one OS, one can hope that one would have less of a need for the other company's client OS products, then significantly lessening the desire to own the other company's server OS products, including the ugly red-headed mutant bastard child of K5 servers.
I've an Apex DVD/MP3 player and love popping in a burned CD containing 10-15 hours of my self-ripped CDs, hitting shuffle, and not worrying about variety for days. However, this gives me little above having purchased a big-honkin' CD-changer. What would make my life complete would be the ability to take the same CD of MP3's, pop it into the car deck, and have it grok it. I could care less 'bout a hard disk on the in-dash player -- use that space for an ATAPI cdrom or DVD drive (yum -- how many MP3s would fit on a burned DVD ???). And then it'd also be a piece of cake for the thing to be able to play standard CDs too!
When I taught our (UNC-Charlotte's CSCI) graduate operating systems course, assmuming that the students had already received an undergraduate OS course (sadly, sometimes too hopeful of an assumption) which covered the core basics of memory management, process management, context swtching, and introduces the two-layer device driver approach (our undergraduate course uses the XINU book), I picked up where that course left off, covering more about device drivers, I/O descriptors and their interaction with system calls, the filesystem (on-disk implementations, kernel implementations, different implementations at different mountpoints), then finishing off with distributed systems. One large component of the course was reading the Linux kernel source code in order to see a "real world" implementation of the coding concepts discussed in class. I have aways been a critic of how too many CSCI courses focus solely upon writing projects, yet don't spend enough (or any) time having the students read non-trivial code. We wouldn't ask novelists-in-training, essayists-in-training, or poets-in-training to write more than we've asked them to read, would we?
Anyway, two series of projects accompanied the lectures and assigned code readings. The first was to design and implement a basic interactive shell, first with basic file redirection and piping, later adding redirection to TCP sockets. This project aimed at giving the students a taste of systems programming that they may not have otherwise received, plus hammering in the UNIX concept that read() / write() will work on any sort of descriptor, be it pipe, file, or socket; even without the knowledge / cooperation of the process doing the I/O. At the time of writing the projects, the students were to read though the kernel code which implements the major system calls that they were using in order to see what was really going on (or at least to get a general idea that it all wasn't magic -- it all boiled down to "C" source code somewhere).
The second project suite was the implementation of an inode-based filesystem, starting from the ground up. First write a simulated mini-SCSI bus that supported two types of devices (one with 512-byte sectors, the other with 4096-byte sectors, just to ward off assumptions at the inode/block management layer). Once that works, add an inode manager that can use one of the virtual SCSI disks. Lastly, add a directory services module on top of the inode manager, so that we can manipulate files, directories, and symbolic links.
Ultimately, the projects asked a good deal from the students, as that the majority of them had not written any multi-threaded OO systems that made use of message passing (over the SCSI "bus"), so not only did they get to simulate some kernel components, they also had to come up to speed with some relatively advanced programming designs. The folks who used C++ learned the hard way that (at the time) debugger support for multithreaded programs was, um, challenged. Folks who wrote in Java had a bit of an easier time. Depending upon the level of knowledge in your undergraduates, I would not recommend the filesystem project. The shell project, OTOH, would be applicable to either 3'rd/4'th year undergraduates or graduate students, as that it hits home on the core UNIX datastructure -- the I/O descriptor. If the students were to have root access to the boxes, then I would have them perhaps extend an existing kernel subsystem or to write a new driver given an existing one. What about a thorough examination of the Linux scheduler / context switching algorithm. Could they cut any fat from it, as the IBM JDK folks did? What about examining the timer system? What about implementing a new "toy" virtual device driver, such as /dev/random (not that it is a toy, but that it doesn't correspond to any single piece of hardware, per se), such as a simple message passing port? One process opens it up, writes to it, then closes, followed by another process opening it and reading from it. That would demonstrate upper-layer device driver interfaces, plus the issue of passing bulk data to/from user space, and why time spent memcpy'ing becomes a factor in I/O bound systems.
Oh yeah, one other thing. You might want to think about obtaining the source code for more than one OS kernel (say also a *BSD kernel or the Solaris kernel -- being at an institution of higher learning, you should be able to get the Solaris source code w/o charge) in order to have the students compare / constrast the different approaches taken.
Have fun with the course!