Why Linux isn’t ready

Mar 7, 2010 Author Nik

There are plenty of people around who will happily slate Microsoft (sorry, that should be Micro$oft), Windoze, and Internet Exploder.  The majority of these people will, unprompted, extoll the virtues of Linux.

I won’t lie, I like Microsoft.  I think Windows is the best all-round family of operating systems available.  And I use Internet Explorer as my default browser, even though I have Firefox and Chrome installed.

But I also run a Linux server.  It is a modest beast.  It has a Sempron processor, three hard disks around 200-500GB each, and about 1GB of RAM.  It doesn’t need much, even though it acts as a mail server, a web server, and a DNS and network file server for my home LAN.  It runs Fedora 11, which is actually quite nice.

I started using Linux with no experience, and with the help of some patience, a few good Internet resources, and good old intuition, I pretty much know what I’m doing.

About a week ago, my Internet connection started to die sporadically, at unpredictable intervals, for no apparent reason.  I traced the lack of connectivity down to the DNS service on the Linux server not responding to requests, and this led me to realise that the server would not respond to any kind of request at all: SSH, HTTP, or even ping.

So imagine my surprise, when after a lot of investigation (and I really do mean a LOT of investigation) it turned out to be Samba, the service which handles network file shares.

I had recently updated Samba from v3.3 to v3.4 using yum, assuming it to be a bug-free release which wouldn’t break anything.  How wrong I was.  From v3.4, Samba has been changed to use a different authentication mechanism by default.  It used to use smbpasswd up to v3.3, but now uses tdbsam.

Ok, no problem really – until the upgrade from v3.3 to v3.4 changes your smb.conf without leaving an smb.conf.backup or something similar sitting next to it.  So without knowing it, your Samba installation now uses tdbsam.  Now, the problem with this is that there is a known bug whereby Windows clients become unable to authenticate and connect.

It was disappointing to have to find this out the hard way – by which I mean trawling around the web.  But still, it should be easy enough to edit smb.conf and change the authentication back to smbpasswd, right?  Wrong, because it seems the upgrade deleted the file containing the smbpasswd credentials (/var/lib/samba/private/smbpasswd).

Redhat’s Bugzilla entry explains how to convert smbpasswd account credentials to tdbsam format, so presumably you can do the reverse.  Well, technically you can – but only if the tdbsam credentials file (/var/lib/samba/private/passdb.tdb) isn’t empty!  That’s right, the upgrade failed (or didn’t even try) to convert the smbpasswd account credentials to the tdb format.

The solution is to run smbpasswd -a username for every Samba account you lost.  I’m glad I only had two.

This is why I think Linux is a long long way from being ready to take over the world.  I don’t think the Linux community appreciates how much help the average desktop user needs when they encounter problems.  This is demonstrated by the fact that Linux gives you no help at all; even the noddy ‘How do I…’ help topics in Windows destroy the assistance Linux offers.

From the very start, Linux makes it very clear you’re on your own.

While I admit that the change to Samba was publicised in the Samba release notes, I simply do not have the time to read through the release notes of, and perform impact analysis upon, every update I install.  I want to be confident that each update is the best thing for my system – much like Windows Update.

For now, I will stick with the majority of users, and keep current with Windows updates for the advantage of not having to enter the root user’s password whenever I want to do something.

Leave a Reply:

*

Protected by Copyscape Online Copyright Protection

Bad Behavior has blocked 237 access attempts in the last 7 days.

Bear