-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So Supreet and I have been slogging our collective a** off working at a client's location (no names just yet), trying to migrate his 5000 users to Samba from a Winduhs file server.
Some experiences... Client has 8 locations, including numerous factories, spread over the country. Were using NT for domain control as well as file and print services (FPS). MS got into the act, convinced them about the joys of Winduhs 2003 and got their domain controllers (DCs) upgraded to W2K3. In the meantime we'd already done most of the work to switch the FPS from NT to Linux. At the last minute (nearly) client comes to us and asks, ``Can you work with a W2K3 domain controller?''. Being the blithe spirits that we are, we searched the web, found some pointers that seemed to vaguely indicate the possibility of a chance of there being some items that could portend the peaceful co-existence of Samba and W2K3, and gave him the reply in one word, `Yes!'. Problem with W2K3 is that it only supports active directory (AD) and none of the older methods of authentication (whatever they are -- /me is no Winduhs expert). So we need a Samba that is AD aware. Lo and behold, Samba 3.0.0 (currently in final Beta) is AD aware, and Google-ification yields a few HOWTOs on how to get the two working together. OK, problem (1) solved. As long as /someone/ has got it working, we should be able to too, right? I mean, what're mailing lists, IRC channels, friends and AK-47s for if not to get you assistance with making Samba work with AD? Download, compile, test, scream, tear out hair, kill w2k3 admin because he can't properly set the one goddam registry entry that we need, find another w2k3 admin, recompile, retest, etc... you know the routine. Finally, it sort of works. Except... see, Samba has this means of automatically adding new users when they're defined on the DC but not in Linux. So we use that facility (with some 'l33t shell scripting by yours truly), but there's some conflict in the group names and permissions and whatnot, and life sucks until Supreet comes up with this weird idea: don't have Unix users at all! I look at him in dismay, thinking, ``He's really lost it this time'' and am about to suggest a long vacation, away from computers when he explains: let the password routines use Winbind to get the users. Sounds like utter cr*p to me, but we're desperate so I mangle the appropriate files, and do a getent passwd ... and Voila! here's the list of all the users on the AD server! The rest of the office is eyeing us with concern (this is at the client's office) as we go into high-fives, middle-fives, low-fives, jaffi-pa's, bhangra, balle-balles and general rejoicing. The rest of the configuration looks like a breeze... ...Until... Wait, the client also has complex access rules for his data! See, the ``folder'' Marketing belongs to the marketing group and everyone in that group has read and write access to it, only, see, the Director Projects needs to view the files in /this/ sub-folder, and the Director Finance must be able to modify the files in /this/ sub-folder and /this/ sub-folder, and... you get the idea. Linux doesn't have fine-grained filesystem access control yet (well, the new betas do, but none of the ``stable'' releases). Scratch heads (scratch patka in Supreet's case), fgrep -ir acl /usr/src/linux/Documentation with no result, try to shrug off gloom and despondency. Finally decide to bite the bullet, put our noses to the grindstone, our back to the wheel and our ear to the ground and go in for SGI's XFS. XFS is a hotsex filesystem which is going to be part of Linux 2.6, but is not available for the 2.4 series except as a patch. Rather than patch, we decide to get SGI's complete Linux kernel CVS tree for kernel 2.4.21. A few hours (170MB downloaded) and a couple of kernel compiles later we're ready to test ACLs on Linux. Bah, what testing? It's Linux, and it works as advertised. Plug ACLs into Samba, and we're ready to start testing the setup. I won't go into the details of the testing phase. Suffice it to say that it was bloody, gory and rigorous. And that it passed off without incident. Saturday (19th) night we brought the new system online. Restored from tape wherever possible -- if you restore a backup from an NT machine onto a Samba share you get the complete user, group and access control lists on each file and directory. Unfortunately some of the tapes (only worth about 10 gig of data) refuse to restore, so we have to copy those files manually from the old NT server. Next 2 hours is spent with the client's IT bossman, looking at each of those files and trying to decide whom it belongs to, who should have access to it and where it should go in the Larger Scheme Of Things. Yesterday (Monday, 21st) morning the users started using the new system, and last (Monday) night we added the few remaining missing parts, and are awaiting feedback from the client as to how it goes. System use has been mostly without any hiccoughs for all of Monday and so far on Tuesday, so we don't Auntie Cipate any major problems. Once Delhi is running fine we're to roll out similar configurations to the other sites. Will be making a success story out of this client if all goes well, Insh'llah. In the interim, of course, MS fscked up and the client nearly had to shut down his factories for a day due to w2k3 problems, but that, as they say, is another story altogether and we shall not dwell on the vagrancies of proprietary software vendors and their excellent products. Lessons learnt Firstly, we discovered that Linux beta software works pretty damn well. In fact, in most cases it works better than release software from proprietary vendors. Samba is currently serving some 100-odd clients on a single-processor server with just 256 MB of RAM, and doing a pretty good job of it too. XFS is behaving exactly as one would expect it to -- stable and full of features. The plan is to switch to Samba 3.0 stable as soon as it is released (I *hate* installing betas and patches at client locations!), as well as to kernel 2.6 as soon as /that/ is released. That'll bring our two major solution components into a manageable state. Next, we had a major issue with Samba not setting group permissions properly when a user logged in. Couldn't find any documentation for this problem, and wasted 1/2 a day trying to figure out why it wasn't working. Finally started looking at the source code, adding debug statements, etc. And in the process, discovered why the group permissions weren't working, and how to make them work. Two minor changes in the configuration file and we were rocking. Moral: Use The Source, Luke. If you have an undocumented problem, catch a coder and get him/her to look at the code. All problems, as well as all the solutions are documented there. I mean, how difficult could it be to figure out what a function named sys_setgroups does? One of the things that never fails to surprise me about free software is how featureful it is. Supreet and I were continually amazed at the frequency of situations where the client would come to us with an obscure requirement, we'd check the documents and be able to say, `Yes, we can do that' within minutes. Makes life worth living when you don't have to say No to a client. Finally, a plug for Linux (yeah, yeah, GNU/Linux, whatever). I mentioned the files that we had to change permissions and ACLs on manually. OK, I lied -- it wasn't manual at all. We did the first couple of users manually, then discovered that we were using the same set of commands again and again with slightly varying parameters. The result? A set of 10-liner shell scripts that would accept a couple of parameters on the command line and go into directories and file and directory permissions, access controls, users and groups while we sat and twiddled our thumbs. This was what was taking our client 1/2 hour per directory to achieve from a Winduhs workstation. Regards, - -- Raju - -- Raj Mathur [EMAIL PROTECTED] http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F It is the mind that moves P.S. Standard disclaimers apply. If using this document as a technical reference causes your computer to blow up, your dog to be run over by a drunken truck driver or your mother-in-law to have a heart attack, Raj Mathur is not resonsible. Theis document is available for distribution under the terms of the GNU Free Documentation License. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE/HMyAyWjQ78xo0X8RArqNAKCOfCuFE898Az1tk1/BbgGCkqTAYACeIbDb BfoJZ6yyVU+Ip2aXJi+6HI0= =XmH3 -----END PGP SIGNATURE----- _______________________________________________ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
