Re: [Freeipa-users] ipa-getcert and SELinux

[Thomas Raehalme]

Hi!

On Mon, Mar 7, 2016 at 11:20 PM, Rob Crittenden  wrote:

> It may be preferable to label the /var/lib/puppet/ssl/* directories as
> certmonger_var_lib_t but I don't know what would do to puppet. You could
> trade one problem for another. A BZ against selinux might be warranted
> to see what they think.
>

Thanks for the detailed instructions!

I found the issue https://bugzilla.redhat.com/show_bug.cgi?id=1062470 where
certmonger was granted READ access to Puppet libs. I wonder why WRITE
access was not added?

Best regards,
Thomas
-- 
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] ipa-getcert and SELinux

[Thomas Raehalme]

Hi!

I have setup certificates for Puppet as described here:
http://www.freeipa.org/page/Using_IPA's_CA_for_Puppet

Unfortunately SELinux is giving me hard time when invoking "ipa-getcert
request" to generate the private/public key for the Puppet agent
(permission denied when trying to write the key pair to
/var/lib/puppet/ssl).

Disabling SELinux temporarily solves the issue, but the same problem
reappears when renewing the certificate (ipa-getcert reports status
NEED_CERTSAVE_PERMS for the request).

What would be the proper way to enable the necessary permissions on SELinux?

Best regards,
Thomas
-- 
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] Identifying current CA master

[Thomas Raehalme]

Hi!

On Mon, Feb 23, 2015 at 10:29 AM, Martin Kosek mko...@redhat.com wrote:

 Good question. You are most likely hitting bug
 https://bugzilla.redhat.com/show_bug.cgi?id=1178190
 that is planned to be fixed in RHEL-6.7.

 It should only affect the display of the values, the actual storage and
 execution should be OK. As indicated in the bug, you can verify the values
 are
 set up correctly in /var/lib/certmonger/requests.

 Does that help?


I checked the request under /var/lib/certmonger/requests and post-save
command seems to be defined properly.

Thanks!

Best regards,
Thomas
-- 
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] Identifying current CA master

[Thomas Raehalme]

Hi!

I am in the process of migrating FreeIPA master to another server following
the instructions on page
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master.

In the instructions 'post-save command' should have one of two given
values, but when I execute the script on the current IPA master there is no
value at all:

# getcert list -d /var/lib/pki-ca/alias -n subsystemCert cert-pki-ca |
grep post-save
post-save command:

Is this a problem?

We are using ipa-server-3.0.0-42 on CentOS 6.6. According to yum the
original version which we installed is ipa-server-3.0.0-26.

Best regards,
Thomas
-- 
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] How to remove an offline replica?

[Thomas Raehalme]

Hi!

I have a replica which is offline, and I'd like to remove it (to be later
replaced).

When trying to remove the replica with ipa-replica-manage according to the
instructions on the wiki, I get an error about inaccessible LDAP server:

# ipa-replica-manage del ipa-1.example.com
Connection to 'ipa-1.example.com' failed: Can't contact LDAP server
Unable to delete replica 'ipa-1.example.com'

ipa-1.example.com is the IPA replica and I am executing the command on IPA
master.

I also tried disconnect, but the result was the same:

# ipa-replica-manage disconnect ipa-1.example.com
Failed to get list of agreements from 'ipa-1.example.com': Can't contact
LDAP server

Does anyone have a hint on how to get the replica removed? I'm running
ipa-server-3.0.0-42 on CentOS 6.6.

Thanks!

Best regards,
Thomas
-- 
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] How to remove an offline replica?

[Thomas Raehalme]

On Thu, Feb 19, 2015 at 9:41 PM, Thomas Raehalme 
thomas.raeha...@codecenter.fi wrote:

 # ipa-replica-manage del ipa-1.example.com
 Connection to 'ipa-1.example.com' failed: Can't contact LDAP server
 Unable to delete replica 'ipa-1.example.com'


And right after posting I found the --force command-line parameter which
did the trick!

Best regards,
Thomas
-- 
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] No LDAPS for dirsrv

[Thomas Raehalme]

On Wed, Feb 18, 2015 at 9:34 AM, Alexander Bokovoy aboko...@redhat.com
wrote:


 Unfortunately this still didn't resolve the issue. After the system has
 been online for about 10 minutes, named starts complaining:
 Also ldapsearch just hangs if you try to perform any queries.
 Any ideas what could go wrong here?

 So, can you get us a backtrace again?


Here is a summary of what is going on:

After a fresh start of IPA master with 'ipactl start' the system goes wrong
after 5-10 minutes.

What happens first is that KDC stops responding:

kinit thomas.raehalme
kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial
credentials

LDAP is still operational, however. It can be verified with ldapsearch.

Finally, after total of 15 minutes LDAP is also not responding:

Feb 18 10:00:12 ipa named[7410]: LDAP query timed out. Try to adjust
timeout parameter

Now I took some stacktraces which I will e-mail to you and Rob directly.

When I then try to stop dirsrv, it responds but seems to wait indefinitely:

[18/Feb/2015:10:03:03 +0200] - slapd shutting down - signaling operation
threads
[18/Feb/2015:10:03:03 +0200] - slapd shutting down - waiting for 30 threads
to terminate

I took two stacktraces from this situation as well.

Best regards,
Thomas
-- 
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 hangs, 0% CPU util

[Thomas Raehalme]

Hi!

On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy aboko...@redhat.com
wrote:

 I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586
 and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin
 configuration does not limit itself to $SUFFIX and listens to changes in
 cn=changelog too so it may deadlock with a replication traffic.

 We fixed these partly by changing slapi-nis configuration, partly by
 fixing bugs in 389-ds.

 I wonder if amending your slapi-nis config to avoid triggering internal
 searches on cn=changelog would be enough.


Is it possible to go around this issue by disabling replication? If so, is
ipa-replica-manage disconnect enough or should we use del instead?

Best regards,
Thomas
-- 
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] No LDAPS for dirsrv

[Thomas Raehalme]

Hi Chris!

On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler cmoh...@oberlin.edu wrote:


 As I wrote earlier we are having some serious problems with IPA right now.
 dirsrv seems to hang every 15 minutes or so, but that's another post.

 Are you running in a VM? If so check your entropy.
 cat /proc/sys/kernel/random/entropy_avail
 It should be ~1k less than 50 is not great and caused me some issues in
 the past.


Yes, the server is a VM. Entropy value is 135 at the moment. Do you know
how to increase the value?

It seems that slapd/dirsrv is now only listening on port 389 for LDAP and
 socket for LDAPI requests. Any idea what could have caused previously
 available LDAPS port 636 to disappear?

 Did your certificates expire? I usually check the web interface and look
 at the SSL Cert in the browser to see when it expires. I bet there is a
 better way to check but I don't know it off hand.


No, at least for the web interface certificates expire in August.

It turned out the nsslapd-security was 'off' when it should have been 'on'.
I really don't know what had changed the value.

Now I only wish we could resolve what's causing the dirsrv process to hang
(wrote about that in another message last Sunday) about 10 minutes after
IPA services were started.

Thanks for your help!

Best regards,
Thomas
-- 
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] No LDAPS for dirsrv

[Thomas Raehalme]

Hi!

As I wrote earlier we are having some serious problems with IPA right now.
dirsrv seems to hang every 15 minutes or so, but that's another post.

It seems that slapd/dirsrv is now only listening on port 389 for LDAP and
socket for LDAPI requests. Any idea what could have caused previously
available LDAPS port 636 to disappear?

Looking at the logs before this whole ordeal started port 636 was also in
use.

After the latest upgrade I have re-enabled port 389 manually because it's
used by some apps, but disabling it also doesn't bring back port 636.

Best regards,
Thomas
-- 
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] No LDAPS for dirsrv

[Thomas Raehalme]

Hi!

On Tue, Feb 17, 2015 at 6:34 PM, Rob Crittenden rcrit...@redhat.com wrote:


 If after an upgrade you had no listeners that means that the upgrade
 failed and wasn't able to restore the previous state. Look in
 /etc/dirsrv/slapd-YOURREALM for dse.ldif.ipa.###. This is the copy
 saved prior to the upgrade attempt. I'd diff it to dse.ldif to see what
 has changed.

 To enable port 636 just set nsslapd-security to on. If you do this via
 dse.ldif you'll need to stop the service before editing the file.


Thanks! For some reason the value of nsslapd-security is 'off' for the
current version although previous dse.ldif.ipa.## files have it enabled.
Changing the value back to 'on' re-enabled port 636.

Best regards,
Thomas
-- 
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] No LDAPS for dirsrv

[Thomas Raehalme]

Hi!

On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden rcrit...@redhat.com wrote:

  Now I only wish we could resolve what's causing the dirsrv process to
  hang (wrote about that in another message last Sunday) about 10 minutes
  after IPA services were started.

 Evidence suggests that the last upgrade failed so I'd start there. It is
 possible some plugins aren't configured properly, for example.


Looking at 'yum history' I performed an update after the problems had
started an hour or two before.

According to /var/log/ipaupgrade.log everything before ipa-ldap-updater ran
smoothly. But when it got to 'service dirsrv stop', it took 562 seconds to
shutdown dirsrv for EXAMPLE-COM and restarting dirsrv afterwards failed
with:

2015-02-15T12:29:58Z DEBUG   [4/8]: starting directory server
2015-02-15T12:30:09Z DEBUG args=/sbin/service dirsrv start
2015-02-15T12:30:09Z DEBUG stdout=Starting dirsrv:
PKI-IPA... already running[  OK  ]^M
PVNET-CC...[FAILED]^M
  *** Error: 1 instance(s) failed to start

2015-02-15T12:30:09Z DEBUG stderr=[15/Feb/2015:14:29:58 +0200] -
Information: Non-Secure Port Disabled

2015-02-15T12:30:09Z INFO   File
/usr/lib/python2.6/site-packages/ipapython/admintool.py, line 152, in
execute
return_value = self.run()
  File
/usr/lib/python2.6/site-packages/ipaserver/install/ipa_ldap_updater.py,
line 139, in run
upgrade.create_instance()
  File
/usr/lib/python2.6/site-packages/ipaserver/install/upgradeinstance.py,
line 84, in create_instance
show_service_name=False)
  File /usr/lib/python2.6/site-packages/ipaserver/install/service.py,
line 358, in start_creation
method()
  File
/usr/lib/python2.6/site-packages/ipaserver/install/upgradeinstance.py,
line 67, in __start_nowait
super(IPAUpgrade, self).start(wait=False)
  File /usr/lib/python2.6/site-packages/ipaserver/install/service.py,
line 265, in start
self.service.start(instance_name, capture_output=capture_output,
wait=wait)
  File /usr/lib/python2.6/site-packages/ipapython/platform/redhat.py,
line 80, in start
ipautil.run([/sbin/service, self.service_name, start,
instance_name], capture_output=capture_output)
  File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 316,
in run
raise CalledProcessError(p.returncode, args)

2015-02-15T12:30:09Z INFO The ipa-ldap-updater command failed, exception:
CalledProcessError: Command '/sbin/service dirsrv start ' returned non-zero
exit status 1
2015-02-15T12:30:09Z ERROR Unexpected error - see /var/log/ipaupgrade.log
for details:
CalledProcessError: Command '/sbin/service dirsrv start ' returned non-zero
exit status 1

Best regards,
Thomas
-- 
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] No LDAPS for dirsrv

[Thomas Raehalme]

Hi!

On Tue, Feb 17, 2015 at 8:43 PM, Thomas Raehalme 
thomas.raeha...@codecenter.fi wrote:

 Hi!

 On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden rcrit...@redhat.com
 wrote:

  Now I only wish we could resolve what's causing the dirsrv process to
  hang (wrote about that in another message last Sunday) about 10 minutes
  after IPA services were started.

 Evidence suggests that the last upgrade failed so I'd start there. It is
 possible some plugins aren't configured properly, for example.


After having restart ipa service, the upgrade command was completed
successfully:

# ipa-ldap-updater --upgrade
Upgrading IPA:
  [1/8]: stopping directory server
  [2/8]: saving configuration
  [3/8]: disabling listeners
  [4/8]: starting directory server
  [5/8]: upgrading server
  [6/8]: stopping directory server
  [7/8]: restoring configuration
  [8/8]: starting directory server
Done.

Now dirsrv was stopped in 2 second when the previous time was over 500
seconds.

Unfortunately this still didn't resolve the issue. After the system has
been online for about 10 minutes, named starts complaining:

Feb 17 21:04:14 ipa named[31117]: LDAP query timed out. Try to adjust
timeout parameter

Also ldapsearch just hangs if you try to perform any queries.

Any ideas what could go wrong here?

Best regards,
Thomas
-- 
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 hangs, 0% CPU util

[Thomas Raehalme]

On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy aboko...@redhat.com
wrote:

 I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586
 and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin
 configuration does not limit itself to $SUFFIX and listens to changes in
 cn=changelog too so it may deadlock with a replication traffic.

 We fixed these partly by changing slapi-nis configuration, partly by
 fixing bugs in 389-ds.

 I wonder if amending your slapi-nis config to avoid triggering internal
 searches on cn=changelog would be enough.

 If you have RHEL subscription, please open a case with Red Hat's
 support.


I opened a support case, but unfortunately the IPA server is running on
CentOS so no help from the support. Any chance you could share the
configuration changes you referred to above?

At the moment we cannot even access ipa-replica-manage because it Can'
contact LDAP server. I doubt it has something to do with Kerberos based
authentication, as kinit is also really unstable at the moment.

Best regards,
Thomas
-- 
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 hangs, 0% CPU util

[Thomas Raehalme]

On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy aboko...@redhat.com
wrote:

 I wonder if amending your slapi-nis config to avoid triggering internal
 searches on cn=changelog would be enough.


I can try, but would need some more details, if possible.



 If you have RHEL subscription, please open a case with Red Hat's
 support.


Ahh, it's been on my todo list for quite some time now (performing fresh
installs of all those CentOS servers isn't something I look forward to).
But an order has now been sent, and we'll start with IPA :-)

Best regards,
Thomas
-- 
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 hangs, 0% CPU util

[Thomas Raehalme]

Hi!

Today we started having problems with dirsrv hanging. We have observed the
following symptoms (using EXAMPLE.COM instead of the real domain):

/var/log/dirsrv/slapd-EXAMPLE-COM/errors:

[15/Feb/2015:21:48:50 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1
(Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not
connected)
[15/Feb/2015:21:48:50 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)

/var/log/messages:

Feb 15 21:49:02 ipa named[5545]: LDAP query timed out. Try to adjust
timeout parameter
Feb 15 21:49:03 ipa named[5545]: LDAP query timed out. Try to adjust
timeout parameter
(repeated)

Trying to access the DS also with ldapsearch just hangs:

ldapsearch -h localhost -x dc=example,dc=com

And Kerberos is unavailable as well:

# KRB5_TRACE=/dev/stdout kinit admin
[6421] 1424029967.466519: Getting initial credentials for ad...@example.com
[6421] 1424029967.467202: Sending request (172 bytes) to EXAMPLE.COM
[6421] 1424029967.467736: Sending initial UDP request to dgram 10.1.1.1:88
[6421] 1424029968.469031: Initiating TCP connection to stream 10.1.1.1:88
[6421] 1424029968.469205: Sending TCP request to stream 10.1.1.1:88
[6421] 1424029971.472024: Sending retry UDP request to dgram 10.1.1.1:88
[6421] 1424029976.477340: Sending retry UDP request to dgram 10.1.1.1:88
kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial
credentials

Strange thing is that there is hardly any CPU utilization when the problem
is occurring.

In addition we have started to see the following entries in
/var/log/messages:

Feb 15 21:37:27 ipa kernel: possible SYN flooding on port 88. Sending
cookies.
Feb 15 21:39:37 ipa kernel: possible SYN flooding on port 88. Sending
cookies.

I'm not sure if this is related, but it's something we haven't seen before.

We are running CentOS release 6.6 (Final) with the latest available
packages:

389-ds-base-libs-1.2.11.15-48.el6_6.x86_64
389-ds-base-1.2.11.15-48.el6_6.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
libipa_hbac-1.11.6-30.el6_6.3.x86_64
sssd-ipa-1.11.6-30.el6_6.3.x86_64
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-server-3.0.0-42.el6.centos.x86_64
libipa_hbac-python-1.11.6-30.el6_6.3.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
krb5-workstation-1.10.3-33.el6.x86_64
krb5-libs-1.10.3-33.el6.x86_64
sssd-krb5-common-1.11.6-30.el6_6.3.x86_64
python-krbV-1.0.90-3.el6.x86_64
krb5-server-1.10.3-33.el6.x86_64
sssd-krb5-1.11.6-30.el6_6.3.x86_64
pam_krb5-2.3.11-9.el6.x86_64

Killing the dirsrv processes and restarting them resolves the issue - until
it happens again after about 15 minutes.

Any idea what could have gone wrong? I can e-mail logs, if necessary.

Thank you in advance!

Best regards,
Thomas
-- 
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 hangs, 0% CPU util

[Thomas Raehalme]

Hi!

On Sun, Feb 15, 2015 at 11:37 PM, Rich Megginson rmegg...@redhat.com
wrote:


  Today we started having problems with dirsrv hanging. We have observed
 the following symptoms (using EXAMPLE.COM instead of the real domain):


 see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs


Thanks! Please find the stacktrace attached.

Best regards,
Thomas


stacktrace.1424039830.txt.gz
Description: GNU Zip compressed data
-- 
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 hangs, 0% CPU util

[Thomas Raehalme]

On Mon, Feb 16, 2015 at 12:57 AM, Rich Megginson rmegg...@redhat.com
wrote:

 Some info missing.  Since this is IPA, you'll need some additional
 debuginfo packages: debuginfo-install ipa-server slapi_nis (or maybe it's
 slapi-nis)

 Also looks as though the nspr debuginfo does not match the nspr version.
 rpm -q nspr nspr-debuginfo


I installed only the minimum debuginfo packages mentioned on the link (with
yum). Now I have added the ones you mentioned here.


 Finally, do some stacktraces every couple of seconds over a period of a
 minute.  For example, is the server really hung at the poll() in thread 32,
 or will the poll() eventually return write ready and proceed?


Will do. Unfortunately it'll probably not take too long until the next
occurrence.

Best regards,
Thomas
-- 
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] named's LDAP connection hangs

[Thomas Raehalme]

Hi!

Today it finally happened again - named is not resolving names under the
IPA domain, pvnet.cc. Killing the named process and restarting it solves
the problem (until it happens again).

Petr, I'll send you the logs directly so I don't have to leave anything
out. I hope that's okay.

Thank you for the help!

Best regards,
Thomas


On Mon, Jun 16, 2014 at 1:54 PM, Petr Spacek pspa...@redhat.com wrote:

 On 16.6.2014 09:41, Thomas Raehalme wrote:

 Hi,

 We have a problem with IPA going out of service every now and then. There
 seems to be two kinds of situations:

 1) The connection between named and dirsrv fails. Named can resolve
 external names but the domain managed by IPA does not resolve any names.
 named cannot be stopped. After killing the process and restarting the
 issue
 is resolved.

 2) Sometimes the situation is more severe and also dirsrv is unresponsive.
 The solution then seems to be restarting both named and dirsrv
 (individually or through the 'ipa' service).

 Regarding #1 the file /var/log/messages contains the following:

 Jun 16 03:22:23 ipa named[7295]: received control channel command 'reload'
 Jun 16 03:22:23 ipa named[7295]: loading configuration from
 '/etc/named.conf'
 Jun 16 03:22:23 ipa named[7295]: using default UDP/IPv4 port range: [1024,
 65535]
 Jun 16 03:22:23 ipa named[7295]: using default UDP/IPv6 port range: [1024,
 65535]
 Jun 16 03:22:23 ipa named[7295]: sizing zone task pool based on 6 zones
 Jun 16 03:22:23 ipa named[7295]: GSSAPI Error: Unspecified GSS failure.
 Minor code may provide more information (Ticket expired)
 Jun 16 03:22:23 ipa named[7295]: bind to LDAP server failed: Local error

 The reload is triggered by logrotate. For some reason authentication
 fails,
 and the IPA domain is no longer resolvable.

 I haven't discovered a pattern how often these problems occur. Maybe once
 a
 week or two.

 FreeIPA master running on CentOS 6.5 has been configured with the default
 settings. In addition a single replica has been added.

 Any ideas where I should look for the source of the problem?


 I have heard about this problem but nobody managed to reproduce the
 problem.

 Please:
 - configure KRB5_TRACE variable as described on
 https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a1.
 Gathersymptoms
 - restart named
 - send me logs when it happens again.

 Thank you!

 --
 Petr^2 Spacek

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users




-- 
*Thomas Raehalme*
*CTO, teknologiajohtaja*
Mobile +358 40 545 0605

*Codecenter Oy*
Väinönkatu 26 A, 4th Floor
40100 JYVÄSKYLÄ, Finland
Tel. +358 10 322 0040
www.codecenter.fi

*Codecenter - Tietojärjestelmiä ymmärrettävästi*
-- 
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] named's LDAP connection hangs

[Thomas Raehalme]

Hi,

We have a problem with IPA going out of service every now and then. There
seems to be two kinds of situations:

1) The connection between named and dirsrv fails. Named can resolve
external names but the domain managed by IPA does not resolve any names.
named cannot be stopped. After killing the process and restarting the issue
is resolved.

2) Sometimes the situation is more severe and also dirsrv is unresponsive.
The solution then seems to be restarting both named and dirsrv
(individually or through the 'ipa' service).

Regarding #1 the file /var/log/messages contains the following:

Jun 16 03:22:23 ipa named[7295]: received control channel command 'reload'
Jun 16 03:22:23 ipa named[7295]: loading configuration from
'/etc/named.conf'
Jun 16 03:22:23 ipa named[7295]: using default UDP/IPv4 port range: [1024,
65535]
Jun 16 03:22:23 ipa named[7295]: using default UDP/IPv6 port range: [1024,
65535]
Jun 16 03:22:23 ipa named[7295]: sizing zone task pool based on 6 zones
Jun 16 03:22:23 ipa named[7295]: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Ticket expired)
Jun 16 03:22:23 ipa named[7295]: bind to LDAP server failed: Local error

The reload is triggered by logrotate. For some reason authentication fails,
and the IPA domain is no longer resolvable.

I haven't discovered a pattern how often these problems occur. Maybe once a
week or two.

FreeIPA master running on CentOS 6.5 has been configured with the default
settings. In addition a single replica has been added.

Any ideas where I should look for the source of the problem?

Thank you in advance!

Best regards,
Thomas
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] named's LDAP connection hangs

[Thomas Raehalme]

Hi!

Thanks for the instructions. I have configured KRB5_TRACE as described. I
will send logs as soon as we encounter the problem again. Could take a week
or two though.

Thank you for your help!

Best regards,
Thomas


On Mon, Jun 16, 2014 at 1:54 PM, Petr Spacek pspa...@redhat.com wrote:

 On 16.6.2014 09:41, Thomas Raehalme wrote:

 Hi,

 We have a problem with IPA going out of service every now and then. There
 seems to be two kinds of situations:

 1) The connection between named and dirsrv fails. Named can resolve
 external names but the domain managed by IPA does not resolve any names.
 named cannot be stopped. After killing the process and restarting the
 issue
 is resolved.

 2) Sometimes the situation is more severe and also dirsrv is unresponsive.
 The solution then seems to be restarting both named and dirsrv
 (individually or through the 'ipa' service).

 Regarding #1 the file /var/log/messages contains the following:

 Jun 16 03:22:23 ipa named[7295]: received control channel command 'reload'
 Jun 16 03:22:23 ipa named[7295]: loading configuration from
 '/etc/named.conf'
 Jun 16 03:22:23 ipa named[7295]: using default UDP/IPv4 port range: [1024,
 65535]
 Jun 16 03:22:23 ipa named[7295]: using default UDP/IPv6 port range: [1024,
 65535]
 Jun 16 03:22:23 ipa named[7295]: sizing zone task pool based on 6 zones
 Jun 16 03:22:23 ipa named[7295]: GSSAPI Error: Unspecified GSS failure.
 Minor code may provide more information (Ticket expired)
 Jun 16 03:22:23 ipa named[7295]: bind to LDAP server failed: Local error

 The reload is triggered by logrotate. For some reason authentication
 fails,
 and the IPA domain is no longer resolvable.

 I haven't discovered a pattern how often these problems occur. Maybe once
 a
 week or two.

 FreeIPA master running on CentOS 6.5 has been configured with the default
 settings. In addition a single replica has been added.

 Any ideas where I should look for the source of the problem?


 I have heard about this problem but nobody managed to reproduce the
 problem.

 Please:
 - configure KRB5_TRACE variable as described on
 https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a1.
 Gathersymptoms
 - restart named
 - send me logs when it happens again.

 Thank you!

 --
 Petr^2 Spacek

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users




-- 
*Thomas Raehalme*
*CTO, teknologiajohtaja*
Mobile +358 40 545 0605

*Codecenter Oy*
Väinönkatu 26 A, 4th Floor
40100 JYVÄSKYLÄ, Finland
Tel. +358 10 322 0040
www.codecenter.fi

*Codecenter - Tietojärjestelmiä ymmärrettävästi*
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications

[Thomas Raehalme]

Hi!

On Thu, Sep 12, 2013 at 3:28 PM, Martin Kosek mko...@redhat.com wrote:

 When using FreeIPA LDAP as identity source, you could ideally use
 Kerberos/GSSAPI authentication. But if that is not available, you can use
 simple LDAP binds too. You cannot read the hash codes unless you are
 cn=Directory Manager (or unless you set ACI allowing that, but this is very
 unsecure).

Could you please elaborate on using simple LDAP binds?

Thanks for the detailed example!

Best regards,
Thomas

-- 
Thomas Raehalme
CTO, teknologiajohtaja
Mobile +358 40 545 0605

Codecenter Oy
Väinönkatu 26 A, 4th Floor
40100 JYVÄSKYLÄ, Finland
Tel. +358 10 322 0040
www.codecenter.fi

Codecenter - Tietojärjestelmiä ymmärrettävästi

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using subdomains (or dots) in hostnames

[Thomas Raehalme]

Hi!

 Let's say we're using domain example.com. Adding clients a.example.com
 and b.example.com was smooth. Adding client a.sub1.example.com also
 had no problems until I tried to get sudoers from the IPA server
 (using SSSD and LDAP as suggested). The client fails to find any users
 matching the server name. Because the only difference compared to a
 fully functional server is the dot in the host name, that's probably
 the reason why no sudoers are found for the server in the subdomain?

What do you use in nsswitch.conf for sudoers? ldap or sss? If sss, can
you also paste your sssd.conf?

Can you paste the output of sudo along with the -D parameter to get some
debugging?

I managed to get subdomains working after adding the subdomain to the
IPA DNS and filling in the various SRV records pointing to the IPA
master. After the DNS was setup properly, DNS discovery would display
the correct subdomain on ipa-client-install.

After the DNS discovery was successful, also sudo started working
properly on most servers. As I specified sss for sudoers in
nsswitch.conf and added the necessary configuration to sssd.conf as
described in the RedHat documentation, I was able to sudo the commands
I had enabled in the IPA policy. That's great!

Some servers are still, however, causing headache. According to
/var/log/secure sudo can authenticate me, but for some reason the list
of allowed commands is empty (sudo -l responds Sorry, user xxx may
not run sudo on yyy.). I have defined sudo rules so that anybody can
use sudo on any host, but only certain commands. I'll try to debug the
problems and let you know how it goes.

The caching mechanism for sudo/sssd and especially clearing the cache
with sss_cache has turned out to be somewhat challenging to
understand. Does anybody know the correct parameters that cause the
sudoers cache be invalidated?

Thanks also to everybody else for replying to my message!

Best regards,
Thomas



-- 
Thomas Raehalme
CTO, teknologiajohtaja
Mobile +358 40 545 0605

Codecenter Oy
Väinönkatu 26 A, 4th Floor
40100 JYVÄSKYLÄ, Finland
Tel. +358 10 322 0040
www.codecenter.fi

Codecenter - Tietojärjestelmiä ymmärrettävästi

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications

[Thomas Raehalme]

Hi!

On Thu, Sep 12, 2013 at 4:33 PM, Martin Kosek mko...@redhat.com wrote:
 Well, LDAP is the data backend for all FreeIPA identity data, you can 
 certainly
 use plain LDAP binds with them (though Kerberos/GSSAPI auth is preferred).
 # ldapsearch -h `hostname` -D 
 uid=jdoe,cn=users,cn=accounts,dc=example,dc=com
 -x -w xO3xs5yOv,dL -b  -s base

Now I got it working. I didn't remember to use dn to login, so no
wonder it didn't work :-)

Thank you for all your help!

Best regards,
Thomas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications

[Thomas Raehalme]

Hi!

On Thu, Sep 12, 2013 at 4:06 PM, Martin Kosek mko...@redhat.com wrote:
 I was just referring to fact, that when a system or application uses LDAP as 
 an
 identity and authentication source, it often use simple LDAP Bind operation
 (i.e. accessing LDAP with user+password or) when testing if the user accessing
 the application provided the right credentials.

Yes, that's true at least for some applications. Does the LDAP in
FreeIPA allow that kind of login by default for IPA users? If not, is
it possible to enable it somehow?

Best regards,
Thomas Raehalme
-- 
Thomas Raehalme
CTO, teknologiajohtaja
Mobile +358 40 545 0605

Codecenter Oy
Väinönkatu 26 A, 4th Floor
40100 JYVÄSKYLÄ, Finland
Tel. +358 10 322 0040
www.codecenter.fi

Codecenter - Tietojärjestelmiä ymmärrettävästi

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications

[Thomas Raehalme]

Hi,

Previously we have used Atlassian Crowd as a source for user data in
various applications, both in-house built and proprietary such as JIRA
or Confluence. As we have deployed FreeIPA, I would like to start
using it as the identity source. Unfortunately using Kerberos is not
always possible so I am thinking about LDAP which often is an option
in 3rd party applicaitons.

Anonymous access to the FreeIPA LDAP is enabled by default. Is it
possible to configure username/password to access the information?
Currently vSphere has a problem with anonymous access to LDAP not
working as intended. Ofcourse it would be nice to be able to restrict
access anyways.

If using FreeIPA LDAP as the identity source, how should
authentication be handled? Is it possible to read the hash code for
passwords? Is it possible to authenticate against the LDAP service?

Any advice appreciated!

Best regards,
Thomas
-- 
Thomas Raehalme
CTO, teknologiajohtaja
Mobile +358 40 545 0605

Codecenter Oy
Väinönkatu 26 A, 4th Floor
40100 JYVÄSKYLÄ, Finland
Tel. +358 10 322 0040
www.codecenter.fi

Codecenter - Tietojärjestelmiä ymmärrettävästi

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Using subdomains (or dots) in hostnames

[Thomas Raehalme]

Hi!

We are in the process of deploying FreeIPA in our virtual environment.
So far things are working smoothly and I am really impressed by the
solution!

One question has risen as we have added our first clients to the
system. Because the total number of clients is 50 and going up, we
have divided our servers to subdomains depending on the purpose of the
server, ie. test servers in one subdomain, internal services on
another and so on. There is, however, no need for each subdomain to
have its own IPA server.

Let's say we're using domain example.com. Adding clients a.example.com
and b.example.com was smooth. Adding client a.sub1.example.com also
had no problems until I tried to get sudoers from the IPA server
(using SSSD and LDAP as suggested). The client fails to find any users
matching the server name. Because the only difference compared to a
fully functional server is the dot in the host name, that's probably
the reason why no sudoers are found for the server in the subdomain?

For IPA master I am using CentOS 6.4 and
ipa-server-3.0.0-26.el6_4.4.x86_64. The clients are also CentOS 6.4
with ipa-client-3.0.0-26.el6_4.4.x86_64.

Any help is appreciated! Please let me know if providing any piece of
information helps.

Best regards,
Thomas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users