On 05/30/2016 06:57 PM, Ken Bass wrote:
> On 05/30/2016 10:32 AM, Martin Kosek wrote:
>> On 05/29/2016 05:33 PM, Ken Bass wrote:
>>> Today I tried my very first ipa-backup attempt. The command reported 'The
>>> ipa-backup command was successful'
>>> YET I saw:
>>> /usr/sbin/db2ldif: line 157: 22567 Segmentation fault /usr/sbin/ns-slapd
>>> db2ldif -D /etc/dirsrv/slapd-DOMAIN-NET -n userRoot -a "/var/l
>>> ib/dirsrv/slapd-DOMAIN-NET/ldif/DOMAIN-NET-userRoot.ldif" -r
>>> I am running Centos 7.2. After googling, I did find -
>>> How am I supposed to backup this box? I want to run the backup-script
>>> to generate the tarball so I can use another script to backup it up along
>>> other stuff. It is a small system with no replication.
>>> As a Centos 7.2 user am I just out of luck since it appears the various
>>> bugs I
>>> am encountering with this software are not being fixed except in newer
>>> of freeipa and sssd which are not available
>>> via the standard repos?
>> Hello Ken,
>> I am sorry to hear about your trouble. The standard way for people with RHEL
>> subscription is to request a RHEL fix from support, but if you do not have
>> you would need to deal with it other way.
> Correct, I do not have a RHEL subscription. However my justification for using
> Centos 7.2, rather than Fedora,
> was that I would be using a production quality product. The same as the 'big
> guys' so to speak.
> So when I am running into
> a bunch of issues it makes me wonder how this stuff got through Q&A in the
> first place.
You obviously must be hitting some scenario or have a configuration environment
that was not tested. Filing a RHEL Bug should help also to ensure that this
scenario is tested.
>> As this is a DS issue (linked from FreeIPA ticket), you can try raising
>> awareness in RHEL-7 product of the 389-ds-base and ask for backport of this
>> issue to RHEL-7.2.x stream.
> I dont think it is solely a DS issue. The ipa-backup script is reporting
> command successful when something internal is seg faulting.
> That would seem like someone is not checking a return code in the ipa-backup
> script. At least the ipa-backup script should be reporting a failure since I
> assume the backup is incomplete.
That *is* a good point and is worth filing upstream ticket
If you can also help FreeIPA with a code contribution, it would help project
immensely as there is a lots of tickets...
>> Alternatively, projects may have own CentOS repos
>> where they can publish builds of upcoming releases, like FreeIPA has:
> I had thought about using that, but it warns it is not for production, and
> the number of issues I have encountered in the production
> version, I worry that the copr version would be even worse, and that if there
> are any issues the response will just be don't use it for production.
It is true that these packages are provided as builds of FreeIPA upstream
project, with "community support", i.e. this mailing list and voluntary based
help. RHEL is officially QE'd and supported, so the base CentOS packages should
be more stable, yes - though with lower amount of updates, given the QE and
support related processes. It is a trade-off as usual.
> Do you know how stable the software being fed to the copr is? While perhaps
> overkill, I am only using this for 2 boxes with 2 users -- mainly for the 2FA
> component. I am not doing anything
> fancy like replication, etc. I had replaced some custom radius server code and
> openldap stuff with freeIPA since it helped with enrolling tokens via freeOTP
> and such. The freeIPA is better
> integrated into sssd than my custom solution (though I had to install sssd
> copr due to basic bugs in the sudo 2FA code).
It is hard to quantify stability, so I would go with "more stable than git
builds as it goes through Upstream QE test suite, less stable than RHEL bits -
that are production ready".
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project