Re: [Freeipa-users] FreeIPA Replica / HA Issues

[Petr Spacek]

Hello,


this log is weird:

On 14.1.2016 03:02, Jeff Hallyburton wrote:
>> 2016-01-14T00:45:35Z DEBUG [IPA Discovery]
>> 2016-01-14T00:45:35Z DEBUG Starting IPA discovery with 
>> domain=west-2.production.example.com, servers=None, 
>> hostname=test.west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG Search for LDAP SRV record in 
>> west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG Search DNS for SRV record of 
>> _ldap._tcp.west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG DNS record found: 0 100 389 
>> ipa1.west-2.production.example.com.
>> 2016-01-14T00:45:35Z DEBUG DNS record found: 10 100 389 
>> ipa2.west-2.production.example.com.
>> 2016-01-14T00:45:35Z DEBUG [Kerberos realm search]
>> 2016-01-14T00:45:35Z DEBUG Search DNS for TXT record of 
>> _kerberos.west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG DNS record found: "EXAMPLE.COM"
>> 2016-01-14T00:45:35Z DEBUG Search DNS for SRV record of 
>> _kerberos._udp.west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG DNS record found: 10 100 88 
>> ipa2.west-2.production.example.com.
>> 2016-01-14T00:45:35Z DEBUG DNS record found: 0 100 88 
>> ipa1.west-2.production.example.com.
>> 2016-01-14T00:45:35Z DEBUG [LDAP server check]
>> 2016-01-14T00:45:35Z DEBUG Verifying that ipa1.west-2.production.example.com 
>> (realm EXAMPLE.COM) is an IPA server
>> 2016-01-14T00:45:35Z DEBUG Init LDAP connection to: 
>> ipa1.west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG Search LDAP server for IPA base DN
>> 2016-01-14T00:45:35Z DEBUG Check if naming context 'dc=example,dc=com' is 
>> for IPA
>> 2016-01-14T00:45:35Z DEBUG Naming context 'dc=example,dc=com' is a valid IPA 
>> context
>> 2016-01-14T00:45:35Z DEBUG Search for (objectClass=krbRealmContainer) in 
>> dc=example,dc=com (sub)
>> 2016-01-14T00:45:35Z DEBUG Found: 
>> cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com
>> 2016-01-14T00:45:35Z DEBUG Discovery result: Success; 
>> server=ipa1.west-2.production.example.com, 
>> domain=west-2.production.example.com, 
>> kdc=ipa2.west-2.production.example.com,ipa1.west-2.production.example.com, 
>> basedn=dc=example,dc=com
>> 2016-01-14T00:45:35Z DEBUG Validated servers: 
>> ipa1.west-2.production.example.com
>> 2016-01-14T00:45:35Z DEBUG will use discovered domain: 
>> west-2.production.example.com

It looks that your IPA domain & realm is "example.com" and "EXAMPLE.COM", is
that correct?

Looking further ...

> 2016-01-14T00:45:39Z DEBUG Writing Kerberos configuration to /etc/krb5.conf:
> 2016-01-14T00:45:39Z DEBUG #File modified by ipa-client-install
> 
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> [libdefaults]
>   default_realm = EXAMPLE.COM
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
>   udp_preference_limit = 0
>   default_ccache_name = KEYRING:persistent:%{uid}
> 
> 
> [realms]
>   EXAMPLE.COM = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> 
>   }
> 
> 
> [domain_realm]
>   .west-2.production.example.com = EXAMPLE.COM
>   west-2.production.example.com = EXAMPLE.COM

Hmm, this is going to be wild guess, but let's try it:
Do you have DNS SRV records in domain west-2.production.example.com but not in
DNS domain example.com?

That would probably cause this kind of problem.

Generally it is necessary to put _kerberos TXT + SRV records into the
(primary) DNS domain specified during IPA installation. Then use --domain
option during ipa-client-install.

--server is generally discouraged as it disables DNS SRV lookup and makes
failover hard or impossible.

--domain is just a hint for the installer where to start looking for DNS SRV
records and allows full automatic failover.


The autodiscovery is quite messy and needs to be imporoved in next versions.
https://fedorahosted.org/freeipa/ticket/5270 should avoid the need to specify
--domain when Kerberos TXT record is in DNS ... Stay tuned :-)

-- 
Petr^2 Spacek

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

Re: [Freeipa-users] FreeIPA Replica / HA Issues

[Jeff Hallyburton]

Rob,

Full log is attached.

Jeff

Jeff Hallyburton
Strategic Systems Engineer
Bloomip Inc.
Web: http://www.bloomip.com

Engineering Support: supp...@bloomip.com
Billing Support: bill...@bloomip.com
Customer Support Portal:  https://my.bloomip.com 

On Wed, Jan 13, 2016 at 8:35 PM, Rob Crittenden  wrote:

> Jeff Hallyburton wrote:
> > We've deployed a FreeIPA server in a client infrastructure and now we're
> > working on making that setup HA.  We've created a replica and I can
> > verify that the replica has connectivity to the existing master and
> > ensured that the auto-discovery DNS records are set up for LDAP /
> > Kerberos / etc, but I'm having a couple of issues with clients:
> >
> > 1.  ipa-client-install fails with the following error whenever a server
> > is not explicitly specified (though explicitly specifying either the
> > original master OR the replica works fine):
> >
> > trying https://ipa1.west-2.production.example.com/ipa/json
> >
> > Cannot connect to the server due to Kerberos error: Kerberos error:
> > Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
> > information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM
> > "', -1765328230)/. Trying with delegate=True
> >
> > trying https://ipa1.west-2.production.example.com/ipa/json
> >
> > Second connect with delegate=True also failed: Kerberos error: Kerberos
> > error: ('Unspecified GSS failure.  Minor code may provide more
> > information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM
> > "', -1765328230)/
> >
> > Cannot connect to the IPA server RPC interface: Kerberos error: Kerberos
> > error: ('Unspecified GSS failure.  Minor code may provide more
> > information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM
> > "', -1765328230)/
> >
> > Installation failed. Rolling back changes.
> >
> > Failed to list certificates in /etc/ipa/nssdb: Command
> > ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero exit
> > status 255
> >
> > Unenrolling client from IPA server
> >
> > Unenrolling host failed: Error obtaining initial credentials: Cannot
> > find KDC for requested realm.
> >
> >
> > What we see in the install logs is:
> >
> > 2016-01-14T00:45:39Z INFO Configured /etc/krb5.conf for IPA realm
> > EXAMPLE.COM 
> >
> > 2016-01-14T00:45:39Z DEBUG Starting external process
> >
> > 2016-01-14T00:45:39Z DEBUG args='keyctl' 'search' '@s' 'user'
> > 'ipa_session_cookie:host/test.west-2.production.example@example.com
> > '
> >
> > 2016-01-14T00:45:39Z DEBUG Process finished, return code=1
> >
> > 2016-01-14T00:45:39Z DEBUG stdout=
> >
> > 2016-01-14T00:45:39Z DEBUG stderr=keyctl_search: Required key not
> available
> >
> >
> > 2016-01-14T00:45:39Z DEBUG Starting external process
> >
> > 2016-01-14T00:45:39Z DEBUG args='/usr/bin/certutil' '-d'
> > '/tmp/tmpCJNEzU' '-N' '-f' '/tmp/tmpPN7H8R'
> >
> > 2016-01-14T00:45:39Z DEBUG Process finished, return code=0
> >
> > 2016-01-14T00:45:39Z DEBUG stdout=
> >
> > 2016-01-14T00:45:39Z DEBUG stderr=
> >
> > 2016-01-14T00:45:39Z DEBUG Starting external process
> >
> > 2016-01-14T00:45:39Z DEBUG args='/usr/bin/certutil' '-d'
> > '/tmp/tmpCJNEzU' '-A' '-n' 'CA certificate 1' '-t' 'C,,'
> >
> > 2016-01-14T00:45:39Z DEBUG Process finished, return code=0
> >
> > 2016-01-14T00:45:39Z DEBUG stdout=
> >
> > 2016-01-14T00:45:39Z DEBUG stderr=
> >
> > 2016-01-14T00:45:39Z DEBUG Starting external process
> >
> > 2016-01-14T00:45:39Z DEBUG args='keyctl' 'search' '@s' 'user'
> > 'ipa_session_cookie:host/test.west-2.production.example@example.com
> > '
> >
> > 2016-01-14T00:45:39Z DEBUG Process finished, return code=1
> >
> > 2016-01-14T00:45:39Z DEBUG stdout=
> >
> > 2016-01-14T00:45:39Z DEBUG stderr=keyctl_search: Required key not
> available
> >
> >
> > 2016-01-14T00:45:39Z DEBUG failed to find session_cookie in persistent
> > storage for principal
> > 'host/test.west-2.production.example@example.com
> > '
> >
> > 2016-01-14T00:45:39Z INFO trying
> > https://ipa1.west-2.production.example.com/ipa/json
> >
> > 2016-01-14T00:45:39Z INFO Cannot connect to the server due to Kerberos
> > error: Kerberos error: Kerberos error: ('Unspecified GSS failure.  Minor
> > code may provide more information', 851968)/('Cannot find KDC for realm
> > "EXAMPLE.COM "', -1765328230)/. Trying with
> > delegate=True
> >
> > 2016-01-14T00:45:39Z INFO trying
> > https://ipa1.west-2.production.example.com/ipa/json
> >
> > 2016-01-14T00:45:39Z WARNING Second connect with delegate=True also
> > failed: Kerberos error: Kerberos error: ('Unspecified GSS failure.
> > Minor code may provide more information', 851968)/('Cannot find KDC for
> > realm "EXAMPLE.COM "', -1765328230)/
> >
> >

Re: [Freeipa-users] FreeIPA Replica / HA Issues

[Rob Crittenden]

Jeff Hallyburton wrote:
> We've deployed a FreeIPA server in a client infrastructure and now we're
> working on making that setup HA.  We've created a replica and I can
> verify that the replica has connectivity to the existing master and
> ensured that the auto-discovery DNS records are set up for LDAP /
> Kerberos / etc, but I'm having a couple of issues with clients:  
> 
> 1.  ipa-client-install fails with the following error whenever a server
> is not explicitly specified (though explicitly specifying either the
> original master OR the replica works fine):
> 
> trying https://ipa1.west-2.production.example.com/ipa/json
> 
> Cannot connect to the server due to Kerberos error: Kerberos error:
> Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
> information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM
> "', -1765328230)/. Trying with delegate=True
> 
> trying https://ipa1.west-2.production.example.com/ipa/json
> 
> Second connect with delegate=True also failed: Kerberos error: Kerberos
> error: ('Unspecified GSS failure.  Minor code may provide more
> information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM
> "', -1765328230)/
> 
> Cannot connect to the IPA server RPC interface: Kerberos error: Kerberos
> error: ('Unspecified GSS failure.  Minor code may provide more
> information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM
> "', -1765328230)/
> 
> Installation failed. Rolling back changes.
> 
> Failed to list certificates in /etc/ipa/nssdb: Command
> ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero exit
> status 255
> 
> Unenrolling client from IPA server
> 
> Unenrolling host failed: Error obtaining initial credentials: Cannot
> find KDC for requested realm.
> 
> 
> What we see in the install logs is:
> 
> 2016-01-14T00:45:39Z INFO Configured /etc/krb5.conf for IPA realm
> EXAMPLE.COM 
> 
> 2016-01-14T00:45:39Z DEBUG Starting external process
> 
> 2016-01-14T00:45:39Z DEBUG args='keyctl' 'search' '@s' 'user'
> 'ipa_session_cookie:host/test.west-2.production.example@example.com
> '
> 
> 2016-01-14T00:45:39Z DEBUG Process finished, return code=1
> 
> 2016-01-14T00:45:39Z DEBUG stdout=
> 
> 2016-01-14T00:45:39Z DEBUG stderr=keyctl_search: Required key not available
> 
> 
> 2016-01-14T00:45:39Z DEBUG Starting external process
> 
> 2016-01-14T00:45:39Z DEBUG args='/usr/bin/certutil' '-d'
> '/tmp/tmpCJNEzU' '-N' '-f' '/tmp/tmpPN7H8R'
> 
> 2016-01-14T00:45:39Z DEBUG Process finished, return code=0
> 
> 2016-01-14T00:45:39Z DEBUG stdout=
> 
> 2016-01-14T00:45:39Z DEBUG stderr=
> 
> 2016-01-14T00:45:39Z DEBUG Starting external process
> 
> 2016-01-14T00:45:39Z DEBUG args='/usr/bin/certutil' '-d'
> '/tmp/tmpCJNEzU' '-A' '-n' 'CA certificate 1' '-t' 'C,,'
> 
> 2016-01-14T00:45:39Z DEBUG Process finished, return code=0
> 
> 2016-01-14T00:45:39Z DEBUG stdout=
> 
> 2016-01-14T00:45:39Z DEBUG stderr=
> 
> 2016-01-14T00:45:39Z DEBUG Starting external process
> 
> 2016-01-14T00:45:39Z DEBUG args='keyctl' 'search' '@s' 'user'
> 'ipa_session_cookie:host/test.west-2.production.example@example.com
> '
> 
> 2016-01-14T00:45:39Z DEBUG Process finished, return code=1
> 
> 2016-01-14T00:45:39Z DEBUG stdout=
> 
> 2016-01-14T00:45:39Z DEBUG stderr=keyctl_search: Required key not available
> 
> 
> 2016-01-14T00:45:39Z DEBUG failed to find session_cookie in persistent
> storage for principal
> 'host/test.west-2.production.example@example.com
> '
> 
> 2016-01-14T00:45:39Z INFO trying
> https://ipa1.west-2.production.example.com/ipa/json
> 
> 2016-01-14T00:45:39Z INFO Cannot connect to the server due to Kerberos
> error: Kerberos error: Kerberos error: ('Unspecified GSS failure.  Minor
> code may provide more information', 851968)/('Cannot find KDC for realm
> "EXAMPLE.COM "', -1765328230)/. Trying with
> delegate=True
> 
> 2016-01-14T00:45:39Z INFO trying
> https://ipa1.west-2.production.example.com/ipa/json
> 
> 2016-01-14T00:45:39Z WARNING Second connect with delegate=True also
> failed: Kerberos error: Kerberos error: ('Unspecified GSS failure. 
> Minor code may provide more information', 851968)/('Cannot find KDC for
> realm "EXAMPLE.COM "', -1765328230)/
> 
> 2016-01-14T00:45:39Z ERROR Cannot connect to the IPA server RPC
> interface: Kerberos error: Kerberos error: ('Unspecified GSS failure. 
> Minor code may provide more information', 851968)/('Cannot find KDC for
> realm "EXAMPLE.COM "', -1765328230)/
> 
> 2016-01-14T00:45:39Z ERROR Installation failed. Rolling back changes.
> 
> 2016-01-14T00:45:39Z DEBUG Loading Index file from
> '/var/lib/ipa/sysrestore/sysrestore.index'
> 
> 2016-01-14T00:45:39Z DEBUG Starting external process
> 
> 2016-01-14T00:45:

[Freeipa-users] FreeIPA Replica / HA Issues

[Jeff Hallyburton]

We've deployed a FreeIPA server in a client infrastructure and now we're
working on making that setup HA.  We've created a replica and I can verify
that the replica has connectivity to the existing master and ensured that
the auto-discovery DNS records are set up for LDAP / Kerberos / etc, but
I'm having a couple of issues with clients:

1.  ipa-client-install fails with the following error whenever a server is
not explicitly specified (though explicitly specifying either the original
master OR the replica works fine):

trying https://ipa1.west-2.production.example.com/ipa/json

Cannot connect to the server due to Kerberos error: Kerberos error:
Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM"',
-1765328230)/. Trying with delegate=True

trying https://ipa1.west-2.production.example.com/ipa/json

Second connect with delegate=True also failed: Kerberos error: Kerberos
error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM"',
-1765328230)/

Cannot connect to the IPA server RPC interface: Kerberos error: Kerberos
error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM"',
-1765328230)/

Installation failed. Rolling back changes.

Failed to list certificates in /etc/ipa/nssdb: Command ''/usr/bin/certutil'
'-d' '/etc/ipa/nssdb' '-L'' returned non-zero exit status 255

Unenrolling client from IPA server

Unenrolling host failed: Error obtaining initial credentials: Cannot find
KDC for requested realm.

What we see in the install logs is:

2016-01-14T00:45:39Z INFO Configured /etc/krb5.conf for IPA realm
EXAMPLE.COM

2016-01-14T00:45:39Z DEBUG Starting external process

2016-01-14T00:45:39Z DEBUG args='keyctl' 'search' '@s' 'user'
'ipa_session_cookie:host/test.west-2.production.example@example.com'

2016-01-14T00:45:39Z DEBUG Process finished, return code=1

2016-01-14T00:45:39Z DEBUG stdout=

2016-01-14T00:45:39Z DEBUG stderr=keyctl_search: Required key not available


2016-01-14T00:45:39Z DEBUG Starting external process

2016-01-14T00:45:39Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpCJNEzU'
'-N' '-f' '/tmp/tmpPN7H8R'

2016-01-14T00:45:39Z DEBUG Process finished, return code=0

2016-01-14T00:45:39Z DEBUG stdout=

2016-01-14T00:45:39Z DEBUG stderr=

2016-01-14T00:45:39Z DEBUG Starting external process

2016-01-14T00:45:39Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpCJNEzU'
'-A' '-n' 'CA certificate 1' '-t' 'C,,'

2016-01-14T00:45:39Z DEBUG Process finished, return code=0

2016-01-14T00:45:39Z DEBUG stdout=

2016-01-14T00:45:39Z DEBUG stderr=

2016-01-14T00:45:39Z DEBUG Starting external process

2016-01-14T00:45:39Z DEBUG args='keyctl' 'search' '@s' 'user'
'ipa_session_cookie:host/test.west-2.production.example@example.com'

2016-01-14T00:45:39Z DEBUG Process finished, return code=1

2016-01-14T00:45:39Z DEBUG stdout=

2016-01-14T00:45:39Z DEBUG stderr=keyctl_search: Required key not available


2016-01-14T00:45:39Z DEBUG failed to find session_cookie in persistent
storage for principal 'host/test.west-2.production.example@example.com'

2016-01-14T00:45:39Z INFO trying
https://ipa1.west-2.production.example.com/ipa/json

2016-01-14T00:45:39Z INFO Cannot connect to the server due to Kerberos
error: Kerberos error: Kerberos error: ('Unspecified GSS failure.  Minor
code may provide more information', 851968)/('Cannot find KDC for realm "
EXAMPLE.COM"', -1765328230)/. Trying with delegate=True

2016-01-14T00:45:39Z INFO trying
https://ipa1.west-2.production.example.com/ipa/json

2016-01-14T00:45:39Z WARNING Second connect with delegate=True also failed:
Kerberos error: Kerberos error: ('Unspecified GSS failure.  Minor code may
provide more information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM"',
-1765328230)/

2016-01-14T00:45:39Z ERROR Cannot connect to the IPA server RPC interface:
Kerberos error: Kerberos error: ('Unspecified GSS failure.  Minor code may
provide more information', 851968)/('Cannot find KDC for realm "EXAMPLE.COM"',
-1765328230)/

2016-01-14T00:45:39Z ERROR Installation failed. Rolling back changes.

2016-01-14T00:45:39Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'

2016-01-14T00:45:39Z DEBUG Starting external process

2016-01-14T00:45:39Z DEBUG args='ipa-client-automount' '--uninstall'
'--debug'

2016-01-14T00:45:40Z DEBUG Process finished, return code=0

2016-01-14T00:45:40Z DEBUG stdout=Restoring configuration

2.  Related to this, all of our existing clients have been configured with
explicit server= statements, meaning that they don't pick up the replica
either.  Is there any way to manually fix this post installation, or will
we simply have to uninstall and reinstall the ipa client?

Thanks,

Jeff

Jeff Hallyburton
Strategic Systems Engineer
Bloomip Inc.
Web: http://www.bloomip.com

Engineering Support: supp...@bloomi

Re: [Freeipa-users] replica install failing with : "Clone does not have all the required certificates"

[James Kinney]

Followup:  I also tested converting an existing 4.2 system to be a CA
by running ipa-ca-install  and got the
same error. So it seems the original system had a failure point prior
to the heating issues. The 4.2 system has been running for quite a
while (with regular updates from an early 4.0).
On Wed, 2016-01-13 at 18:10 -0500, James Kinney wrote:
> I need to upgrade from IPA3.0 to IPA4.2 (from centos 6.7 to 7.2) and
> the replica process is failing to install on the new system:
> 
> 2016-01-13T17:27:46Z DEBUG Starting external process
> 2016-01-13T17:27:46Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
> '/tmp/tmpjklK4o'
> 2016-01-13T17:28:19Z DEBUG Process finished, return code=1
> 2016-01-13T17:28:19Z DEBUG stdout=Log file: /var/log/pki/pki-ca-
> spawn.20160113122746.log
> Loading deployment configuration from /tmp/tmpjklK4o.
> Installing CA into /var/lib/pki/pki-tomcat.
> Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-
> tomcat/ca/deployment.cfg.
> 
> Installation failed.
> 
> 
> 2016-01-13T17:28:19Z DEBUG stderr=/usr/lib/python2.7/site-
> packages/urllib3/connectionpool.py:769: InsecureRequestWarning:
> Unverified HTTPS request is being made. Adding certifi
> cate verification is strongly advised. See: https://urllib3.readthedo
> cs.org/en/latest/security.html
>   InsecureRequestWarning)
> pkispawn: WARNING  ... unable to validate security domain
> user/password through REST interface. Interface not available
> pkispawn: ERROR... Exception from Java Configuration
> Servlet: 500 Server Error: Internal Server Error
> pkispawn: ERROR... ParseError: not well-formed (invalid
> token): line 1, column 0:
> {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base
> .PKIException
> ","Code":500,"Message":"Clone does not have all the required
> certificates"} 
> 
> 2016-01-13T17:28:19Z CRITICAL Failed to configure CA instance:
> Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpjklK4o''
> returned non-zero exit status 1
> 2016-01-13T17:28:19Z CRITICAL See the installation logs and the
> following files/directories for more information:
> 2016-01-13T17:28:19Z CRITICAL   /var/log/pki-ca-install.log
> 2016-01-13T17:28:19Z CRITICAL   /var/log/pki/pki-tomcat
> 2016-01-13T17:28:19Z DEBUG Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-
> packages/ipaserver/install/service.py", line 418, in start_creation
> run_step(full_msg, method)
>   File "/usr/lib/python2.7/site-
> packages/ipaserver/install/service.py", line 408, in run_step
> method()
>   File "/usr/lib/python2.7/site-
> packages/ipaserver/install/cainstance.py", line 620, in
> __spawn_instance
> DogtagInstance.spawn_instance(self, cfg_file)
>   File "/usr/lib/python2.7/site-
> packages/ipaserver/install/dogtaginstance.py", line 201, in
> spawn_instance
> self.handle_setup_error(e)
>   File "/usr/lib/python2.7/site-
> packages/ipaserver/install/dogtaginstance.py", line 465, in
> handle_setup_error
> raise RuntimeError("%s configuration failed." % self.subsystem)
> RuntimeError: CA configuration failed.
> 
> 2016-01-13T17:28:19Z DEBUG   [error] RuntimeError: CA configuration
> failed.
> 2016-01-13T17:28:19Z DEBUG   File "/usr/lib/python2.7/site-
> packages/ipapython/admintool.py", line 171, in execute
> return_value = self.run()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py",
> line 311, in run
> 
> 
> 
> It looks to me that the original, first install version 3.0 system is
> generating a bad gpg file.  Will a reinstall of the orginal cert file
> solve this? If so, where and what is the best procedure? Is there a
> way to add CA capability to an existing master replicant by reusing
> it's original replica.gpg file?
> 
> Background: the old v3.0 system runs on a virtual machine (ovirt).
> The physical host had a series of "bad days" that involved multiple
> crashes and lock-ups that were ultimately attributed to insufficient
> cooling of the RAID card. It is suspected that the data was scrambled
> on the drive. The original cert is backed up but the remaining
> machine backups are of dubious quality (long story - bad week at the
> datacenter).
> 
> This is the last system on old hardware that was hit when the
> datacenter cooling totally failed and erased all the backups. Some
> days your're the pigeon, some days you're the statue.
> 
> 
> -- 
> 
> 
> 
> Jim Kinney
> Senior System Administrator
> 36 Eagle Row Suite 588
> Department of Biomedical Informatics
> Emory University School of Medicine
> jkin...@emory.edu
> 404-712-0300
> -- 
> 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
-- 
Jim Kinney
Senior System Administrator
36 Eagle Row Suite 588
Department of Biomedical Informatics
Emory University School of Medicine
jkin...@emory.edu
404-712-0300-- 
Manage your subscription for the Freeipa-users mailin

Re: [Freeipa-users] GID, groups and ipa group-show

[Prasun Gera]

This is an old thread, but I can confirm that this is still an issue on
RHEL 7.2 + 4.2. This creates problems when there are roles associated with
groups, but group membership through GID is broken. I had migrated all old
NIS accounts into ipa. I then added the host enrollment role to a
particular group. Now, unless I add the users to the group explicitly, they
won't get the role, even if their gid is the same as the gid of the group.

On Mon, Aug 24, 2015 at 5:01 AM, David Kupka  wrote:

> On 21/08/15 15:21, bahan w wrote:
>
>> Hello !
>>
>> I contact you because I notice something strange with IPA environment.
>>
>> I created a group :
>> ipa group-add g1 --desc="my first group"
>>
>> Then I created a user with the GID of g1
>> GID1=`ipa group-show g1 | awk '/GID/ {printf("%s",$2)}'`
>> ipa user-add --first=u1 --last=u1 --homedir=/home/u1 --shell=/bin/bash
>> --gidnumber=${GID1} u1
>>
>> Then when I perform ipa group-show g1 command, I got the following result
>> :
>> ###
>>Group name: g1
>>Description: my first group
>>GID: 
>> ###
>>
>> Same for ipa user-show u1 :
>> ###
>>User login: u1
>>First name: u1
>>Last name: u1
>>Home directory: /home/u1
>>Login shell: /bin/bash
>>Email address: u1@
>>UID: 
>>GID: 
>>Account disabled: False
>>Password: False
>>Member of groups: ipausers
>>Kerberos keys available: False
>> ###
>>
>> These 2 commands does not see u1 as a member of g1.
>> When I try the command id u1, I can see the group :
>>
>> ###
>> id u1
>> uid=(u1) gid=(g1) groups=(g1)
>> ###
>>
>> Is it the normal behaviour of these IPA commands ?
>>
>> Best regards.
>>
>> Bahan
>>
>>
>>
> Hello!
>
> I'm not sure if this is intended and/or correct behavior or not.
> Looking at /etc/passwd and /etc/group I see it behaves similarly in a way.
>
> You can have following entries in the aforementioned files
>
> [/etc/group]
> ...
> g1:x::
> ...
>
> [/etc/passwd]
> ...
> u1:x/home/u1:/bin/bash
> ...
>
> Looking in /etc/group you can't see user 'u1' is member of group 'g1' but
> tools like id, groups, getent shows this information.
>
> On the other hand it would be useful to show these "implicit" members in
> group-show output.
> Could you please file a ticket (https://fedorahosted.org/freeipa/newticket
> )?
>
> --
> David Kupka
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] replica install failing with : "Clone does not have all the required certificates"

[James Kinney]

I need to upgrade from IPA3.0 to IPA4.2 (from centos 6.7 to 7.2) and
the replica process is failing to install on the new system:

2016-01-13T17:27:46Z DEBUG Starting external process
2016-01-13T17:27:46Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmpjklK4o'
2016-01-13T17:28:19Z DEBUG Process finished, return code=1
2016-01-13T17:28:19Z DEBUG stdout=Log file: /var/log/pki/pki-ca-
spawn.20160113122746.log
Loading deployment configuration from /tmp/tmpjklK4o.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-
tomcat/ca/deployment.cfg.

Installation failed.


2016-01-13T17:28:19Z DEBUG stderr=/usr/lib/python2.7/site-
packages/urllib3/connectionpool.py:769: InsecureRequestWarning:
Unverified HTTPS request is being made. Adding certifi
cate verification is strongly advised. See: https://urllib3.readthedocs
.org/en/latest/security.html
  InsecureRequestWarning)
pkispawn: WARNING  ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: 500 Server Error: Internal Server Error
pkispawn: ERROR... ParseError: not well-formed (invalid
token): line 1, column 0:
{"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.P
KIException
","Code":500,"Message":"Clone does not have all the required
certificates"} 

2016-01-13T17:28:19Z CRITICAL Failed to configure CA instance: Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpjklK4o'' returned non-
zero exit status 1
2016-01-13T17:28:19Z CRITICAL See the installation logs and the
following files/directories for more information:
2016-01-13T17:28:19Z CRITICAL   /var/log/pki-ca-install.log
2016-01-13T17:28:19Z CRITICAL   /var/log/pki/pki-tomcat
2016-01-13T17:28:19Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 418, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 408, in run_step
method()
  File "/usr/lib/python2.7/site-
packages/ipaserver/install/cainstance.py", line 620, in
__spawn_instance
DogtagInstance.spawn_instance(self, cfg_file)
  File "/usr/lib/python2.7/site-
packages/ipaserver/install/dogtaginstance.py", line 201, in
spawn_instance
self.handle_setup_error(e)
  File "/usr/lib/python2.7/site-
packages/ipaserver/install/dogtaginstance.py", line 465, in
handle_setup_error
raise RuntimeError("%s configuration failed." % self.subsystem)
RuntimeError: CA configuration failed.

2016-01-13T17:28:19Z DEBUG   [error] RuntimeError: CA configuration
failed.
2016-01-13T17:28:19Z DEBUG   File "/usr/lib/python2.7/site-
packages/ipapython/admintool.py", line 171, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py",
line 311, in run






It looks to me that the original, first install version 3.0 system is 
generating a bad gpg file.  Will a reinstall of the orginal cert file solve 
this? If so, where and what is the best procedure? Is there a way to add CA 
capability to an existing master replicant by reusing it's original replica.gpg 
file?


Background: the old v3.0 system runs on a virtual machine (ovirt). The physical 
host had a series of "bad days" that involved multiple crashes and lock-ups 
that were ultimately attributed to insufficient cooling of the RAID card. It is 
suspected that the data was scrambled on the drive. The original cert is backed 
up but the remaining machine backups are of dubious quality (long story - bad 
week at the datacenter).


This is the last system on old hardware that was hit when the datacenter 
cooling totally failed and erased all the backups. Some days your're the 
pigeon, some days you're the statue.




-- 








  
  


Jim Kinney

Senior System Administrator

36 Eagle Row Suite 588

Department of Biomedical Informatics

Emory University School of Medicine

jkin...@emory.edu

404-712-0300


-- 
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] IPA users not visible in NIS passwd map

[Prasun Gera]

Great! I hope it makes it downstream to RHEL.

On Wed, Jan 13, 2016 at 4:27 PM, Alexander Bokovoy 
wrote:

> On Wed, 13 Jan 2016, Prasun Gera wrote:
>
>> They are authenticated using CRYPT passwords. i.e. Even after a user is
>> disabled in ipa, it's entry is still visible in ypcat passwd on the
>> clients.
>>
> https://fedorahosted.org/slapi-nis/ticket/10
>
> The definition is unfortunately in the C code, so it would require
> recompile of slapi-nis. For Fedora I plan to do new release next week or
> so as there are enough patches ready to go to new release.
>
>
> --
> / 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] IPA users not visible in NIS passwd map

[Alexander Bokovoy]

On Wed, 13 Jan 2016, Prasun Gera wrote:

They are authenticated using CRYPT passwords. i.e. Even after a user is
disabled in ipa, it's entry is still visible in ypcat passwd on the
clients.

https://fedorahosted.org/slapi-nis/ticket/10

The definition is unfortunately in the C code, so it would require
recompile of slapi-nis. For Fedora I plan to do new release next week or
so as there are enough patches ready to go to new release.


--
/ 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] IPA users not visible in NIS passwd map

[Prasun Gera]

They are authenticated using CRYPT passwords. i.e. Even after a user is
disabled in ipa, it's entry is still visible in ypcat passwd on the
clients.

On Wed, Jan 13, 2016 at 4:17 PM, Alexander Bokovoy 
wrote:

> On Wed, 13 Jan 2016, Prasun Gera wrote:
>
>> I think I've solved this. I don't know what or who enabled it, but for
>> some
>> reason the original NIS service (ypserv) was running on the server. That
>> was taking precedence over ipa's fake NIS, and causing problems. I have
>> now
>> deleted the maps and commented them out in the Makefile so that it doesn't
>> get enabled accidentally again.
>>
>> I do see another problem though. In an attempt to clean up a lot of old
>> users, I have disabled them in the webui. This works for ipa clients and
>> access is denied, but the users can still log in on the old NIS clients.
>> Is
>> this a known limitation ?
>>
> How they are authenticated on the NIS clients? FreeIPA does not provide
> shadow map.
> --
> / 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] IPA users not visible in NIS passwd map

[Alexander Bokovoy]

On Wed, 13 Jan 2016, Prasun Gera wrote:

I think I've solved this. I don't know what or who enabled it, but for some
reason the original NIS service (ypserv) was running on the server. That
was taking precedence over ipa's fake NIS, and causing problems. I have now
deleted the maps and commented them out in the Makefile so that it doesn't
get enabled accidentally again.

I do see another problem though. In an attempt to clean up a lot of old
users, I have disabled them in the webui. This works for ipa clients and
access is denied, but the users can still log in on the old NIS clients. Is
this a known limitation ?

How they are authenticated on the NIS clients? FreeIPA does not provide
shadow map.
--
/ 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] py.test is missing

[Alexander Bokovoy]

On Wed, 13 Jan 2016, Adam Kaczka wrote:

Hi,

I am trying to run make-test in 4.0.2 after make and I see that it is
trying to run py.test but I don't see py.test anywhere in the directory?
For some reason it is simply missing.

pytest is a separate package which you need to install.

--
/ 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] IPA users not visible in NIS passwd map

[Prasun Gera]

I think I've solved this. I don't know what or who enabled it, but for some
reason the original NIS service (ypserv) was running on the server. That
was taking precedence over ipa's fake NIS, and causing problems. I have now
deleted the maps and commented them out in the Makefile so that it doesn't
get enabled accidentally again.

I do see another problem though. In an attempt to clean up a lot of old
users, I have disabled them in the webui. This works for ipa clients and
access is denied, but the users can still log in on the old NIS clients. Is
this a known limitation ?

On Mon, Jan 11, 2016 at 9:21 PM, Prasun Gera  wrote:

> This is the output of the command:
>
> ldapsearch  -LLL -H $(cat /etc/ipa/default.conf | grep ldap_uri|cut -d=
> -f2) -b cn=config '(nis-domain=*)' dn CreateTimestamp ModifyTimestamp
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> dn: nis-domain=domain.edu+nis-map=auto.home,cn=NIS
> Server,cn=plugins,cn=config
> CreateTimestamp: 20150321091139Z
> ModifyTimestamp: 20150321091139Z
>
> dn: nis-domain=domain.edu+nis-map=auto.local,cn=NIS
> Server,cn=plugins,cn=confi
>  g
> CreateTimestamp: 20150321091209Z
> ModifyTimestamp: 20150321091209Z
>
> dn: nis-domain=domain.edu+nis-map=auto.master,cn=NIS
> Server,cn=plugins,cn=conf
>  ig
> CreateTimestamp: 20150321091201Z
> ModifyTimestamp: 20150321091201Z
>
> dn: nis-domain=domain.edu+nis-map=ethers.byaddr,cn=NIS
> Server,cn=plugins,cn=co
>  nfig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=ethers.byname,cn=NIS
> Server,cn=plugins,cn=co
>  nfig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=group.bygid,cn=NIS
> Server,cn=plugins,cn=conf
>  ig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=group.byname,cn=NIS
> Server,cn=plugins,cn=con
>  fig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=netgroup,cn=NIS
> Server,cn=plugins,cn=config
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=netid.byname,cn=NIS
> Server,cn=plugins,cn=con
>  fig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=passwd.byname,cn=NIS
> Server,cn=plugins,cn=co
>  nfig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=passwd.byuid,cn=NIS
> Server,cn=plugins,cn=con
>  fig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
>
> All the maps are listed from what I can tell. passwd is the one that is
> not working as expected. Autofs maps are working all right on nis clients.
>
> On Mon, Jan 11, 2016 at 4:21 PM, Alexander Bokovoy 
> wrote:
>
>> On Mon, 11 Jan 2016, Prasun Gera wrote:
>>
>>> I upgraded ipa to 4.2 on my rhel 7.2 servers a few weeks ago. One of the
>>> users reported that he is not able to log in to certain systems any more.
>>> It turns out that there is some change in behaviour w.r.t NIS clients
>>> after
>>> this upgrade. I see that his username is not visible in "ypcat passwd" on
>>> the old clients that are using NIS. This user was added natively through
>>> ipa. The old users that were migrated from NIS still work as expected on
>>> the NIS clients. I can also confirm that if I add a new user now in ipa,
>>> it
>>> is not visible in NIS maps. Until we phase out the NIS clients
>>> completely,
>>> I would like all users to be able to log into them. This used to be the
>>> case, but a recent update seems to have changed that. I don't know if
>>> this
>>> is intentional. How do i revert to the old behaviour ?
>>>
>> Do you see all the maps configured?
>>
>> # ldapsearch  -LLL -H $(cat /etc/ipa/default.conf | grep ldap_uri|cut -d=
>> -f2) -b cn=config '(nis-domain=*)' dn CreateTimestamp ModifyTimestamp
>>
>> We have a bug in the upgrade script that was fixed this morning
>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00154.html
>>
>> --
>> / 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

[Freeipa-users] py.test is missing

[Adam Kaczka]

Hi,

I am trying to run make-test in 4.0.2 after make and I see that it is
trying to run py.test but I don't see py.test anywhere in the directory?
For some reason it is simply missing.
-- 
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] IPA-Server installation

[Alexander Bokovoy]

On Wed, 13 Jan 2016, Gady Notrica wrote:

Hi,

Trying to install IPA-Server but failing.
The file 
"b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2"
 is no longer available.

It has been replace by 
"14824767ac8a1b07914066cf2f721b1ba0de7cf93e04662a6f669cb302de61d1-primary.sqlite.bz2"

NEW FILE
http://mirror.its.sfu.ca/mirror/CentOS/7.2.1511/updates/x86_64/repodata/14824767ac8a1b07914066cf2f721b1ba0de7cf93e04662a6f669cb302de61d1-primary.sqlite.bz2

OLD FILE
http://centos.bhs.mirrors.ovh.net/ftp.centos.org/7.2.1511/updates/x86_64/repodata/b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404 - Not Found
http://centos.mirror.netelligent.ca/centos/7.2.1511/updates/x86_64/repodata/b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404 - Not Found
http://mirror.esecuredata.com/centos/7.2.1511/updates/x86_64/repodata/b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404 - Not Found


I'm not sure what you are trying to achieve by this post. There are many
mirrors for CentOS project and they may have non-synchronized state.
It may take several hours or days to get new content synchronized. If
some mirror does not work, other mirror would be selected by yum until
the working data set is obtained.

FreeIPA team has no influence over CentOS project and their mirrors. If
you see constant issues with some of CentOS mirrors, report these issues
to CentOS project IT people.

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

[Freeipa-users] IPA-Server installation

[Gady Notrica]

Hi,

Trying to install IPA-Server but failing.
The file 
"b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2"
 is no longer available.

It has been replace by 
"14824767ac8a1b07914066cf2f721b1ba0de7cf93e04662a6f669cb302de61d1-primary.sqlite.bz2"

NEW FILE
http://mirror.its.sfu.ca/mirror/CentOS/7.2.1511/updates/x86_64/repodata/14824767ac8a1b07914066cf2f721b1ba0de7cf93e04662a6f669cb302de61d1-primary.sqlite.bz2

OLD FILE
http://centos.bhs.mirrors.ovh.net/ftp.centos.org/7.2.1511/updates/x86_64/repodata/b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404 - Not Found
http://centos.mirror.netelligent.ca/centos/7.2.1511/updates/x86_64/repodata/b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404 - Not Found
http://mirror.esecuredata.com/centos/7.2.1511/updates/x86_64/repodata/b0789cdf06109ebe3313dab51585247700dd285b7eb0bc83f9d80a90cf2360f6-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404 - Not Found

Gady Notrica | IT Systems Analyst | 416.814.7800 Ext. 7921 | Cell. 416.818.4797 
| gnotr...@candeal.com
CanDeal | 152 King St. E, 4th Floor, Toronto ON M5A 1J4 | 
www.candeal.com | Follow us: [Description: Description: 
cid:image003.jpg@01CBD419.622CDF90]    
[Description: Description: Description: cid:image002.jpg@01CBD419.622CDF90] 


-- 
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] configure: error: xmlrpc-c/base.h not found

[Rob Crittenden]

Anthony Cheng wrote:
> Hi all,
> 
> I am getting an error with make for both freeipa-4.3.0
> and freeipa-4.2.0; both errors are the same:
> 
> checking for xmlrpc-c/base.h... no
> configure: error: xmlrpc-c/base.h not found
> make: *** [client-autogen] Error 1
> 
> I read from http://www.freeipa.org/page/Releases/4.0.0 that XMLRPC
> system commands were not implemented; so is it safe to ignore this error?

You can't ignore it, the referenced system commands are introspectives
for the XMLRPC protocol itself.

> If not would it suffice to install one of the following?
> 
> xmlrpc-c-c++.x86_64 : C++ libraries for xmlrpc-c
> xmlrpc-c-client.x86_64 : C client libraries for xmlrpc-c
> xmlrpc-c-client++.x86_64 : C++ client libraries for xmlrpc-c
> xmlrpc-c-devel.x86_64 : Development files for xmlrpc-c based programs
> xmlrpc-c.x86_64 : A lightweight RPC library based on XML and HTTP
> xmlrpc-c-apps.x86_64 : Sample XML-RPC applications
> xmlrpc-client.noarch : XML-RPC client implementation
> xmlrpc-common.noarch : Common classes for XML-RPC client and server
> implementations

You need xmlrpc-c-devel which will probably pull in most if not all of
that. See BUILD.txt in the top level of the source tree for some helpers
in getting all the dependencies installed.

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] Fwd: NetworkError : invalid continuation byte with utf8 codec

[philippe domineaux]

Thanks It works like a charm.
Btw I switched to en_US.iso 

Fixed for me.

> Le 6 janv. 2016 à 22:21, Carlos Raúl Laguna  a écrit :
> 
> Happy new year to all, just to point out that this also affect Fedora23 
> Free-IPA 4.2.0 and 4.3.0 from corps. locale  are set to es_ES.UTF-8.  Regards
> 
> 2016-01-05 23:32 GMT-05:00 Fraser Tweedale :
>> On Mon, Jan 04, 2016 at 03:13:43PM +0100, Domineaux Philippe wrote:
>> > Hello,
>> >
>> > Happy new year.
>> >
>> > So the content of my /etc/locale.conf :
>> >
>> > LANG="fr_FR.UTF-8"
>> >
>> Happy new year to you too, and thanks for the info.
>> 
>> I reproduced the issue and there is a now a patch awaiting review.
>> Ticket: https://fedorahosted.org/freeipa/ticket/5578
>> 
>> Cheers,
>> Fraser
>> 
>> > -- Forwarded message --
>> > From: Fraser Tweedale 
>> > Date: 2015-12-23 5:11 GMT+01:00
>> > Subject: Re: [Freeipa-users] NetworkError : invalid continuation byte with
>> > utf8 codec
>> > To: Gmail 
>> > Cc: freeipa-users@redhat.com
>> >
>> >
>> > On Tue, Dec 22, 2015 at 08:39:09AM +0100, Gmail wrote:
>> > > Here are the files you ask for:
>> > >
>> > Thank you.  I see Tomcat is running in an fr_FR locale. Could you
>> > also provide contents of `/etc/locale.conf'?
>> >
>> > Cheers,
>> > Fraser
>> >
>> > >
>> > >
>> > > Le 22 décembre 2015 à 02:30:06, Fraser Tweedale (ftwee...@redhat.com) a
>> > écrit:
>> > >
>> > > On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote:
>> > > > Hi all,
>> > > >
>> > > > When trying to install on a fresh new Centos 7 I’ve got this error :
>> > > >
>> > > > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed,
>> > exception: NetworkError: cannot connect to '
>> > https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't
>> > decode byte 0xea in position 13: invalid continuation byte
>> > > > 2015-12-21T16:04:44Z ERROR cannot connect to '
>> > https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't
>> > decode byte 0xea in position 13: invalid continuation byte
>> > > >
>> > > > My freeipa-server version is :  4.2.0
>> > > > I’m running a Centos 3.10.0-327.3.1.el7.x86_64
>> > > >
>> > > > Any idea of what goes wrong?
>> > > >
>> > > Thanks for reporting. I have not seen this error before. Could you
>> > > please include the following log files and I will take a closer
>> > > look:
>> > >
>> > > /var/log/ipaserver-install.log
>> > > /var/log/pki/pki-tomcat/ca/debug
>> > >
>> > > Cheers,
>> > > Fraser
>> 
>> > --
>> > Manage your subscription for the Freeipa-users mailing list:
>> > https://www.redhat.com/mailman/listinfo/freeipa-users
>> > Go to http://freeipa.org for more info on the project
>> 
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] configure: error: xmlrpc-c/base.h not found

[Anthony Cheng]

Hi all,

I am getting an error with make for both freeipa-4.3.0 and freeipa-4.2.0;
both errors are the same:

checking for xmlrpc-c/base.h... no
configure: error: xmlrpc-c/base.h not found
make: *** [client-autogen] Error 1

I read from http://www.freeipa.org/page/Releases/4.0.0 that XMLRPC system
commands were not implemented; so is it safe to ignore this error?

If not would it suffice to install one of the following?

xmlrpc-c-c++.x86_64 : C++ libraries for xmlrpc-c
xmlrpc-c-client.x86_64 : C client libraries for xmlrpc-c
xmlrpc-c-client++.x86_64 : C++ client libraries for xmlrpc-c
xmlrpc-c-devel.x86_64 : Development files for xmlrpc-c based programs
xmlrpc-c.x86_64 : A lightweight RPC library based on XML and HTTP
xmlrpc-c-apps.x86_64 : Sample XML-RPC applications
xmlrpc-client.noarch : XML-RPC client implementation
xmlrpc-common.noarch : Common classes for XML-RPC client and server
implementations

-- 

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

Re: [Freeipa-users] How to migrate from freeipa distribution to separate components

[Simo Sorce]

On Wed, 2016-01-13 at 17:10 +0100, bahan w wrote:
> Re !
> 
> Thank both of you again for your answers, guys.
> 
> Simo, I would be very interested in this feature list in fact.
> Do you know if there is a way to find it ?
> I would really need it, it would help a lot.

You can start from here: http://www.freeipa.org/page/Documentation
For example under the "by component" part although that does not make
you understand all the work behind the installer, which was the first
big chunk of work when we started 8 years ago.

Simo.

> Best regards.
> 
> Bahan
> 
> On Wed, Jan 13, 2016 at 4:11 PM, Martin Kosek  wrote:
> 
> > On 01/13/2016 03:57 PM, bahan w wrote:
> > > Re.
> > >
> > > Thanks both of you for your answers.
> > >
> > > Simo, MIT Kerberos and OpenLDAP can work on their own and provide the
> > same
> > > kind of service that we want from IPA, even if it is not embedded in
> > > integrated solution like IPA.
> > >
> > > I totally agree that IPA provides a lot of things but I am quite sure the
> > > isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for LDAP and
> > a
> > > cache client like sssd or nscd/nslcd can work.
> >
> > It "can" work. But home grown solutions like that require non-trivial
> > effort to
> > even get started.
> >
> > As soon as you have more requests on such home grown infrastructure, you
> > will
> > need to implement enhancements (like something cert or DNS related). At
> > that
> > moment, you may realize you are re-implementing what FreeIPA may support
> > already. FreeIPA project was started for a reason :-)
> >
> > > Alexander, when I mention migration, I think of the following actions :
> > > 1. Take the principals that we have for the KDC and recreate them in an
> > MIT
> > > Kerberos KDC architecture
> > > 2. Take the users/groups/pwpolicies in the LDAP and recreate them in an
> > > openLDAP architecture
> > >
> > > Do you know if there is other things necessary to recreate in the LDAP or
> > > in the KDC ?
> > >
> > > Additionnaly, do you have a list of points which could help to convince
> > to
> > > keep the freeipa architecture ?
> > >
> > > Best regards.
> > >
> > > Bahan
> > >
> > > On Wed, Jan 13, 2016 at 3:33 PM, Alexander Bokovoy 
> > > wrote:
> > >
> > >> On Wed, 13 Jan 2016, bahan w wrote:
> > >>
> > >>> Hello Simo !
> > >>>
> > >>> For the reason :
> > >>> The production team wants to use only the two components openLDAP and
> > MIT
> > >>> Kerberos, possibily on different servers.
> > >>>
> > >>> For the explanation :
> > >>> They want to install only MIT Kerberos and openLDAP.
> > >>> We already have an existing FreeIPA installation, with users, groups,
> > >>> principals, pwpolicies.
> > >>> We would like to migrate this to an openLDAP for the users, groups and
> > >>> pwpolicies, and to another MIT Kerberos for the principals (hope I'm
> > not
> > >>> forgetting anything).
> > >>>
> > >> FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA
> > >> LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA
> > >> schema.
> > >>
> > >> Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two
> > >> dozen additional plugins. These plugins either don't exist for OpenLDAP
> > >> at all or have different behavior and rely on different LDAP schema.
> > >>
> > >> In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be
> > >> used by MIT Kerberos LDAP driver because it doesn't know about that
> > >> data, and OpenLDAP server will not have the same behavior as expected by
> > >> IPA clients (SSSD) for IPA-specific mode.
> > >>
> > >> Whatever your production team is thinking about this move, it is most
> > >> certainly not properly thought out.
> > >>
> > >> --
> > >> / 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


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] tricky one in OpenLDAP migration, groups

[Rob Crittenden]

Janelle wrote:
> Might it be possible with a user-mod or group-add/group-mod to accomplish?
> 
> Just thinking outside the box I guess.

The hard part is the UPG. I think you'd need an ldapmodify to achieve
that. IIRC you'd need to manually create the managed group entry and in
the same update link the user to it.

rob

> ~J
> 
> On 1/13/16 7:59 AM, Rob Crittenden wrote:
>> Janelle wrote:
>>> Hello,
>>>
>>> This may not be possible, or if it is I am going to guess it is not
>>> going to be easy. If I have an old OpenLDAP environment with users who
>>> never had unique UIG/GID - in other words, the GID was not unique to a
>>> user, instead it was some global group. Well, I was hoping to migrate
>>> over the OpenLDAP domain to IPA, but at the same time create a private
>>> group for each user. Just wondering if this might be possible?
>>>
>>> Example OpenLDAP
>>> user=freddy (UID=13) , GID=123456(friday)
>>>
>>> After migration to IPA:
>>> user= uid=13(freddy), gid=13(freddy), groups=123456(friday)
>>>
>>> Does that make sense?
>> It does but it isn't possible today. In fact the migration won't create
>> user private groups at all (though there is an RFE for that,
>> https://fedorahosted.org/freeipa/ticket/4738 )
>>
>> I don't think this is an unreasonable request. It may be an extension of
>> the above ticket, probably requiring a new option to deal with the
>> existing primary group.
>>
>> 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] tricky one in OpenLDAP migration, groups

[Janelle]

Might it be possible with a user-mod or group-add/group-mod to accomplish?

Just thinking outside the box I guess.
~J

On 1/13/16 7:59 AM, Rob Crittenden wrote:

Janelle wrote:

Hello,

This may not be possible, or if it is I am going to guess it is not
going to be easy. If I have an old OpenLDAP environment with users who
never had unique UIG/GID - in other words, the GID was not unique to a
user, instead it was some global group. Well, I was hoping to migrate
over the OpenLDAP domain to IPA, but at the same time create a private
group for each user. Just wondering if this might be possible?

Example OpenLDAP
user=freddy (UID=13) , GID=123456(friday)

After migration to IPA:
user= uid=13(freddy), gid=13(freddy), groups=123456(friday)

Does that make sense?

It does but it isn't possible today. In fact the migration won't create
user private groups at all (though there is an RFE for that,
https://fedorahosted.org/freeipa/ticket/4738 )

I don't think this is an unreasonable request. It may be an extension of
the above ticket, probably requiring a new option to deal with the
existing primary group.

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] How to migrate from freeipa distribution to separate components

[bahan w]

Re !

Thank both of you again for your answers, guys.

Simo, I would be very interested in this feature list in fact.
Do you know if there is a way to find it ?
I would really need it, it would help a lot.

Best regards.

Bahan

On Wed, Jan 13, 2016 at 4:11 PM, Martin Kosek  wrote:

> On 01/13/2016 03:57 PM, bahan w wrote:
> > Re.
> >
> > Thanks both of you for your answers.
> >
> > Simo, MIT Kerberos and OpenLDAP can work on their own and provide the
> same
> > kind of service that we want from IPA, even if it is not embedded in
> > integrated solution like IPA.
> >
> > I totally agree that IPA provides a lot of things but I am quite sure the
> > isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for LDAP and
> a
> > cache client like sssd or nscd/nslcd can work.
>
> It "can" work. But home grown solutions like that require non-trivial
> effort to
> even get started.
>
> As soon as you have more requests on such home grown infrastructure, you
> will
> need to implement enhancements (like something cert or DNS related). At
> that
> moment, you may realize you are re-implementing what FreeIPA may support
> already. FreeIPA project was started for a reason :-)
>
> > Alexander, when I mention migration, I think of the following actions :
> > 1. Take the principals that we have for the KDC and recreate them in an
> MIT
> > Kerberos KDC architecture
> > 2. Take the users/groups/pwpolicies in the LDAP and recreate them in an
> > openLDAP architecture
> >
> > Do you know if there is other things necessary to recreate in the LDAP or
> > in the KDC ?
> >
> > Additionnaly, do you have a list of points which could help to convince
> to
> > keep the freeipa architecture ?
> >
> > Best regards.
> >
> > Bahan
> >
> > On Wed, Jan 13, 2016 at 3:33 PM, Alexander Bokovoy 
> > wrote:
> >
> >> On Wed, 13 Jan 2016, bahan w wrote:
> >>
> >>> Hello Simo !
> >>>
> >>> For the reason :
> >>> The production team wants to use only the two components openLDAP and
> MIT
> >>> Kerberos, possibily on different servers.
> >>>
> >>> For the explanation :
> >>> They want to install only MIT Kerberos and openLDAP.
> >>> We already have an existing FreeIPA installation, with users, groups,
> >>> principals, pwpolicies.
> >>> We would like to migrate this to an openLDAP for the users, groups and
> >>> pwpolicies, and to another MIT Kerberos for the principals (hope I'm
> not
> >>> forgetting anything).
> >>>
> >> FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA
> >> LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA
> >> schema.
> >>
> >> Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two
> >> dozen additional plugins. These plugins either don't exist for OpenLDAP
> >> at all or have different behavior and rely on different LDAP schema.
> >>
> >> In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be
> >> used by MIT Kerberos LDAP driver because it doesn't know about that
> >> data, and OpenLDAP server will not have the same behavior as expected by
> >> IPA clients (SSSD) for IPA-specific mode.
> >>
> >> Whatever your production team is thinking about this move, it is most
> >> certainly not properly thought out.
> >>
> >> --
> >> / 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] tricky one in OpenLDAP migration, groups

[Rob Crittenden]

Janelle wrote:
> Hello,
> 
> This may not be possible, or if it is I am going to guess it is not
> going to be easy. If I have an old OpenLDAP environment with users who
> never had unique UIG/GID - in other words, the GID was not unique to a
> user, instead it was some global group. Well, I was hoping to migrate
> over the OpenLDAP domain to IPA, but at the same time create a private
> group for each user. Just wondering if this might be possible?
> 
> Example OpenLDAP
> user=freddy (UID=13) , GID=123456(friday)
> 
> After migration to IPA:
> user= uid=13(freddy), gid=13(freddy), groups=123456(friday)
> 
> Does that make sense?

It does but it isn't possible today. In fact the migration won't create
user private groups at all (though there is an RFE for that,
https://fedorahosted.org/freeipa/ticket/4738 )

I don't think this is an unreasonable request. It may be an extension of
the above ticket, probably requiring a new option to deal with the
existing primary group.

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] How to migrate from freeipa distribution to separate components

[Loris Santamaria]

El mié, 13-01-2016 a las 15:57 +0100, bahan w escribió:
> Re.
> 
> Thanks both of you for your answers.
> 
> Simo, MIT Kerberos and OpenLDAP can work on their own and provide the
> same kind of service that we want from IPA, even if it is not
> embedded in integrated solution like IPA.
> 
> I totally agree that IPA provides a lot of things but I am quite sure
> the isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for
> LDAP and a cache client like sssd or nscd/nslcd can work.
Yes, they work. I installed some similar solutions ten years ago. Then
i began using freeipa and never looked back.
> Alexander, when I mention migration, I think of the following actions
> :> 1. Take the principals that we have for the KDC and recreate them in an 
> MIT Kerberos KDC architecture> 2. Take the users/groups/pwpolicies in the 
> LDAP and recreate them in an openLDAP architecture> 
> 
You should first setup openldap following their various howto, then
setup kerberos with the ldap kdb driver, then dump ldap data from IPA,
massage it in something acceptable for openldap and your chosen schema,
then add it using ldapadd or slapadd. After that you'll want to tune
openldap and add all the needed indexes. You should think about
replication. You should think about security. You should think about
ldap administration.
Good luck, you will need it.
> Do you know if there is other things necessary to recreate in the
> LDAP or in the KDC ?> 
> Additionnaly, do you have a list of points which could help to convince to 
> keep the freeipa architecture ?> > Best regards.> 
> Bahan

> On Wed, Jan 13, 2016 at 3:33 PM, Alexander Bokovoy > >  
> wrote:
> > On Wed, 13 Jan 2016, bahan w wrote:
> > 
> > > 
> > > Hello Simo !
> > > 

> > > 
> > > For the reason :
> > > 
> > > The production team wants to use only the two components openLDAP and MIT
> > > 
> > > Kerberos, possibily on different servers.
> > > 

> > > 
> > > For the explanation :
> > > 
> > > They want to install only MIT Kerberos and openLDAP.
> > > 
> > > We already have an existing FreeIPA installation, with users, groups,
> > > 
> > > principals, pwpolicies.
> > > 
> > > We would like to migrate this to an openLDAP for the users, groups and
> > > 
> > > pwpolicies, and to another MIT Kerberos for the principals (hope I'm not
> > > 
> > > forgetting anything).
> > > 
> > 
> > FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA
> > 
> > LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA
> > 
> > schema.
> > 

> > 
> > Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two
> > 
> > dozen additional plugins. These plugins either don't exist for OpenLDAP
> > 
> > at all or have different behavior and rely on different LDAP schema.
> > 

> > 
> > In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be
> > 
> > used by MIT Kerberos LDAP driver because it doesn't know about that
> > 
> > data, and OpenLDAP server will not have the same behavior as expected by
> > 
> > IPA clients (SSSD) for IPA-specific mode.
> > 

> > 
> > Whatever your production team is thinking about this move, it is most
> > 
> > certainly not properly thought out.
> > 

> > 
> > -- 
> > 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
-- 
Loris Santamaria   linux user #70506   xmpp:lo...@lgs.com.ve
Links Global Services, C.A.http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:1...@lgs.com.ve

"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford



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

[Freeipa-users] tricky one in OpenLDAP migration, groups

[Janelle]

Hello,

This may not be possible, or if it is I am going to guess it is not 
going to be easy. If I have an old OpenLDAP environment with users who 
never had unique UIG/GID - in other words, the GID was not unique to a 
user, instead it was some global group. Well, I was hoping to migrate 
over the OpenLDAP domain to IPA, but at the same time create a private 
group for each user. Just wondering if this might be possible?


Example OpenLDAP
user=freddy (UID=13) , GID=123456(friday)

After migration to IPA:
user= uid=13(freddy), gid=13(freddy), groups=123456(friday)

Does that make sense?
~J

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

[Freeipa-users] tricky one in OpenLDAP migration, groups

[Janelle]

Hello,

This may not be possible, or if it is I am going to guess it is not 
going to be easy. If I have an old OpenLDAP environment with users who 
never had unique UIG/GID - in other words, the GID was not unique to a 
user, instead it was some global group. Well, I was hoping to migrate 
over the OpenLDAP domain to IPA, but at the same time create a private 
group for each user. Just wondering if this might be possible?


Example OpenLDAP
user=freddy (UID=13) , GID=123456(friday)

After migration to IPA:
user= uid=13(freddy), gid=13(freddy), groups=123456(friday)

Does that make sense?
~J

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

Re: [Freeipa-users] How to migrate from freeipa distribution to separate components

[Simo Sorce]

On Wed, 2016-01-13 at 15:57 +0100, bahan w wrote:
> Re.
> 
> Thanks both of you for your answers.
> 
> Simo, MIT Kerberos and OpenLDAP can work on their own and provide the same
> kind of service that we want from IPA, even if it is not embedded in
> integrated solution like IPA.
> 
> I totally agree that IPA provides a lot of things but I am quite sure the
> isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for LDAP and a
> cache client like sssd or nscd/nslcd can work.

I know they *can* work, but there is no "migration" path there because
they are not a solution, they are a bag of parts you need to manually
configure and integrate on your own.

> Alexander, when I mention migration, I think of the following actions :
> 1. Take the principals that we have for the KDC and recreate them in an MIT
> Kerberos KDC architecture

If you know how to deploy openldap+MIT kdc you should know how to do
this, if you do not  you should ask yourself if you can support your
plan, because you'll be on your own there.

> 2. Take the users/groups/pwpolicies in the LDAP and recreate them in an
> openLDAP architecture

This is also just a matter of playing with LDIFs (depending on how close
or far the schema you'll chose for your custom soution is) and you
should know how to do this if you are planning on your own custom setup.
Again if you don't you should ask yourself how likely it is you'll be
able to support yourself.

> Do you know if there is other things necessary to recreate in the LDAP or
> in the KDC ?

Look at kdb5_ldap_util from MIT krb5.

> Additionnaly, do you have a list of points which could help to convince to
> keep the freeipa architecture ?

The FreeIPA installer goes through a few hundred steps just to set up
the system, and this does not take in accoount the integration plpugins
we built, and the management features that will be completely missing in
a bare openldap+mit system for things as simple as "allow a non-ldap
expert to create a user, manage its passwords and groups", also Access
control, delegation, etc... the feature list is huge.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-users] How to migrate from freeipa distribution to separate components

[Martin Kosek]

On 01/13/2016 03:57 PM, bahan w wrote:
> Re.
> 
> Thanks both of you for your answers.
> 
> Simo, MIT Kerberos and OpenLDAP can work on their own and provide the same
> kind of service that we want from IPA, even if it is not embedded in
> integrated solution like IPA.
> 
> I totally agree that IPA provides a lot of things but I am quite sure the
> isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for LDAP and a
> cache client like sssd or nscd/nslcd can work.

It "can" work. But home grown solutions like that require non-trivial effort to
even get started.

As soon as you have more requests on such home grown infrastructure, you will
need to implement enhancements (like something cert or DNS related). At that
moment, you may realize you are re-implementing what FreeIPA may support
already. FreeIPA project was started for a reason :-)

> Alexander, when I mention migration, I think of the following actions :
> 1. Take the principals that we have for the KDC and recreate them in an MIT
> Kerberos KDC architecture
> 2. Take the users/groups/pwpolicies in the LDAP and recreate them in an
> openLDAP architecture
> 
> Do you know if there is other things necessary to recreate in the LDAP or
> in the KDC ?
> 
> Additionnaly, do you have a list of points which could help to convince to
> keep the freeipa architecture ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Jan 13, 2016 at 3:33 PM, Alexander Bokovoy 
> wrote:
> 
>> On Wed, 13 Jan 2016, bahan w wrote:
>>
>>> Hello Simo !
>>>
>>> For the reason :
>>> The production team wants to use only the two components openLDAP and MIT
>>> Kerberos, possibily on different servers.
>>>
>>> For the explanation :
>>> They want to install only MIT Kerberos and openLDAP.
>>> We already have an existing FreeIPA installation, with users, groups,
>>> principals, pwpolicies.
>>> We would like to migrate this to an openLDAP for the users, groups and
>>> pwpolicies, and to another MIT Kerberos for the principals (hope I'm not
>>> forgetting anything).
>>>
>> FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA
>> LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA
>> schema.
>>
>> Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two
>> dozen additional plugins. These plugins either don't exist for OpenLDAP
>> at all or have different behavior and rely on different LDAP schema.
>>
>> In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be
>> used by MIT Kerberos LDAP driver because it doesn't know about that
>> data, and OpenLDAP server will not have the same behavior as expected by
>> IPA clients (SSSD) for IPA-specific mode.
>>
>> Whatever your production team is thinking about this move, it is most
>> certainly not properly thought out.
>>
>> --
>> / 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] How to migrate from freeipa distribution to separate components

[bahan w]

Re.

Thanks both of you for your answers.

Simo, MIT Kerberos and OpenLDAP can work on their own and provide the same
kind of service that we want from IPA, even if it is not embedded in
integrated solution like IPA.

I totally agree that IPA provides a lot of things but I am quite sure the
isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for LDAP and a
cache client like sssd or nscd/nslcd can work.

Alexander, when I mention migration, I think of the following actions :
1. Take the principals that we have for the KDC and recreate them in an MIT
Kerberos KDC architecture
2. Take the users/groups/pwpolicies in the LDAP and recreate them in an
openLDAP architecture

Do you know if there is other things necessary to recreate in the LDAP or
in the KDC ?

Additionnaly, do you have a list of points which could help to convince to
keep the freeipa architecture ?

Best regards.

Bahan

On Wed, Jan 13, 2016 at 3:33 PM, Alexander Bokovoy 
wrote:

> On Wed, 13 Jan 2016, bahan w wrote:
>
>> Hello Simo !
>>
>> For the reason :
>> The production team wants to use only the two components openLDAP and MIT
>> Kerberos, possibily on different servers.
>>
>> For the explanation :
>> They want to install only MIT Kerberos and openLDAP.
>> We already have an existing FreeIPA installation, with users, groups,
>> principals, pwpolicies.
>> We would like to migrate this to an openLDAP for the users, groups and
>> pwpolicies, and to another MIT Kerberos for the principals (hope I'm not
>> forgetting anything).
>>
> FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA
> LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA
> schema.
>
> Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two
> dozen additional plugins. These plugins either don't exist for OpenLDAP
> at all or have different behavior and rely on different LDAP schema.
>
> In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be
> used by MIT Kerberos LDAP driver because it doesn't know about that
> data, and OpenLDAP server will not have the same behavior as expected by
> IPA clients (SSSD) for IPA-specific mode.
>
> Whatever your production team is thinking about this move, it is most
> certainly not properly thought out.
>
> --
> / 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] How to migrate from freeipa distribution to separate components

[Alexander Bokovoy]

On Wed, 13 Jan 2016, bahan w wrote:

Hello Simo !

For the reason :
The production team wants to use only the two components openLDAP and MIT
Kerberos, possibily on different servers.

For the explanation :
They want to install only MIT Kerberos and openLDAP.
We already have an existing FreeIPA installation, with users, groups,
principals, pwpolicies.
We would like to migrate this to an openLDAP for the users, groups and
pwpolicies, and to another MIT Kerberos for the principals (hope I'm not
forgetting anything).

FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA
LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA
schema.

Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two
dozen additional plugins. These plugins either don't exist for OpenLDAP
at all or have different behavior and rely on different LDAP schema.

In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be
used by MIT Kerberos LDAP driver because it doesn't know about that
data, and OpenLDAP server will not have the same behavior as expected by
IPA clients (SSSD) for IPA-specific mode.

Whatever your production team is thinking about this move, it is most
certainly not properly thought out.

--
/ 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] How to migrate from freeipa distribution to separate components

[Simo Sorce]

On Wed, 2016-01-13 at 15:10 +0100, bahan w wrote:
> Hello Simo !
> 
> For the reason :
> The production team wants to use only the two components openLDAP and MIT
> Kerberos, possibily on different servers.
> 
> For the explanation :
> They want to install only MIT Kerberos and openLDAP.
> We already have an existing FreeIPA installation, with users, groups,
> principals, pwpolicies.
> We would like to migrate this to an openLDAP for the users, groups and
> pwpolicies, and to another MIT Kerberos for the principals (hope I'm not
> forgetting anything).

Sorry but FreeIPA is not just a generic directory server and an MIT KDC,
it is an integrated solution. There is no path to use loose parts
instead of the integrated set.

I do not mean this snarkly in any way, but with a car analogy what you
asked is something like: Can we migrate this Toyota Corolla to a set of
loose parts (including and engine from Mercedes and the chassis of an
Honda) that our mechanic can put together ? 

Simo.

> Best regards.
> 
> Bahan
> 
> On Wed, Jan 13, 2016 at 2:58 PM, Simo Sorce  wrote:
> 
> > On Wed, 2016-01-13 at 14:54 +0100, bahan w wrote:
> > > Hello !
> > >
> > > I send you this mail because I have a question relative to the migration
> > > from the IPA distribution to the separate components.
> > >
> > > With FreeIPA, we are using only :
> > > - MIT Kerberos
> > > - DS389
> > > - The PKI CA is installed but not used from our side
> > >
> > > Is it possible to migrate to the following separate components :
> > > - MIT Kerberos (we keep the same)
> > > - OpenLDAP
> > >
> > > I often found documentation to migrate from MIT Kerberos and OpenLDAP to
> > > FreeIPA but not the opposite.
> >
> > Can you explain what you mean by "migrate to the following separate
> > components" ? And why you want to do so ?
> >
> > Simo.
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> >
> >


-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-users] How to migrate from freeipa distribution to separate components

[bahan w]

Hello Simo !

For the reason :
The production team wants to use only the two components openLDAP and MIT
Kerberos, possibily on different servers.

For the explanation :
They want to install only MIT Kerberos and openLDAP.
We already have an existing FreeIPA installation, with users, groups,
principals, pwpolicies.
We would like to migrate this to an openLDAP for the users, groups and
pwpolicies, and to another MIT Kerberos for the principals (hope I'm not
forgetting anything).

Best regards.

Bahan

On Wed, Jan 13, 2016 at 2:58 PM, Simo Sorce  wrote:

> On Wed, 2016-01-13 at 14:54 +0100, bahan w wrote:
> > Hello !
> >
> > I send you this mail because I have a question relative to the migration
> > from the IPA distribution to the separate components.
> >
> > With FreeIPA, we are using only :
> > - MIT Kerberos
> > - DS389
> > - The PKI CA is installed but not used from our side
> >
> > Is it possible to migrate to the following separate components :
> > - MIT Kerberos (we keep the same)
> > - OpenLDAP
> >
> > I often found documentation to migrate from MIT Kerberos and OpenLDAP to
> > FreeIPA but not the opposite.
>
> Can you explain what you mean by "migrate to the following separate
> components" ? And why you want to do so ?
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to migrate from freeipa distribution to separate components

[Simo Sorce]

On Wed, 2016-01-13 at 14:54 +0100, bahan w wrote:
> Hello !
> 
> I send you this mail because I have a question relative to the migration
> from the IPA distribution to the separate components.
> 
> With FreeIPA, we are using only :
> - MIT Kerberos
> - DS389
> - The PKI CA is installed but not used from our side
> 
> Is it possible to migrate to the following separate components :
> - MIT Kerberos (we keep the same)
> - OpenLDAP
> 
> I often found documentation to migrate from MIT Kerberos and OpenLDAP to
> FreeIPA but not the opposite.

Can you explain what you mean by "migrate to the following separate
components" ? And why you want to do so ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Freeipa-users] How to migrate from freeipa distribution to separate components

[bahan w]

Hello !

I send you this mail because I have a question relative to the migration
from the IPA distribution to the separate components.

With FreeIPA, we are using only :
- MIT Kerberos
- DS389
- The PKI CA is installed but not used from our side

Is it possible to migrate to the following separate components :
- MIT Kerberos (we keep the same)
- OpenLDAP

I often found documentation to migrate from MIT Kerberos and OpenLDAP to
FreeIPA but not the opposite.

Best regards.

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

[Freeipa-users] Slow non-kerberised nfs mounts when ipa started

[Roderick Johnstone]

Hi

I'm not sure this is quite the right place to post this query, but the 
problem is provoked by starting the ipa server so hopefully someone on 
the list might have encountered and resolved the issue already.


This on a fully updated Redhat 7.2 system.

Once I have my ipa server started I'm finding that non-kerberised nfs4 
mounts of a filesystem from a host that is not an ipa client are very 
slow. Typically it takes 4-5 seconds for the mount operation to complete.


The nfs server is exporting the filesystem with the option sec=sys in 
/etc/exports.


I testing the mount speed with the mount command (so no autofs involved) 
and specifying the client address by ipv4 number (so no name lookups).


I can reduce the delay to 2-3 seconds by specifying -o sec=sys on the 
mount line, but this too is very slow.


The following causes mounts to happen at full speed, ie less than 0.1 
sec elapsed:


1) Using mount option -o vers=3 (nfs v3)

2) Turning off the nfs-secure service (stops rpc.gssd)

3) Turning off the ipa server (ipactl stop)

On my Redhat 6.7 testing ipa server the nfsv4 mounts also comlplete in 
under 0.1 sec so this seems to be an RHEL7 change.


In /var/log/messages there are lots of messages like this:
gssproxy: gssproxy[790]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS 
failure.  Minor code may provide more information, No credentials cache 
found


but they come out whether the nfs mounts are slow or quick.

Does anyone else see this or have any ideas on how to speed up the nfs 
v4 mount on Redhat 7 when the ipa server is running?


Thanks

Roderick Johnstone

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