Building rpms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Wed, 2005-11-30 at 15:35 -0500, Bowie Bailey wrote:
> From: Craig White [mailto:craigwhite@xxxxxxxxxxx]
> > On Wed, 2005-11-30 at 12:53 -0600, Johnny Hughes wrote:
> > > 
> > > What is the purpose of the LDAP upgrade ... if it is security you are
> > > worried about ... those get in there.
> > > 
> > > See this:
> > > http://www.redhat.com/advice/speaks_backport.html
> > > 
> > > When you start changing major components, you greatly reduce the
> > > stability of CentOS for yourself ... and you ruin the system
> > > interoperability.
> > ----
> > I pretty much agree with that last statement - and could never
> > conceive of getting an rpm of openldap/servers/client from Fedora
> > and rebuilding it on RHEL/CentOS without it being really really
> > tough to build and not breaking anything.
> > 
> > I think the general consensus on openldap message base is to build
> > everything in /usr/local from source, which in my case, I built db4
> > (4.2.52+patches), kerberos, cyrus-sasl, openssl and then finally
> > openldap - all from source and it wasn't nearly as hard as I feared
> > and left RHEL stuff alone and didn't break anything. The information
> > that I used to do this all came from Quanah's web pages at
> > Stanford...
> > http://www.stanford.edu/services/directory/openldap/
> 
> I'm looking at doing that.  I was just trying to stay with RPMs if
> possible so that I don't run in to dependency issues later when I try
> to install an RPM that requires openldap.
----
that's a no brainer. You don't remove, touch or do anything with the
openldap rpm's unless yum installs updates...they simply aren't used. If
you install everything in /usr/local (i.e. openssl/kerberos/db4/cyrus-
sasl), then nothing is affected by updates and openldap runs within its
own environment.
----
> 
> > Perhaps a less painful method might be to use Buchan Milne's rpm's
> > which would do much the same and though they seem to be created for
> > Mandriva, apparently can build/install on RHEL (sorry, I don't have
> > a URL for this but you can either post to openldap list or search
> > their archives).
> 
> Not a bad idea.  Anyone tried this on CentOS4?
----
perhaps someone is and they'll sound off. I know that Tony Earnshaw is
doing it on RHEL
----
> 
> > Lastly, perhaps the least painful method of all is the pretty much
> > turnkey packages available from symas... <http://www.symas.com>
> 
> Interesting.  I may look into this.
> 
> > Now, generally Red Hat back port works well enough but if you are
> > going to make RHEL/CentOS the base of a large directory service...
> > 2.0.7-20 (CentOS3) and 2.2.13-4 (CentOS4) simply don't cut it for a
> > number of reasons. I stick with them on most of my installations
> > because the number of users and the extent of the demands that I put
> > upon ldap are pretty minimal but if you are going to have a
> > substantial investment in time/energy in ldap,
> > fahgettibouddit...install current.
> 
> That's about what we determined.
> 
> > Recognize that 2.2.30 (I believe) is still the latest categorized
> > 'stable' - 2.3.11 (and I think it is now up to 2.3.12) is discussed
> > and sometimes casually referred to as 'stable' - I don't think that
> > it has 'officially' been designated so.
> 
> Actually, 2.3.11 is stable as of 10/18.
----
I see that listing but of course, they now have 2.3.12 in downloads as
stable...unfortunately, they seem to have frequent updates when they
introduce a bunch of new features (2.3.x) and there's still a number of
things that are not working as planned. The tag 'stable' is a curious
one since all of them that are involved in the development are
undoubtedly still using 2.2.x for their main directories at this point
and the only one that I recall that has made the commitment to 2.3.x was
Dusty Doris. But 2.2.x is feature frozen and unlikely to see anything
more than security updates and if they refuse to put out security
updates for 2.2.x, it will be awkward for RHEL4.

Craig


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux