Re: [Freeipa-users] Questions about 1.14 software bugs

[Sullivan, Daniel [AAA]]

Lukas,

Thank you for responding.  This particular issue was the one that was 
preventing us from using sssd 1.13 on RHEL 6.8.

https://www.redhat.com/archives/freeipa-users/2016-July/msg00163.html

Basically no matter what I did HBAC seemed to randomly break on some systems. 
The systems were deployed from the same template, and from what I could tell 
had consistent configurations, all packages updated,  etc.  I honestly probably 
spent a week on this and upgrading to 1.14 was a very last resort.  It 
immediately fixed the problem in all cases.

We will discuss 1.14.1 internally and would be happy to provide any feedback on 
identified issues.

Dan



> On Aug 25, 2016, at 3:27 PM, Lukas Slebodnik  wrote:
> 
> On (25/08/16 18:30), Sullivan, Daniel [AAA] wrote:
>> Hi, 
>> 
>> I feel like I’ve been warned at least twice that sssd 1.14 has some known 
>> regressions that make it unstable.  We’re in the process of rolling it out 
>> to our production environment (we can’t use 1.13 due to another issue); so 
>> far it seems pretty stable, although if possible I’d like any sort of highly 
>> informed advisement if it is really stupid or insane to move forward with 
>> 1.14.  Specifically, we are implementing 1.14.0-3.el6.
>> 
> May I know what is a blocker for using default version of sssd(1.13) in el6?
> It is a stable version ready for production.
> 
>> Similarly, is it safe to say that this is a comprehensive list of known 
>> issues or are there identified problems that aren’t documented in this 
>> report?
>> 
>> https://fedorahosted.org/sssd/report/2
>> 
> https://fedorahosted.org/sssd/report/3 would be better
> and look directly into the bucket "SSSD 1.14.2"
> 
>> Any advise or recommendation that an expert in sssd 1.14 could provide would 
>> be appreciated (as I said before so far it seems pretty stable).
>> 
> We fixed many bugs in 1.14.1 and copr repository was updated
> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
> I would say it si 99% ready for production.
> 
> We will appreciate testing. And in case of any bugs, I can release
> new version in copr immediately after fixing bug in upstream.
> 
> LS



This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


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

Re: [Freeipa-users] (no subject)

[Iain M Conochie]

On 24/08/16 18:08, Sean Hogan wrote:


Hi All,

Would anyone be able to direct me to some docs regarding NFS automount 
with IPA. We are currently using this setup but to be specific I do 
not want the priv keys to be in the users mounted home. When I did the 
keygen I took the defaults for location and it went into the exported 
home of the user meaning it is mounted on any system the user logs 
onto which is not a good idea. Is there a way to set this up so the 
priv keys stay out of the mounted home or since I have the keys 
uploaded into IPA I do not need the key in home?



The key that is uploaded into IPA is the public key, not the private key.

You still need a private key on the local server the user is logging into.

Cheers

Iain






Sean Hogan







-- 
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] Cleaning Up an Unholy Mess

[Mark Reynolds]

On 08/25/2016 02:04 PM, Ian Harding wrote:
>
> On 08/25/2016 10:41 AM, Rob Crittenden wrote:
>> Ian Harding wrote:
>>>
>>> On 08/24/2016 06:33 PM, Rob Crittenden wrote:
 Ian Harding wrote:
> I tried to simply uninstall and reinstall freeipa-dal and this
> happened.
>
> It only had a replication agreement with freeipa-sea
>
> [root@freeipa-dal ianh]# ipa-server-install --uninstall
>
> This is a NON REVERSIBLE operation and will delete all data and
> configuration!
>
> Are you sure you want to continue with the uninstall procedure?
> [no]: yes
> Shutting down all IPA services
> Removing IPA client configuration
> Unconfiguring ntpd
> Configuring certmonger to stop tracking system certificates for KRA
> Configuring certmonger to stop tracking system certificates for CA
> Unconfiguring CA
> Unconfiguring named
> Unconfiguring ipa-dnskeysyncd
> Unconfiguring web server
> Unconfiguring krb5kdc
> Unconfiguring kadmin
> Unconfiguring directory server
> Unconfiguring ipa_memcached
> Unconfiguring ipa-otpd
> [root@freeipa-dal ianh]# ipa-server-install --uninstall
>
> This is a NON REVERSIBLE operation and will delete all data and
> configuration!
>
> Are you sure you want to continue with the uninstall procedure?
> [no]: yes
>
> WARNING: Failed to connect to Directory Server to find information
> about
> replication agreements. Uninstallation will continue despite the
> possible
> existing replication agreements.
> Shutting down all IPA services
> Removing IPA client configuration
> Configuring certmonger to stop tracking system certificates for KRA
> Configuring certmonger to stop tracking system certificates for CA
> [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
> --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
> Directory Manager (existing master) password:
>
> The host freeipa-dal.bpt.rocks already exists on the master server.
> You should remove it before proceeding:
>   % ipa host-del freeipa-dal.bpt.rocks
> [root@freeipa-dal ianh]#
>
> So I tried to delete it again with --force
>
> [root@freeipa-sea ianh]# ipa-replica-manage --force del
> freeipa-dal.bpt.rocks
> Directory Manager password:
>
> 'freeipa-sea.bpt.rocks' has no replication agreement for
> 'freeipa-dal.bpt.rocks'
> [root@freeipa-sea ianh]#
>
> Can't delete it from the master server either
>
> [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
> disabled
>
>
> Now what?  I'm running out of things that work.
 Not sure what version of IPA you have but try:

 # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks

 If this had a CA on it then you'll want to ensure that any replication
 agreements it had have been removed as well.

 rob

>>> It turns out I'm not smart enough to untangle this mess.
>>>
>>> Is there any way to kind of start over?  I managed to delete and
>>> recreate a couple replicas but the problems (obsolete ruv as far as I
>>> can tell) carry on with the new replicas.  They won't even replicate
>>> back to the master they were created from.
>> Once you have the right version of 389-ds then then cleanruv tasks work
>> a lot better. What version are you running now?
> 1.3.4.0. 
Ian,

Can you the exact version please?  rpm -qa | grep 389-ds-base

Thanks,
Mark
>  It's handcuffed to my CentOS 7 so I don't want to update it
> outside the CentOS ecosystem.  What's the downside of upgrading it from
> source or an RPM for a different flavor of RedHat derived Linux?
>
> I'm a one-man band but I'd be interested in hearing a pitch from someone
> who is super smart on this stuff for a working consulting gig and maybe
> ongoing support.  Who would I talk to at RedHat about coming in from the
> cold for full on corporate support?
>
> Thanks!
>
>>> Basically, is there a way to do a fresh install of FreeIPA server, and
>>> do a dump/restore of data from my existing messed up install?
>> Not really, no. You can migrate IPA to IPA but only users and groups and
>> you lose private groups for existing users (they become regular POSIX
>> groups).
>>
>> rob
>>

-- 
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] Questions about 1.14 software bugs

[Sullivan, Daniel [AAA]]

Jakub,

Thank you for responding.  We’ll have to talk about upgrading to 1.14.1 
internally.  I appreciate your time, this is the sort of information I was 
looking for. 

Best,

Dan
  
> On Aug 25, 2016, at 3:39 PM, Jakub Hrozek  wrote:
> 
> On Thu, Aug 25, 2016 at 06:30:22PM +, Sullivan, Daniel [AAA] wrote:
>> Hi, 
>> 
>> I feel like I’ve been warned at least twice that sssd 1.14 has some known 
>> regressions that make it unstable.  We’re in the process of rolling it out 
>> to our production environment (we can’t use 1.13 due to another issue); so 
>> far it seems pretty stable, although if possible I’d like any sort of highly 
>> informed advisement if it is really stupid or insane to move forward with 
>> 1.14.  Specifically, we are implementing 1.14.0-3.el6.
>> 
> 
> It's gotten better in the last couple of weeks :)
> 
>> Similarly, is it safe to say that this is a comprehensive list of known 
>> issues or are there identified problems that aren’t documented in this 
>> report?
>> 
>> https://fedorahosted.org/sssd/report/2
> 
> In upstream we don't tag regressions vs. other bugs in any other way
> than tagging the regressions as 'critical' or 'blocker' in trac.
> 
> Since you are rolling out 1.14 on el6, you're already on your own I
> guess, so you might as well choose to run 1.14.1 which was released
> quite recently.
> 
> The most notable known bug you might be interested in since you are running
> IPA-AD trusts is:
>https://fedorahosted.org/sssd/ticket/3127
> 
> -- 
> 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



This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


-- 
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] SUDO and group lookup in AD trust

[Lukas Slebodnik]

On (25/08/16 11:30), Troels Hansen wrote:
>Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>getting a version 1.14.1, clean cache DB (complaing about cache being
>old version),
Upgrade to 1.14.1 should not require puring sssd cache.
If you are able to reproduce then please provide steps.
Or file a sssd bug https://fedorahosted.org/sssd/newticket

>I can getent users, but log log in for no obvious reason (system error in 
>secure.log).
>
system error sounds bad. Please provide log files with
high debug level in domain section sssd.conf

https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs

LS

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

Re: [Freeipa-users] Questions about 1.14 software bugs

[Jakub Hrozek]

On Thu, Aug 25, 2016 at 06:30:22PM +, Sullivan, Daniel [AAA] wrote:
> Hi, 
> 
> I feel like I’ve been warned at least twice that sssd 1.14 has some known 
> regressions that make it unstable.  We’re in the process of rolling it out to 
> our production environment (we can’t use 1.13 due to another issue); so far 
> it seems pretty stable, although if possible I’d like any sort of highly 
> informed advisement if it is really stupid or insane to move forward with 
> 1.14.  Specifically, we are implementing 1.14.0-3.el6.
> 

It's gotten better in the last couple of weeks :)

> Similarly, is it safe to say that this is a comprehensive list of known 
> issues or are there identified problems that aren’t documented in this report?
> 
> https://fedorahosted.org/sssd/report/2

In upstream we don't tag regressions vs. other bugs in any other way
than tagging the regressions as 'critical' or 'blocker' in trac.

Since you are rolling out 1.14 on el6, you're already on your own I
guess, so you might as well choose to run 1.14.1 which was released
quite recently.

The most notable known bug you might be interested in since you are running
IPA-AD trusts is:
https://fedorahosted.org/sssd/ticket/3127

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

Re: [Freeipa-users] Slow logins with multi site replication

[Jakub Hrozek]

On Thu, Aug 25, 2016 at 04:11:29PM +, Neal Harrington | i-Neda Ltd wrote:
> > > Hi,
> 
> > >
> > > I am experiencing slow logins and sudo authentication for servers joined 
> > > to my FreeIPA domain. I have been following the other recent thread on 
> > > slow logins and believe my issue is different.
> > >
> > > I have replication setup with 2 FreeIPA servers at each of 3 sites. The 
> > > replication is working well and I am able to login correctly on client 
> > > servers with correct sudo permissions etc. Logins seem to take a long 
> > > time however. There seems to be some kind of DNS/connection timeout 
> > > issues, see the example below where the client times out on the auth01 
> > > server, then retries and connects. I have also seen it switch to an 
> > > alternate IPA server on timeout. Total delay in this example is about 10 
> > > seconds however it can take longer (approx 30 seconds). It is worth 
> > > mentioning that client servers in each site cannot connect to IPA servers 
> > > is a different site - however in the example below the auth01 IPA server 
> > > is in the same site as the client server. I'm not sure if there is any 
> > > way to make the IPA clients site aware so they prefer to log in to a 
> > > local server?
> > >
> > >
> > > On the IPA servers themselves there is no noticeable delay and once I 
> > > have authenticated with sudo once, subsequent attempts in the same login 
> > > are also near instant. I have not been able to find any reason for this 
> > > delay in any logs (which probably just means I'm not looking in the right 
> > > place).
> > >
> > >
> > > DNS servers are running on each IPA server and responding well whenever I 
> > > have tested.
> > >
> > >
> > > IPA Servers: CentOS 7.2.1511 running IPA 4.2.0 (from standard CentOS repo)
> > >
> > > Client servers: Ubuntu 14.04 running IPA 3.3.4 (From standard Ubuntu repo)
> > >
> > >
> > > Any comments or suggestions greatly appreciated.
> > >
> > >
> > > Thanks,
> > >
> > > Neal.
> > >
> > >
> > > Example sssd log for a "sudo -l" attempt.
> > >
> > > (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_child_timeout]
> > > (0x0040): Timeout for child [7430] reached. In case KDC is distant or
> > > network is slow you may consider increasing value of krb5_auth_timeout.
> > > (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_auth_done] (0x0020):
> > > child timed out!
> >
> > These debug messages seem to be telling you what the problem is. Have
> > you tried how long does it take to kinit (preferably with
> > KRB5_TRACE=/dev/stderr prepended) ?
> 
> Hi Jakub,
> 
> Thanks for your response and sorry for my delay in replying. kinit takes 
> between 2 and 25 seconds to complete - the KRB5_TRACE option shows it trying 
> a random auth server, timing out and trying another random server until it 
> picks a local server which then completes almost immediately. This seems to 
> confirm that the problem is simply the server tries to authenticate against a 
> FreeIPA server that is unreachable and times out causing the randomly slow 
> logins. Given 6 auth servers with only 2 on each site there is a ~ 10% chance 
> of hitting 3 bad servers in a row before login succeeds - if each takes 20 
> seconds that would explain the random login times of a few sec - 1 minute.
> 
> If I enter the local kdc servers manually in the realm section of krb5.conf 
> then ssh logins always happen in < 2sec - however I would prefer to avoid the 
> manual step of configuring and updating this (planning to expand out to a few 
> hundred servers over 4-5 sites). Manually setting these is likely to lead to 
> mistakes and it just feels inelegant compared to DNS SRV records.
> 
> I have seen https://www.freeipa.org/page/V4/DNS_Location_Mechanism which 
> looks good but is a proposal from 2013 with no indications that it has 
> actually been developed. I was also very interested by 
> https://www.freeipa.org/page/Howto/IPA_locations which would be perfect - 
> except the "ipa location-add" commands do not seem to be recognised by my 
> FreeIPA installs.
> 
> Am I missing a better way to handle the case of multiple locations with 
> clients in Location A being unable to authenticate against FreeIPA servers at 
> location B?
> 
> Any suggestions greatly appreciated.
> 
> Thanks,
> Neal.
> 

Petr Spacek (CC) has been working lately in this area, but frankly I
don't know what the status is or what a recommendation for current
versions might be..

-- 
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] Questions about 1.14 software bugs

[Lukas Slebodnik]

On (25/08/16 18:30), Sullivan, Daniel [AAA] wrote:
>Hi, 
>
>I feel like I’ve been warned at least twice that sssd 1.14 has some known 
>regressions that make it unstable.  We’re in the process of rolling it out to 
>our production environment (we can’t use 1.13 due to another issue); so far it 
>seems pretty stable, although if possible I’d like any sort of highly informed 
>advisement if it is really stupid or insane to move forward with 1.14.  
>Specifically, we are implementing 1.14.0-3.el6.
>
May I know what is a blocker for using default version of sssd(1.13) in el6?
It is a stable version ready for production.

>Similarly, is it safe to say that this is a comprehensive list of known issues 
>or are there identified problems that aren’t documented in this report?
>
>https://fedorahosted.org/sssd/report/2
>
https://fedorahosted.org/sssd/report/3 would be better
and look directly into the bucket "SSSD 1.14.2"

>Any advise or recommendation that an expert in sssd 1.14 could provide would 
>be appreciated (as I said before so far it seems pretty stable).
>
We fixed many bugs in 1.14.1 and copr repository was updated
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
I would say it si 99% ready for production.

We will appreciate testing. And in case of any bugs, I can release
new version in copr immediately after fixing bug in upstream.

LS

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

Re: [Freeipa-users] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Linov Suresh]

Great! That worked.
Thank you so much Rob. Your help is highly appreciated.

On Thu, Aug 25, 2016 at 3:49 PM, Rob Crittenden  wrote:

> Linov Suresh wrote:
>
>> I ran  ldapsearch -Y GSSAPI, what we are seeing is IPA server 2, ipa02
>>   is missing on both master and replica servers. Do we need to add IPA
>> server 2, ipa02 on both master and replica?
>>
>
> No, it should replicate. I find it very strange that these are missing. I
> wonder what else wasn't setup when the replica was created.
>
> In any case, this will add the entries:
>
> # ldapmodify -Y GSSAPI
> dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=teloip,dc=net
> changetype: modify
> add: memberPrincipal
> memberPrincipal: HTTP/ipa02.teloip@teloip.net
>
> ^D
>
> # ldapmodify -Y GSAPI
> dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=teloip,dc=net
> hangetype: modify
> add: memberPrincipal
> memberPrincipal: ldap/ipa02.teloip@teloip.net
>
> ^D
>
> rob
>
>>
>> *[root@ipa01 ~]# ldapsearch -Y GSSAPI -H ldap://ipa01.teloip.net
>>  -b "cn=s4u2proxy,cn=etc,dc=teloip,dc=net"*
>> SASL/GSSAPI authentication started
>> SASL username: ad...@teloip.net 
>> SASL SSF: 56
>> SASL data security layer installed.
>> # extended LDIF
>> #
>> # LDAPv3
>> # base 

Re: [Freeipa-users] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Rob Crittenden]

Linov Suresh wrote:

I ran  ldapsearch -Y GSSAPI, what we are seeing is IPA server 2, ipa02
  is missing on both master and replica servers. Do we need to add IPA
server 2, ipa02 on both master and replica?


No, it should replicate. I find it very strange that these are missing. 
I wonder what else wasn't setup when the replica was created.


In any case, this will add the entries:

# ldapmodify -Y GSSAPI
dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=teloip,dc=net
changetype: modify
add: memberPrincipal
memberPrincipal: HTTP/ipa02.teloip@teloip.net

^D

# ldapmodify -Y GSAPI
dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=teloip,dc=net
hangetype: modify
add: memberPrincipal
memberPrincipal: ldap/ipa02.teloip@teloip.net

^D

rob


*[root@ipa01 ~]# ldapsearch -Y GSSAPI -H ldap://ipa01.teloip.net
 -b "cn=s4u2proxy,cn=etc,dc=teloip,dc=net"*
SASL/GSSAPI authentication started
SASL username: ad...@teloip.net 
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base 

[Freeipa-users] Questions about 1.14 software bugs

[Sullivan, Daniel [AAA]]

Hi, 

I feel like I’ve been warned at least twice that sssd 1.14 has some known 
regressions that make it unstable.  We’re in the process of rolling it out to 
our production environment (we can’t use 1.13 due to another issue); so far it 
seems pretty stable, although if possible I’d like any sort of highly informed 
advisement if it is really stupid or insane to move forward with 1.14.  
Specifically, we are implementing 1.14.0-3.el6.

Similarly, is it safe to say that this is a comprehensive list of known issues 
or are there identified problems that aren’t documented in this report?

https://fedorahosted.org/sssd/report/2

Any advise or recommendation that an expert in sssd 1.14 could provide would be 
appreciated (as I said before so far it seems pretty stable).

Best,

Dan Sullivan


This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


-- 
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] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Linov Suresh]

I ran  ldapsearch -Y GSSAPI, what we are seeing is IPA server 2, ipa02  is
missing on both master and replica servers. Do we need to add IPA server 2,
ipa02 on both master and replica?

*[root@ipa01 ~]# ldapsearch -Y GSSAPI -H ldap://ipa01.teloip.net
 -b "cn=s4u2proxy,cn=etc,dc=teloip,dc=net"*
SASL/GSSAPI authentication started
SASL username: ad...@teloip.net
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] sudo rules question on ubuntu 16.0.1

[Jeff Goddard]

I'm still hoping someone can offer additional help. I see in the apt
term.log these errors when downloading the freeipa-client package. Could
this be the problem?

Creating SSSD system user & group...
adduser: Warning: The home directory `/var/lib/sss' does not belong to the
user you are currently creating.
Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing
complain mode
Warning failed to create cache: usr.sbin.sssd
Job for sssd.service failed because the control process exited with error
code. See "systemctl status sssd.service" and "journalctl -xe" for details.
sssd.service couldn't start.
Setting up sssd-ad-common (1.13.4-1ubuntu1) ...
Setting up sssd-krb5-common (1.13.4-1ubuntu1) ...
Setting up sssd-ad (1.13.4-1ubuntu1) ...
Setting up sssd-ipa (1.13.4-1ubuntu1) ...
Setting up sssd-krb5 (1.13.4-1ubuntu1) ...
Setting up sssd-ldap (1.13.4-1ubuntu1) ...
Setting up sssd-proxy (1.13.4-1ubuntu1) ...
Setting up sssd (1.13.4-1ubuntu1) ...
Setting up freeipa-client (4.3.1-0ubuntu1) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Processing triggers for systemd (229-4ubuntu7) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for dbus (1.10.6-1ubuntu3) ...
Log ended: 2016-08-25  13:49:53


On Sun, Aug 14, 2016 at 2:16 PM, Jakub Hrozek  wrote:

> Hi Pavel, can you help us with this thread?
>
> > On 12 Aug 2016, at 21:57, Jeff Goddard  wrote:
> >
> >
> >
> > On Fri, Aug 12, 2016 at 3:53 PM, Justin Stephenson 
> wrote:
> > In the CentOS/RHEL 7 version of sssd, a NIS netgroup is created
> automatically in the IPA compat tree under 'cn=ng,cn=compat,$suffix'
> because sudo has no understanding of hostgroups.
> >
> > You should be able to query this on a client with
> >   # getent netgroup office
> >
> > This should return nisNetgroupTriple for each host in the hostgroup
> >  (ipa-client-1.example.com,-,example.com) (ipa-client-2.example.com
> ,-,example.com)
> >
> > I would check this in your environment between working and non-working
> systems.
> > I believe in later versions of sssd they added IPA sudo schema support
> to eliminate the need for the compat tree so this could be related to the
> issue if newer ubuntu clients are not working but CentOS is working.
> >
> > What version of sssd are you running?
> > Kind regards,
> >
> > Justin Stephenson
> > On 08/12/2016 02:35 PM, Jeff Goddard wrote:
> >> I made the edit as suggested - removing nis and just leaving sss -
> restarted sssd and then re-tried. I also tried with files sss. Still
> getting the same result.
> >>
> >> Thanks,
> >>
> >> Jeff
> > The query returns the expect results:
> >
> >  getent netgroup office
> > office(docker-dev-01.internal.emerlyn.com,-,internal.
> emerlyn.com) (docker-dev-02.internal.emerlyn.com,-,internal.emerlyn.com) (
> docker-dev-03.internal.emerlyn.com,-,internal.emerlyn.com) [more hosts]
> >
> > sssd version is 1.13.4
> >
> > Jeff
> >
> >
> >
>
>


Jeff
-- 
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] Cleaning Up an Unholy Mess

[Ian Harding]

On 08/25/2016 10:41 AM, Rob Crittenden wrote:
> Ian Harding wrote:
>>
>>
>> On 08/24/2016 06:33 PM, Rob Crittenden wrote:
>>> Ian Harding wrote:
 I tried to simply uninstall and reinstall freeipa-dal and this
 happened.

 It only had a replication agreement with freeipa-sea

 [root@freeipa-dal ianh]# ipa-server-install --uninstall

 This is a NON REVERSIBLE operation and will delete all data and
 configuration!

 Are you sure you want to continue with the uninstall procedure?
 [no]: yes
 Shutting down all IPA services
 Removing IPA client configuration
 Unconfiguring ntpd
 Configuring certmonger to stop tracking system certificates for KRA
 Configuring certmonger to stop tracking system certificates for CA
 Unconfiguring CA
 Unconfiguring named
 Unconfiguring ipa-dnskeysyncd
 Unconfiguring web server
 Unconfiguring krb5kdc
 Unconfiguring kadmin
 Unconfiguring directory server
 Unconfiguring ipa_memcached
 Unconfiguring ipa-otpd
 [root@freeipa-dal ianh]# ipa-server-install --uninstall

 This is a NON REVERSIBLE operation and will delete all data and
 configuration!

 Are you sure you want to continue with the uninstall procedure?
 [no]: yes

 WARNING: Failed to connect to Directory Server to find information
 about
 replication agreements. Uninstallation will continue despite the
 possible
 existing replication agreements.
 Shutting down all IPA services
 Removing IPA client configuration
 Configuring certmonger to stop tracking system certificates for KRA
 Configuring certmonger to stop tracking system certificates for CA
 [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
 --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
 Directory Manager (existing master) password:

 The host freeipa-dal.bpt.rocks already exists on the master server.
 You should remove it before proceeding:
   % ipa host-del freeipa-dal.bpt.rocks
 [root@freeipa-dal ianh]#

 So I tried to delete it again with --force

 [root@freeipa-sea ianh]# ipa-replica-manage --force del
 freeipa-dal.bpt.rocks
 Directory Manager password:

 'freeipa-sea.bpt.rocks' has no replication agreement for
 'freeipa-dal.bpt.rocks'
 [root@freeipa-sea ianh]#

 Can't delete it from the master server either

 [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
 ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
 disabled


 Now what?  I'm running out of things that work.
>>>
>>> Not sure what version of IPA you have but try:
>>>
>>> # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks
>>>
>>> If this had a CA on it then you'll want to ensure that any replication
>>> agreements it had have been removed as well.
>>>
>>> rob
>>>
>>
>> It turns out I'm not smart enough to untangle this mess.
>>
>> Is there any way to kind of start over?  I managed to delete and
>> recreate a couple replicas but the problems (obsolete ruv as far as I
>> can tell) carry on with the new replicas.  They won't even replicate
>> back to the master they were created from.
> 
> Once you have the right version of 389-ds then then cleanruv tasks work
> a lot better. What version are you running now?

1.3.4.0.  It's handcuffed to my CentOS 7 so I don't want to update it
outside the CentOS ecosystem.  What's the downside of upgrading it from
source or an RPM for a different flavor of RedHat derived Linux?

I'm a one-man band but I'd be interested in hearing a pitch from someone
who is super smart on this stuff for a working consulting gig and maybe
ongoing support.  Who would I talk to at RedHat about coming in from the
cold for full on corporate support?

Thanks!

> 
>> Basically, is there a way to do a fresh install of FreeIPA server, and
>> do a dump/restore of data from my existing messed up install?
> 
> Not really, no. You can migrate IPA to IPA but only users and groups and
> you lose private groups for existing users (they become regular POSIX
> groups).
> 
> rob
> 

-- 
Ian Harding
IT Director
Brown Paper Tickets
1-800-838-3006 ext 7186
http://www.brownpapertickets.com

-- 
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] Migrate users with password from one IPA to another

[Rob Crittenden]

Rene Trippen wrote:

Hi,

I`ve got an IPA with a broken CA infrastructure (don`t know what
happened, but new clients cannot be registered)
It is even not possible to setup a new replica.


It may be fairly straightforward to getting the CA back up. How is it 
broken?



So, I wanted to setup a new IPA Server with new CA, and I want to move
all users with their passwords to the new IPA instance.
I`ve tried with 'ipa migrate-ds'

ipa migrate-ds --continue --bind-dn="cn=Directory Manager"
--user-container=cn=users,cn=accounts
--group-container=cn=groups,cn=accounts --group-objectclass=posixgroup
--group-overwrite-gid --with-compat ldap://

The output is OK
===
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.


But  the ipa/migration website is not working for me.
Anyway, is there a way to export the users with passwords? I think I
have to export some kerberos specific stuff from the old IPA?


The log file /var/log/httpd/error_log may have details on what isn't 
working.


The way to export users with passwords is the method you've already 
tried. To not have to change a password at all would require the same 
Kerberos master key and these are generated randomly at install time.


rob

--
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] Cleaning Up an Unholy Mess

[Rob Crittenden]

Ian Harding wrote:



On 08/24/2016 06:33 PM, Rob Crittenden wrote:

Ian Harding wrote:

I tried to simply uninstall and reinstall freeipa-dal and this happened.

It only had a replication agreement with freeipa-sea

[root@freeipa-dal ianh]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes
Shutting down all IPA services
Removing IPA client configuration
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa_memcached
Unconfiguring ipa-otpd
[root@freeipa-dal ianh]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes

WARNING: Failed to connect to Directory Server to find information about
replication agreements. Uninstallation will continue despite the possible
existing replication agreements.
Shutting down all IPA services
Removing IPA client configuration
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
[root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
--no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
Directory Manager (existing master) password:

The host freeipa-dal.bpt.rocks already exists on the master server.
You should remove it before proceeding:
  % ipa host-del freeipa-dal.bpt.rocks
[root@freeipa-dal ianh]#

So I tried to delete it again with --force

[root@freeipa-sea ianh]# ipa-replica-manage --force del
freeipa-dal.bpt.rocks
Directory Manager password:

'freeipa-sea.bpt.rocks' has no replication agreement for
'freeipa-dal.bpt.rocks'
[root@freeipa-sea ianh]#

Can't delete it from the master server either

[root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
disabled


Now what?  I'm running out of things that work.


Not sure what version of IPA you have but try:

# ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks

If this had a CA on it then you'll want to ensure that any replication
agreements it had have been removed as well.

rob



It turns out I'm not smart enough to untangle this mess.

Is there any way to kind of start over?  I managed to delete and
recreate a couple replicas but the problems (obsolete ruv as far as I
can tell) carry on with the new replicas.  They won't even replicate
back to the master they were created from.


Once you have the right version of 389-ds then then cleanruv tasks work 
a lot better. What version are you running now?



Basically, is there a way to do a fresh install of FreeIPA server, and
do a dump/restore of data from my existing messed up install?


Not really, no. You can migrate IPA to IPA but only users and groups and 
you lose private groups for existing users (they become regular POSIX 
groups).


rob

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

Re: [Freeipa-users] Slow logins with multi site replication

[Neal Harrington | i-Neda Ltd]

> > Hi,

> >
> > I am experiencing slow logins and sudo authentication for servers joined to 
> > my FreeIPA domain. I have been following the other recent thread on slow 
> > logins and believe my issue is different.
> >
> > I have replication setup with 2 FreeIPA servers at each of 3 sites. The 
> > replication is working well and I am able to login correctly on client 
> > servers with correct sudo permissions etc. Logins seem to take a long time 
> > however. There seems to be some kind of DNS/connection timeout issues, see 
> > the example below where the client times out on the auth01 server, then 
> > retries and connects. I have also seen it switch to an alternate IPA server 
> > on timeout. Total delay in this example is about 10 seconds however it can 
> > take longer (approx 30 seconds). It is worth mentioning that client servers 
> > in each site cannot connect to IPA servers is a different site - however in 
> > the example below the auth01 IPA server is in the same site as the client 
> > server. I'm not sure if there is any way to make the IPA clients site aware 
> > so they prefer to log in to a local server?
> >
> >
> > On the IPA servers themselves there is no noticeable delay and once I have 
> > authenticated with sudo once, subsequent attempts in the same login are 
> > also near instant. I have not been able to find any reason for this delay 
> > in any logs (which probably just means I'm not looking in the right place).
> >
> >
> > DNS servers are running on each IPA server and responding well whenever I 
> > have tested.
> >
> >
> > IPA Servers: CentOS 7.2.1511 running IPA 4.2.0 (from standard CentOS repo)
> >
> > Client servers: Ubuntu 14.04 running IPA 3.3.4 (From standard Ubuntu repo)
> >
> >
> > Any comments or suggestions greatly appreciated.
> >
> >
> > Thanks,
> >
> > Neal.
> >
> >
> > Example sssd log for a "sudo -l" attempt.
> >
> > (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_child_timeout]
> > (0x0040): Timeout for child [7430] reached. In case KDC is distant or
> > network is slow you may consider increasing value of krb5_auth_timeout.
> > (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_auth_done] (0x0020):
> > child timed out!
>
> These debug messages seem to be telling you what the problem is. Have
> you tried how long does it take to kinit (preferably with
> KRB5_TRACE=/dev/stderr prepended) ?

Hi Jakub,

Thanks for your response and sorry for my delay in replying. kinit takes 
between 2 and 25 seconds to complete - the KRB5_TRACE option shows it trying a 
random auth server, timing out and trying another random server until it picks 
a local server which then completes almost immediately. This seems to confirm 
that the problem is simply the server tries to authenticate against a FreeIPA 
server that is unreachable and times out causing the randomly slow logins. 
Given 6 auth servers with only 2 on each site there is a ~ 10% chance of 
hitting 3 bad servers in a row before login succeeds - if each takes 20 seconds 
that would explain the random login times of a few sec - 1 minute.

If I enter the local kdc servers manually in the realm section of krb5.conf 
then ssh logins always happen in < 2sec - however I would prefer to avoid the 
manual step of configuring and updating this (planning to expand out to a few 
hundred servers over 4-5 sites). Manually setting these is likely to lead to 
mistakes and it just feels inelegant compared to DNS SRV records.

I have seen https://www.freeipa.org/page/V4/DNS_Location_Mechanism which looks 
good but is a proposal from 2013 with no indications that it has actually been 
developed. I was also very interested by 
https://www.freeipa.org/page/Howto/IPA_locations which would be perfect - 
except the "ipa location-add" commands do not seem to be recognised by my 
FreeIPA installs.

Am I missing a better way to handle the case of multiple locations with clients 
in Location A being unable to authenticate against FreeIPA servers at location 
B?

Any suggestions greatly appreciated.

Thanks,
Neal.

-- 
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] Two masters and one of them is desynchronized

[Ludwig Krispenz]

On 08/25/2016 04:41 PM, bahan w wrote:


Hello everyone.

Could you explain to me about this field Sent/Skipped please ?
if replication is enabled all changes on a server are logged into the 
changelog -changes coming from clients and internal changes (eg mmeberof 
update, passwordpolocy updates, lstlogin time ...).
In the replication agreement you can configure attributes for which 
changes are not replicated (keep them local) - and IPA uses this feature 
eg for krblastlogintime.


Looking at the replication traffic your monitoring shows, I think most 
of the "real" updates are going to one server and most of the clients 
triggering internal updates are going to the other. This makes 
replciation in one direction "normal" and in the other fractional. The 
problem with fractional is that the determined staring point for a 
replciation session can b every far behind and it again and again 
iterates over the same changes until finally an update which is not 
skipped is found.


There are some options to improve this:
- upgarde to a newer version, teh DS will automatically generate updates 
to a "keep alive" entry, so that the sequences of skipped changes get 
much smaller
- do it yourself by regularily applying a dummy update on the 
problematic server which will be replicated
- check configuration if writing the internal mods can be avoided, I 
think there is an option not to log krblastlogin




I checked the doc and found this :
###

Sent/Skipped :



The number of changes that were sent from the supplier and the number 
skipped in the replication update. The numbers are kept in suppliers’ 
memory only and are cleared if the supplier is restarted.


###

If I check the first part :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Last Modify Time: 8/24/2016 18:36:32
Supplier: :389
Sent/Skipped: 182110 / 1054
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:36:32
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

This is the replication from the MASTER OK (the supplier) to the 
MASTER UNSYNC (the receiver), right ?

So, the MASTER OK sent 182110 changes.
And in addition to these 182110 changes, 1054 changes were sent to the 
MASTER UNSYNC but skipped by the MASTER UNSYNC, right ?

Why are they skipped ?

In the other side, if I take the second part :
###
Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9048655
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:36:33
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

The supplier is the MASTER UNSYNC and the receiver is the MASTER OK.
In this case I have only 3 changes sent.
And in addition to these 3 changes, 9 048 655 changes were sent but 
skipped on the MASTER OK, right ?


I ask these questions just to be sure I understand right the return of 
the pl script.



Best regards.

Bahan


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] Migrate users with password from one IPA to another

[Rene Trippen]

Hi,

I`ve got an IPA with a broken CA infrastructure (don`t know what happened,
but new clients cannot be registered)
It is even not possible to setup a new replica.
So, I wanted to setup a new IPA Server with new CA, and I want to move all
users with their passwords to the new IPA instance.
I`ve tried with 'ipa migrate-ds'

ipa migrate-ds --continue --bind-dn="cn=Directory Manager"
--user-container=cn=users,cn=accounts
--group-container=cn=groups,cn=accounts --group-objectclass=posixgroup
--group-overwrite-gid --with-compat ldap://

The output is OK
===
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.


But  the ipa/migration website is not working for me.
Anyway, is there a way to export the users with passwords? I think I have
to export some kerberos specific stuff from the old IPA?

Best regards,
Rene
-- 
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] Two masters and one of them is desynchronized

[bahan w]

Hello everyone.

Could you explain to me about this field Sent/Skipped please ?

I checked the doc and found this :
###

Sent/Skipped :

The number of changes that were sent from the supplier and the number
skipped in the replication update. The numbers are kept in suppliers’
memory only and are cleared if the supplier is restarted.
###

If I check the first part :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Last Modify Time: 8/24/2016 18:36:32
Supplier: :389
Sent/Skipped: 182110 / 1054
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:36:32
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

This is the replication from the MASTER OK (the supplier) to the MASTER
UNSYNC (the receiver), right ?
So, the MASTER OK sent 182110 changes.
And in addition to these 182110 changes, 1054 changes were sent to the
MASTER UNSYNC but skipped by the MASTER UNSYNC, right ?
Why are they skipped ?

In the other side, if I take the second part :
###
Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9048655
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:36:33
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

The supplier is the MASTER UNSYNC and the receiver is the MASTER OK.
In this case I have only 3 changes sent.
And in addition to these 3 changes, 9 048 655 changes were sent but skipped
on the MASTER OK, right ?

I ask these questions just to be sure I understand right the return of the
pl script.


Best regards.

Bahan
-- 
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] SUDO and group lookup in AD trust

[Jakub Hrozek]

On Thu, Aug 25, 2016 at 11:30:52AM +0200, Troels Hansen wrote:
> Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade, getting a 
> version 1.14.1, clean cache DB (complaing about cache being old version), I 
> can getent users, but log log in for no obvious reason (system error in 
> secure.log).
> 
> Downgrading to official RHEL 7.2 SSSD-1.13 restores logging in. 

Please send some logs..

-- 
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] SUDO and group lookup in AD trust

[Troels Hansen]

Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade, getting a 
version 1.14.1, clean cache DB (complaing about cache being old version), I can 
getent users, but log log in for no obvious reason (system error in secure.log).

Downgrading to official RHEL 7.2 SSSD-1.13 restores logging in. 

- On Aug 25, 2016, at 10:48 AM, Lukas Slebodnik lsleb...@redhat.com wrote:

> On (25/08/16 10:05), Troels Hansen wrote:
>>Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>>
>>https://fedorahosted.org/sssd/ticket/2919
>>
> Meanwhile, you can test upstream version
> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
> 
> LS

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] SUDO and group lookup in AD trust

[Lukas Slebodnik]

On (25/08/16 10:05), Troels Hansen wrote:
>Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>
>https://fedorahosted.org/sssd/ticket/2919
>
Meanwhile, you can test upstream version
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

LS

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Jakub Hrozek]

yes.

On Thu, Aug 25, 2016 at 10:05:36AM +0200, Troels Hansen wrote:
> Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
> 
> https://fedorahosted.org/sssd/ticket/2919
> 
> Am I correct?
> 
> - On Aug 25, 2016, at 9:24 AM, Troels Hansen t...@casalogic.dk wrote:
> 
> > Hmm, sometimes the man page actually helps
> > 
> > It seems setting "default_domain_suffix" to allow users to log in, without 
> > the
> > domain part changes use_fully_qualified_names default to true, without the
> > option of setting it false.
> > 
> > So, we have two options:
> > - Have users always use their full login including domain
> > - Setting default_domain_suffix to help the users and efficiently break 
> > SUDO?
> > 
> > Can this be true?
> > 
> > 
> > - On Aug 25, 2016, at 8:42 AM, Troels Hansen t...@casalogic.dk wrote:
> > 
> >> Yes and no
> >> 
> >> Have tried setting it to both true and false, but doesn't make a huge
> >> difference.
> >> 
> >> Current result with "use_fully_qualified_names = false"
> >> 
> >> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
> >> 
> >> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
> >> (0x0200): Searching sysdb with
> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
> >> ...
> >> (sudoUser=%domain_users)(sudoUser=+*)))]
> >> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
> >> rules with higher-wins logic
> >> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> >> (0x0400): Returning 1 rules for [drext...@net.dr.dk]
> >> 
> >> SSSD cache shows the sudo rule:
> >> 
> >> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb
> >> '(objectClass=sudoRule)'
> >> asq: Unable to register control with rootdse!
> >> # record 1
> >> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> >> cn: guffe
> >> dataExpireTimestamp: 1472110940
> >> entryUSN: 325878
> >> name: guffe
> >> objectClass: sudoRule
> >> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> >> sudoCommand: /usr/bin/cat /var/log/messages
> >> sudoHost: ALL
> >> sudoRunAsGroup: ALL
> >> sudoRunAsUser: ALL
> >> sudoUser: %domain_users
> >> distinguishedName: 
> >> name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> >> 
> >> But still sudo debug log says:
> >> 
> >> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
> >> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
> >> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> >> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
> >> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
> >> 0x7f877f45d348
> >> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
> >> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> >> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
> >> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
> >> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 
> >> 0x7f877f44ef20
> >> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
> >> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
> >> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 
> >> 0x7f877f44ef38
> >> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
> >> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
> >> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
> >> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
> >> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
> >> 
> >> 
> >> I'm quite lost on how to debug further on this.
> >> 
> >> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
> >> 
> >>> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>  Running RHEL 7.2:
>  
>  ipa-client-4.2.0-15.el7_2.18
>  sssd-ipa-1.13.0-40.el7_2.12.x86_64
>  ipa-server-4.2.0-15.el7_2.18.x86_64
>  
>  I have a sudo rule where I try to give sudo access based on a AD group.
>  
>  # groups drext...@net.dr.dk
>  drext...@net.dr.dk : drext...@net.dr.dk ... 
>  domain_us...@linux.dr.dk
>  
>  I'm member of the group domain_users via AD.
>  
>  SUDO rule in LDAP:
>  
>  # guffe, sudoers, linux.dr.dk
>  dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>  sudoUser: %domain_users
>  sudoRunAsGroup: ALL
>  objectClass: sudoRole
>  objectClass: top
>  sudoCommand: /usr/bin/cat /var/log/messages
>  sudoRunAsUser: ALL
>  sudoHost: ALL
>  cn: guffe
> >>> 
> >>> domain_users != domain_us...@linux.dr.dk
> >>> 
> >>> I'm also curious why sssd qualifies the IPA group name (domain_users is
> >>> an IPA group name right?)
> >>> 
> >>> do you set use_fully_qualified_names=true by chance in the config file?
> >>> 
> >>> --

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Rakesh Rajasekharan]

All of the troubleshooting seems fine.


However, Running libconv.pl gives me this output

- Recommendations -

 1.  You have unindexed components, this can be caused from a search on an
unindexed attribute, or your returned results exceeded the
allidsthreshold.  Unindexed components are not recommended. To refuse
unindexed searches, switch 'nsslapd-require-index' to 'on' under your
database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).

 2.  You have a significant difference between binds and unbinds.  You may
want to investigate this difference.


I feel, this could be a pointer to things going slow.. and IPA hanging. I
think i now have something that I can try and nail down this issue.

On a sidenote, I was earlier running openldap and migrated over to Freeipa,

Thanks
Rakesh



On Wed, Aug 24, 2016 at 12:38 PM, Petr Spacek  wrote:

> On 23.8.2016 18:44, Rakesh Rajasekharan wrote:
> > I think thers something seriously wrong with my system
> >
> > not able to run any  IPA commands
> >
> > klist
> > Ticket cache: KEYRING:persistent:0:0
> > Default principal: ad...@xyz.com
> >
> > Valid starting   Expires  Service principal
> > 2016-08-23T16:26:36  2016-08-24T16:26:22  krbtgt/xyz@xyz.com
> >
> >
> > [root@prod-ipa-master-1a :~] ipactl status
> > Directory Service: RUNNING
> > krb5kdc Service: RUNNING
> > kadmin Service: RUNNING
> > ipa_memcached Service: RUNNING
> > httpd Service: RUNNING
> > pki-tomcatd Service: RUNNING
> > ipa-otpd Service: RUNNING
> > ipa: INFO: The ipactl command was successful
> >
> >
> >
> > [root@prod-ipa-master :~] ipa user-find p-testuser
> > ipa: ERROR: Kerberos error: ('Unspecified GSS failure.  Minor code may
> > provide more information', 851968)/("Cannot contact any KDC for realm '
> > XYZ.COM'", -1765328228)
> >
>
> This is weird because the server seems to be up.
>
> Please follow
> http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos
>
> Petr^2 Spacek
>
> >
> >
> > Thanks
> >
> > Rakesh
> >
> > On Tue, Aug 23, 2016 at 10:01 PM, Rakesh Rajasekharan <
> > rakesh.rajasekha...@gmail.com> wrote:
> >
> >> i changed the loggin level to 4 . Modifying nsslapd-accesslog-level
> >>
> >> But, the hang is still there. though I dont see the sigfault now
> >>
> >>
> >>
> >>
> >> On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
> >> rakesh.rajasekha...@gmail.com> wrote:
> >>
> >>> My disk was getting filled too fast
> >>>
> >>> logs under /var/log/dirsrv was coming around 5 gb quickly filling up
> >>>
> >>> Is there a way to make the logging less verbose
> >>>
> >>>
> >>>
> >>> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek 
> wrote:
> >>>
>  On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
> > I was able to fix that may be temporarily... when i checked the
>  network..
> > there was another process that was running and consuming a lot of
>  network (
> > i have no idea who did that. I need to seriously start restricting
>  people
> > access to this machine )
> >
> > after killing that perfomance improved drastically
> >
> > But now, suddenly I started experiencing the same hang.
> >
> > This time , I gert the following error when checked dmesg
> >
> > [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
> > 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
> > [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port
> 88.
> > Sending cookies.  Check SNMP counters.
> > [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
> > 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
> > [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
> > 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
> 
>  Okay, this one is serious. The LDAP server crashed.
> 
>  1. Make sure all your packages are up-to-date.
> 
>  Please see
>  http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
>  ebugging-crashes
>  for further instructions how to debug this.
> 
>  Petr^2 Spacek
> 
> >
> > and in /var/log/dirsrv/example-com/errors
> >
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>  could
> > not delete change record 3291138 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>  could
> > not delete change record 3291139 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>  could
> > not delete change record 3291140 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>  could
> > not delete change record 3291141 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>  could
> > not delete change record 3291142 (rc: 32)
> > [23/Aug/2016:12:49:36 +] 

Re: [Freeipa-users] Two masters and one of them is desynchronized

[Ludwig Krispenz]

I just noticed that you have many skipped entries, Sent/Skipped: 3 / 9045345

that could be an effect of fractional replication which  reiterates the 
same sequence of changes. This is fixed in recent releases, but looks 
like your on RHEL 6.6


Ludwig

On 08/24/2016 06:33 PM, bahan w wrote:

Hey guys.

I performed it :
###
# /usr/bin/repl-monitor.pl  -f /tmp/checkconf -s
Directory Server Replication Status (Version 1.1)

Time: Wed Aug 24 2016 18:16:50

Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Last Modify Time: 8/24/2016 18:16:50
Supplier: :389
Sent/Skipped: 179031 / 1037
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9045345
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI
###

Do you see something strange in there ?
I have another environment where I have two replicated master and they 
are OK.

And when I check the same command, the result is a little bit different :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Last Modify Time: 8/24/2016 18:16:00
Supplier: :389
Sent/Skipped: 343515 / 0
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:15:59
Update Ended: 08/24/2016 18:16:08
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 390:51:38
Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
Last Modify Time: 8/8/2016 11:24:28
Supplier: :389
Sent/Skipped: 5 / 2596073
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:16:00
Update Ended: 08/24/2016 18:16:12
Schedule: always in sync
SSL: SASL/GSSAPI
###

Best regards.

Bahan


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] SUDO and group lookup in AD trust

[Troels Hansen]

Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem

https://fedorahosted.org/sssd/ticket/2919

Am I correct?

- On Aug 25, 2016, at 9:24 AM, Troels Hansen t...@casalogic.dk wrote:

> Hmm, sometimes the man page actually helps
> 
> It seems setting "default_domain_suffix" to allow users to log in, without the
> domain part changes use_fully_qualified_names default to true, without the
> option of setting it false.
> 
> So, we have two options:
> - Have users always use their full login including domain
> - Setting default_domain_suffix to help the users and efficiently break SUDO?
> 
> Can this be true?
> 
> 
> - On Aug 25, 2016, at 8:42 AM, Troels Hansen t...@casalogic.dk wrote:
> 
>> Yes and no
>> 
>> Have tried setting it to both true and false, but doesn't make a huge
>> difference.
>> 
>> Current result with "use_fully_qualified_names = false"
>> 
>> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
>> 
>> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>> (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
>> ...
>> (sudoUser=%domain_users)(sudoUser=+*)))]
>> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
>> rules with higher-wins logic
>> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
>> (0x0400): Returning 1 rules for [drext...@net.dr.dk]
>> 
>> SSSD cache shows the sudo rule:
>> 
>> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb
>> '(objectClass=sudoRule)'
>> asq: Unable to register control with rootdse!
>> # record 1
>> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
>> cn: guffe
>> dataExpireTimestamp: 1472110940
>> entryUSN: 325878
>> name: guffe
>> objectClass: sudoRule
>> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>> sudoCommand: /usr/bin/cat /var/log/messages
>> sudoHost: ALL
>> sudoRunAsGroup: ALL
>> sudoRunAsUser: ALL
>> sudoUser: %domain_users
>> distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
>> 
>> But still sudo debug log says:
>> 
>> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
>> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
>> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
>> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
>> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
>> 0x7f877f45d348
>> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
>> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
>> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
>> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
>> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
>> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
>> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
>> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 
>> 0x7f877f44ef38
>> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
>> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
>> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
>> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
>> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
>> 
>> 
>> I'm quite lost on how to debug further on this.
>> 
>> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
>> 
>>> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
 Running RHEL 7.2:
 
 ipa-client-4.2.0-15.el7_2.18
 sssd-ipa-1.13.0-40.el7_2.12.x86_64
 ipa-server-4.2.0-15.el7_2.18.x86_64
 
 I have a sudo rule where I try to give sudo access based on a AD group.
 
 # groups drext...@net.dr.dk
 drext...@net.dr.dk : drext...@net.dr.dk ... 
 domain_us...@linux.dr.dk
 
 I'm member of the group domain_users via AD.
 
 SUDO rule in LDAP:
 
 # guffe, sudoers, linux.dr.dk
 dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
 sudoUser: %domain_users
 sudoRunAsGroup: ALL
 objectClass: sudoRole
 objectClass: top
 sudoCommand: /usr/bin/cat /var/log/messages
 sudoRunAsUser: ALL
 sudoHost: ALL
 cn: guffe
>>> 
>>> domain_users != domain_us...@linux.dr.dk
>>> 
>>> I'm also curious why sssd qualifies the IPA group name (domain_users is
>>> an IPA group name right?)
>>> 
>>> do you set use_fully_qualified_names=true by chance in the config file?
>>> 
>>> --
>>> 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
>> 
>> --
>> Med venlig hilsen
>> 
>> Troels Hansen
>> 
>> Systemkonsulent
>> 
>> Casalogic A/S
>> 
>> 
>> T (+45) 70 20 10 63
>> 
>> M (+45) 22 43 71 57
>> 
>> 

Re: [Freeipa-users] Two masters and one of them is desynchronized

[Ludwig Krispenz]

The replication agreements to the "unsync" master says that update has 
started, so it looks like replication connection is active.
You need to check the access and error logs of bot sides and check if 
tehre is replication traffic


On 08/24/2016 06:33 PM, bahan w wrote:

Hey guys.

I performed it :
###
# /usr/bin/repl-monitor.pl  -f /tmp/checkconf -s
Directory Server Replication Status (Version 1.1)

Time: Wed Aug 24 2016 18:16:50

Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Last Modify Time: 8/24/2016 18:16:50
Supplier: :389
Sent/Skipped: 179031 / 1037
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9045345
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI
###

Do you see something strange in there ?
I have another environment where I have two replicated master and they 
are OK.

And when I check the same command, the result is a little bit different :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Last Modify Time: 8/24/2016 18:16:00
Supplier: :389
Sent/Skipped: 343515 / 0
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:15:59
Update Ended: 08/24/2016 18:16:08
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 390:51:38
Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
Last Modify Time: 8/8/2016 11:24:28
Supplier: :389
Sent/Skipped: 5 / 2596073
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:16:00
Update Ended: 08/24/2016 18:16:12
Schedule: always in sync
SSL: SASL/GSSAPI
###

Best regards.

Bahan


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] SUDO and group lookup in AD trust

[Troels Hansen]

Hmm, sometimes the man page actually helps

It seems setting "default_domain_suffix" to allow users to log in, without the 
domain part changes use_fully_qualified_names default to true, without the 
option of setting it false.

So, we have two options:
- Have users always use their full login including domain
- Setting default_domain_suffix to help the users and efficiently break SUDO?

Can this be true?


- On Aug 25, 2016, at 8:42 AM, Troels Hansen t...@casalogic.dk wrote:

> Yes and no
> 
> Have tried setting it to both true and false, but doesn't make a huge
> difference.
> 
> Current result with "use_fully_qualified_names = false"
> 
> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
> 
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
> (0x0200): Searching sysdb with
> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
> ...
> (sudoUser=%domain_users)(sudoUser=+*)))]
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
> rules with higher-wins logic
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> (0x0400): Returning 1 rules for [drext...@net.dr.dk]
> 
> SSSD cache shows the sudo rule:
> 
> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb
> '(objectClass=sudoRule)'
> asq: Unable to register control with rootdse!
> # record 1
> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> cn: guffe
> dataExpireTimestamp: 1472110940
> entryUSN: 325878
> name: guffe
> objectClass: sudoRule
> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> sudoCommand: /usr/bin/cat /var/log/messages
> sudoHost: ALL
> sudoRunAsGroup: ALL
> sudoRunAsUser: ALL
> sudoUser: %domain_users
> distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> 
> But still sudo debug log says:
> 
> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
> 0x7f877f45d348
> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
> 
> 
> I'm quite lost on how to debug further on this.
> 
> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
> 
>> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>>> Running RHEL 7.2:
>>> 
>>> ipa-client-4.2.0-15.el7_2.18
>>> sssd-ipa-1.13.0-40.el7_2.12.x86_64
>>> ipa-server-4.2.0-15.el7_2.18.x86_64
>>> 
>>> I have a sudo rule where I try to give sudo access based on a AD group.
>>> 
>>> # groups drext...@net.dr.dk
>>> drext...@net.dr.dk : drext...@net.dr.dk ... 
>>> domain_us...@linux.dr.dk
>>> 
>>> I'm member of the group domain_users via AD.
>>> 
>>> SUDO rule in LDAP:
>>> 
>>> # guffe, sudoers, linux.dr.dk
>>> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>>> sudoUser: %domain_users
>>> sudoRunAsGroup: ALL
>>> objectClass: sudoRole
>>> objectClass: top
>>> sudoCommand: /usr/bin/cat /var/log/messages
>>> sudoRunAsUser: ALL
>>> sudoHost: ALL
>>> cn: guffe
>> 
>> domain_users != domain_us...@linux.dr.dk
>> 
>> I'm also curious why sssd qualifies the IPA group name (domain_users is
>> an IPA group name right?)
>> 
>> do you set use_fully_qualified_names=true by chance in the config file?
>> 
>> --
>> 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
> 
> --
> Med venlig hilsen
> 
> Troels Hansen
> 
> Systemkonsulent
> 
> Casalogic A/S
> 
> 
> T (+45) 70 20 10 63
> 
> M (+45) 22 43 71 57
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og
> meget mere.
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Jakub Hrozek]

On Thu, Aug 25, 2016 at 08:42:28AM +0200, Troels Hansen wrote:
> Yes and no
> 
> Have tried setting it to both true and false, but doesn't make a huge 
> difference.
> 
> Current result with "use_fully_qualified_names = false"
> 
> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
> 
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
> (0x0200): Searching sysdb with 
> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
> ...
> (sudoUser=%domain_users)(sudoUser=+*)))]
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
> rules with higher-wins logic
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
> (0x0400): Returning 1 rules for [drext...@net.dr.dk]

Does the sudo log indicate that the rule is the one you'd expect?
Because I don't see sudo looking for domain_users below. Can you attach
the complete logs?

> 
> SSSD cache shows the sudo rule:
> 
> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb 
> '(objectClass=sudoRule)'
> asq: Unable to register control with rootdse!
> # record 1
> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> cn: guffe
> dataExpireTimestamp: 1472110940
> entryUSN: 325878
> name: guffe
> objectClass: sudoRule
> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> sudoCommand: /usr/bin/cat /var/log/messages
> sudoHost: ALL
> sudoRunAsGroup: ALL
> sudoRunAsUser: ALL
> sudoUser: %domain_users
> distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> 
> But still sudo debug log says:
> 
> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
> 0x7f877f45d348
> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
> 
> 
> I'm quite lost on how to debug further on this.
> 
> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
> 
> > On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
> >> Running RHEL 7.2:
> >> 
> >> ipa-client-4.2.0-15.el7_2.18
> >> sssd-ipa-1.13.0-40.el7_2.12.x86_64
> >> ipa-server-4.2.0-15.el7_2.18.x86_64
> >> 
> >> I have a sudo rule where I try to give sudo access based on a AD group.
> >> 
> >> # groups drext...@net.dr.dk
> >> drext...@net.dr.dk : drext...@net.dr.dk ... 
> >> domain_us...@linux.dr.dk
> >> 
> >> I'm member of the group domain_users via AD.
> >> 
> >> SUDO rule in LDAP:
> >> 
> >> # guffe, sudoers, linux.dr.dk
> >> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> >> sudoUser: %domain_users
> >> sudoRunAsGroup: ALL
> >> objectClass: sudoRole
> >> objectClass: top
> >> sudoCommand: /usr/bin/cat /var/log/messages
> >> sudoRunAsUser: ALL
> >> sudoHost: ALL
> >> cn: guffe
> > 
> > domain_users != domain_us...@linux.dr.dk
> > 
> > I'm also curious why sssd qualifies the IPA group name (domain_users is
> > an IPA group name right?)
> > 
> > do you set use_fully_qualified_names=true by chance in the config file?
> > 
> > --
> > 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
> 
> -- 
> Med venlig hilsen 
> 
> Troels Hansen 
> 
> Systemkonsulent 
> 
> Casalogic A/S 
> 
> 
> T (+45) 70 20 10 63 
> 
> M (+45) 22 43 71 57 
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
> meget mere.

-- 
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] SUDO and group lookup in AD trust

[Troels Hansen]

Yes and no

Have tried setting it to both true and false, but doesn't make a huge 
difference.

Current result with "use_fully_qualified_names = false"

LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...

(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
...
(sudoUser=%domain_users)(sudoUser=+*)))]
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
rules with higher-wins logic
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
(0x0400): Returning 1 rules for [drext...@net.dr.dk]

SSSD cache shows the sudo rule:

# ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb 
'(objectClass=sudoRule)'
asq: Unable to register control with rootdse!
# record 1
dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
cn: guffe
dataExpireTimestamp: 1472110940
entryUSN: 325878
name: guffe
objectClass: sudoRule
originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
sudoCommand: /usr/bin/cat /var/log/messages
sudoHost: ALL
sudoRunAsGroup: ALL
sudoRunAsUser: ALL
sudoUser: %domain_users
distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb

But still sudo debug log says:

Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 0x7f877f45d348
Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false


I'm quite lost on how to debug further on this.

- On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:

> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>> Running RHEL 7.2:
>> 
>> ipa-client-4.2.0-15.el7_2.18
>> sssd-ipa-1.13.0-40.el7_2.12.x86_64
>> ipa-server-4.2.0-15.el7_2.18.x86_64
>> 
>> I have a sudo rule where I try to give sudo access based on a AD group.
>> 
>> # groups drext...@net.dr.dk
>> drext...@net.dr.dk : drext...@net.dr.dk ... 
>> domain_us...@linux.dr.dk
>> 
>> I'm member of the group domain_users via AD.
>> 
>> SUDO rule in LDAP:
>> 
>> # guffe, sudoers, linux.dr.dk
>> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>> sudoUser: %domain_users
>> sudoRunAsGroup: ALL
>> objectClass: sudoRole
>> objectClass: top
>> sudoCommand: /usr/bin/cat /var/log/messages
>> sudoRunAsUser: ALL
>> sudoHost: ALL
>> cn: guffe
> 
> domain_users != domain_us...@linux.dr.dk
> 
> I'm also curious why sssd qualifies the IPA group name (domain_users is
> an IPA group name right?)
> 
> do you set use_fully_qualified_names=true by chance in the config file?
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] Two masters and one of them is desynchronized

[bahan w]

Le 24 août 2016 18:42, "bahan w"  a écrit :

> Hey guys.
>
> I rechecked and in fact I also have the same message on the multi master
> setup with one master unsynchronized :
> ###
> Master: :389 ldap://:389/
> Replica ID: 4
> Replica Root: dc=
> Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
> Receiver: :389 ldap://:389/
> Type: master
> Time Lag: 0:00:00
> Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
> Last Modify Time: 8/24/2016 18:36:32
> Supplier: :389
> Sent/Skipped: 182110 / 1054
> Update Status: 0 Replica acquired successfully: Incremental update
> succeeded
> Update Started: 08/24/2016 18:36:32
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
>
> Master: :389 ldap://:389/
> Replica ID: 3
> Replica Root: dc=
> Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
> Receiver: :389 ldap://:389/
> Type: master
> Time Lag: - 0:22:29
> Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
> Last Modify Time: 8/24/2016 17:07:34
> Supplier: :389
> Sent/Skipped: 3 / 9048655
> Update Status: 0 Replica acquired successfully: Incremental update
> succeeded
> Update Started: 08/24/2016 18:36:33
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
> ###
>
> So even the synchronization looks good no ?
>
> And even with that, this master really is unsynchronized and don't have
> all the users the other master has.
>
> Best regards.
>
> Bahan
>
> On Wed, Aug 24, 2016 at 6:33 PM, bahan w  wrote:
>
>> Hey guys.
>>
>> I performed it :
>> ###
>> # /usr/bin/repl-monitor.pl -f /tmp/checkconf -s
>> Directory Server Replication Status (Version 1.1)
>>
>> Time: Wed Aug 24 2016 18:16:50
>>
>> Master: :389 ldap://:389/
>> Replica ID: 4
>> Replica Root: dc=
>> Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: 0:00:00
>> Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
>> Last Modify Time: 8/24/2016 18:16:50
>> Supplier: :389
>> Sent/Skipped: 179031 / 1037
>> Update Status: 0 Replica acquired successfully: Incremental update started
>> Update Started: 08/24/2016 18:16:50
>> Update Ended: n/a
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>>
>> Master: :389 ldap://:389/
>> Replica ID: 3
>> Replica Root: dc=
>> Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: - 0:22:29
>> Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
>> Last Modify Time: 8/24/2016 17:07:34
>> Supplier: :389
>> Sent/Skipped: 3 / 9045345
>> Update Status: 0 Replica acquired successfully: Incremental update started
>> Update Started: 08/24/2016 18:16:50
>> Update Ended: n/a
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>> ###
>>
>> Do you see something strange in there ?
>> I have another environment where I have two replicated master and they
>> are OK.
>> And when I check the same command, the result is a little bit different :
>> ###
>> Master: :389 ldap://:389/
>> Replica ID: 4
>> Replica Root: dc=
>> Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: 0:00:00
>> Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
>> Last Modify Time: 8/24/2016 18:16:00
>> Supplier: :389
>> Sent/Skipped: 343515 / 0
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 08/24/2016 18:15:59
>> Update Ended: 08/24/2016 18:16:08
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>>
>> Master: :389 ldap://:389/
>> Replica ID: 3
>> Replica Root: dc=
>> Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: - 390:51:38
>> Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
>> Last Modify Time: 8/8/2016 11:24:28
>> Supplier: :389
>> Sent/Skipped: 5 / 2596073
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 08/24/2016 18:16:00
>> Update Ended: 08/24/2016 18:16:12
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>> ###
>>
>> Best regards.
>>
>> Bahan
>>
>
>
-- 
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