[Freeipa-users] size of DIRSRV database file

[Marisa Sandhoff]

Dear all,

our freeipa (4.1.4) environment manages about 60 users and 250 hosts.
Trying to find out why the disk of our freeipa server is getting tight,
we saw that the database files


[root@ipa cldb]# ls -lh
total 4.9G
-rw--- 1 dirsrv dirsrv  32M Aug 30 08:10
9b098085-8a0c11e5-b48de780-506eafe9_5645e9410060.db
-rw-r--r-- 1 dirsrv dirsrv0 Aug  9 14:32
9b098085-8a0c11e5-b48de780-506eafe9.sema
-rw--- 1 dirsrv dirsrv 4.9G Aug 30 08:23
a5a45b06-f8ad11e4-9f0be780-506eafe9_555205010004.db
-rw-r--r-- 1 dirsrv dirsrv0 Aug  9 14:32
a5a45b06-f8ad11e4-9f0be780-506eafe9.sema
-rw--- 1 dirsrv dirsrv   30 May 12  2015 DBVERSION


in

[root@ipa cldb]# pwd
/var/lib/dirsrv/slapd-PLEIADES-UNI-WUPPERTAL-DE/cldb

are really huge ...

We think that the database is quite big for our not too huge environment
... are there any possibilities in freeipa to reduce the size of the
database files?

Thanks a lot for your help!

Best regards,
Marisa

-- 
Dr. Marisa Sandhoff
Experimentelle Elementarteilchenphysik
Fakultät für Mathematik und Naturwissenschaften
Bergische Universitaet Wuppertal
Gaussstr. 20
D-42097 Wuppertal, Germany
---
marisa.sandh...@cern.ch
sandh...@physik.uni-wuppertal.de
Phone +49 202 439 3521

-- 
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] Permission not working as expected

[Alexander Bokovoy]

On Tue, 30 Aug 2016, Alexander Bokovoy wrote:

On Mon, 29 Aug 2016, Deepak Dimri wrote:

Hi All,
I have created below permission for my "testhostgroup" with the
expectation that this permission will only allow write permission to
the members of "testhostgroup" but, then it allows me to add/delete
other hostgroup members as well. I tried changing the effective
attribute to "memberof" instead of "member" but in vain as with that i
started getting permission denied error even on  testhostgroup itself.
*

ipa permission-add 'testhostgroup-modify' --permission=write --attrs=member 
--filter='(&(cn=testhostgroup)(objectclass=ipahostgroup ))'
--
Added permission "testhostgroup-modify"
--
Permission name: testhostgroup-modify
Granted rights: write
Effective attributes: member
Bind rule type: permission
Subtree: dc=us-west-2,dc=compute,dc=amazonaws,dc=com
Extra target filter: (&(cn= testhostgroup)(objectclass=ipahostgroup ))**
How can i restrict permissions to manage only those hosts which are
part of a particular hostgroup? any help you could offer on this would
be much appreciated. I could not find much on similar issue in the
forum :( Thanks,Deepak  

The permission above says: "Allow changing 'member' attribute in the
testhostgroup object". I don't think this is what you wanted, according
to your explanation above.

Let's say you have host group 'myhostgroup':
# ipa hostgroup-add myhostgroup
-
Added hostgroup "myhostgroup"
-
Host-group: myhostgroup

and now you want to create a permission that would target hosts in the
host group. A member of that permission would be able to do anything
with the host.

First, you need to create a basic permission which applies to hosts:

# ipa permission-add manage-my-hostgroup --right=all 
--bindtype=permission --type=host 
--

Added permission "manage-my-hostgroup"
--
Permission name: manage-my-hostgroup
Granted rights: all
Bind rule type: permission
Subtree: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
Type: host
Permission flags: V2, SYSTEM

Now, look at the permission in detail:

# ipa permission-show --all --raw manage-my-hostgroup
dn: cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc=ipa,dc=ad,dc=test
cn: manage-my-hostgroup
ipapermright: all
ipapermbindruletype: permission
ipapermlocation: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
ipapermtargetfilter: (objectclass=ipahost)
ipapermissiontype: V2
ipapermissiontype: SYSTEM
aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl 
"permission:manage-my-hostgroup";allow (all) groupdn = 
"ldap:///cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc=ipa,dc=ad,dc=test";;)
objectclass: ipapermission
objectclass: top
objectclass: groupofnames
objectclass: ipapermissionv2

As you can see, it applies to hosts: cn=computers,cn=accounts,$SUFFIX
subtree, and target filter is set to (objectclass=ipahost). So it would
apply to any host. To further limit the permission, you have to add more
target filters. But to do so, you need to know DN of the hostgroup that
will be our target limit:

# ipa hostgroup-show --raw --all myhostgroup
dn: cn=myhostgroup,cn=hostgroups,cn=accounts,dc=ipa,dc=ad,dc=test
cn: myhostgroup
ipaUniqueID: 6d8c72f2-6e6d-11e6-b9e4-525400bf08fe
mepManagedEntry: cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test
objectClass: ipahostgroup
objectClass: ipaobject
objectClass: nestedGroup
objectClass: groupOfNames
objectClass: top
objectClass: mepOriginEntry

Now, using DN of the myhostgroup, you can add a filter to the
permission:

# ipa permission-mod manage-my-hostgroup --filter 
'(memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)'

Sorry, a typo here^^ I copied wrong DN, it should be
cn=myhostgroup,cn=hostgroups,cn=accounts,dc=ipa,dc=ad,dc=test

not the managed entry DN.


-
Modified permission "manage-my-hostgroup"
-
Permission name: manage-my-hostgroup
Granted rights: all
Bind rule type: permission
Subtree: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
Extra target filter: (memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)
Type: host
Permission flags: V2, SYSTEM

Check all details of the permission to see that ACI was actually
modified to include the filter:

# ipa permission-show --all --raw manage-my-hostgroup
dn: cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc=ipa,dc=ad,dc=test
cn: manage-my-hostgroup
ipapermright: all
ipapermbindruletype: permission
ipapermlocation: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
ipapermtargetfilter: (objectclass=ipahost)
ipapermtargetfilter: (memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)
ipapermissiontype: V2
ipapermissiontype: SYSTEM
aci: (targetfilter = 
"(&(memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)(objectclass=ipah

Re: [Freeipa-users] Permission not working as expected

[Alexander Bokovoy]

On Mon, 29 Aug 2016, Deepak Dimri wrote:

Hi All,
I have created below permission for my "testhostgroup" with the
expectation that this permission will only allow write permission to
the members of "testhostgroup" but, then it allows me to add/delete
other hostgroup members as well. I tried changing the effective
attribute to "memberof" instead of "member" but in vain as with that i
started getting permission denied error even on  testhostgroup itself.
*

ipa permission-add 'testhostgroup-modify' --permission=write --attrs=member 
--filter='(&(cn=testhostgroup)(objectclass=ipahostgroup ))'
--
Added permission "testhostgroup-modify"
--
 Permission name: testhostgroup-modify
 Granted rights: write
 Effective attributes: member
 Bind rule type: permission
 Subtree: dc=us-west-2,dc=compute,dc=amazonaws,dc=com
 Extra target filter: (&(cn= testhostgroup)(objectclass=ipahostgroup ))**
How can i restrict permissions to manage only those hosts which are
part of a particular hostgroup? any help you could offer on this would
be much appreciated. I could not find much on similar issue in the
forum :( Thanks,Deepak  

The permission above says: "Allow changing 'member' attribute in the
testhostgroup object". I don't think this is what you wanted, according
to your explanation above.

Let's say you have host group 'myhostgroup':
# ipa hostgroup-add myhostgroup
-
Added hostgroup "myhostgroup"
-
 Host-group: myhostgroup

and now you want to create a permission that would target hosts in the
host group. A member of that permission would be able to do anything
with the host.

First, you need to create a basic permission which applies to hosts:

# ipa permission-add manage-my-hostgroup --right=all --bindtype=permission --type=host 
--

Added permission "manage-my-hostgroup"
--
 Permission name: manage-my-hostgroup
 Granted rights: all
 Bind rule type: permission
 Subtree: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
 Type: host
 Permission flags: V2, SYSTEM

Now, look at the permission in detail:

# ipa permission-show --all --raw manage-my-hostgroup
 dn: cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc=ipa,dc=ad,dc=test
 cn: manage-my-hostgroup
 ipapermright: all
 ipapermbindruletype: permission
 ipapermlocation: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
 ipapermtargetfilter: (objectclass=ipahost)
 ipapermissiontype: V2
 ipapermissiontype: SYSTEM
 aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl 
"permission:manage-my-hostgroup";allow (all) groupdn = 
"ldap:///cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc=ipa,dc=ad,dc=test";;)
 objectclass: ipapermission
 objectclass: top
 objectclass: groupofnames
 objectclass: ipapermissionv2

As you can see, it applies to hosts: cn=computers,cn=accounts,$SUFFIX
subtree, and target filter is set to (objectclass=ipahost). So it would
apply to any host. To further limit the permission, you have to add more
target filters. But to do so, you need to know DN of the hostgroup that
will be our target limit:

# ipa hostgroup-show --raw --all myhostgroup
 dn: cn=myhostgroup,cn=hostgroups,cn=accounts,dc=ipa,dc=ad,dc=test
 cn: myhostgroup
 ipaUniqueID: 6d8c72f2-6e6d-11e6-b9e4-525400bf08fe
 mepManagedEntry: cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test
 objectClass: ipahostgroup
 objectClass: ipaobject
 objectClass: nestedGroup
 objectClass: groupOfNames
 objectClass: top
 objectClass: mepOriginEntry

Now, using DN of the myhostgroup, you can add a filter to the
permission:

# ipa permission-mod manage-my-hostgroup --filter 
'(memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)'
-
Modified permission "manage-my-hostgroup"
-
 Permission name: manage-my-hostgroup
 Granted rights: all
 Bind rule type: permission
 Subtree: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
 Extra target filter: 
(memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)
 Type: host
 Permission flags: V2, SYSTEM

Check all details of the permission to see that ACI was actually
modified to include the filter:

# ipa permission-show --all --raw manage-my-hostgroup
 dn: cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc=ipa,dc=ad,dc=test
 cn: manage-my-hostgroup
 ipapermright: all
 ipapermbindruletype: permission
 ipapermlocation: cn=computers,cn=accounts,dc=ipa,dc=ad,dc=test
 ipapermtargetfilter: (objectclass=ipahost)
 ipapermtargetfilter: 
(memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)
 ipapermissiontype: V2
 ipapermissiontype: SYSTEM
 aci: (targetfilter = 
"(&(memberOf=cn=myhostgroup,cn=ng,cn=alt,dc=ipa,dc=ad,dc=test)(objectclass=ipahost))")(version 
3.0;acl "permission:manage-my-hostgroup";allow (all) groupdn = 
"ldap:///cn=manage-my-hostgroup,cn=permissions,cn=pbac,dc

Re: [Freeipa-users] ipa-replica-install fails with python import error for module ssl_match_hostname

[White Hat]

The exact same error is in the /var/log/ipareplica-install log

Here are the last few relevant lines.

  File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py",
line 28, in 
from backports.ssl_match_hostname import match_hostname

2016-08-11T03:53:02Z DEBUG The ipa-replica-install command failed,
exception: ImportError: No module named ssl_match_hostname
2016-08-11T03:53:02Z ERROR No module named ssl_match_hostname
[root@lcars log]#



On Thu, Aug 11, 2016 at 10:51 AM, Rob Crittenden  wrote:
> White Hat wrote:
>>
>> When attempting to run ipa-replica-install I get a python error, No
>> module named ssl_match_hostname
>>
>>
>> This is on a CentOS 7.2 x86_64 testing box.
>>
>> All available updates including kernel installed, and system rebooted
>> same day. Same error before and after patching and reboot.
>>
>> Let me know if you want to see the yum history log info.
>>
>> - Operating system version
>> [root@lcars site-packages]# cat /etc/redhat-release
>> CentOS Linux release 7.2.1511 (Core)
>>
>> [root@lcars site-packages]# uname -a
>> Linux lcars.internal.madisonrentals.biz 3.10.0-327.28.2.el7.x86_64 #1
>> SMP Wed Aug 3 11:11:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> - Here are the installed packages.  All were installed using yum.
>> [root@lcars site-packages]# yum list installed | awk '/backports|ipa-/'
>> ipa-admintools.x86_64  4.2.0-15.0.1.el7.centos.18
>> @updates
>> ipa-client.x86_64  4.2.0-15.0.1.el7.centos.18
>> @updates
>> ipa-python.x86_64  4.2.0-15.0.1.el7.centos.18
>> @updates
>> ipa-server.x86_64  4.2.0-15.0.1.el7.centos.18
>> @updates
>> ipa-server-dns.x86_64  4.2.0-15.0.1.el7.centos.18
>> @updates
>> python-backports.noarch1.0-6.el7
>> @anaconda
>> python-backports.x86_641.0-8.el7
>> installed
>> python-backports-ssl_match_hostname.noarch
>>
>> I have the following repositories enabled:
>> base/7/x86_64
>> epel/x86_64
>> extras/7/x86_64
>> updates/7/x86_64
>>
>> - Other threads on this issue suggest using pip to install
>> backports.ssl_match_hostname.  I still get the same error after doing
>> that.
>>
>> [root@lcars site-packages]# pip install backports.ssl_match_hostname
>> Requirement already satisfied (use --upgrade to upgrade):
>> backports.ssl_match_hostname in /usr/lib/python2.7/site-packages
>>
>> [root@lcars site-packages]# pip install --upgrade
>> backports.ssl_match_hostname
>> Requirement already up-to-date: backports.ssl_match_hostname in
>> /usr/lib/python2.7/site-packages
>>
>> - Here's the actual attempt
>> [root@lcars site-packages]# ipa-replica-install --setup-ca --setup-dns
>> --forwarder=4.2.2.1
>> /root/replica-info-lcars.internal.madisonrentals.biz.gpg
>> WARNING: conflicting time&date synchronization service 'chronyd' will
>> be disabled in favor of ntpd
>>
>> Directory Manager (existing master) password:
>>
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> ipa.ipapython.install.cli.install_tool(Replica): ERRORNo module
>> named ssl_match_hostname
>>
>> Even when running the suggested ipa-server-install --uninstall, I
>> still receive the error about the missing module.
>>
>> Here's what I have in /usr/lib/python2.7/site-packages
>>
>> [root@lcars site-packages]# pwd
>> /usr/lib/python2.7/site-packages
>> [root@lcars site-packages]# ls | awk '/backports.ssl/'
>> backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info
>> backports.ssl_match_hostname-3.5.0.1-py2.7.egg-info
>>
>> - And here are the contents of each directory.
>> [root@lcars site-packages]# cd
>> backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info/
>>
>> [root@lcars backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info]# ls
>> dependency_links.txt  PKG-INFO  SOURCES.txt  top_level.txt
>>
>> [root@lcars backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info]# cd ..
>> [root@lcars site-packages]# ls
>> backports.ssl_match_hostname-3.5.0.1-py2.7.egg-info
>> dependency_links.txt  installed-files.txt  PKG-INFO  SOURCES.txt
>> top_level.txt
>>
>> Another thread suggested that this can be caused by a missing
>> __init__.py file, however, creating this file in both directories
>> doesn't help.
>>
>> A commit by Heimes may shed some light on this.
>> The commit is in regards to otptoken and states that:
>>
>> "The otptoken plugin is the only module in FreeIPA that uses Python's ssl
>> module instead of NSS. The patch replaces ssl with NSSConnection. It
>> uses the default NSS database to lookup trust anchors. NSSConnection
>> uses NSS for hostname matching. The package
>> python-backports-ssl_match_hostname is no longer required."
>>
>> The master IPA server is up and running with no issues.
>>
>> An ipa connection between replica server and master reports that the
>> connection is working.
>>
>> What else could I be missing?
>
>
> Is there a more complete traceback in /var/log/ipareplica-install? I'm
> curious wher

[Freeipa-users] Permission not working as expected

[Deepak Dimri]

Hi All,
I have created below permission for my "testhostgroup" with the expectation 
that this permission will only allow write permission to the members of 
"testhostgroup" but, then it allows me to add/delete other hostgroup members as 
well. I tried changing the effective attribute to "memberof" instead of 
"member" but in vain as with that i started getting permission denied error 
even on  testhostgroup itself.
*







ipa permission-add 'testhostgroup-modify' --permission=write --attrs=member 
--filter='(&(cn=testhostgroup)(objectclass=ipahostgroup ))'
--
Added permission "testhostgroup-modify"
--
  Permission name: testhostgroup-modify
  Granted rights: write
  Effective attributes: member
  Bind rule type: permission
  Subtree: dc=us-west-2,dc=compute,dc=amazonaws,dc=com
  Extra target filter: (&(cn= testhostgroup)(objectclass=ipahostgroup ))**
How can i restrict permissions to manage only those hosts which are part of a 
particular hostgroup? any help you could offer on this would be much 
appreciated. I could not find much on similar issue in the forum :(
Thanks,Deepak -- 
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/29/2016 12:48 PM, Ian Harding wrote:
>
> On 08/25/2016 03:10 PM, Mark Reynolds wrote:
>>
>> 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
> Sorry about the delay..
>
> [root@freeipa-sea ianh]# rpm -qa | grep 389-ds-base
> 389-ds-base-libs-1.3.4.0-33.el7_2.x86_64
> 389-ds-base-1.3.4.0-33.el7_2.x86_64
Now I'm not sure what is going on.  You are on the latest version of
389-ds-base, and it has the cleanAllRUV fix I was talking about. 
Perhaps the message "Waiting to process all the updates from the deleted
replica..." returned by "ipa-replica-manage list-clean-ruv" is not
accurate/current. 

If there are cleanAllRUV tasks running(and not finishing) there will be
evidence in the Directory Server's errors log.  If there are tasks
running the errors log will tell us exactly what is going on (the
logging is very good).  So if the "clean" task is not working start
tailing the DS errors log(/var/log/dirsrv/slapd-INSTANCE/errors), check
for logging that is prefixed with "CleanAllRUV Task", and you should see
what's really going on.  Please post this logging if you find anything.

Mark

>
>
>>>  It's handcuffed to my CentOS 7 so I don't want to update it
>>> outside the CentOS ecosystem.

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Rich Megginson]

On 08/29/2016 10:53 AM, Rakesh Rajasekharan wrote:

Hi Thierry,

My machine has 30GB RAM ..and  389-ds version is 1.3.4

ldapsearch shows the values for nsslapd-cachememsize updated to 200MB.

ldapsearch -LLL -o ldif-wrap=no -D "cn=directory manager" -w 
'mypassword' -b 'cn=userRoot,cn=ldbm 
database,cn=plugins,cn=config'|grep nsslapd-cachememsize

nsslapd-cachememsize: 209715200


So, it seems to have updated though seeing that warning(WARNING: 
ipaca: entry cache size 10485760B is less than db size 11599872B) in 
the log confuses me a bit.


Thers one more entry that I found from the ldapsearch to be bit low

nsslapd-dncachememsize: 10485760
maxdncachesize: 10485760

Should I update these as well to a higher value

At the time when the issue happened, the memory usage as well as the 
overall load of the system was very low .
I will try reproducing the issue atleast in my QA env..probably by 
trying to mock  simultaneous parallel logins to a large number of hosts


To monitor your cache sizes, please use the dbmon.sh tool provided with 
your distro.  If that is not available with your particular distro, see 
https://github.com/richm/scripts/wiki/dbmon.sh





thanks
Rakesh




On Mon, Aug 29, 2016 at 8:16 PM, thierry bordaz > wrote:


Hi Rakesh,

Those tuning may depend on the memory available on your machine.
nsslapd-cachememsize allows the entry cache to consume up to 200Mb
but its memory footprint is known to go above.
200Mb both looks pretty good to me. How large is your machine ?
What is your version of 389-ds ?

Those warnings do not change your settings. It just raise that
entry cache of 'ipaca' and 'retrocl' are small but it is fine. The
size of the entry cache is important mostly in userRoot.
You may double check the actual values, after restart, with
ldapsearch on 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
and 'cn=config,cn=ldbm database,cn=plugins,cn=config'.

A step is to know what will be response time of DS to know if it
is responsible of the hang or not.
The logs and possibly pstack during those intermittent hangs will
help to determine that.

regards
thierry





On 08/29/2016 04:25 PM, Rakesh Rajasekharan wrote:

I tried increasing the nsslapd-dbcachesize and
nsslapd-cachememsize in my QA envs to 200MB.

However, in my log files, I still see this message
[29/Aug/2016:04:34:37 +] - WARNING: ipaca: entry cache size
10485760B is less than db size 11599872B; We recommend to
increase the entry cache size nsslapd-cachememsize.
[29/Aug/2016:04:34:37 +] - WARNING: changelog: entry cache
size 2097152B is less than db size 441647104B; We recommend to
increase the entry cache size nsslapd-cachememsize.

these are my ldif files that i used to modify the values
modify entry cache size
cat modify-cache-mem-size.ldif
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 209715200

modify db cache size
cat modfy-db-cache-size.ldif
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 209715200

After modifying , i restarted IPA services

Is there anything else that  I need to take care of as the logs
suggest its still not getting the updated values

Thanks
Rakesh

On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan
mailto:rakesh.rajasekha...@gmail.com>> wrote:

Hi Thierry,

Coz of the issues we had to revert back to earlier running
openldap in production.

I have now done a few TCP related changes in sysctl.conf and
have also increased the nsslapd-dbcachesize and
nsslapd-cachememsize to 200MB

I will again start migrating hosts back to IPA and see if I
face the earlier issue.

I will update back once I have something


Thanks,
Rakesh



On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz
mailto:tbor...@redhat.com>> wrote:



On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:

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.


   

Re: [Freeipa-users] Delegated Administration in IPA

[Deepak Dimri]

**adding FreeIPA-Users***




Hi Alexander,
I was referring to you below reply regarding managing the access ( adding and 
deleting etc) for only those hosts which are part of a particular hostgroup - 
you mentioned i can do that using "additional target filter based on the 
hostgroup membership." in the freeIPA permission. What would be the 
attribute/DN i should be giving in the target filter to achieve this?
obviously default host group membership allow the admin to add and delete any 
hosts. Which i dont want. I want management restricted to only those host which 
are part of the hostgroup
Thanks in advance
Best Regards,Deepak


> Date: Mon, 8 Aug 2016 11:54:23 +0300
> From: aboko...@redhat.com
> To: deepak_di...@hotmail.com
> CC: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Delegated Administration in IPA
> 
> On Mon, 08 Aug 2016, Deepak Dimri wrote:
> >Hi List,
> >I want some help here! i have 100 of linux servers and ec2 instances
> >used by various teams/departments.   I want to have group wise
> >clubbing of these servers so that i can delegate administration access
> >to manager of  that particular group. For example lets say out of those
> >100 servers, 25 servers belongs to engineering team so i want to
> >register these 25 servers under engineering group/domain and then
> >assign the full administration access to engineering manager to manage
> >these 25 servers and there accesses.  I am getting a sense that we can
> >create DNS subdomains for each team i.e. engineering. >name> and then register those 25 servers under engineering. >domain name> but then i am not sure how i can assign the access and do
> >rest of the configurations.  I would be thankfully if any of you can
> >provide with configuration steps to help me
> What kind of administration do you want to achieve?
> 
> - Managing IPA objects themselves?
> - Managing actual machines as in login to them, run sudo, etc?
> 
> For the former you'd need to learn how to deal with
> permissions/privileges/roles and create separate
> permissions/privileges/roles that look like a default one with
> additional target filter based on the hostgroup membership.
> 
> For the latter you'd use HBAC rules.
> 
> -- 
> / 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] Cleaning Up an Unholy Mess

[Ian Harding]

On 08/25/2016 03:10 PM, Mark Reynolds wrote:
> 
> 
> 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

Sorry about the delay..

[root@freeipa-sea ianh]# rpm -qa | grep 389-ds-base
389-ds-base-libs-1.3.4.0-33.el7_2.x86_64
389-ds-base-1.3.4.0-33.el7_2.x86_64


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

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Rakesh Rajasekharan]

Hi Thierry,

My machine has 30GB RAM ..and  389-ds version is 1.3.4

ldapsearch shows the values for nsslapd-cachememsize updated to 200MB.

ldapsearch -LLL -o ldif-wrap=no -D "cn=directory manager" -w 'mypassword'
-b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config'|grep
nsslapd-cachememsize
nsslapd-cachememsize: 209715200


So, it seems to have updated though seeing that warning(WARNING: ipaca:
entry cache size 10485760B is less than db size 11599872B) in the log
confuses me a bit.

Thers one more entry that I found from the ldapsearch to be bit low

nsslapd-dncachememsize: 10485760
maxdncachesize: 10485760

Should I update these as well to a higher value

At the time when the issue happened, the memory usage as well as the
overall load of the system was very low .
I will try reproducing the issue atleast in my QA env..probably by trying
to mock  simultaneous parallel logins to a large number of hosts


thanks
Rakesh




On Mon, Aug 29, 2016 at 8:16 PM, thierry bordaz  wrote:

> Hi Rakesh,
>
> Those tuning may depend on the memory available on your machine.
> nsslapd-cachememsize allows the entry cache to consume up to 200Mb but its
> memory footprint is known to go above.
> 200Mb both looks pretty good to me. How large is your machine ? What is
> your version of 389-ds ?
>
> Those warnings do not change your settings. It just raise that entry cache
> of 'ipaca' and 'retrocl' are small but it is fine. The size of the entry
> cache is important mostly in userRoot.
> You may double check the actual values, after restart, with ldapsearch on
> 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' and 'cn=config,cn=ldbm
> database,cn=plugins,cn=config'.
>
> A step is to know what will be response time of DS to know if it is
> responsible of the hang or not.
> The logs and possibly pstack during those intermittent hangs will help to
> determine that.
>
> regards
> thierry
>
>
>
>
>
> On 08/29/2016 04:25 PM, Rakesh Rajasekharan wrote:
>
> I tried increasing the nsslapd-dbcachesize and nsslapd-cachememsize in my
> QA envs to 200MB.
>
> However, in my log files, I still see this message
> [29/Aug/2016:04:34:37 +] - WARNING: ipaca: entry cache size 10485760B
> is less than db size 11599872B; We recommend to increase the entry cache
> size nsslapd-cachememsize.
> [29/Aug/2016:04:34:37 +] - WARNING: changelog: entry cache size
> 2097152B is less than db size 441647104B; We recommend to increase the
> entry cache size nsslapd-cachememsize.
>
> these are my ldif files that i used to modify the values
> modify entry cache size
> cat modify-cache-mem-size.ldif
> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 209715200
>
> modify db cache size
> cat modfy-db-cache-size.ldif
> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-dbcachesize
> nsslapd-dbcachesize: 209715200
>
> After modifying , i restarted IPA services
>
> Is there anything else that  I need to take care of as the logs suggest
> its still not getting the updated values
>
> Thanks
> Rakesh
>
> On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
>
>> Hi Thierry,
>>
>> Coz of the issues we had to revert back to earlier running openldap in
>> production.
>>
>> I have now done a few TCP related changes in sysctl.conf and have also
>> increased the nsslapd-dbcachesize and nsslapd-cachememsize to 200MB
>>
>> I will again start migrating hosts back to IPA and see if I face the
>> earlier issue.
>>
>> I will update back once I have something
>>
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>> On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz < 
>> tbor...@redhat.com> wrote:
>>
>>>
>>>
>>> On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:
>>>
>>> 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 < 
>>> pspa...@redhat.com> 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

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[thierry bordaz]

Hi Rakesh,

Those tuning may depend on the memory available on your machine.
nsslapd-cachememsize allows the entry cache to consume up to 200Mb but 
its memory footprint is known to go above.
200Mb both looks pretty good to me. How large is your machine ? What is 
your version of 389-ds ?


Those warnings do not change your settings. It just raise that entry 
cache of 'ipaca' and 'retrocl' are small but it is fine. The size of the 
entry cache is important mostly in userRoot.
You may double check the actual values, after restart, with ldapsearch 
on 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' and 
'cn=config,cn=ldbm database,cn=plugins,cn=config'.


A step is to know what will be response time of DS to know if it is 
responsible of the hang or not.
The logs and possibly pstack during those intermittent hangs will help 
to determine that.


regards
thierry




On 08/29/2016 04:25 PM, Rakesh Rajasekharan wrote:
I tried increasing the nsslapd-dbcachesize and nsslapd-cachememsize in 
my QA envs to 200MB.


However, in my log files, I still see this message
[29/Aug/2016:04:34:37 +] - WARNING: ipaca: entry cache size 
10485760B is less than db size 11599872B; We recommend to increase the 
entry cache size nsslapd-cachememsize.
[29/Aug/2016:04:34:37 +] - WARNING: changelog: entry cache size 
2097152B is less than db size 441647104B; We recommend to increase the 
entry cache size nsslapd-cachememsize.


these are my ldif files that i used to modify the values
modify entry cache size
cat modify-cache-mem-size.ldif
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 209715200

modify db cache size
cat modfy-db-cache-size.ldif
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 209715200

After modifying , i restarted IPA services

Is there anything else that  I need to take care of as the logs 
suggest its still not getting the updated values


Thanks
Rakesh

On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan 
mailto:rakesh.rajasekha...@gmail.com>> 
wrote:


Hi Thierry,

Coz of the issues we had to revert back to earlier running
openldap in production.

I have now done a few TCP related changes in sysctl.conf and have
also increased the nsslapd-dbcachesize and nsslapd-cachememsize to
200MB

I will again start migrating hosts back to IPA and see if I face
the earlier issue.

I will update back once I have something


Thanks,
Rakesh



On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz
mailto:tbor...@redhat.com>> wrote:



On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:

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
mailto:pspa...@redhat.com>> 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

  

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Rakesh Rajasekharan]

I tried increasing the nsslapd-dbcachesize and nsslapd-cachememsize in my
QA envs to 200MB.

However, in my log files, I still see this message
[29/Aug/2016:04:34:37 +] - WARNING: ipaca: entry cache size 10485760B
is less than db size 11599872B; We recommend to increase the entry cache
size nsslapd-cachememsize.
[29/Aug/2016:04:34:37 +] - WARNING: changelog: entry cache size
2097152B is less than db size 441647104B; We recommend to increase the
entry cache size nsslapd-cachememsize.

these are my ldif files that i used to modify the values
modify entry cache size
cat modify-cache-mem-size.ldif
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 209715200

modify db cache size
cat modfy-db-cache-size.ldif
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 209715200

After modifying , i restarted IPA services

Is there anything else that  I need to take care of as the logs suggest its
still not getting the updated values

Thanks
Rakesh

On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan <
rakesh.rajasekha...@gmail.com> wrote:

> Hi Thierry,
>
> Coz of the issues we had to revert back to earlier running openldap in
> production.
>
> I have now done a few TCP related changes in sysctl.conf and have also
> increased the nsslapd-dbcachesize and nsslapd-cachememsize to 200MB
>
> I will again start migrating hosts back to IPA and see if I face the
> earlier issue.
>
> I will update back once I have something
>
>
> Thanks,
> Rakesh
>
>
>
> On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz 
> wrote:
>
>>
>>
>> On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:
>>
>> 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)
>>>
>>
>> Hi Rakesh,
>>
>> Having a reproducible test case would you rerun the command above.
>> During its processing you may monitor DS process load (top). If it is
>> high, you may get some pstacks of it.
>> Also would you attach the part of DS access logs taken during the command.
>>
>> regards
>> thierry
>>
>> >
>>>
>>> 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:
>>> >

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Rakesh Rajasekharan]

Hi Thierry,

Coz of the issues we had to revert back to earlier running openldap in
production.

I have now done a few TCP related changes in sysctl.conf and have also
increased the nsslapd-dbcachesize and nsslapd-cachememsize to 200MB

I will again start migrating hosts back to IPA and see if I face the
earlier issue.

I will update back once I have something


Thanks,
Rakesh



On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz  wrote:

>
>
> On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:
>
> 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)
>>
>
> Hi Rakesh,
>
> Having a reproducible test case would you rerun the command above.
> During its processing you may monitor DS process load (top). If it is
> high, you may get some pstacks of it.
> Also would you attach the part of DS access logs taken during the command.
>
> regards
> thierry
>
> >
>>
>> 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
>> 

[Freeipa-users] Delegated administration use case

[Deepak Dimri]

My IPA server has bunch of IPA-clients registered with it, i have done 
department/product wise grouping of my ipa clients and users. Example: for 
business unit1 (BU1) i have "BU1UserGroup" and "BU1HostGroup" similarly  for 
BU2 its "BU2UserGroup" & "BU2HostGroup". Now i  want to have department wise 
delegation administration in such a way that admin of BU1 can manage access for 
the users in "BU1UserGroup" and "BU1HostGroup" and admin of BU2 can manage the 
users and hosts for hosts in "BU2UserGroup" & "BU2HostGroup".  Essentially 
these sub admins should have full access to manage the access privileges for 
users and mange the hosts for their respective department/BU. 
I am still playing with IPA to understand this better but thought of asking you 
if this is a valid user case of IPA server and any pointer how this can be 
achieved would be much appreciated
Thanks,Deepak
  -- 
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] LDAP only seems to allow anonymous access

[Harry Kashouli]

Sorry, I missed adding the mailing list, added now.

Ah, I'll bear that in mind about authentication prior to 4.4. I have 4.3.1
on Fedora 24 right now. I'm using anonymous authentication for now, for my
various situations such as Jira/etc, and it seems to work, and I'll try
again in 4.4 with various GUI apps.

Thanks again for all the help!

-Harry

On 29 August 2016 at 01:59, Alexander Bokovoy  wrote:

> Again, don't answer to me directly, use freeipa-users@ mailing list.
>
> On Mon, 29 Aug 2016, Harry Kashouli wrote:
>
>> Fixed it, and now it looks like I actually get a successful result, and it
>> gives me info on the account. Thanks, I should've guessed that I needed to
>> replace $REALM.
>>
>> Now, even though this works, if I try to connect via a GUI such as LDAP
>> Admin, I can only connect to the database if I use "Simple
>> Authentication",
>> and anonymous. If I switch it to GSS-API and add the admin user, I get an
>> error as follows:
>> "LDAP error! Invalid credentials: SASL(-13): authentication failure:
>> GSSAPI Failure: gss_accept_sec_context"
>>
>> I've tried using the following two options as base, but still no sucess:
>> - dc=outland,dc=zsazouli,dc=com
>> - cn=users,cn=accounts,dc=outland,dc=zsazouli,dc=com
>>
> I don't think it is related to the choice of the base here. You need to
> look into details of your GUI application. 'LDAP Admin' app is running
> on Windows and I don't think it is going to use IPA's credentials -- it
> is rather using Active Directory user's ones. However, we do not support
> GSSAPI authentication as an AD user to LDAP in versions before FreeIPA 4.4.
>
> --
> / 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] LDAP only seems to allow anonymous access

[Alexander Bokovoy]

Don't answer directly, answer to the list.

On Mon, 29 Aug 2016, Harry Kashouli wrote:

Gotcha, updated error below:

$ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,$REALM uid=admin
SASL/GSSAPI authentication started
SASL username: ad...@outland.zsazouli.com
SASL SSF: 56
SASL data security layer installed.
No such object (32)

I know the user exists, cause I see the admin (and my other users) in the
FreeIPA web UI, and kinit gives me a valid ticket

Did you replace $REALM above with the correct value? E.g.

ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=outland,dc=zsazouli,dc=com 
uid=admin

As you can see in the SASL output, the GSSAPI negotiation happened
successfully, the "No such object (32)" answer is LDAP return code which
is most likely due to wrong base used. If no object would exist, you'd
get empty successful result instead.



-Harry

On 29 August 2016 at 01:13, Alexander Bokovoy  wrote:


On Mon, 29 Aug 2016, Harry Kashouli wrote:


This is the error I get:

ldapsearch -LLL GSSAPI -b cn=users,cn=accounts,$REALM uid=admin
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
   additional info: SASL(-4): no mechanism available:

You are using wrong syntax. To specify SASL mechanism, you need to use

-Y option:

ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,$REALM uid=admin


--
/ Alexander Bokovoy



--
/ 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] LDAP only seems to allow anonymous access

[Alexander Bokovoy]

On Mon, 29 Aug 2016, Harry Kashouli wrote:

This is the error I get:

ldapsearch -LLL GSSAPI -b cn=users,cn=accounts,$REALM uid=admin
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
   additional info: SASL(-4): no mechanism available:


You are using wrong syntax. To specify SASL mechanism, you need to use
-Y option:

ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,$REALM uid=admin


--
/ 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] LDAP only seems to allow anonymous access

[Harry Kashouli]

This is the error I get:

ldapsearch -LLL GSSAPI -b cn=users,cn=accounts,$REALM uid=admin
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:

-Harry

On 28 August 2016 at 08:01, Rob Crittenden  wrote:

> Harry Kashouli wrote:
>
>> Hi all,
>>
>> I can only seem to connect clients to my FreeIPA's LDAP if I use the
>> following:
>>   - Simple authentication
>>   - Anonymous login
>>
>> If I try to log in using any user credentials, it will not work. Are
>> both GSS-API and named logins not allowed by default?
>>
>
> Not sure what you mean by named logins but GSSAPI should work fine:
>
> $ kinit test
> $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,$REALM uid=test
> ...
>
> What error(s) are you seeing?
>
> 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] Ubuntu 16.04 released with FreeIPA 4.3.1

[Timo Aaltonen]

On 21.04.2016 22:01, Timo Aaltonen wrote:
>
> ps. Debian unstable will have 4.3.1 once the package has gone through
> the NEW queue because the packaging got split in certain ways

No it did not, because the ftpmaster rejected the upload since it ships
with minified javascript which is not considered modifiable source code.
And the old version has now been removed from Debian because it was
unmaintainable.

So I hope #5639 will be resolved at some point. Note that Debian doesn't
require the javascript to be minified during package build, just that
the source would ship the unminified copy as well.

-- 
t

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