On 05/30/2016 10:32 AM, Martin Kosek wrote:
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.
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
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 nightly
to generate the tarball so I can use another script to backup it up along with
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 versions
of freeipa and sssd which are not available
via the standard repos?
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 it,
you would need to deal with it other way.
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.
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 with 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.
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 from copr due to basic bugs in the sudo 2FA code).
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project