Re: [Freeipa-users] DirSrv hanging
On 10 Jan 2017, at 11:58, Adam Bishop <adam.bis...@jisc.ac.uk> wrote: > On 10 Jan 2017, at 09:22, Ludwig Krispenz <lkris...@redhat.com> wrote: >> this is a hang inside BerkeleyDB and we have so far not been able to resolve >> it, also with Oracle support. The weird thing is that from the code in BDB >> this should not be possible, but it is happening. Ther is a suspicion that >> it could be an effect of VMs, where the wrong page is accessed, but no >> further evidence on this. > > I can confirm we're we are running in a VM (ESXi 6.0), which gives me a few > ideas. I've migrated our instance to faster storage and to a host > topologically closer to the storage array to reduce latency. Touch wood, the reduced storage latency and higher IO throughput has mitigated the issue. DirSrv has not hung again so far. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. -- 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] DirSrv hanging
On 10 Jan 2017, at 09:22, Ludwig Krispenz <lkris...@redhat.com> wrote: > this is a hang inside BerkeleyDB and we have so far not been able to resolve > it, also with Oracle support. The weird thing is that from the code in BDB > this should not be possible, but it is happening. Ther is a suspicion that it > could be an effect of VMs, where the wrong page is accessed, but no further > evidence on this. I can confirm we're we are running in a VM (ESXi 6.0), which gives me a few ideas. I've migrated our instance to faster storage and to a host topologically closer to the storage array to reduce latency. > You can try to change the timing pattern of checkpointing, eg by changing the > checkpoint interval or the dbcache size, but there is no guarantee it will > help. I'll give that a try. Is there any additional telemetry you would like me to capture if it occurs again? Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. -- 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] SLAPD stops answering
On 9 Jan 2017, at 13:06, Troels Hansen <t...@casalogic.dk> wrote: > Anyone with some thoughts about this, other that "Just upgrade". This sounds similar to the behaviour I'm seeing on my standalone instance; though I don't have anything in the error log: https://www.redhat.com/archives/freeipa-users/2017-January/msg00162.html If you attach strace to the slapd process, do you see repeated (failing) calls to getpeername()? Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. -- 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] DirSrv hanging
I have a standalone FreeIPA instance that is becoming unresponsive every few
hours. While in this state it will accept connections, but will not do anything
with them (i.e. if you connect an ldaps client to 636, you see
SYN->SYNACK->ACK->ClientHello, but a ServerHello is not returned). This system
is running FreeIPA 4.4.0 currently, but this also occurred on 4.2.x. Time is
synchronised correctly and this is a fairly new installation so all the PKI
expiry dates are well into the future.
It handles queries without complaint, right up until the point it doesn't.
Inspecting the process with strace shows it waiting on a socket:
getpeername(7, 0x7ffeb749af70, [112]) = -1 ENOTCONN (Transport endpoint
is not connected)
poll([{fd=50, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN},
{fd=8, events=POLLIN},
{fd=66, events=POLLIN}, {fd=80, events=POLLIN}, {fd=79, events=POLLIN},
{fd=78, events=POLLIN},
{fd=77, events=POLLIN}, {fd=76, events=POLLIN}, {fd=75, events=POLLIN},
{fd=73, events=POLLIN},
{fd=71, events=POLLIN}, {fd=70, events=POLLIN}, {fd=68, events=POLLIN}],
15, 250) = 0 (Timeout)
fd 7 is a constant:
ls -l /proc/2428/fd
lrwx--. 1 root root 64 Jan 6 17:16 7 -> socket:[18972]
I'm not sure if I'm understanding the meaning of the fd entry correctly, but I
believe this is the entry:
[root@ldap-001 log]# lsof -p 2428 | grep 18972
ns-slapd 2428 dirsrv7u IPv6 18972 0t0 TCP
*:ldaps (LISTEN)
A backtrace from GDB follows at the end of this message - it shows the address
struct, which just contains the source address of the last connection to port
636 before DirSrv hangs.
The server is configured to use the FreeIPA dns service as its own resolver.
The DNS service is definitely still running, and resolves the query fine when
executed with dig.
There is nothing in the DirSrv logs that indicates an issue. The KDC logs
indicate a problem, but I i don't know if DirSrv is hanging because of the KDC,
or if the KDC is just reflecting that DirSrv is unresponsive.
Jan 06 21:53:29 ldap-001.domain krb5kdc[2702](info): AS_REQ (6 etypes {18
17 16 23 25 26}) 193.63.63.108: LOOKING_UP_CLIENT: host/ldap-001.domain@DOMAIN
for krbtgt/DOMAIN@DOMAIN, Server error
Jan 06 21:53:29 ldap-001.domain krb5kdc[2702](info): closing down fd 12
sssd reports an issue too, but that is almost certainly due to an unresponsive
DirSrv:
(Sat Jan 7 03:16:08 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The
Data Provider returned an error
[org.freedesktop.sssd.Error.DataProvider.Offline]
I'm not really sure what to check next - all the individual components seem to
be working, but not together.
Any suggestions are appreciated.
Regards,
Adam Bishop
gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460
jisc.ac.uk
---
[root@ldap-001 log]# gdb -p 2428
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 2428
0x7fc80bf4fdfd in poll () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install
ipa-server-4.4.0-14.el7.centos.1.1.x86_64
(gdb) break getpeername
Breakpoint 1 at 0x7fc80bf5b4b0: file ../sysdeps/unix/syscall-template.S, line
81.
(gdb) cont
Continuing.
Breakpoint 1, getpeername () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) bt full
#0 getpeername () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1 0x7fc80c888389 in pt_GetPeerName (fd=0x7fc810d92010,
addr=0x7ffeb749af70) at ../../../nspr/pr/src/pthreads/ptio.c:2795
rv = -1
addr_len = 112
#2 0x7fc80d3fec23 in ssl_Poll (fd=0x7fc810b69260, how_flags=, p_out_flags=0x7ffeb749b06c) at sslsock.c:2639
ss = 0x7fc810d94f30
new_flags = 1
addr = {raw = {family = 0, data = '\000' }, inet =
{family = 0, port = 0, ip = 0, pad = "\000\000\000\000\000\000\000"}, ipv6 =
{family = 0, port = 0, flowinfo = 0,
ip = {_S6_un = {_S6_u8 = '\000' , _S6_u16 = {0,
0, 0, 0, 0, 0, 0, 0}, _S6_u32 = {0, 0, 0, 0}, _S6_u64 = {0, 0}}}, scope_id =
0}, local = {family = 0,
path = '\000' ,
"\061\071\063.63.63.108\000\000\000`\327!\f\310\177\000\000\017\000\000\000\000\000\000\000p\260I\267\376\177\000\000\000\000\000\000\000\000\000\000\372",
'\000' , "\372\000\000\000\000\000\000\000\215", }}
#3 0x7fc
Re: [Freeipa-users] ipalib authentication
On 24 Nov 2016, at 16:18, Christian Heimes <chei...@redhat.com> wrote: > for a service you can use a Kerberos keytab to authenticate. A keytab > can be requested with ipa-getkeytab. The command will replace the > password of the service with a random one. Thanks everyone, I think using a key tab will be fine; having a manual step for initial configuration is not a huge burden. I'll take a look at python-gssapi too. Thanks again, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. -- 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] ipalib authentication
I'm writing a bit of code using ipalib directly, I'm a little stuck on authentication though. It works fine if grab a Kerberos ticket with kinit then run the code interactively, but I'd like to run this as a daemon which makes maintaining a ticket tricky. What other options are there for authenticating to the API, avoiding calling external tools like curl or kinit? Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. -- 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] Unable to join FreeIPA client to server
On 29 Mar 2016, at 14:29, Adam Bishop <adam.bis...@jisc.ac.uk> wrote: > I could use a bit of help resolving this - full client debug follows. Both > systems are running nss 3.19.1 which *should* support TLS1.2., so I'm unsure > where to start fixing this. Turns out to be a little easier to solve than I thought; the CentOS 6 client was running an older version of NSS than I thought it was. ipa-client-3.0.0-47.el6.centos.1.x86_64 defaults to requiring tls1.2 , but does not depend on a version of NSS that actually supports tls1.2. Manually installing an updated version of NSS has resolved the problem. Regards, Adam Bishop gpg: 0x6609D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. -- 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] Unable to join FreeIPA client to server
Client is running ipa-client-3.0.0-47.el6.centos.1.x86_64 on CentOS 6
Servers are running ipa-server-4.2.0-15.0.1.el7.centos.6.x86_64 on CentOS 7
When I try to join the CentOS 6 client to the CentOS 7 servers,
ipa-client-install is unable to access /ipa/xml, throwing the following error:
...
Connecting: [2001:630:1:177::98]:0
Failed to set TLS range to tls1.0, tls1.2
Could not connect socket to [2001:630:1:177::98]:443, error:
(SSL_ERROR_INVALID_VERSION_RANGE) SSL version range is not valid.
...
The full log follows, but I don't see anything interesting or unusual, other
than HTTPS connections are established OK earlier in the installation process.
I could use a bit of help resolving this - full client debug follows. Both
systems are running nss 3.19.1 which *should* support TLS1.2., so I'm unsure
where to start fixing this.
Thanks,
Adam Bishop
gpg: 0x6609D460
jisc.ac.uk
---
Starting IPA discovery with domain=example.org, servers=None,
hostname=rms1.example.org
Search for LDAP SRV record in example.org
Search DNS for SRV record of _ldap._tcp.example.org.
DNS record found:
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:atl-ipa-001.example.org.}
DNS record found:
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:swi-ipa-001.example.org.}
[Kerberos realm search]
Search DNS for TXT record of _kerberos.example.org.
DNS record found:
DNSResult::name:_kerberos.example.org.,type:16,class:1,rdata={data:example.org}
Search DNS for SRV record of _kerberos._udp.example.org.
DNS record found:
DNSResult::name:_kerberos._udp.example.org.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:swi-ipa-001.example.org.}
DNS record found:
DNSResult::name:_kerberos._udp.example.org.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:atl-ipa-001.example.org.}
[LDAP server check]
Verifying that atl-ipa-001.example.org (realm example.org) is an IPA server
Init LDAP connection with: ldap://atl-ipa-001.example.org:389
Search LDAP server for IPA base DN
Check if naming context 'dc=example,dc=org' is for IPA
Naming context 'dc=example,dc=org' is a valid IPA context
Search for (objectClass=krbRealmContainer) in dc=example,dc=org (sub)
Found: cn=example.org,cn=kerberos,dc=example,dc=org
Discovery result: Success; server=atl-ipa-001.example.org, domain=example.org,
kdc=swi-ipa-001.example.org,atl-ipa-001.example.org, basedn=dc=example,dc=org
Validated servers: atl-ipa-001.example.org
will use discovered domain: example.org
Start searching for LDAP SRV record in "example.org" (Validating DNS Discovery)
and its sub-domains
Search DNS for SRV record of _ldap._tcp.example.org.
DNS record found:
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:swi-ipa-001.example.org.}
DNS record found:
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:atl-ipa-001.example.org.}
DNS validated, enabling discovery
will use discovered server: atl-ipa-001.example.org
Discovery was successful!
will use discovered realm: example.org
will use discovered basedn: dc=example,dc=org
Hostname: rms1.example.org
Hostname source: Machine's FQDN
Realm: example.org
Realm source: Discovered from LDAP DNS records in atl-ipa-001.example.org
DNS Domain: example.org
DNS Domain source: Discovered LDAP SRV records from example.org
IPA Server: atl-ipa-001.example.org
IPA Server source: Discovered from LDAP DNS records in atl-ipa-001.example.org
BaseDN: dc=example,dc=org
BaseDN source: From IPA server ldap://atl-ipa-001.example.org:389
Continue to configure the system with these values? [no]: yes
args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r example.org
stdout=
stderr=realm not found
User authorized to enroll computers: admin
will use principal provided as option: admin
Synchronizing time with KDC...
Search DNS for SRV record of _ntp._udp.example.org.
No DNS record found
args=/usr/sbin/ntpdate -U ntp -s -b -v atl-ipa-001.example.org
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v atl-ipa-001.example.org
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v atl-ipa-001.example.org
stdout=
stderr=
Unable to sync time with IPA NTP server, assuming the time is in sync. Please
check that 123 UDP port is opened.
Writing Kerberos configuration to /tmp/tmpX2eUdM:
#File modified by ipa-client-install
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = example.org
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
[realms]
example.org = {
kdc = atl-ipa-001.example.org:88
master_kdc = atl-ipa-001.example.org:88
admin_server = atl-ipa-001.example.org:749
default_domain = example.org
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.org = example.org
e
[Freeipa-users] Config applied to SSSd
ipa-client-install on RHEL6-ish distro's configures SSSd as follows: [domain/MYDOMAIN] ... ipa_server = _srv_, ldap01.my.domain ... The man page isn't too clear on what is this value used for (or how ipa-client-install derives it in a multi-server deployment), or what would happen if ldap01 went offline. Is anyone able to clarify the how the defaults behave? Regards, Adam Bishop Systems Development Specialist gpg: 0x6609D460 t: +44 (0)1235 822 245 xmpp: ad...@jabber.dev.ja.net Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 -- 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] FreeIPA dual stacked
On 15 Apr 2013, at 17:45, John Dennis jden...@redhat.com wrote: We're supposed to work fine with IPv6. Dual stack should also be fine. I know we've done a bunch of testing in this area but apparently something fell through the cracks. I suspect this is an installer only issue where it's validation logic is not sufficiently robust. Please open a bug report so we can address this. I think if you pick one of the addresses and let the install proceed everything should just work. Please let us know if it doesn't. I'm not surprised we still have some IPv6 bumps to smooth out, it doesn't get exercised as much as IPv4. FWIW we fully expect IPv6 enabled systems to be dual stack. Thanks for the replies all, I'll complete the installation later today and open a ticket with any issues. Regards, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] FreeIPA dual stacked
Hi, I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump. The server hostname resolves to more than one address: :::::4 xxx.xxx.xxx.180 Please provide the IP address to be used for this host name: The answer I would like to give here is both - is this a limitation of the installation script that I can fix up later, or is FreeIPA incompatible with dual-stacked hosts at the moment? Thanks, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
