July 21, 2004
July 20, 2004
More Portal Fun
From Bridges Advisory #18 - July 20, 2004:
DIRECT DEPOSIT INFORMATION REMOVED FROM myUFL. Due to campus security concerns, the university has removed self service access in the portal for viewing of direct deposit information.
:-D
July 16, 2004
Mac OS X vs. Samba
Mac OS X's implementation of Samba is a load of crap.
Taking a trick out of Microsoft's book, Apple has embraced and extended Samba to use Open Directory for user authentication. I won't speak on the merits of Open Directory, since I don't have much experience with it (other than using NetInfo Manager to manage groups), but something went wrong with the marriage of Samba and Open Directory.
Before ranting, I should probably note that I've used Samba on Linux for years now. I'm used to getting it running with a fairly simple configuration, using smbpasswd as my passdb backend. It's a simple way to get Samba running for one or two people. It hasn't failed me for any reason other than my own stupidity, but it's certainly not something I'd want to use in an "enterprise".
Anyway, I've spent the better part of my week trying to figure out why our Windows XP clients (which I don't administer) could not connect to our Mac OS X file server (which I manage). The clients refused to authenticate to any account on the Mac via Windows file sharing, regardless of what I tried - specifying the domain, leaving it off, etc. I tried creating new accounts on the Mac, but those didn't work. This kind of problem gets to be very frustrating when your coworkers need to access their files to do their jobs, and you have no idea why.
Did I mention that Mac OS X and Linux clients had no problems connecting (except for a strange permissions issue on my Linux workstation)?
When a Windows XP client would attempt to connect, I saw the following over and over in smbd.log:
[2004/07/16 14:19:42, 0] /SourceCache/samba/samba-56/samba/source/smbd/server.c:main(747)
smbd version 3.0.2 started.
Copyright Andrew Tridgell and the Samba Team 1992-2004
Weird, huh? Sometimes I would see an entry like:
[2004/07/16 14:19:42, 1] pdb_ods.c:odssam_getsampwrid(1831)
odssam_getsampwrid: rid<501> rid str<501>
This was neither informative nor helpful. Actually, it didn't make any sense. The rid matched my account's uid, but not the uid of the account which was attempting to connect via Samba. I spent some time reading the code from Apple's implementation of Samba, but I know next to nothing about Samba's codebase to begin with, let alone Open Directory. I was desperate, but not that desperate. (If anyone from Apple reads this: why the fuck isn't that code documented?)
Oh, did I mention I'm debugging "production" services during business hours, when people who can connect are actively working from the file server? "Sorry, guys, I have to restart Samba again."
I pretty much figured that our Windows XP clients were passing authentication information from the domain which they are a part of. Sure, if your domain authentication fails, Windows prompts you for a username and password. But apparently ignores what you enter. I can't be sure, since I don't know where Windows logs this kind of information, even if it does.
The "Network Guys" (our Windows domain administrators) suggested that I give the Mac a NetBIOS name, set its workgroup to match the name of the Windows domain, and create accounts with the same username as the domain accounts. Didn't work, but I'll admit I might have missed something.
So now you're probably wondering why I'm blaming Mac OS X for these problems. Just for fun, I set up a Samba share on Linux. The Windows clients were able to connect with no problems. So something on Mac OS X was failing, and the log entries suggested Open Directory. (Truthfully, I should verify this again - I tested this on my laptop when it was still able (magically) to connect to the Mac.)
"Okay," I thought, "let's try using smbpasswd instead of opendirectorysam." I change smb.conf, restart the service, and try adding a Samba password:
[14:39:23 dwc@server ~]$ sudo smbpasswd -a dwc
New SMB password:
Retype new SMB password:
could not find new user/computer dwc in passdb.
Failed to initialise SAM_ACCOUNT for user dwc.
Failed to modify password entry for user dwc
So it seems that smbpasswd doesn't understand Mac OS X's user accounts (through Open Directory) when you use smbpasswd as the passdb backend. Great. I wasn't about to go mucking about in /etc/passwd when I didn't know how it would affect Open Directory and Mac OS X as a whole.
I have found these links - but they are fairly old and haven't been very helpful so far.
- Mac OS X and SMB HOWTO (I don't have access to
regedit.exe, by the way, so I can't enable plain text passwords - nor would I want to) - Using MacOS X 10.2.X Windows File Sharing
- Mac OS X Server Cross-platform Issues
As a result of all these headaches, I've been pushing for moving the file share back to the Network Guys. Once you're on a domain, it really seems like an all or nothing kind of deal.
There are really two issues here:
- People not listening to me. A few months ago: "Let's move some of our services away from the Network Guys, since us Mac users can't connect to the shares they provide." Fine, as long as the Windows computers can connect. I didn't like the idea because I was still a student, and didn't want an important server to go down when I wasn't around. I made this pretty clear to everyone involved, but it was decided that we still wanted the server. Now we have the same problem on a wider scale.
- Commercial software getting in my way. Time and time again, I've been disappointed by commercial software because it gets in my way. It pushes my buttons. The free software I've chosen to use doesn't hinder me in this way. It works consistently, tells me when I'm being stupid (usually with an informative message), and is generally better documented. So why do people use commercial software? Oh, becuase pressing a button and hoping it works is easier than modifying a text file and knowing it will work.
It's not up to you
It never really was
July 12, 2004
Tour de France
Neat article about the Tour de France. Specifically:
Consider the numbers behind the Tour de France: 21 days of riding; 2,110 miles; 5,200 calories burned per day; a peak of 1,000 watts output at any given moment (enough juice to run seven iMacs).
One thousand watts peak power output. Wow.