On Thu, 2005-03-24 at 18:59, Craig White wrote: > > Not me - I haven't made it all work yet because as soon as a popular > > distribution ships something, everything else will be obsolete. However > > the discussion on the k12ltsp list leads me to believe that a scripted > > setup works for a lot of people, and they end up with linux accounts > > with automounted home dirs and an idealx based domain controller. If > > a few more people succeed with the setup it will probably be included > > in the distribution which is basically fedora plus ltsp and a few other > > extras. > ---- > see this is what confuses me - k12ltsp is thin clients for Linux server. > Windows domain controller seems to be totally out of purview of k12ltsp. First, the thin clients are not the issue: users log into the server via xdm. The problem is that a server handles only 30 or so clients and they want to be able to set up hundreds of terminals with minimal per-server setup (and no per-client setup...). Their solution is to NFS export the home directories to all the servers and do network authentication. Then any number of other servers can be used and any user can log in at any terminal. Most already have Windows boxes and Macs on the network and many are happy about being able to teach in a heterogenous environment. They use login scripts on the windows boxes to map the users home directory as a drive at login - some with roaming profiles to allow anyone to log in anywhere. Some are booting macs as thin clients - I think others use X under OSX and log into the k12ltsp servers from there. I don't see anything confusing about wanting to do this. > Of course, it all breaks if they don't use k12ltsp server for domain > controller and my general feelings about IDEALX scripts are that they > are a poor way to run a railroad. How would anything else break if they don't use that part? Some don't use windows at all. > Now that we are discussing the IDEALX scripts - they are a one size fits > all and the only time I have used them is to migrate an NT 4 domain > controller and I have had to hack the scripts to get what I want and > then I still end up doing a slapcat on the DSA and a few global > find/replace edits, drop the DSA, slapadd the fixed one and then I'm > done. No doubt they are finding that IDEALX scripts need a bunch of work > for their purposes too. Yes, that's why they are trying to script as much of the setup as possible. > The purpose of the IDEALX scripts is to facilitate the use of > Microsoft's 'User Manager for Domains' utility aka usrmgr.exe I think being able to mange passwords in one place regardless of the plaform(s) where you log in is the main point. > While this tool does a reasonable job for Windows attributes, it falls > far short in all other areas so the IDEALX scripts too end up being > mostly inadequate for a more comprehensive solution. Yes, there have been several people asking about web/GUI programs to manage the LDAP data. And others reporting varying degrees of success. > > > > If you poke through recent k12ltsp list archives you should find the > > script setup. > --- > I do see a k12ltsp-list at lists.redhat.com but there's nothing really > in the archives - I am a subscriber to ltsp list @ sourceforge but there > hasn't been that much discussed about ldap I guess the list name changed to k12osn somewhere along the line and their web home page is hopelessly out of date. Follow the link from the wiki: http://www.k12ltsp.org/phpwiki/ to the mail list. Now that I think about it, they may not be doing automounting either - they may just mount the whole /home from the nfs server into all the k12ltsp servers. > of course the k12ltsp is as you say, a fedora based project where as > ltsp itself is vendor neutral - thus a 'fedora' solution isn't going to > be adopted by the larger project if it isn't vendor neutral. At best, it > is going to be a 'local' fix. For a while some people were recommending something called scoelinux which was a similar concept built on Debian. They didn't like it as well for most things but LDAP was all set up so some people loaded it on one box to use for LDAP only. > Based on my experience on samba@xxxxxxxxxxxxxxx and turnkey installation > of IDEALX scripts, there is going to be a LOT of pain, anguish, > frustration and recrimination going on in k12ltsp arena if they actually > implement this. And the other options would be???? > Surely your not expecting this discussion on this list to get anything > done in this regard. > --- I guess I was hoping that things weren't really as bad as I thought and someone would point me to an ldap-config.rpm package. Sort of like what happens when you ask about something simple like a video recorder with a bunch of codecs ... > In fact, this is the ugly truth about LDAP - once you finally get > it...you get it. Until then, it's a bitch. So to implement even a core > LDAP setup without a full understanding, you can't troubleshoot, you > can't fix it, you can't even describe what it is that isn't working. > It's a tragedy that I see playing out daily on the samba list. They've > now moved much of that traffic over to ldap-interop list so it plays in > two separate arena's now. I suppose the practical way to deal with it is something like: http://tools.arlut.utexas.edu/gash2/ which keeps all your user data in a totally independent database and exports it in formats to work with everything that needs it. It just sounds like horrible overkill not to use the system native tools. -- Les Mikesell les@xxxxxxxxxxxxxxxx
