Slashdot Mirror
Converting Desktops to Thin Clients?
tfiedler asks: "I manage about 3500 desktop computers and was recently asked by my CIO to begin looking into thin client computing, something like WYSE terminals. I'd like to know, what are some good functional, and more importantly, manageable options to convert existing desktop computers into what would essentially be a Citrix terminal? I was thinking some brand of Linux that starts up an X11 session, starts the Citrix client and connects to our server farm. The user would see a Windows logon, our apps would function as normal and I'd get the benefit of performing a LOT LESS client-side maintenance. Any suggestions?"
Check out sunrays. They are dirt cheap and they now have a windows version of the software. I use them at home they are really that easy to setup. We run a windows and a linux sunray server here. 2 Servers that I upgrade every 2 years and then we have about 10 terminals scattered throughout the house. I'm on one right now actually. It's a simple solution and fairly cheap to deploy.
There exists some positive integer N that you are the Nth person to read this signature.
Even 20 years ago, we were using rdist on Solaris (or is it rsync?) to totally automate updating of clients, and then we were NFS mounting the home directories, so that they are on the server and backed up. So you get most of the benefits of local computing with local CPU etc, and the benefits of no client maintenance because it's all automated and the home directories are backed up. Why does Windows make it so hard?
Dave Richards, sysadmin for the City of Largo, Florida has been documenting some of his work with choosing and setting up thin-clients.
They have a server for each application (Firefox, OO.org, GNOME, etc) and use HP thin clients (set to be in use for 10 years), and manage to provide a great service, including all the new fancy XGL-like effects.You're may be looking for the Linux Terminal Server Project.
Trusted Computing FAQ | Free Dawit Isaak!
Here's a suggestion straight from the BOFH that might work though; Spin off a company to test the citrix rollout. After a couple of weeks of using citrix anyone who finds it acceptable gets moved to the new company. Then mismanage the new company into bankruptcy. You'll have gotten rid of most of the deadwood at your company and the citrix rollout will die the ignomious death it so richly deserves.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
We use this where I work.
Essentially we have little sub-1Ghz client boxes with 512MB RAM and no hard drive. They boot off ethernet via PXE, grabbing a kernel and then mounting the root filesystem etc via NFS.
Newer setups have the client files in a vserver (google util-vserv) which allows for some convenience in seperating the server's components and those for the clients.
Some apps run locally on the client's processor/RAM, while others are run remotely "ssh -X" with the GUI piped back.
I'm trying to setup something similar at home, with a server image that should allow friends to connect and use 'nix while at my house (for rounds of frozen bubble, or whatever). You could email me (form on my website) if you want more info.
Try PXES. I used it at a high school to netboot old desktops ( I think I used etherboot, with all nics embedded, so it didn't matter what nic was in the desktop), to download pxes, which would then connect to the X11 box to run all the applications. It features RDP, X11, NX, and others perhaps.Download here.
With the equipment available in this day and age, really thin computing where the desk local equipment does nothing but citrix/rdp/vnc/x forward from a server doing all the work doesn't usually make sense. As you say, doing all that stuff in a centralized way will be suboptimal and latencies annoying. You may be able to get the work done, but do not think for a minute your overall productivity and expense will go as you want them to.
The other end of the spectrum, everyone installing local applications and keeping most of their useful data offline on their disk all the time is also a nightmare in terms of maintenance and data reliability. You can address these, but at significant pain...
What I'd advocate is somewher in the middle. Essentially, disposable interchangeable workstations. Networking infrastructures can serve up filesystem access pretty well, and with the right set up, a client system's install can contain no data worth backing up. I.e. my home directory is nfs mounted on my workstation, and my mail and calendar stay on the imap/caldav servers. In my case, the workstation is linux and the company has an apt repo setup with all the important applications. The other day to test whether my setup allowed me to migrate freely, I got a different system, hooked it in, and within an hour I had my full setup on another system.
I don't have to endure the pain of high latency display nor do I put a huge memory/processing load at a place where the company has a hard time managing it, but at the same time my data does go right to a place they can easily manage and backup. The file access is slower a bit, but the company has a fairly beefy and robust setup that doesn't bother me too much.
XML is like violence. If it doesn't solve the problem, use more.
It's a lot easier and faster to repair one server than it is to reformat and clear a few thousand client machines. You think you would have done much if all of the client machines got infected with a worm?
I would suggest a hacksaw, a dremel, and some duct tape. Those should be able to make any desktop thinner.
What you're asking for is what the citrix-loaded WYSE terminals do automatically. You choose which model terminal (and which OS, they have both linux and windows based ones) and then set the level of local access (allow local apps, allow local USB drives, allow local streaming media, etc).
You then set up your citrix farm and away it goes. You can either have a full session, so that the user thinks they're using windows on a workstation, or you can have each app running 1 by 1 as the user launches them from the terminal.
Last I checked the terminals were about $200 each if you go with the linux ones since you skip having a windows license for the local box.
Thin clients are supposed to lessen the management of PCs. All apps would reside on a central location and depending on your implementation, either run on a beefy central server or on local machines. The problem with the former is that you have a very expensive central server that's usually completely inadequate for desktop applications. Now this may work for the subset of users that don't need the traditional desktop tools. But in this case it would likely be cheaper to web-enable those critical apps or look at some of the web application suites (I think Google just released one).
The problem with the latter (run on local machines) is that this is taking a PC and crippling its functionality. If your users' PCs are just glorified terminals then this is easy. If not you'll get all the cost of a PC and little of its benefits.
If your boss insists on thin clients there are a few things you can try:
1) Set up a fairly powerful server with vncserver instances with locked configurations.
2) If you're trying to reduce PC maintenance, try running applications from a central server. This works for almost 6 different applications that don't require local registry settings.
3) Take the PCs and throttle down the speed to 800MhZ to simulate running apps remotely. To be fair, only some apps will slowdown. These apps include those that require graphical output or user interaction.
4) Replace your network. RFB is chatty and puts a tremendous load on your network. Simulate it by running all NICs at 10Mbit/half.
A lot of problems associated with thin client computing have little to do with the computers and terminals themselves; if you ignore the fact that your dependancy on the network is going to be an important part of keeping your thin clients working properly, it will likely cause more problems than solve them.
Redundant switches and network cards in servers will help increase the available bandwidth and avoid leaving possible single points of failure. Also, if your budget allows, try to seperate the network the users access the servers on from the one that serves file shares, backups and administrator access. It will go a long way to improve the service available to users of the thin clients.
I rmeember trying this onea few years ago. Someone opened a worm infected email 10 minutes before the scheduled antivirus update at 9am. It only took that ten minutes to take down the entire head office of the organisation with thousands of desktops infected. Funnily enough in some places Linux boxes were used as routers on some gigabit networks. One of the techs told me afterwards that it was laggy connecting to the computers because the gigabit links were full of this worm attacking the entire network. My mates got home at 9pm that day after disinfecting the entire network. So yes, whilst in client-server if the server goes down you can't work, but its still easy to fix one server than thousands of desktops. Plus the one (or more) servers are typically in one location physically, which makes things that require physically rebooting the machine easier (keeping in mind that your network is now shot with computers trying to infect each other and the rest of the internet).
I always wondered where this setting was...
First warning... end users that these terminals are targeted towards typically HATE having to use a terminal like this where the software is served remotely. Unless if you have enough server bandwidth and they are local enough to be able to deliver the needed software at a speed similar to using it locally on a PC, you're going to be doing nothing but frustrating the end users. For people that really need to do the work, they want their software to run as quickly as possible so they can get their job done as quickly as possible. Running it remotely is only going to slow things down.
Second warning... if you're going to do something like this, PLEASE understand that each person has a different function that may require different software. You have to make sure that each person has the software required to do their job, and to do it well. If they don't have the required software, you have to make it an easy/seamless process to get that software. Nothing makes a job suck more than upgrading the local hardware only to find out that the software one needs to do the job has not been made available and they have to wait while IT figures out how to make it available to you over the coming weeks.
The company I work for (a major luxury car manufacturer) is trying something like this where we're basically running on dummy terminals, but they never bothered to find out what each of us really needs for our jobs. We've had these new terminals sitting around for months not getting touched because the basic software we need to run the warehouse (yes, I'm on the warehouse side of things) is either not available through that terminal, or once it is, it is EXTREMELY slow. You don't mention whether or not those 3500 PCs are in a single building or location or not. If not, serving software from a remote location is going to be extremely slow, and as I said, it will really frustrate the end users.
If it were me, here is what I'd do (note: I'm not an IT specialist at all, but I'm an end user with more computing experience than most in my company):
1) Don't do dummy terminals. Go with real PCs. The users will be much happier in the end if you do.
2) Do a survey. Survey EVERYONE. Find out what people use. People in a single department are LIKELY to use very similar software. Some may use one or two things more than others, but it will still give you a baseline. It's better to have someone with two extra programs installed that they don't use than have a user that doesn't have the software they require.
3) Build a series of disk images based on people's needs. These are your backups. If something needs to be seriously fixed or upgraded, do it on the disk image first. Then put it on a test PC. Let them try it. Let them give you feedback and let you know how it works for them. Make sure that everyone that is getting upgraded has a chance to mess with it.
4) You want do so some storage remotely? Give the users remote storage space, and stress to them that this is to be their primary storage. Save their files there. If possible, save their settings there. If you're going to be doing Windows, if I recall correctly, there is a key that can be changed to make any location the default "Save" location. Make it this remote "drive" or "directory" to help encourage saving to the remote storage. This way when there are software updates and a PC gets re-imaged, their files are safe. Along with this, you have to also make people aware of company policy regarding the software they have available to them and what they can use. Basically boil it down to this: If there's something they need to get your job done that the company hasn't licensed, then they need to work with the company to see about licensing it. Otherwise, each re-imaging is going to wipe it out because it's not sanctioned.
5) Image the PCs with those disk images according to your surveyed results.
This way you kinda-sorta have the best of both worlds. The users have software running locally on the PC a
*slight crashing sound*
As other people on here have said, this isn't a good idea. You're going to need to spend money on upgrading your network, buying new terminals when you already have perfectly good PCs, and you're going to need to build a server cluster to ensure that there is no down time. With 3500 users 5 nines isn't good enough, even a few minutes of down time is going to cost you $TEXAS.
You're much better off setting up some Unattended install scripts and then setting everybody to use a network share for their documents directory, a SAN or NAS would be fine for this. With the proper security settings and group policies you shouldn't be spending that much time on fixing desktops, unless you have a lot of hardware failures.
You also don't want to introduce a single point of failure, which is what running everything off a central server would do.
The last system I designed had 130 seats as Linux thin clients and I could tweak the whole system without leaving my chair in seconds. I had redundant servers ($1500 each) instead of redundant clients and it took only minutes a day to verify that everything was OK and it was for months. Not one incident of malware disrupting anything. The users migrated from needing a full time geek to re-install that other OS several times each year on each client to having machines as reliable as telephones.
A problem is an opportunity http://mrpogson.com
Here's what we've found so far:
We're actually doing pretty well with this, but don't forget that some positions in the enterprise just can't function without full-blown PCs. Hosting things like engineering or CAD apps is not worth the effort.