On 11/08/2013 02:58 PM, Michael Gettes wrote:
On Nov 8, 2013, at 4:50 PM, Rich Megginson <rmeggins@redhat.com> wrote:

On 11/08/2013 02:10 PM, Michael Gettes wrote:
As I currently understand things, 389 1.2 is available via RPM dist channels (including epel test using rmeggins people repo)

. . . and really isn't fully supported.  My main intention for providing EL6 binaries was to give a preview of upcoming features that were going in to RHEL6.  There isn't much difference between my personal epel repo and the version in RHEL6.

and 1.3 is available by source tarball.

Binary packages are available for Fedora . . .

i should have mentioned - i need for RHEL6.

Understood




due to how my organization handles firewall access, it is quite the PITA to build network source based software which makes it rather difficult for me to deploy 1.3 in test or prod.

What exactly is the issue?

If there was any chance of getting 1.3 (and beyond) via a standard RPM dist channel,

I don't know what that would be.  I don't know if there is a "forward" looking EPEL6 category - most users using EPEL6 want older, more stable software - I suppose you would need some sort of "bleeding edge yet fully supported and supportable" software channel.

My fedorapeople repo is not really a "standard RPM dist channel".

I would be willing to run it, maybe even in production!  as i attempted to build 1.3 it had requirements which would have necessitated building via git or something similar and i got stuck cuz of how we do things here (no comment on how we do things, please).

No comment, just want to understand what exactly the problem is.
What problems did you have building 1.3?  Was it 1.3.1?  1.3.2?

1.3.2 - the one with the SASL init hang.  i went to build the LDAPSDK and it recommends getting source via (need to go find it…)
found it - https://wiki.mozilla.org/LDAP_C_SDK says to do cvs

I guess you are using the instructions here - http://port389.org/wiki/Building - which are very out-of-date - I would be willing to work with you to come up with a simpler, up-to-date build procedure.

Or even just taking the epel6 389-ds-base.spec file, changing the version, and using rpmbuild to build rpms.

As for mozldap, starting with 1.2.6 or so, 389 uses openldap c sdk not mozldap.

In fact, all of the build dependencies are available on RHEL6 (usually from the optional repos, where the -devel packages live), so you shouldn't have to do anything.


my org blocks outbound access and it is a real PITA to work with the security team to get things opened up.

You need outbound access to build from source?

on the plus side - i know other similar orgs to mine who have gotten bit and we haven’t so i guess our strong firewall approach “appears” to work for now.

does this help?  i could just be doing something stupid in not realizing how to build the software…. but, again, i would most prefer not to build.

We need to make it easier to build from source, and to build rpms.  There will be situations where it will not be possible to provide binary packages for all versions with all possible combinations of options (e.g. build without systemd on rhel7).


i understand running “bleeding edge” in prod can be risky.  but if probs are being fixed out in the bleeding edge, i can make a case for it.  the support via this mailing list has been, frankly, better than most vended software i have dealt with in my career.  THANK YOU!  so the risk seems to be quite low at this point given the quality of the people involved.

/mrg



if i have any of this wrong, i’d greatly appreciate being corrected.  pointers welcome.

like i said, something to consider.

have a great weekend all!

/mrg

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users