Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux Implementation For 2500 Workstations? 205

Posted by Cliff from the helpful-recommendations-wanted dept.
Jeff Kwiatkowski asks: "We are looking to roll out Linux to over 2500 desktops and could use any advice that we can get. We need security info, implementation suggestions and any other advice that you would care to offer. We are currently evaluating Debian, Caldera and Red Hat. I also want a minimalist desktop, so I have been leaning toward WindowMaker as the window manager. In addition, we currently have machines with 32 meg of RAM (fast processors, though) and would like to keep the upgrade to 64 meg, only, if possible. Lastly, do any of you have any thoughts on Word Perfect vs. Applixware?" For those of you who think that the claim 'Linux is not ready for the desktop' is a falsehood, then this story is for you. As you can see, people are looking at deploying Linux on the desktop, and suggestions from you guys could make this process a lot easier.
This discussion has been archived. No new comments can be posted.

Linux Implementation for 2500 Workstations? More

Linux Implementation for 2500 Workstations?

Comments Filter:

  • Central administration is the key (Score:1)

    by Anonymous Coward
    1. You do not want to keep /home on the local disk. It will be very difficult to make backups of 2500 disks. Instead, keep it on a central file server. That way, the workstations will not need any backups at all. AFS is a good distributed file system, if you can afford it. Otherwise, use Coda.

    2. Have one common /etc/passwd for the whole site. Keep one central copy, and distribute it to all workstations every day or hour. That way, in combination with (1), everyone will be able to use every workstation and it will be very easy to create new accounts.

    3. Centralize as much administration as possible. The same way you distribute /etc/passwd, you can distribute all other configuration. It's even possible to upgrade the machines remotely.

    4. Keep some services in /etc/inetd.conf going. fingerd isn't going to hurt you. You will definitely want to keep some remote login service going, like telnet or ssh. Believe me, if you cannot log in to all of your computers remotely, administratiing them will be a veritable hell.

    5. Encrypt all sensitive communication. Sending passwords unencrypted over the network is a Bad Thing, especially in a court house. Use Kerberos authentication, it better, simpler and more flexible than ssh in the long run. You can use it for encrypted telnet, encrypted POP3 and IMAP, encrypted remote X, file system authentication and more. Don't forget to turn off cleartext logins, or people will use it anyway. (Don't let them get used to it!)

    There are lots of other things you can do, but these are the basics. All this will save you a lot of work.

    I'd go for fvwm2 as the standard window manager. I haven't tried WP, so I don't know if it's better that ApplixWare. I hate StarOffice because it one huge application with a completely nonstandard user interface, instead of a few smaller applications that works well together with each other and fits well into GNOME, KDE, all window managers and X in general.

  • Re:Kickstart (Score:1)

    by Anonymous Coward
    There is a quite easy way to set up many boxes. Set up one, then make am image with e.g. Ghost. Then just put this image on the other boxes. Works quite well. Another way is to set up application servers with thin clients.
  • use one of the "old style" window managers, like twm, rather than one of these "environments".

    Actually, wasn't one of the motivations behind fvwm that twm was too heavy?

  • Just installed it here...doesn't seem to be too user-friendly. OTOH, it saves in standard file formats (rtf & html for the word processor). Also, it's GPL so maybe elements of other GPL office suites could be merged (like WordPerfect/MS Word filters).
  • I help admin a couple Irix labs and four Linux labs. For the Linux labs, we've been using VA's SystemImager [systemimager.org].

    We basically do a kickstart install of RedHat 6.x, then call 'updateclient' with the proper options to grab the image from our server. SystemImager is a big Perl script that uses rsync to pull files across the network. It's quick and it works 99% of the time. We've done quite a few machines, and we are doing a couple more labs worth in August. I am the 'image builder guy,' so I get to assemble and test an image, break it, bend it, and, when it's ready, I upload it for our labs to share. When the labs are ready, we pull the image down onto a few test machines, and if everything goes right, we do the rest. It's a simple process that is easily scriptable, and you only have to maintain one image for all of the machines.

    All of our machines are EXACTLY the same, though, so if your machines are different, you could run into problems. We've had very good luck with it, and I would recommend it to anyone doing a big Linux rollout.

    ---
    Ryan

  • By keeping all data and major apps on a remote server you are sacrificing performance and avaliability for convenience. Not the users convenience, mind you, but the sysdamin's. Such a strategy may work in smaller (where the network can handle it) non-mission critical environments (so when your file server and its backups or the network go south and no work is possible its no big deal) or where you lack skilled system administrators to devise better systems. However, the most scalable and robust method is the use a remote update facility, e,g, rdist, rsync, apt, rpm.

  • Having used FreeBSD and Linux exclusively on my 3 home computers for the last few years, I thought I would comment on the day to day use of "office suites."

    Word Perfect seemed slick, but querky. Font and printing problems alone were enough to make me stop using it. It was nice, but the little problems were a pain in the ***.

    Applix seems so "out of date" to me, I almost tried to figure out if I could return it for my money back. But I ended up using it the most for about 1.5 years when I had at least 64M RAM. Honestly, with gnumeric and abiword, I think gnome has rendered Applix outdated (and they cost NOTHING!)

    In the end, I've settled on the one solution I think was worthwhile, Star Office with at least 128M RAM. Once you get to like 160M or more, Star Office really is very useful. Of course, I couldn't afford to upgrade EVERY system to run Star Office, so I found another solution. Upgrade a couple systems as much as possable, and then just run them that way (X -query fast.system.net or export DISPLAY=workstation).

    I still haven't got around to installing this Windows95 thing, I hear 98^H^H2000 is out now?

  • You may want to check out tagfiles with Slackware. With them you can create lists of the packages you want installed. The only problem is that Slackware does not include a network install. You may need to create your own network installation based on slackwares installation disks.
  • You have more choices here than you really want or need. here are a few of my favorites.

    you can install Mandrake on a desktop, configuring the installation to taste then at the end of it you have the option of creating a boot diskette which will clone that installation. If that installation is from a server then you can make copies of the diskette and run around booting the PCs and letting rip.

    This wouldn't give you Wordperfect Or Applix ( unless they are included in the App CDs for Mandrake ) but you can push that out with an FTP script from the server.

    Another nice option is to install on one PC configure and tweak it to death then use DD and wget to create an image of the hard drive on the server ( this assumes the server has a better network connection than the workstations and includes a blazing fast RAID ( with 2500 workstations you need that anyway ).

    you can then create a boot diskette with a script that simply partitions the hard drive and dumps that image off the server to it. This is easily the fastest way to clone an installation to a pile of PCs.

    As for software I disagree about the Window manager but it's totally your choice. I would use KDE mostly because it comes with all the utilities you would want your users foundling and it has that familiar Windows 9x feel by default.

    64 megs is more than enough to handle this stuff. One hint though is to use a 1 gig swap partition ( which you can likely afford on modern machines ). That way runaway leakware (caught) Netscape (cough) won't take your machines down too quickly.

    The initial role out isn't that critical though. What is really fun is the latter updates. Trust me on this one, you *will* want to push KDE-2.0 and KOffice 1.0 ( despite plans to the contrary, I suspect they won't ship together ). Other cool things you will want to push to these desktops latter include Mozilla and the next generation of JVMs.

    Fortunately you can likely live with the current Kernel for a few years.

    Finally I would use Mandrake Update or something similar with your own server set as the mirror so you can butcher security holes as soon as they are discovered with little if any hassle.

    All the best and tell me where to send my resume if you can't do this stuff by yourself.
  • I'll be breif.

    Points:
    1) Redhat's kickstart system is very usefull. Split a 'in house' tree of 6.2.
    2) Create custom package lists in the base/comps file to reflect the type of machines you need.
    3) Create/recreate rpm's in distro to reflect all the spicific setting changes/customizations you need. (And any comercial software you need on machines. Those RPMS are just kept inhouse.
    4) Make sure all updates/systemconfig changes are done thru some type of package management system.. RPM is actually VERY good for this. Get familar with writing spec files.. :)
    5) Auth systems: Kerb5. NIS, only if necessary and on 'controled' network segments.
    6) Home dir Fileserver: Network Appliance F760. Period. There is simply no other solution that works as nicely. Cost per megabyte is high, but its so damn reliable and easy to deal with.
    7) Give all your machines hostnames based upon some location sceme, and use dhcp to give out addresses _based upon hostname_ so management of vlans can be a easier to keep track of.

    Also.. Its not hard to hack together a web interface to pop out floppy images with all the necessary info in the kickstart config file. Have every machine with a nearby copy of its 'reinstal' floppy, so if the machine gets 'screwed', its easier to do a 20 min reinstall (thats all it takes) then send someone from IT to 'fix' the machine.
    ...
    . ""The future masters of technology will have to be lighthearted and
    . intelligent. The machine easily masters the grim and the dumb."
  • It is *much* easier to install a new application on a few servers, than it is to install it on a few workstations. In the long run.

    When some bug is found in the application and it needs an update, who got the application ? You can use a database for keeping track of it of couse, but still...

    Keeping everything homogenous when you can actually do so, is the clever thing to do. This is actually a special kind of setup, since they only need one architecture, and all the servers can be configured the same. IMO it would be stupid not to take advantage of that.

    Also, by having the same applications on all servers or on all workstations (whichever approach is chosen), avoids the problem that someone using someone else's workstation is missing applications (and need to bother the admin with the problem).
  • When I first started using WindowMaker I thought the lack of a pager was a glaring omission, but it's [sic] absence forced me to use the kbd shortcuts which are WAY faster than mouse clicks.

    And if you build Window Maker from source (and your X server is set up properly), you can use your mouse's scrollwheel to switch between workspaces by "scrolling" on the root window.

    To do this:

    1. Ensure that MOUSE_WS_SWITCH is defined in src/wconfig.h.in
    2. Optionally, change the sense of the scrollwheel in src/event.c [hint: change the sign in the calls to wWorkspaceRelativeChange() near line 638].
  • I'm suprised that no one from RH has replied to this - but mkkickstart under 6.1 had some known issues. I will say that I've successfully used kickstart under 6.2 to load 6.1 on a station and that's a nice way to do an install. I'll also mention that I'm looking at a future install of a slightly larger number of stations - and that I *need* a fairly touchless way to install to some boxes that don't have floppy drives or cd-rom drives. kickstart + bootp/dhcp is pretty darn cool.
  • I absolutely agree with the above comment. And I just want to point out a few more excellent points of this setup:

    1. CPU power and memory requirements keep increasing year after year, forcing you to upgrade stand-alone PCs. In the case of terminals, however, they are used only for running the X server. All the applications would run remotely. Therefore, it would be irrelevant if the terminal is P-100 or a P3-1000 -- all it's used for is *display* of data. You would need to upgrade the terminals *only* if you decide that they need more video memory/faster video acceleration or something. And in general, since a terminal does no work wrt running applications, it is not subject to the usual upgrade cycle of stand-alone PCs and, therefore, can last *much* longer.

    2. It is *much* more efficient to run applications on a single server than on a whole buch of stand-alone PCs. First of all, 99% of the time a stnad-alone PC is idle. How much CPU work does it take to type in a letter in Word or read a web page in Netscape? Since a single application server would run all the apps for a fairly large group of terminals, the CPU time would be used much more efficiently. Therefore, even a not-so-fast server would be able to easily serve a few dozen terminals. Further, how many people in the office would be running exactly the same apps? Say, 20 people are running netscape at the same time. On stand-alone PCs, each would need to have a copy of Netscape code in memory. On an app server, only *one* copy would be required for all 20 users, thanks to the shared memory. So, an app server is also more memory-efficient as well as CPU-efficient.

    3. Windows apps. Yes, people need to run them too. (like Word for instance). You can set up a couple of NT servers to run wincenter or something. Then, the terminal users can run windows apps in almost the same way as remote X apps (windows apps appear inside a separate window that looks like a NT desktop window)

    4. Another poster has already explained the virtues of storing all user data remotely on file servers, so I'm not gonna go into details

    5. Upgrades. I already said why hardware upgrades would need to be very rare. Same with software. The terminals would run a very minimalist installation of Linux with all daemons off except for the X server. So you would neet to worry only about upgrading the servers. It sure is easier to upgrade a few dozen servers than 2500 individual workstations.

    I could go on, but that should be enough to give you the idea. Just to let you know I'm not speaking out of my ass, my university (www.uwaterloo.ca) is using exactly the same setup, except the terminals also boot remotely (via bootp). It works very nicely. Only problem is that this being a cash-strapped university, the terminals have really crappy video cards in them, and really crapy monitors. Oh well.
    ___
  • I'm not in favor of remote execution of applications. For reasons I stated later, running X over a LAN isn't a scalable choice.

    Actually, it is. My university is running 5 labs of diskless X terminals (20 - 30 terminals in each) over an unswitched half-duplex 10BaseT and it works great. Don't forget that X was designed for network. Why not use this feature then?
    ___

  • uhhm, no. I'm in third year. Go away troll.
    ___
  • You've never tried it yourself have you? My university is running exactly this setup and it works perfectly. Yes, netscape runs just fine remotely. There's no Applix or WordPerfect, but you can use MS Office 97 that runs over wincenter and it also runs just fine. Come back after you've seen this kind of thing in action. X was designed for network. The ability to run X apps remotely is there for a reason.
    ___
  • I have never successfully gotten kickstart to work. I spent about a week trying with RH6.1. They may have gotten it fixed in 6.2, but 6.1 is absolutely unusable. Also, they need a validator, so you can check your kickstart syntax errors on the fly.
  • Corel defeats one of the primary benefits of Linux - vendor independence. Because of its closed nature, the only method of support/upgrades you will get for Corel Linux is Corel.
  • 64MB is plenty for anything I've done. I'd use sawfish (formerly sawmill) as a WM. It's really easy on the resources, easy to config, etc. etc. As for distribution, it depends on your needs. What kind of upgrade path do you want to follow? As far as short-term, it doesn't really matter. The problems will occur in the long term. Considering this, you will want to use a distribution that is entirely free like RH/Debian/Slack, because 5 years down the road, if you get a vendor-specific distribution, you will be a slave to that vendor. I've never used Applix, but WP is very nice.

    One thing you should really consider when choosing a dist is to make sure that _everything_ you install works properly. This is RH's big difficulty. All of the GUI tools and sysadmin tools work "half-way". If you look at them wrong, they break. For desktop users, this is unacceptable. Users can usually deal with strange environments surprisingly well, as long as the tools actually work. They get really frustrated when some buttons don't work, some right-click menus don't work, or a certain sequence of clicks crash a program. If you don't know what I'm talking about, try using the RedHat GNOME RPM manager in RH 6.1 (haven't really looked at 6.2). RH is nice on the server (without Linuxconf), because it has everything you need, and everything is integrated with PAM, and organized in a sane way. But on the desktop, it has too many half-done tools. So, either find a dist that doesn't have half-done tools, or don't install anything that doesn't work 99.99% right. I'd be happy to supply you with more advice (advice does come cheaply), but I'd have to know more about your requirements.
  • One more thing, remember to disable any unnecessary services that are being run, or find a dist that doesn't run them by default. This will not only improve security (it is actually a MUST for security) but will drastically improve performance. And, in conclusion, DONT RUN SENDMAIL ON DESKTOP MACHINES. This is a bad idea that always leads to trouble. Just use SMTP. A lot of people/dists (esp RH) try to put a lot of servers on desktop installs. WHY????? Isn't that what server machines are for?
  • While rolling out 2500 workstations will be a task on its own, managing them day-to-day will take some intense planning.

    I've seen people above advocating centralizing your user data, and making the boxes all cookie-cutter installs. Excellent advice.

    Once you have them up and running, however the question becomes. "How do I make changes to the environment en-masse?".

    Thats where GNU cfEngine [hioslo.no] comes in. It's a great tool for maintaining heterogeneous networks. You should consider implementing this on the rollout, as it will allow you some means to "push out" changes to all of the hosts.

    Check out:

    http://www.iu.hioslo.no/cfengine/ [hioslo.no]

    Its a very powerful tool, so much forethought and planning is in order with it, but it pays off in the long run in being able to make changes to the machines in large chunks.

    -- PoochieReds

  • Have you tried SIAG office?

    It is available at www.siag.nu
  • Try Mandrake 7.1, it is very easy to set up, and the easy-to-set-up thing is very important when you want to do the set-up thing some 2,500 times.
  • Well, if you're looking for something to keep all 2500 machines up to date, then I'd advise debian. Debian's apt tool makes maintenance very easy, especially over a large number of computers.

    If you have a debian cd, or if you wouldn't mind making your own ftp mirror of a debian ftp server, you can have one single computer that acts as the "syncronizer". Now this idea I've just heard about, never actually tried it. All the other computers can be configured through a crontab to run apt-get update, and if you point them to that single machine on the network or whatever, it'd be so much easier.

    Each machine's software configuration in perfect sync. I guess this would work, in theory, but again, i've never tried it myself. Well, Cheers. See ya later. Hope I dont get flamed or anything :) *ducks*

    -- webfreak

    webfreak@themes.org
    http://e.themes.org
  • Window manager plug: icewm can easily be set up to be inimal but still functional (start menu, taskbar, nothing else).
  • To replicate a lot of disks, and to be able to switch broken disks (or just to make easy real-world tests), I strongly recommend the use of disk racks.

    Since for obvious cost reasons, you'll most probably use IDE on your deployed machines, I recommend that your replicator be a mostly SCSI machine, with an IDE rack, and IDE compiled as kernel modules; this way, you can hot-plug and hot-unplug your IDE racked disks as you replicate them, by modprobing the IDE modules in and out (be sure to use the right hdparm/ioctl calls to flush caches and shutdown disks, though): no reboot needed!

    Even without a SCSI machine, I've installed a company's computer rooms with IDE racks, and it's been a pleasure to replicate, install, test, fix, and reinstall machines there. (I also used debian as the basic distribution, which isn't perfect in a NFS- and NIS- sharing environment, but is the least horrible thing I tried.)

    Finally, if your machines are heavily networked, you can use such thing as the Linbox Network Architecture [linbox.com] (web site currently down for recreation; contact the people at linbox.com), which is basically a lots of diskless linux clients (you buy a fast ethernet and RAM instead of lame IDE disks), and a few badass servers for files and applications. Ten times less disks to maintain and clients without persistent state means much less administration.

    Yours freely,

    -- Faré @ TUNES [tunes.org].org

  • I'd go with WindowMaker. It may be personal bias (and I'm definitely *STEP biased) but I think it is the most solid and clean WM out there. It's especially better than all the Windows clones out there. It can use more resources than Blackbox or something, but it's a lot better than E.
  • If you are buying new machines, why not ask the vendor to install what you want?

    If you are installing 2500 machines, you usually know better than your vendor. 1 hour maintenance per machine equals 1 man-year. You'd better have competent sysadmin(s) and automate as much as possible. You must be able to automate the system reinstallation, software upgrade, hardware upgrades, ..., of the machines.

  • Good advice. I'd simply add that network architecture should be carefully considered - depending on the trade-offs taken, you're going to see a lot of routine network traffic.

    If you do end up with workgroup application/mail/print/etc. servers, think about where they live in the heirarchy, and keep them close to the users.

    You'll have to calculate your bandwidth needs, bu t I suspect that for that number of clients, you'll probably end up with a three tier network. Clients on the bottom, on 100MBit switches, connected via fiber to concentrator switches with the user servers, connected to the backbone.

    -j, showing his biases

  • With any kind of roll out of this size you are going to do massive customization. What defines
    which distribution you wish to use is which one
    is easiest to customize. I have found Debian the easiest to customize to my needs. In most large environments, people don't upgrade machines, they wipe them out and migrate their server data. Debian gives you the choice of upgrading machines.

    The real power of debian, is that you can customize one users machine and those customizations will continue across upgrades. Not everyone needs dia, but some subset of people do and they have dia and when the upgrade they still have dia and you don't have to do anything. That is powerfull and usefull. Yes you have to login to someones machine and give them dia the first time.

    If you use debian you need dzinstall [unitn.it] and you will need to customize the base install.

    Another important strategy that has not been
    discussed is how do you break this down to groups.

    Identify groups of dependent people. The accounting department is all dependent on everyone else there so they should be made a unit. Give them their own server. I would aim for 1 server for every 20-100 users. Those users should be able to function with their server even if the "centralized" servers go down.

    each "departmental" server should be backed up, should have a "network drive", a "name server", an "account server", a "network server", "OS Server", "print server"

    NFS server

    NIS slave

    DHCP server

    DNS server

    Web server (Intranet)

    LPD

    should server as an apt server or as an rpm server

    The machine configuration for the department should also live on your central server and should be pushed out to each department using rsync. But by distributing the neccesary services you reduce this risk of a catastrophic failure hitting all users.

    NIS/NFS

    NIS/NFS security I know it is impossible but they are very convienient and there are some precaustions you can take.

    NFS -
    users do not have root on NFS clients. IF they do they can be any user on the system.

    you keep a static arp table for IP address and you
    use static DHCP for clients. And you list every
    client that is allowed to connect to your NFS server. Yes this can still be hacked!!!! but someone cannot just bring in a laptop and full control over your users files. Its keeps accidents from happening.

    NIS

    enforce use of good passwds. this is done by configuring the passwd program.

    Make sure you have slave NIS servers!!!! Set the local slave to be the default NIS server for clients.

    Don't use broadcast NIS, set the NIS server on each client. Yes someone can still spoof your NIS server, do not let the NIS from the outside internet in. It is worth it to trust your users, becuase it makes your computing environment better and you can trace down who caused problems and get them fired.

    Automated Installs.

    2500 user machines
    assume 50 departmental server and 5 back end master servers.

    Buy new equipment and do the master servers correctly.

    Replication Strategy.

    Make sure you can produce a departmental server from a blank box in 2 hours. Make sure anyone who can read instructions can produce a departmental server in 2 hours. And hopefully that won't be two hours of interactive time.

    Given a departmental server, make sure you can build a new desktop from a blank machine in one hour. If cannot you have problems with your automation and your network fix!

    USE SOURCE CONTROL all system infromation should be in source control! From the very beginning keep your management scripts, your NIS source files, your deployment descripters in Source control, I reccomend CVS! This will make your life easier.

    DESKTOP

    as for a desktop, I like windowmaker, I think it is very obvious for beginning users.

    WP is substantially lighter than Star Office, and is fairly feature complete. Star office will be a pig, try it out, some users will require it as it is the most feature complete office swuite available on linux. (NOTE DO NOT INSTALL star office so it is user writable, even if there is just one user per machine install it as a net install "setup /net" otherwise it lets users corrupt it) Applixware is clean, fast, stable has
    strange user interface, and doesn't have the feature count that many people want. And what you see on the screen and what you see on the printer tend to be pretty far off.

    I would reccomend avoiding net storage for applications and even all user data. Hard drives are cheap. It makes users less reliant on the network for performance issues. It also makes users for more in control at their workstation and it allows you to customize a workstation to an individuals tastes. (this is why debian is great, you get both customizations and easy upgrades). From a computing efficiency standard this does not make sense the net-slave computers are better. From an employee productivity standard this makes lots of sense.

    When setting this up script everything, make sure
    the that someone other than the person who solved the problem tries it and can do it.

    This is a lot of work and requires formalizing a lot of things. I would reccomend start trying to build the departmental server. The build the things to build the departmental server, destroy it and verify that it can be automaticall built by someone else, using information stored in source control. After that then start doing the end user workstations.

    Good LUCK! if you found any of these thoughts usefull do email me.

  • I think setting up 2500 linux boxes sounds like a great experience!
    Admin'ing would be easy. Hardware support would be the bitch.

    1. Network 10/100 Switched network
    2. DHCP
    3. NIS+
    4. NFS (Automounted)(hehe, CIFS?)
    5. Kickstart, or some automated install.
    6. IceWM (Very small, looks window'ish, FAST low mem,themeable, toolbar. Easy configs. I use it on all my Sun/Linux boxes)
    7. Web Interface for Email w/ SSL
    8. StarOffice.
    9. PowerBroker.
    10. SSH+SSHD.
    11. FTPD. (OpenBSD Ftp Port? no exec command) 12. Xfree 4.0.1 (Need to upgrade mine this weekend)
    13. Netscape. (Not sure which version is the most stable)
    14. Lot of people been talking about ReiserFS. Might be a good idea.
    15. Winframe clients maybe. (Dont know his setup)
    16. ENskip? (We use SKIP/EFS on our Solaris boxes, thou with static IPs. Soon to use winskip on laptops via dhcp)

    You could be real anal, and lock the basic install down. Dont want these 2500 boxes to be someones DoS jump point.
    It also depends on what these 2500 computers are doing, Call Center, Trouble shooting NOC, Workstations...
    Each has it own own little problems that need tweaks..

    One of my jobs, I ran the helpdesk for a 500+ call/dispatch center. Adminstration was quite easy. Everyone ran Xterm's with menu driven apps.
    The largest amount of works for techs was repair the hardware or file systems.
    I only had to fix some print que's, basic unix administration. Then read /. and surf pr0n. ;)

    Man O man, to be an SA again. :)

    -IronWolve

  • Have you considered KDE? I know it's a desktop environment, but its office suite is (in my opinion) nicer than Wordperfect, or Star Office (I haven't tried Applixware). WP and Star Office eat a lot of resources on their own...I suspect this is because they first Windows apps, that have been ported over to Linux (I could be very wrong on this, but that's how they seem). KDE's Koffice is still in development, but what they have so far is very impressive. In addition, KDE has a very polished user interface...and once it hits 2.0 it should be quite stable, and be quite feature-rich. The stable version is quite solid.

    As for distro, RedHat is easy to install, but Debian seems to be more complete, and the packages work! It is definately easier to upgrade. It will take more digging, and learning on the installer's side, but it should install easily over many machines once you've got it set up for replication.

    Debian is refusing to distribute KDE over licensing issues, and this situation is likely to continue, but there's nothing to stop you from installing it yourself, and then propagating it out over your workstations. Try it out, and their Koffice and see what you think.

    I believe 64meg of RAM will be plenty for your needs. While KDE is a big system, it runs very quickly.
  • Given the submitter's email address, this is for lawyers and the like to use, right? IIRC, Wordperfect is used in the courts a lot more than Word, or so I've heard.

    --

  • I've heard others say this, but everyone seems to leave out exactly what they are doing over X.

    X is a nasty remote protocol - it's very verbose, and generates lots of traffic for any X-related function. Using one of the X-protocol compressor setups helps this quite a bit (it reduces GUI-related X overhead traffic by about 60%).

    Indeed, you can run many X-terminals over standard unswitched 10BaseT. But only if you're doing non-GUI-intensive apps. xterm, emacs, et al. Give the original post, I'm assuming that they are going to be running Netscape, Applix, WordPerfect, StarOffice, and stuff like Matlab. All generate lots and lots of GUI calls, which have to traverse the network. I think you'll find that 5 users writing a document in WorkPerfect generate more traffic than 20 users using Emacs to write the same document.

    X is just not scalable to allow everyone to run GUI-intensive apps remotely.

    -Erik

  • Best solution - IMAP4 with a web gateway. Thus you can access mail without the not-so-ubiquitous IMAP client and you get a nice centralized server.

  • There is another CYA plus to this method:

    If you need to, you can install the Citrix ICA Client on the terminals and/or have a product such as NCD Wincenter running on a Windows Terminal Server if some (or even all) users desperately must have one or more Windoze apps.

    We've had Wincenter + Terminal Server + X terminals here for four years, and most users are hard-pressed to tell that they aren't running Windows on their desks.

    Again, this is not quite what you're looking for, but it does provide a nice backdoor if it doesn't quite work out.

  • I'm just a user and no sys-expert, but at the university I'm at, until recently, the network I was on had at least 45 pure xterms over a 10 mbit network at it might not be great, but it's was OK. I don't know how many network cards the central hpux's had, but they were _definitely_ 10 mbit. Obviously, you want more than that, but I think I wouldn't worry too much if you're going to put only 25 machines over a 100 mbit connection onto your servers...

  • Re:Use Suse (Score:2)

    by Anonymous Coward
    Create a script to create the symlinks (as described in the parent response), and after installing/setting up your first machine, run this script on the other 2499 workstations, which would just replace the configuration files in /etc (and other places) with the files on your NFS / Samba / Coda / NIS based server. Then if you want to change something about your network, you make that change in one spot and save yourself from having to edit 2500 different configuration files.

    Also, use DHCP to assign your IP addresses -- don't try to manually manipulate 2500 different IP addresses, that would be a nightmare!

    As far as distros go, I would definitely think about Mandrake -- it's very easy to install, and even has the ability to save the disk partition map to a floppy. It's 10 times easier to install than any other distro, even Corel's, which has problems on some machines. Mandrake is RedHat based, but if you look at rpmfind.net, you'll see a very large shift in the direction of the updates -- Mandrake's always come out first, even before RedHats (like Xfree86 4.0.1, for instance).

    Also, I wouldn't make these machines available to the internet.. put them behind a single large server running IPCHAINS/NAT and give them all the 192.168.x.x local IP addresses. This keeps them safe and keeps you from worrying about outside cracks on any of those 2500 machines.

    KDE 1.1.2 is by far the easiest environment to use. Save yourself some help desk calls and use a minimalist KDE environment on your workstations. It's functionally similar to the Windows desktop, so the transition for your users should be fairly simple.

    Good luck, and please write another article to describe your experiences once you are done!

  • yep yep (Score:2)

    by mosch ( 204 )

    you can do something like this with redhat kickstart installs. Once you get them working (fairly trivial, though mkkickstart doesn't really work out of the box) you can install software with about two minutes of human interaction, and then a varying amount for the rest, depending on how many packages are getting installed. You can also add any custom RPMs to the list, so as long as you know how to roll an RPM you're golden.

    If you don't know how to roll an RPM then just check out www.rpm.org [rpm.org] which includes a lot of helpful reference material, including the slightly outdated but exceedingly thorough Maximum RPM available in Postscript [rpm.org] or LaTeX [rpm.org].


    ----------------------------
  • Basically, you put the script on a boot diskette and put the cdrom in the cd drive and off you go...

    This demonstrates the problem with Ask Slashdot questions like this -- small town mentality. Yes, the method described above will work, but it simply isn't practical in an enterprise environment. If you need to put a CD in each machine to install it, it's going to be a very long and tedious process. Of course, I don't see a reason why the kickstart method couldn't be used for a network install, too, but I've never tried it myself...

  • Comparing this to my approach (running apps on servers):

    Both:
    *) Communication is not encrypted, so the network must be physically secure if you want secure communications between workstations and servers. This should be considered.

    Your:
    *) Apps run locally, taking advantage of the processing power in each workstation. But resources available to one user are those of one workstation, no more.
    *) Each workstation must be powerfull enough to run the apps well
    *) Requires a somewhat secure way of sharing user information between workstations (NIS is out)
    *) A workstation is trusted - it is allowed to mount a filesystem, so NFS is out and Coda is in
    *) Printing must be set up for each workstation - maybe not a concern, it depends on printing policies.
    *) Upgrading applications should be automated, so that each workstation can be upgraded easily
    *) The network is used for file transfers

    Mine:
    *) Apps run on servers, taking better advantage of shared information (shared libraries and loaded executables). The load is balanced on the servers because of the multiple users, so one user can use more than his share of the resources, if they don't all do it at once.
    *) A workstation will only need to run the X server. If it can do more, we won't benefit from that.
    *) Communication between servers is physically secure, so you can use NIS
    *) Workstations are completely un-trusted. You can use the best performing technology to share filesystems between servers (PVFS/NFS/GFS)
    *) Printing is set up on the servers only.
    *) Upgrading applications is only a concern on the servers.
    *) The network is used for X communications

    Any thoughs Erik ?
  • Netscape can be killed, so it's not a big problem that it doesn't always die. It can be managed, as I've stated elsewhere.

    Besides, you will be running a multi-cpu server, and one spinning netscape process will only bog down one CPU. The system doesn't slow _that_ much down in such a configuration, and if the process is killed within the next five minutes by the aforementioned cron job, I think it will be an acceptable solution.

    I think you're guessing when it comes to the animated gifs. I'm _pretty_ sure that netscape will upload the images to the X server, and tell it to change the picture, not upload the new frame every time.

    But sure, X will load the network. Put the applications on the workstations, and Coda/AFS/PVFS/NFS/GFS/whatever will load the network instead.

    From my experience, X works extremely well even on a low-bandwidth high-latency line. Of course, if the network is *that* bad, users will notice, but all in all I wouldn't be so damn worried about X and network bandwidth. I don't think it's a problem compared to what you'll see with *file* transfers from running the apps locally on the workstations.
  • The risk is there of course, if you hack up a poor script, that you may once in a while kill a netscape process that shouldn't have been killed.

    If you consider
    *) CPU time spent (seconds)
    *) Process state (running or sleeping)
    *) Last 1-minute CPU time spent (percentage)
    and of course the UID (don't kill root's netscape ;) you can come up with a really good solution.

    And sure, once in a blue moon the script will fail. But hey, this is *netscape*, after all.

    You will spot which processes tend to get stuck over time, and add them to the script. Been there done that, and it works.

    Please, if you have a better approach tell me about it.
  • You want people to run netscape on the server for *exactly* the reasons you mention:

    It's memory hungry, but quite a lot of memory is spent on the (huge bloated) executable itself, and this will be shared between all users.

    Also, not everyone is running netscape all the time. So if you want 30 Megs for one netscape instance, you can probably do just fine with 10 Megs for each such instance on the server, and only half the users have a netscape active.

    Besides, Netscape uses the X server to hold images etc. so the 32 megs on the desktops will be put to good use still. But the _real_ bloat can be nicely kept on the server.

    Every five minutes or so, cron should run a small script to check for netscape processes that hog CPU (this would be a heuristic, but it can be done well - I know because I've done it). That way the server can kill dead netscape processes, and your users won't come back complaining about their workstation being slow everytime a local netscape process dies.
  • So I'm curious if maybe your old company were responsible.

    No. Our systems were only just starting to be deployed (however we had 2 or 3 contracts for 20,000 odd screens each that we had to fulfill). We had 20 or so in SE Asia and a heap spread around the USA - maybe 40 or so (I believe we had a demo box in Times Square, NY). All these boxes were running Linux so maybe you got the BSOD screen saver :). BTW, believe it or not, all the rendering software was written in Java. Worked surprisingly well too (decent performance when doing Video work etc).

  • The company I have just left ( RBuzz.com [rbuzz.com]) was in the process of rolling out approximately 50,000 linux boxes in an embedded style system. These machines were to be controllers for electronic display systems (Gas Plasma, video walls etc). We had similar restrictions - Althon 750s + 64MB per screen handled.

    For this the installers decided to go with Debian for the customisability (can strip to minimal feature set easily compared to RH and others) and easy upgrade capabilities for very large installations.

    As a personal workstation I prefer Mandrake over everything else. Have used RH (and a former Slackware devotee) at work for the development machines and decided to give Mandrake a burn on one of the home boxes. Much prefer the feel of the setup (even though it is sort of a recompiled RH). RH seems to install just about everything, even when trying to do minimal stuff, whereas madrake does everything nicely. As a bonus they compile everything with the pentium (-m586)options so if you have only pentiums and above then this should give that little extra boost in a small memory footprint environment.

    Footnote: The reason I left was that due to some political bullshit the VC people decided that they really wanted to use Windows boxes as the display hardware right at the last minute (ie a month before we'd finished the software development). So, if you are walking through a train station or shopping mall and the screen gets a BSOD - blame the fscking VC's that don't have a bloody clue. They destroyed an extremely profitable business model and wouldn't surprise me (and the rest of the developers that left) if the company now went broke within 6 months.

  • Keep program files local, data files global. With a package based distribution like Red Hat or Debian this shouldn't be a problem; just mount home directories over NFS, and find a tool (or write your own 5 line ssh-all script) to keep package installs consistent across all systems. And *only* do package installs; if there's a tarball you want to install (even a binary tarball), write your own spec file (or whatever the Debian equivalent is) for it and install it as a package. Sure, it makes the first install more of a pain, but by the 2400th install (or more importantly, the 2400th upgrade/uninstall) you'll be glad you did.

    Oh, I can't stress NFS/NIS enough. You could use LDAP or Kerberos (or NT domain, I think) based authentication with Linux, too, but NIS is the easiest to set up, and may not be as sexy as LDAP but is just as good. Also, I'd suggest using autofs for all the NFS mounts. And splurge on the servers; NFS/NIS will make your desktops trivial to swap/repair without interrupting work if something goes wrong, but you want 99.999% uptime on the servers.

    I don't like Caldera. To be fair, I haven't used it since 1998 or so; it may have improved.

    NFS is a fine filesystem, by the way, as long as you have root on all the machines using it and don't have to worry about packet sniffers in between those machines.

    Make sure you've got 10/100 NICs in all the machines. The cards aren't more expensive than plain 10baseT, really, and the hub prices are dropping quickly enough that if you don't start with a 100baseT network you'll want one soon. You'll definitely want 100baseT connections to the servers from the start.

    32MB should be fine for WindowMaker (although you'll want lots of swap with an office suite and Netscape running); 64MB (still with 64+MB swap) would probably be perfect with any desktop. I've got 128MB on my home machine, but that's cause if I close Netscape I want it to reopen entirely from disk cache. ;-)

    Why pick your users' desktop? It's not like you're going to have 1GB drives on the clients, so install 'em all, set whatever you prefer as the display manager default option, and make sure the desktops boot to kdm or gdm.

    I assume you're worried about security? I would turn off most network services (on Linux boxes in front of the firewall at my work, there are no UDP ports and only the ssh TCP port open); you won't need them on clients, but most distros will default with them on anyway. Also, make sure you have the BIOS set to boot only from HDD, a BIOS administrator password, a LILO restricted password, and go-rw permissions on lilo.conf. It's shocking how few people do this; I'd say 99+% of Linux computers in the world let you get root with no password by simply rebooting.
  • check out redhat's kickstart. look into ldap or nis. with pam ldap might work for auths. look into mounting /home off a server - that way you can log into any workstation and get your desktop. someone said to avoid nfs, but i've used it with success quite well. avoid smb though because smbmount is not well liked by either linux kernel or samba folks. coda could be nice but i'm not sure where it's at.
  • If you really wanted to, you _could_ run diskless X terminals. That would make system administration really easy. And, those who really do need their own computer (not sure why), could have one, and just run an X server on it. If your requirements allow it, it is an excellent choice. See

    http://www.ltsp.org/
    http://www.solucorp.qc.ca/xterminals/

    for more details.

  • You can make kickstart work over NFS. The problem is updating each machine automatically. For that you can use autorpm.
  • Here is the idea.

    Have your own apt server, and have each desktop regularly fetch updates from it. Then when you want to roll out a new update, all you need to do is test it, put it on the apt server, and all of the desktops that are using it will update themselves.

    This is very convenient for getting rid of any need to visit individual desktops to figure out who is using what custom packages. If they are using it, it gets updated. If they are not, it ignores the update.

    :-)

    Cheers,
    Ben
  • When someone's job involves accessing mainframe data on a terminal emulator and dashing off brief e-mails and faxes, you do not want that person to use a word processor in the course of their work. A word processor, with its font choices, advanced formatting tools and endless options is a huge productivity drain when it's used for short notes and memos, just as pick-and-pack staff in a warehouse shouldn't have a spreadhseet or presentation package available on shop-floor terminals, but the warehouse managers should.

  • Everyone seems to be taking a different view from what I had in mind when I said:

    First off, you don't want any data locally. That's right. I don't care who has the workstation, the only thing sitting on the local disk should be the OS. All user files, and major applications should be sitting on a remote filesystem.

    Obviously, this means I wasn't clear in my wording, since everyone seems to miss what my intention was.

    I'm not in favor of remote execution of applications. For reasons I stated later, running X over a LAN isn't a scalable choice.

    Rather, what I was trying to suggest was this: only the OS should be stored on the workstations' local disks, while all applications should be stored on a remotely-mounted network file system. Such apps directories would be mounted on the workstation, then the apps in them run locally.

    I don't care how slick apt-get or rsync or rdist setups you can make. It's still far more complicated than having all commonly-used applications stored on a central file server. It's then much easier to do upgrades, and also much simpler to make multiple versions of the same app available (this is extraordinarily difficult (and/or clunky) to do locally).

    I hope I'm a bit clearer this time.

    Thanks for the feedback, folks!

    -Erik

  • its only 80 machines, but im doing desktop
    for 5000 students here. the distribution does not matter much, since realy want your own install
    mechanism for roll outs.

    the easiest, pre-packaged way is useing drive
    image, a tool designed for yust that. if there is
    also windows on these machines, you realy want
    this.

    but if its only linux you can create your own
    auto install process.

    many networkc cards like the 3c905C have a network boot rom, but you can also work with a boot disk.

    the install mechanism can be very simple:
    boot a kernel with the necessary drivers, get ip via dhcp, filesystem via nfs-root, partition the hard disk, create filesystems + swap, put your "image" (can be a tar ball) of the software you want on the hard disk, change some things like hostname, install the bootloader, done.

    manageing hostnames could be done via a small
    cleint/server system: some server gives out the hostnames, the clients aquires one from this cental resource. its realy easy to do this with
    a cgi script and GET or wget, its scriptable.

    if your hardware is not all the same, you can detect some stuff by parsing the kernel log
    from the boot process. lspci (and some grep commands) is a big help with pci cards, e.g. vga.

    building a base system to install on all machines
    is "easy": install your favorite distributions
    and the software you want, and tune everything till you are sattisfied. then build a tar.gz of everythign and put it on the server. grab the partition table with sfdisk -d (sfdisk can use this output to create the same partition table on a different system), and you are fine.

    you could also install some hooks in the image,
    that will run at the next boot, and delete themself. these hooks can fire up X11 and ask
    stuff like hostname, dhcp/manual ip, and all this.
    gtk/perl/glade is a big help, or tcl/tk or whatever you use.

    a roll out, a mere installation of everything is very very easy. the mechanisms are widespread known for more than 10 years, and they do not differ very much from a windows rollout.

    but realy hard is the maintaince. software updates on linux dont go that easy. you cant use the distribution mechanisms, sind the might fuck up
    (like some debian packages asking for [ENTER]).
    i found a big friend in rsync. so, the software update/installation side needs some work, most important if you have lots of different combinations of software on the machines.

    its getting harder with the hardware: after some time hardware will fail, and people will replace it with different hardware. all the distriibutions know how to do autodetection for installation, but there is no tool to do it everytime the machine boots. you dont want someone to edit some config file, because a serial mouse was replaced with a
    ps2 one.

    but the hardest part is a good configuration for lots of users, if they have different backgrounds.
    sure you can use skell like mechanisms, but face it: they suck, they are very ugly hacks. but lots of applications dont have good config files in /etc, and somethings like a "group config file" is not known to most applications.

    it would be realy nice to have some windows features for people who want them, like hardware detection at boot time, or a "run this the next time linux boots, but only once" mechanism,
    or some automatic configuration of IPsec
    (like the windows "add to domain"), and lots
    of other stuff.

    i looked at bit at some windows software, where the user can pick the software he wants, and gets
    it installed. if there are updates, they are listed, and installed when he wants them. admins
    can create and configure these software packages
    and updates and can put a lot of magic in it.
    and it all works, without the user having
    (root|administrator) rights. linux could need some of this stuff for big desktop users.
  • 2500 workstations is quite a load but in terms of TCO you'll be a little more pleased with Linux than with Windows. I hope all your machines are pretty similar, installing on many different system configurations is a bitch. For every hardware configuration set up a reference box that you can set up and configure until things work, once thats done export the config files and compiled binaries to an NFS server and have a cron job get the files off the server every night (or whenever you feel is prudent) that way everyone is always up to date. A good business distro is SuSE's Office Suite. It comes with SuSE 6.3 and a full version of Applix Office as well as several other good office apps. SuSE is a rather easy distro to install and keep updates due to YaST, it's also got default security measures (no remote root logins permitted by default). It's hard to impress that you need way more than 32 megs of ram for Linux. Having only 32 megs might work decently but for real speed on the boxes upgrade to 64 or 96 with your swap set to 192 or 256 megs. This will give you plenty of room to work and to run large projects, especially if any of the boxes are going to be used for graphics. Think centralization:

    1. Standardize hardware so you can have a reference box the admins can work with and then duplicate the settings on the server for download.

    2. Set up an NFS server to store the user's personal files with a cron job on each client sending to a particular server so you've always have online backups of user data.

    3. For security on the workstations disable everything except needed remote access permissions and services. Let users log into the main server to get personal files using FTP or HTTP rather than their personal box at the office.

    4. Set up an office wide intranet with lots of online help files and HOWTOs, make your admins rewrite or write HOWTOs that pertain to the hardware and software you're going to use. Being able to fire up netscape to get help rather than call the IT department will save everyone a few headaches.

    For actual software on the workstations you ought to probably use the most stable version of XFree you can get away with, 3.3.6 and 4.0.1 are both pretty stable although 3.3.6 is a bit more documented and security related bugs are documented a bit more. Use IceWM instead of a fancy shmancy one, its both stable and fast. You don't need a bunch of extra stuff in the background. I personally feel that GNOME makes the most efficient use of the space on your screen but KDE works just as well. If you really want to be hardcore, load up KDE's widget libraries (or GNOME's if you're using KDE) so you have better range of choices for graphical apps. Applix Office 4.x is a very good suite that has the best file compatibility I've seen. I hope that helps a bit.
  • It all depends what you're running in terms of apps and desktops. Remember that for each X server you run X is starting up another process (in 3.x and lower). If each one of your users is running E and GNOME you're going to need a hell of a fast system with alot of RAM serving those clients. You also need a beefy network, 10Mbps for five client machines would be crazy. The key to making many things run at once well is to have a huge amount of RAM, about 64 megs per client if you're running X and such.
  • You can grab some Snap! servers from quantum to make a bunch of diskless clients, the only problem is that is very slow even with a switched network. You also run into problems is a large number (even if you've got small segments) of people try to access the same thing or all write files at once unless of course you have NFS servers with >256 megs of RAM and you cache everything into RAM rather than write it to disk.
  • VNC is a cheap knockoff of XDMCP. XDMCP is a much more robust remote graphical login system. VNC is nice for Windows machines but isn't needed if you run X. If you want to run Windows for anything spend a few bucks to get a copy of VMWare. Subnetting though is a very good idea, it allows you to easily administer networks and allow for access restrictions based on addresses.
  • I meant a standard box to use as a reference system. That way the admins can configure a single system and just ghost the hard drive onto all the machines in the lab or office.
  • XDMCP is how you get a networked X server to display the screen or a remote X client box. I have XDM running on my Linux box and connect to it using XDMCP with any other box on my network with an X server and use GNOME and all my other goodies. VNC lets you view and control the GUI of remote boxes, XDMCP lets you USE the GUI of remote boxes. VNCserver is a waste of time to use with Linux because you can use X's native networking ability to do exactly the same way. X has been working over the network since it started. VNCserver on a Windows box on the otherhand has it's benefits because it allows you to remotely use a Windows machine which is generally not an option unless you've got Windows NT Terminal Server.
  • I'd actually recommend StartOffice 5.2 over Word Perfect. In the event that your users need to deal with Microsoft Office files StartOffice does a better job with word files. It is bulkier though and you'd need the 64Meg of RAM.

    As far as debian, caldera, or redhat goes, it depends on your admins. All have package management, and rpm vs dpkg could be debaited till the univers collapses and the truth is it depends on what you prefer. I personally found installing debian to be tough cause the last version I tried did the dependency checking at each step where redhat does it after you select the packages. At least that was my experience. 64 Meg of RAM is plenty for Linux boxes.

    alien will convert packages between the two systems, and gnorpm and kpackage will handle rpms and kpackage also handles debs as well.

    My personal feeling on teh deb vs RH debate is that many companies look at RH because there is a company behind it where debian there is not. Yes there is storm and corel which are based on debian, but if you look at the different software ports that are done to Linux many large companies go with RH first. Just look at IBM. IBM released there via voice technology for Linux (you can buy the software for 59.95 or so) and they recommend RH 6.0 or later.

    Others may feel different and they can, but this is my opinion and experience. Incidentally I have been enjoying RH since I first tried 5.1

    send flames > /dev/null

  • I use StarOffice. I could afford Windows and MS-Office. I don't like Windows, I don't like MS-Office, I don't want Windows, I don't want MS-Office.

    I do like Word Perfect a little better than the word processor in StarOffice, but StarOffice is more than usable.

    At any rate, how many people actually use more than 10% of the features in their office suite? The argument that you have to pick the absolutely most feature bloated office suite just doesn't make much sense when you consider that most people won't ever need half of it.

    Most people could get everything done they need to using something as spartan as Applixware... Maybe faster, since they wouldn't be tempted to twiddle with as many frills or have to wade through so much extraneous junk.

  • I haven't looked into it yet, but Red Hat offers kickstart (which as far as I know is similar in function to Jumpstart from Solaris). You might make your life easier by installing one box manually and kickstarting the rest from it's profile.


    Regards,

  • Certainly if you have a fast LAN/WAN infrastructure, then X terminals could really solve the "only 64Mb" per client for your memory intensive applications.

    There are even utilities that allow you to load-balance over a cluster of servers. Say a cluster of 10x128Mb servers with process load balancing enabled. Running xclients remotely will mean that you can probably get away with most clients stuck to 32Mb and some swap.

    As it seems you already have the workstations there I can't see any reason to remove the harddisks - By runnning the X servers locally you will save what might be valuable network bandwidth for the applications.

    Wow! Seems really interesting project. I have to say however that I'm not a "Linux on the Desktop" advocate yet... sure - I run it on my workstation, but I like ordinary users to use what they already know.
  • Maybe you want to look at imap servers like Cyrus.

  • For a rollout of that size, I'd say that you need two key things: first, either a network or CDR-based install from a cut-down release tailored to your business environment, with all options pre-selected

    I think that Red Hat Kickstart [redhat.com] is exactly that. It lets you script the answers to all the questions and choices in the installer and perform a fully automated install. Basically, you put the script on a boot diskette and put the cdrom in the cd drive and off you go...

  • Agreed. My recent frustration is that I am one of these technical users, trying to convert myself to a business user. I have always administered my own machine and knew everything that was on it. I enjoyed it.

    Now, I'm more into development and integration and my time isn't worth doing administrative level tasks. So, I fall behind in knowledge, but still think I can fix things, usually just making it worse. Add to that that my workstation is running *shudder* NT and I have always had Linux on my workstation. I'm trying to learn to trust the support group to solve my problems and get my real work done instead of spending hours breaking my workstation.

    It sucks because I feel like those jerky kids in the support group know something that I don't. Oh, well. I'm getting paid more than them.


  • First off, you don't want any data locally. That's right. I don't care who has the workstation, the only thing sitting on the local disk should be the OS. All user files, and major applications should be sitting on a remote filesystem.

    This is both totally correct and totally, utterly wrong, because you forgot the most important part of making this work, which is caching. X-terminals and diskless workstations were tried for a while, and they sucked. They sucked because they were slow, and they were slow because getting their data off the server. That hasn't changed, either. Available bandwidth has increased, but so has appetite for bandwidth. The solution now, as it has always been, is to cache at the clients for performance, which means that the clients should and will have data - just not authoritative copies of data.


    The problem is that, to make this work, you need to use a protocol that maintains all the semantics of local file access, most inportantly cache coherency but also things like locking. This is hard to do efficiently, especially when you have to consider things like recovery and failover, and so you don't often see it done well (or at all). NFS just punted on cache coherency, which is why everyone but a few people who've made careers out of implementing NFS agree that NFS blows chunks. AFS/DFS/Coda were at least designed to do this stuff right, but IMO - I'm a distributed and shared-storage FS designer/implementer - don't do it as well as they should and have suffered acceptance problems because of second-order technical (and some non-technical) issues. Sprite at Berkeley and Plan9 at AT&T have shown that this kind of thing can be done, but it has yet to be done in the context of a commodity OS. Some might argue that it can't be done in such a context, but I disagree. It is in fact one of my goals to create just such a filesystem...if I can ever convince an employer to let me, or find the means to do it on my own.


  • Hmmm, I think were on the same track here then. I'm on Debian unstable right now, and thats where my caution about excessive upgrades really comes from. After a while one is just making sure to get every bug going through...
  • every box could nightly do a 'apt-get upgrade'

    Um, thats silly... Imagine this scenerio: a package breaks networking. Oh sh*t! You have to fix 2500 machines manually and delete your inbox.

    They would have to try any new packages on a trial configuration, and wouldn't want to risk upgrading more than once a month

    I know Debian stable is really good, but any sysadmin with that much responsibility has to apply due diligence

  • Debain has all sorts of sexy tools for this kind of thing in thier distro. dpkg-repack can repack an installed system into a distribution cd that installs exactly that system. Debian can be a little more work for one system but you can automate your whole show with the tools provided... thats worth it.

    Look here [debian.org].


  • $300 * 2500 = $750,000

    Yeah, I would really use Windows 2000 here, with the expensive support contracts, tendancy for users to save their files unsafely on the local machines, etc. Linux, or FreeBSD even, will allow the sysadmin to tightly control what can be done on each machine, and all the users will save automatically to a backed-up server all the time, without knowing it. Add on the cost for a few Win2000 Servers, and licenses for Windows Terminal Servers, and more, and you could be doubling the cost, for no appreciable reason.

    Each machine will be stripped down, FreeBSD is great for this, and I am surprised that no-one has mentioned it! Install only what you need, and it runs great on 32Mb. Try out the different window managers on the users, although Window Maker should be good enough - make sure that the WordPerfect icon is on the right hand side! Lawyers use WordPerfect, so use WordPerfect Office, the only real cost to the system, and still cheaper than 2,500 user license for Office 2000.

    I assume most machines are different in configuration in some way, so the disk image system isn't going to work too well, unless you can easily classify machines into large groups with the same config. Tie down the security, obviously, and make sure that printing will work fine, and you should be set.

    Make sure that there are some decent fonts on the systems. Most Unixes still don't know what a font is barely, so Freetype or xfstt are a necessity.

    Also install some desktop games! Sokoban and Mahjong would be good (more intellectual), as opposed to Solitaire and Minesweeper (for middle managers) :-)

  • I have to take exception to applications on central servers. As you point out yourself - you'll be able to run 1-2 IF you have local app servers serving just 25 workstations.

    It's sounds tempting - put everything on servers, it's much easier to maintain. It's true - from the admin point of view, having everything on the server is much easier. It's also much easier from that point of view to lie down and go sleepytime and forget about the users....

    Problems with central apps:
    Software needs unique to small groups - they are often left out in the cold. typically, fighting starts about putting special need apps on the central servers. End result - they can't do their work.

    And, network delays - as has already been pointed out, employees will sit staring at useless screens waiting for stuff to happen.

    Given good cloning/replication/remote admin, you shouldn't need to put apps on a central server just so going from version 2.5 to 2.6 is easier. You ought to be able to set up a script that remotely updates the necessary applications across many workstations.

    Don't ask me how though - I'm just a "user". :-)

  • That's why you change the default server to one on your own network, rather than the official Debian apt-server. You look over the new stable packages on a trial system first, and if you like them, toss it into your local, private repository for everyone else to pull down during their nightly upgrades.

    That said, Debian stable is really darn stable... And the apt tools make maintenance trivial.

    Ray
    --
  • Two things:
    • I'd like to see you remotely flip a powerswitch, replace a hard disk, or do recabling.
    • NT certainly has the ability to do remote adminning. It can even display the console on a remote machine.

    -- Abigail

  • webmail

    But you don't want to ruin your cooperate image by sending out the drek that Netscape and MSIE produce.

    central point for scanning for viruses ect.

    That's why you have a global incoming mail server.

    central point for security.

    Ditto. Besides, you do have firewalls, don't you?

    less support needed instead of having to run around to each machine to fix things all the time you have

    Which you also achieve with a global mail server. Of course, you will still have clients. Even web based email needs a client. (But you one install one client, on your NFS or AFS, right?)

    one point to manage

    Those are features of a central mail server, and a shared filesystem. Not of web based mail.

    ease of adding and removing users

    And that is complicated otherwise because of what exactly?

    Users like the ability to bring up an email on another machine when they are working in a group setting.

    IMAP and even POP will do that too.

    -- Abigail

  • This is less about Linux, and more about how to
    roll out 2500 secure Linux boxes (or any other OS) at the same time.

    Norton Ghost [pcanywheregroup.com] (Originally writen by Binary Research, a Canadian company) is a pretty sweet piece of software that will let you "clone" a disk partition, even over a network to multiple clients simultaneously using IP multicast. This means you can set up Linux on one workstation, install all your software and security patches, link up all 2500 machines by network, insert a Ghost boot disk in the other 2499 machines, then copy your complete installation - software and all - to all 2500 machines at once.
  • First off, you don't want any data locally. That's right. I don't care who has the workstation, the only thing sitting on the local disk should be the OS. All user files, and major applications should be sitting on a remote filesystem. Otherwise, you end up with a completely intractible backup and upgrade problem. Trust me on this.

    If you are actually using machines designed as workstations (thin clients), I agree. But if you are using PCs, then isn't this a huge waste of the processor power, hard drive capacity, etc.. of a desktop. I'm a user not an administrator, so of course my main concern is that is that I have the apps I need to get my work done. This means that I don't want to wait on a slow network while I'm using an app. I also don't want to sit and stare at a useless pile of parts if the network is down (this has happended quite a bit where I work).

    I realize that having apps installed on 2500 hardrives might be a nightmare, but you shouldn't lose sight of why you have those apps in the first place. Those apps are there to support the needs of the end user, not to make the admin's job easier. After all, that's why you get paid the big bucks right? :)

    Is there a way to remotely manage apps on the hard drives, if not maybe there should be. How about remote power on. I mean as long as those PCs are turned on, you should have remote access to their hard drives and you shouldn't have to go around and turn on every one manually. Actually, I think this would be a great idea anyway. I'd love for my computer to be on and ready to go when I walk in at 8:10, er I mean 8:00. But then again, if your network never goes down, and those apps will run from the server as fast as they would run from a desktop, then sure, I agree, buy thin clients and put everything on the server. But if you work were I do, that's the last thing you want.


    ----------
    AbiWord [abisource.com]: The BEST opensource word processor

  • I have done this (on 40 machines, not 2500, but WTH) with Mandrake 7.0. I'm not sure about the distro (it fit our needs, yours might be different) but I installed one distro, created an "exclude file" containing things like /tmp, /var/log/* etc which are never touched and then used rsync to clone the machines.

    Whenever I change something on the "master client" I fire up a script I wrote to rsync all the other machines. For 40 machines, this takes about 2min per machine (unloaded 100MBit network).

    So:

    • Pick your distro of choice
    • Get to know the configuration things (this is probably easiest with Debian, as they use raw /etc maintenance anyway) and create your exclude file
    • Use five or something hosts to get rsync parameters right (I use rsync -vae ssh --exclude-from=$exfile / $IP:/)
    • Do a couple updates and try them out
    This works perfectly for us. We haven't tried a distro upgrade though. and of course it only works if all machines have at least SIMILAR hardware, and should be installed identically.

    I have begun to document this at www.linuxfaq.de [linuxfaq.de] (German, though). Please tell us what you decide to do.

    Have fun! :)

  • Corel Linux, at the moment at least, is a castrated version of Debian. For example, Corel (at least on my free copy) runs a special version of KDE. That's too big for this kind of thing. It has a really, really, really cruddy library setup, so trying to compile anything comes out with messages such as "missing libc" or whatever, even when I can see the files in the directories in the libpath.

    Easy to install? You can't select singular packages, it installs LILO to the MBR whether you want it or not (I don't - I dualboot already, using XOSL [xosl.org] and LILO in the root partition), and it's slow as hell. Oh, and only the paid-for version has WordPerfect 8 with it, and there's not much other software (not even a complete KDE) with it either.

    Why has no-one suggested Mandrake? It's got the fastest RPM-based installation I've seen (and RPM has some nasty inherent timings after it's finished installing files), it allows singular package selection, it's got StarOffice (which is better), it's based on a version of Redhat and so has all the utilities you've come to know, and is supplied with Blackbox, my favourite WM. Small, takes up almost no memory whatsoever, and exquisitely stylish, especially in the blue mode. (SuSE supplies an outdated version - watch for this.) Also, it supplies network install, which is a plus, and can be installed very small.

    --------------------
    This message is not written by an employee of any Linux distribution firm, which is obvious as, at the moment, I am on a student footing.
  • Very little of the memory used by netscape is used by the binary - it is mostly data, pixmaps etc. Trust me, running netscape on a shared server is a bad idea. Environments I've been working in typically allows you to run most programs but netscape on the server - memory is one issue, CPU is another (netscape doesn't always die when you want it to) - and confining netscape to the desktops is by far the safest way. Also, animated gifs (I hate them, but they are present) can present a strain on the network.
  • You can do almost the same thing as ghost by imaging your 'master' workstation using 'dd', and running a 'netcat' (nc) server somewhere with the raw dd'ed image on it. Then you make a boot floppy that just runs nc connecting to the server and dumps the output directly to dd.

    Disadvantage: requires a modicum of shell scripting knowledge.

    Advantage: free.

  • If you go with a full linux desktop but find some "must have app" that only runs on Windows, then definitely consider a Windows Terminal Server with Metaframe to serve just those apps.

    This lets you keep the coolness and control of having linux on the desktop but lets you run a "thin client" to a Windows machine to run all your windows only apps. It can also be the thing that keeps the Pointy Haired Boss from deep-sixing your linux project because of some particular app.

    The client protocol is also very bandwidth-lean and depending on the app you can get 40-60 users on a dual proc PIII-800 WTS machine. The licensing for a Windows Terminal Server is nightmarish but it might be the only solution to some real business problems .

  • How powerful are your servers though? Granted, it's extremely unlikely that everyone on the campus will be using 100% of their allotted CPU time at once. But when you're building a campus of 2500 users, how do you know what is enough processing power so that users don't get miffed when Netscape takes 2 minutes to load instead of 30 seconds?

    This is an honest question, I'd like to know. I'm a big fan of the client-server approach... However, till now my only experience has been with a very underpowered SGI/Irix server serving way too many dumb terminals and a Sunray lab designed for 30 stations but with only a few concurrent users. Two extremes.

    --

  • Other people have pretty good comments about what you should do. However, no-one has really commented about what WM to use.

    I'd suggest using IceWM [sourceforge.net]. It's FAST, only requires about 1.5MB (my current usage is 1.3MB) and by default it looks and feels like Windows. You're switching from Win, right? Using a WM that looks and feels the same helps a lot. And with only 32/64 megs, you'll want something that doesn't use half of if just to give you pretty icons.

  • ...you're already on the wrong track.

    I strongly suggest you get a Unix/Linux consultant (perhaps from SCO) to come in and write something up, or even better, hire a good Unix/Linux admin.

    That being said, I'd go with RedHat, since it's pretty well supported and has a large presence on the web for QA sessions.

    I'm rolling out about 300 desktops "soon". I'd love to do it with my preferred destop -- HelixCode's gnome and debian -- but the install is just a little over the top.

    try replacing Enlightenment with Sawmill/Sawfish.

    32 MB. might not be too good if you plan on running any real apps.
  • Well, granted RH6.1 did have some pretty annoying bugs, the kickstart did work. RedHat rewrote big chunks of the installer in Python starting with 6.0, and they didn't get everything implemented correctly. It did work mostly though.

    I've been using kickstart+DHCP+NFS since RH5.2 and, despite its annoyances, it sure beats the hell out of the Slackware "jumpstart" we hacked togeather here.

    RH6.2 fixed a lot of little bugs, so I'd give it a try again.

    As far as a validator goes, I'm not sure exactly what you mean, but the RedHat installer does provide *A LOT* of debugging output on virtual consoles 2, 3, 4, and 5. Also, once this install gets on its way, a shell is opened up on VC2. That's all I've ever needed.

    And the post installation hooks are very powerful. I won't go into that here, but if you'd like to see what we've done here at the Computer Science Department at the University of Minnesota, send me an e-mail.
  • Yes, I've used kickstart since 5.2, and have been able to get it to work in all cases.

    Python errors are usually the result of using the wrong boot disk. If you doing a network install you need to use the bootnet image, otherwise use the basic boot image.

    If you're getting any other Python errors, there's probably something wrong in your kicstart config file. Otherwise, maybe you have actually stumbled upon a bug.

    I've only used Kickstart+DHCP+NFS installs. So I just put in the stock bootnet floppy, boot with "linux ks", the istaller goes off the the DHCP server to get the network config, brings up the NIC, mounts up the directory with all of our kickstart config files via NFS, reads the particular config file for that client, mounts up the distribution via NFS, and the install begins.

    There was a bug in 6.1 where the "next-server" option obtained from the DHCP server didn't work. This forced you to put the kickstart config files on the same server as the DHCP server. A minor annoyance, but it's been fixed in 6.2 now.

    As far as installing third-party software, there's nothing that says you can't do that with post-install scripts. We do, and it works great.
    Our post install scripts even install all of the updates.

    There's nothing wrong with compiling from source either. That's what /usr/local/ is for. You're not going to get everything you want from the distribution anyway. (e.g. ssh)

  • Define requirements better (Score:3)

    by hatless ( 8275 ) on Saturday July 15, 2000 @05:10AM (#931506)
    For an installation even one-tenth of this size, X terminals and big servers are the way to go. And no, the terminals don't need to be fast. We use P133s with 32MB just fine. Administering two, or even ten servers is a whole lot easier than administering 2500 independent workstations, even with the slickest use of NIS and NFS to pull off centralized configuration and management.

    How much document sharing will there be with organizations that use other (read: Microsoft or Corel) office software? For interoperability and the shallowest learning curve for MS Office users, Corel WordPerfect Office and StarOffice are the best choices. Both will read existing MS Office files well enough, and will export new files in that format well enough, too. Neither is up to the task of heavy back-and-forth collaboration with MS Office users, but that's true of any office suite on any platform. StarOffice can't deal with most WordPerfect Office files. This would be a non-issue under 98% of circumstances, as so little of the world really uses WordPerfect anymore. However, as a state court system, you're part of the 2%: WordPerfect still has a strong presence at law offices, so interview a representative sample of users and managers to find out whether they currently do receive a notable number of WordPerfect files via e-mail or on disk. Frankly, they probably don't, instead getting them via fax or in hardcopy. So it may well not be an issue.

    This answered and all other things being equal, I'd opt for StarOffice; Sun is in better financial shape these days than Corel, and bulky though StarOffice is, it's also natively written for Unix/Linux. It's also got more features that suit it for network and large-environment use. Both Corel and StarOffice are available in identical versions for Windows, so the laptop brigade can work seamlessly withe the terminal crowd.

    For another thing, many job functions don't require an office suite at all. Don't assume everyone needs one, and don't just reflexively give one out, even if it's free of license fees like StarOffice. If someone just sends simple faxes and email, that's all they should be able to do. If someone simply accesses an AS/400 or mainframe and works with e-mail, they need access to nothing more than a web browser for e-mail (or perhaps Netscape Communicator with its IMAP mail support), and a tn5250 emulator. For sending faxes, use email-to-fax and fax-to-email gateways. Hylafax is your friend. And incidentally, StarOffice has nice hooks for printing and "emailing" through networked Hylafax servers. It can also sync with Palm gizmos.

    For more complex environments, StarOffice has some further advantages. Enterprise-caliber support contracts are available, as are user and administration courses. Macros and scripts for it can be written in Javascript or in VBA. MS Office VBA scripts themselves won't work, but the skills some users and managers may have can be leveraged very easily. For another thing, it can be scripted with and interact with Java. So what? Ah, here's the nifty enterprise-caliber part: not only can StarOffice 5.2 access ODBC databases. It can also access any JDBC data source--which means pretty much any database on the planet, regardless of OS. In addition, you can take advantage of Java toolkits and SDKs for all sorts of things. For example, IBM has a toolkit for Java access for AS/400 client APIs. Want to add a menu item to StarOffice for retrieving data directly from a mainframe into a spreadsheet? Or linking calendar items (have I mentioned StarOffice's Outlook-like group calendaring?) dirtectly to AS/400 screens? You can. In ways that can be reused on other platforms and environments.

    What Linux distribution you use is the least important piece of this. Choose something that offers easy creation of kickstart disks, to ease installation on new machines, and that offers good, reliable security upgrades. Me, I'd go with something that offers decent commercial support contracts. The terminals won't need any such nonsense, but it sure is nice to know you can get an engineer on the phone if a $50,000 server has a memory leak you can't squash. There are several ways to do this: you can go with a Linux vendor that offers contracts, like RedHat, or with a hardware vendor that sells Linux OS support on its hardware, like an IBM or VA Linux. For this reason, Mandrake comes out weaker than RedHat. It's not about the quality of the default installer or the number of "extras" on the CD. It's about maintainability going forward and the quality of support you can buy for those times when Usenet and online documentation cost too much downtime.

    Depending on what you need in the way of file storage or backend applications, you may well want to look into a commercial Unix (say, Solaris, which runs StarOffice splendidly) on the backend. Linux is great, but if your needs really call for a SAN (and it doesn't sound like they do), or you want to go with one gigantic 24-CPU server instead of several 4-CPU ones, Linux may not cut it. Don't compromise your implementation for politics. Keep in mind that at this level, Linux is Unix is Unix, and that things like data and email and so forth can move fluidly between flavors without a moment's thought. Linux can certainly support 2500 users well; it can support tens of thousands of users well, as most large universities can tell you. There are also things it can do that something like Solaris can't, such as attach seamlessly to Windows file shares. But plan your applications and your network before you make the final OS decision, so the OS doesn't force compromises.

    And another nice thing about these Linux X terminals is their flexibility. Just need green-screen VT102/3270/5250 access in the mailroom? Can do. Need to mix in some Windows-only applications after all? Set up a Metaframe server and give the X terminals access to an ICA client. Want users to be able to save to floppy, or attach a barcode reader? You can. With no changes on the terminals themselves.

  • A matter of taste. Centralization. (Score:3)

    by Hanno ( 11981 ) on Saturday July 15, 2000 @02:36AM (#931507) Homepage
    On the question of distributions...

    I use Suse on the desktop and found it to be *very* practical. But mostly, the question "what distribution shall I use?" comes down to "that's a matter of taste".

    There are differences in their target audience, of course. Corel Linux is targeted mainly at beginners, while RedHat, Suse, Mandrake and Caldera try to be useful "for everyone" (they all can be installed and used by dummies but they all offer features for the pros, too). Debian is a little different because unlike the previous distributions, it doesn't offer automated configuration scripts. Again, it is solely a matter of taste if you like Suse's "yast" to mangle your configuration files for you (I do) or if you prefer to edit them by hand. Those people using Debian tell me that they are very happy with it (especially with its easy upgrade process and its security model).

    Installing on auto-pilot...

    BTW, if your machines are 2500 identical hardware setups, you could easily create one reference linux setup and copy the entire harddisk across the network, using a simple custom bootdisk and the "dd" command. Also, all distributions offer automated install features (ask their support about it) so that you just put in the CD and they auto-install your custom setup.

    Centralization...

    Reading from your requirement list, you may want to hire a Unix (semi-)professional for the setup. I mean, 2500 machines!

    There are a number of Unix features that can make life easier in such a situation, so it's good to have someone who knows how to setup things like that...

    Here are a few ways of centralizing things in the Unix world. Each step means a bit more centralization and means that the server must be more powerful and vice versa that the client doesn't have to be a powerful, fast machine anymore.

    - You can use a centralized NIS/YP server for the user and password administration, which will make life a lot easier for your admin. I have never done this myself, but I worked with such a setup at University and it was incredibly practical.

    - How about setting up a central file server for the user's home directories? If all user-related information is mounted via NFS, your workstations can easily be replaced and employees can easily move offices. Just login on someone else's machine and your personal files are right there.

    - Next, you could setup a central file server that contains all the application binaries. This makes updates easy and avoids the need to upgrade your workstations' harddisks.

    - And the final step would be to make all those machines pure X-Terminals that only run the X-Server and a local window manager, while the applications run on a central server. I don't know if this is for you, since this requires buying new powerful servers. On the other hand, since 32 MB is more than enough for an X-Terminal, you can avoid buying RAM for 2500 machines.

    Some more thoughts on memory...

    If you want all the applications to run locally, you should choose a minimalistic window manager (not KDE and not Gnome, both work with 32 MB, but ask for more) and Applixware. I have tried Applixware and it runs fine on a small machine, but I mostly use StarOffice now. StarOffice is a memory hog, though, so it isn't an alternative for you. (I have not tried Word Perfect, so I cannot judge about it.)

    Finally...

    Good luck for your project, but please expect a few weeks, possibly even months of time before everything works smoothly. The sheer size of your network is a true challenge.

    ------------------

  • Comment removed (Score:3)

    by account_deleted ( 4530225 ) on Saturday July 15, 2000 @08:32AM (#931508)
    Comment removed based on user account deletion

  • User Community? (Score:3)

    by garver ( 30881 ) on Saturday July 15, 2000 @02:23AM (#931509)

    The type of user community that you are supporting is very important. I am guessing at two different types of groups: operations and business users.

    1. Operations: These people run one or two applications and don't care about the computer underneath. The workstation might as well be an appliance. Linux is ready for this since it provides a stable, light platform and you don't run into compatibility issues.
    2. Business Users: These people run anything and everything and need to import files from other groups. In other words, compatibility is very important for this group. I don't think Linux is ready for this, and god bless you if you are trying it.

    As for Operations, here are my tips:

    1. Automate the install, completely. I think you will find plenty of support for this out there now. Either scripted network installs or blowing an image onto a hard disk. Worse case, you end up with a boot disk that runs a script to make the filesystems, mount a NFS image, copy the image locally, run a script to patch up local info (like IP address and hostname), run lilo, and reboot. Since everything is tangible in Linux (e.g. no stinking registry!), this shouldn't be too bad.
    2. Make all of the machines rubber stamps of each other. If one dies, you should be able to plop another down, power it on, log in the user, and they are home. To do this, make sure all of their non-transient data goes into their home directory. Anything that goes into /tmp better not be needed. This is one area that Linux sings in. It should be a no-brainer to make this happen.
    3. Come up with some sort of diagnostics test that you can run to help determine what part of a workstation is failing (e.g. memory, video, etc.). Otherwise, just lease the computers and let someone else fix the hardware.
    For Business Users, good luck. I would first worry about whether you can solve the compatibility issue. From there, try to do as much of the above as possible. Mobile users will make it more interesting. Keep a replicated copy of their home directory local and a boot option/script to pick Mobile/Office.

    Have fun.

  • Use the terminals as terminals (Score:4)

    by Oestergaard ( 3005 ) on Saturday July 15, 2000 @02:16AM (#931510) Homepage
    My suggestion: Leave the terminals with 32 meg, as that is plenty for the X server. Your standard terminal should have one single harddrive with a minimal installation of some distribution. You will want to have a standard way of setting up such a machine when a disk dies and gets replaced, but backups aren't needed (as there is no user data on the terminal) and you won't have to care much about updates either (as there should be no daemons running on the terminals).

    One big benefit: As the terminals do not hold data, it doesn't matter if they are stolen. Terminals are not trusted.

    The X protocol is made for networks, and a 10 MBit/s hose to each terminal would be just great. However, it's not encrypted, so you should at least consider how physically secure your network is, and what the requirements would be.

    Then set up one server for each N users. If they are doing web access and text editing, your average ``high end but not that high'' server should be able to run 15-40 users. Maybe more, but I haven't tried this type of workload myself so I can't say. Anyone ?

    You will end up with a server farm. Each server should hold a home filesystem locally, and preferrably the users with the homes on that local fs should log in on that server. You can choose to let the server export their home fs'es to the other servers as well and share user accounts with NIS, which would let any user log in anywhere. If a terminal is tied to a user and vice versa, there should be no need for a terminal to be able to choose other servers, but if they're not, then the need will be there.

    I've done a few such setups, but at a *much* smaller scale. I can tell you that it is a relief to _only_ have to update software on the server(s).

  • Large rollouts (Score:4)

    by Phill Hugo ( 22705 ) on Saturday July 15, 2000 @02:25AM (#931511) Homepage
    Back at University, we had a very hacked up Slackware distribution which did nothing special, expect on bootup where it would download and install any packages that sat on the upgrade server.

    The same principle is absolutely essential for anything more than 100 or so machines (even if upgrades aren't a priority, bug fixes and security fixes will be).

    In truth, I can't imagine any distribution would be better suited than any another here, especially if you are willing to write a boot up script which can download any new RPMs or DEBs and install them. The only problem is making sure they are not "interactively installed". Lots of Debian packages are but this is easily remedied. In fact, if you used Debian, adding apt-get update && apt-get dist-upgrade to your boot script and setting up your own packages repository (a simple FTP folder) would do that for you. You may need to tweak the odd package to force some settings but that's what your network of 5 machines reserved for testing are for right...

    I'd also go with Sawfish/Sawmill instead of Window Maker. While I'm a huge fan of WM, I think sawfish has a much more desktop friendly future ahead. It can also look pretty identical to WM, and some of the other themes are very practical for desktop use. Its memory footprint on my machine is just under 4MB with half of that as shared libs which lots of other programs are using. Perhaps a choice at login would be useful, especially if offered with something pretty like GDM.

    The major issue will probably be support, although that's more likely to be for specific applications than the whole system. I take it that to be entrusted to install 2500 desktops, you know your greps from your seds and are pretty capable of writing some scripts to manage upgrades. If not, find someone who is and pick their brains.

  • Re:I'll let others slug it out over desktop ideas. (Score:4)

    by Ramses0 ( 63476 ) on Saturday July 15, 2000 @06:38AM (#931512)

    Rather than bogging down the network with remote X apps, *please* investigate Debian's apt-get tool. In some ways, the Debian distribution is a 10,000+ distributed cluster of homogenous systems.

    For my home Debian box, all I have to do is run apt-get update; apt-get upgrade once a day, and then my system is homogenous with the official Debian distribution.

    If you put those two commands into your user's init scripts (probably with the --force option), then lock down the /etc/apt/sources.list, then...

    1. Your system is just as secure as any other unix system.
    2. You have a central point of software management (your local "debian mirror"), which you control completely.
    3. You can guarantee that anytime a user turns on a computer, it will be sync'ed with the master server. (or put it in a cron job if your expect computers to be left on. apt will happily run in the background, and update most things without intervention)
    4. Debian has been doing this for years under much weirder conditions, and dammit, it just works.

    The biggest disadvantage of using apt-get is that your network will probably get bogged down after you change a large package. The next morning, at 8am, when 1000 people turn on their computers, they'll all be trying to download the same package at the same time, which could be a mini nightmare. If you're a good sysadmin, you'll figure out a good way around it.

    The other big advantages:

    1. You can have different ~groups~ of systems-set your sources to ftp://workstations.packages.myplace.org/, then ftp://development.packages.myplace.org/
    2. You already have a great policy [debian.org] to work from, specifically about maintaining the central repository [debian.org]. Why reinvent the wheel?
    3. Debian software is guaranteed not to get you into licensing trouble. Pretty much every package in Debian meets the Debian Free Software Guidelines [debian.org], which is what the Open Source Definition is based on.
    4. Debian has an overwhelming support infrastructure. Nothing much commercial, but every package has a maintainer (who you can contact), and debian has a central bugtracking system, used to keep track of what bugs are found in which packages, and eventually send those patches back to the original package authors.

    If you don't need to roll out this installation tomorrow, I'd recommend that you install a copy of Debian (Debian 2.1 [debian.org] is stable, but out of date, Debian 2.2 [debian.org] is not quite released yet).

    Once you install Debian 2.1, hang out for a while talking to people on the irc channels (irc.debian.org), and get all your stuff configured, then run the command apt-get update; apt-get dist-upgrade, and your distribution will automatically be upgraded from 2.1 to 2.2 (hopefully with almost no user intervention).

    This message turned out to be a lot longer than I expected, but there's a lot to consider in your situation. Good luck!

    --Robert

  • debian + replicator! (Score:4)

    by raphinou ( 115574 ) on Saturday July 15, 2000 @01:27AM (#931513) Homepage
    Debian is easy to install and update through the network. And there is a package replicator available to replicate an machine installation through the network. It's really great. The replicator maintainer is also very responsive. I had lots of mail exchange with him and he helped me if I needed. got to http://www.ens-lyon.fr/~schaumat/replicator/ [ens-lyon.fr]

  • Tailored installation, user/system separation (Score:5)

    by Morgaine ( 4316 ) on Saturday July 15, 2000 @01:45AM (#931514)
    For a rollout of that size, I'd say that you need two key things: first, either a network or CDR-based install from a cut-down release tailored to your business environment, with all options pre-selected, and secondly, the seemingly trivial but massively important separation of system and user areas, each in their own filestore.

    The first is important because one of your major costs is going to be support --- this will skyrocket if you use standard distro CDs because they're all based on interactive user choice in varying degrees, and corporate handholding costs money.

    The second is important because without the separation, upgrading will become a nightmare over time --- again, this will increase your support costs. In fact, consider seriously the possibility of not holding any user data on the workstations at all, but on a central filestore instead. That simplifies data backup as well as workstation upgrading, because then you can regard workstation state as throwaway.

  • I'll let others slug it out over desktop ideas... (Score:5)

    by trims ( 10010 ) on Saturday July 15, 2000 @02:05AM (#931515) Homepage

    ... I'm a Sys/Net Architect, so guess where my biases are? :-)

    Anyway, what you have on the desktop matters (esp the mechanism you use for clone workstations (you are planning to clone workstations, right?)), but I'll concentrate on something else equally important, and which will affect how you set up the desktops: Network and Backend System Design

    First off, you don't want any data locally. That's right. I don't care who has the workstation, the only thing sitting on the local disk should be the OS. All user files, and major applications should be sitting on a remote filesystem. Otherwise, you end up with a completely intractible backup and upgrade problem. Trust me on this.

    As a correllary to the last statement, you don't want to use NFS as your file sharing method. Hell, even SMB would be better. You want to look at either AFS or Coda. I would recommend the latter, as it's nowhere near as nasty to set up.

    As part of Coda/AFS, you are going to have to think about how you design your file server setup. A central bank of servers is tempting, but this tends to be really harsh on the campus backbone, as it puts the workstation relatively "far" from the server, and all traffic has to traverse the backbone. Consider local file servers which may cache user data for replication back to the master server(s) later.

    Printing is also a bit of a problem. I heartily recommend the CUPS [cups.org] system talked about here [slashdot.org] a couple of days ago. Have all your workstations spool to dedicated print servers. They don't have to be powerful, but make them dedicated. You won't regret it.

    As far as security and other mishmash goes, do the usual /etc/inetd.conf edit, and comment EVERYTHING out. Don't run ANY daemons on the clients (other than what is absolutely necessary for Coda). Have all mail blindly forwarded to a central mail server. As a correllary, use IMAP (preferably IMAP-over-SSL) as your mail server. Stay away from local UNIX mail, and POP. And look at running postfix or exim instead of sendmail.

    You can think about using application servers (i.e. run X apps remotely) if you want, but realize that this will up the bandwidth requirement, and honestly, you probably can't run more than two dozen major X apps over a LAN before it bogs down completely. That is, you need a local app server with 100Mbit connections to about 25 machines so each can run 1 or 2 X apps remotely.

    If you can afford it, and have the time, use LDAP as your user info directory - avoid NIS and NIS+ (the first is horribly insecure, and the second is nasty).

    This is a first approximation of what you might do. If you want a serious proposal, I'm available nights and weekends (for a modest fee, of course... heehee)

    Good luck!

    -Erik

  • No Beowulf comment?!?! (Score:5)

    by blogan ( 84463 ) on Saturday July 15, 2000 @04:07AM (#931516)
    There's been about 80 posts already and not one refers to a Beowulf cluster. Come on! He has 2500 machines here. Keep on your toes!

Slashdot Top Deals

"The pyramid is opening!" "Which one?" "The one with the ever-widening hole in it!" -- The Firesign Theatre

Close