Got it Rob, once again thanks a lot for your help and effort following up on
this matter.
For a final question, is there any way I could move that existing range from
server IDM to the server NS1?
I imagine that by simply having the one range on that server would fix the
issue too?
Best regard
I was under the impression replicas could be added and not have replication
agreements with every other master hence I assumed this wouldn't be a problem.
And truth be told until the fallback group step the replica installation goes
well so I guess it should be possible if it wasn't for the dns
Hi Rob,
Thank you for your reply and I'm sorry for the delay in getting back to you.
So as instructed we changed the cn=config nsslapd-errorlog-level on the master
replica ns1 to 8192 and used 65536 on the replica being added.
I've added them to gists as they're too big:
ns1 master 389ds log:
h
Hi Rob, once again thank you for your time and effort following up on this.
First and regarding the --skip-conncheck the answer is no, I'm not using skip
conncheck.
The process I'm using to add the replica is:
1. ipa-client-install
2. on ns1 add ns3 to ipaservers group
3. ipa-replica-install --se
Hi Rob thank you for your replies.
So I tried to add the replica again in order to get the 389-ds logs.
Regarding the ipa versions:
[root@ns1 ~]# rpm -q ipa-server ipa-client 389-ds-base pki-ca krb5-server
ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64
ipa-client-4.9.6-10.module+el8.5.
Hi,
I was out for a couple of weeks and this stood on standby. Checking the
dnarange:
# ipa-replica-manage dnarange-show
Directory Manager password:
idm.dom0.io: 156226-156239
ns1.dom0.io: No range set
ns2.dom0.io: No range set
# ipa idrange-find
---
1 range matched
Hi Rob thank you for your reply.
# ipa-replica-manage dnarange-show
Directory Manager password:
idm.dom0.io: 156226-156239
ns1.dom0.io: No range set
ns2.dom0.io: No range set
ns3.dom0.io: Connection failed: cannot connect to 'ldaps://ns3.dom0.io:636':
Transport endpoint is not
I'm sorry I forgot the OS and ida version - latest updates
# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.5 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.5 (Ootpa)"
# ipa --version
VERSION: 4.9.6, API_VER
Hi there,
I'm unable to add a new replica to the cluster as it fails:
Configuring SID generation
[1/8]: creating samba domain object
Samba domain object already exists
[2/8]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
[3/8]: addi
Hi Rob,
Thank you for the feedback, the "secret" and "requiredSecret" in server.xml had
different values, I checked for the correct value in
/etc/httpd/conf.d/ipa-pki-proxy.conf and did fix it.
Cheers!
___
FreeIPA-users mailing list -- freeipa-users@l
Hi Rob thank you for your reply and I'm sorry for the missing information.
Everything is up to date latest available
# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.5 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise L
Hi,
I'm having an issue where I can't remove an host due to the error:
"Operation Error
Some entries were not deleted
Show details:
- Certificate operation cannot be completed: Unable to communicate with CMS
(403)"
getcert list
Number of certificates and requests being tracked: 9.
Request ID '2
Hi all,
Came around to post the definite fix for my problem, don't know if it will help
anyone since it was all a mess.
As mentioned previously:
> There's the expected "slapd-DOMAIN-IO" but I also have a
> "try_ca_renew-slapd-DOMAIN-IO" dir dated from 8 of June that resembles a
> copy of "sl
he master (they don't seem to be working anyway), remove
the DNS entries and then try to replicate from id01 solely, don't know
if that would work either because the references to DNSSEC Key Master
and CA Master still exist on that replica anyway so probably would fail.
Ricardo
Hello again Rob,
I really would like to express my appreciation for the feedback you've
been giving and trying to help man really amazing!
I have detailed some of the issues I'm going through now here:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/I5
Hi all,
We've had problems with our master IPA server, the issue was the second
master-replica died due to an issue with the hypervisor and we lost access to
the first master as the Let's Encrypt certificates expired.
In the meanwhile we got to renew some certificates but the CA master
function
Hi Rob,
Thank you for all your help so far I haven't write back before, I've
been swamped.
Ok so I was going kinda crazy about the lost access to ldap. In the
meanwhile we got developments on the server that had the freeipa replica
and this is back up.
So now I have this:
- Master is malfunc
Hi Rob once again many thanks for helping!
My guess is that the LE CA certificates are not trusted by the NSS
database that dogtag uses. Assuming you've added those CA certificates
to IPA using ipa-cacert-manage install then running ipa-certupdate
should fix things for you.
rob
I think the LE
You're totally right. I feel dumb.
Ok so I did the following:
I edited the renew-le.sh and replaced the cert name but the line that
adds the cert again
"certutil -A -d ... -n Server-Cert"
Edited /etc/httpd/conf.d/nss.conf and changed the NSSNickname
But I still can't start pki-tomcatd:
# sy
Hi Rob thanks for your message.
Right the cert nickname is CN=main.domain.io. I'm assuming you manually
installed the LE certs originally using ipa-server-certinstall right?
That doesn't follow the pattern of using Server-Cert for the nickname by
default.
Iirc I used the antevens/letsencrypt
the freeipa-letsencrypt commit 601f03b before "Move from mod_nss
to mod_ssl". Not sure what to do next.
On 11/06/2020 08:31, Florence Blanc-Renaud wrote:
On 6/10/20 8:42 PM, Ricardo Mendes via FreeIPA-users wrote:
Hi Rob,
Thanks a lot for your reply.
It's because you are in t
find certificate named "Server-Cert":
PR_FILE_NOT_FOUND_ERROR: File not found
certutil: Server-Cert is neither a key-type nor a nickname nor a key-id:
SEC_ERROR_INVALID_ARGS: security library: invalid arguments.
(btw https://lists.fedoraproject.org is down)
Ricardo Mendes via FreeIPA-u
>I think you need to see what certs and keys are in /etc/httpd/alias.
> Sounds like there is no Server-Cert nickname.
certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
This is the output, and I'm adding getcert list in
Ok so I don't know what happened the server really did take a long time to come
up but it did.
Everything looks pretty much the same. The setup-le.sh command I ran that said
> The ipa-certupdate command was successful
But I can't see it. I have to start ipa services with --ignore-service-failu
Hi Rob,
Thanks a lot for your reply.
> It's because you are in the middle of an upgrade. You can add
> --skip-version-check to not do the upgrade until after the certs are renewed.
Amazing! So I turned back the clock and:
# ipactl restart --ignore-service-failure --skip-version-check
Skipping
Hi Florence,
Thank you so much for your reply.
I have some questions regarding your instructions.
1. ipactl start --ignore-service-failures doesn't work, it leaves most services
down and I must use systemctl to bring them up.
# sudo ipactl restart --ignore-service-failures
IPA version error: d
# certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca
Hi all,
I'm having serious issues with our FreeIPA setup and I need some direction.
Our FreeIPA setup had two master-replicas. Late last month one of the
hypervisors at OVH died, they replaced hardware but the server is having issues
so hasn't come up yet. So for all matters, one master-replica
28 matches
Mail list logo
