We are in some trouble here...
ipa-server-4.4.0-14.el7_3.7.x86_64 on rhel7.3
4 x IDM setup.
The directory server on the master CRL server decided to have a fit, every attempt of starting it results in SEGV and core dump. I have the dns started but that is all that is running on the server at the moment.
not event "ipactl -f start" works. It just abort with:
ipactl -f start
Skipping version check
Starting Directory Service
Failed to start Directory Service: Command '/bin/systemctl start dirsrv(a)DOMAINE.service<mailto:dirsrv@DOMAINE.service>' returned non-zero exit status 1
An ongoing ticket at redhat does not bring any solution so I am going to restore server from a backup. Fortunately, it is a vmmware server.
Now while waiting for permissions from the customer to do the swap, I would love to promote another idm as master-crl but I am a little confused as how best do this.
In https://access.redhat.com/solutions/2253241 the procedure is:
on defect server: shutdown pki, reconfigure, start pki - shutdown httpd, reconfigure httpd, start httpd
on new sever: shutdown pki, reconfigure, start pki - shutdown httpd, reconfigure httpd, start httpd
The note also says:
NOTE: The procedure described above requires the first CA master to be reachable by the replica. If this system is no longer available, there is currently no way to setup a CA clone on any replica. The reason for this is, that the replica connects to the master to ask for some CA specific details. A workaround exists by recovering the first master from a backup and make it available to the replica system for installation time of the new CA. To avoid replication conflicts the replication agreements between the master and the replica should be deleted.
the procedure boils down to:
with the comment: "The command also automatically reconfigures the previous CA from renewal master to clone."
From the above, I take it there is no way to promote another server to master-crl as long as the dirserver on the original master-crl is down?
Now, when I boot up the restored server, then what?
The restored server is ready in an isolated environment and I have verified that the dirserver and everything starts up as it should.
The server will be 6 days old.
My thought is, I just boot it and run:
ipa-replica-manage re-initialize --from=working-idm
But for peace of mind I would still like to move the master-crl function to a different server. Could this be done before "ipa-replica-manage re-initialize"?
That would give me the freedom to completely scratch the server if something goes wrong.
And for the future: I find this failure to be quite problematic.
We have an extremely redundant setup, if an idm dies, I just remove it from the set, rebuild and rejoin. Tried it a couple of times, works great, nobody notice.
But the master-crl seems to be a real pain. Are the any way to rearrange things to a more robust setup. Maybe copy some directory contents from the master-crl to the other servers and then simply reconfigure
one of the other servers in case of failure? Sort of a cold standby feature.
Any advice is appreciated.
Guys, I had set up FreeIPA 4.5 on Centos 7 with self-signed SSL cert.
Now I want to install my main wildcard cert (from Comodo CA) for domain where IPA-server located, just for web-service, so web browsers won't complain to users about ssl.
As expected - when I'm trying to do:
# ipa-server-certinstall -w comodo.crt comodo.key
Peer's certificate issuer is not trusted ((SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized.). Please run ipa-cacert-manage install and ipa-certupdate to install the CA certificate.
The ipa-server-certinstall command failed.
I've found on https://support.comodo.com/index.php?/comodo/Knowledgebase/Article/View/9...
all CA certs for Comodo and set them up via
# ipa-cacert-manage -p DM_PASSWORD -n NICKNAME -t C,, install ca.crt
As pointed on https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
But nontheless, when I'm trying after it - ipa-server-certinstall, I get above error anyway.
I'm starting to go crazy with it and don't know what should I do to solve this :(
Help me please!
My cluster has been successfully working for over a year with version 4.2
I have replica of two ipa nodes and winsync
Tried to upgrade (ipa-server-upgrade) and replica seems to be ruined after it.
I can't even check its status
[root@idm0 ~]# ipa-replica-manage list --verbose
Traceback (most recent call last):
File "/usr/sbin/ipa-replica-manage", line 1615, in <module>
File "/usr/sbin/ipa-replica-manage", line 1548, in main
File "/usr/sbin/ipa-replica-manage", line 197, in list_replicas
config_string = ent.single_value['ipaConfigString']
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 564, in __getitem__
value = self._entry[name]
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 442, in __getitem__
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 409, in _get_nice
name = self._get_attr_name(name)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 405, in _get_attr_name
name = self._names[name]
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 583, in __getitem__
return super(CIDict, self).__getitem__(key.lower())
Unexpected error: u'ipaconfigstring'
Please any advises how to restore replication and winsync after upgrade, this is quite critical.
any recommendations how to best update the compat tree after changes of AD user attributes?
We use IPA 4.5 with AD trust. After modification of a AD user attribute, e.g. loginShell, the compat tree doesn't get updated automatically and so the unix/linux can't enjoy his new shell.
Accourding to Red Hat's knowledge base article https://access.redhat.com/solutions/1503713 the only way is to restart dirsrv ...
Maybe there's a better way to achieve this.
Thanks in advance!
Mit freundlichen Grüßen
BITMARCK Beratung GmbH
Firmensitz: Putzbrunner Straße 93, 81739 München
Geschäftsführer: Christian Niklaus
Registergericht: Amtsgericht München HRB 130163
Die Information in dieser E-Mail ist vertraulich und ausschließlich für
den/die benannten Adressaten bestimmt. Ein Zugriff auf diese E-Mail
durch andere Personen als den/die benannten Adressaten ist nicht
gestattet. Sollten Sie nicht der benannte Adressat sein, löschen Sie bitte