python3-ipaserver installutils.py missing IPA_MODULES list
by iulian roman
Hello everybody,
I do not know if this is the right place to mentioned, but maybe there will be someone who can redirect me to the right list or support channel.
On RHEL 8.3 , the latest python3-ipaserver package (python3-ipaserver-4.9.2-3.module+el8.4.0+10412+5ecb5b37) does not contain the IPA_MODULES list in the installutils.py package. Due to that, the ansible freeipa role will fail.
Can you please suggest whom I should contact for that or where should it be reported ?
2 years, 3 months
named won't start
by Bret Wortman
It's an ancient server, and one I'm trying to get us off of, but it's our current primary IPA server on this network and named didn't like its last reboot and is erroring on startup:
[root@ipa1 ~]# systemctl status -l named-pkcs11.service
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native PKCS#11
Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; disabled)
Active: failed (Result: exit-code) since Thu 2021-06-03 12:47:25 EDT; 13min ago
Process: 1055 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, status=1/FAILURE)
Process: 1053 ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf (code=exited, status=0/SUCCESS)
Jun 03 12:47:25 ipa1.our.net named-pkcs11[1057]: bind-dyndb-ldap version 6.1 compiled at 17:24:34 Dec 2 2014, compiler 4.9.2 20141101 (Red Hat 4.9.2-1)
Jun 03 12:47:25 ipa1.our.net named-pkcs11[1057]: option 'serial_autoincrement' is not supported, ignoring
Jun 03 12:47:25 ipa1.our.net named-pkcs11[1057]: GSSAPI client step 1
Jun 03 12:47:25 ipa1.our.net named-pkcs11[1057]: GSSAPI client step 1
Jun 03 12:47:25 ipa1.our.net named-pkcs11[1057]: LDAP error: Invalid credentials: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context: bind to LDAP server failed
Jun 03 12:47:25 ipa1.our.net named-pkcs11[1057]: couldn't establish connection in LDAP connection pool: permission denied
Jun 03 12:47:25 ipa1.our.net systemd[1]: named-pkcs11.service: control process exited, code=exited status=1
Jun 03 12:47:25 ipa1.our.net systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.
Jun 03 12:47:25 ipa1.our.net systemd[1]: Unit named-pkcs11.service entered failed state.
Jun 03 12:47:25 ipa1.our.net systemd[1]: named-pkcs11.service failed.
One of its replicas is still up and running so I'm not in emergency crisis mode yet.
This server is running Fedora 21 and ipa-server 4.1.4-1.
We got here as I was trying to take this server and replicate it to a C7 box running a more recent ipa-server (4.6.8-5) but couldn't get the replication to work. Along the way, I rebooted the F21 server and it came back in this state.
What should I try next to get it back?
--
Bret Wortman
bret.wortman(a)damascusgrp.com
2 years, 4 months
Automember Hostgroup Rule not applying to new hosts
by Russ Long
Hello,
I have an automember rule for a hostgroup where it uses the nshostlocation of the host to then add the host to the group. When adding new hosts, which are installed via ipa-client-install, and then have the nshostlocation added via ipa host-mod, all in an automated process, the new hosts are not being added to the group. If I run an automembership rebuild, the hosts are then added.
As these hosts spin up and down frequently, having to manually trigger this is less than ideal. Is there a better way to handle this? I'm not dead set on using the nshostlocation for the automember rule, but it seemed the easiest and most appropriate for my situation.
Thanks,
Russ
2 years, 4 months
Solve freeipa 'fragility' via orchestrated containers & whole-container upgrade?
by Harry G. Coin
Long time freeipa users have faced a certain 'fragility' freeipa has
inherited, mostly as a result of freeipa being the 'band director' over
a number of distinct subsystems maintained by various groups across the
world.
This or that 'little upgrade' in a seemingly small sub-part of freeipa
'suddenly breaks' major things like not being able to install a replica
& etc, there's a quite a list and it's been going on for a few years at
least to my knowledge. Usually one expects newer features to have bugs
but none that disrupt core prior functionality.
I wonder whether it would be a solution to this if free-ipa took a look
at how a 'similar feeling' multi-host, multi-subsystem architecture has
appeared to have solved this puzzle: ceph's 'containers' and
'orchestrator' / cephadm / 'ceph orch' concept.
For some time, as freeipa, ceph relied on packages and 'dependency hell
management' to operate as native packages across hosts connected on an
internal network. Then in a very effective shift: they treated 'the
contents of a container' much as 'one thing owned entirely by and
released by ceph' and tested that -- each container housing known-good
versions of dependent and third party modules as well as their own code
-- 'as one thing', to the point of providing their own tool to
'download and manage upgrade installs in the proper sequence' across
hosts providing this-or-that functionality.
You might imagine a freeipa orchestrator upgrading masters and replicas
in the correct order, freeipa devs knowing for certain-sure that no 'dnf
upgrade' on the host will disrupt the setup that passed qa in the
container... Will not 'corrupt a database' owing to a 'sync' with
content one version understood but another did not, etc.
Over these many months, while freeipa has struggled to provide
consistent service and value, ceph has been working nearly flawlessly
across many upgrade cycles and I think it's because ceph controls the
versions of the subsystems in the containers-- and that improves QA and
dramatically limits surprise breakages' that lead to the feeling of
'always catching up' under conditions of time pressure owing to down
services, this or that distro's 100 package mantainers deciding when/if
to include this/that patch and when to publish which new version, which
are 'security updates', which are 'bug fix updates', etc. If freeipa
server came in a container that was tested and QA'd as a container,
deployed as a container, perhaps the 'fragility factor' would improve by
10x.
My $0.02
2 years, 4 months
ipa-replica-install failing - operations error: the changelog directory already exists and is not empty
by Sinh Lam
Hi Everyone -
I’m running into this odd issue I can’t seem to find a resolution to. Long
story short, my IPA master was on a system that had a power failure. Upon
bring up, the dirsrv failed to start up due to a zero byte dse.ldif file.
Used a “backup” of the file and my master seemed to have came back up ok
however replication seems to have stopped working.
When I noticed that replication wasn’t working from the replicas to the
master I went digging and found this (which led me to try to recover by
removing the old replicas and trying to do a reinstall) :
replica.domain.net: replica
last update status: Error (6) Replication error acquiring replica: Unable
to acquire replica: there is no replicated area on the consumer server.
Replication is aborting. (no such replica)
last update ended: 2021-05-20 15:29:28+00:00
The above “last update” corresponds with the power outage that took down
the IPA master.
I’m trying to re-initialize the replication by doing a reinstall of the
replica server but I’m failing with the following error :
Disabled p11-kit-proxy
Configuring directory server (dirsrv). Estimated time: 30 seconds
[1/42]: creating directory server instance
[2/42]: configure autobind for root
[3/42]: tune ldbm plugin
[4/42]: stopping directory server
[5/42]: updating configuration in dse.ldif
[6/42]: starting directory server
[7/42]: adding default schema
[8/42]: enabling memberof plugin
[9/42]: enabling winsync plugin
[10/42]: configure password logging
[11/42]: configuring replication version plugin
[12/42]: enabling IPA enrollment plugin
[13/42]: configuring uniqueness plugin
[14/42]: configuring uuid plugin
[15/42]: configuring modrdn plugin
[16/42]: configuring DNS plugin
[17/42]: enabling entryUSN plugin
[18/42]: configuring lockout plugin
[19/42]: configuring topology plugin
[20/42]: creating indices
[21/42]: enabling referential integrity plugin
[22/42]: configuring certmap.conf
[23/42]: configure new location for managed entries
[24/42]: configure dirsrv ccache and keytab
[25/42]: enabling SASL mapping fallback
[26/42]: restarting directory server
[27/42]: creating DS keytab
[28/42]: ignore time skew for initial replication
[29/42]: setting up initial replication
[error] DatabaseError: Operations error: The changelog directory
[/var/lib/dirsrv/slapd-REPLICA-DOMAIN-NET/cldb] already exists and is not
empty. Please choose a directory that does not exist or is empty.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Operations error: The changelog directory
[/var/lib/dirsrv/slapd-REPLICA-DOMAIN-NET/cldb] already exists and is not
empty. Please choose a directory that does not exist or is empty.
The ipa-replica-install command failed. See /var/log/ipareplica-install.log
for more information
I’ve since done several uninstalls and verified at each uninstall the
/var/lib/dirsrv directory is empty.
Any pointers on how to get past this issue would be great since I have
about 10 more replicas to get back up.
Thanks.
Sinh
2 years, 4 months
groups imported incorrectly (made compat tree look out of sync memberUid)
by Scott Serr
A few months ago, using IPA 4.8.7, I imported users and groups from
OpenLDAP:
ipa -v migrate-ds --with-compat \
--bind-dn="cn=Manager,dc=example,dc=com" \
--user-container="ou=People,dc=example,dc=com" \
--user-objectclass="posixAccount" \
--group-container="ou=Group,dc=example,dc=com" \
--group-objectclass="posixGroup" \
--group-overwrite-gid \
--schema=RFC2307 \
ldap://openldap-server:389
Now, I've found a problem...
In addition to the expected "member" attribute list on the group dn, I
also have a memberUid attribute list. These memberUid attributes are
not created when using IPA to assign users to groups, just during my import.
An imported user:
dn: cn=wahoo,cn=groups,cn=accounts,dc=example,dc=com
member: uid=fred,cn=users,cn=accounts,dc=example,dc=com
memberUid: fred
dn: cn=wahoo,cn=groups,cn=compat,dc=example,dc=com
memberUid: fred
So, no harm done yet. Then I remove fred from the group wahoo. And I
end up with this:
dn: cn=wahoo,cn=groups,cn=accounts,dc=example,dc=com
memberUid: fred
dn: cn=wahoo,cn=groups,cn=compat,dc=example,dc=com
memberUid: fred
Now, anything pointing to my compat tree, still thinks fred is in the
wahoo group.
The solution is removing the memberUids from the
cn=groups,cn=accounts,dc=example,dc=com tree, and the compat tree
automatically reflects that change.
Question:
Is this a bug or did I do something wrong on the import?
Thanks,
Scott
PS- If someone else runs into this, I hope I saved you time.
2 years, 4 months
Re: IPA Reinstall
by Robert.Mattson＠L3Harris.com
Hi Florence,
Thank you for taking the time to respond.
We have a number of replicas in various campus locations around our region, and our state and country is currently locked-down with COVID restrictions, and it would take days to get to the replicas even without restrictions. We have had wide-scale WAN outages over weeks for this system.
To describe our problem in a simplified manner;
We had the IPA replicas ‘Location1R1’ and ‘Location2R1’ talking happily when the WAN between them went away, while it was down we added ‘Location2R2’ to ‘Location2R1’, and manually added some user-ranges for accounts at Location2. We also added a number of ipa-clients at Location2. When the WAN came back, ‘Location1R1’ and ‘Location2R1’ stopped sharing data because the CSN updates were dropped weeks ago. We re-initialized ‘Location2R1’ from ‘Location1R1’, however that has resulted in isolation of ‘Location2R2’. Most logins at Location2 fail, depending on where the DNS round-robin points SSSD at the time of login.
We have multiple locations, each with a flavor of this issue. No replica has a complete picture of all replication agreements, host accounts and user accounts. Though we have had some success with continually re-initializing replicas.
It was my hope, once the WAN was stabilized to remove and re ipa-server-install at our first server, then remove and re-run ipa-client-install then ipa-replica-install at each secondary server. I believe this would re-constitute the system, effectively by re-installation of that specific service. And yes, this would all be done via SSH.
However, we meet the obstacles described in my initial email when performing the install a second time.
Sincerely, and with many thanks in advance,
Rob
From: Florence Renaud via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
Sent: Wednesday, 2 June 2021 2:16 AM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Mattson, Robert (FP) <Robert.Mattson(a)L3Harris.com>; Florence Renaud <flo(a)redhat.com>
Subject: [EXTERNAL] [Freeipa-users] Re: IPA Reinstall
Hi,
the recommended way to uninstall a replica and reinstall it is described in the doc:
1. Uninstall the replica (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...) with ipa server-del and ipa-server-install --uninstall
2. re-install the replica as if it was a new one: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
Was there any reason to backup files and restore them? The replica installation should re-create everything.
flo
On Wed, May 26, 2021 at 7:32 AM Robert.Mattson--- via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> wrote:
Dear Community,
I'd like to uninstall and reinstall IPA from a CentOS box because its easier than reinstalling the OS completely.
We have a number of replicas, and this host is installed using ipa-client-install and then ipa-replica-install.
To remove it, I backup some data like /var/kerberos/krb5kdc/{cacert.pem,kd*} and /etc/httpd/conf/password.conf
and then run '/usr/sbin/ipa-server-install --uninstall -U --ignore-topology-disconnect'.
I then sed '/Environment=K/d', '/ExecStartPre/d', '/ExecStopPost/d' /etc/systemd/system/httpd.service
I recreate the host-account on another replica using ipa host-add, then ipa hostgroup-add-member.
On the now-removed host, I do some housekeeping like restoring the backed up files and then I run;
/usr/sbin/ipa-client-install \
--password=${otp} \
--mkhomedir \
--no-ntp \
--unattended \
--domain=realm.name<http://realm.name> \
--realm=REALM.NAME<http://REALM.NAME> \
--ca-cert-file=/etc/pki/ca-trust/source/ca.crt
then
/usr/sbin/ipa-replica-install \
--dirsrv-cert-file=/etc/pki/tls/private/ipa.pkcs12 \
--http-cert-file=/etc/pki/tls/private/ipa.pkcs12 \
--dirsrv-pin=pwd \
--http-pin=pwd \
--unattended \
--no-pkinit \
--no-ntp
I seem to get the following keytab request problem followed by dirsrv failure. from ipa-replica-install (4.6.4-10.el7.centos.3.x86_64). If I upgrade to 4.6.8-5.el7.centos.4.noarch.rpm, I get the same problem.[1]
On serverb, the host which receives the binding request for the reinstall, I get permission denied the bind dn “” does not have permission in dirsrv error log…?
Does anyone have any thoughts,
Cheers and many thanks in advance,
Rob
[1]
2021-05-26T02:50:56Z DEBUG Backing up system configuration file '/etc/httpd/conf.d/ipa.conf'
2021-05-26T02:50:56Z DEBUG -> Not backing up - '/etc/httpd/conf.d/ipa.conf' doesn't exist
2021-05-26T02:50:56Z DEBUG Backing up system configuration file '/etc/httpd/conf.d/ipa-rewrite.conf'
2021-05-26T02:50:56Z DEBUG -> Not backing up - '/etc/httpd/conf.d/ipa-rewrite.conf' doesn't exist
2021-05-26T02:50:56Z DEBUG duration: 0 seconds
2021-05-26T02:50:56Z DEBUG [10/21]: setting up httpd keytab
2021-05-26T02:50:56Z DEBUG raw: service_add(u'HTTP/servera.system(a)REALM.NAME<mailto:servera.system@REALM.NAME>', force=True, version=u'2.230')
2021-05-26T02:50:56Z DEBUG service_add(ipapython.kerberos.Principal('HTTP/servera.system(a)REALM.NAME<mailto:servera.system@REALM.NAME>'), force=True, all=False, raw=False, version=u'2.230', no_members=False)
2021-05-26T02:50:56Z DEBUG flushing ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket from SchemaCache
2021-05-26T02:50:56Z DEBUG retrieving schema for SchemaCache url=ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f0d29f50368>
2021-05-26T02:50:57Z DEBUG raw: host_show(u'servera.system', version=u'2.230')
2021-05-26T02:50:57Z DEBUG host_show(u'servera.system', rights=False, all=False, raw=False, version=u'2.230', no_members=False)
2021-05-26T02:50:57Z DEBUG Backing up system configuration file '/var/lib/ipa/gssproxy/http.keytab'
2021-05-26T02:50:57Z DEBUG -> Not backing up - '/var/lib/ipa/gssproxy/http.keytab' doesn't exist
2021-05-26T02:50:57Z DEBUG Starting external process
2021-05-26T02:50:57Z DEBUG args=/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL
2021-05-26T02:50:57Z DEBUG Process finished, return code=9
2021-05-26T02:50:57Z DEBUG stdout=
2021-05-26T02:50:57Z DEBUG stderr=Failed to parse result: unsupported extended operation
Retrying with pre-4.0 keytab retrieval method...
Failed to parse result: unsupported extended operation
Failed to get keytab!
Failed to get keytab
2021-05-26T02:50:57Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 637, in request_service_keytab
super(HTTPInstance, self).request_service_keytab()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab
self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab
ipautil.run(args, nolog=nolog)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))
CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z DEBUG [error] CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 319, in run
return cfgr.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 364, in run
return self.execute()
exc_handler(exc_info)
<snip />
File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 65, in _install
for unused in self._installer(self.parent):
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/__init__.py", line 622, in main
replica_install(self)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 406, in decorated
func(installer)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1487, in install
fstore=fstore)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 173, in install_http
subject_base=config.subject_base, master_fqdn=config.master_host_name)
File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 188, in create_instance
self.start_creation()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 637, in request_service_keytab
super(HTTPInstance, self).request_service_keytab()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab
self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab
ipautil.run(args, nolog=nolog)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))
2021-05-26T02:50:57Z DEBUG The ipa-replica-install command failed, exception: CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z ERROR Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
[2]
[26/May/2021:12:50:47.240285166 +1000] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meToservera.system" (servera:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica.
[26/May/2021:12:50:47.858057379 +1000] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=meToservera.system" (servera:389)".
[26/May/2021:12:50:50.679652092 +1000] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=meToservera.system" (servera:389)". Sent 582 entries.
[26/May/2021:12:50:52.158394667 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
[26/May/2021:12:50:55.079367688 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
[26/May/2021:12:50:58.084381230 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
[26/May/2021:12:51:01.092727541 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@lists.fedorahosted.org>
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2 years, 4 months
custom tls certtificate for web UI
by iulian roman
Hello everybody,
I tried to change the WEB UI certificate with a custom certificate signed by our internal CA. The custom certificate was provided as a bundle (certificate + intermediates). The root ca which signs the intermediate was added in the truststore with ipa-cacert-manage.
Everything was successful but when I accessed the Web UI I noticed that IPA provides only the certificate, not the full chain, which makes the certificate not trusted by the browsers (they are configured to trust only our internal root ca).
Is there any method to configure IPA/Idm to provide the full certificate chain (certificate + intermediate) to the http clients or is there anything I configured wrong ?
2 years, 4 months
cleanup of removed masters
by Stijn De Weirdt
hi all,
our ipa-healthcheck gives some seemingly odd output:
> Internal server error HTTPSConnectionPool(host='oldm2.domain', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f32581cb748>: Failed to establish a new connection: [Errno -2] Name or service not known',))
> [
> {
> "source": "pki.server.healthcheck.clones.connectivity_and_data",
> "check": "ClonesConnectivyAndDataCheck",
> "result": "ERROR",
> "uuid": "c7694559-157f-42da-9722-29ab4308d8bc",
> "when": "20210601115956Z",
> "duration": "0.424097",
> "kw": {
> "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: oldm2.domain Port: 443"
> }
> },
googling the error itself, i find references to this being a false
positive; but looking closer (and also the initial server error) give an
actual error: they reference an old master (it's obviously not called
oldm2, so i had to read it a few times to see it was actually this old
host).
a while ago we migrated our centos7 setup (oldm1 and oldm2) to rhel82
(newm3 and newm4), by following the migration guide
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
i'm quite sure we followed all steps, including the final uninstall on
oldm1 and oldm2.
however, after starting to run ipa-healthcheck recently and seeing this
error, we looked for other traces of the old servers and started to
clean them up. the old hosts are no longer around, so no chance to rerun
things or check logs.
so far we removed a bunch of DNS entries where the oldm1 was still used,
but we now also have some other ones that reference oldm2: e.g. the pki
related error above, but also oldm2 is still referenced in some entries
in our dirserv dse.ldif (2 nsslapd-referral, 3 nsds50ruv and 3
nsruvReplicaLastModified). the traces are only of oldm2, not sign of
oldm1 there.
i'd appreciate some tips/guidance for removing the pki reference to
oldm2 and things we can do to cleanup the dse.ldif
many many thanks,
stijn
2 years, 4 months
IPA Reinstall
by Robert.Mattson＠L3Harris.com
Dear Community,
I'd like to uninstall and reinstall IPA from a CentOS box because its easier than reinstalling the OS completely.
We have a number of replicas, and this host is installed using ipa-client-install and then ipa-replica-install.
To remove it, I backup some data like /var/kerberos/krb5kdc/{cacert.pem,kd*} and /etc/httpd/conf/password.conf
and then run '/usr/sbin/ipa-server-install --uninstall -U --ignore-topology-disconnect'.
I then sed '/Environment=K/d', '/ExecStartPre/d', '/ExecStopPost/d' /etc/systemd/system/httpd.service
I recreate the host-account on another replica using ipa host-add, then ipa hostgroup-add-member.
On the now-removed host, I do some housekeeping like restoring the backed up files and then I run;
/usr/sbin/ipa-client-install \
--password=${otp} \
--mkhomedir \
--no-ntp \
--unattended \
--domain=realm.name \
--realm=REALM.NAME \
--ca-cert-file=/etc/pki/ca-trust/source/ca.crt
then
/usr/sbin/ipa-replica-install \
--dirsrv-cert-file=/etc/pki/tls/private/ipa.pkcs12 \
--http-cert-file=/etc/pki/tls/private/ipa.pkcs12 \
--dirsrv-pin=pwd \
--http-pin=pwd \
--unattended \
--no-pkinit \
--no-ntp
I seem to get the following keytab request problem followed by dirsrv failure. from ipa-replica-install (4.6.4-10.el7.centos.3.x86_64). If I upgrade to 4.6.8-5.el7.centos.4.noarch.rpm, I get the same problem.[1]
On serverb, the host which receives the binding request for the reinstall, I get permission denied the bind dn "" does not have permission in dirsrv error log...?
Does anyone have any thoughts,
Cheers and many thanks in advance,
Rob
[1]
2021-05-26T02:50:56Z DEBUG Backing up system configuration file '/etc/httpd/conf.d/ipa.conf'
2021-05-26T02:50:56Z DEBUG -> Not backing up - '/etc/httpd/conf.d/ipa.conf' doesn't exist
2021-05-26T02:50:56Z DEBUG Backing up system configuration file '/etc/httpd/conf.d/ipa-rewrite.conf'
2021-05-26T02:50:56Z DEBUG -> Not backing up - '/etc/httpd/conf.d/ipa-rewrite.conf' doesn't exist
2021-05-26T02:50:56Z DEBUG duration: 0 seconds
2021-05-26T02:50:56Z DEBUG [10/21]: setting up httpd keytab
2021-05-26T02:50:56Z DEBUG raw: service_add(u'HTTP/servera.system(a)REALM.NAME', force=True, version=u'2.230')
2021-05-26T02:50:56Z DEBUG service_add(ipapython.kerberos.Principal('HTTP/servera.system(a)REALM.NAME'), force=True, all=False, raw=False, version=u'2.230', no_members=False)
2021-05-26T02:50:56Z DEBUG flushing ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket from SchemaCache
2021-05-26T02:50:56Z DEBUG retrieving schema for SchemaCache url=ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f0d29f50368>
2021-05-26T02:50:57Z DEBUG raw: host_show(u'servera.system', version=u'2.230')
2021-05-26T02:50:57Z DEBUG host_show(u'servera.system', rights=False, all=False, raw=False, version=u'2.230', no_members=False)
2021-05-26T02:50:57Z DEBUG Backing up system configuration file '/var/lib/ipa/gssproxy/http.keytab'
2021-05-26T02:50:57Z DEBUG -> Not backing up - '/var/lib/ipa/gssproxy/http.keytab' doesn't exist
2021-05-26T02:50:57Z DEBUG Starting external process
2021-05-26T02:50:57Z DEBUG args=/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL
2021-05-26T02:50:57Z DEBUG Process finished, return code=9
2021-05-26T02:50:57Z DEBUG stdout=
2021-05-26T02:50:57Z DEBUG stderr=Failed to parse result: unsupported extended operation
Retrying with pre-4.0 keytab retrieval method...
Failed to parse result: unsupported extended operation
Failed to get keytab!
Failed to get keytab
2021-05-26T02:50:57Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 637, in request_service_keytab
super(HTTPInstance, self).request_service_keytab()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab
self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab
ipautil.run(args, nolog=nolog)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))
CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z DEBUG [error] CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 319, in run
return cfgr.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 364, in run
return self.execute()
exc_handler(exc_info)
<snip />
File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 65, in _install
for unused in self._installer(self.parent):
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/__init__.py", line 622, in main
replica_install(self)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 406, in decorated
func(installer)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1487, in install
fstore=fstore)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 173, in install_http
subject_base=config.subject_base, master_fqdn=config.master_host_name)
File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 188, in create_instance
self.start_creation()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 637, in request_service_keytab
super(HTTPInstance, self).request_service_keytab()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab
self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab
ipautil.run(args, nolog=nolog)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))
2021-05-26T02:50:57Z DEBUG The ipa-replica-install command failed, exception: CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z ERROR Command '/usr/sbin/ipa-getkeytab -k /var/lib/ipa/gssproxy/http.keytab -p HTTP/servera.system(a)REALM.NAME<mailto:HTTP/servera.system@REALM.NAME> -H ldapi://%2Fvar%2Frun%2Fslapd-REALM-NAME.socket -Y EXTERNAL' returned non-zero exit status 9
2021-05-26T02:50:57Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
[2]
[26/May/2021:12:50:47.240285166 +1000] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meToservera.system" (servera:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica.
[26/May/2021:12:50:47.858057379 +1000] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=meToservera.system" (servera:389)".
[26/May/2021:12:50:50.679652092 +1000] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=meToservera.system" (servera:389)". Sent 582 entries.
[26/May/2021:12:50:52.158394667 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
[26/May/2021:12:50:55.079367688 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
[26/May/2021:12:50:58.084381230 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
[26/May/2021:12:51:01.092727541 +1000] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToservera.system" (servera:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
2 years, 4 months
