Updating Samba From RPMs

Question

My Red Hat Enterprise Edition 4 comes with Samba Version 3.0.10, which does not have support for the "inherit owner" attribute that is essential in implementing a Deny-Delete Write Once Read Many share (for examples, search google for a-shared-drop-box-using-samba).

(BTW, if any body knows an alternative way to do it without updating samba, I'm all ears!)

I am not all that comfortable building from source, and after hours of googling (no, I do not have a red hat subscription, so I cannot just run the up2date command), I found a whole bunch of rpms on http://ftp.sernet.de/pub/samba/tested/rhel/4/i386/ (Samba 3.2.15 for RHEL 4)...

Next, I tried updating them with the rpm -U --nodeps command, but I got file conflict errors. So I went ahead and overwrote everything (or so I thought) by using the rpm's --force option. But no good has come of all that. /usr/sbin/smbd -V still returns the old version.

As of now, rpm -qa | grep samba returns,

samba3-client-3.2.15-40.el4
samba-3.0.10-1.4E.2
samba-client-3.0.10-1.4E.2
system-config-samba-1.2.21-1
samba3-3.2.15-40.el4
samba-common-3.0.10-1.4E.2
samba3-winbind-3.2.15-40.el4

I cannot remove the older ones because

samba-common >= 3.0.8-0.pre1.3 is needed by (installed) gnome-vfs2-smb-2.8.2-8.2.x86_64
libsmbclient.so.0()(64bit) is needed by (installed) kdebase-3.3.1-5.8.x86_64
libsmbclient.so.0()(64bit) is needed by (installed) gnome-vfs2-smb-2.8.2-8.2.x86_64

Now thats a whole bunch of dependencies that I dare not touch :)

Any and all pointer are welcome at this stage. Thanks in advance!

Answer 1

I wouldn't be scared of building from source: it's fun and rewarding. The only big problem you'll have is the same problem you're already having: dependencies. To get around the dependency problem, you'll need a package manager.

Hmmmm. You can install Yum, which is what'd you'd get on Fedora instead of up2date...It's pretty good at handling dependencies, and googling Yum and RHEL and Repository gives a good number of hits, so there are repositories out there which will have RPMs built for your system.

If it were me, I'd probably go ahead and upgrade KDE and Gnome, if it was that important to install the newer version of samba (that's a lie actually. I love the command line, so I'd just go ahead and break kde and gnome and not look back). Resolving this sort of dependency problem is what it's all about.

Answer 2

RPMs are built to resolve dependencies. The newer Samba RPMs you found were built for a different system, and compiled against different versions of the libraries.

Instead of trying to force-install binaries that might not work with your system libraries, you should build your own RPMs and install those. Look for an SRPM of the version of Samba you want to make it easy, and read through some good tutorials and books to understand the process.

The upsides are:

• If you have multiple machines using the same distribution, building your own local packages makes it easy to install everywhere;

• You avoid breaking dependencies with other system packages.

There are a couple of downsides to this approach:

• It requires installing all the *-dev packages needed to compile Samba (plus any required to build SRPMs);

• It may require upgrading some of the dependencies, just to get it to compile (usually through the same process);

• It introduces potential problems to your system, in the form of software that didn't go through your distribution's testing process.

Alternatively, you could obtain the source tarball for Samba, install to /usr/local, and remove all Samba RPMs in favor of your compiled version. But as you've noted, many other packages depend on Samba, so that's a whole other can of worms. Building your own RPMs and upgrading is far friendlier than trying to force RPM to keep packages with missing dependencies.

Answer 3

Use Samba builds from Enterprise Samba. Those are distribution-specific builds and they are very reliable.

Answer 4

Okay, so I finally (on Satanicpuppy's prodding :) went ahead and left the dangling dependencies dangling. This has apparently solved the problem without any side effects, so I am posting the steps here posterity (I am not accepting any one of the answers because all of them were, in a way, right)

1. rpm -qa | grep samba | xargs rpm -e --nodeps
2. wget ftp://ftp.sernet.de/pub/samba/tested/rhel/4/x86_64/*.rpm
3. rm samba3-cifsmount-3.2.15-40.el4.x86_64.rpm
4. rpm -ivh *.rpm

The drop box is working as expected from the Windows clients, but the Macs don't seem to like it. The macs seem to be creating a proxy file on the SMB server before writing out the actual file. Since I am locking the file as soon as it is created (my original purpose was to have a write once and deny delete drop box), this chokes the mac clients up and they create truncated zero byte files.

Anyways, thanks a lot to everyone who took the effort to help out. Happy Computing!

Answer 5

I solved on RHEL 5.4 upgrade by installing libsmbclient-3.0.33 and after on update i excluded libsmbclient.