Slashdot Mirror
Large Scale Deployment of Linux for File/Print Services?
sgtrock asks: "I was
approached this week by a manager of the server support group at my
company. He says he and his boss are trying to figure out what
should host our file and print services for the company (read,
replace Netware). He asked me if I thought if it would be feasible
to do on Linux servers. Now, I was more than pleasantly surprised by
the question, because as late as last fall I couldn't get this guy to
take Linux seriously for companies our size. However, recent stories
about Microsoft plus some of their actions here have really soured him
on the idea of moving to Win2k services where he doesn't have to. I
told him that in theory we could do it: LDAP authentication to our
existing NDS on the back end, Samba file service and either LPR/LPD or
CUPS based printing. The big open question mark for me is archiving.
He then asked me if I knew of anyone already doing it." I'm sure
there are shops out there that are using Linux as such. If you are,
please raise your hand! Numbers on the size of the network
and how well the system has been holding up would be appreciated.
"This is a pretty conservative company. We HATE to be first if we can avoid it. Every time we are we pay in much pain and sweat. So, I'd like to know the following: Does anyone know of or can point to success stories for this kind of application in very large environments? Mind you, I'm talking about tens of thousands of desktops, as we have 60,000 users. University stories will be looked at with skepticism by this management team. I'll read the stories, but they probably won't be given much credence by anyone else. Thanks for your time."
been there done that. i used LDAP with kerberos and LPR/LPD (& CUPS which we finally moved to but we started with lpr/lpd for its simplicity...i recommend doing the same) on 15 print servers for 15,000 students. solution is working well after 1.5 yrs...15 print servers deployed which handle the load quite well. print servers have web based admin (lpr called by a cgi--not very secure but the print servers have CDROM based boot and no remote access stuff other than lpr/lpd so rooting em doesnt get anyone anything..no compiler and minimal debian distros on em). archiving print jobs is handled by a copy to an AFS server and the cron jobs clear the spooled files from the RAM drive every 24 hrs after doing the AFS copy.
I run 6 SAMBA boxes in an NT network, and they all authenticate back to PDC and BDC boxes. The SAMBA technical lists indicate that authenticating back to an LDAP backend such as NDS is mature.
I have one "large" (150Gb storage) box that the other units trickle back to via rsync on 15 minute crons for backup, and a meagre 30Gb of archived files which barely fit on my 40Gb Tape backup unit. Check with the manufacturers for a supported hardware combination for your archive unit. I use HP, but they seem to be getting worse at support. IBM, for all their advertising, are probably just fine, or you could use an independant vendor. I don't recommend DELL. You will have to rsync via ssh the passwd and group files, and these will have to be generated independant from the NDS backend, or you can use "bad user" mapping, or even guest if you want.
I have had nothing but grief with LPR, then LPRNG, all due to bugs. Currently LPRNG hangs with many print jobs, and I have confirmed that this is a bug, but there isn't an updated RPM yet. Printing support for W2K/NT clients in Samba 2.2.2 changed dramatically, if you have only 9x clients, you should be fine, otherwise take some time to set up your "shares" and do stress testing. You may find you need to manually compile your printing engine, so you can rapidly update it. Some have suggested CUPS, I'll try that next.
Our biggest issues were with printing - LPR just plain sucks. At the time, CUPS was still very new, so we used LPRng. I ended up writing a GUI front end for printer management (since printtool didn't work well, and editing printcap files by hand was unacceptable). The final "problem" was quotas - the NT admins were used to setting directory level quotas, while Linux/Unix uses partition level quotas. Simply put, we had to split /home and /shared while they were used to having just one partition. Quota management under Linux just isn't the same as NT (for better or worse), and you need to remember things like "if a user & group quota affect a directory, the MOST restrictive effects the user" (which is why you need to make two partitions).
With newer kernels, this is a more reasonable project. Linux really is "enterprise-ready" now (I hate that term). Previously, things like a journaled filesystem were missing, which was a big gripe with the NT guys (when a system goes down, it takes a long time to scan 100 GB of data!). Also, newer kernels support more than 32000 users and groups (usefulness depends on your company size).
Finally, make sure you consider backup systems, how the systems would be administered, etc. It's a big project, but manageable if your company is really interested.
If you need some fodder for the fight to help convince management that this will save a LOT of money, check out this business case. You might also be interested in this deployment plan. Infrastructures.org also has a number of useful (must read) documents. Finally, you may want some help designing the architecture, and making sure you've found any issues. Find someone who has done this before (shameless plug: US Linux Networks) and have them at least work through some fo the major points to make sure you've got everything covered - the cost for a few days of requirements, architecture, and design may save you a lot of wasted effort.
OK, we are not a big company, so your "bigwigs" won't care too much for this story, but...
We are using Samba and cups to provide all of our file/print services, and they are both authenticating back to LDAP. Here is best source that I have found so far for samba and LDAP integration. It works very nicely, and with Samba 2.2 you can even do automatic NT/2000 printer driver installation as well.
For backup we use a Tivoli storage manager, which has native linux support, and so far has proved to be pretty reliable. We also run this thing in a very heterogenous environment (Linux, AIX, Solaris, NT and 2000!) with very few problems.
Cisco in 1998 was managing 50 print servers and about 1600 printers world-wide. About 10,000 Unix and Windows clients.
Linux Journal Article
This doesn't really answer your question, but...
If you can, skip SAMBA. Instead use IPP in conjunction with CUPS. It's simply the easiest thing to use on the planet, and works perfectly with Windows2K, 98, ME and XP.
I was astonished how easy it was to get this working, and you can even copy over the printer drivers onto the server (from the NT box) and have CUPS automatically deliver the printer driver down to the client when they request to "add" that printer.
It's just the sweetest solution imaginable.
Matt. Want XML + Apache + Stylesheets? Get AxKit.