Is there a LTSP/LDAP Howto? On Fri, 23 Jan 2004 01:31:09 +0100 Anders Bruun Olsen <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 22, 2004 at 11:50:40AM -0500, John D. Robertson wrote: > > > This would not get over the problem that all the users would need an > > > account on both servers and the fact that their settings wouldn't > > > migrate from one server to the other. > > Well, there's no way you could do these things with any dhcp daemon anyway, no > > matter how cleverly configured. > > If you set up NIS for user authentication and use an NFS mounted volume for > > Either NIS or like the setup I have with an LDAP directory which logins > are done against will make it easy to do it. > > > user home directories, then the solution I suggested would work just fine. If > > Yes, I know - but if you just mount the home directories on one machine > from the other and the master server goes down, it's going to be > useless. As I understood it, availability was also an issue, but I might > have misunderstood? > > > you are sysadmining an LTSP installation, you should already know this. I > > assume you are a Windows sysadmin and new to Unix. > > I am in fact an experienced linux sysadmin (been working with linux > professionally since 2000). Don't be so quick to jump to conclusions :). > I am administrating an LTSP installation with 10 clients. > > > You need to know that Linux servers just don't go down unless the hardware > > fails, or the sysadmin is incompetant. I have an installation where the > > I know that quite well, but I have experienced things like thin clients > spontaneously rebooting when using kernel 2.4.22-ltsp-2 but working fine > with 2.4.19-ltsp-1 and our LTSP server having build up so many defunct > processes that init couldn't handle em all any more and it ate up 99% > CPU resources, leaving me with no other option than rebooting the > server. So linux servers CAN go down for things other than hardware > faults. > > > entire enterprise (24 users, email, web server, database, firewall, dns, > > dhcp, ...) is running on _one_ dual processor system. The users access it > > using LTSP thin clients. The system has been up for 50 days. The last time it > > was down was for a kernel upgrade. > > If you want true high availability then the cost and complexity will be > > substantial. You may find that it is much less expensive to put all your > > software on one fast server with RAID'd disks. keep a complete set of spare > > parts handy so you could fix a hardware failure and have the server back up > > again quickly. > > I agree completely - I was saying that there are problems with running a > load balancing-like solution as suggested, but suggested that if the > hardware available wasn't enough a cluster solution might be an idea. > > > > > Put an entry in the crontab to run this script every minute. > > > I believe this would put quite a load on the server - CPU time which in > > > my opinion could be used better for other things. > > Better upgrade that '386 man! > > No 386's here.. > > > Seriously, you need to look at this quantitatively. What makes you think that > > a tiny job that runs once a _minute_ would put excessive load on the CPU? It > > Okay, so I may have exagerated a bit - shoot me will you?.. The point > was that restarting the dhcp daemon every minute seems like a foolish > solution IMHO. > > > would probably take a few _milliseconds_ of CPU time at the most. Compared to > > the CPU load of things like Gnome, KDE, Mozilla, Java, and Open Office, this > > is serveral _orders_of_magnitude_ smaller, or negligable. > > In terms of wasted CPU, you should be concerned about processes like "java_vm" > > and "wineloader", which are often particularly obnoxious. For example, one > > user can bring the system to it's knees when they hit a web page with 20 java > > applets on it, each one spawning a different "java_vm" that is eating all the > > CPU it can get! > > Yeah, java can be a bitch sometimes.. > > > My solution to this is the following script, which runs once per minute: > > ----------------------------------------------------------------------------------------------------------------------------- > > [SNIP - script] > > Thats all nice and well, but not a solution I would recommend, it seems > like a not altogether nice hack (the overall solution, not your code, > that's quite pretty :). But we are all different, so some will probably > like your approach to the solution, others will prefer something else. > > -- > Anders > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V > PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? > ------END GEEK CODE BLOCK------ > PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8BFECB41 > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
