Re: [Freeipa-users] start and stop of ipa commands in systemd
Am 04.04.2016 um 09:06 schrieb Martin Babinsky: > On 04/01/2016 08:53 PM, Martin (Lists) wrote: >> Hallo >> >> I have a question regarding enabling/disabling separate ipa parts in >> systemd. Is it necessarry or required to have httpd, directory server, >> named memcache and all the other ipa services to be enabled in systemd? >> Or is it recomended to have only the main ipa service enabled (and all >> the other disabled)? >> >> Regards >> Martin >> > Hi Martin, > > ipa.service actually calls `ipactl` command which starts/stops all > individual components at once (dirsrv, http, kdc, kpasswd, memcache, > pki-tomcat etc.). All of these services (which are listed in `ipactl > status`) must be up and running for IPA server to work correctly in all > aspects. > > So in this sense 'ipa.service' is just an umbrella that groups all the > components of FreeIPA installation. > For starting and stopping all neccessarry parts this is OK. But if I have enabled some of these services directly in systemd (lets say memcached or the ldap server) does that make problems during startup or shutdown. May be it is just a coincidence, but I had several warnings (up to thousands) in the past from the LDAP Server at a simple restart of the server: DSRetroclPlugin - delete_changerecord: could not delete change record 553423 (rc: 32): 1 Time(s) An I have not found any reason for this. Therefore the question: can this be due to a false shutdown or startup sequence by systemd? Last time I run "ipactl stop" before restarting the server and had no such warnings. As I said may be its just a coincidence. I run ipa on a up to date fedora 23 server. Regards Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] start and stop of ipa commands in systemd
Hallo I have a question regarding enabling/disabling separate ipa parts in systemd. Is it necessarry or required to have httpd, directory server, named memcache and all the other ipa services to be enabled in systemd? Or is it recomended to have only the main ipa service enabled (and all the other disabled)? Regards Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] adding user to a group failed
Am 09.11.2015 um 19:38 schrieb Martin (Lists): > Hallo > > recently I tried to add a user to one of my groups, but this always > failed with the error message: This entry already exists. > > Of course does this entry (user) exists, but not in this group. and it > is not added. I tried to add this from web interface and command line > with the same result. > > I use freeipa version 4.1.4 on fedora 22 > > Anyone with a tip? > > Regards > Martin > Sorry for the noise, found it. I had a failing index (from yesterday reindex) and this prohibited every change to my ldap server. Regards Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] adding user to a group failed
Hallo recently I tried to add a user to one of my groups, but this always failed with the error message: This entry already exists. Of course does this entry (user) exists, but not in this group. and it is not added. I tried to add this from web interface and command line with the same result. I use freeipa version 4.1.4 on fedora 22 Anyone with a tip? Regards Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] thousands DSRetroclPlugin mesages
Am Freitag, 1. Mai 2015, 21:21:09 schrieb Martin: > Sorry, first post went to Ludwig only. Now to the list as well. > > Am 30.04.2015 um 13:36 schrieb Ludwig Krispenz: > >>> indicating that trimming works. > >> > >> As it seems my trimming is broken, at least partially. Is there > >> something I can adjust? > > > > no, it seems to be ok, IPA configures the "changelog maxage" as 2d, so > > if changelog trimming runs, it removes changes older than two days, then > > it "sleeps" for this time and then runs again, so the changes could pile > > up to four days, then get trimmed and so on ... > > > >>> you said "thousands" of messages, how frequent are they really ? > >> > >> On every reboot I got these messages. I do not get them during normal > >> opperation. > > > > how frequently do you reboot ? maybe you only see the trimming after > > startup > > I reboot with almost every kernel update for fedora 21 (so about every > month). > > >> Something odd I observed after the last two reboots: ns-slapd runs my > >> hard disk for several minutes (about 15 minutes) after the reboot. This > >> is the time it takes to log all these change record messages. > > So my question remains: What does the ldap server do with all these > data? Is it possible to run trimming manually before shutdown? Or can I > do some other things the get this messages away? > > >> Kindly > >> Martin OK, next step. After two reboots without this showing up I had the thousand changelog messages again. I am still wondering what I can do to reduce this. kindly Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] thousands DSRetroclPlugin mesages
Sorry, first post went to Ludwig only. Now to the list as well. Am 30.04.2015 um 13:36 schrieb Ludwig Krispenz: >>> indicating that trimming works. >> As it seems my trimming is broken, at least partially. Is there >> something I can adjust? > no, it seems to be ok, IPA configures the "changelog maxage" as 2d, so > if changelog trimming runs, it removes changes older than two days, then > it "sleeps" for this time and then runs again, so the changes could pile > up to four days, then get trimmed and so on ... >>> you said "thousands" of messages, how frequent are they really ? >> On every reboot I got these messages. I do not get them during normal >> opperation. > how frequently do you reboot ? maybe you only see the trimming after > startup I reboot with almost every kernel update for fedora 21 (so about every month). >> Something odd I observed after the last two reboots: ns-slapd runs my >> hard disk for several minutes (about 15 minutes) after the reboot. This >> is the time it takes to log all these change record messages. So my question remains: What does the ldap server do with all these data? Is it possible to run trimming manually before shutdown? Or can I do some other things the get this messages away? >> Kindly >> Martin >> -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] thousands DSRetroclPlugin mesages
Am 29.04.2015 um 15:43 schrieb Ludwig Krispenz: > > On 04/29/2015 03:17 PM, Martin (Lists) wrote: >> Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz: >>> On 04/26/2015 10:49 AM, Martin (Lists) wrote: >>>> Hallo >>>> >>>> after a reboot I get almost thousand of the following messages: >>>> >>>> DSRetroclPlugin - delete_changerecord: could not delete change record >>>> 128755 (rc: 32) >>> this message comes from changeglog trimming and means that an entry, >>> which should be purged does not exist (any more). >>> the retrocl maintains a first/lastchange and trinming starts at >>> firstchange. if for some reason (race ?) there is an attempt to try to >>> delete the same entry a second time this message should be logged. >>> since the changenumbers in the error message increases, I think >>> changelog trimming moves forward. you could do searches on >>> "cn=changelog" to verify that trimming works. >> changelog is part of the ldbm database plugin and contains several >> informations I don't understand (or understand partially). What kind of >> information should I look for? > the changelog keeps track of the changes applied to the database, a > typical entry looks like: > dn: changenumber=4,cn=changelog > objectClass: top > objectClass: changelogentry > changeNumber: 4 > targetDn: cn=tuser,ou=people,dc=example,dc=com > changeTime: 20140411093444Z > changeType: delete OK, I looked in the wrong directory. Now I have found many changelog entries, starting with number 152926 and ending with 155512 (ldapsearch states 2588 numEntries). Should that be that much? The oldest is about two days and an half old and it does not change within the last few minutes. > > each entry gets a DN made up from he changenumber, so your entries will > be named: > > dn: changenumber=61,cn=changelog > dn: changenumber=62,cn=changelog > dn: changenumber=63,cn=changelog > dn: changenumber=64,cn=changelog > > changenumbers start and are always incremented, changelog trimming > removes old entries (depending on config). > > so if you do a search like: > ldapsearch .. -b "cn=changelog" > the changenumber of the first entry rerurne should always increase, > indicating that trimming works. As it seems my trimming is broken, at least partially. Is there something I can adjust? > > you said "thousands" of messages, how frequent are they really ? On every reboot I got these messages. I do not get them during normal opperation. Something odd I observed after the last two reboots: ns-slapd runs my hard disk for several minutes (about 15 minutes) after the reboot. This is the time it takes to log all these change record messages. Kindly Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] thousands DSRetroclPlugin mesages
Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz: > > On 04/26/2015 10:49 AM, Martin (Lists) wrote: > > Hallo > > > > after a reboot I get almost thousand of the following messages: > > > > DSRetroclPlugin - delete_changerecord: could not delete change record > > 128755 (rc: 32) > this message comes from changeglog trimming and means that an entry, > which should be purged does not exist (any more). > the retrocl maintains a first/lastchange and trinming starts at > firstchange. if for some reason (race ?) there is an attempt to try to > delete the same entry a second time this message should be logged. > since the changenumbers in the error message increases, I think > changelog trimming moves forward. you could do searches on > "cn=changelog" to verify that trimming works. changelog is part of the ldbm database plugin and contains several informations I don't understand (or understand partially). What kind of information should I look for? I only have one server running by the way. Regards Martin > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] thousands DSRetroclPlugin mesages
Hallo after a reboot I get almost thousand of the following messages: DSRetroclPlugin - delete_changerecord: could not delete change record 128755 (rc: 32) The record number changes from 127600 up to 148400. What does this mean? I have searched the web but did not find any hint on this. I use Fedora 21 Server with current IPA packages (Version 4.1.4). Kindly Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Am 08.04.2015 um 10:57 schrieb Jakub Hrozek: > > > > > > > Most of the host can only communicate in the local net, which has not > > that much hosts (10). The wired ones are connected via GBit Network, > > wireless it is up to 150MBit. Server is a Xeon E3-1225 with 8GB Mem. All > > Systems have Fedora 21 installed > > Does it communicate with the same KDC as krb5_child? > Yep, same host, same port number. Currently I have only one IPA server running. Replication is on my todo list though. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Am 08.04.2015 um 10:27 schrieb Jakub Hrozek: > Can you run: > KRB5_TRACE=/dev/stderr kinit yourprinc@YOUR.REALM > > So that we can compare with the krb5_child.log you sent earlier? I > wonder if SSSD talks to a KDC that is slower or far away from your > client.. > This is my trace from kinit: [2422] 1428482081.62208: AS key obtained for encrypted timestamp: aes256-cts/61D1 [2422] 1428482081.62288: Encrypted timestamp (for 1428482081.868994): plain ***, encrypted *** [2422] 1428482081.62328: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [2422] 1428482081.62342: Produced preauth for next request: 133, 2 [2422] 1428482081.62379: Sending request (265 bytes) to MITTELERDE.DE [2422] 1428482081.62484: Sending initial UDP request to dgram 1.2.3.4:88 [2422] 1428482081.201814: Received answer (740 bytes) from dgram 1.2.3.4:88 [2422] 1428482081.201872: Response was from master KDC [2422] 1428482081.201905: Processing preauth types: 19 [2422] 1428482081.201914: Selected etype info: etype aes256-cts, salt "***", params "" [2422] 1428482081.201920: Produced preauth for next request: (empty) [2422] 1428482081.201929: AS key determined by preauth: aes256-cts/61D1 [2422] 1428482081.201973: Decrypted AS reply; session key is: aes256-cts/C464 [2422] 1428482081.201991: FAST negotiation: available [2422] 1428482081.202014: Initializing KEYRING:persistent:0:0 with default princ fr...@mittelerde.de [2422] 1428482081.202058: Removing fr...@mittelerde.de -> krbtgt/mittelerde...@mittelerde.de from KEYRING:persistent:0:0 [2422] 1428482081.202065: Storing fr...@mittelerde.de -> krbtgt/mittelerde...@mittelerde.de in KEYRING:persistent:0:0 [2422] 1428482081.202110: Storing config in KEYRING:persistent:0:0 for krbtgt/mittelerde...@mittelerde.de: fast_avail: yes [2422] 1428482081.202126: Removing fr...@mittelerde.de -> krb5_ccache_conf_data/fast_avail/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF: from KEYRING:persistent:0:0 [2422] 1428482081.202133: Storing fr...@mittelerde.de -> krb5_ccache_conf_data/fast_avail/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF: in KEYRING:persistent:0:0 [2422] 1428482081.202166: Storing config in KEYRING:persistent:0:0 for krbtgt/mittelerde...@mittelerde.de: pa_type: 2 [2422] 1428482081.202177: Removing fr...@mittelerde.de -> krb5_ccache_conf_data/pa_type/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF: from KEYRING:persistent:0:0 [2422] 1428482081.202184: Storing fr...@mittelerde.de -> krb5_ccache_conf_data/pa_type/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF: in KEYRING:persistent:0:0 Most of the host can only communicate in the local net, which has not that much hosts (10). The wired ones are connected via GBit Network, wireless it is up to 150MBit. Server is a Xeon E3-1225 with 8GB Mem. All Systems have Fedora 21 installed Martin. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Am 07.04.2015 um 18:27 schrieb Simo Sorce: > On Tue, 2015-04-07 at 17:57 +0200, Martin (Lists) wrote: >> Hallo >> >> attached you can find the data from krb_child.log. As far as I can see >> it, the three seconds are due to the communication with the kerberos >> server. (1.2.3.4 is my server). > > Do you experience the same latency if you kinit manually ? > > Simo. > No, kinit completes almost instantly after entering the password. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Hallo attached you can find the data from krb_child.log. As far as I can see it, the three seconds are due to the communication with the kerberos server. (1.2.3.4 is my server). regards Martin Am 07.04.2015 um 11:21 schrieb Jakub Hrozek: > On Tue, Apr 07, 2015 at 11:12:40AM +0200, Martin (Lists) wrote: > > Am 05.04.2015 um 11:51 schrieb Martin (Lists): > >> > >> Hallo > >> > >> I have a similar issue. On login (graphic systems and ssh) and on the > >> screen saver I have a delay from about 2 secons to 10 seconds. > >> > >> According to my logfile i have the following timeline at login: > >> > >> 0pam_unix (auth) > >> 3pam_sss (auth) > >> 3pam_kwallet (sddm:auth) > >> 4pam_kwallet (sddm:setcred) > >> 5pam_unix (session) > >> > >> First collum is the number of seconds after the first action. On > myl old > >> server I had a pure kerberos (handmade) system, which reacted almost > >> instandly. > >> > >> Regards > >> Martin > >> > > Hallo > > > > I enabled debugging (set to level 6). selinux provider is set to none. > > During a login I got data accorting to my attachment. > > > > Regards > > Martin > > If that's all the data, then the login seems quite fast (3 seconds). > The slowdown seems to happen when the krb5 provider is initializing the > krb5 ccache for the user. krb5_child.log with a high debug level would > show what's happening in particular. > > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [be_req_set_domain] (0x0400): Changing request domain from > [mittelerde.de] to [mittelerde.de] > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [be_pam_handler] (0x0100): Got request with the following data > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): command: PAM_AUTHENTICATE > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): domain: mittelerde.de > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): user: frodo > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): service: sddm > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): tty: > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): ruser: > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): rhost: > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): authtok type: 1 > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): newauthtok type: 0 > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): priv: 1 > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): cli_pid: 6409 > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [pam_print_data] (0x0100): logon name: not set > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [be_resolve_server_process] (0x0200): Found address for server > gandalf.mittelerde.de: [10.2.33.5] TTL 1200 > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [ipa_resolve_callback] (0x0400): Constructed uri > 'ldap://gandalf.mittelerde.de' > > (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] > [write_pipe_handler] (0x0400): All data has been sent! > > Here we sent data to krb5_child > > > (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] > [child_sig_handler] (0x0100): child [6410] finished successfully. > > Here the krb5_child process finished > > > (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] > [read_pipe_handler] (0x0400): EOF received, client finished > > (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] > [fo_set_port_status] (0x0100): Marking port 0 of server > 'gandalf.mittelerde.de' as 'working' > > (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] > [set_server_common_status] (0x0100): Marking server > 'gandalf.mittelerde.de' as 'working' > > (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] > [fo_set_port_status] (0x0400): Marking port 0 of duplicate server > 'gandalf.mittelerde.de' as 'working' > > (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] > [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) > [Success] > > (Tue Apr 7 10:52:41 201
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Am 05.04.2015 um 11:51 schrieb Martin (Lists): > > Hallo > > I have a similar issue. On login (graphic systems and ssh) and on the > screen saver I have a delay from about 2 secons to 10 seconds. > > According to my logfile i have the following timeline at login: > > 0 pam_unix (auth) > 3 pam_sss (auth) > 3 pam_kwallet (sddm:auth) > 4 pam_kwallet (sddm:setcred) > 5 pam_unix (session) > > First collum is the number of seconds after the first action. On myl old > server I had a pure kerberos (handmade) system, which reacted almost > instandly. > > Regards > Martin > Hallo I enabled debugging (set to level 6). selinux provider is set to none. During a login I got data accorting to my attachment. Regards Martin (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_req_set_domain] (0x0400): Changing request domain from [mittelerde.de] to [mittelerde.de] (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): domain: mittelerde.de (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): user: frodo (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): service: sddm (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): tty: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): ruser: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): rhost: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): authtok type: 1 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): priv: 1 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): cli_pid: 6409 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): logon name: not set (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_resolve_server_process] (0x0200): Found address for server gandalf.mittelerde.de: [10.2.33.5] TTL 1200 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://gandalf.mittelerde.de' (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [child_sig_handler] (0x0100): child [6410] finished successfully. (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [set_server_common_status] (0x0100): Marking server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Sending result [0][mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Sent result [0][mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_req_set_domain] (0x0400): Changing request domain from [mittelerde.de] to [mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): domain: mittelerde.de (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): user: frodo (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): service: sddm (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): tty: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): ruser: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): rhost: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): authtok type: 0 (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Apr 7 10:52:41 2015) [sssd[be[mi
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Am 05.04.2015 um 06:10 schrieb Dan Mossor: > I've recently deployed a new domain based on 4.1.2 in F21. We've noticed > an issue and can't quite seem to nail it down. The problem is that > logins are taking an inordinate amount of time to complete - the fastest > logon we can get using LDAP credentials is 8 seconds. During our > testing, even logons to the IPA server itself took over 30 seconds to > complete. > > I've narrowed this down to sssd, but that is as far as I can get. When > cranking up debugging for sshd and PAM, I see a minimum 2 second delay > between ssh handing off the authentication request to sssd and the reply > back. The only troubleshooting I've done is with ssh, but the area that > causes the most grief is Apache logins. We configured Apache to use PAM > for auth through IPA, vice directly calling IPA itself. Logging in to > our Redmine site takes users a minimum of 34 seconds to complete. > Following this, a simple webpage containing two hyperlinks and two small > thumbnail images takes over a minute to load on a gigabit network. > > The *only* thing changed in this environment was the IPA server. We > moved the Redmine from our old network that was using IPA 3.x (F20 > branch) to the new one. My initial reaction was that it was the VM that > was hosting Redmine, but we've run these tests against bare metal > machines in the same network and have the same issue. It appears that > sssd is taking a very, very long time to talk to FreeIPA - even on the > IPA server itself. > > However, Kerberos logins into the IPA web GUI are near instantaneous, > while Username/Password logins take more than a few seconds. > > I need to get this solved. My developers don't appreciate the glory days > of XP taking 5 minutes to log into an IIS 2.1 web server on the local > network. I don't have the budget to keep them at the coffee pot waiting > on the network. So, what further information do you need from me to > track this one down? > > Dan > Hallo I have a similar issue. On login (graphic systems and ssh) and on the screen saver I have a delay from about 2 secons to 10 seconds. According to my logfile i have the following timeline at login: 0 pam_unix (auth) 3 pam_sss (auth) 3 pam_kwallet (sddm:auth) 4 pam_kwallet (sddm:setcred) 5 pam_unix (session) First collum is the number of seconds after the first action. On myl old server I had a pure kerberos (handmade) system, which reacted almost instandly. Regards Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
