On Fri, 28 Mar 2003, Hall, Ken (IDS ECCS) wrote: > Well, 2 come to mind: > > 1) It stopped accepting connections at 50 users. > > 2) There was a problem with joining domains with smbpasswd. It couldn't find the DC. > > Both gone in later releases. > > > >Same thing with Openldap, and the latest version won't even > > build properly > > >on SLES7 because SuSE had to add patches to it that aren't > > in the base > > >versions yet. > > This is one of the hazards you run into when you decide to > > get away from > > being a consumer of a package, and into the role of developer. It's > > happened to me any number of times, and it's rarely been an > > easy problem to > > surmount. If it's important enough to me, I follow through. > > If not, I > > decide to try to wait for the next update from my distributor. > > > > Except that with Open Source, it's often quicker to go pull the latest version from > the developer and build yourself rather than wait for the support vendor to retrofit > a patch. > > The Openldap problem is a Catch-22. There's a known bug in versions up to a certain > point (please don't make me go look) where password changes don't replicate to slave > servers. It was fixed several > versions ago, but the SuSE-supplied version is about 4 releases older, and doesn't > have the fix. > > The problem is that "officially" libtool (which is used to build shared libraries) > and Openldap don't know about Linux/390, so SuSE patched them to properly recognize > it. Unpatched versions don't > build shared libraries because they don't recognize the architecture. So here I > have to depend on for SuSE to fix the problem. (Disclaimer: I haven't actually > gone to SuSE with this because we're > in the middle of switching to Kerberos for password storage anyway, so the issue > becomes moot soon. I'm just using this as an example.)
You can't expect SuSE to read your mind. If you have a support contract with SuSE, then when you have a problem, ask them to fix it. Even if you don't think you will need the fix for long because you don't plan to use the broken software for much longer, getting the report in helps others too. Helping each other is an importand part of OSS. If there are significant changes in Samba 2.2.8 over 2.2.3 (and I suspect there are), then that implies that for many users, upgrading is more than just "rpm --upgrade ...." Users who don't want those new features won't bless the vendor who inflicts them on the user-base. It's not practical for a vendor to fit its release cycles with OSS developers. IBM, on its software, controls development and release cycles, and in splitting MVS into separater products all those years ago, made the task a little easier. The Samba folk have a release cycle. The Linux Kernel people have several: 2.0 (I don't think it's quite defunct yet), 2.2, 2.4 and 2.5 streams. Then there are gcc, KDE, GNOME and many others, all with their own schedults, sometimes depending others, sometimes not. Vendors take a snapshot of the world around them, put a selection together and go through their testing cyycle. Following one, two or three betas they figure they have something that works. Maybe, and they release it. Any time they introduce a new version of a package "because it's got this great new feature," they risk breaking hundreds of thuousands, maybe millions, of peoples' computers all at once. Red Hat has stuffed things up a time or two, and you can safely bet there were lots of unhappy users complaining about it, even if tehy hadn't paid for it. > > >There also seem to be product features disabled or "missing", such as > > >Winbind in Samba, and quota support, sometimes because the > > various required > > >components aren't at the right level, or often for no > > apparent reason at > > >all. When this happens, there's almost no way to fix it and > > stay within > > >the "official" support scheme. > > Things like this are usually options that can be selected at > > compile-time. > > You should have the source RPM for the package, so you should > > be able to > > tweak the spec file for it to turn those on, if you really > > want them. You > > may find out the hard way, though, that they were left turned > > off for good > > reasons. (Similar to the reasons that Red Hat didn't turn on > > LVM in their > > 7.2 platform.) Linux distributors are not interested in gratuitously > > turning of functionality, since they'll usually get asked why > > something > > isn't available, when distribution xyz has it. (Again, take > > Red Hat 7.2 and > > LVM for example.) > > > > Agreed, but I often find little logic in their choice of build-time options. > Winbind left out of Samba, for example, and support for LDAP maps left out of > autofs. No Kerberos server package at ALL. > But that's because these are features *I* need, so I admit I'm biased. > > But then they include packages like cdrecord and ppp. Why? Does anyone care about > these in a mainframe server OS? I suspect because they build cleanly without > fiddling. I've never explored the reasons for Red Hat's configuration choices, but it's a fair bet that if Windbind failed their testing, they would not make it part of the default package. Enrol in their Bugzilla system and see what you can find. -- Cheers John. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
