[Freeipa-users] Re: Can't sync a new replica, large db file,

[Mike Johnson via FreeIPA-users]

I should add that I deleted/moved the large DB file as it was on the
single remaining master, with no replication agreements left.

Is it worth asking on the 389-users list as well?

Thanks
Mike

On 14 November 2017 at 16:48, Mike Johnson  wrote:
> Pastebin for dirsrv/errors log file during/after failed join --
> https://pastebin.com/gJR1SZWZ
>
> On 14 November 2017 at 16:40, Mike Johnson  wrote:
>> Ludwig, thank you for the prompt, helpful reply.
>>
>> I've deleted the stale replication agreements, cleaned the dangling
>> RUVs and renamed the huge file.  It recreated the file but it's
>> nowhere near as big as it was.
>>
>> Now, on the second issue, it doesn't appear to be listening on port 636.
>>
>> The steps I'm following are, broadly:
>>
>> yum install ipa-server
>> ipa-replica-install ./replica-info-id5.prod.mydomain.com.gpg
>>
>> I did not join the replica machine as a client before initiating the
>> replication, I understand this is correct?
>>
>> Presumably the directory starts on the replica during the
>> replica-install process?
>>
>> journalctl on the replica shows many of the following after I try to install:
>> ERR - NSMMReplicationPlugin - replica_replace_ruv_tombstone - Failed
>> to update replication update vector for replica
>> dc=prod,dc=mydomain,dc=com: LDAP error - 1
>>
>> This is the state of things after trying to install the replica:
>> [root@id5 ~]# netstat -ltnp
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address   Foreign Address
>> State   PID/Program name
>> tcp0  0 0.0.0.0:111 0.0.0.0:*
>> LISTEN  1/systemd
>> tcp0  0 0.0.0.0:22  0.0.0.0:*
>> LISTEN  1139/sshd
>> tcp0  0 127.0.0.1:250.0.0.0:*
>> LISTEN  1332/master
>> tcp6   0  0 :::111  :::*
>> LISTEN  1/systemd
>> tcp6   0  0 :::22   :::*
>> LISTEN  1139/sshd
>> tcp6   0  0 ::1:25  :::*
>> LISTEN  1332/master
>> tcp6   0  0 :::389  :::*
>> LISTEN  1964/ns-slapd
>>
>> I note that port 389 is showing as tcp6 but I can see it with v4 from the 
>> master
>>
>> What I have noticed is that the master is very, very slow.  In
>> particular the httpd process running under the ipaapi user is sitting
>> at 100% load most of the time.  I suspect timeouts may be occurring if
>> it's taking a long time for the master to respond to requests.
>>
>> Grateful for any more guidance
>> Mike
>>
>>
>>
>> On 14 November 2017 at 12:23, Ludwig Krispenz via FreeIPA-users
>>  wrote:
>>>
>>> On 11/14/2017 11:40 AM, Mike Johnson via FreeIPA-users wrote:

 Hi

 I've got a small environment which had until recently 2 IPA servers.
 Both CentOS 7.4.1708

 Version info:

 id1:
 Name: ipa-server
 Version : 4.5.0
 Release : 21.el7.centos.2.2
 Kernel: 3.10.0-693.5.2.el7.x86_64
 389-ds-base is at version 1.3.6.1

 id5:
 Name: ipa-server
 Version : 4.5.0
 Release : 21.el7.centos.2.2
 Kernel: 3.10.0-693.5.2.el7.x86_64
 389-ds-base is at version 1.3.6.1

 I recently had an issue with high IO/load, and noted that the following
 file:
 /var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/.db
 was huge (5GB-ish) in a very small 2-master environment.  This is on
 the master.  My understanding is that the entries in this file, which
 have timestamps from months ago, exist because of failed replication.
 I don't understand how to clear this without breaking things.
>>>
>>> looks like you have changelog trimming not enabled, if you enable trimming
>>> now this would reduce the content, but not necessary reduce the file size,
>>> but it would prevent it to grow.
>>> If you stop the server and remove it, it will be recreated. What can happen
>>> then is that required changes to update another replica are missing and repl
>>> will ask you to reinit the other server.
>>>
>>> Now, the second problem should be unrelated. Looks like total init tries to
>>> connect to port 636 and fails, the normal repl session fals because the init
>>> didn't happen. Could you verify that id5 is listening on 636 or if you have
>>> any errors in its error logs.


 Second issue; not sure if related:

 I've since lost the replica (id2) but I've prepared a new machine
 (id5) to be a new replica of id1.  I've cleaned the RUVs and deleted
 the replication agreements but when I join the new machine to the
 existing one using `ipa-replica-install` then I get the following on
 the replica:

 
 Starting replication, please wait until this has completed.
 Update in progress, 10 seconds elapsed
 [ldap://id1.prod.mydomain.com:389] reports: Update failed! Status:
 [-11 connection 

[Freeipa-users] ad trust and external services

[Николай Савельев via FreeIPA-users]

Hi
 I setup zimbra by this docs 
http://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA
I also use AD trust.

But i dont undestand why get all users from freeipa and ad for zimbra

By instructions i getting only ipa users. I can get only AD users.

But I can get it together&

-- 
С уважением, Николай.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] PWM and FreeIPA integration

[Aaron Hicks via FreeIPA-users]

Hello the FreeIPA List,

 

So as using the FreeIPA API and using LDAP directly to set existing users
passwords (because they don't yet have one) didn't work, we've set up PWM by
mostly following this gist:
https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a

 

This has worked, and users with existing passwords can log in an manage
their passwords. We are not using it to create user accounts. However we
have some users who do not have passwords, so they can't provide a current
password to do a password change.

 

We have a page on our customer management system that allows users with no
password to enter a password and this is sent to the PWM REST interface to
set the user's password in FreeIPA. The user is not new, they just have no
password set. There's a couple of thousand of them, so we're really keen on
self service.

 

However when we send a password reset request to the PWM REST with the
setpassword command (using the pwmproxy user credentials) we get the
following response:

 

{"error":true,"errorCode":5027,"errorMessage":"You do not have permission to
perform the requested action."}

 

We've tried making the pwmproxy user a admin, and have giving them
permission to change users passwords with the System: Change User password
permission, however this gives the same response. I'd prefer not to give the
pwmproxy account admin, but we need this to work. We've also tried using the
admin account with the same results, we'd prefer to use an API key but have
not yet managed to authenticate with one.

 

I'm asking here as PWM is recommended by FreeIPA as a suitable 3rd Party
project https://www.freeipa.org/page/Self-Service_Password_Reset

 

I feel we're one step away from making this work. Is there a specific
permission, aci, or other hoop to jump through to allow PWM to set a user's
password?

 

Regards,

 

Aaron Hicks

 

 

 

 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: [Freeipa-devel] FreeIPA wiki: troubleshooting

[Felipe Barreto via FreeIPA-users]

Hi flo,

that's a good idea. +1!

If you need help to move the content to component-specific pages,
please, let me know.

On 11/13/2017 09:45 AM, Florence Blanc-Renaud via FreeIPA-devel wrote:

Hi all,

FreeIPA wiki contains a really long page for Troubleshooting [1], and I 
would like to re-organize the content a little bit differently.


My proposal would be to keep this page as the main access point and only 
store pointers to other pages, organized by component. We can keep the 
existing component structure, ie:

- installation
- directory server
- authentication/kerberos
- AD trusts
- dns
- pki
- administration framework
- web UI
- integration with other software
but I would also add
- certmonger and certificate renewal
- OTP

It would be great if the troubleshooting steps could explicitly define 
which version they apply to (for instance the RA certificate has changed 
location in 4.5).


I see this as a group effort, meaning that anyone planning to add 
information related to troubleshooting could review the section he's 
planning to modify and add details (for instance if the existing 
information is deprecated, or applies only to a specific version etc...)


I can start by moving the content from [1] to component-specific pages, 
for instance http://www.freeipa.org/page/Troubleshooting/Installation if 
you agree with the proposal.


So any thoughts/comments on this?

Flo


[1] http://www.freeipa.org/page/Troubleshooting
___
FreeIPA-devel mailing list -- freeipa-de...@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] RADIUS and FreeIPA

[Andrew Meyer via FreeIPA-users]

After all the emails (thank you for your help) I have most of my Mac OS X 
clients authenticating to FreeIPA over wireless.  Clients running on a 2014 or 
newer 10.12.5 and up won't work.  I suspect this has to do with the TLS 
version.  
Tell me if I'm approaching this the right way.
I am trying to apply a certificate FROM FreeIPA to FreeRADIUS.  I am also 
trying to register the service within FreeIPA but strugglging with some of the 
syntax.
I have been following this:FreeIPA: Giving permissions to service accounts. — 
Firstyear's blog-a-log

  
|  
|   |  
FreeIPA: Giving permissions to service accounts. — Firstyear's blog-a-log
 Firstyear`s blog-a-log  |  |

  |

 

I'm having some trouble adding the privileges and roles:[andrew.meyer@radius01 
~]$ ipa privilege-add-permission 'Radius service' --permission='Radius Service' 
 Privilege name: Radius Service  Description: Privileges needed to allow 
radiusd servers to operate  Failed members:    permission: Radius Service: 
permission not found-Number of permissions added 
0-[andrew.meyer@radius01 ~]$ ipa 
privilege-add-permission 'Radius service' --permission='Radius service'  
Privilege name: Radius Service  Description: Privileges needed to allow radiusd 
servers to operate  Failed members:    permission: Radius service: permission 
not found-Number of permissions added 
0-[andrew.meyer@radius01 ~]$ ipa role-add 'Radius 
server' --desc="Radius server role"--Added role "Radius 
server"--  Role name: Radius server  Description: 
Radius server role[andrew.meyer@radius01 ~]$ ipa role-add-privilege 
--privileges="Radius services" 'Radius server'  Role name: Radius server  
Description: Radius server role  Failed members:    privilege: Radius services: 
privilege not foundNumber of privileges added 
0[andrew.meyer@radius01 ~]$___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA wiki: troubleshooting

[Lukas Slebodnik via FreeIPA-users]

On (13/11/17 12:45), Florence Blanc-Renaud via FreeIPA-users wrote:
>Hi all,
>
>FreeIPA wiki contains a really long page for Troubleshooting [1], and I would
>like to re-organize the content a little bit differently.
>
+1 for the effort.

BTW it might be good to have a section with links to troubleshooting of
"subcomponents" DNS(bind-dyndb-ldap), client(SSSD) ...

LS
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA & wireless

[Andrew Meyer via FreeIPA-users]

For the newer macbooks (High Sierra) how did you get around the TLS 1.2 
requirement?  Did you generate a SSL cert and publish that to the RADIUS server?
 

On Tuesday, November 14, 2017 9:54 AM, Michael Plemmons via FreeIPA-users 
 wrote:
 

 We have a range of OS X versions from 10.10 and newer.   Our RADIUS server 
(running FreeRadius on Linux) is using FreeIPA for the authentication via LDAP. 
  Our WiFi access point is configured to talk to the radius server for 
authentication.



Mike Plemmons | Senior DevOps Engineer | CrossChx
614.427.2411mike.plemm...@crosschx.com
www.crosschx.com 
On Tue, Nov 14, 2017 at 9:47 AM, Andrew Meyer  wrote:

Michael,What version of Mac OS X are your MacBooks running?   10.12.5+?
You are using Windows Server for RADIUS auth correct? 

On Monday, November 13, 2017 2:35 PM, Michael Plemmons via FreeIPA-users 
 wrote:
 

 Our entire office is Macbooks.



Mike Plemmons | Senior DevOps Engineer | CrossChx
614.427.2411mike.plemm...@crosschx.com
www.crosschx.com 
On Mon, Nov 13, 2017 at 3:18 PM, Andrew Meyer  wrote:

Do you have any MacBook users? 

On Monday, November 13, 2017 2:07 PM, Michael Plemmons via FreeIPA-users 
 wrote:
 

 In order for us to make it work, I had to setup a RADIUS (FreeRadius) server 
which uses FreeIPA as its backend.   Our WiFi access point is configured to 
point to the RADIUS server.   I had to make sure the AD trust package was 
installed on the FreeIPA server in order for the proper security features to 
work.   We do not have SSL certs on our machine.



Mike Plemmons | Senior DevOps Engineer | CrossChx
614.427.2411mike.plemm...@crosschx.com
www.crosschx.com 
On Fri, Nov 10, 2017 at 11:07 AM, Andrew Meyer via FreeIPA-users 
 wrote:

So I was wondering if anyone has FreeIPA setup to do authentication with 
wireless.   We have an ArubaNetworks platform setup to do EAP-PEAP only 
communicating back to the current OpenLDAP system, but would like to migrate to 
FreeIPA.     
I was able to set this up using Meraki MR18s but I have to use a WPA2-PSK 
(enterprise) with splash page in order to log into my FreeIPA system.   I don't 
know if I will have to put the password in again I am waiting until tonight to 
test that.
All of our laptops are Mac OS X running El Capitan and a few running High 
Sierra (w/ all of them upgrading eventually).   We have under 5 laptops running 
Windows 7-10 and are mostly hard wired.
The issue is that when I log into wireless using FreeIPA I get prompted for a 
password.   It gets added to the keychain but when I shutdown for the night and 
come back in the next day it asks for the password again the next day.     
While researching this issue I found that some people have put SSL certificates 
on the machines.   I don't want to create and enroll an SSL cert for EACH user. 
  I would like to get system-wide one deployed IF this is the correct way to 
go.     
While this may sound like a ArubaNetworks wireless issue I wanted to pose this 
question to the mailing list just in case there was a step I missed or didn't 
do something that might have been documented somewhere and to see if anyone 
else has had this issue.     
Thank you in advance!
__ _
 FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
 To unsubscribe send an email to freeipa-users-leave@lists. fedorahosted.org
 


__ _
FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists. fedorahosted.org


   

__ _
FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists. fedorahosted.org


   

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


   ___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can't sync a new replica, large db file,

[Mike Johnson via FreeIPA-users]

Pastebin for dirsrv/errors log file during/after failed join --
https://pastebin.com/gJR1SZWZ

On 14 November 2017 at 16:40, Mike Johnson  wrote:
> Ludwig, thank you for the prompt, helpful reply.
>
> I've deleted the stale replication agreements, cleaned the dangling
> RUVs and renamed the huge file.  It recreated the file but it's
> nowhere near as big as it was.
>
> Now, on the second issue, it doesn't appear to be listening on port 636.
>
> The steps I'm following are, broadly:
>
> yum install ipa-server
> ipa-replica-install ./replica-info-id5.prod.mydomain.com.gpg
>
> I did not join the replica machine as a client before initiating the
> replication, I understand this is correct?
>
> Presumably the directory starts on the replica during the
> replica-install process?
>
> journalctl on the replica shows many of the following after I try to install:
> ERR - NSMMReplicationPlugin - replica_replace_ruv_tombstone - Failed
> to update replication update vector for replica
> dc=prod,dc=mydomain,dc=com: LDAP error - 1
>
> This is the state of things after trying to install the replica:
> [root@id5 ~]# netstat -ltnp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address
> State   PID/Program name
> tcp0  0 0.0.0.0:111 0.0.0.0:*
> LISTEN  1/systemd
> tcp0  0 0.0.0.0:22  0.0.0.0:*
> LISTEN  1139/sshd
> tcp0  0 127.0.0.1:250.0.0.0:*
> LISTEN  1332/master
> tcp6   0  0 :::111  :::*
> LISTEN  1/systemd
> tcp6   0  0 :::22   :::*
> LISTEN  1139/sshd
> tcp6   0  0 ::1:25  :::*
> LISTEN  1332/master
> tcp6   0  0 :::389  :::*
> LISTEN  1964/ns-slapd
>
> I note that port 389 is showing as tcp6 but I can see it with v4 from the 
> master
>
> What I have noticed is that the master is very, very slow.  In
> particular the httpd process running under the ipaapi user is sitting
> at 100% load most of the time.  I suspect timeouts may be occurring if
> it's taking a long time for the master to respond to requests.
>
> Grateful for any more guidance
> Mike
>
>
>
> On 14 November 2017 at 12:23, Ludwig Krispenz via FreeIPA-users
>  wrote:
>>
>> On 11/14/2017 11:40 AM, Mike Johnson via FreeIPA-users wrote:
>>>
>>> Hi
>>>
>>> I've got a small environment which had until recently 2 IPA servers.
>>> Both CentOS 7.4.1708
>>>
>>> Version info:
>>>
>>> id1:
>>> Name: ipa-server
>>> Version : 4.5.0
>>> Release : 21.el7.centos.2.2
>>> Kernel: 3.10.0-693.5.2.el7.x86_64
>>> 389-ds-base is at version 1.3.6.1
>>>
>>> id5:
>>> Name: ipa-server
>>> Version : 4.5.0
>>> Release : 21.el7.centos.2.2
>>> Kernel: 3.10.0-693.5.2.el7.x86_64
>>> 389-ds-base is at version 1.3.6.1
>>>
>>> I recently had an issue with high IO/load, and noted that the following
>>> file:
>>> /var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/.db
>>> was huge (5GB-ish) in a very small 2-master environment.  This is on
>>> the master.  My understanding is that the entries in this file, which
>>> have timestamps from months ago, exist because of failed replication.
>>> I don't understand how to clear this without breaking things.
>>
>> looks like you have changelog trimming not enabled, if you enable trimming
>> now this would reduce the content, but not necessary reduce the file size,
>> but it would prevent it to grow.
>> If you stop the server and remove it, it will be recreated. What can happen
>> then is that required changes to update another replica are missing and repl
>> will ask you to reinit the other server.
>>
>> Now, the second problem should be unrelated. Looks like total init tries to
>> connect to port 636 and fails, the normal repl session fals because the init
>> didn't happen. Could you verify that id5 is listening on 636 or if you have
>> any errors in its error logs.
>>>
>>>
>>> Second issue; not sure if related:
>>>
>>> I've since lost the replica (id2) but I've prepared a new machine
>>> (id5) to be a new replica of id1.  I've cleaned the RUVs and deleted
>>> the replication agreements but when I join the new machine to the
>>> existing one using `ipa-replica-install` then I get the following on
>>> the replica:
>>>
>>> 
>>> Starting replication, please wait until this has completed.
>>> Update in progress, 10 seconds elapsed
>>> [ldap://id1.prod.mydomain.com:389] reports: Update failed! Status:
>>> [-11 connection error: Unknown connection error (-11) - Total update
>>> aborted]
>>>
>>>[error] RuntimeError: Failed to start replication
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
>>> ERRORFailed to start replication
>>> 

[Freeipa-users] Re: Can't sync a new replica, large db file,

[Mike Johnson via FreeIPA-users]

Ludwig, thank you for the prompt, helpful reply.

I've deleted the stale replication agreements, cleaned the dangling
RUVs and renamed the huge file.  It recreated the file but it's
nowhere near as big as it was.

Now, on the second issue, it doesn't appear to be listening on port 636.

The steps I'm following are, broadly:

yum install ipa-server
ipa-replica-install ./replica-info-id5.prod.mydomain.com.gpg

I did not join the replica machine as a client before initiating the
replication, I understand this is correct?

Presumably the directory starts on the replica during the
replica-install process?

journalctl on the replica shows many of the following after I try to install:
ERR - NSMMReplicationPlugin - replica_replace_ruv_tombstone - Failed
to update replication update vector for replica
dc=prod,dc=mydomain,dc=com: LDAP error - 1

This is the state of things after trying to install the replica:
[root@id5 ~]# netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address
State   PID/Program name
tcp0  0 0.0.0.0:111 0.0.0.0:*
LISTEN  1/systemd
tcp0  0 0.0.0.0:22  0.0.0.0:*
LISTEN  1139/sshd
tcp0  0 127.0.0.1:250.0.0.0:*
LISTEN  1332/master
tcp6   0  0 :::111  :::*
LISTEN  1/systemd
tcp6   0  0 :::22   :::*
LISTEN  1139/sshd
tcp6   0  0 ::1:25  :::*
LISTEN  1332/master
tcp6   0  0 :::389  :::*
LISTEN  1964/ns-slapd

I note that port 389 is showing as tcp6 but I can see it with v4 from the master

What I have noticed is that the master is very, very slow.  In
particular the httpd process running under the ipaapi user is sitting
at 100% load most of the time.  I suspect timeouts may be occurring if
it's taking a long time for the master to respond to requests.

Grateful for any more guidance
Mike



On 14 November 2017 at 12:23, Ludwig Krispenz via FreeIPA-users
 wrote:
>
> On 11/14/2017 11:40 AM, Mike Johnson via FreeIPA-users wrote:
>>
>> Hi
>>
>> I've got a small environment which had until recently 2 IPA servers.
>> Both CentOS 7.4.1708
>>
>> Version info:
>>
>> id1:
>> Name: ipa-server
>> Version : 4.5.0
>> Release : 21.el7.centos.2.2
>> Kernel: 3.10.0-693.5.2.el7.x86_64
>> 389-ds-base is at version 1.3.6.1
>>
>> id5:
>> Name: ipa-server
>> Version : 4.5.0
>> Release : 21.el7.centos.2.2
>> Kernel: 3.10.0-693.5.2.el7.x86_64
>> 389-ds-base is at version 1.3.6.1
>>
>> I recently had an issue with high IO/load, and noted that the following
>> file:
>> /var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/.db
>> was huge (5GB-ish) in a very small 2-master environment.  This is on
>> the master.  My understanding is that the entries in this file, which
>> have timestamps from months ago, exist because of failed replication.
>> I don't understand how to clear this without breaking things.
>
> looks like you have changelog trimming not enabled, if you enable trimming
> now this would reduce the content, but not necessary reduce the file size,
> but it would prevent it to grow.
> If you stop the server and remove it, it will be recreated. What can happen
> then is that required changes to update another replica are missing and repl
> will ask you to reinit the other server.
>
> Now, the second problem should be unrelated. Looks like total init tries to
> connect to port 636 and fails, the normal repl session fals because the init
> didn't happen. Could you verify that id5 is listening on 636 or if you have
> any errors in its error logs.
>>
>>
>> Second issue; not sure if related:
>>
>> I've since lost the replica (id2) but I've prepared a new machine
>> (id5) to be a new replica of id1.  I've cleaned the RUVs and deleted
>> the replication agreements but when I join the new machine to the
>> existing one using `ipa-replica-install` then I get the following on
>> the replica:
>>
>> 
>> Starting replication, please wait until this has completed.
>> Update in progress, 10 seconds elapsed
>> [ldap://id1.prod.mydomain.com:389] reports: Update failed! Status:
>> [-11 connection error: Unknown connection error (-11) - Total update
>> aborted]
>>
>>[error] RuntimeError: Failed to start replication
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
>> ERRORFailed to start replication
>> ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
>> ERRORThe ipa-replica-install command failed. See
>> /var/log/ipareplica-install.log for more information
>> [root@id5 ~]# ipa-replica-manage re-initialize --from
>> id1.prod.mydomain.com
>> Re-run /usr/sbin/ipa-replica-manage with --verbose option to get more
>> information
>> Unexpected error: cannot 

[Freeipa-users] Re: Got RBAC controls for individual AD users sorted; now to allow login based on AD group membership ?

[Alexander Bokovoy via FreeIPA-users]

On ti, 14 marras 2017, Chris Dagdigian via FreeIPA-users wrote:

Hi folks,

Have an AWS footprint that thanks to FreeIPA can talk to a really 
complex remote AD forest with lots of transitive trusts and child 
domains. Would not be possible without FreeIPA in the mix.


So far we've only really been required to grant admin/sudo access and 
we've done that individually with role based user and hostgroups


I'm comfortable with bringing an AD user into the fold:

1. Make a non-posix group in FreeIPA to hold the AD usernames
2. Make a second group of type=POSIX that inherits members from the 
external non-posix group

3. Implement RBAC controls and rules via the posix group
4. magic!

Now I need to globally allow SSH and possibly other PAM service access 
based on pre-existing AD group membership


Looking for guidance or URLs on how to manage RBAC controls based on 
AD group rather than AD username.


Is it roughly the same (or exactly the same? )

- Make non-posix group that references the AD group in FreeIPA
- Make POSIX group in FreeIPA that inherits members of the non-posix group
- Implement RBAC rules?

Correct. It is exactly the same.



Any tips or cheatsheets for allowing RBAC controls based on groups 
that exist in AD would be appreciated. thanks!

You just listed it above. Remember that 'external members' of non-POSIX
group in freeIPA are just SIDs. Since on AD side any SID that can be
part of a Kerberos ticket's MS-PAC structure can be used for security
controls, any SID mentioned as an 'external member' of such non-POSIX
group in IPA (which is a member of some POSIX group in IPA) can be used
to control membership in that POSIX group, and thus HBAC/SUDO rules.

It is a bit of a magic but a magic that was carefully designed this way.


Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA & wireless

[Michael Plemmons via FreeIPA-users]

We have a range of OS X versions from 10.10 and newer.   Our RADIUS server
(running FreeRadius on Linux) is using FreeIPA for the authentication via
LDAP.   Our WiFi access point is configured to talk to the radius server
for authentication.




*Mike Plemmons | Senior DevOps Engineer | CrossChx*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Tue, Nov 14, 2017 at 9:47 AM, Andrew Meyer  wrote:

> Michael,
> What version of Mac OS X are your MacBooks running?   10.12.5+?
>
> You are using Windows Server for RADIUS auth correct?
>
>
> On Monday, November 13, 2017 2:35 PM, Michael Plemmons via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>
> Our entire office is Macbooks.
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CrossChx*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Mon, Nov 13, 2017 at 3:18 PM, Andrew Meyer 
> wrote:
>
> Do you have any MacBook users?
>
>
> On Monday, November 13, 2017 2:07 PM, Michael Plemmons via FreeIPA-users 
>  fedorahosted.org > wrote:
>
>
> In order for us to make it work, I had to setup a RADIUS (FreeRadius)
> server which uses FreeIPA as its backend.   Our WiFi access point is
> configured to point to the RADIUS server.   I had to make sure the AD trust
> package was installed on the FreeIPA server in order for the proper
> security features to work.   We do not have SSL certs on our machine.
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CrossChx*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Fri, Nov 10, 2017 at 11:07 AM, Andrew Meyer via FreeIPA-users 
>  fedorahosted.org > wrote:
>
> So I was wondering if anyone has FreeIPA setup to do authentication with
> wireless.   We have an ArubaNetworks platform setup to do EAP-PEAP only
> communicating back to the current OpenLDAP system, but would like to
> migrate to FreeIPA.
>
> I was able to set this up using Meraki MR18s but I have to use a WPA2-PSK
> (enterprise) with splash page in order to log into my FreeIPA system.   I
> don't know if I will have to put the password in again I am waiting until
> tonight to test that.
>
> All of our laptops are Mac OS X running El Capitan and a few running High
> Sierra (w/ all of them upgrading eventually).   We have under 5 laptops
> running Windows 7-10 and are mostly hard wired.
>
> The issue is that when I log into wireless using FreeIPA I get prompted
> for a password.   It gets added to the keychain but when I shutdown for the
> night and come back in the next day it asks for the password again the next
> day.
>
> While researching this issue I found that some people have put SSL
> certificates on the machines.   I don't want to create and enroll an SSL
> cert for EACH user.   I would like to get system-wide one deployed IF this
> is the correct way to go.
>
> While this may sound like a ArubaNetworks wireless issue I wanted to pose
> this question to the mailing list just in case there was a step I missed or
> didn't do something that might have been documented somewhere and to see if
> anyone else has had this issue.
>
> Thank you in advance!
>
> __ _
> FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
> 
> To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org 
>
>
> __ _
> FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
> 
> To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org 
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Got RBAC controls for individual AD users sorted; now to allow login based on AD group membership ?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Have an AWS footprint that thanks to FreeIPA can talk to a really 
complex remote AD forest with lots of transitive trusts and child 
domains. Would not be possible without FreeIPA in the mix.


So far we've only really been required to grant admin/sudo access and 
we've done that individually with role based user and hostgroups


I'm comfortable with bringing an AD user into the fold:

1. Make a non-posix group in FreeIPA to hold the AD usernames
2. Make a second group of type=POSIX that inherits members from the 
external non-posix group

3. Implement RBAC controls and rules via the posix group
4. magic!

Now I need to globally allow SSH and possibly other PAM service access 
based on pre-existing AD group membership


Looking for guidance or URLs on how to manage RBAC controls based on AD 
group rather than AD username.


Is it roughly the same (or exactly the same? )

- Make non-posix group that references the AD group in FreeIPA
- Make POSIX group in FreeIPA that inherits members of the non-posix group
- Implement RBAC rules?

Any tips or cheatsheets for allowing RBAC controls based on groups that 
exist in AD would be appreciated. thanks!


Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: freeipa trust issues

[Alexander Bokovoy via FreeIPA-users]

On ti, 14 marras 2017, Zach Bayne wrote:

trust add completes and logs attached.
appreciate the help

Zach, I'd suggest you to re-establish trust again, to re-generate
cross-forest trust object passwords which you made public by posting
link to logs to the list.

Anyway, the trust itself seems to get established just fine. What failed
is an attempt to login as AD user to Web UI. Am I correct?

If so, then you need first to enable each AD user to login by creating
(even empty) ID override for this user in the default trust view:

ipa idoverrideuser-add 'Default Trust View' foo@ad.domain

this would create an empty ID override that should allow foo@ad.domain
to authenticate to IPA LDAP server with GSSAPI. This is exactly what Web
UI needs because it always uses GSSAPI to authenticate to LDAP on behalf
of users trying to login to it.


On Mon, Nov 13, 2017 at 3:01 PM, Alexander Bokovoy 
wrote:


On ma, 13 marras 2017, Zach Bayne via FreeIPA-users wrote:


I have active directory as dc1.ad.domainname and dc2.ad.domainname
I also have freeipa at ipa1.ipa.domainname and ipa2.ipa.domainname
both of them seem to work fine independently, I then created a trust and
set smb min and max to 2. from the server 2k12 side  the trust validates
and from the ipa side i can kinit user@ad.domainname but thats where the
working ends. I can not login to webinterface as ad it says my session has
expired and to relogin. wbinfo status shows ad as offline
both ldap dns records for ipa and ad look correct
[root@ipa1 ~]# wbinfo -n 'AD\Domain Admins'
failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
Could not lookup name AD\Domain Admins


[root@ipa1 ~]# ipa --version
VERSION: 4.5.0, API_VERSION: 2.228

[root@ipa1 ~]# sssd --version
1.15.2
attached below is the log.wd.ad
I am happy to provide any more information and thank anyone who can help
me
solve this, have been beaten up for a bit on it.


Forget about looking into Samba logs alone. They aren't relevant here.
IPA uses SSSD to look up users/groups, not winbindd. Winbindd is used by
Samba itself for topology details and not for user lookups. It is
expected to see wbinfo reporting "offline" state because it is not
relevant at all.

See
https://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
and provide information requested there.

--
/ Alexander Bokovoy



--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Listing groups in FreeIPA

[Kristian Petersen via FreeIPA-users]

Thanks!  I somehow missed that the group wasn't required.

On Fri, Nov 10, 2017 at 11:33 AM, Rob Crittenden 
wrote:

> Kristian Petersen via FreeIPA-users wrote:
> > I did that before sending my initial email.  The command group_find()
> > only appears to look for the group name that you tell it to search for.
> > I am looking for something that will give me a list of every group in
> > IPA without knowing their names.  None of the group functions seem to
> > provide this functionality.  I was hoping there was some other way of
> > exporting a list of all of them from the server.
>
> You just don't pass it a positional argument.
>
> {u'params': [[], {u'version': u'2.215'}], u'method': u'group_find',
> u'id': 0}
>
> You can see the API in action with: ipa -vvv 
>
> Note that there is no guarantee that this will return all groups. There
> are still search limits both in IPA and within 389-ds. The cap IIRC in
> LDAP is 2000 entries.
>
> rob
>
> >
> > On Fri, Nov 10, 2017 at 1:37 AM, Florence Blanc-Renaud  > > wrote:
> >
> > On 11/09/2017 08:10 PM, Kristian Petersen via FreeIPA-users wrote:
> >
> > Hey all,
> >
> > Is there a way to get a list of all of the groups in FreeIPA
> > using the python API?
> >
> > --
> > Kristian Petersen
> > System Administrator
> > Dept. of Chemistry and Biochemistry
> >
> >
> > ___
> > FreeIPA-users mailing list --
> > freeipa-users@lists.fedorahosted.org
> > 
> > To unsubscribe send an email to
> > freeipa-users-le...@lists.fedorahosted.org
> > 
> >
> >
> > Hi,
> >
> > you can find all the commands provided by the API using the web GUI:
> > - login to https://server.domain.com/ipa/ui
> > 
> > - navigate to IPA Server > API Browser
> > From there you will be able to search for commands related to
> > "group" and group_find may be the one you are interested in.
> > The API browser will show you the arguments and options for each
> > command.
> >
> > HTH,
> > Flo
> >
> >
> >
> >
> > --
> > Kristian Petersen
> > System Administrator
> > Dept. of Chemistry and Biochemistry
> >
> >
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
> >
>
>


-- 
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA & wireless

[Andrew Meyer via FreeIPA-users]

Michael,What version of Mac OS X are your MacBooks running?  10.12.5+?
You are using Windows Server for RADIUS auth correct? 

On Monday, November 13, 2017 2:35 PM, Michael Plemmons via FreeIPA-users 
 wrote:
 

 Our entire office is Macbooks.



Mike Plemmons | Senior DevOps Engineer | CrossChx
614.427.2411mike.plemm...@crosschx.com
www.crosschx.com 
On Mon, Nov 13, 2017 at 3:18 PM, Andrew Meyer  wrote:

Do you have any MacBook users? 

On Monday, November 13, 2017 2:07 PM, Michael Plemmons via FreeIPA-users 
 wrote:
 

 In order for us to make it work, I had to setup a RADIUS (FreeRadius) server 
which uses FreeIPA as its backend.   Our WiFi access point is configured to 
point to the RADIUS server.   I had to make sure the AD trust package was 
installed on the FreeIPA server in order for the proper security features to 
work.   We do not have SSL certs on our machine.



Mike Plemmons | Senior DevOps Engineer | CrossChx
614.427.2411mike.plemm...@crosschx.com
www.crosschx.com 
On Fri, Nov 10, 2017 at 11:07 AM, Andrew Meyer via FreeIPA-users 
 wrote:

So I was wondering if anyone has FreeIPA setup to do authentication with 
wireless.   We have an ArubaNetworks platform setup to do EAP-PEAP only 
communicating back to the current OpenLDAP system, but would like to migrate to 
FreeIPA.     
I was able to set this up using Meraki MR18s but I have to use a WPA2-PSK 
(enterprise) with splash page in order to log into my FreeIPA system.   I don't 
know if I will have to put the password in again I am waiting until tonight to 
test that.
All of our laptops are Mac OS X running El Capitan and a few running High 
Sierra (w/ all of them upgrading eventually).   We have under 5 laptops running 
Windows 7-10 and are mostly hard wired.
The issue is that when I log into wireless using FreeIPA I get prompted for a 
password.   It gets added to the keychain but when I shutdown for the night and 
come back in the next day it asks for the password again the next day.     
While researching this issue I found that some people have put SSL certificates 
on the machines.   I don't want to create and enroll an SSL cert for EACH user. 
  I would like to get system-wide one deployed IF this is the correct way to 
go.     
While this may sound like a ArubaNetworks wireless issue I wanted to pose this 
question to the mailing list just in case there was a step I missed or didn't 
do something that might have been documented somewhere and to see if anyone 
else has had this issue.     
Thank you in advance!
__ _
 FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
 To unsubscribe send an email to freeipa-users-leave@lists. fedorahosted.org
 


__ _
FreeIPA-users mailing list -- freeipa-users@lists. fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists. fedorahosted.org


   

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


   ___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: freeipa trust issues

[Zach Bayne via FreeIPA-users]

trust add completes and logs attached.
appreciate the help
https://drive.google.com/open?id=1SwiAaQkq4PttVaGNUBS_DoVP12Z53kZM

--
Golden Dog Development
z...@goldendogdev.net
636/395-0804
http://goldendogdev.net
--
All messages should be signed
27D1 C230 E66F BEF6 9697
D40E 2A04 2009 B9BD 15C5
27D1 C230 E66F BEF6 9697
D40E 2A04 2009 B9BD 15C5

On Mon, Nov 13, 2017 at 3:01 PM, Alexander Bokovoy 
wrote:

> On ma, 13 marras 2017, Zach Bayne via FreeIPA-users wrote:
>
>> I have active directory as dc1.ad.domainname and dc2.ad.domainname
>> I also have freeipa at ipa1.ipa.domainname and ipa2.ipa.domainname
>> both of them seem to work fine independently, I then created a trust and
>> set smb min and max to 2. from the server 2k12 side  the trust validates
>> and from the ipa side i can kinit user@ad.domainname but thats where the
>> working ends. I can not login to webinterface as ad it says my session has
>> expired and to relogin. wbinfo status shows ad as offline
>> both ldap dns records for ipa and ad look correct
>> [root@ipa1 ~]# wbinfo -n 'AD\Domain Admins'
>> failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
>> Could not lookup name AD\Domain Admins
>>
>>
>> [root@ipa1 ~]# ipa --version
>> VERSION: 4.5.0, API_VERSION: 2.228
>>
>> [root@ipa1 ~]# sssd --version
>> 1.15.2
>> attached below is the log.wd.ad
>> I am happy to provide any more information and thank anyone who can help
>> me
>> solve this, have been beaten up for a bit on it.
>>
> Forget about looking into Samba logs alone. They aren't relevant here.
> IPA uses SSSD to look up users/groups, not winbindd. Winbindd is used by
> Samba itself for topology details and not for user lookups. It is
> expected to see wbinfo reporting "offline" state because it is not
> relevant at all.
>
> See
> https://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
> and provide information requested there.
>
> --
> / Alexander Bokovoy
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Delete certificates from Dogtag PKI

[Francois Picot via FreeIPA-users]

Hello Rob, 

Thanks for these answers. It seems to be much worse than I thought : ipa 
host-show shows every certificates issued for the host, and each certificate 
issued has its own request in LDAP (54K entries in ou=ca,ou=requests,o=ipaca)

I believe the correct way would be : 
* Get the serial of currently used cert on each host.  
* For each cert present in LDAP, that has been issued during the loop : 
** Remove it from the host with ipa host-remove-cert (this will revoke the cert)
** Get the requestID and delete the request from LDAP
** Delete the cert from LDAP

Once this is done, the ldap changelog db will likely be huge. From what I see 
in [2], I can reduce nsslapd-changelogmaxage to force the trim, and set 
nsslapd-changelogcompactdb-interval to a low value to force the compaction of 
the db. 

Do you see anything I'm forgetting ? 

Kind regards,
François PICOT 

[2] http://www.port389.org/docs/389ds/FAQ/changelog-trimming.html 


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: lundi 13 novembre 2017 19:28
To: FreeIPA users list 
Cc: Francois Picot 
Subject: Re: [Freeipa-users] Re: Delete certificates from Dogtag PKI

Francois Picot via FreeIPA-users wrote:
> Hello all,
> 
> I'm not sure this is the correct list to post in, but it seems to be more of 
> a PKI issue. I'm wondering if there is a clean/easy way to delete 
> certificates from IPA CA/PKI.  
> 
> For a little context.. One of our systems has an IPA pair, which issues 
> certificates for internal use via dogtag PKI. Two weeks ago, we found that 
> some certificates were renewed without DNS SAN. After a few searches, I found 
> this thread [1] which helped us import the profile into LDAP and everything 
> seemed to go back to normal.
> 
> However, some servers in this system went mad a few days later, and 
> certmonger looped on renewal of some certificates. 
> In /var/log/messages, we can see these two lines repeating every few seconds 
> : 
> Nov  8 14:22:14 srv-01 certmonger: Certificate in file "/etc/httpd/httpd.crt" 
> is no longer valid.
> Nov  8 14:22:14 srv-01 certmonger: Certificate in file "/ etc/httpd/httpd.crt 
> " issued by CA and saved.

Were these cut-n-pasted? The space looks very strange.

> After restarting certmonger, the loop stopped. 
> 
> The problem now is we have 54K certificates in IPA CA. Some hosts have up to 
> 2400 certificates issued. The dirsrv file id2entry.db is 1.3GB. The backup 
> process needs about 8GB to run and produce 3,5GB backups (up from ~100MB). 
> Almost all ipa commands time out because of the huge number of certificates. 
> 
> I would like to avoid revoking the certificates for two reasons : 
> * They are for an exclusively internal use, and I'm absolutely 
> positive that they have not been compromised,
> * It's likely it wouldn't solve the backup size problem. 
> 
> Is there another way than manually deleting them from LDAP ? I couldn't find 
> any command that would simply delete the certs. 
> If not, is it safe to delete them ? 

Normally I'd say no, don't delete the certificates, but given the circumstances 
it may be worthwhile. I'm not sure how much space will be reclaimed when the 
entries are deleted.

You will want to be extremely careful not to delete the current certificate 
associated in IPA unless you also remove that entry. When a new certificate is 
issued in IPA it will try to revoke the current one and if that cert isn't in 
the store it will fail.

The certificates themselves are stored in ou=certificateRepository,ou=ca,o=ipaca

You may also need to look in ou=ca,ou=requests,o=ipaca. I'm guessing that this 
will be a reasonable value since the same CSR should have been used with each 
request.

I can't say that this will be easy. I'd create a list of dns and pass that to 
ldapdelete to do the cleanup.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] freeipa trust issues

[Zach Bayne via FreeIPA-users]

I have active directory as dc1.ad.domainname and dc2.ad.domainname
I also have freeipa at ipa1.ipa.domainname and ipa2.ipa.domainname
both of them seem to work fine independently, I then created a trust and
set smb min and max to 2. from the server 2k12 side  the trust validates
and from the ipa side i can kinit user@ad.domainname but thats where the
working ends. I can not login to webinterface as ad it says my session has
expired and to relogin. wbinfo status shows ad as offline
[root@ipa1 ~]# wbinfo -n 'AD\Domain Admins'
failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
Could not lookup name AD\Domain Admins


[root@ipa1 ~]# ipa --version
VERSION: 4.5.0, API_VERSION: 2.228

[root@ipa1 ~]# sssd --version
1.15.2
 attached below is the log.wd.ad
I am happy to provide any more information and thank anyone who can help me
solve this, have been beaten up for a bit on it.

https://gist.github.com/anonymous/36d1a48cf1a1116b116f9ce911d91d8a
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can't sync a new replica, large db file,

[Ludwig Krispenz via FreeIPA-users]

On 11/14/2017 11:40 AM, Mike Johnson via FreeIPA-users wrote:

Hi

I've got a small environment which had until recently 2 IPA servers.
Both CentOS 7.4.1708

Version info:

id1:
Name: ipa-server
Version : 4.5.0
Release : 21.el7.centos.2.2
Kernel: 3.10.0-693.5.2.el7.x86_64
389-ds-base is at version 1.3.6.1

id5:
Name: ipa-server
Version : 4.5.0
Release : 21.el7.centos.2.2
Kernel: 3.10.0-693.5.2.el7.x86_64
389-ds-base is at version 1.3.6.1

I recently had an issue with high IO/load, and noted that the following file:
/var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/.db
was huge (5GB-ish) in a very small 2-master environment.  This is on
the master.  My understanding is that the entries in this file, which
have timestamps from months ago, exist because of failed replication.
I don't understand how to clear this without breaking things.
looks like you have changelog trimming not enabled, if you enable 
trimming now this would reduce the content, but not necessary reduce the 
file size, but it would prevent it to grow.
If you stop the server and remove it, it will be recreated. What can 
happen then is that required changes to update another replica are 
missing and repl will ask you to reinit the other server.


Now, the second problem should be unrelated. Looks like total init tries 
to connect to port 636 and fails, the normal repl session fals because 
the init didn't happen. Could you verify that id5 is listening on 636 or 
if you have any errors in its error logs.


Second issue; not sure if related:

I've since lost the replica (id2) but I've prepared a new machine
(id5) to be a new replica of id1.  I've cleaned the RUVs and deleted
the replication agreements but when I join the new machine to the
existing one using `ipa-replica-install` then I get the following on
the replica:


Starting replication, please wait until this has completed.
Update in progress, 10 seconds elapsed
[ldap://id1.prod.mydomain.com:389] reports: Update failed! Status:
[-11 connection error: Unknown connection error (-11) - Total update
aborted]

   [error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERRORFailed to start replication
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERRORThe ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
[root@id5 ~]# ipa-replica-manage re-initialize --from id1.prod.mydomain.com
Re-run /usr/sbin/ipa-replica-manage with --verbose option to get more
information
Unexpected error: cannot connect to 'ldaps://id5.prod.mydomain.com:636':


and the following on the master:


[14/Nov/2017:10:05:28.671905981 +] - INFO - NSMMReplicationPlugin
- repl5_tot_run - Beginning total update of replica
"agmt="cn=meToid5.prod.mydomain.com" (id5:389)".
[14/Nov/2017:10:05:38.031033860 +] - ERR - NSMMReplicationPlugin -
repl5_tot_log_operation_failure - agmt="cn=meToid5.prod.mydomain.com"
(id5:389): Received error -1 (Can't contact LDAP server):  for total
update operation
[14/Nov/2017:10:05:38.032272148 +] - ERR - NSMMReplicationPlugin -
release_replica - agmt="cn=meToid5.prod.mydomain.com" (id5:389):
Unable to send endReplication extended operation (Can't contact LDAP
server)
[14/Nov/2017:10:05:38.095893236 +] - ERR - NSMMReplicationPlugin -
repl5_tot_run - Total update failed for replica
"agmt="cn=meToid5.prod.mydomain.com" (id5:389)", error (-11)
[14/Nov/2017:10:05:38.113388624 +] - INFO - NSMMReplicationPlugin
- bind_and_check_pwp - agmt="cn=meToid5.prod.mydomain.com" (id5:389):
Replication bind with GSSAPI auth resumed
[14/Nov/2017:10:05:38.425682940 +] - WARN - NSMMReplicationPlugin
- repl5_inc_run - agmt="cn=meToid5.prod.mydomain.com" (id5:389): The
remote replica has a different database generation ID than the local
database.  You may have to reinitialize the remote replica, or the
local replica.


I've checked the firewalls on both machines, and gone as far as to
flush all the iptables rules to get it to work.  No luck.

I'm also getting hundreds of the last line "different database
generation ID" but my understanding is that this is only logged
because the replica is yet to be set up.

Would anyone please be able to provide some guidance?  I've been at
this for a few days now!

Thanks!
MIke
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


--
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
___
FreeIPA-users mailing list 

[Freeipa-users] Can't sync a new replica, large db file,

[Mike Johnson via FreeIPA-users]

Hi

I've got a small environment which had until recently 2 IPA servers.
Both CentOS 7.4.1708

Version info:

id1:
Name: ipa-server
Version : 4.5.0
Release : 21.el7.centos.2.2
Kernel: 3.10.0-693.5.2.el7.x86_64
389-ds-base is at version 1.3.6.1

id5:
Name: ipa-server
Version : 4.5.0
Release : 21.el7.centos.2.2
Kernel: 3.10.0-693.5.2.el7.x86_64
389-ds-base is at version 1.3.6.1

I recently had an issue with high IO/load, and noted that the following file:
/var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/.db
was huge (5GB-ish) in a very small 2-master environment.  This is on
the master.  My understanding is that the entries in this file, which
have timestamps from months ago, exist because of failed replication.
I don't understand how to clear this without breaking things.

Second issue; not sure if related:

I've since lost the replica (id2) but I've prepared a new machine
(id5) to be a new replica of id1.  I've cleaned the RUVs and deleted
the replication agreements but when I join the new machine to the
existing one using `ipa-replica-install` then I get the following on
the replica:


Starting replication, please wait until this has completed.
Update in progress, 10 seconds elapsed
[ldap://id1.prod.mydomain.com:389] reports: Update failed! Status:
[-11 connection error: Unknown connection error (-11) - Total update
aborted]

  [error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERRORFailed to start replication
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERRORThe ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
[root@id5 ~]# ipa-replica-manage re-initialize --from id1.prod.mydomain.com
Re-run /usr/sbin/ipa-replica-manage with --verbose option to get more
information
Unexpected error: cannot connect to 'ldaps://id5.prod.mydomain.com:636':


and the following on the master:


[14/Nov/2017:10:05:28.671905981 +] - INFO - NSMMReplicationPlugin
- repl5_tot_run - Beginning total update of replica
"agmt="cn=meToid5.prod.mydomain.com" (id5:389)".
[14/Nov/2017:10:05:38.031033860 +] - ERR - NSMMReplicationPlugin -
repl5_tot_log_operation_failure - agmt="cn=meToid5.prod.mydomain.com"
(id5:389): Received error -1 (Can't contact LDAP server):  for total
update operation
[14/Nov/2017:10:05:38.032272148 +] - ERR - NSMMReplicationPlugin -
release_replica - agmt="cn=meToid5.prod.mydomain.com" (id5:389):
Unable to send endReplication extended operation (Can't contact LDAP
server)
[14/Nov/2017:10:05:38.095893236 +] - ERR - NSMMReplicationPlugin -
repl5_tot_run - Total update failed for replica
"agmt="cn=meToid5.prod.mydomain.com" (id5:389)", error (-11)
[14/Nov/2017:10:05:38.113388624 +] - INFO - NSMMReplicationPlugin
- bind_and_check_pwp - agmt="cn=meToid5.prod.mydomain.com" (id5:389):
Replication bind with GSSAPI auth resumed
[14/Nov/2017:10:05:38.425682940 +] - WARN - NSMMReplicationPlugin
- repl5_inc_run - agmt="cn=meToid5.prod.mydomain.com" (id5:389): The
remote replica has a different database generation ID than the local
database.  You may have to reinitialize the remote replica, or the
local replica.


I've checked the firewalls on both machines, and gone as far as to
flush all the iptables rules to get it to work.  No luck.

I'm also getting hundreds of the last line "different database
generation ID" but my understanding is that this is only logged
because the replica is yet to be set up.

Would anyone please be able to provide some guidance?  I've been at
this for a few days now!

Thanks!
MIke
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org