Posted
by
Cliffon Monday October 07, 2002 @12:20PM
from the damn-good-ideas dept.

dsavitsk asks: "I am a part owner and I.T. manager of a small company. I spend most of my time writing in-house software in Python and VB, and administering the various systems we use. (Our current setup is a Win2k Server, a few win2k clients, a FreeBSD gateway, and a few other things.) I am also in law school, so my time is very short. In general, whenever I can, I will use an open source program over a closed one (hence, most of our software is now Python powered). One of the perks of my job is that I have an open budget and mandate to learn as much as I can about new technology we might use. (I've bought $1200.00 in O'Reilly books in the last year alone!) So, the question. I simply don't have time to learn everything I need to know, and to configure lots of open source projects that don't have a pile of books or decent documentation written about them. I found, in fact, that not knowing anything, it was much easier to set up a Windows domain than a Samba server. We also don't have the money to hire a full time sysadmin. What we would like is to hire a consultant for open source software who would not only come in to install and configure something, but who would also teach me the hows and whys so that I could then pickup where they left off. Clearly, we are not looking for free help, and would be happy to pay market rate for the work. In short, we are looking for people who would advocate for open source not just be producing it and consulting about it, but by administering it and teaching at the same time. So, where would I find such a someone?"

One of the wonders of Free software is that you can deal with the actual authors of the software you're using. Not everyone will be likely to help you out, but you might get some good suggestions on who *can* help you. Of course, physical proximity is helpful for setting some things up on your machine, but many packages can be installed and configured remotely, and email takes the pain of asynchronous communication away nicely.

You gave as an example setting up a Samba DC versus using Windows 2000 Server... that example should be telling launching redflags as you ask this question...

If you want to run a Windows domain -- use windows. While you *CAN* use samba, is it worth your time (which is in very limited supply if I read your post correctly) and your money to setup a custom, "free" solution to everything?

What do you do when Windows XP ServicePack 8 stops interacting with your Samba DC?? Do you stop studying for the bar, drop your management duties to figure out how to fix it? Do you have enough money lying around to pay an expert to fix it?

At work I try to stick with things that everyone is familiar with that also happen to work.

Use the best, simplest solution you can afford. If you want a Windows Domain, buy a server from Dell for $2000 with a W2k Server licence. You spend about 4 hours setting it up with resources available readiliy online.

If you go with a samba solution, you buy a server for $1200, and buy 16 hours of consulting time, while losing 8 hours of your time learning how to use it.

What do you do when Windows XP ServicePack 8 stops interacting with your Samba DC?? Do you stop studying for the bar, drop your management duties to figure out how to fix it? Do you have enough money lying around to pay an expert to fix it?

This is why IT managers manage the software/fixes installed on desktop machines. One should never apply a large OS update to their entire network without testing it in a controlled situation first. Thousands of people ran into problems with Win2k SP3, while many thousands of people prepared themselves for it by testing the SP in a test lab so they would know what the outcome would be.

Moreover, wouldn't these guys [afr.com] be apt to find a fix to the "XP Service Pack 8" breakage for you? Open source doesn't always mean "fix it yourself", you know.

Of particular interest (apologies for the redundancy);

"Because it doesn't have access to Microsoft's source code, the Samba team has been forced to develop a suite of testing and debugging tools that systematically interrogate Windows, looking for new features and checking that the old features haven't changed whenever Microsoft brings out a new version of Windows. It's likely that the Samba team now spends more time testing Microsoft's networking software than Microsoft itself."

I do not mean any insult to Samba itself -- it's a great project run by some world-class coders. That was one example meant to illustrate the real crux of his problem: Who is going to maintain all of this custom crap?

You are correct that open-source doesn't mean fix it yourself -- but open source isn't an IT nirvana either.

Let's assume one day this guy's company grows and he hires a sys admin, or a programmer who wears a sys admin hat. The original poster is an attorney now and is busy running his company.

Who in the hell has the time to do routine IT crap, and figure out all sorts of bizarre configurations. If you stick to standard configurations you'll be able to find people to run/fix/upgrade/maintain them. Unless you are a huge organization with lots of technical expertise, don't customize for the sake of doing it or to save $500.

This leads to another thought: If you don't want to run non-free software -- don't use Windows! If you want to adhere to open standards -- don't use a proprietary directory scheme! If you want a free user directory -- don't use a domain!

You said you didn't mean to insult Samba, but that doesn't sound particularly flattering to me.

Who in the hell has the time to do routine IT crap, and figure out all sorts of bizarre configurations. If you stick to standard configurations you'll be able to find people to run/fix/upgrade/maintain them.

Samba is a standard configuration. You'll find it in smb.conf. As to the people who can run/fix/upgrade your configuration; that would be a UNIX/Linux systems administrator. (All readers who fit that bill and have a resumee handy, please raise a paw)

don't customize for the sake of doing it or to save $500.

It sounds to me like you haven't priced out a Win2k Server with Exchange Server for 10-12 seats, have you? We're talking closer to $6000, not $500, and we still have to build a server and install the OS, which means either the lawyer must do it himself or pay a beanie-wearing MCSE to do it for him.

With about ten hours' worth of labour, I can install and configure a Linux server to replicate the majority of the functionality of a Win2k domain controller running Exchange. That means approximately a 90% savings on the cost of getting the server up and running - assuming the O.P. performs the Windows install/config himself.

This leads to another thought: If you don't want to run non-free software

He didn't say he wanted to avoid using non-free software altogether, only that he's interested in using OSS for his company servers. After having administered an NT4 domain (~1300 users), and with the few Win2k domains I'm presently responsible for, I can perfectly understand why he'd want to use a UNIX/Linux based approach.

I'm asking a serious question, becuase I don't know how easy it is to support NFS on Windows desktops. How much is all the MS naming service crap worth? Why not use and promote the open alternatives from the top down. TCP/IP, DNS, NFS, SMTP, ???.

If this sort of thing was provided as a turnkey package that a guy like this could use, it would give us another very credible example to point to. Sort of a Lindows Server, to steal the name but not the business model.

This should protect him from the service pack that breaks everything a lot more than using emulated MS protocols.

I looked for a stable Win-NFS client -- the only ones available at the time were very expensive. I think the only people using it were DoD/DoE and Petroleum types who had very fixed requirements.

That's what led me to use SMB -- samba works very well and I already paid for the client when I bought windows!

That being said, I don't think anything offers what the Windows 2000 domain model does. You get Dynamic DNS and authentication for both clients and machines that also allow you to place ACLs on filesystem objects.

I'd say the closest thing to this in the Unix world would be LDAP on an SGI or Linux box with the XFS filesystem and bind 9 (supports DDNS, right?). That would require alot of hacking just to get what Windows gives you out of the box.

Thanks for the excellent reply. That is more or less what I understood to be the case. I listen to my Windows experts even though I'm pretty actively staying away from getting too deep myself.

So what is the response of the Open/Free Source community to all of this? A Samba client on Windows might outperform the original code. The recent interview with Tresh made that clear. How hard would it be to make a replacement client? I know it won't be long before Palladium and related projects from MS make this even harder, but since when has that stopped anyone.

And what about an open replacement for their domain model? We went around this by using a MS domain controller with Samba servers. This was worthwhile because we needed both NFS and SMB from the same file systems. Even so there were some hoops to jump through.

I don't think that can happen in the open-source world. The whole windows model integrates filesystems, network user-ids and machines transparently and securely. That is what people mean when they compare NT to the VMS os of VAX fame.

To shoehorn that sort of model on Unix would be difficult -- to do so on Linux would be impossible. The "Trusted" Unix OS's hit the nail on the head from a filesystem point-of-view, but except for DCE (which is a nightmare) makes no allowance for networked users.

I think the next evolutionary step for this sort of thing is a "Trusted-AFS on crack" which would create a universal, virtual filesystem namespace instead of local filesystems and a universally available LDAP or other database. If you have used Tivoli Enterprise software, think of it as having Framework (except it works well) mixed with the AFS network filesystem.

"What do you do when Windows XP ServicePack 8 stops interacting with your Samba DC??"

I remember when I think it was SP4(?) for NT4 did this. It forced the SMB client to not send unencrypted passwords across the network. There was quite a large amount of dismay on the samba usenet groups.

Short term there was a fix to change a registry setting in Windows. Long term there was a fix to Samba to make it support encrypted passwords. What amazed me was the number of people who took the short term fix, and in fact are still promoting this as a legitimate option.

Sometimes I wonder if people really think through the full consequences of their decisions.

Encrypting SMB passwords is the wrong place to applys security. There is a gain that is not entirely trivial, but bad guys who can sniff your network can still capture your data, run dictionary attacks on your passwords, and so on. If you don't trust your network's physical security, there is no solution that makes a big difference except encryption at or below the transport layer (i.e., SSL/TLS or IPSec). Enforcing a weak security solution while breaking functionality is a double lose.

Ahh, thank you Mr./. security expert for digressing off topic in a futile attempt to show how "smart" you were.

Most LANs are physically secured already to prevent sniffing by way of switched ethernet secured in a closet. The SMB password issue had more to do with social engineering someone to connect to your "server", which would then cause the authentication packet be sent in the clear, than it did with network sniffing.

IPsec or SSL are not great solutions unless you utilize them to prevent access to corporate LAN ports, because otherwise they are fairly non-discriminating on who they will setup a secure channel with. You can control this with ipsec, but there is quite a lot of overhead resulting from this solution both from computer resources and process management overhead, such that it is really only viable in paranoid installations.

So while the SMB encrypted password thing was not a great solution, it was an appropriate short term solution for the existing client base. A better long term solution was to move away from the password hashes completely and towards Kerberos PKI for authentication, which is what happened with the advent of Windows 2000.

I completely fail to be impressed with the importance of a security fix whose primary function is to turn the "convince a user to connect to an external SMB server, then sniff their password" attack into the "convince a user to connect to an external SMB server, then sniff and crack their password" attack. Users, in the main, have terrible passwords. Giving away a hash is little better than giving away the password

Kerberos provides some sort of authentication infrastructure, but it sure wasn't Public Key Intrastructure last I checked, but rather pre-shared keys for DES (in the case of K4) and other symmetric cyphers (with K5). SSL and IPSec, on the other hand, do work quite nicely with public keys, even if most people don't seem to want to bother using client certificates or even verifying server certificates.

I replied to a comment that said, in essense, "it's not Microsoft that's lame for breaking Samba compatibility, it's Samba that's lame for not keeping up with Microsoft's l33t security updates" by saying, in essense, "Microsoft's security update is not so l33t and has the added effect of breaking stuff, so Microsoft is lame after all". You have failed to explain how this is off topic or, for that matter, wrong.

A low UID is not a license to be rude, and snide comments are especially out of place when they are misinformed. I suggest a calmative, followed by a period of quiet reflection.

"If you don't have anything to say, say it in a condescending tone." I'd be happy to continue the conversation about practical system administration as soon as you're ready to rejoin it. Since I had the last post with actual content, it's up to you now. I won't bother to reply to any more personal attacks from you.

Taking all of 5 minutes to migrate the entire Windows domain from compiled source on Slackware to built-in runtimes on RedHat: Priceless.

Not having to touch it since I installed it except to migrate it (for about 4 years now): Also priceless.

Once it's set up, you'll never think about it again. Good luck achieving that sort of stability on Windows.

Don't get confused. You can't estimate the initial setup costs on Linux and then tack on the usual maintenance costs on Windows. For the most part, it's one or the other, and, in my experience, I'll take the larger up-front investment over the weekly hassle any day.

but his employer IS NOT paying him. He said he is a part owner, so he essentially employes himself.That $1200 is $1200 lost profit, part of which may have gone to him as cash. Basically, he paid for the books himself.

Strangely enough I did exactly what you're talking about earlier this year. I was working for a company that got hit with a pretty hefty fine from Micro$oft for not having enough Win95 licenses or something. They decided they wanted to migrate as many servers as possible to Linux (and maybe some workstations). The main problem was that although the staff was very competent in windows they didn't have enough linux experience to get past the unproductive part of the learning curve. At least from my perspective it was extremely helpfull for people with little experience in Linux to have someone around to help them with the stupid stuff. I was there for two weeks and by the end they were compiling kernels without hesitation.

I'd bet that there are a lot of people who would rather pay someone to come in and train some of their IT staff than give that money to Micro$oft.