date:20141107

Re: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations

2014-11-07 Thread Petr Spacek


On 6.11.2014 16:41, Dmitri Pal wrote:

On 11/06/2014 10:00 AM, Martin Basti wrote:

On 06/11/14 14:58, Walter van Lille wrote:

Hi,

I need some assistance please.
I've taken over an IPA server to manage a few months ago, and it was
working fine until recently when it started acting up seemingly off its own
accord.
When I do an ipactl status it basically gives an output as shown below:


*Directory Service: RUNNING
*
*
*
*Loong pause... (To the
tune of 7 minutes sometimes)*
*
*
*KDC Service: RUNNING*
*KPASSWD Service: RUNNING*
*DNS Service: RUNNING*
*MEMCACHE Service: RUNNING*
*HTTP Service: RUNNING*
*CA Service: RUNNING*
*ADTRUST Service: RUNNING*
*EXTID Service: RUNNING*

Running top showed that ns-slapd was munching almost all my resources, but
I got that fixed by upping the cache. Unfortunately this did not correct
the issue and it still reacts in the same fashion, although the resources
have been freed up now.
I've noticed that when I run dig on either the local server or a remote
machine that the query basically just times out as shown here:

*dig freeipa.myexample.sample*
*
*
*; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>>
freeipa.myexample.sample*
*;; global options: +cmd*
*;; connection timed out; no servers could be reached*

When the KDC service fails to start, then name lookups seem OK, but
authentication fails. otherwise it's dead in the water.

This also happens:

*sudo ipactl status*
*Directory Service: RUNNING*
*Unknown error when retrieving list of services from LDAP:*
*
*
My software setup is as follows:

*CentOS release 6.5 (Final)
*
*389-ds-base.x86_64   1.2.11.15-34.el6_5
*
*bind.x86_64  32:9.8.2-0.23.rc1.el6_5.1
*
*bind-dyndb-ldap.x86_64*
*bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1*
*bind-utils.x86_6432:9.8.2-0.23.rc1.el6_5.1*
*rpcbind.x86_64   0.2.0-11.el6 @anaconda-CentOS-201311291202.x86_64/6.5*
*samba4-winbind.x86_64*
*krb5-server.x86_64   1.10.3-15.el6_5.1
*
*
*
*Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
*

It's not a permanent situation as it sometimes runs 100% for a while, but
80% of the time it is unusable. If anybody can assist me, please be so kind.

Regards,

Walter


Hello please which version of bind-dyndb-ldap do you use?
I had similar issue with bind-dyndb-ldap, but it was development version,
I'm not sure if this is your case.
When named was failing, dirserv was really slow.

Can you send journalctl -b -u named log when dig doesn't work??

--
Martin Basti



You also want to look at the directory server logs especially at startup and
see what is it doing.
Also check the diskspace. May be you do not have much room on the volume and
it might cause DS to slow down.


One thing to keep in mind:
FreeIPA DNS service is backed by LDAP so can't possibly work if your LDAP 
server is down or is unresponsive.


If you encounter a problem with DNS again please try to follow steps 1-5 
described on page 
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart .


I'm mainly interested in results obtained in step 5 (other steps are just 
prerequisite).  It will tell us if DNS (bind-dyndb-ldap) is broken or if LDAP 
server does not respond and DNS is failing because of the cascade/domino effect.


Good luck!

--
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

Re: [Freeipa-users] Kerberos for cronjoob

2014-11-07 Thread Sumit Bose

On Thu, Nov 06, 2014 at 10:28:34PM -0500, Dmitri Pal wrote:
> On 11/06/2014 08:20 PM, Thomas Lau wrote:
> >?Hi,
> >
> >Is it possible to renew ticket once in a while for cronjob to run on
> >certain users? How do you guys run cronjob on Kerberos user without
> >getting ticket expire?
> >
> >Sent from my BlackBerry 10 smartphone.
> >
> >
> Here is an example: 
> http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/
> 
> But starting kerberos  1.11 kerberos library should be able to automatically
> renew the ticket for service accounts
> http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation

SSSD can renew tickets as well, see krb5_renew_interval option described
in sssd-krb5(5).

Depending on how often your cronjob is run and what is the lifetime of
your tickets you might just call 'kinit -R' at the beginning of the
cronjob.

bye,
Sumit

> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
> 

> -- 
> 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

-- 
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] Fwd: Re: dns stops working after upgrade

2014-11-07 Thread Martin Basti

Forward message back to list

 Original Message 
Subject:Re: [Freeipa-users] dns stops working after upgrade
Date:   Thu, 6 Nov 2014 21:42:55 +0100
From:   Rob Verduijn 
To: Martin Basti 

Hi again,

I tried the update to 4.1.1
It didn't went well, actually it went worse than to 4.1.
Now the directory service went down and was no longer able to start.

Some part of the logs is below.
Besides the warnings about a weak cipher there was not much in the 
journalctl.

It's getting late overhere, I'll dig into the logs tomorrow.

Rob

Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory 
Server TJAKO-THUIS
Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory 
Server TJAKO-THUIS..
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5 is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 is weak. 
It is enabled since allowWeakCipher is "on" (default setting for the 
backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 is weak. 
It is enabled since allowWeakCipher is "on" (default setting for the 
backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is weak. It 
is enabled since allowWeakCipher is "on" (default setting for the 
backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is weak. 
It is enabled since allowWeakCipher is "on" (default setting for the 
backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_3des_sha is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza is not 
available in NSS 3.17.  Ignoring fortezza
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite 
fortezza_rc4_128_sha is not available in NSS 3.17.  Ignoring 
fortezza_rc4_128_sha
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_null is 
not available in NSS 3.17.  Ignoring fortezza_null
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher 
tls_rsa_export1024_with_rc4_56_sha is weak.  It is enabled since 
allowWeakCipher is "on" (default setting for the backward 
compatibility). We strongly recommend to set it to "off".  Please 
replace the value of allowWeakCipher with "off" in the encryption config 
entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher 
tls_rsa_export1024_with_des_cbc_sha is weak.  It is enabled since 
allowWeakCipher is "on" (default setting for the backward 
compatibility). We strongly recommend to set it to "off".  Please 
replace the value of allowWeakCipher with "off" in the encryption config 
entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: 
[0

Re: [Freeipa-users] Kerberos for cronjoob

2014-11-07 Thread Thomas Lau

Hi,

Thanks for replying.

I am running Ubuntu 14 IPA client, here is the result when I try to run
kinit -R
tlau@mocha:~$ kinit -R
kinit: KDC can't fulfill requested option while renewing credentials
tlau@mocha:~$ klist
Ticket cache: FILE:/tmp/krb5cc_121843_rZ7eX7
Default principal: t...@domain.com

Valid starting   Expires  Service principal
2014-11-07T16:59:42  2014-11-08T16:59:42  krbtgt/domain@domain.com
tlau@mocha:~$ date
Fri Nov  7 17:09:24 HKT 2014

Any idea why?


On Fri, Nov 7, 2014 at 4:41 PM, Sumit Bose  wrote:

> On Thu, Nov 06, 2014 at 10:28:34PM -0500, Dmitri Pal wrote:
> > On 11/06/2014 08:20 PM, Thomas Lau wrote:
> > >?Hi,
> > >
> > >Is it possible to renew ticket once in a while for cronjob to run on
> > >certain users? How do you guys run cronjob on Kerberos user without
> > >getting ticket expire?
> > >
> > >Sent from my BlackBerry 10 smartphone.
> > >
> > >
> > Here is an example:
> http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/
> >
> > But starting kerberos  1.11 kerberos library should be able to
> automatically
> > renew the ticket for service accounts
> > http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation
>
> SSSD can renew tickets as well, see krb5_renew_interval option described
> in sssd-krb5(5).
>
> Depending on how often your cronjob is run and what is the lifetime of
> your tickets you might just call 'kinit -R' at the beginning of the
> cronjob.
>
> bye,
> Sumit
>
> >
> > --
> > Thank you,
> > Dmitri Pal
> >
> > Sr. Engineering Manager IdM portfolio
> > Red Hat, Inc.
> >
>
> > --
> > 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
>
> --
> 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
>
-- 
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] Kerberos for cronjoob

2014-11-07 Thread Alexander Bokovoy


On Fri, 07 Nov 2014, Sumit Bose wrote:

On Thu, Nov 06, 2014 at 10:28:34PM -0500, Dmitri Pal wrote:

On 11/06/2014 08:20 PM, Thomas Lau wrote:
>?Hi,
>
>Is it possible to renew ticket once in a while for cronjob to run on
>certain users? How do you guys run cronjob on Kerberos user without
>getting ticket expire?
>
>Sent from my BlackBerry 10 smartphone.
>
>
Here is an example: 
http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/

But starting kerberos  1.11 kerberos library should be able to automatically
renew the ticket for service accounts
http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation


SSSD can renew tickets as well, see krb5_renew_interval option described
in sssd-krb5(5).

Depending on how often your cronjob is run and what is the lifetime of
your tickets you might just call 'kinit -R' at the beginning of the
cronjob.

Note that it will only work if your KDC allows to issue renewable
tickets. FreeIPA by default does allow it but you have to explicitly ask
for renewable time longer than the ticket validity time:
$ kinit -r 15h -l 10h admin 
Password for ad...@ipacloud.test: 
$ klist -edf  
Ticket cache: KEYRING:persistent:1000:1000

Default principal: ad...@ipacloud.test

Valid starting   Expires  Service principal
07.11.2014 11:10:56  07.11.2014 21:10:53  krbtgt/ipacloud.t...@ipacloud.test
   renew until 08.11.2014 02:10:53, Flags: FRIA
   Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 


as can be seen above, I've asked for 15h of renewal time while ticket
lifetime is 10h. I'm getting back a TGT that has R flag set (renewable)
and that can be renewed 5h beyond the expiration time. Not that 5 hours
are helpful here because if ticket is expired, it cannot be renewed
anymore even it the R flag is there but renewal time has to be longer
than the ticket lifetime in order to get 'renewable' flag set.
--
/ 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] Centos IPA Client fails after upgrade to 6.6

2014-11-07 Thread Jakub Hrozek

On Thu, Nov 06, 2014 at 09:33:35PM -0800, Michael Lasevich wrote:
> For what its worth, my issue was resolved when I rebooted the server.
> 
> Restarting sssd and/or clearing it's cache did not do it, but a full reboot
> seems to have done it. Something much have been cached or some temp file I
> missed. Will need to look into it further as I have a number of servers yet
> to be upgraded and having to reboot linux servers to do an upgrade seem
> sacrilegious...

We need to see the krb5_child.log file ideally with a very high
debug_level (10 would enable KRB5_TRACE debugging as well..)

> 
> -M
> 
> On Thu, Nov 6, 2014 at 9:26 PM, David Taylor 
> wrote:
> 
> >  As an add on, I’ve upgraded our Xen template to 6.6 and run up a new VM
> > using that and it attaches to the IPA environment perfectly well, so I’m
> > guessing it is an issue with the upgrade scripts.
> >
> >
> >
> >
> >
> > Best regards
> >
> > *David Taylor*
> >
> >  *From:* Michael Lasevich [mailto:mlasev...@gmail.com]
> > *Sent:* Friday, 7 November 2014 4:00 PM
> > *To:* Jakub Hrozek
> > *Cc:* David Taylor; freeipa-users@redhat.com
> > *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to
> > 6.6
> >
> >
> >
> > I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11
> > (centos 6.5 to 6.6)
> >
> >
> >
> > I seem to be able to log in via ssh, but when I use http pam service, I
> > get inconsistent behavior - seems like sometimes it works and others it
> > errors out (success and failure can happen within a second)
> >
> >
> >
> > In the logs I see things like:
> >
> >
> >
> > [sssd[krb5_child[15410]]]: Internal credentials cache error
> >
> > and
> >
> > authentication failure; logname= uid=48 euid=48 tty= ruser= rhost=
> > user=username
> > received for user username: 4 (System error)
> >
> > Nothing in the audit.log that I can see
> >
> > I am guessing this is an sssd issue but I am hoping someone here knows how
> > to deal with it.
> >
> > IN case it matters - here is the pam config:
> >
> > authrequired  pam_env.so
> > authsufficientpam_sss.so
> > authrequired  pam_deny.so
> >
> > account [default=bad success=ok user_unknown=ignore] pam_sss.so
> > account required  pam_permit.so
> >
> > passwordrequisite pam_cracklib.so try_first_pass retry=3 type=
> > passwordsufficientpam_sss.so use_authtok
> > passwordrequired  pam_deny.so
> >
> >
> >
> > session optional  pam_keyinit.so revoke
> > session required  pam_limits.so
> > session optional  pam_oddjob_mkhomedir.so
> > session [success=1 default=ignore] pam_succeed_if.so service in crond
> > quiet use_uid
> > session optional  pam_sss.so
> >
> > -M
> >
> >
> >
> > On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek  wrote:
> >
> >  On Wed, Nov 05, 2014 at 02:30:55AM +, David Taylor wrote:
> > > Thanks for the reply. The PAM file is pretty stock for a centos build
> > >
> > > #%PAM-1.0
> > > # This file is auto-generated.
> > > # User changes will be destroyed the next time authconfig is run.
> > > authrequired  pam_env.so
> > > authsufficientpam_unix.so nullok try_first_pass
> > > authrequisite pam_succeed_if.so uid >= 500 quiet
> > > authsufficientpam_sss.so use_first_pass
> > > authrequired  pam_deny.so
> > >
> > > account required  pam_unix.so
> > > account sufficientpam_localuser.so
> > > account sufficientpam_succeed_if.so uid < 500 quiet
> > > account [default=bad success=ok user_unknown=ignore] pam_sss.so
> > > account required  pam_permit.so
> > >
> > > passwordrequisite pam_cracklib.so try_first_pass retry=3 type=
> > > passwordsufficientpam_unix.so sha512 shadow nullok
> > try_first_pass use_authtok
> > > passwordsufficientpam_sss.so use_authtok
> > > passwordrequired  pam_deny.so
> > >
> > > session optional  pam_keyinit.so revoke
> > > session required  pam_limits.so
> > > session [success=1 default=ignore] pam_succeed_if.so service in
> > crond quiet use_uid
> > > session required  pam_unix.so
> > > session optional  pam_sss.so
> > >
> > >
> > > Best regards
> > > David Taylor
> >
> > OK, so pam_sss is there ...
> >
> > And yet you see no mention of pam_sss.so in /var/log/secure ?
> >
> > Is this the file that was included from the service-specific PAM
> > configuration?
> >
> >
> > --
> > 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
> >
> >
> >

-- 
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] DS failed after upgrade

2014-11-07 Thread Martin Basti


Changed subject.
Rob CCed

On 07/11/14 09:52, Martin Basti wrote:

Forward message back to list


 Original Message 
Subject:Re: [Freeipa-users] dns stops working after upgrade
Date:   Thu, 6 Nov 2014 21:42:55 +0100
From:   Rob Verduijn 
To: Martin Basti 



Hi again,

I tried the update to 4.1.1
It didn't went well, actually it went worse than to 4.1.
Now the directory service went down and was no longer able to start.

Some part of the logs is below.
Besides the warnings about a weak cipher there was not much in the 
journalctl.


It's getting late overhere, I'll dig into the logs tomorrow.

Rob

Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory 
Server TJAKO-THUIS
Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory 
Server TJAKO-THUIS..
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5 is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is weak. 
It is enabled since allowWeakCipher is "on" (default setting for the 
backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is weak. 
It is enabled since allowWeakCipher is "on" (default setting for the 
backward compatibility). We strongly recommend to set it to "off".  
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_3des_sha is 
weak. It is enabled since allowWeakCipher is "on" (default setting for 
the backward compatibility). We strongly recommend to set it to "off". 
Please replace the value of allowWeakCipher with "off" in the 
encryption config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza is not 
available in NSS 3.17.  Ignoring fortezza
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite 
fortezza_rc4_128_sha is not available in NSS 3.17. Ignoring 
fortezza_rc4_128_sha
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_null 
is not available in NSS 3.17.  Ignoring fortezza_null
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher 
tls_rsa_export1024_with_rc4_56_sha is weak.  It is enabled since 
allowWeakCipher is "on" (default setting for the backward 
compatibility). We strongly recommend to set it to "off".  Please 
replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.
Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: 
[06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher 
tls_rsa_export1024_with_des_cbc_sha is weak.  It is enabled since 
allowWeakCipher is "on" (default setting for the backward 
compatibility). We strongly recommend to set it to "off".  Please 
replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the

Re: [Freeipa-users] unable to sudo

2014-11-07 Thread Jakub Hrozek

On Thu, Nov 06, 2014 at 07:27:04PM +, Craig White wrote:
> -Original Message-
> From: Lukas Slebodnik [mailto:lsleb...@redhat.com] 
> Sent: Thursday, November 06, 2014 9:34 AM
> To: Craig White
> Cc: t...@tetrioncapital.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] unable to sudo
> 
> On (06/11/14 15:42), Craig White wrote:
> >As Bob pointed out in a direct e-mail to me, there was the detail of adding 
> >sudo and sss to /etc/nsswitch.conf but – once I did so, it pointed out that 
> >the Rackspace RHEL packaging that doesn’t provide what I need – possibly 
> >need from epel.
> >
> 
> ># yum search /usr/lib64/libsss_sudo.so
> This file was in separate package in sssd 1.9. The packaging was changed in 
> sssd >= 1.10 and it is installed by default (part of package sssd-common) and 
> rhel/CentOS 6.6 contains sssd 1.11.6
> 
> Unfortunately for me, Rackspace still has these boxes on RHEL 6.5
> 
> # rpm -qa | grep sssd
> sssd-client-1.9.2-129.el6_5.4.x86_64
> sssd-1.9.2-129.el6_5.4.x86_64
> 
> nowhere to go I think - thanks

I find it odd that they'd only give you half of the packages.

Anyway, can you grab libsss_sudo RPMs from CentOS ?

-- 
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] mastercrl.bin very old

2014-11-07 Thread Martin Kosek


On 11/05/2014 09:20 PM, Natxo Asenjo wrote:

On Wed, Nov 5, 2014 at 7:45 PM, Natxo Asenjo  wrote:

And I think I found it:
https://fedorahosted.org/freeipa/ticket/3727


permissions of that folder:

$ ls -ld publish/
drwxr-xr-x. 2 root root 73728 Jun 13  2013 publish/

I just changed them to pkiuser:pkiuser, let's see what the next run does.


and it's fixed (after undoing the change in CS.cfg and re-setting

ca.crl.MasterCRL.enableCRLCache=false
ca.crl.MasterCRL.enableCRLUpdates=false

both to true and reloading pki-cad):

-rw-rw-r--. 1 pkiuser pkiuser 1807 Jun 28  2013 MasterCRL-20130628-21.der
-rw-rw-r--. 1 pkiuser pkiuser 5278 Nov  5 21:00 MasterCRL-20141105-21.der
lrwxrwxrwx. 1 pkiuser pkiuser   57 Nov  5 21:00 MasterCRL.bin ->
/var/lib/ipa/pki-ca/publish/MasterCRL-20141105-21.der

phew


Good! I am glad you fixed the problem. I added this case to
http://www.freeipa.org/page/Troubleshooting#CRL_gets_very_old

I am wondering what caused the issue. In the beginning you wrote that you use 
centos 6.5. However, the bug you correctly referred to was fixed in 6.5:


https://bugzilla.redhat.com/show_bug.cgi?id=975431

So I am wondering if some scenario was missed and for example the IPA updater 
did not fix the folder ownership.


Thanks,
Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] ATTN: CVE-2014-7828

2014-11-07 Thread Martin Kosek


On 11/05/2014 09:43 PM, Alexander Bokovoy wrote:

Hi,

Heads up for those who are using 2FA feature of FreeIPA 4.0 and 4.1.
A security issue was identified in the released versions of FreeIPA 4.0
and 4.1 that makes possible for users with enabled OTP token to
authenticate using only the second factor.

We have a fix available already and will be doing releases for 4.0.5 and
4.1.1 tomorrow to get packages into Fedora 21, COPR repos, and Debian
Unstable.

In meantime, you can mitigate by disabling OTP authentication for the
users.

Sorry for inconvenience.

https://fedorahosted.org/freeipa/ticket/4690


Just to close the thread, FreeIPA releases fixing the CVE are now in both 
Fedora 21 updates-testing repository and also in the main Copr repository.


Details also in http://www.freeipa.org/page/CVE-2014-7828

Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] mastercrl.bin very old

2014-11-07 Thread Natxo Asenjo

hi Martin,

On Fri, Nov 7, 2014 at 10:46 AM, Martin Kosek  wrote:

> Good! I am glad you fixed the problem. I added this case to
> http://www.freeipa.org/page/Troubleshooting#CRL_gets_very_old

nice. Hopefully it will help someone.

> I am wondering what caused the issue. In the beginning you wrote that you
> use centos 6.5. However, the bug you correctly referred to was fixed in 6.5:


> https://bugzilla.redhat.com/show_bug.cgi?id=975431
>
> So I am wondering if some scenario was missed and for example the IPA
> updater did not fix the folder ownership.

Maybe there is a difference between the RHEL and centos rpm's ...

I guess it's time to start monitoring the crl as well for (plenty of
choice in the nagios exchange, apparently).

Thanks for the tip!

--
Groeten,
natxo

-- 
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] DS failed after upgrade

2014-11-07 Thread Rob Verduijn

Hi all,

Either I was to worn out last night, or another update has happened.
This morning the directory server did start after the update.
local dns zones however where not available again after the update
ipa-ldap-updater did not help to fix it.

The are again only 7 DNS aci objects are still in the ds.( same as before
when it failed )
I also noticed that there are also quite a lot lower case dns aci objects.

Rob




2014-11-07 10:25 GMT+01:00 Martin Basti :

>  Changed subject.
> Rob CCed
>
> On 07/11/14 09:52, Martin Basti wrote:
>
> Forward message back to list
>
>
>  Original Message   Subject: Re: [Freeipa-users] dns
> stops working after upgrade  Date: Thu, 6 Nov 2014 21:42:55 +0100  From: Rob
> VerduijnTo: Martin
> Basti  
>
> Hi again,
>
>  I tried the update to 4.1.1
> It didn't went well, actually it went worse than to 4.1.
> Now the directory service went down and was no longer able to start.
>
>  Some part of the logs is below.
> Besides the warnings about a weak cipher there was not much in the
> journalctl.
>
>  It's getting late overhere, I'll dig into the logs tomorrow.
>
>  Rob
>
>  Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory
> Server TJAKO-THUIS
> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory
> Server TJAKO-THUIS..
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_rc4_40_md5 is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_rc2_40_md5 is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_des_sha is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_fips_des_sha is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_3des_sha is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher rsa_fips_3des_sha is weak. It is enabled since
> allowWeakCipher is "on" (default setting for the backward compatibility).
> We strongly recommend to set it to "off".  Please replace the value of
> allowWeakCipher with "off" in the encryption config entry
> cn=encryption,cn=config and restart the server.
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher suite fortezza is not available in NSS 3.17.
> Ignoring fortezza
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher suite fortezza_rc4_128_sha is not available in
> NSS 3.17.  Ignoring fortezza_rc4_128_sha
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher suite fortezza_null is not available in NSS
> 3.17.  Ignoring fortezza_null
> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
> +0100] - SSL alert: Cipher tls_rsa_export1024_with_rc4_56_sha is weak.  It
> is enabled since allowWeakCipher is "on" (default setting for the backward
> compatibility). We strongly recom

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

2014-11-07 Thread Martin Basti


On 07/11/14 13:52, Rob Verduijn wrote:

Hi all,

Either I was to worn out last night, or another update has happened.
This morning the directory server did start after the update.
local dns zones however where not available again after the update
ipa-ldap-updater did not help to fix it.

The are again only 7 DNS aci objects are still in the ds.( same as 
before when it failed )

I also noticed that there are also quite a lot lower case dns aci objects.

Rob



Hi,

do you have any errors in /var/log/ipaupgrade.log ?



2014-11-07 10:25 GMT+01:00 Martin Basti >:


Changed subject.
Rob CCed

On 07/11/14 09:52, Martin Basti wrote:

Forward message back to list


 Original Message 
Subject:Re: [Freeipa-users] dns stops working after upgrade
Date:   Thu, 6 Nov 2014 21:42:55 +0100
From:   Rob Verduijn 

To: Martin Basti  



Hi again,

I tried the update to 4.1.1
It didn't went well, actually it went worse than to 4.1.
Now the directory service went down and was no longer able to start.

Some part of the logs is below.
Besides the warnings about a weak cipher there was not much in
the journalctl.

It's getting late overhere, I'll dig into the logs tomorrow.

Rob

Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389
Directory Server TJAKO-THUIS
Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389
Directory Server TJAKO-THUIS..
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5
is weak. It is enabled since allowWeakCipher is "on" (default
setting for the backward compatibility). We strongly recommend to
set it to "off".  Please replace the value of allowWeakCipher
with "off" in the encryption config entry cn=encryption,cn=config
and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5
is weak. It is enabled since allowWeakCipher is "on" (default
setting for the backward compatibility). We strongly recommend to
set it to "off".  Please replace the value of allowWeakCipher
with "off" in the encryption config entry cn=encryption,cn=config
and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5
is weak. It is enabled since allowWeakCipher is "on" (default
setting for the backward compatibility). We strongly recommend to
set it to "off".  Please replace the value of allowWeakCipher
with "off" in the encryption config entry cn=encryption,cn=config
and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is
weak. It is enabled since allowWeakCipher is "on" (default
setting for the backward compatibility). We strongly recommend to
set it to "off".  Please replace the value of allowWeakCipher
with "off" in the encryption config entry cn=encryption,cn=config
and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha
is weak. It is enabled since allowWeakCipher is "on" (default
setting for the backward compatibility). We strongly recommend to
set it to "off".  Please replace the value of allowWeakCipher
with "off" in the encryption config entry cn=encryption,cn=config
and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is
weak. It is enabled since allowWeakCipher is "on" (default
setting for the backward compatibility). We strongly recommend to
set it to "off".  Please replace the value of allowWeakCipher
with "off" in the encryption config entry cn=encryption,cn=config
and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher
rsa_fips_3des_sha is weak. It is enabled since allowWeakCipher is
"on" (default setting for the backward compatibility). We
strongly recommend to set it to "off".  Please replace the value
of allowWeakCipher with "off" in the encryption config entry
cn=encryption,cn=config and restart the server.
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza
is not available in NSS 3.17.  Ignoring fortezza
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite
fortezza_rc4_128_sha is not available in NSS 3.17.  Ignoring
fortezza_rc4_128_sha
Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]:
[06/Nov/2014:21

[Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

2014-11-07 Thread Traiano Welcome

Hi List

I'm trying to configure a replica for a primary freeipa IdM server
(both CentOS 7, AD trusts configured on primary), but "ipa-replica-install"
fails with the following error:
--
 ipa-replica-install -d  --setup-ca --setup-dns --no-forwarders
/var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
.
.
Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
IP network address
.
.
--

For context, here is the full output from the replica-install command (I've
attached the full debug output):

---
[root@lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns
--no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
WARNING: conflicting time&date synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'lolpr-idm-mstr.idm.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@IDM.LOCAL password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'lolpr-idm-slve.idm.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
IP network address
[root@lolpr-idm-slve ipa]#

---

Some things I've tested:

1. disable  selinux (followed by reboot) - no change
2. disable IPv6 (followed by reboot) - no change

DNS resolution and IP checks seem fine:
---

[root@lolpr-idm-slve install]# hostname
lolpr-idm-slve.idm.local


[root@lolpr-idm-slve install]# ifconfig
ens192: flags=4163  mtu 1500
inet 172.16.100.222  netmask 255.255.255.255  broadcast
172.16.100.222
ether 00:50:56:9c:1e:60  txqueuelen 1000  (Ethernet)
RX packets 17964  bytes 1705674 (1.6 MiB)
RX errors 0  dropped 10  overruns 0  frame 0
TX packets 3772  bytes 595134 (581.1 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
--

/etc/hosts looks like this:

--
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
172.16.100.68   lolpr-idm-mstr.idm.locallolpr-idm-mstr
172.16.100.222  lolpr-idm-slve.idm.locallolpr-idm-slve
172.16.104.231  loltestdc001.loltestdc.com  loltestdc001
--

Host naming, forward and reverse resolution seems fine:

---
[root@lolpr-idm-slve install]#
[root@lolpr-idm-slve install]# host `hostname`
lolpr-idm-slve.idm.local has address 172.16.100.222
[root@lolpr-idm-slve install]#
[root@lolpr-idm-slve install]# host `hostname`^C
[root@lolpr-idm-slve install]# host `hostname`| cut -d " " -f  4| xargs
-Iname host name
222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local.
[root@lolpr-idm-slve install]#
---

I'd be thankful if anyone could shed a light on why this error is happening
and point me in the direction of a fix.

Kind Regards,
Traiano
ipa : DEBUGstdout=enabled

ipa : DEBUGstderr=
WARNING: conflicting time&date synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/bin/gpg-agent --batch --homedir 
/tmp/tmpIaHxbXipa/ipa-Ae8JB2/.gnupg --daemon /usr/bin/gpg --batch --homedir 
/tmp/tmpIaHxbXipa/ipa-Ae8JB2/.gnupg --passphrase-fd 0 --yes --no-tty -o 
/tmp/tmpIaHxbXipa/files.tar -d 
/var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
ipa : DEBUGProcess finished, return code=0
ipa : DEBUGStarting external process
ipa : DEBUGargs=tar xf /tmp/tmpIaHxbXipa/files.tar -C 
/tmp/tmpIaHxbXipa
ipa : DEBUGProcess finished, return code=0
ipa : DEBUGstdout=
ipa : DEBUGstderr=
ipa : DEBUGInstalling replica file with version 30303 (0 means no 
version in prepared file).
ipa : DEBUGCheck if lolpr-idm-slve.idm.local is a primary hostname 
for localhost
ipa : DEBUGPrimary hostname for localhost: lolpr-idm-slve.idm.local
ipa : DEBUGSearch DNS for lolpr-idm-slve.idm.local
ipa : DEBUGCheck if lolpr-idm-slve.idm.local is not a CNAME
ipa

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

2014-11-07 Thread Rob Verduijn

Hello,

Yes this time there are
This section :
2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential integrity
postoperation,cn=plugins,cn=config

2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc':
'Operations error'}
2014-11-07T13:10:03Z ERROR Update failed: Operations error:

and this one
2014-11-07T13:10:18Z INFO New entry: cn=ADTrust
Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis

2014-11-07T13:10:18Z ERROR Add failure

and this one: (but since I do not have AD it's kinda logical)
2014-11-07T13:10:18Z INFO New entry: cn=ADTrust
Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis

2014-11-07T13:10:19Z ERROR Upgrade failed with
2014-11-07T13:10:19Z DEBUG Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
line 152, in __upgrade
self.modified = (ld.update(self.files, ordered=True) or
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 874, in update
updates = api.Backend.updateclient.update(POST_UPDATE,
self.dm_password, self.ldapi, self.live_run)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py",
line 123, in update
(restart, apply_now, res) = self.run(update.name, **kw)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py",
line 146, in run
return self.Updater[method](**kw)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1399, in
__call__
return self.execute(**options)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py",
line 89, in execute
api.Command.dnszone_mod(zone[u'idnsname'][0], **update)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in
__call__
ret = self.run(*args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in
run
return self.execute(*args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2528,
in execute
result = super(dnszone_mod, self).execute(*keys, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line
1385, in execute
dn = self.obj.get_dn(*keys, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1784,
in get_dn
assert zone.is_absolute()
AssertionError

2014-11-07T13:10:23Z ERROR IPA upgrade failed.
2014-11-07T13:10:23Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py",
line 151, in run
raise admintool.ScriptError('IPA upgrade failed.', 1)

2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed, exception:
ScriptError: IPA upgrade failed.
2014-11-07T13:10:23Z ERROR IPA upgrade failed.
2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with
options: {'debug': False, 'quiet': True}
2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20


and another
2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential integrity
postoperation,cn=plugins,cn=config

2014-11-07T13:10:03Z DEBUG Live 1, updated 1
2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc':
'Operations error'}
2014-11-07T13:10:03Z ERROR Update failed: Operations error:

That's it
Rob




2014-11-07 13:56 GMT+01:00 Martin Basti :

>  On 07/11/14 13:52, Rob Verduijn wrote:
>
> Hi all,
>
>  Either I was to worn out last night, or another update has happened.
> This morning the directory server did start after the update.
> local dns zones however where not available again after the update
> ipa-ldap-updater did not help to fix it.
>
>  The are again only 7 DNS aci objects are still in the ds.( same as
> before when it failed )
> I also noticed that there are also quite a lot lower case dns aci objects.
>
>  Rob
>
>
>   Hi,
>
> do you have any errors in /var/log/ipaupgrade.log ?
>
>
>
> 2014-11-07 10:25 GMT+01:00 Martin Basti :
>
>>  Changed subject.
>> Rob CCed
>>
>> On 07/11/14 09:52, Martin Basti wrote:
>>
>> Forward message back to list
>>
>>
>>  Original Message   Subject: Re: [Freeipa-users] dns
>> stops working after upgrade  Date: Thu, 6 Nov 2014 21:42:55 +0100  From: Rob
>> VerduijnTo: Martin
>> Basti  
>>
>> Hi again,
>>
>>  I tried the update to 4.1.1
>> It didn't went well, actually it went worse than to 4.1.
>> Now the directory service went down and was no longer able to start.
>>
>>  Some part of the logs is below.
>> Besides the warnings about a weak cipher there was not much in the
>> journalctl.
>>
>>  It's getting late overhere, I'll dig into the logs tomorrow.
>>
>>  Rob
>>
>>  Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory
>> Server TJAKO-THUIS
>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory
>> Server TJAKO-THUIS..
>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58
>> +0100] - SSL alert: Cipher

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

2014-11-07 Thread Martin Basti


On 07/11/14 14:26, Rob Verduijn wrote:

Hello,

Yes this time there are
This section :
2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential 
integrity postoperation,cn=plugins,cn=config


2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: 
{'desc': 'Operations error'}

2014-11-07T13:10:03Z ERROR Update failed: Operations error:

and this one
2014-11-07T13:10:18Z INFO New entry: cn=ADTrust 
Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis


2014-11-07T13:10:18Z ERROR Add failure

Known issues


and this one: (but since I do not have AD it's kinda logical)
2014-11-07T13:10:18Z INFO New entry: cn=ADTrust 
Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis


2014-11-07T13:10:19Z ERROR Upgrade failed with
2014-11-07T13:10:19Z DEBUG Traceback (most recent call last):
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 152, in __upgrade

self.modified = (ld.update(self.files, ordered=True) or
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
line 874, in update
updates = api.Backend.updateclient.update(POST_UPDATE, 
self.dm_password, self.ldapi, self.live_run)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", 
line 123, in update
(restart, apply_now, res) = self.run(update.name 
, **kw)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", 
line 146, in run

return self.Updater[method](**kw)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 
1399, in __call__

return self.execute(**options)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", 
line 89, in execute

api.Command.dnszone_mod(zone[u'idnsname'][0], **update)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 
439, in __call__

ret = self.run(*args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 
754, in run

return self.execute(*args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 
2528, in execute

result = super(dnszone_mod, self).execute(*keys, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", 
line 1385, in execute

dn = self.obj.get_dn(*keys, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 
1784, in get_dn

assert zone.is_absolute()
AssertionError


This is the problem, it is new bug.

The workaround is replace the code in:
/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py:68
- zones = api.Command.dnszone_find(all=True)['result']
+ zones = api.Command.dnszone_find(all=True, raw=True)['result']

(I didn't test it)

and run ipa-ldap-updater --upgrade

Thank you for patience.




2014-11-07T13:10:23Z ERROR IPA upgrade failed.
2014-11-07T13:10:23Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, 
in execute

return_value = self.run()
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", 
line 151, in run

raise admintool.ScriptError('IPA upgrade failed.', 1)

2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed, 
exception: ScriptError: IPA upgrade failed.

2014-11-07T13:10:23Z ERROR IPA upgrade failed.
2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked 
with options: {'debug': False, 'quiet': True}

2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20


and another
2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential 
integrity postoperation,cn=plugins,cn=config


2014-11-07T13:10:03Z DEBUG Live 1, updated 1
2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: 
{'desc': 'Operations error'}

2014-11-07T13:10:03Z ERROR Update failed: Operations error:

That's it
Rob




2014-11-07 13:56 GMT+01:00 Martin Basti >:


On 07/11/14 13:52, Rob Verduijn wrote:

Hi all,

Either I was to worn out last night, or another update has happened.
This morning the directory server did start after the update.
local dns zones however where not available again after the update
ipa-ldap-updater did not help to fix it.

The are again only 7 DNS aci objects are still in the ds.( same
as before when it failed )
I also noticed that there are also quite a lot lower case dns aci
objects.

Rob



Hi,

do you have any errors in /var/log/ipaupgrade.log ?



2014-11-07 10:25 GMT+01:00 Martin Basti mailto:mba...@redhat.com>>:

Changed subject.
Rob CCed

On 07/11/14 09:52, Martin Basti wrote:

Forward message back to list


 Original Message 
Subject:Re: [Freeipa-users] dns stops working after upgrade
Date:   Thu, 6 Nov 2014 21:42:55 +0100
From:   Rob Verduijn 

To: Martin Basti 




Hi again,

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

2014-11-07 Thread Rob Verduijn

Yup that solved it.

Everything looks ok now :-)

Thank you for you great effort.
Rob

2014-11-07 14:55 GMT+01:00 Martin Basti :

>  On 07/11/14 14:26, Rob Verduijn wrote:
>
> Hello,
>
>  Yes this time there are
> This section :
>  2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential
> integrity postoperation,cn=plugins,cn=config
>  
>  2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR:
> {'desc': 'Operations error'}
> 2014-11-07T13:10:03Z ERROR Update failed: Operations error:
>
>  and this one
> 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust
> Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis
>  
> 2014-11-07T13:10:18Z ERROR Add failure
>
>  Known issues
>
>  and this one: (but since I do not have AD it's kinda logical)
> 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust
> Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis
>  
>  2014-11-07T13:10:19Z ERROR Upgrade failed with
> 2014-11-07T13:10:19Z DEBUG Traceback (most recent call last):
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
> line 152, in __upgrade
> self.modified = (ld.update(self.files, ordered=True) or
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
> line 874, in update
> updates = api.Backend.updateclient.update(POST_UPDATE,
> self.dm_password, self.ldapi, self.live_run)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py",
> line 123, in update
> (restart, apply_now, res) = self.run(update.name, **kw)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py",
> line 146, in run
> return self.Updater[method](**kw)
>   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1399,
> in __call__
> return self.execute(**options)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line
> 89, in execute
> api.Command.dnszone_mod(zone[u'idnsname'][0], **update)
>   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in
> __call__
> ret = self.run(*args, **options)
>   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in
> run
> return self.execute(*args, **options)
>   File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line
> 2528, in execute
> result = super(dnszone_mod, self).execute(*keys, **options)
>   File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line
> 1385, in execute
> dn = self.obj.get_dn(*keys, **options)
>   File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line
> 1784, in get_dn
> assert zone.is_absolute()
> AssertionError
>
>
> This is the problem, it is new bug.
>
> The workaround is replace the code in:
> /usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py:68
> - zones = api.Command.dnszone_find(all=True)['result']
> + zones = api.Command.dnszone_find(all=True, raw=True)['result']
>
> (I didn't test it)
>
> and run ipa-ldap-updater --upgrade
>
> Thank you for patience.
>
>
>
>  
>  2014-11-07T13:10:23Z ERROR IPA upgrade failed.
>  2014-11-07T13:10:23Z DEBUG   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> execute
> return_value = self.run()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py",
> line 151, in run
> raise admintool.ScriptError('IPA upgrade failed.', 1)
>
>  2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed,
> exception: ScriptError: IPA upgrade failed.
> 2014-11-07T13:10:23Z ERROR IPA upgrade failed.
> 2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with
> options: {'debug': False, 'quiet': True}
> 2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20
>
>
>  and another
> 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential
> integrity postoperation,cn=plugins,cn=config
>  
>  2014-11-07T13:10:03Z DEBUG Live 1, updated 1
> 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc':
> 'Operations error'}
> 2014-11-07T13:10:03Z ERROR Update failed: Operations error:
>
>  That's it
> Rob
>
>
>
>
> 2014-11-07 13:56 GMT+01:00 Martin Basti :
>
>>  On 07/11/14 13:52, Rob Verduijn wrote:
>>
>> Hi all,
>>
>>  Either I was to worn out last night, or another update has happened.
>> This morning the directory server did start after the update.
>> local dns zones however where not available again after the update
>> ipa-ldap-updater did not help to fix it.
>>
>>  The are again only 7 DNS aci objects are still in the ds.( same as
>> before when it failed )
>> I also noticed that there are also quite a lot lower case dns aci objects.
>>
>>  Rob
>>
>>
>>   Hi,
>>
>> do you have any errors in /var/log/ipaupgrade.log ?
>>
>>
>>
>> 2014-11-07 10:25 GMT+01:00 Martin Basti :
>>
>>>  Changed subject.
>>> Rob CCed
>>>
>>> On 07/11/14 09:52, Martin Basti wrote:
>>>
>>> Forward message back to list
>>>
>>>
>>>  Original Message   Subject: Re: [Freeipa-users] dns
>>> stop

Re: [Freeipa-users] Kerberos for cronjoob

2014-11-07 Thread Michael ORourke

What we do in our environment is create "service users" that are designated for certain tasks.   Say you need to run a rsync job every night, after the user is created, you will need to create a keytab.  Then copy the keytab file over to the box that the cronjob will run on.  Then at the top of the script (which is called from the cronjob), add something like this:/usr/kerberos/bin/kdestroy/usr/kerberos/bin/kinit -k -t /home/srv_rsync/srv_rsync.keytab srv_rsync@MYDOMAIN.LOCALAnd you can verify that you have a TGT by using the klist command.-Mike-Original Message-From: Thomas Lau Sent: Nov 6, 2014 8:20 PMTo: freeipa-users Subject: [Freeipa-users] Kerberos for cronjoob  ‎Hi, Is it possible to renew ticket once in a while for cronjob to run on certain users? How do you guys run cronjob on Kerberos user without getting ticket expire? Sent from my BlackBerry 10 smartphone.

-- 
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 bind also-notify behavior.

2014-11-07 Thread Petr Spacek

On 4.11.2014 16:57, Matthew Sellers wrote:
> Hi Guys,
> 
> Thanks for the previous replies.  I hate to dig up and old thread, but im
> still banging my head on this.  I am trying to configure IPA to send notify
> to slaves servers on manual updates from the web or CLI tools.
> 
> Dynamic DNS updates from an IPA client issuing an nsupdate works great, I
> get an immediate zone transfer to zone NS slaves ( bind 9.x slaves).
> 
> Performing an update via IPA CLI ( for non-dynamic static record)  tools
> triggers nothing.  The test documents and Petr's previous statements hold
> true for the nsupdate case, is this also true for CLI driven updates as
> well?
> 
> I have tested this on 3.3.5 (Fedora 20)  and 4.1 (COPR) release.

Congratulations! You have found a regression in bind-dyndb-ldap:
https://fedorahosted.org/bind-dyndb-ldap/ticket/144

I have sent patch to the devel list and it is waiting for review at the
moment. It should be fixed in nearest release of bind-dyndb-ldap.

Thank you very much for catching this!

Petr^2 Spacek

> On Wed, Sep 3, 2014 at 2:25 AM, Petr Spacek  wrote:
> 
>> On 1.9.2014 12:16, Dmitri Pal wrote:
>>
>>> On 09/01/2014 12:05 PM, Martin Kosek wrote:
>>>
 On 09/01/2014 07:50 AM, Dmitri Pal wrote:

> On 08/29/2014 09:32 PM, Matthew Sellers wrote:
>
>> Hi Everyone!
>>
>> I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure
>> FreeIPA to
>> send notifies to non-IPA slaves, but it seems broken on IPA ( notify
>> packets
>> are never sent to to slaves ).
>>
>> I have configured also-notify { nameserverip; };  in named.conf on my
>> FreeIPA
>> test host in the options section and watched for notify traffic with
>> tcpdump.
>>
>> This document suggests that this is supported, and this is something I
>> have
>> used in non-IPA bind servers with no issues.
>>
>> https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer
>>
>> I wanted to ask the list before I file a bug with more details.   Is
>> anyone
>> using this bind feature on IPA with any success?
>>
>> Thanks!
>> Matt
>>
>>
>>  The DNS level change propagation is not supported between IPA
> replicas instead
> it uses LDAP replication to propagate the changes.
> If you want another non IPA DNS server to be a slave then you can do
> it. See
> http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for
> more
> information.
>
 I thought that from F20, bind-dyndb-ldap was capable of native DNS
 operations
 like AXFR/IXFR which can be used to actually deploy slave DNS servers. I
 wonder
 if also-notify is something different. CCing Petr Spacek to advise.

>>> AFAIU slave DNS servers not controlled by IPA yes, replicas as slaves -
>>> no.
>>>
>>
>> Let me summarize:
>> - AXFR is supported (at least) by all versions RHEL 6.5 and newer versions
>> - IXFR is supported by bind-dyndb-ldap 4.0 and newer (Fedora 20+)
>> - DNS NOTIFY messages are always sent to servers listed in NS records
>>
>> I.e. you have to add your non-IPA slave servers to NS records in
>> particular zone and then it should 'just work', no other configuration
>> (like 'also-notify') is necessary.
>>
>> Please let me know if it doesn't work for you.

-- 
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] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

2014-11-07 Thread Petr Spacek

On 7.11.2014 14:08, Traiano Welcome wrote:
> Hi List
> 
> I'm trying to configure a replica for a primary freeipa IdM server
> (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install"
> fails with the following error:
> --
>  ipa-replica-install -d  --setup-ca --setup-dns --no-forwarders
> /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
> .
> .
> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
> IP network address
> .
> .
> --
> 
> For context, here is the full output from the replica-install command (I've
> attached the full debug output):
> 
> ---
> [root@lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns
> --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
> WARNING: conflicting time&date synchronization service 'chronyd' will
> be disabled in favor of ntpd
> 
> Directory Manager (existing master) password:
> 
> Run connection check to master
> Check connection from replica to remote master 'lolpr-idm-mstr.idm.local':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos Kpasswd: TCP (464): OK
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
> 
> The following list of ports use UDP protocol and would need to be
> checked manually:
>Kerberos KDC: UDP (88): SKIPPED
>Kerberos Kpasswd: UDP (464): SKIPPED
> 
> Connection from replica to master is OK.
> Start listening on required ports for remote master check
> Get credentials to log in to remote master
> admin@IDM.LOCAL password:
> 
> Check SSH connection to remote master
> Execute check on remote master
> Check connection from master to remote replica 'lolpr-idm-slve.idm.local':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos KDC: UDP (88): OK
>Kerberos Kpasswd: TCP (464): OK
>Kerberos Kpasswd: UDP (464): OK
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
> 
> Connection from master to replica is OK.
> 
> Connection check OK
> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
> IP network address
> [root@lolpr-idm-slve ipa]#
> 
> ---
> 
> Some things I've tested:
> 
> 1. disable  selinux (followed by reboot) - no change
> 2. disable IPv6 (followed by reboot) - no change
> 
> DNS resolution and IP checks seem fine:
> ---
> 
> [root@lolpr-idm-slve install]# hostname
> lolpr-idm-slve.idm.local
> 
> 
> [root@lolpr-idm-slve install]# ifconfig
> ens192: flags=4163  mtu 1500
> inet 172.16.100.222  netmask 255.255.255.255  broadcast
> 172.16.100.222

This is the cause: IP address on ens192 interface is 172.16.100.222/32.

What is your environment? Is it some kind of weird container?

Is it even valid configuration? :-) I don't recall any use case for 32-bit
netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point
to point links.

Petr^2 Spacek

> ether 00:50:56:9c:1e:60  txqueuelen 1000  (Ethernet)
> RX packets 17964  bytes 1705674 (1.6 MiB)
> RX errors 0  dropped 10  overruns 0  frame 0
> TX packets 3772  bytes 595134 (581.1 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> --
> 
> /etc/hosts looks like this:
> 
> --
> 127.0.0.1   localhost localhost.localdomain localhost4
> localhost4.localdomain4
> 172.16.100.68   lolpr-idm-mstr.idm.locallolpr-idm-mstr
> 172.16.100.222  lolpr-idm-slve.idm.locallolpr-idm-slve
> 172.16.104.231  loltestdc001.loltestdc.com  loltestdc001
> --
> 
> Host naming, forward and reverse resolution seems fine:
> 
> ---
> [root@lolpr-idm-slve install]#
> [root@lolpr-idm-slve install]# host `hostname`
> lolpr-idm-slve.idm.local has address 172.16.100.222
> [root@lolpr-idm-slve install]#
> [root@lolpr-idm-slve install]# host `hostname`^C
> [root@lolpr-idm-slve install]# host `hostname`| cut -d " " -f  4| xargs
> -Iname host name
> 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local.
> [root@lolpr-idm-slve install]#
> ---
> 
> I'd be thankful if anyone could shed a light on why this error is happening
> and point me in the direction of a fix.
> 
> Kind Regards,
> Traiano
> 
> 
> 


-- 
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

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

2014-11-07 Thread Martin Kosek


On 11/07/2014 03:05 PM, Rob Verduijn wrote:

Yup that solved it.

Everything looks ok now :-)

Thank you for you great effort.


Well, thank you for your patience. It will allow us to fix this bug in next 
FreeIPA release, the patch was already submitted on freeipa-devel.


Thanks again!
Martin


Rob

2014-11-07 14:55 GMT+01:00 Martin Basti mailto:mba...@redhat.com>>:

On 07/11/14 14:26, Rob Verduijn wrote:

Hello,

Yes this time there are
This section :
2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential
integrity postoperation,cn=plugins,cn=config

2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR:
{'desc': 'Operations error'}
2014-11-07T13:10:03Z ERROR Update failed: Operations error:

and this one
2014-11-07T13:10:18Z INFO New entry: cn=ADTrust
Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis

2014-11-07T13:10:18Z ERROR Add failure

Known issues


and this one: (but since I do not have AD it's kinda logical)
2014-11-07T13:10:18Z INFO New entry: cn=ADTrust
Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis

2014-11-07T13:10:19Z ERROR Upgrade failed with
2014-11-07T13:10:19Z DEBUG Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
line 152, in __upgrade
self.modified = (ld.update(self.files, ordered=True) or
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line
874, in update
updates = api.Backend.updateclient.update(POST_UPDATE,
self.dm_password, self.ldapi, self.live_run)
  File

"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py",
line 123, in update
(restart, apply_now, res) = self.run(update.name
, **kw)
  File

"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py",
line 146, in run
return self.Updater[method](**kw)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1399,
in __call__
return self.execute(**options)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line
89, in execute
api.Command.dnszone_mod(zone[u'idnsname'][0], **update)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439,
in __call__
ret = self.run(*args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754,
in run
return self.execute(*args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line
2528, in execute
result = super(dnszone_mod, self).execute(*keys, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py",
line 1385, in execute
dn = self.obj.get_dn(*keys, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line
1784, in get_dn
assert zone.is_absolute()
AssertionError


This is the problem, it is new bug.

The workaround is replace the code in:
/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py:68
- zones = api.Command.dnszone_find(all=True)['result']
+ zones = api.Command.dnszone_find(all=True, raw=True)['result']

(I didn't test it)

and run ipa-ldap-updater --upgrade

Thank you for patience.





2014-11-07T13:10:23Z ERROR IPA upgrade failed.
2014-11-07T13:10:23Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py",
line 151, in run
raise admintool.ScriptError('IPA upgrade failed.', 1)

2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed,
exception: ScriptError: IPA upgrade failed.
2014-11-07T13:10:23Z ERROR IPA upgrade failed.
2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with
options: {'debug': False, 'quiet': True}
2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20


and another
2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential
integrity postoperation,cn=plugins,cn=config

2014-11-07T13:10:03Z DEBUG Live 1, updated 1
2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR:
{'desc': 'Operations error'}
2014-11-07T13:10:03Z ERROR Update failed: Operations error:

That's it
Rob




2014-11-07 13:56 GMT+01:00 Martin Basti mailto:mba...@redhat.com>>:

On 07/11/14 13:52, Rob Verduijn wrote:

Hi all,

Either I was to worn out last night, or another update has happened.
This morning the directory server did start after the update.
local dns zones however where not available again after the update
ipa-ldap-updater did not help to fix it.

The are again only 7 DNS aci objects are st

Re: [Freeipa-users] unable to sudo

2014-11-07 Thread Craig White

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
Sent: Friday, November 07, 2014 2:32 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] unable to sudo

On Thu, Nov 06, 2014 at 07:27:04PM +, Craig White wrote:
> -Original Message-
> From: Lukas Slebodnik [mailto:lsleb...@redhat.com] 
> Sent: Thursday, November 06, 2014 9:34 AM
> To: Craig White
> Cc: t...@tetrioncapital.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] unable to sudo
> 
> On (06/11/14 15:42), Craig White wrote:
> >As Bob pointed out in a direct e-mail to me, there was the detail of adding 
> >sudo and sss to /etc/nsswitch.conf but – once I did so, it pointed out that 
> >the Rackspace RHEL packaging that doesn’t provide what I need – possibly 
> >need from epel.
> >
> 
> ># yum search /usr/lib64/libsss_sudo.so
> This file was in separate package in sssd 1.9. The packaging was changed in 
> sssd >= 1.10 and it is installed by default (part of package sssd-common) and 
> rhel/CentOS 6.6 contains sssd 1.11.6
> 
> Unfortunately for me, Rackspace still has these boxes on RHEL 6.5
> 
> # rpm -qa | grep sssd
> sssd-client-1.9.2-129.el6_5.4.x86_64
> sssd-1.9.2-129.el6_5.4.x86_64
> 
> nowhere to go I think - thanks

I find it odd that they'd only give you half of the packages.

Anyway, can you grab libsss_sudo RPMs from CentOS ?

Odd is a nice way of phrasing it.

The thing is that these 2 servers are managed by Rackspace - hence the 
different repos.

It may come down to installing epel or different repos or just waiting around 
to see what is packaged when they finally move to RHEL 6.6 and taking these 
boxes over from Rackspace management but that is not a decision made by someone 
in my pay grade  ;-)

Thanks

Craig

-- 
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] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

2014-11-07 Thread Traiano Welcome

Hi Petr



On Fri, Nov 7, 2014 at 6:19 PM, Petr Spacek  wrote:
> On 7.11.2014 14:08, Traiano Welcome wrote:
>> Hi List
>>
>> I'm trying to configure a replica for a primary freeipa IdM server
>> (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install"
>> fails with the following error:
>> --
>>  ipa-replica-install -d  --setup-ca --setup-dns --no-forwarders
>> /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
>> .
>> .
>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
>> IP network address
>> .
>> .
>> --
>>
>> For context, here is the full output from the replica-install command (I've
>> attached the full debug output):
>>
>> ---
>> [root@lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns
>> --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
>> WARNING: conflicting time&date synchronization service 'chronyd' will
>> be disabled in favor of ntpd
>>
>> Directory Manager (existing master) password:
>>
>> Run connection check to master
>> Check connection from replica to remote master 'lolpr-idm-mstr.idm.local':
>>Directory Service: Unsecure port (389): OK
>>Directory Service: Secure port (636): OK
>>Kerberos KDC: TCP (88): OK
>>Kerberos Kpasswd: TCP (464): OK
>>HTTP Server: Unsecure port (80): OK
>>HTTP Server: Secure port (443): OK
>>
>> The following list of ports use UDP protocol and would need to be
>> checked manually:
>>Kerberos KDC: UDP (88): SKIPPED
>>Kerberos Kpasswd: UDP (464): SKIPPED
>>
>> Connection from replica to master is OK.
>> Start listening on required ports for remote master check
>> Get credentials to log in to remote master
>> admin@IDM.LOCAL password:
>>
>> Check SSH connection to remote master
>> Execute check on remote master
>> Check connection from master to remote replica 'lolpr-idm-slve.idm.local':
>>Directory Service: Unsecure port (389): OK
>>Directory Service: Secure port (636): OK
>>Kerberos KDC: TCP (88): OK
>>Kerberos KDC: UDP (88): OK
>>Kerberos Kpasswd: TCP (464): OK
>>Kerberos Kpasswd: UDP (464): OK
>>HTTP Server: Unsecure port (80): OK
>>HTTP Server: Secure port (443): OK
>>
>> Connection from master to replica is OK.
>>
>> Connection check OK
>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
>> IP network address
>> [root@lolpr-idm-slve ipa]#
>>
>> ---
>>
>> Some things I've tested:
>>
>> 1. disable  selinux (followed by reboot) - no change
>> 2. disable IPv6 (followed by reboot) - no change
>>
>> DNS resolution and IP checks seem fine:
>> ---
>>
>> [root@lolpr-idm-slve install]# hostname
>> lolpr-idm-slve.idm.local
>>
>>
>> [root@lolpr-idm-slve install]# ifconfig
>> ens192: flags=4163  mtu 1500
>> inet 172.16.100.222  netmask 255.255.255.255  broadcast
>> 172.16.100.222
>
> This is the cause: IP address on ens192 interface is 172.16.100.222/32.
>
> What is your environment? Is it some kind of weird container?
>
> Is it even valid configuration? :-) I don't recall any use case for 32-bit
> netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point
> to point links.
>


AFAIK, a /32 netmask designates a single address. Should be valid,
although I'm not sure how IPA's installutils.py handles that. ipcalc
says:


root@lol-dev:/opt/automation# ipcalc 172.16.100.222/32
Address:   172.16.100.222   10101100.0001.01100100.1100
Netmask:   255.255.255.255 = 32 ...
Wildcard:  0.0.0.0  ...
=>
Hostroute: 172.16.100.222   10101100.0001.01100100.1100
Hosts/Net: 1 Class B, Private Internet


Nice reference, seems to confirm this is a single host:
http://www.oav.net/mirrors/cidr.html






> Petr^2 Spacek
>
>> ether 00:50:56:9c:1e:60  txqueuelen 1000  (Ethernet)
>> RX packets 17964  bytes 1705674 (1.6 MiB)
>> RX errors 0  dropped 10  overruns 0  frame 0
>> TX packets 3772  bytes 595134 (581.1 KiB)
>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>> --
>>
>> /etc/hosts looks like this:
>>
>> --
>> 127.0.0.1   localhost localhost.localdomain localhost4
>> localhost4.localdomain4
>> 172.16.100.68   lolpr-idm-mstr.idm.locallolpr-idm-mstr
>> 172.16.100.222  lolpr-idm-slve.idm.locallolpr-idm-slve
>> 172.16.104.231  loltestdc001.loltestdc.com  loltestdc001
>> --
>>
>> Host naming, forward and reverse resolution seems fine:
>>
>> ---
>> [root@lolpr-idm-slve install]#
>> [root@lolpr-idm-slve install]# host `hostname`
>> lolpr-idm-slve.idm.local has address 172.16.100.222
>> [root@lolpr-idm-slve install]#
>> [root@lolpr-idm-slve install]# host `hostname`^C
>> [root@lolpr-idm-slve install]# host `hostname`| cut -d " " -f  4| xargs
>> -Iname host name
>> 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local.
>> [root@lolpr-idm-slve install]#
>> ---
>>
>> I'd be thankful if anyone

Re: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

2014-11-07 Thread Petr Spacek

On 7.11.2014 17:20, Traiano Welcome wrote:
> Hi Petr
> 
> 
> 
> On Fri, Nov 7, 2014 at 6:19 PM, Petr Spacek  wrote:
>> On 7.11.2014 14:08, Traiano Welcome wrote:
>>> Hi List
>>>
>>> I'm trying to configure a replica for a primary freeipa IdM server
>>> (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install"
>>> fails with the following error:
>>> --
>>>  ipa-replica-install -d  --setup-ca --setup-dns --no-forwarders
>>> /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
>>> .
>>> .
>>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
>>> IP network address
>>> .
>>> .
>>> --
>>>
>>> For context, here is the full output from the replica-install command (I've
>>> attached the full debug output):
>>>
>>> ---
>>> [root@lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns
>>> --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
>>> WARNING: conflicting time&date synchronization service 'chronyd' will
>>> be disabled in favor of ntpd
>>>
>>> Directory Manager (existing master) password:
>>>
>>> Run connection check to master
>>> Check connection from replica to remote master 'lolpr-idm-mstr.idm.local':
>>>Directory Service: Unsecure port (389): OK
>>>Directory Service: Secure port (636): OK
>>>Kerberos KDC: TCP (88): OK
>>>Kerberos Kpasswd: TCP (464): OK
>>>HTTP Server: Unsecure port (80): OK
>>>HTTP Server: Secure port (443): OK
>>>
>>> The following list of ports use UDP protocol and would need to be
>>> checked manually:
>>>Kerberos KDC: UDP (88): SKIPPED
>>>Kerberos Kpasswd: UDP (464): SKIPPED
>>>
>>> Connection from replica to master is OK.
>>> Start listening on required ports for remote master check
>>> Get credentials to log in to remote master
>>> admin@IDM.LOCAL password:
>>>
>>> Check SSH connection to remote master
>>> Execute check on remote master
>>> Check connection from master to remote replica 'lolpr-idm-slve.idm.local':
>>>Directory Service: Unsecure port (389): OK
>>>Directory Service: Secure port (636): OK
>>>Kerberos KDC: TCP (88): OK
>>>Kerberos KDC: UDP (88): OK
>>>Kerberos Kpasswd: TCP (464): OK
>>>Kerberos Kpasswd: UDP (464): OK
>>>HTTP Server: Unsecure port (80): OK
>>>HTTP Server: Secure port (443): OK
>>>
>>> Connection from master to replica is OK.
>>>
>>> Connection check OK
>>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
>>> IP network address
>>> [root@lolpr-idm-slve ipa]#
>>>
>>> ---
>>>
>>> Some things I've tested:
>>>
>>> 1. disable  selinux (followed by reboot) - no change
>>> 2. disable IPv6 (followed by reboot) - no change
>>>
>>> DNS resolution and IP checks seem fine:
>>> ---
>>>
>>> [root@lolpr-idm-slve install]# hostname
>>> lolpr-idm-slve.idm.local
>>>
>>>
>>> [root@lolpr-idm-slve install]# ifconfig
>>> ens192: flags=4163  mtu 1500
>>> inet 172.16.100.222  netmask 255.255.255.255  broadcast
>>> 172.16.100.222
>>
>> This is the cause: IP address on ens192 interface is 172.16.100.222/32.
>>
>> What is your environment? Is it some kind of weird container?
>>
>> Is it even valid configuration? :-) I don't recall any use case for 32-bit
>> netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point
>> to point links.
>>
> 
> 
> AFAIK, a /32 netmask designates a single address. Should be valid,
> although I'm not sure how IPA's installutils.py handles that. ipcalc
> says:
> 
> 
> root@lol-dev:/opt/automation# ipcalc 172.16.100.222/32
> Address:   172.16.100.222   10101100.0001.01100100.1100
> Netmask:   255.255.255.255 = 32 ...
> Wildcard:  0.0.0.0  ...
> =>
> Hostroute: 172.16.100.222   10101100.0001.01100100.1100
> Hosts/Net: 1 Class B, Private Internet
> 
> 
> Nice reference, seems to confirm this is a single host:
> http://www.oav.net/mirrors/cidr.html

Sure, but how you can communicate using this address? You need to assign an
address to the other end too :-)

It is still unclear to me what is your use case.

Petr^2 Spacek

>>
>>> ether 00:50:56:9c:1e:60  txqueuelen 1000  (Ethernet)
>>> RX packets 17964  bytes 1705674 (1.6 MiB)
>>> RX errors 0  dropped 10  overruns 0  frame 0
>>> TX packets 3772  bytes 595134 (581.1 KiB)
>>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>> --
>>>
>>> /etc/hosts looks like this:
>>>
>>> --
>>> 127.0.0.1   localhost localhost.localdomain localhost4
>>> localhost4.localdomain4
>>> 172.16.100.68   lolpr-idm-mstr.idm.locallolpr-idm-mstr
>>> 172.16.100.222  lolpr-idm-slve.idm.locallolpr-idm-slve
>>> 172.16.104.231  loltestdc001.loltestdc.com  loltestdc001
>>> --
>>>
>>> Host naming, forward and reverse resolution seems fine:
>>>
>>> ---
>>> [root@lolpr-idm-slve install]#
>>> [root@lolpr-idm-slve install]# host `hostname`
>>> lolpr-idm-slve.idm.loca

Re: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

2014-11-07 Thread Traiano Welcome

On Fri, Nov 7, 2014 at 7:22 PM, Petr Spacek  wrote:
> On 7.11.2014 17:20, Traiano Welcome wrote:
>> Hi Petr
>>
>>
>>
>> On Fri, Nov 7, 2014 at 6:19 PM, Petr Spacek  wrote:
>>> On 7.11.2014 14:08, Traiano Welcome wrote:
 Hi List

 I'm trying to configure a replica for a primary freeipa IdM server
 (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install"
 fails with the following error:
 --
  ipa-replica-install -d  --setup-ca --setup-dns --no-forwarders
 /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
 .
 .
 Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
 IP network address
 .
 .
 --

 For context, here is the full output from the replica-install command (I've
 attached the full debug output):

 ---
 [root@lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns
 --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg
 WARNING: conflicting time&date synchronization service 'chronyd' will
 be disabled in favor of ntpd

 Directory Manager (existing master) password:

 Run connection check to master
 Check connection from replica to remote master 'lolpr-idm-mstr.idm.local':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos Kpasswd: TCP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK

 The following list of ports use UDP protocol and would need to be
 checked manually:
Kerberos KDC: UDP (88): SKIPPED
Kerberos Kpasswd: UDP (464): SKIPPED

 Connection from replica to master is OK.
 Start listening on required ports for remote master check
 Get credentials to log in to remote master
 admin@IDM.LOCAL password:

 Check SSH connection to remote master
 Execute check on remote master
 Check connection from master to remote replica 'lolpr-idm-slve.idm.local':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos KDC: UDP (88): OK
Kerberos Kpasswd: TCP (464): OK
Kerberos Kpasswd: UDP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK

 Connection from master to replica is OK.

 Connection check OK
 Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use
 IP network address
 [root@lolpr-idm-slve ipa]#

 ---

 Some things I've tested:

 1. disable  selinux (followed by reboot) - no change
 2. disable IPv6 (followed by reboot) - no change

 DNS resolution and IP checks seem fine:
 ---

 [root@lolpr-idm-slve install]# hostname
 lolpr-idm-slve.idm.local


 [root@lolpr-idm-slve install]# ifconfig
 ens192: flags=4163  mtu 1500
 inet 172.16.100.222  netmask 255.255.255.255  broadcast
 172.16.100.222
>>>
>>> This is the cause: IP address on ens192 interface is 172.16.100.222/32.
>>>
>>> What is your environment? Is it some kind of weird container?
>>>
>>> Is it even valid configuration? :-) I don't recall any use case for 32-bit
>>> netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for 
>>> point
>>> to point links.
>>>
>>
>>
>> AFAIK, a /32 netmask designates a single address. Should be valid,
>> although I'm not sure how IPA's installutils.py handles that. ipcalc
>> says:
>>
>> 
>> root@lol-dev:/opt/automation# ipcalc 172.16.100.222/32
>> Address:   172.16.100.222   10101100.0001.01100100.1100
>> Netmask:   255.255.255.255 = 32 ...
>> Wildcard:  0.0.0.0  ...
>> =>
>> Hostroute: 172.16.100.222   10101100.0001.01100100.1100
>> Hosts/Net: 1 Class B, Private Internet
>> 
>>
>> Nice reference, seems to confirm this is a single host:
>> http://www.oav.net/mirrors/cidr.html
>
> Sure, but how you can communicate using this address? You need to assign an
> address to the other end too :-)

Doh! Thanks a ton, Petr. Time for me to lay off the coffee :-)

>
> It is still unclear to me what is your use case.
>

Simply to have a replica IdM server for clients to failover to should
the primary IdM server be unreachable. Which is working wonderfully
now ...



> Petr^2 Spacek
>
>>>
 ether 00:50:56:9c:1e:60  txqueuelen 1000  (Ethernet)
 RX packets 17964  bytes 1705674 (1.6 MiB)
 RX errors 0  dropped 10  overruns 0  frame 0
 TX packets 3772  bytes 595134 (581.1 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 --

 /etc/hosts looks like this:

 --
 127.0.0.1   localhost localhost.localdomain localhost4
 localhost4.

Re: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade

2014-11-07 Thread Dmitri Pal


On 11/07/2014 01:24 AM, Will Sheldon wrote:
On November 6, 2014 at 10:07:54 PM, Dmitri Pal (d...@redhat.com 
) wrote:

On 11/07/2014 12:18 AM, Will Sheldon wrote:


Hello all :)

On the whole we are loving FreeIPA, Many thanks and much respect to 
all involved, we’ve had a great 12-18 months hassle free use out of 
it  - it is a fantastically stable trouble free solution… however 
now we’ve run into a small issue we (as mere mortals) are finding it 
hard to resolve :-/


We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything 
seems to go well, but one server is behaving oddly. It’s likely not 
an IPA issue, it also reset it’s hostname somehow after the upgrade 
(it’s an image in an openstack environment)


If anyone has any pointers as to how to debug I’d be hugely 
appreciative :)


Two servers, server1.domain.com and server2.domain.com

Server1 can’t push data to server2, there are updates and new 
records on server1 that do not exist on server2.



from the logs on server1:

[07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - 
agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to 
send endReplication extended operation (Can't contact LDAP server)
[07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - 
agmt="cn=meToserver2.domain.com" (server2:389): Replication bind 
with GSSAPI auth resumed
[07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - 
agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to 
replicate schema: rc=2
[07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - 
agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to 
replay change (uniqueid (null), CSN (null)): Can't contact LDAP 
server(-1). Will retry later.


Try to see
a) Server 1 properly resolves server 2
b) You can connect from server 1 to server 2 using ldapsearch
c) your firewall has proper ports open
d) dirserver on server 2 is actually running


All seems working:

[root@server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base 
-b '' namingContexts


Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y 
switch?


Did you find anything in the server2 logs?


# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=domain,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@server1 ~]#

And:

[root@server2 ~]# /etc/init.d/dirsrv status
dirsrv DOMAIN-COM (pid 1009) is running...
dirsrv PKI-IPA (pid 1083) is running...
[root@server2 ~]#






Check logs on server 2 to see whether it actually sees an attempt to 
connect, I suspect not, so it is most likely a DNS/FW issue or dir 
server is not running on 2.



and the servers:

[root@server1 ~]# ipa-replica-manage list -v `hostname`
Directory Manager password:

server2.domain.com: replica
last init status: None
last init ended: None
last update status: 0 Replica acquired successfully: Incremental 
update started

last update ended: 2014-11-07 01:35:58+00:00
[root@server1 ~]#



[root@server2 ~]# ipa-replica-manage list -v `hostname`
Directory Manager password:

server1.domain.com: replica
last init status: None
last init ended: None
last update status: 0 Replica acquired successfully: Incremental 
update succeeded

last update ended: 2014-11-07 01:35:43+00:00
[root@server2 ~]#




Will Sheldon






--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
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



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-- 
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] DNS and $GENERATE Directive

2014-11-07 Thread Andrew Powell

Is there a way to add a Bind $GENERATE directive line to FreeIPA to 
automatically name DHCP-assigned ranges?


In a file-based Bind installation, I can have the following line in the 
forward example.com zone file:


$generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$

(which adds records wd080.example.com thru wd250.example.com)

And for the reverse zone (0.168.192.in-addr.arpa) I can have the 
following line:


$generate 80-250/1 $ PTR wd${0,3,d}.example.com.

I can do without naming the DHCP-assigned ranges, but it seems like the 
proper thing to do.


--
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] tuning for DS?

2014-11-07 Thread Janelle


hi all..

As we head into  the weekend, I hope you all take time to play and 
enjoy.  At the same time, if you are online and have any ideas - are 
there any good tuning suggestions for beefing up 389ds for an 
environment with approx 4000 users and approx 1000 hosts?


My guess is the cache needs work for the number of users, so that is 
where I am looking. Any ideas?


~J

--
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] tuning for DS?

2014-11-07 Thread Dmitri Pal


On 11/07/2014 06:29 PM, Janelle wrote:

hi all..

As we head into  the weekend, I hope you all take time to play and 
enjoy.  At the same time, if you are online and have any ideas - are 
there any good tuning suggestions for beefing up 389ds for an 
environment with approx 4000 users and approx 1000 hosts?


My guess is the cache needs work for the number of users, so that is 
where I am looking. Any ideas?


~J


http://www.port389.org/docs/389ds/FAQ/performance-tuning.html#linux

I would start there.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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 unresponsive - Causes DOS situations

Re: [Freeipa-users] Kerberos for cronjoob

[Freeipa-users] Fwd: Re: dns stops working after upgrade

Re: [Freeipa-users] Kerberos for cronjoob

Re: [Freeipa-users] Kerberos for cronjoob

Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6

Re: [Freeipa-users] DS failed after upgrade

Re: [Freeipa-users] unable to sudo

Re: [Freeipa-users] mastercrl.bin very old

Re: [Freeipa-users] ATTN: CVE-2014-7828

Re: [Freeipa-users] mastercrl.bin very old

Re: [Freeipa-users] DS failed after upgrade

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

[Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

Re: [Freeipa-users] Kerberos for cronjoob

Re: [Freeipa-users] FreeIPA bind also-notify behavior.

Re: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

Re: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade)

Re: [Freeipa-users] unable to sudo

Re: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

Re: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

Re: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address

Re: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade

[Freeipa-users] DNS and $GENERATE Directive

[Freeipa-users] tuning for DS?

Re: [Freeipa-users] tuning for DS?

29 matches

Site Navigation

Mail list logo

Footer information