[Freeipa-users] freeipa and User Private Groups
Hi All, Running ipa-3.0.0-42.el6 and sssd-1.11.6-30.el6_6.3.x86_64 So, by default, when you create a user in freeipa, That user will be set to have a primary group that is hidden and not a POSIX group. This means that when the user logs in to a host, they will see something like... id: cannot find name for group ID group_number running the id command shows no name returned for this group. I understand you can disable private groups globally, however it is discouraged. I also realise you can simply create POSIX groups when creating users. In the spirit of trying to stick with the defaults Is there a way to avoid the login error where id can't retrieve the group name from a UPG? Thanks, Les -- 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] Force IPA client Reverse Zone Dynamic Updates
On 12/07/15 10:05, Sina Owolabi wrote: Hi I have several dns zones defined in IPA. I noticed recently that the zone files are empty. I find this odd because I created them like the example below. Is it possible to force clients to auto-update reverse zones? Thanks in advance! How I created all the zones: ipa dnszone-add 0.14.10.in-addr.arpa. --minimum=3000 --allow-sync-ptr=TRUE --dynamic-update Zone name: 0.14.10.in-addr.arpa. Active zone: TRUE Authoritative nameserver: services.ourdomain.com. Administrator e-mail address: hostmaster SOA serial: 1436688202 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3000 BIND update policy: grant QRIOS.COM krb5-subdomain 0.14.10.in-addr.arpa. PTR; Dynamic update: TRUE Allow query: any; Allow transfer: none; Allow PTR sync: TRUE Hello, do you have --allow-sync-ptr=True configured in zones where the particular A/ records are? SSSD is able to update records. Please check if dyndns_update is set to true in sssd.conf. (man sssd-ipa) -- Martin Basti -- 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] AD users not visible in FreeIPA mapped group
On Mon, 13 Jul 2015, Angelo Pantano wrote: I added the external groups to map my Domain Admins AD group like the freeipa documentation suggests: # ipa group-add --desc='ad_domain admins external map' ad_admins_external --external # ipa group-add --desc='ad_domain admins' ad_admins # ipa group-add-member ad_admins_external --external 'ad_netbios\Domain Admins' # ipa group-add-member ad_admins --groups ad_admins_external But I dont see any user in the web interface under ad_admins or ad_admins_external. I thought that this would give us a view of the AD users in FreeIPA, but I dont see any difference.. Am I missing something here? Where did you look them? External members for ad_admins_external group would be under 'external' tab, like in the attached screenshot. -- / Alexander Bokovoy -- 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] DNS configuration for not resolving some addresses
On 8.7.2015 20:46, Karl Forner wrote: I forgot my main use case: I have name-based reverse proxies (SNI) for some web apps/services , that are accessible both from the internal and external network. They must be accessed with the exact same name/url, otherwise the dispatch can not work. Until now I manage this by manually editing all /etc/hosts on all internal computers, but I had hoped to benefit from the freeIPA DNS a more elegant solution. Standard DNS cannot provide you with this, you need to hack it yourself. Sorry! Petr Spacek @ Red Hat On Wed, Jul 8, 2015 at 4:50 PM, Petr Spacek pspa...@redhat.com wrote: On 8.7.2015 16:32, Karl Forner wrote: Thanks Petr. My use case is: we have scripts that connect to some services, let's say a docker registry. I want these scripts to be work either internally or externally, without changing the URLs. What would the best or easiest setting to achieve this ? Personally I use config file for this. I.e. the script is the same and URLs, names, passwords, etc. are read from config file stored alongside the script. This allows me to test it easily without any changes in DNS or system-wide configuration like /etc/hosts. Yes, it requires more code, but in long-term it is way more debug-able than DNS tricks. Petr^2 Spacek On Wed, Jul 8, 2015 at 4:25 PM, Petr Spacek pspa...@redhat.com wrote: On 8.7.2015 15:07, Karl Forner wrote: On Wed, Jul 8, 2015 at 2:32 PM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Wed, Jul 08, 2015 at 02:26:02PM +0200, Karl Forner wrote: When using my freeIPA DNS name server for my domain example.test, I need to exclude some names from the server( to be forwarded to the DNS forwarder for instance. For example, I'd like foo.example.test not to be resolved, but forwarded. How could I implement this ? That would mean you have two different nameservers authoritative for the same DNS domain. That is generally not recommended setup. Yes, that's what I read, but I do not know how to easily do differently. But in the end, what I'd like for my users, is to have foo.example.test resolved from the outside to my external server IP, and from the inside to the internal server IP. Such setup is generally not recommended because it is usually pain when it comes to long-term operation and maintenance. http://www.freeipa.org/page/DNS#Caveats http://www.freeipa.org/page/Deployment_Recommendations#DNS Two main use-cases are: a) Two or more different servers are using the same name and which server is used depends on client's network. This is usually very cumbersome because DNS caching will play against you, especially when we introduce system-wide cache into Fedora 23. It is also hard to manage and debug because you have to ask the same question from different networks etc. And it will be harder when you deploy DNSSEC to increase security... The typical recommendation is to use a sub-domain for internal names, e.g. i.example.com for internal names and example.com for externally-resolvable names. b) Seconds use-case: Attempt to optimize IP routing by using DNS tricks. Yes, it is as bad idea as it sounds. Can't you make foo.example.test a CNAME to foo.example.org or another hostname, in domain with different authoritative DNS server? Hmm yes that should work, thanks ! Please keep in mind that it only hides the problem under yet another layer of indirection. humor Yes, it is always possible! We know it because it is written in The Twelve Networking Truths: https://tools.ietf.org/html/rfc1925#page-2 point (6) but you should take into account point (3) into account, too :-) /humor -- Petr^2 Spacek -- 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] Primary certificates
Good morning, I was wondering, I install my servers with the self-signed certs. Now my management wants me to use official certificates. Is there an easy/recommended way to swap out all the certificates on all the servers? Especially with 16 servers, just trying to figure out if this is something I could script with PSSH or similar in order to do them all at once. Does it matter the order? Thank you ~Janelle -- 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] ns-slapd high cpu usage
can you get a pstack of the slapd process along with a top -H to find th ethread with high cpu usage Ludwig On 07/13/2015 04:46 PM, Andrew E. Bruno wrote: We have 3 freeipa-replicas. Centos 7.1.1503, ipa-server 4.1.0-18, and 389-ds 1.3.3.1-16. Recently, the ns-slapd process on one of our replicas started showing higher than normal CPU usage. ns-slapd is pegged at high CPU usage more or less constantly. Seems very similar to this thread: https://www.redhat.com/archives/freeipa-users/2015-February/msg00281.html There are a few errors showing in /var/log/dirsrv/slapd-[domain]/errors (not sure if these are related): [13/Jul/2015:02:56:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:04:11:50 -0400] - dn2entry_ext: Failed to get id for changenumber=2277387,cn=changelog from entryrdn index (-30993) [13/Jul/2015:04:11:50 -0400] - Operation error fetching changenumber=2277387,cn=changelog (null), error -30993. [13/Jul/2015:04:11:50 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2277387, dn = changenumber=2277387,cn=changelog: Operations error. [13/Jul/2015:04:11:50 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:07:41:49 -0400] - Operation error fetching Null DN (01de36ac-295411e5-b94db2ab-07afbca6), error -30993. [13/Jul/2015:07:41:49 -0400] - dn2entry_ext: Failed to get id for changenumber=2281464,cn=changelog from entryrdn index (-30993) [13/Jul/2015:07:41:49 -0400] - Operation error fetching changenumber=2281464,cn=changelog (null), error -30993. [13/Jul/2015:07:41:49 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2281464, dn = changenumber=2281464,cn=changelog: Operations error. [13/Jul/2015:07:41:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] access logs seem to be showing normal activity. Here's the number of open connections: # ls -al /proc/`cat /var/run/dirsrv/slapd-[domain].pid`/fd|grep socket|wc -l 62 Note: the other two replicas have much higher open connections (250) and low cpu load avgs. Here's some output of logconv.pl from our most recent access log on the replica with high cpu load: Start of Logs:13/Jul/2015:04:49:18 End of Logs: 13/Jul/2015:10:06:11 Processed Log Time: 5 Hours, 16 Minutes, 53 Seconds Restarts: 0 Total Connections:2343 - LDAP Connections: 2120 - LDAPI Connections: 223 - LDAPS Connections: 0 - StartTLS Extended Ops: 45 Secure Protocol Versions: - TLS1.2 128-bit AES - 45 Peak Concurrent Connections: 22 Total Operations: 111865 Total Results:111034 Overall Performance: 99.3% Searches: 95585 (5.03/sec) (301.64/min) Modifications:3369 (0.18/sec) (10.63/min) Adds: 0 (0.00/sec) (0.00/min) Deletes: 0 (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) (0.00/min) Compares: 0 (0.00/sec) (0.00/min) Binds:7082 (0.37/sec) (22.35/min) Proxied Auth Operations: 0 Persistent Searches: 0 Internal Operations: 0 Entry Operations: 0 Extended Operations: 5317 Abandoned Requests: 416 Smart Referrals Received: 0 VLV Operations: 96 VLV Unindexed Searches: 0 VLV Unindexed Components: 32 SORT Operations: 64 Entire Search Base Queries: 0 Paged Searches: 3882 Unindexed Searches: 0 Unindexed Components: 5 FDs Taken:2566 FDs Returned: 2643 Highest FD Taken: 249 Broken Pipes: 0 Connections Reset By Peer:0 Resource Unavailable: 0 Max BER Size Exceeded:0 Binds:7082 Unbinds: 2443 - LDAP v2 Binds: 0 - LDAP v3 Binds: 6859 - AUTOBINDs: 223 - SSL Client Binds: 0 - Failed SSL Client Binds: 0 - SASL Binds:6814 GSSAPI - 6591 EXTERNAL - 223 - Directory Manager Binds: 0 - Anonymous Binds: 6591 - Other Binds: 491 strace timing on the ns-slapd process: % time seconds usecs/call callserrors syscall -- --- --- - - 94.400.346659597758 poll 4.100.015057 15057 1 restart_syscall 0.910.003353 575959 getpeername 0.490.001796 15012 futex 0.100.000364 73 5 read -- --- --- - - 100.000.367229 13559 total top output (with threads 'H'): PID USER
[Freeipa-users] ns-slapd high cpu usage
We have 3 freeipa-replicas. Centos 7.1.1503, ipa-server 4.1.0-18, and 389-ds 1.3.3.1-16. Recently, the ns-slapd process on one of our replicas started showing higher than normal CPU usage. ns-slapd is pegged at high CPU usage more or less constantly. Seems very similar to this thread: https://www.redhat.com/archives/freeipa-users/2015-February/msg00281.html There are a few errors showing in /var/log/dirsrv/slapd-[domain]/errors (not sure if these are related): [13/Jul/2015:02:56:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:04:11:50 -0400] - dn2entry_ext: Failed to get id for changenumber=2277387,cn=changelog from entryrdn index (-30993) [13/Jul/2015:04:11:50 -0400] - Operation error fetching changenumber=2277387,cn=changelog (null), error -30993. [13/Jul/2015:04:11:50 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2277387, dn = changenumber=2277387,cn=changelog: Operations error. [13/Jul/2015:04:11:50 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:07:41:49 -0400] - Operation error fetching Null DN (01de36ac-295411e5-b94db2ab-07afbca6), error -30993. [13/Jul/2015:07:41:49 -0400] - dn2entry_ext: Failed to get id for changenumber=2281464,cn=changelog from entryrdn index (-30993) [13/Jul/2015:07:41:49 -0400] - Operation error fetching changenumber=2281464,cn=changelog (null), error -30993. [13/Jul/2015:07:41:49 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2281464, dn = changenumber=2281464,cn=changelog: Operations error. [13/Jul/2015:07:41:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] access logs seem to be showing normal activity. Here's the number of open connections: # ls -al /proc/`cat /var/run/dirsrv/slapd-[domain].pid`/fd|grep socket|wc -l 62 Note: the other two replicas have much higher open connections (250) and low cpu load avgs. Here's some output of logconv.pl from our most recent access log on the replica with high cpu load: Start of Logs:13/Jul/2015:04:49:18 End of Logs: 13/Jul/2015:10:06:11 Processed Log Time: 5 Hours, 16 Minutes, 53 Seconds Restarts: 0 Total Connections:2343 - LDAP Connections: 2120 - LDAPI Connections: 223 - LDAPS Connections: 0 - StartTLS Extended Ops: 45 Secure Protocol Versions: - TLS1.2 128-bit AES - 45 Peak Concurrent Connections: 22 Total Operations: 111865 Total Results:111034 Overall Performance: 99.3% Searches: 95585 (5.03/sec) (301.64/min) Modifications:3369 (0.18/sec) (10.63/min) Adds: 0 (0.00/sec) (0.00/min) Deletes: 0 (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) (0.00/min) Compares: 0 (0.00/sec) (0.00/min) Binds:7082 (0.37/sec) (22.35/min) Proxied Auth Operations: 0 Persistent Searches: 0 Internal Operations: 0 Entry Operations: 0 Extended Operations: 5317 Abandoned Requests: 416 Smart Referrals Received: 0 VLV Operations: 96 VLV Unindexed Searches: 0 VLV Unindexed Components: 32 SORT Operations: 64 Entire Search Base Queries: 0 Paged Searches: 3882 Unindexed Searches: 0 Unindexed Components: 5 FDs Taken:2566 FDs Returned: 2643 Highest FD Taken: 249 Broken Pipes: 0 Connections Reset By Peer:0 Resource Unavailable: 0 Max BER Size Exceeded:0 Binds:7082 Unbinds: 2443 - LDAP v2 Binds: 0 - LDAP v3 Binds: 6859 - AUTOBINDs: 223 - SSL Client Binds: 0 - Failed SSL Client Binds: 0 - SASL Binds:6814 GSSAPI - 6591 EXTERNAL - 223 - Directory Manager Binds: 0 - Anonymous Binds: 6591 - Other Binds: 491 strace timing on the ns-slapd process: % time seconds usecs/call callserrors syscall -- --- --- - - 94.400.346659597758 poll 4.100.015057 15057 1 restart_syscall 0.910.003353 575959 getpeername 0.490.001796 15012 futex 0.100.000364 73 5 read -- --- --- - - 100.000.367229 13559 total top output (with threads 'H'): PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
Re: [Freeipa-users] ipa client on ubuntu and sudo rules
For reference: I could not make the sudo rules on ubuntu 12.04, I tried many many things. Worked like a charm on ubuntu 14.04: as simple as adding sudo to services in [sssd] section of nsssd.conf. On Fri, Jul 10, 2015 at 5:18 PM, Lukas Slebodnik lsleb...@redhat.com wrote: On (10/07/15 16:19), Karl Forner wrote: Hello, I setup an ubuntu client for freeIPA 4.1.4, and sudo rules do not seem to work. I then realized that I used ipa-client-install version 3.3.4. Is this a plausible cause ? And if so, where can I get a more recent version for ubuntu/debian ? Never version of ipa-client configures sssd integration with sudo by default. Please follow intructions from manual page sssd-sudo and you should be able to configure it yourself. Different version of sssd requires different configuration with ipa provider. IIRC sssd 1.10 nas native ipa sudo provider so you need't to configure sudo ldap provider with IPA. That's the reason why it's better to follow instruction form man page sssd-sudo. LS -- 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] Windows sync agreement becomes uninitialized and crashes directory server
On 07/13/2015 07:07 PM, nat...@nathanpeters.com wrote:
2 FreeIPA 4.1.4 servers running on CentOS 7.
dc1 has a sync agreement to a windows server.
It has been running fine since June 5 when I re-initialized a sync
agreement that had somehow uninitialized itself. Original issue report
here :
https://www.redhat.com/archives/freeipa-users/2015-June/msg00147.html
Bug report here : https://fedorahosted.org/freeipa/ticket/5054
It appears the same thing may have happened again, one month later, but
this time randomly, as we have not made any changes to our sync agreement
since the initial change in June. it appears to have unitialized itself
without us changing it and managed to crash the directory server in doing
so.
Crash? http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
# debuginfo-install 389-ds-base ipa-server slapi-nis
Note that during the last week I could still login to the web ui, but
around the time the log entries change, I became unable to.
I tried to login to the web server today and it would not let me login, so
I went to the shell on the server and noticed that ipactl command would
freeze up again. I looked at the logs (which I will paste below) and
restarted the directory server service.
I then found that my sync agreement had become uninitialized.
--- output ---
[root@dc1 slapd-IPADOMAIN-NET]# ldapsearch -xLLL -D cn=directory manager
-W -b cn=config objectclass=nsDSWindowsReplicationAgreement
Enter LDAP Password:
dn: cn=meToofficedc2.office.addomain.net,cn=replica,cn=dc\3Dipadomain
\2Cdc\3Dnet,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: OU=Staff,DC=office,DC=addomain,DC=net
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipadomain,dc=net
cn: meToofficedc2.office.addomain.net
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to officedc2.office.addomain.net
nsDS5ReplicaRoot: dc=ipadomain,dc=net
nsDS5ReplicaHost: officedc2.office.addomain.net
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=freeipa syncuser,ou=Service
Account,dc=office,dc=addomain,dc=net
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipadomain.net
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
RERBNEJDUmtOelUzTTJJNVlpMDBaV1EyTTJRMQ0KWXkwNU0yTm1aV05sTVMxbU5qRXpaak5oTlFBQ
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ2k0N0NxRGZFd2JIdm
I0MFVFZVI3MA==}gWI9NIB8lbt9tmNszzbBFCAe4Vs/e0sMyn5+NZPJg9E=
nsds7DirsyncCookie::
TVNEUwMAAABoJPGME7jQAQAAYAEAAPc1qQAAA
AD3NakAAMUjuImqVZhBkOkdt24C0IsBAA4AY4GwFkVcvEmMMExrVon4d6
13PwAADGzFNzznrESIxHzA74fbsz4HUgAAOnFoO5OE2E27lR/g4EcjQTLbIwAAuEm
PWjYok0qGS0HM/+TDmK7FgAMA6PTFXvAdnkaJSIkZT1lS+/FcJAAA4qTQaC46/Ua4KXgP
/ixNcbK4dgAAWowbgYD1akibZ+sCul5C4VNsMQAAxSO4iapVmEGQ6R23bgLQi/c1qQAAA
AAAogC6jFcyFUmhBp4B7FkaBcRHwwEAyhKMxsP0uUKGEnG2lsyA8eTUwgYA4n8Xx1bAlU
mBUl3zhlZ9WBngDAAA71vM2ebFEkCJkBaLjB4CGU+4CQMAGfO+4ndZCkaVKnwZNlNsf90
NDAAAgD6n+M2bcUGkOwo5gPLx7IOjAwAA
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 4 ldap://dc1.ipadomain.net:389} 553fe9c9
0004 557f49fb00020004
nsds50ruv: {replica 3 ldap://dc2.ipadomain.net:389} 553fe9c
40003 557f3e4a00020003
nsruvReplicaLastModified: {replica 4 ldap://dc1.ipadomain.ne
t:389} 557f494a
nsruvReplicaLastModified: {replica 3 ldap://dc2.ipadomain.n
et:389} 557f3d95
oneWaySync: fromWindows
nsds5ReplicaEnabled: on
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateEnd: 0
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: -1 - LDAP error: Can't contact LDAP server
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0
--- output ---
Here are the error logs for the last month for the directory server. They
are totally empty until July 2.
---output---
389-Directory/1.3.3.8 B2015.040.128
dc1.ipadomain.net:636 (/etc/dirsrv/slapd-IPADOMAIN-NET)
[02/Jul/2015:03:19:02 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[02/Jul/2015:06:10:29 +] - Entry
uid=jenkinsdev,cn=users,cn=accounts,dc=ipadomain,dc=net missing
attribute sn required by object class person
[03/Jul/2015:02:04:02 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:05:39:01 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:17:09:00 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:22:41:32 +] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id
Re: [Freeipa-users] Force IPA client Reverse Zone Dynamic Updates
Hi Martin Yes all my sssd configs are set ipa_dyndns_update = True I didn't have --allow-sync-ptr=TRUE in all the forward zones so I set them. I've tried to set it in the very first zone (setup during installation) but dnszone-mod complains: # ipa dnszone-mod mydom.com --allow-sync-ptr=TRUE --dynamic-update=TRUE ipa: ERROR: no modifications to be performed But I don't see it in the show command: ipa dnszone-show mydom.com Zone name: mydom.com. Active zone: TRUE Authoritative nameserver: services.mydom.com. Administrator e-mail address: hostmaster.mydom.com. SOA serial: 1436799166 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; On Mon, Jul 13, 2015 at 11:20 AM, Martin Basti mba...@redhat.com wrote: On 12/07/15 10:05, Sina Owolabi wrote: Hi I have several dns zones defined in IPA. I noticed recently that the zone files are empty. I find this odd because I created them like the example below. Is it possible to force clients to auto-update reverse zones? Thanks in advance! How I created all the zones: ipa dnszone-add 0.14.10.in-addr.arpa. --minimum=3000 --allow-sync-ptr=TRUE --dynamic-update Zone name: 0.14.10.in-addr.arpa. Active zone: TRUE Authoritative nameserver: services.ourdomain.com. Administrator e-mail address: hostmaster SOA serial: 1436688202 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3000 BIND update policy: grant QRIOS.COM krb5-subdomain 0.14.10.in-addr.arpa. PTR; Dynamic update: TRUE Allow query: any; Allow transfer: none; Allow PTR sync: TRUE Hello, do you have --allow-sync-ptr=True configured in zones where the particular A/ records are? SSSD is able to update records. Please check if dyndns_update is set to true in sssd.conf. (man sssd-ipa) -- Martin Basti -- 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] ns-slapd high cpu usage
On 07/13/2015 05:05 PM, Andrew E. Bruno wrote: On Mon, Jul 13, 2015 at 04:58:46PM +0200, Ludwig Krispenz wrote: can you get a pstack of the slapd process along with a top -H to find th ethread with high cpu usage Attached is the full stacktrace of the running ns-slapd proccess. top -H shows this thread (2879) with high cpu usage: 2879 dirsrv20 0 3819252 1.962g 11680 R 99.9 3.1 8822:10 ns-slapd this thread is a replication thread sending updates, what is strange is that the current csn_str is quite old (july, 7th), I can't tell which agreeement this thread is handling, but looks like it is heavily reading the changeglog and sending updates. anything changed recently in replication setup ? On 07/13/2015 04:46 PM, Andrew E. Bruno wrote: We have 3 freeipa-replicas. Centos 7.1.1503, ipa-server 4.1.0-18, and 389-ds 1.3.3.1-16. Recently, the ns-slapd process on one of our replicas started showing higher than normal CPU usage. ns-slapd is pegged at high CPU usage more or less constantly. Seems very similar to this thread: https://www.redhat.com/archives/freeipa-users/2015-February/msg00281.html There are a few errors showing in /var/log/dirsrv/slapd-[domain]/errors (not sure if these are related): [13/Jul/2015:02:56:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:04:11:50 -0400] - dn2entry_ext: Failed to get id for changenumber=2277387,cn=changelog from entryrdn index (-30993) [13/Jul/2015:04:11:50 -0400] - Operation error fetching changenumber=2277387,cn=changelog (null), error -30993. [13/Jul/2015:04:11:50 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2277387, dn = changenumber=2277387,cn=changelog: Operations error. [13/Jul/2015:04:11:50 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:07:41:49 -0400] - Operation error fetching Null DN (01de36ac-295411e5-b94db2ab-07afbca6), error -30993. [13/Jul/2015:07:41:49 -0400] - dn2entry_ext: Failed to get id for changenumber=2281464,cn=changelog from entryrdn index (-30993) [13/Jul/2015:07:41:49 -0400] - Operation error fetching changenumber=2281464,cn=changelog (null), error -30993. [13/Jul/2015:07:41:49 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2281464, dn = changenumber=2281464,cn=changelog: Operations error. [13/Jul/2015:07:41:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] access logs seem to be showing normal activity. Here's the number of open connections: # ls -al /proc/`cat /var/run/dirsrv/slapd-[domain].pid`/fd|grep socket|wc -l 62 Note: the other two replicas have much higher open connections (250) and low cpu load avgs. Here's some output of logconv.pl from our most recent access log on the replica with high cpu load: Start of Logs:13/Jul/2015:04:49:18 End of Logs: 13/Jul/2015:10:06:11 Processed Log Time: 5 Hours, 16 Minutes, 53 Seconds Restarts: 0 Total Connections:2343 - LDAP Connections: 2120 - LDAPI Connections: 223 - LDAPS Connections: 0 - StartTLS Extended Ops: 45 Secure Protocol Versions: - TLS1.2 128-bit AES - 45 Peak Concurrent Connections: 22 Total Operations: 111865 Total Results:111034 Overall Performance: 99.3% Searches: 95585 (5.03/sec) (301.64/min) Modifications:3369 (0.18/sec) (10.63/min) Adds: 0 (0.00/sec) (0.00/min) Deletes: 0 (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) (0.00/min) Compares: 0 (0.00/sec) (0.00/min) Binds:7082 (0.37/sec) (22.35/min) Proxied Auth Operations: 0 Persistent Searches: 0 Internal Operations: 0 Entry Operations: 0 Extended Operations: 5317 Abandoned Requests: 416 Smart Referrals Received: 0 VLV Operations: 96 VLV Unindexed Searches: 0 VLV Unindexed Components: 32 SORT Operations: 64 Entire Search Base Queries: 0 Paged Searches: 3882 Unindexed Searches: 0 Unindexed Components: 5 FDs Taken:2566 FDs Returned: 2643 Highest FD Taken: 249 Broken Pipes: 0 Connections Reset By Peer:0 Resource Unavailable: 0 Max BER Size Exceeded:0 Binds:7082 Unbinds: 2443 - LDAP v2 Binds: 0 - LDAP v3 Binds: 6859 - AUTOBINDs: 223 - SSL Client Binds: 0 - Failed SSL Client Binds: 0 - SASL Binds:6814 GSSAPI - 6591 EXTERNAL - 223 - Directory Manager Binds: 0 - Anonymous Binds: 6591 - Other Binds: 491 strace timing on the ns-slapd
Re: [Freeipa-users] ipa client on ubuntu and sudo rules
On (13/07/15 14:49), Karl Forner wrote: For reference: I could not make the sudo rules on ubuntu 12.04, I tried many many things. Ahh, Default version of sssd in ubuntu 12.04 is 1.8.2 http://packages.ubuntu.com/precise/sssd it's better to use newer version which contains fixes for sudo. I would suggest at least the latest 1.9. But there is another problem. The default version of sudo in ununtu 12.04 (1.8.3p1) does not contain sssd support. http://packages.ubuntu.com/precise/sudo. The support for sssd in sudo code was added in upstream sudo 1.8.6 http://www.sudo.ws/stable.html#1.8.6 LS -- 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] ns-slapd high cpu usage
On Mon, Jul 13, 2015 at 05:29:13PM +0200, Ludwig Krispenz wrote: On 07/13/2015 05:05 PM, Andrew E. Bruno wrote: On Mon, Jul 13, 2015 at 04:58:46PM +0200, Ludwig Krispenz wrote: can you get a pstack of the slapd process along with a top -H to find th ethread with high cpu usage Attached is the full stacktrace of the running ns-slapd proccess. top -H shows this thread (2879) with high cpu usage: 2879 dirsrv20 0 3819252 1.962g 11680 R 99.9 3.1 8822:10 ns-slapd this thread is a replication thread sending updates, what is strange is that the current csn_str is quite old (july, 7th), I can't tell which agreeement this thread is handling, but looks like it is heavily reading the changeglog and sending updates. anything changed recently in replication setup ? Yes, we had one replica fail on (6/19) which we removed (not this one showing high CPU load). Had to perform some manual cleanup of the ipa-ca RUVs. Then we added the replica back in on 7/1. Since then, replication appears to have been running normally between the 3 replicas. We've been monitoring utilization since 7/1 and only recently seen this spike (past 24 hours or so). On a side note, we get hit with this bug often: https://www.redhat.com/archives/freeipa-users/2015-July/msg00018.html (rouge sssd_be processing hammering a replica). This causes high ns-slapd utilization on the replica and restarting sssd on the client host immediately fixes the issue. However, in this case, we're not seeing this behavior. On 07/13/2015 04:46 PM, Andrew E. Bruno wrote: We have 3 freeipa-replicas. Centos 7.1.1503, ipa-server 4.1.0-18, and 389-ds 1.3.3.1-16. Recently, the ns-slapd process on one of our replicas started showing higher than normal CPU usage. ns-slapd is pegged at high CPU usage more or less constantly. Seems very similar to this thread: https://www.redhat.com/archives/freeipa-users/2015-February/msg00281.html There are a few errors showing in /var/log/dirsrv/slapd-[domain]/errors (not sure if these are related): [13/Jul/2015:02:56:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:04:11:50 -0400] - dn2entry_ext: Failed to get id for changenumber=2277387,cn=changelog from entryrdn index (-30993) [13/Jul/2015:04:11:50 -0400] - Operation error fetching changenumber=2277387,cn=changelog (null), error -30993. [13/Jul/2015:04:11:50 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2277387, dn = changenumber=2277387,cn=changelog: Operations error. [13/Jul/2015:04:11:50 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [13/Jul/2015:07:41:49 -0400] - Operation error fetching Null DN (01de36ac-295411e5-b94db2ab-07afbca6), error -30993. [13/Jul/2015:07:41:49 -0400] - dn2entry_ext: Failed to get id for changenumber=2281464,cn=changelog from entryrdn index (-30993) [13/Jul/2015:07:41:49 -0400] - Operation error fetching changenumber=2281464,cn=changelog (null), error -30993. [13/Jul/2015:07:41:49 -0400] DSRetroclPlugin - replog: an error occured while adding change number 2281464, dn = changenumber=2281464,cn=changelog: Operations error. [13/Jul/2015:07:41:49 -0400] retrocl-plugin - retrocl_postob: operation failure [1] access logs seem to be showing normal activity. Here's the number of open connections: # ls -al /proc/`cat /var/run/dirsrv/slapd-[domain].pid`/fd|grep socket|wc -l 62 Note: the other two replicas have much higher open connections (250) and low cpu load avgs. Here's some output of logconv.pl from our most recent access log on the replica with high cpu load: Start of Logs:13/Jul/2015:04:49:18 End of Logs: 13/Jul/2015:10:06:11 Processed Log Time: 5 Hours, 16 Minutes, 53 Seconds Restarts: 0 Total Connections:2343 - LDAP Connections: 2120 - LDAPI Connections: 223 - LDAPS Connections: 0 - StartTLS Extended Ops: 45 Secure Protocol Versions: - TLS1.2 128-bit AES - 45 Peak Concurrent Connections: 22 Total Operations: 111865 Total Results:111034 Overall Performance: 99.3% Searches: 95585 (5.03/sec) (301.64/min) Modifications:3369 (0.18/sec) (10.63/min) Adds: 0 (0.00/sec) (0.00/min) Deletes: 0 (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) (0.00/min) Compares: 0 (0.00/sec) (0.00/min) Binds:7082 (0.37/sec) (22.35/min) Proxied Auth Operations: 0 Persistent Searches: 0 Internal Operations: 0 Entry Operations: 0 Extended Operations: 5317 Abandoned Requests: 416 Smart Referrals Received: 0 VLV Operations: 96 VLV Unindexed
[Freeipa-users] Windows sync agreement becomes uninitialized and crashes directory server
2 FreeIPA 4.1.4 servers running on CentOS 7.
dc1 has a sync agreement to a windows server.
It has been running fine since June 5 when I re-initialized a sync
agreement that had somehow uninitialized itself. Original issue report
here :
https://www.redhat.com/archives/freeipa-users/2015-June/msg00147.html
Bug report here : https://fedorahosted.org/freeipa/ticket/5054
It appears the same thing may have happened again, one month later, but
this time randomly, as we have not made any changes to our sync agreement
since the initial change in June. it appears to have unitialized itself
without us changing it and managed to crash the directory server in doing
so. Note that during the last week I could still login to the web ui, but
around the time the log entries change, I became unable to.
I tried to login to the web server today and it would not let me login, so
I went to the shell on the server and noticed that ipactl command would
freeze up again. I looked at the logs (which I will paste below) and
restarted the directory server service.
I then found that my sync agreement had become uninitialized.
--- output ---
[root@dc1 slapd-IPADOMAIN-NET]# ldapsearch -xLLL -D cn=directory manager
-W -b cn=config objectclass=nsDSWindowsReplicationAgreement
Enter LDAP Password:
dn: cn=meToofficedc2.office.addomain.net,cn=replica,cn=dc\3Dipadomain
\2Cdc\3Dnet,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: OU=Staff,DC=office,DC=addomain,DC=net
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipadomain,dc=net
cn: meToofficedc2.office.addomain.net
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to officedc2.office.addomain.net
nsDS5ReplicaRoot: dc=ipadomain,dc=net
nsDS5ReplicaHost: officedc2.office.addomain.net
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=freeipa syncuser,ou=Service
Account,dc=office,dc=addomain,dc=net
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipadomain.net
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
RERBNEJDUmtOelUzTTJJNVlpMDBaV1EyTTJRMQ0KWXkwNU0yTm1aV05sTVMxbU5qRXpaak5oTlFBQ
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ2k0N0NxRGZFd2JIdm
I0MFVFZVI3MA==}gWI9NIB8lbt9tmNszzbBFCAe4Vs/e0sMyn5+NZPJg9E=
nsds7DirsyncCookie::
TVNEUwMAAABoJPGME7jQAQAAYAEAAPc1qQAAA
AD3NakAAMUjuImqVZhBkOkdt24C0IsBAA4AY4GwFkVcvEmMMExrVon4d6
13PwAADGzFNzznrESIxHzA74fbsz4HUgAAOnFoO5OE2E27lR/g4EcjQTLbIwAAuEm
PWjYok0qGS0HM/+TDmK7FgAMA6PTFXvAdnkaJSIkZT1lS+/FcJAAA4qTQaC46/Ua4KXgP
/ixNcbK4dgAAWowbgYD1akibZ+sCul5C4VNsMQAAxSO4iapVmEGQ6R23bgLQi/c1qQAAA
AAAogC6jFcyFUmhBp4B7FkaBcRHwwEAyhKMxsP0uUKGEnG2lsyA8eTUwgYA4n8Xx1bAlU
mBUl3zhlZ9WBngDAAA71vM2ebFEkCJkBaLjB4CGU+4CQMAGfO+4ndZCkaVKnwZNlNsf90
NDAAAgD6n+M2bcUGkOwo5gPLx7IOjAwAA
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 4 ldap://dc1.ipadomain.net:389} 553fe9c9
0004 557f49fb00020004
nsds50ruv: {replica 3 ldap://dc2.ipadomain.net:389} 553fe9c
40003 557f3e4a00020003
nsruvReplicaLastModified: {replica 4 ldap://dc1.ipadomain.ne
t:389} 557f494a
nsruvReplicaLastModified: {replica 3 ldap://dc2.ipadomain.n
et:389} 557f3d95
oneWaySync: fromWindows
nsds5ReplicaEnabled: on
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateEnd: 0
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: -1 - LDAP error: Can't contact LDAP server
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0
--- output ---
Here are the error logs for the last month for the directory server. They
are totally empty until July 2.
---output---
389-Directory/1.3.3.8 B2015.040.128
dc1.ipadomain.net:636 (/etc/dirsrv/slapd-IPADOMAIN-NET)
[02/Jul/2015:03:19:02 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[02/Jul/2015:06:10:29 +] - Entry
uid=jenkinsdev,cn=users,cn=accounts,dc=ipadomain,dc=net missing
attribute sn required by object class person
[03/Jul/2015:02:04:02 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:05:39:01 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:17:09:00 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:22:41:32 +] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2
(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information (Cannot contact any KDC
for realm
[Freeipa-users] AD users not visible in FreeIPA mapped group
I added the external groups to map my Domain Admins AD group like the freeipa documentation suggests: # ipa group-add --desc='ad_domain admins external map' ad_admins_external --external # ipa group-add --desc='ad_domain admins' ad_admins # ipa group-add-member ad_admins_external --external 'ad_netbios\Domain Admins' # ipa group-add-member ad_admins --groups ad_admins_external But I dont see any user in the web interface under ad_admins or ad_admins_external. I thought that this would give us a view of the AD users in FreeIPA, but I dont see any difference.. Am I missing something here? -- 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
