[Freeipa-users] FreeIPA Read Only Replica

[Andrey Ptashnik]

Team,

Is it possible to setup read only replica for use in DMZ for example?

Regards,

Andrey

-- 
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-replica-conncheck wants listener on port 7389

[Ian Pilcher]

I'm part way through my CentOS 6 to 7 "upgrade".  I've reached the
point of trying to set up my new IPA server as a replica of a temporary
VM.

ipa-replica-conncheck is complaining, because nothing on the temporary
server is listening on port 7389.

The documentation here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html

Says:

  In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not
  required.

Which seems to indicate that nothing *should* be listening on that port
on a CentOS 7 IPA server.

So who's right?  And if something (pki-tomcatd?) should be listening on
that port, how do I make it do so?

Thanks!

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


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

Re: [Freeipa-users] Ubuntu client 2FA not working

[Jochen Hein]

Tommy Nikjoo  writes:

> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

Can you provide logs what doesn't work? See also my report in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856307
In short: without _kerberos._udp entries it should work out-of-the-box.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] AD Sites and Trusts

[Jakub Hrozek]

On Mon, Feb 27, 2017 at 01:50:50PM -0600, Jason B. Nance wrote:
> Hello,
> 
> I was wondering if this thread regarding AD trusts and sites is still correct:
> 
> https://www.redhat.com/archives/freeipa-users/2015-December/msg00214.html
> 
> (no way to make use of AD sites)

Well, you can configure krb5.conf on the client..but there is still no
automatic configuration.

> 
> If so, is there already an RFE for this that I can vote for and track?

RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=1416528
upstream:
https://pagure.io/SSSD/sssd/issue/3291

This is a stretch goal for the next upstream release, but given our
timeline and the fact that nobody started on this RFE, I think the
release after the next one is more realistic.

-- 
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] AD Sites and Trusts

[Jason B. Nance]

Hello,

I was wondering if this thread regarding AD trusts and sites is still correct:

https://www.redhat.com/archives/freeipa-users/2015-December/msg00214.html

(no way to make use of AD sites)

If so, is there already an RFE for this that I can vote for and track?

Thanks,

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] New install, unsupported format?

[Steve Huston]

On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka  wrote:
> Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can
> run `ipa domainlevel-get` on the master if you don't know)? Did you have a
> client installed prior to ipa-replica-install?

It's level 1.  I did have a couple clients installed, and the machine
I was trying to promote to a replica was one of them.  This whole
instance is a testing instance, with live data but not in production,
while I make sure everything works as expected before I deploy it, so
the servers and their data are new as of a couple weeks ago and began
life as a RHEL7.3 install.

It seems there might be two issues here; the one I originally reported
was that the ipa-server packages installed on a client machine are
unable to talk to the server, even though it obviously knows what the
server is (the "unsupported format" error I originally shared).  The
second is with setting up a replica in general.

I had tried the various methods outlined in the RedHat IdM
documentation, including promoting a client via an administrators TGT,
adding the client to the ipaservers group on the server, etc.  What
did finally work was unprovisioning the client, setting a one-time
password, and running "ipa-replica-install -v
--domain=astro.princeton.edu --server=ipa.astro.princeton.edu
--realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu
--setup-ca -p foobar" - this yielded a fully working replica when it
finished.  All of the previous failures happened in the same way as
mentioned before - it seems to unprovision the client for some reason,
then fail in reprovisioning it.

One problem which has cropped up before and caused problems is with
DNS capitalization.  DNS reports the domain name of "Princeton.EDU"
for hosts here, which means in order to do just about anything with a
FreeIPA server I have to manually add the host to /etc/hosts with all
lowercase letters.  I also have to force all of the host names via
command line switches so that DNS is not consulted for lookups, which
will return the StudlyCaps names and fail.  I suppose I should raise
that as a separate issue, because my understanding is that
hostnames/domainnames should be case insensitive so I'm not sure why
FreeIPA cares (and it may be easier to steer the entire project to not
care than convince those in control of DNS here to change it :D )

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
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] ID Mapping

[Hanoz Elavia]

Thanks Jakub!!


*Hanoz Elavia |*  IT Manager
*O:* 604-734-2866 *|*  *www.atomiccartoons.com
*
112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6

On Mon, Feb 27, 2017 at 7:26 AM, Jakub Hrozek  wrote:

> On Sun, Feb 26, 2017 at 12:12:23PM -0800, Hanoz Elavia wrote:
> > Hey guys,
> >
> > Is it possible to disable ID mapping for AD users in a FreeIPA AD trust
> > setup?
> >
> > The version report is as follows:
> >
> > AD: Windows 2008 R2
> > FreeIPA Server: 4.4.0-14
> > FreeIPA Client: 4.4.0-14
> > SSSD: 1.14.0-43
> > Linux version: CentOS 7.3 x64_86
> >
> > I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain
> > sectionwith no success.
> >
> > Regards,
> >
> > Hanoz
>
> In IPA-AD trust environment the mapping is managed on the server. So
> you'd need to remove the algorithmical range and add a POSIX range
> instead (see  ipa help idrange-add, --type=['ipa-ad-trust-posix',
> 'ipa-ad-trust', 'ipa-local'])
>
> Note that clients cannot modify the range type at the moment, so you
> also need to remove the cache from all clients in the domain.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] CentOS 6 -> 7 migration

[Greg]

I've had success going from RHEL6 to RHEL7 and IPA 3.0 to 4.4, without
losing any data/objects/clients. It is as you found though, through
replication.

I've followed this guide for IPA upgrade:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc

And this guide for in-situ RHEL6 to 7 upgrade, not sure if/how applicable
that is to CentOS, but if you can get away doing fresh OS installs, that's
always better (I couldn't, very limited access to hardware/BIOS):

https://access.redhat.com/solutions/637583

For IPA upgrade, you definitely want a replica. Well, just another machine
on the same network really to help you migrate and you can later go back to
using just the one IPA server. As suggested by Rob, you could nominate one
of your IPA clients as a replica temporarily (though if that's CentOS 6,
it'd need OS upgrade too).

In my case I already had two replicas, and I had done the following
(deviating slightly from Redhat's guide, that says use 3rd/fresh machine,
then decomm old ones):

- Removed one RHEL6 replica, uninstalled IPA 3.0 on it, trashed the config
etc, made it into as clean RHEL 6 as possible (even yum remove ipa-server
etc).
- Upgraded that cleaned up RHEL6 ex-replica to RHEL7 in-situ, and installed
IPA 4.4 server.
- Joined the freshly upgraded and empty RHEL7/IPA4.4 to existing realm and
moved CA renewal service to it (important).
- Repeated the steps on the other replica (remove from replication,
uninstall/trash everything to have as clean RHEL6 as possible, upgraded to
RHEL7, install IPA 4.4, re-join).

In a way your steps would be even easier, cause you can ignore step 1, and
just use a fresh machine. If you still want to end up with just 1 IPA
server, then you'd introduce new CentOS 7 / IPA 4.4 replica (new machine on
the same network, or existing client nominated to be a server for duration
of migration), make sure clients can connect to it / are aware of it, move
CA renewal to it, remove existing/old IPA from replication, clean it,
upgrade to CentOS 7 / IPA 4.4 (or re-install OS from scratch), re-introduce
into replication, move CA renewal back to it, and finally remove the new
machine replica, so that you're left with your original machine in an
upgraded state.

Hope that makes sense. If you can avoid in-situ 6 to7 OS upgrade and do
fresh OS installs between the replica migrations, all the better, as it can
be a bit of an added nuisance (trawling all the *.rpmnew config files and
making sure everything is correct).

--
Thanks,

Greg Kubok.

On 26 February 2017 at 11:08, Rob Verduijn  wrote:

> Upgrading centos6 to 7 is not a smart thing, unless you like to suffer a
> lot of issues.
>
> Then there are many comaptibility issues regarding the upgrade from ipa3.3
> to 4.4
>
> You should consider setting up a temporary vm to migrate from.
> On one of your client systems, I assume you got at least 1 ipa client
>
> Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your
> current system to a vm  (side effect : instant full backup)
>
> When you got the vm up and running you can reinstall your main system with
> the new os and ipa.
> Then replicate the old ipa to the new one.
>
> Rob Verduijn
>
>
>
> 2017-02-26 0:45 GMT+01:00 Ian Pilcher :
>
>> Is there any way to migrate an IPA server from 6 -> 7 without losing all
>> of the IPA configuration and data?  All of the documentation I can find
>> involves setting up a replica, replicating the data over, and then
>> decommissioning the old system; not exactly an option with a single
>> system.
>>
>> --
>> 
>> Ian Pilcher arequip...@gmail.com
>>  "I grew up before Mark Zuckerberg invented friendship" 
>> 
>>
>> --
>> 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
>



-- 
Thanks,

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

Re: [Freeipa-users] Ubuntu client 2FA not working

[Jochen Hein]

Tommy Nikjoo  writes:

> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

I'm not finished with my quest, but I think I got at least some hints.
Right now I'm not trying with pam/sss, but with kinit alone. I do have
two IPA servers and in the default configuration I see:

$ KRB5_TRACE=/dev/stderr kinit -T KEYRING:persistent:1004:krb_ccache_UhNqkJ3 
jochen
[15136] 1488197822.55857: Resolving hostname freeipa1.example.org.
[15136] 1488197822.57587: Sending initial UDP request to dgram 192.168.30.121:88
[15136] 1488197822.60106: Received answer (546 bytes) from dgram 
192.168.30.121:88
[15136] 1488197822.60994: Response was from master KDC
[15136] 1488197822.61069: Received error from KDC: -1765328359/zusätzlich 
Vorauthentifizierung erforderlich
[15136] 1488197822.61093: Decoding FAST response
[15136] 1488197822.61282: Processing preauth types: 136, 141, 133, 137
[15136] 1488197822.61298: Received cookie: MIT
Enter your OTP password: 
[15136] 1488197829.991232: Preauth module otp (141) (real) returned: 0/Success
[15136] 1488197829.991271: Produced preauth for next request: 133, 142
[15136] 1488197829.991289: Encoding request body and padata into FAST request
[15136] 1488197829.991518: Sending request (1221 bytes) to EXAMPLE.ORG
[15136] 1488197829.993141: Resolving hostname freeipa1.example.org.
[15136] 1488197829.993873: Sending initial UDP request to dgram 
192.168.30.121:88
[15136] 1488197830.994965: Resolving hostname freeipa2.example.org.
[15136] 1488197830.995866: Sending initial UDP request to dgram 
192.168.30.122:88
[15136] 1488197831.128141: Received answer (546 bytes) from dgram 
192.168.30.121:88
[15136] 1488197831.129630: Response was from master KDC
[15136] 1488197831.129731: Received error from KDC: 
-1765328360/Vorauthentifizierung fehlgeschlagen
[15136] 1488197831.129764: Decoding FAST response
[15136] 1488197831.129953: Preauth tryagain input types: 136, 141, 133, 137
kinit: Vorauthentifizierung fehlgeschlagen bei Anfängliche Anmeldedaten werden 
geholt.

We ask the first ipa server for preauth, after I've entered the
password+OTP we ask the first server with UDP, but don't get an answer
within one second. So we ask the other server. Shortly after we get the
answer from the first server.

If I use only one KDC in krb5.conf:
  dns_lookup_kdc = false
...
kdc = freeipa1.example.org

we only ask that server and get the correct answer.

So I see two questions for now:
- Why do we ask both servers with such a short timeout?
- Why do we use UDP when using dns_lookup_kdc, even if I have 
"udp_preference_limit = 1" set?

My FreeIPA servers ask themselves, so they don't use DNS. I'll try to check a 
normal client.
Hm, one CentOS client has krb5-workstation-1.14.1-27.el7_3.x86_64 and works 
fine.
My Debian host I analyzed here has krb5-user 1.15-1.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] Migration of FreeIPA issue tracker - Trac and git repo to pagure.io

[Petr Vobornik]

Hello list,

today and tomorrow a migration of FreeIPA issue tracker[1] and git repo 
will take place.


It is due to FedoraHosted sunset [2]. Both will be migrated to pagure.io 
[3].


During this migration it won't be possible to add new tickets and 
comments to Trac or Pagure.


[1] https://fedorahosted.org/freeipa/
[2] https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/
[3] https://pagure.io/

Thank you for understanding,
--
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat, Inc.

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

[Freeipa-users] Kerberos - Weblogic SSO in IPA

[Troels Hansen]

Hi, I'm trying to help a Weblogic admin trying to enable SSO using IPA as a 
backend in AD trust, and I'm not anywhere near a Java or Weblogic man. 

The ticket looks OK, and I can kinit it. 

Klist shows: 

# klist -ke sso.keytab 
Keytab name: FILE:sso.keytab 
KVNO Principal 
 -- 
3 HTTP/ssotst01pack.lx.dr...@lx.dr.dk (aes256-cts-hmac-sha1-96) 
3 HTTP/ssotst01pack.lx.dr...@lx.dr.dk (aes128-cts-hmac-sha1-96) 
3 HTTP/ssotst01pack.lx.dr...@lx.dr.dk (des3-cbc-sha1) 
3 HTTP/ssotst01pack.lx.dr...@lx.dr.dk (arcfour-hmac) 


Ticket is exported without the need for pre-auth. 

I have made a pretty basic krb5.conf for use with Weblogic: 

[libdefaults] 
default_realm = LX.DR.DK 
permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts 
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes256-cts 
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes256-cts 
dns_lookup_realm = false 
dns_lookup_kdc = false 
noaddresses = true 
[realms] 
LX.DR.DK = { 
kdc = ipa01.lx.dr.dk 
} 
[domain_realm] 
.lx.dr.dk = LX.DR.DK 
lx.dr.dk = LX.DR.DK 


When trying to authenticate on web-ui I see: 

krb5kdc.log on IPA server shows: 

Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3349](info): AS_REQ (2 etypes {18 18}) 
10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, 
HTTP/ssotst01pack.lx.dr...@lx.dr.dk for krbtgt/lx.dr...@lx.dr.dk 
Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3349](info): AS_REQ (2 etypes {18 18}) 
10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, 
HTTP/ssotst01pack.lx.dr...@lx.dr.dk for krbtgt/lx.dr...@lx.dr.dk 
Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3353](info): AS_REQ (2 etypes {18 18}) 
10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, 
HTTP/ssotst01pack.lx.dr...@lx.dr.dk for krbtgt/lx.dr...@lx.dr.dk 
Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3353](info): AS_REQ (2 etypes {18 18}) 
10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, 
HTTP/ssotst01pack.lx.dr...@lx.dr.dk for krbtgt/lx.dr...@lx.dr.dk 
Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3353](info): AS_REQ (2 etypes {18 18}) 
10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, 
HTTP/ssotst01pack.lx.dr...@lx.dr.dk for krbtgt/lx.dr...@lx.dr.dk 

Java shows: 

[2017-02-22T14:17:06.666+01:00] [oam_server1] [ERROR] [] 
[oracle.oam.engine.authn] [tid: [ACTIVE].ExecuteThread: '0' for queue: 
'weblogic.kernel.Default (self-tuning)'] [userId: ] [ecid: 
236b75b1bd93b747:4e356648:15a65f5a492:-8000-00db,0] [APP: 
oam_server#11.1.2.0.0] Failure unspecified at GSS-API level (Mechanism level: 
Specified version of key is not available (44))[[ 
GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified 
version of key is not available (44)) 

(Not same time, I know. Log files from different days). 

>From what I can see on the krb5 log it tries to make 5 auth requests, but 
>fails with "Specified version of key is not available", however, they are 
>I have already verified this and tried exporting new ones just to make sure. 

The unlimited encryption package have been added to Java. 

Does these errors mean anything for some expert on this list, as i'm starting 
to run out of ideas.. 

-- 


Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

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

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

Re: [Freeipa-users] New install, unsupported format?

[Standa Laznicka]

On 02/24/2017 08:38 PM, Steve Huston wrote:

So, I tried a different tack.  Took my bare VM configured as an IPA
client, did a 'yum install ipa-server' and edited the cainstance.py
file to fix the IPv6 issue.  Then, without adding the host to
ipaservers in the webui, I simply tried to promote it:

# kinit admin
Password for ad...@astro.princeton.edu:
# ipa-replica-install --verbose
ipa.ipapython.install.cli.install_tool(Replica): DEBUGLogging to
/var/log/ipareplica-install.log
ipa.ipapython.install.cli.install_tool(Replica): DEBUG
ipa-replica-install was invoked with arguments [] and options:
{'no_dns_sshfp': None, 'skip_schema_check': None, 'setup_kra': None,
'ip_addresses': None
, 'mkhomedir': None, 'http_cert_files': None, 'ssh_trust_dns': None,
'reverse_zones': None, 'no_forwarders': None, 'keytab': None,
'no_ntp': None, 'domain_name': None, 'http_cert_name': None,
'dirsrv_cert_files
': None, 'no_dnssec_validation': None, 'no_reverse': None,
'unattended': False, 'auto_reverse': None, 'auto_forwarders': None,
'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None,
'dirsrv_config_file':
  None, 'forwarders': None, 'verbose': True, 'setup_ca': None,
'realm_name': None, 'skip_conncheck': None, 'no_ssh': None,
'forward_policy': None, 'dirsrv_cert_name': None, 'quiet': False,
'server': None, 'setup_dns': None, 'host_name': None, 'log_file':
None, 'allow_zone_overlap': None}
ipa.ipapython.install.cli.install_tool(Replica): DEBUGIPA version
4.4.0-14.el7_3.4
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/selinuxenabled
ipa : DEBUGProcess finished, return code=0
ipa : DEBUGstdout=
ipa : DEBUGstderr=
ipa : DEBUGLoading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
ipa : DEBUGLoading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
ipa : DEBUGhttpd is not configured
ipa : DEBUGkadmin is not configured
ipa : DEBUGdirsrv is not configured
ipa : DEBUGpki-tomcatd is not configured
ipa : DEBUGinstall is not configured
ipa : DEBUGkrb5kdc is not configured
ipa : DEBUGntpd is not configured
ipa : DEBUGnamed is not configured
ipa : DEBUGipa_memcached is not configured
ipa : DEBUGfilestore is tracking no files
ipa : DEBUGLoading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa : DEBUGConfiguring client side components
Configuring client side components
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/ipa-client-install --unattended --no-ntp
IPA client is already configured on this system.
If you want to reinstall the IPA client, uninstall it first using
'ipa-client-install --uninstall'.
ipa : DEBUGProcess finished, return code=3
Removing client side components
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/ipa-client-install --unattended
--uninstall
Unenrolling client from IPA server
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to
/etc/sssd/sssd.conf.deleted
nslcd daemon is not installed, skip configuration
Client uninstall complete.
ipa : DEBUGProcess finished, return code=0

ipa.ipapython.install.cli.install_tool(Replica): 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 318, in run
 cfgr.run()
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 308, in run
 self.validate()
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 317, in validate
 for nothing in self._validator():
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 372, in __runner
 self._handle_exception(exc_info)
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 394, in _handle_exception
 six.reraise(*exc_info)
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 362, in __runner
 step()
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 359, in 
 step = lambda: next(self.__gen)
   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 81, in run_generator_with_yield_from
 six.reraise(*exc_info)
   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 59, in run_generator_with_yield_from
 value = gen.send(prev_value)
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 564, in _configure
 next(validator)
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 372, in __runner
 self._handle_exception(exc_info)
   File 

Re: [Freeipa-users] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring

[Martin Basti]

On 26.02.2017 07:35, Jochen Hein wrote:

Jochen Hein  writes:


I'm implementing logcheck on my server and found the following message
in my logs:


Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' is 
not supported, ignoring

| Updates and Upgrades
|
| Replace serial_autoincrement option in /etc/named.conf with serial_remote 
option.
| Dependencies
`

I just tried that and got a message that serial_remote is unknown.
I run a current CentOS 7.3 server.

Jochen


Hello,

the documentation you found is old, it may be applicable to RHEL6.
For current configuration options see section "5.1 Configuration 
options" in https://pagure.io/bind-dyndb-ldap

You can safely remove serial_autoincrement option form your config.

Martin

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

Re: [Freeipa-users] named-pkcs11: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute; cnamerecord': unknown class/type

[Martin Basti]

On 26.02.2017 07:37, Jochen Hein wrote:

When reloading named I get the following message 8 times:

Feb 26 05:30:27 freeipa2 named-pkcs11[4935]: dns_rdatatype_fromtext()
failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown
class/type

I do have cnames in my zones, but what is missing here?
DNS seems to work fine for CNAMEs.

I'm running CentOS 7.3.

Jochen



Hello, you can safely ignore this message, this is template for creating 
location records we just failed to get rid of that message.


Martin

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