[Freeipa-users] Re: Problems after replacing SSL certificates
I noticed a weird "ipa" directly appended to the host URL. Not sure where this is coming from... ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: Problems after replacing SSL certificates
This is what the Apache error log shows:
[Mon Apr 20 20:40:32.719986 2020] [wsgi:error] [pid 24934:tid 139866966574848]
[remote 141.58.21.12:59320] ipa: INFO: 401 Unauthorized:
HTTPSConnectionPool(host='Xipa', port=443): Max retries exceeded with url:
/session/cookie (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or
service not known'))
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: Problems after replacing SSL certificates
> Andreas Bulling via FreeIPA-users wrote: > > You have a chicken and egg problem. When replacing your certs on an > existing infrastructure you first have to add your new CA certs using > ipa-cacert-manage, then run ipa-certupdate on all enrolled machines, > including masters, then you can run ipa-servercert-install to replace them. This seems to be the routine described on the freeipa page - which I followed except for running ipa-certupdate on all enrolled machines prior to ipa-servercert-install. The documentation doesn't mention this, should probably be fixed before more people end up in this situation. Is there any way for me to fix this? client uninstall and reinstall? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: Problems after replacing SSL certificates
Andreas Bulling via FreeIPA-users wrote:
> Dear all,
>
> I have recently started using FreeIPA (4.8.1 on Ubuntu) and now wanted to
> replace the original SSL certificates for the web UI and the LDAP server with
> official ones issued by our university.
>
> I've followed the procedure described here (no errors):
> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>
> I could confirm in the browser that the certificate for the web UI has been
> replaced and I therefore assume so has the LDAP certificate. Authentication
> from other hosts/services using LDAP still works but in the server log file I
> see errors like these for all hosts in the domain:
>
> Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25
> 26}) X: NEEDED_PREAUTH: host/X@X for krbtgt/X@X, Additional
> pre-authentication required
> Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
> Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25
> 26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X
> for krbtgt/X@X
> Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
> Apr 20 19:57:11 auth krb5kdc[24895]: TGS_REQ (8 etypes {18 17 20 19 16 23 25
> 26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X
> for ldap/X@X
> Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
>
> Also, ipa-certupdate on the respective clients shows
>
> ipa-certupdate
> trying https://X/ipa/json
> [try 1]: Forwarding 'schema' to json server 'https://X/ipa/json'
> cannot connect to 'https://X/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED]
> certificate verify failed (_ssl.c:727)
> The ipa-certupdate command failed.
>
> Also, I can't login to the web UI anymore. I tried
>
> ipa-getkeytab -s X -p HTTP/X@X -k /var/lib/ipa/gssproxy/http.keytab
>
> on the freeipa server (followed by ipactl restart) but this didn't help.
Kerberos and TLS are separate crypto engines. Changing the certs
shouldn't affect it at all.
You have a chicken and egg problem. When replacing your certs on an
existing infrastructure you first have to add your new CA certs using
ipa-cacert-manage, then run ipa-certupdate on all enrolled machines,
including masters, then you can run ipa-servercert-install to replace them.
Otherwise your clients will not trust the CA that issued the new certs.
For the UI error I'd start with the apache error log for details.
rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Problems after replacing SSL certificates
Dear all,
I have recently started using FreeIPA (4.8.1 on Ubuntu) and now wanted to
replace the original SSL certificates for the web UI and the LDAP server with
official ones issued by our university.
I've followed the procedure described here (no errors):
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
I could confirm in the browser that the certificate for the web UI has been
replaced and I therefore assume so has the LDAP certificate. Authentication
from other hosts/services using LDAP still works but in the server log file I
see errors like these for all hosts in the domain:
Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25
26}) X: NEEDED_PREAUTH: host/X@X for krbtgt/X@X, Additional pre-authentication
required
Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25
26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X for
krbtgt/X@X
Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
Apr 20 19:57:11 auth krb5kdc[24895]: TGS_REQ (8 etypes {18 17 20 19 16 23 25
26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X for
ldap/X@X
Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
Also, ipa-certupdate on the respective clients shows
ipa-certupdate
trying https://X/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://X/ipa/json'
cannot connect to 'https://X/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed (_ssl.c:727)
The ipa-certupdate command failed.
Also, I can't login to the web UI anymore. I tried
ipa-getkeytab -s X -p HTTP/X@X -k /var/lib/ipa/gssproxy/http.keytab
on the freeipa server (followed by ipactl restart) but this didn't help.
Any idea/suggestions for how to get everything working again?
Thanks a lot!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: Sudo command not working
Hi i had this problem too. i studied all of these pages but it doesnt work and i had to stop working with IPA On Mon, 20 Apr 2020, 18:45 Rob Crittenden via FreeIPA-users, < freeipa-users@lists.fedorahosted.org> wrote: > Faraz Younus via FreeIPA-users wrote: > > Hi Team, > > I'm getting error when executing sudo su on client server what can be > > the issue sudo command is there > > > > [faraz.younus@england-web-dev ~]$ sudo su > > > > [sudo] password for faraz.younus: > > > > faraz.younus is not allowed to run sudo on england-web-dev. This > > incident will be reported. > > Start with these: > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/granting-sudo-access-to-an-idm-user-on-an-idm-client_configuring-and-managing-idm > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/troubleshooting-sudo > > https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html > > To help we'd need a lot more information: the distro of client and > server, the HBAC settings, what the SUDO rules are, logs, etc. > > rob > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 4/20/20 3:35 PM, Kees Bakker wrote: On 20-04-2020 15:16, thierry bordaz wrote: On 4/20/20 3:02 PM, Kees Bakker wrote: On 20-04-2020 14:51, Rob Crittenden wrote: Kees Bakker via FreeIPA-users wrote: On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: On 20-04-2020 09:09, Florence Blanc-Renaud wrote: On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs Hi, you can start by having a look at dirsrv error log in /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. The FAQ page of 389 also explains a few troubleshooting steps: http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting I did exactly that, look at the "errors" log, but there was no clue, at least not for me. Strange enough it kept running for a few hours and then it was hanging again. I tried the command "ipctl restart", but that was hanging forever. However "systemctl restart dirsrv@MY-DOMAIN" was able to restart it after several minutes. Meanwhile the sn-slapd process was using 100% CPU. Another remark I want to make. Every ldap connection (ldapsearch, whatever) hangs for ever. No timeout, nothing. When it rains, it pours, they say. There is another master with the same symptom. I'm getting nervous now. Thanks for the Troubleshooting link. I'll have to dive into the deep, I guess. Could it be a deadlock? [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): #0 0x7ff92943035e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 #1 0x7ff9190b6639 in backend_be_pre_write_cb () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so Without debuginfo the trace of these threads look like this: Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so #2 0x7ff9190b8745 in backend_search_cb () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so #3 0x7ff92bcd9028 in plugin_call_func () at /usr/lib64/dirsrv/libslapd.so.0 #4 0x7ff92bcd92e3 in plugin_call_plugins () at /usr/lib64/dirsrv/libslapd.so.0 #5 0x7ff92bccc0d7 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #6
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 20-04-2020 15:35, Kees Bakker via FreeIPA-users wrote: > On 20-04-2020 15:16, thierry bordaz wrote: >> On 4/20/20 3:02 PM, Kees Bakker wrote: >>> On 20-04-2020 14:51, Rob Crittenden wrote: Kees Bakker via FreeIPA-users wrote: > On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: >> On 20-04-2020 09:09, Florence Blanc-Renaud wrote: >>> On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs >>> Hi, >>> you can start by having a look at dirsrv error log in >>> /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. >>> >>> The FAQ page of 389 also explains a few troubleshooting steps: >>> http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting >> I did exactly that, look at the "errors" log, but there was no clue, at >> least >> not for me. Strange enough it kept running for a few hours and then it >> was hanging again. >> >> I tried the command "ipctl restart", but that was hanging forever. >> However "systemctl restart dirsrv@MY-DOMAIN" was able to restart >> it after several minutes. Meanwhile the sn-slapd process was using 100% >> CPU. >> >> Another remark I want to make. Every ldap connection (ldapsearch, >> whatever) >> hangs for ever. No timeout, nothing. >> >> When it rains, it pours, they say. There is another master with the same >> symptom. >> I'm getting nervous now. >> >> Thanks for the Troubleshooting link. I'll have to dive into the deep, I >> guess. > Could it be a deadlock? > > [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt > Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at > /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > -- > Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at > /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > -- > Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at > /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > -- > Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): > #0
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 20-04-2020 15:16, thierry bordaz wrote: > On 4/20/20 3:02 PM, Kees Bakker wrote: >> On 20-04-2020 14:51, Rob Crittenden wrote: >>> Kees Bakker via FreeIPA-users wrote: On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: > On 20-04-2020 09:09, Florence Blanc-Renaud wrote: >> On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: >>> Hey, >>> >>> I'm looking for advice how to analyse/debug this. >>> >>> On one of the masters the dirsrv is unresponsive. It runs, but every >>> attempt to connect it hangs. >>> >>> The command "systemctl status" does not show anything alarming >>> >>> ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. >>> Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; >>> vendor preset: disabled) >>> Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h >>> 33min ago >>> Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl >>> /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) >>> Main PID: 3134 (ns-slapd) >>> Status: "slapd started: Ready to process requests" >>> CGroup: >>> /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service >>> └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM >>> -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid >>> >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 >>> apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 >>> >>> However, an ldapsearch command hangs forever >>> >>> [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D >>> uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o >>> ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com >>> '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' >>> uid >>> Enter LDAP Password: >>> >>> Even if I use the socket >>> (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch >>> command hangs. >>> >>> "ipactl status" hangs >>> >>> "kinit" hangs >>> >>> >> Hi, >> you can start by having a look at dirsrv error log in >> /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. >> >> The FAQ page of 389 also explains a few troubleshooting steps: >> http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting > I did exactly that, look at the "errors" log, but there was no clue, at > least > not for me. Strange enough it kept running for a few hours and then it > was hanging again. > > I tried the command "ipctl restart", but that was hanging forever. > However "systemctl restart dirsrv@MY-DOMAIN" was able to restart > it after several minutes. Meanwhile the sn-slapd process was using 100% > CPU. > > Another remark I want to make. Every ldap connection (ldapsearch, > whatever) > hangs for ever. No timeout, nothing. > > When it rains, it pours, they say. There is another master with the same > symptom. > I'm getting nervous now. > > Thanks for the Troubleshooting link. I'll have to dive into the deep, I > guess. Could it be a deadlock? [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): #0 0x7ff92943035e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 #1 0x7ff9190b6639 in backend_be_pre_write_cb () at
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 4/20/20 3:02 PM, Kees Bakker wrote: On 20-04-2020 14:51, Rob Crittenden wrote: *** EXTERNAL E-MAIL *** Kees Bakker via FreeIPA-users wrote: On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: On 20-04-2020 09:09, Florence Blanc-Renaud wrote: On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs Hi, you can start by having a look at dirsrv error log in /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. The FAQ page of 389 also explains a few troubleshooting steps: http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting I did exactly that, look at the "errors" log, but there was no clue, at least not for me. Strange enough it kept running for a few hours and then it was hanging again. I tried the command "ipctl restart", but that was hanging forever. However "systemctl restart dirsrv@MY-DOMAIN" was able to restart it after several minutes. Meanwhile the sn-slapd process was using 100% CPU. Another remark I want to make. Every ldap connection (ldapsearch, whatever) hangs for ever. No timeout, nothing. When it rains, it pours, they say. There is another master with the same symptom. I'm getting nervous now. Thanks for the Troubleshooting link. I'll have to dive into the deep, I guess. Could it be a deadlock? [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): #0 0x7ff92943035e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 #1 0x7ff9190b6639 in backend_be_pre_write_cb () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so Without debuginfo the trace of these threads look like this: Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so #2 0x7ff9190b8745 in backend_search_cb () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so #3 0x7ff92bcd9028 in plugin_call_func () at /usr/lib64/dirsrv/libslapd.so.0 #4 0x7ff92bcd92e3 in plugin_call_plugins () at /usr/lib64/dirsrv/libslapd.so.0 #5 0x7ff92bccc0d7 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #6 0x562454427bbe in do_search () #7 0x56245441595a in
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 20-04-2020 14:51, Rob Crittenden wrote: > *** EXTERNAL E-MAIL *** > > > Kees Bakker via FreeIPA-users wrote: >> On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: >>> On 20-04-2020 09:09, Florence Blanc-Renaud wrote: On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: > Hey, > > I'm looking for advice how to analyse/debug this. > > On one of the masters the dirsrv is unresponsive. It runs, but every > attempt to connect it hangs. > > The command "systemctl status" does not show anything alarming > > ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; > vendor preset: disabled) > Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min > ago >Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl > /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) > Main PID: 3134 (ns-slapd) > Status: "slapd started: Ready to process requests" > CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service > └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i > /var/run/dirsrv/slapd-EXAMPLE-COM.pid > > apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 > apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 > apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 > > However, an ldapsearch command hangs forever > > [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D > uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o > ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com > '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' > uid > Enter LDAP Password: > > Even if I use the socket > (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch > command hangs. > > "ipactl status" hangs > > "kinit" hangs > > Hi, you can start by having a look at dirsrv error log in /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. The FAQ page of 389 also explains a few troubleshooting steps: http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting >>> I did exactly that, look at the "errors" log, but there was no clue, at >>> least >>> not for me. Strange enough it kept running for a few hours and then it >>> was hanging again. >>> >>> I tried the command "ipctl restart", but that was hanging forever. >>> However "systemctl restart dirsrv@MY-DOMAIN" was able to restart >>> it after several minutes. Meanwhile the sn-slapd process was using 100% >>> CPU. >>> >>> Another remark I want to make. Every ldap connection (ldapsearch, whatever) >>> hangs for ever. No timeout, nothing. >>> >>> When it rains, it pours, they say. There is another master with the same >>> symptom. >>> I'm getting nervous now. >>> >>> Thanks for the Troubleshooting link. I'll have to dive into the deep, I >>> guess. >> Could it be a deadlock? >> >> [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt >> Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): >> #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 >> #1 0x7ff9190cc49c in map_rdlock () at >> /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >> -- >> Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): >> #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 >> #1 0x7ff9190cc49c in map_rdlock () at >> /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >> -- >> Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): >> #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 >> #1 0x7ff9190cc49c in map_rdlock () at >> /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >> -- >> Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): >> #0 0x7ff92943035e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 >> #1 0x7ff9190b6639 in backend_be_pre_write_cb () at >> /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >> >> Without debuginfo the trace of these threads look like this: >> >> Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): >> #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 >> #1 0x7ff9190cc49c in map_rdlock () at >>
[Freeipa-users] Re: Sudo command not working
Faraz Younus via FreeIPA-users wrote: > Hi Team, > I'm getting error when executing sudo su on client server what can be > the issue sudo command is there > > [faraz.younus@england-web-dev ~]$ sudo su > > [sudo] password for faraz.younus: > > faraz.younus is not allowed to run sudo on england-web-dev. This > incident will be reported. Start with these: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/granting-sudo-access-to-an-idm-user-on-an-idm-client_configuring-and-managing-idm https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/troubleshooting-sudo https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html To help we'd need a lot more information: the distro of client and server, the HBAC settings, what the SUDO rules are, logs, etc. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: dirsrv hangs soon after reboot
Kees Bakker via FreeIPA-users wrote: > On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: >> On 20-04-2020 09:09, Florence Blanc-Renaud wrote: >>> On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs >>> Hi, >>> you can start by having a look at dirsrv error log in >>> /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. >>> >>> The FAQ page of 389 also explains a few troubleshooting steps: >>> http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting >> I did exactly that, look at the "errors" log, but there was no clue, at least >> not for me. Strange enough it kept running for a few hours and then it >> was hanging again. >> >> I tried the command "ipctl restart", but that was hanging forever. >> However "systemctl restart dirsrv@MY-DOMAIN" was able to restart >> it after several minutes. Meanwhile the sn-slapd process was using 100% >> CPU. >> >> Another remark I want to make. Every ldap connection (ldapsearch, whatever) >> hangs for ever. No timeout, nothing. >> >> When it rains, it pours, they say. There is another master with the same >> symptom. >> I'm getting nervous now. >> >> Thanks for the Troubleshooting link. I'll have to dive into the deep, I >> guess. > > Could it be a deadlock? > > [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt > Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > -- > Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > -- > Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > -- > Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): > #0 0x7ff92943035e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 > #1 0x7ff9190b6639 in backend_be_pre_write_cb () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > > Without debuginfo the trace of these threads look like this: > > Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): > #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 > #1 0x7ff9190cc49c in map_rdlock () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > #2 0x7ff9190b8745 in backend_search_cb () at > /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > #3 0x7ff92bcd9028 in plugin_call_func () at >
[Freeipa-users] Sudo command not working
Hi Team, I'm getting error when executing sudo su on client server what can be the issue sudo command is there [faraz.younus@england-web-dev ~]$ sudo su [sudo] password for faraz.younus: faraz.younus is not allowed to run sudo on england-web-dev. This incident will be reported. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: ipa: ERROR: CIFS server communication error: code "3221225506", message "{Access Denied} A process has requested access to an object but has not been granted those access rights."
Hello, I know the thread is old, but I have the same problem. Were you able to find a solution? Any help would be helpful. Thank you! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 20-04-2020 09:58, Kees Bakker via FreeIPA-users wrote: > On 20-04-2020 09:09, Florence Blanc-Renaud wrote: >> On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: >>> Hey, >>> >>> I'm looking for advice how to analyse/debug this. >>> >>> On one of the masters the dirsrv is unresponsive. It runs, but every >>> attempt to connect it hangs. >>> >>> The command "systemctl status" does not show anything alarming >>> >>> ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. >>> Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; >>> vendor preset: disabled) >>> Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago >>>Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl >>> /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) >>> Main PID: 3134 (ns-slapd) >>> Status: "slapd started: Ready to process requests" >>> CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service >>> └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i >>> /var/run/dirsrv/slapd-EXAMPLE-COM.pid >>> >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 >>> apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >>> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 >>> >>> However, an ldapsearch command hangs forever >>> >>> [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D >>> uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o >>> ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com >>> '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' >>> uid >>> Enter LDAP Password: >>> >>> Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) >>> the ldapsearch >>> command hangs. >>> >>> "ipactl status" hangs >>> >>> "kinit" hangs >>> >>> >> Hi, >> you can start by having a look at dirsrv error log in >> /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. >> >> The FAQ page of 389 also explains a few troubleshooting steps: >> http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting > I did exactly that, look at the "errors" log, but there was no clue, at least > not for me. Strange enough it kept running for a few hours and then it > was hanging again. > > I tried the command "ipctl restart", but that was hanging forever. > However "systemctl restart dirsrv@MY-DOMAIN" was able to restart > it after several minutes. Meanwhile the sn-slapd process was using 100% > CPU. > > Another remark I want to make. Every ldap connection (ldapsearch, whatever) > hangs for ever. No timeout, nothing. > > When it rains, it pours, they say. There is another master with the same > symptom. > I'm getting nervous now. > > Thanks for the Troubleshooting link. I'll have to dive into the deep, I guess. Could it be a deadlock? [root@linge ~]# grep -a1 '^#0.*lock' slapd-stacktrace.1587374239.txt Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 7 (Thread 0x7ff8f7255700 (LWP 14490)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 4 (Thread 0x7ff8f5a52700 (LWP 14493)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so -- Thread 2 (Thread 0x7ff92c355700 (LWP 15679)): #0 0x7ff92943035e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 #1 0x7ff9190b6639 in backend_be_pre_write_cb () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so Without debuginfo the trace of these threads look like this: Thread 23 (Thread 0x7ff8ff265700 (LWP 14474)): #0 0x7ff929430144 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #1 0x7ff9190cc49c in map_rdlock () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so #2 0x7ff9190b8745 in backend_search_cb () at /usr/lib64/dirsrv/plugins/schemacompat-plugin.so #3 0x7ff92bcd9028 in plugin_call_func () at /usr/lib64/dirsrv/libslapd.so.0 #4 0x7ff92bcd92e3 in plugin_call_plugins () at /usr/lib64/dirsrv/libslapd.so.0 #5 0x7ff92bccc0d7 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #6
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 20-04-2020 09:09, Florence Blanc-Renaud wrote: > On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: >> Hey, >> >> I'm looking for advice how to analyse/debug this. >> >> On one of the masters the dirsrv is unresponsive. It runs, but every >> attempt to connect it hangs. >> >> The command "systemctl status" does not show anything alarming >> >> ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. >> Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor >> preset: disabled) >> Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago >> Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl >> /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) >> Main PID: 3134 (ns-slapd) >> Status: "slapd started: Ready to process requests" >> CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service >> └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i >> /var/run/dirsrv/slapd-EXAMPLE-COM.pid >> >> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 >> apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 >> apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 >> >> However, an ldapsearch command hangs forever >> >> [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D >> uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no >> -b cn=users,cn=accounts,dc=example,dc=com >> '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' >> uid >> Enter LDAP Password: >> >> Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) >> the ldapsearch >> command hangs. >> >> "ipactl status" hangs >> >> "kinit" hangs >> >> > Hi, > you can start by having a look at dirsrv error log in > /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. > > The FAQ page of 389 also explains a few troubleshooting steps: > http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting I did exactly that, look at the "errors" log, but there was no clue, at least not for me. Strange enough it kept running for a few hours and then it was hanging again. I tried the command "ipctl restart", but that was hanging forever. However "systemctl restart dirsrv@MY-DOMAIN" was able to restart it after several minutes. Meanwhile the sn-slapd process was using 100% CPU. Another remark I want to make. Every ldap connection (ldapsearch, whatever) hangs for ever. No timeout, nothing. When it rains, it pours, they say. There is another master with the same symptom. I'm getting nervous now. Thanks for the Troubleshooting link. I'll have to dive into the deep, I guess. -- Kees ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: Bizarre behavior (SSO+MFA) asking for credentials on some servers, but with extra "specialness"
On Thu, Apr 16, 2020 at 12:19:57AM -0400, Michael S. Moody via FreeIPA-users wrote: > Good evening, > > First, thank you, again, for FreeIPA. I know I say it every time I send a > message to the list, but it's magic. > > We're running into an interesting situation where some of our hosts are > requesting a first/second factor, even once authenticated. > > Essentially, we SSH into a bastion host using MFA (PW+TOTP at the moment). > Once we're in, we're able to pretty reliably SSH to other hosts without > issue. However, we've got a few hosts that prompt for "First Factor/Second > Factor". We're able to authenticate against those hosts if we provide > credentials, but if we logout and log back in, we have to do it again. Hi, what is the expected behavior after you have logged into the bastion host? Is it that you can ssh to the other hosts without any prompts at all (authentication with ssh keys) or that you are only prompt for the password and not for both factors? bye, Sumit > > Interestingly, there's a host we can SSH to (bastion01 to dev-server02) > which we can then SSH to another (dev-server02 to dev-server01) and not be > prompted for credentials, but if we attempt to authenticate against it > directly from the bastion host, we get prompted (bastion01 to dev-server01). > > Similarly, we can hop onto other servers, no issues. I can SSH from a host > to another and then try to SSH again back (a circle) and get prompted > (bastion01 too dev-server02 to dev-server01 to bastion01) and it might > work, or it might not, depending on the host in question. It's the most > bizarre behavior I've ever seen with FreeIPA. > > Any guidance that you can provide is appreciated. > > Thanks in advance, > Michael S. Moody > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 4/20/20 8:28 AM, Kees Bakker via FreeIPA-users wrote: Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs Hi, you can start by having a look at dirsrv error log in /var/log/dirsrv-slapd-YOUR_DOMAIN/errors, and the journal. The FAQ page of 389 also explains a few troubleshooting steps: http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting HTH, flo ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] dirsrv hangs soon after reboot
Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv@EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs -- Kees Bakker pEpkey.asc Description: application/pgp-keys ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
