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
