Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Martin Bašti 
It will create clone of the original CA, it will work as backup not a 
separate CA.


I'm afraid it will result into the same behavior because it uses almost 
the same code, but as I said before this issue is on dogtag side and not 
always reproducible.



On 18.05.2017 14:44, Callum Guy wrote:

Thanks for that Martin.

The man page for ipa-ca-install suggests i could pass in my replica 
file to create a "CA-less" configuration. Is this what i want or is a 
CA-full appropriate? All I want to achieve is the additional 
resilience provided by a replica which can both authorise and sign 
certificates in the event of a loss of the master server. I certainly 
don't want an entirely separate CA to be installed - my anticipation 
is that my replica will be able to become an intermediate authority - 
is that the intended arrangement for a replica?


Finally, do you hold out much hope that ipa-ca-install will work any 
better than --setup-ca flag I was attempting to get working for the 
replica install? If its the same code I would probably just end up 
with a half configured CA and have to rebuild my replica - something I 
would like to avoid repeating after the last couple of days!


On Thu, May 18, 2017 at 1:28 PM Martin Bašti <mailto:mba...@redhat.com>> wrote:


ipa-ca-install will install on top of FreeIPA CA-less replica,
nothing else, you really don't want to do it manually.


On 18.05.2017 14:12, Callum Guy wrote:

Thanks Martin, really appreciate the additional information.

Are you aware of a separate guide for installing DogTag/PKI on
top of FreeIPA - basically I am happy to install separately if it
doesn't compromise the FreeIPA server configuration, i'm not
clear on whether this is possible without a major time investment.

On Thu, May 18, 2017 at 12:46 PM Martin Bašti mailto:mba...@redhat.com>> wrote:


Please note that commits in #6766 will not fix this issue,
the issue is on dogtag side, please see
https://pagure.io/dogtagpki/issue/2646

Sorry for troubles


On 18.05.2017 12:19, Callum Guy wrote:

Haha, looks like i'm going CA-less for a while on the
replica. I don't see any immediate requirement for one so
time to get on with my life!

I'll post back if anything changes but I'm probably stuck
waiting for the upgrade too..

On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman
mailto:data...@gmail.com>> wrote:

Sorry cobber. We only found 6766 today - we've been
tackling it on and off for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for
collective action, to build collective power, to achieve
collective transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:53, Callum Guy
mailto:callum@x-on.co.uk>>
wrote:

Ah, thanks for that Lachlan - its always reassuring
to hear that its not just me!

As mentioned above I have it running without the CA
so that's a good start. I am sure we will upgrade as
well once 4.5 becomes stable and GA for CentOS. I'm
not expecting that to happen quickly so will have to
work with what we have for now.

Do you happen to know if there is any way to build
the CA component separately?

On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman
mailto:data...@gmail.com>> wrote:

https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and
inspiration for collective action, to build
collective power, to achieve collective
transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:34, Lachlan Musicman
mailto:data...@gmail.com>>
wrote:

We are seeing this. I'm not at work, but I
think it's bug report 6766.

Patch has already been committed (bot by
us), we're waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and
inspiration for collective

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Martin Bašti 
ipa-ca-install will install on top of FreeIPA CA-less replica, nothing 
else, you really don't want to do it manually.



On 18.05.2017 14:12, Callum Guy wrote:

Thanks Martin, really appreciate the additional information.

Are you aware of a separate guide for installing DogTag/PKI on top of 
FreeIPA - basically I am happy to install separately if it doesn't 
compromise the FreeIPA server configuration, i'm not clear on whether 
this is possible without a major time investment.


On Thu, May 18, 2017 at 12:46 PM Martin Bašti <mailto:mba...@redhat.com>> wrote:



Please note that commits in #6766 will not fix this issue, the
issue is on dogtag side, please see
https://pagure.io/dogtagpki/issue/2646

Sorry for troubles


On 18.05.2017 12:19, Callum Guy wrote:

Haha, looks like i'm going CA-less for a while on the replica. I
don't see any immediate requirement for one so time to get on
with my life!

I'll post back if anything changes but I'm probably stuck waiting
for the upgrade too..

On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman
mailto:data...@gmail.com>> wrote:

Sorry cobber. We only found 6766 today - we've been tackling
it on and off for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for
collective action, to build collective power, to achieve
collective transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:53, Callum Guy mailto:callum@x-on.co.uk>> wrote:

Ah, thanks for that Lachlan - its always reassuring to
hear that its not just me!

As mentioned above I have it running without the CA so
that's a good start. I am sure we will upgrade as well
once 4.5 becomes stable and GA for CentOS. I'm not
expecting that to happen quickly so will have to work
with what we have for now.

Do you happen to know if there is any way to build the CA
component separately?

On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman
mailto:data...@gmail.com>> wrote:

https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and inspiration
for collective action, to build collective power, to
achieve collective transformation, rooted in grief
and rage but pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:34, Lachlan Musicman
mailto:data...@gmail.com>> wrote:

We are seeing this. I'm not at work, but I think
it's bug report 6766.

Patch has already been committed (bot by us),
we're waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and
inspiration for collective action, to build
collective power, to achieve collective
transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 18:57, Callum Guy
mailto:callum@x-on.co.uk>> wrote:

Hi All,

I am currently stuck trying to setup the
first replica of our master IPA server. I
have tried a number of different approaches
including escalating from a client and
nothing is working for me. I perform a full
OS reset each time I get stuck.

I'm running CentOS 7.2 with the FreeIPA 4.4.0
(rpm -q reports this version however having
performed ipa-server-upgrade - does this mean
i'm on 4.4.4?).

The command is shown below - note that i am
skipping the conn check as my platforms
security settings do not allow the SSH
session to be established back on the master,
all ports should be available to the
application however.

[root@ipa2 ~]# ipa-replica-install
--ip-address=172.24.0.101 --setup-ca
--setup

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Martin Bašti 
 110 London
Road, Apsley, Hemel Hempstead, Herts, HP3 9SD.
Company Registration No. 2578478.
The information in this e-mail is confidential and
for use by the addressee(s) only. If you are not
the intended recipient, please notify X-on
immediately on +44(0)333 332 
 and delete the
message from your computer. If you are not a named
addressee you must not use, disclose, disseminate,
distribute, copy, print or reply to this email.
Views or opinions expressed by an individual
within this email may not necessarily reflect the
views of X-on or its associated companies.
Although X-on routinely screens for viruses,
addressees should scan this email and any attachments
for viruses. X-on makes no representation or
warranty as to the absence of viruses in this
email or any attachments.


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





*^0333 332   | www.x-on.co.uk <http://www.x-on.co.uk> |
_**_^<https://www.linkedin.com/company/x-on>
<https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited
company registered in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley,
Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by
the addressee(s) only. If you are not the intended recipient,
please notify X-on immediately on +44(0)333 332 
 and delete the
message from your computer. If you are not a named addressee
you must not use, disclose, disseminate, distribute, copy,
print or reply to this email. Views or opinions expressed by
an individual
within this email may not necessarily reflect the views of
X-on or its associated companies. Although X-on routinely
screens for viruses, addressees should scan this email and any
attachments
for viruses. X-on makes no representation or warranty as to
the absence of viruses in this email or any attachments.




*^0333 332   | www.x-on.co.uk <http://www.x-on.co.uk>  | 
_**_^<https://www.linkedin.com/company/x-on> 
<https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company 
registered in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel 
Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the 
addressee(s) only. If you are not the intended recipient, please 
notify X-on immediately on +44(0)333 332  and delete the
message from your computer. If you are not a named addressee you must 
not use, disclose, disseminate, distribute, copy, print or reply to 
this email. Views or opinions expressed by an individual
within this email may not necessarily reflect the views of X-on or its 
associated companies. Although X-on routinely screens for viruses, 
addressees should scan this email and any attachments
for viruses. X-on makes no representation or warranty as to the 
absence of viruses in this email or any attachments.






--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] IMPORTANT: Migration of FreeIPA-users list to lists.fedorahosted.org

2017-05-18 Thread Martin Bašti 

Dear FreeIPA-users subscribers,

due to various issues with the current mailing lists, the FreeIPA-users 
list is being migrated to a new provider, lists.fedorahosted.org.



Information about the new list:

E-mail address: freeipa-us...@lists.fedorahosted.org
Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/ 


List-Id: FreeIPA users list 


All subscribers will be automatically subscribed to the new mailing 
list, please update your email filters in advance.

The mass subscription will be done in 24 hours.

This mailing list will be set to read-only mode after migration.

Sorry for inconvenience,
Your FreeIPA developers

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] Fresh Install of FreeIPA-Server - CentOS7

2017-05-12 Thread Martin Bašti 

That's weird, it should be super fast, anything in /var/log/httpd/error_log?


On 11.05.2017 22:23, Robert L. Harris wrote:


Odd, must have clicked reply instead of reply-all.

Anyway, I did the revert and re-install.  Actual install went through 
fine then the "ipa-server-install" ran until this:


  [8/9]: restoring configuration
  [9/9]: starting directory server
Done.
Restarting the directory server
Restarting the KDC
Please add records in this file to your DNS system: 
/tmp/ipa.system.records.v5Jwrt.db

Restarting the web server
Configuring client side components
Using existing certificate '/etc/ipa/ca.crt'.
Client hostname: ipa.rdlg.net <http://ipa.rdlg.net>
Realm: RDLG.NET <http://RDLG.NET>
DNS Domain: rdlg.net <http://rdlg.net>
IPA Server: ipa.rdlg.net <http://ipa.rdlg.net>
BaseDN: dc=rdlg,dc=net

Skipping synchronizing time with NTP server.
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
trying https://ipa.rdlg.net/ipa/json
Forwarding 'schema' to json server 'https://ipa.rdlg.net/ipa/json'


It's been sitting there for a while ( 4 hours? )  I don't see anyting 
in the ipaserver-install.log, but it's here: https://pastebin.com/biK1Dmv7




On Thu, May 11, 2017 at 8:12 AM Martin Bašti <mailto:mba...@redhat.com>> wrote:


Please keep freeipa-users in CC

Snapshot is always better, so I suggest to use it. Otherwise there
is an option --ignore-last-of-role to unblock uninstallation.

Martin


On 11.05.2017 16:00, Robert L. Harris wrote:


Looks like you hit it, apache didn't have a group:

-- Logs begin at Wed 2017-05-10 19:56:27 MDT, end at Thu
2017-05-11 07:48:27 MDT. --
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]:
Starting The Apache HTTP Server...
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net>
ipa-httpd-kdcproxy[28808]: ipa : INFO KDC proxy enabled
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> httpd[28809]:
AH00544: httpd: bad group name apache
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]:
httpd.service: main process exited, code=exited, status=1/FAILURE
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> kill[28812]:
kill: cannot find process ""
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]:
httpd.service: control process exited, code=exited status=1
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]:
Failed to start The Apache HTTP Server.
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]:
Unit httpd.service entered failed state.
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]:
httpd.service failed.

Thanks, didn't know that command.  I tried to continue the process:

{0}:/root>ipa-server-install

The log file for this installation can be found in
/var/log/ipaserver-install.log
ipa.ipapython.install.cli.install_tool(Server): ERRORIPA
server is already configured on this system.
If you want to reinstall the IPA server, please uninstall it
first using 'ipa-server-install --uninstall'.
ipa.ipapython.install.cli.install_tool(Server): ERRORThe
ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information

root@ipa
{1}:/root>ipa-server-install  --uninstall

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

Are you sure you want to continue with the uninstall procedure?
[no]: yes
ipa : ERRORServer removal aborted: Deleting this
server is not allowed as it would leave your installation without
a CA..



This is a VM and I took a snapshot right before I started the
install, so I can revert, just make sure ti add the apache user
before starting the install. Or if you have a better command to
continue the clean-up/install.


On Thu, May 11, 2017 at 2:19 AM Martin Bašti mailto:mba...@redhat.com>> wrote:

Hello,

comments inline


On 11.05.2017 06:06, Robert L. Harris wrote:


Sigh... Sorry, it's been a long day, I thought I put that
log in the first pastebin.  It's in this one:
https://pastebin.com/18PAXXNS


Could you please provide journalctl -u httpd and
/var/log/httpd/error_log ?





Also,
   Anyone else get the constant spam when mailing this
list?  Got an address to block for it?


Sorry for that, there is a bot mining public archives. We
plan to resolve this issue but it may take time as we are not
maintaining our mailman.

Martin




Robert




On Wed, May 10, 2017 at 9:56 PM Lachlan Musicman
mailto

Re: [Freeipa-users] Fresh Install of FreeIPA-Server - CentOS7

2017-05-11 Thread Martin Bašti 

Please keep freeipa-users in CC

Snapshot is always better, so I suggest to use it. Otherwise there is an 
option --ignore-last-of-role to unblock uninstallation.


Martin


On 11.05.2017 16:00, Robert L. Harris wrote:


Looks like you hit it, apache didn't have a group:

-- Logs begin at Wed 2017-05-10 19:56:27 MDT, end at Thu 2017-05-11 
07:48:27 MDT. --
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]: 
Starting The Apache HTTP Server...
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> 
ipa-httpd-kdcproxy[28808]: ipa : INFO KDC proxy enabled
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> httpd[28809]: 
AH00544: httpd: bad group name apache
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]: 
httpd.service: main process exited, code=exited, status=1/FAILURE
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> kill[28812]: kill: 
cannot find process ""
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]: 
httpd.service: control process exited, code=exited status=1
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]: Failed 
to start The Apache HTTP Server.
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]: Unit 
httpd.service entered failed state.
May 10 20:36:00 ipa.rdlg.net <http://ipa.rdlg.net> systemd[1]: 
httpd.service failed.


Thanks, didn't know that command.  I tried to continue the process:

{0}:/root>ipa-server-install

The log file for this installation can be found in 
/var/log/ipaserver-install.log
ipa.ipapython.install.cli.install_tool(Server): ERROR  IPA server is 
already configured on this system.
If you want to reinstall the IPA server, please uninstall it first 
using 'ipa-server-install --uninstall'.
ipa.ipapython.install.cli.install_tool(Server): ERROR  The 
ipa-server-install command failed. See /var/log/ipaserver-install.log 
for more information


root@ipa
{1}:/root>ipa-server-install  --uninstall

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


Are you sure you want to continue with the uninstall procedure? [no]: yes
ipa : ERRORServer removal aborted: Deleting this server is 
not allowed as it would leave your installation without a CA..




This is a VM and I took a snapshot right before I started the install, 
so I can revert, just make sure ti add the apache user before starting 
the install.  Or if you have a better command to continue the 
clean-up/install.



On Thu, May 11, 2017 at 2:19 AM Martin Bašti <mailto:mba...@redhat.com>> wrote:


Hello,

comments inline


On 11.05.2017 06:06, Robert L. Harris wrote:


Sigh... Sorry, it's been a long day, I thought I put that log in
the first pastebin.  It's in this one: https://pastebin.com/18PAXXNS


Could you please provide journalctl -u httpd and
/var/log/httpd/error_log ?





Also,
   Anyone else get the constant spam when mailing this list?  Got
an address to block for it?


Sorry for that, there is a bot mining public archives. We plan to
resolve this issue but it may take time as we are not maintaining
our mailman.

Martin




Robert




On Wed, May 10, 2017 at 9:56 PM Lachlan Musicman
mailto:data...@gmail.com>> wrote:

Robert, did you look in /var/log/ipaserver-install.log as it
says?

Was there any other information?

cheers
L.

--
"Mission Statement: To provide hope and inspiration for
collective action, to build collective power, to achieve
collective transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 11 May 2017 at 13:24, Robert L. Harris
mailto:robert.l.har...@gmail.com>> wrote:

Ok,  I gave up on Ubuntu.  I'm now trying the latest
CentOS7.  I built out a "minimal server" with some normal
base packages which did include the freeipa-client but
otherwise, just standard tools.  Here's a pastebin of the
output of the install: https://pastebin.com/zAWCgkUU

Robert


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





-- 
Martin Bašti

Software Engineer
Red Hat Czech



--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] Fresh Install of FreeIPA-Server - CentOS7

2017-05-11 Thread Martin Bašti 

Hello,

comments inline


On 11.05.2017 06:06, Robert L. Harris wrote:


Sigh... Sorry, it's been a long day, I thought I put that log in the 
first pastebin.  It's in this one: https://pastebin.com/18PAXXNS


Could you please provide journalctl -u httpd and /var/log/httpd/error_log ?




Also,
   Anyone else get the constant spam when mailing this list?  Got an 
address to block for it?


Sorry for that, there is a bot mining public archives. We plan to 
resolve this issue but it may take time as we are not maintaining our 
mailman.


Martin



Robert




On Wed, May 10, 2017 at 9:56 PM Lachlan Musicman <mailto:data...@gmail.com>> wrote:


Robert, did you look in /var/log/ipaserver-install.log as it says?

Was there any other information?

cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective
action, to build collective power, to achieve collective
transformation, rooted in grief and rage but pointed towards
vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 11 May 2017 at 13:24, Robert L. Harris
mailto:robert.l.har...@gmail.com>> wrote:

Ok,  I gave up on Ubuntu.  I'm now trying the latest CentOS7. 
I built out a "minimal server" with some normal base packages

which did include the freeipa-client but otherwise, just
standard tools. Here's a pastebin of the output of the
install: https://pastebin.com/zAWCgkUU

Robert


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





--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] Domain Levels

2017-05-11 Thread Martin Bašti 



On 10.05.2017 22:42, Michael Plemmons wrote:
I am currently running 4.4.0 on a three node cluster.  My domain level 
is currently 0 on all three nodes.  Is there a reason to keep the 
domain level at 0?  I do not plan on adding any older versions of IPA 
into the cluster.  Is there anything I need to worry about if I 
elevate the domain level to 1?


My current setup is the server A is the master and B and C are 
replicas.  I do not have replication agreements between B and C and I 
am looking into creating those agreements.  If I increase the domain 
level do I have to handle anything differently if I add the B to C 
replication agreement?



*Mike Plemmons | Senior DevOps Engineer | CROSSCHX
*
614.427.2411
mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
www.crosschx.com <http://www.crosschx.com/>




Hello,
we recommend to raise DL to 1, it opens new functionality.

With DL1 you can create that replication agreement via webUI, and you 
will see your replication topology, so no more ipa-replica-manage for 
connecting replicas.


Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] DNS update failing

2017-05-11 Thread Martin Bašti 
://testbook3.int.dplcl.com>.
86400INA10.0.1.36



Reply from update query:

;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:  33167

;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0

;; ZONE SECTION:

;int.dplcl.com <http://int.dplcl.com>.INSOA
-- 



*Jason Sherrill*
Deeplocal Inc. <http://deeplocal.com/>
mobile: 412-636-2073 
office: 412-362-0201 





Hello,

DNS updates are using GSS-TSIG mechanism by default in FreeIPA, so you 
cannot use plain nsupdate without providing credentials


Here is policy, hosts can update only its records using GSS-TSIG (kerberos)

BIND update policy: grant INT.DPLCL.COM <http://INT.DPLCL.COM> krb5-self 
* A; grant INT.DPLCL.COM <http://INT.DPLCL.COM> krb5-self * ; grant 
INT.DPLCL.COM <http://INT.DPLCL.COM> krb5-self *


 SSHFP;

So for manual updates via nsupdate, you have to do following steps:

1, kinit -kt /etc/krb5.keytab

2, nsupdate -g

... update A records ...

I don't know why a reverse zone works for you, you should check policy 
of the reverse zone.


Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] "Purge" scripts?

2017-04-27 Thread Martin Bašti 



On 26.04.2017 20:07, Robert L. Harris wrote:
  So twice now I've tried installing freeipa on an Ubuntu 16.04 
system.  Both times I've gotten an error and followed the instructions 
to "fix it" and they didn't work so I removed files ( with purge ), 
cleaned up everything I could find related to freeipa, sssd and kerb 
but trying to run it again gives either a different error or the same 
error with a different process output indicating it's not 100% clean.


   Is there a known list of paths, packages or files to make sure are 
un-installed or wiped out to make the system 100% clean?  Preferably 
for Ubuntu.


Robert





Hello, could you be more specific about the errors?

Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] weird conflicts in AWS EC2 install

2017-04-25 Thread Martin Bašti 
FreeIPA conflicts shouldn't prevent installing of other packages. For me 
it looks like "python-zope-interface" is missing.



On 25.04.2017 16:27, Kat wrote:
Yes- this comes after IPA is installed and running (this is actually a 
client upgraded to a master-replica). Then trying to install 
Let'sEncrypt gives the error:


yum install -y letsencrypt

That is when the conflict errors occur. The problem with "ignoring", 
is that you can't force yum to just do the install anyway unless you 
download the packages directly and use rpm to install. Is that the 
suggestion here?


Thanks


On 4/25/17 9:22 AM, Martin Bašti wrote:

Hello,

comments inline


On 25.04.2017 16:06, Kat wrote:

Hi all,

Trying to get letsencrypt working for an AWS instance of FreeIPA - 
and run into an odd conflict I have not dealt with before. When 
trying to install Let's Encrypt after a clean install of IPA, I am 
seeing:


--> Finished Dependency Resolution
Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel)
   Requires: python-zope-interface
Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel)
   Requires: python-zope-interface
 You could try using --skip-broken to work around the problem



These packages are not needed for freeipa. So it may be broken 
dependency of letsencrypt?



** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows:
ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch
ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts 
freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64
ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch
ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch
ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts 
freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64
ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch


Any ideas? Maybe this is something known in the AWS world?

Thanks
Kat



Yum check gives false positive errors about IPA packages, this will 
be fixed in RHEL7.4. You can safely ignore those warnings.






--
Martin Bašti
Software Engineer
Red Hat Czech

--
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] weird conflicts in AWS EC2 install

2017-04-25 Thread Martin Bašti 

Hello,

comments inline


On 25.04.2017 16:06, Kat wrote:

Hi all,

Trying to get letsencrypt working for an AWS instance of FreeIPA - and 
run into an odd conflict I have not dealt with before. When trying to 
install Let's Encrypt after a clean install of IPA, I am seeing:


--> Finished Dependency Resolution
Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel)
   Requires: python-zope-interface
Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel)
   Requires: python-zope-interface
 You could try using --skip-broken to work around the problem



These packages are not needed for freeipa. So it may be broken 
dependency of letsencrypt?



** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows:
ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch
ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts 
freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64
ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch
ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch
ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts 
freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64
ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts 
freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch


Any ideas? Maybe this is something known in the AWS world?

Thanks
Kat



Yum check gives false positive errors about IPA packages, this will be 
fixed in RHEL7.4. You can safely ignore those warnings.


--
Martin Bašti
Software Engineer
Red Hat Czech

--
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] DNSSEC warning when DNSSEC should be disabled

2017-04-25 Thread Martin Bašti 



On 24.04.2017 20:22, Dan Dietterich wrote:


I still think there is something wrong here.

You say that the DNSSEC reply is "just warning", but when I get that 
warning, a subsequent trust-add fails every time. When I don't get the 
warning, the trust-add works.


Therefore, the warning cannot just be ignored. Why is that?

If you have disabled DNSSEC validation then the issue is probably 
somewhere else in DNS. The check is not 100% reliable, sometimes it may 
false positively report DNSSEC issues when there is a different DNS issue.


Please try to "dig" AD domain and check if records are correct, also 
check if FreeIPA domain is accessible from AD side.


Also in case of failure please check journalctl -u named-pkcs11 log on 
FreeIPA server, there might be additional information.



I have tried the following:

-Signing the target Active Directory zone – it does not make a difference


Then there is a different issue than DNSSEC IMO

-FreeIPA /etc/named.conf – "validation no" makes the warning go away 
ONLY when I use the CLI on a root login.


This check is done on server side, so there is no difference between 
CLI/webUI or used user


-Running the ipa CLI from a salt state or a subprocess of my Java 
webapp ALWAYS gets the warning regardless.


If there really should be a warning, then why don't I see it from the CLI?

And can you help me understand what would be significantly different 
between an interactive login and a "su –l root" in salt?


Thank you for any insight,

Dan

*From: *Dan Dietterich 
*Date: *Wednesday, April 19, 2017 at 9:24 AM
*To: *Martin Bašti , "freeipa-users@redhat.com" 

*Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should be 
disabled


*From: *Martin Bašti 
*Date: *Wednesday, April 19, 2017 at 9:23 AM
*To: *Dan Dietterich , "freeipa-users@redhat.com" 

*Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should be 
disabled


IPA servers always check if DNSSEC is working on forwarders, but it is 
just warning. If you have disabled  dnssec in named.conf then it is okay.


I'm not sure why sometimes you see this warning and sometimes don't, 
maybe inconsistent replies from forwarder.


domain ".internal" should always fail because it is unregistered TLD

Martin

On 19.04.2017 15:11, Dan Dietterich wrote:

My configuration is a single ipa server and both the code path and
the bash prompt path are running on the node that is also running
the ipa server. I thought that since FreeIPA was installed with
--no-dnssec-validation that I should never see this warning. And I
confirmed that both dnssec-enabled and dnssec-validation are set
to 'no' in the /etc/named.conf.

So I'm confused that you say the DNSSEC should always fail.

Thanks for your help!

*From: *Martin Bašti  <mailto:mba...@redhat.com>
*Date: *Wednesday, April 19, 2017 at 3:59 AM
*To: *Dan Dietterich  <mailto:d...@cazena.com>,
"freeipa-users@redhat.com" <mailto:freeipa-users@redhat.com>
 <mailto:freeipa-users@redhat.com>
*Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should
be disabled

On 13.04.2017 22:50, Dan Dietterich wrote:

I am seeing inconsistent results configuring a DNS forward zone.

At a bash prompt, as root, after kinit admin, I do:

ipa dnsforwardzone-add domain.internal  --forwarder=
ww.xx.yy.zz --forward-policy=only

That works fine and does not warn about DNSSEC.

In a Java webapp running as root under a Jetty, I run a shell
sub-process and issue the kinit and the same ipa statement.

_/Sometimes/_, I get

ipa: WARNING: DNSSEC validation failed: record
'domain.internal. SOA' failed DNSSEC validation on server
ww.xx.yy.zz.

Please verify your DNSSEC configuration or disable DNSSEC
validation on all IPA servers.

I modified the /etc/named.conf file to say:

dnssec-enable no;

dnssec-validation no;

and systemctl restart ipa

Any clue why the results are different?

ipa –version: VERSION: 4.4.0, API_VERSION: 2.213

Linux … 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Thanks for any insight!

Regards,

Dan





Hello,

checks are done on IPA server side, how many servers do you have?
Is possible that CLI connects to different servers.

    However in this case, DNSSEC check should always fail and report
error, so it is weird why it passed.

    Martin


-- 


Martin Bašti

Software Engineer

Red Hat Czech



--
Martin Bašti
Software Engineer
Red Hat Czech


--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] SSSD dyndns_update on machine with multiple IP address

2017-04-20 Thread Martin Bašti 



On 19.04.2017 17:14, David Goudet wrote:


On 04/19/2017 12:31 PM, Martin Bašti wrote:



On 17.04.2017 19:42, David Goudet wrote:

Hi,

Nobody has response about my questions?

The main question is: Is it possible to configure SSSD to update DNS 
(option dyndns_update) with only IP address "primary" in ip addr 
list or which is used to FreeIPA server communication (-IP1- used on 
TCP binding)?


Thank you for your help.

Best regards,

On 03/27/2017 09:40 PM, Jakub Hrozek wrote:

On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote:

Hi,

Thanks to dyndns_update=True parameter, SSSD service on client machine 
updating host DNS entry in FreeIPA.
Everything is fine on machines which have only one IP adress on network 
interface.
I have problem with machines which have more that one IP address on 
network interface: if machine have two IP address, SSSD update host DNS entry 
with these two IP address.

To reproduce the problem:
Host have -IP1- and i add -IP2-
ip addr add -IP2-/26 dev em1

ip addr list:
em1:  mtu 1496 qdisc mq state UP qlen 
1000
  link/ether 
  inet -IP1-/26 brd  scope global em1
  inet -IP2-/26 scope global secondary em1
 valid_lft forever preferred_lft forever

DNS resolution (dig) before restarting sssd returns only -IP1-. After 
restarting sssd returns -IP1- & -IP2-

In dyndns_update manpage, we have "The IP address of the IPA LDAP connection 
is used for the updates", what does it means? Is it IP address of the DNS server 
(used to update the DNS entry)? or is it IP address on client machine used during LDAP 
TCP bind (-IP1- in my case)?

dyndns_update (boolean)
 Optional. This option tells SSSD to automatically update 
the DNS server built into FreeIPA v2 with the IP address of this client.
 The update is secured using GSS-TSIG. The IP address of 
the IPA LDAP connection is used for the updates, if it is not otherwise
 specified by using the “dyndns_iface” option.

Is it normal behaviour that SSSD add in host DNS entry every IPs 
enabled on client machine?

IIRC we added this to support multiple interfaces (user can choose 
which one to use) and to update both IPv6 () and IPv4 (A) 
records. IPA/SSSD cannot reliably determine which IP address to use, 
it is all or none from interface. With the previous behavior users 
want to use different/more addresses than the one which has been 
detected from LDAP connection and it was not possible previously.

Do you have set  dyndns_iface in sssd.conf?

Martin

Looks like this was a deliberate change:
  https://pagure.io/SSSD/sssd/issue/2558
but to be honest, I forgot why exactly we did this. Martin, do you know?

Is it possible to configure SSSD to update DNS with only IP address 
"primary" in ip addr list or which is used to FreeIPA server communication 
(-IP1- used on TCP binding)?

Only if the IP addresses are of different families (v4/v6), then it's
possible to restrict one of the families.





I asked question here

https://www.redhat.com/archives/freeipa-users/2017-March/msg00360.html





Hi,

Thank you for your response.

In sssd.conf parameter dyndns_iface is not defined, we are in case:
Default: Use the IP addresses of the interface which is used for IPA 
LDAP connection


This point (dyndns_iface) is ok, every IPs of this interface and only 
this interface is updated on IPA host DNS entry.
I use only IPv4, so it is not possible to filter on only one IP 
("primary") it is "none" or "all" on one interface.


In my case i see two solutions:
- Split IP "primary" on one interface (bond0 for exemple) and other 
virtual IPs on one other interface (bond0.1 or bond1 for exemple)

- Disable dyndns_update functionality on this machine

You confirm, i have no other solutions?




Well, then you have only choices you wrote. Sorry.

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] DNSSEC warning when DNSSEC should be disabled

2017-04-19 Thread Martin Bašti 
IPA servers always check if DNSSEC is working on forwarders, but it is 
just warning. If you have disabled  dnssec in named.conf then it is okay.


I'm not sure why sometimes you see this warning and sometimes don't, 
maybe inconsistent replies from forwarder.


domain ".internal" should always fail because it is unregistered TLD

Martin


On 19.04.2017 15:11, Dan Dietterich wrote:


My configuration is a single ipa server and both the code path and the 
bash prompt path are running on the node that is also running the ipa 
server. I thought that since FreeIPA was installed with 
--no-dnssec-validation that I should never see this warning. And I 
confirmed that both dnssec-enabled and dnssec-validation are set to 
'no' in the /etc/named.conf.


So I'm confused that you say the DNSSEC should always fail.

Thanks for your help!

*From: *Martin Bašti 
*Date: *Wednesday, April 19, 2017 at 3:59 AM
*To: *Dan Dietterich , "freeipa-users@redhat.com" 

*Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should be 
disabled


On 13.04.2017 22:50, Dan Dietterich wrote:

I am seeing inconsistent results configuring a DNS forward zone.

At a bash prompt, as root, after kinit admin, I do:

ipa dnsforwardzone-add domain.internal  --forwarder= ww.xx.yy.zz
--forward-policy=only

That works fine and does not warn about DNSSEC.

In a Java webapp running as root under a Jetty, I run a shell
sub-process and issue the kinit and the same ipa statement.

_/Sometimes/_, I get

ipa: WARNING: DNSSEC validation failed: record 'domain.internal.
SOA' failed DNSSEC validation on server ww.xx.yy.zz.

Please verify your DNSSEC configuration or disable DNSSEC
validation on all IPA servers.

I modified the /etc/named.conf file to say:

dnssec-enable no;

dnssec-validation no;

and systemctl restart ipa

Any clue why the results are different?

ipa –version: VERSION: 4.4.0, API_VERSION: 2.213

Linux … 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux

Thanks for any insight!

Regards,

Dan




Hello,

checks are done on IPA server side, how many servers do you have? Is 
possible that CLI connects to different servers.


However in this case, DNSSEC check should always fail and report 
error, so it is weird why it passed.


Martin

--
Martin Bašti
Software Engineer
Red Hat Czech


--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] SSSD dyndns_update on machine with multiple IP address

2017-04-19 Thread Martin Bašti 
out_watcher] (0x4000): Unscheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[request_watch_destructor] (0x0400): Deleting request watch
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] 
(0x4000): [.] does not look like an IP address
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_step] (0x2000): Querying DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_dns_query] (0x0100): Trying to resolve  
record of '.' in DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[request_watch_destructor] (0x0400): Deleting request watch
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_next] (0x0200): No more address families to retry
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_next] (0x0100): No more hosts databases to retry
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[sdap_dyndns_addrs_diff] (0x1000): Address on localhost only: -IP2-
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[sdap_dyndns_dns_addrs_done] (0x0400): Detected IP addresses change, 
will perform an update
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[nsupdate_msg_create_common] (0x0200): Creating update message for 
realm [].
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[be_nsupdate_create_fwd_msg] (0x0400):  -- Begin nsupdate message --

realm 
update delete .. in A
send
update delete .. in 
send
update add .. 1200 in A -IP2-
update add .. 1200 in A -IP1-
send
  -- End nsupdate message --
..
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[nsupdate_msg_create_common] (0x0200): Creating update message for 
server [ds01.] and realm [].
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[be_nsupdate_create_fwd_msg] (0x0400):  -- Begin nsupdate message --

server ds01.
realm 
update delete .. in A
send
update delete .. in 
send
update add .. 1200 in A -IP2-
update add .. 1200 in A -IP1-
send
  -- End nsupdate message --
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] 
(0x2000): Setting up signal handler up for pid [20631]
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] 
(0x2000): Signal handler set up for pid [20631]
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [write_pipe_handler] 
(0x0400): All data has been sent!
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_args] 
(0x0200): nsupdate auth type: GSS-TSIG

setup_system()

Thank you for your help!






I asked question here

https://www.redhat.com/archives/freeipa-users/2017-March/msg00360.html



--
Martin Bašti
Software Engineer
Red Hat Czech

--
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] DM Password Change & Password Storage

2017-04-19 Thread Martin Bašti 



On 12.04.2017 23:06, Jeremy Utley wrote:
Hello all!  We've got 2 replicated instances of FreeIPA 4.4.0 from the 
EPEL repository running on fully-updated CentOS 7 instances.  We're 
going thru an audit right now, and I have to provide some proof of 
certain things related to IPA to our auditors.  Unfortunately, the 
person who originally set these up evidently did not document the 
Directory Manager password in our docs, so I was forced to reset this 
password, using the process at:


http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html

This was successful, and I can now bind to the DS with the new 
password.  I'm now trying to follow the steps at:


https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

A few things are rather confusing to me.  I've tried Google searching 
without much luck either.  So hopefully you guys can answer a few 
questions for me.


1) First off, the doc says:

The following procedure is only applicable to FreeIPA 3.2.1 or older. 
Since FreeIPA 3.2.2 (and ticket #3594 
<https://fedorahosted.org/freeipa/ticket/3594>), the procedure is 
automated as a part of preparing a replica info file by using 
ipa-replica-prepare


So do I even need to perform these steps at all, considering I'm well 
beyond 3.2.2.  We don't have any intention of running 
ipa-replica-prepare for the forseeable future (we shouldn't ever need 
to add a third directory server here).


2) The first step (Update LDAP bind password) seems to indicate you're 
adding the new password in clear-text to the password.conf file - this 
seems like a major security issue. Am I misunderstanding what is being 
requested here?  The old password is not in this file (All my current 
files have is lines for "internal" and "replicationdb"


3) The next step regenerates the cacert.p12 file, but seems to do 
nothing with it, just leaves it sitting in /root - what should be done 
with this file afterward?


Thanks for any help you can give!

Jeremy Utley




Hello,

you have to follow only this howto 
http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html


The PKI parts are relevant only for old IPA servers, so with newer 
versions there is no need to manually update pki servers.


Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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] DNSSEC warning when DNSSEC should be disabled

2017-04-19 Thread Martin Bašti 



On 13.04.2017 22:50, Dan Dietterich wrote:


I am seeing inconsistent results configuring a DNS forward zone.

At a bash prompt, as root, after kinit admin, I do:

ipa dnsforwardzone-add domain.internal  --forwarder= ww.xx.yy.zz 
--forward-policy=only


That works fine and does not warn about DNSSEC.

In a Java webapp running as root under a Jetty, I run a shell 
sub-process and issue the kinit and the same ipa statement.


_/Sometimes/_, I get

ipa: WARNING: DNSSEC validation failed: record 'domain.internal. SOA' 
failed DNSSEC validation on server ww.xx.yy.zz.


Please verify your DNSSEC configuration or disable DNSSEC validation 
on all IPA servers.


I modified the /etc/named.conf file to say:

dnssec-enable no;

dnssec-validation no;

and systemctl restart ipa

Any clue why the results are different?

ipa –version: VERSION: 4.4.0, API_VERSION: 2.213

Linux … 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux


Thanks for any insight!

Regards,

Dan





Hello,

checks are done on IPA server side, how many servers do you have? Is 
possible that CLI connects to different servers.


However in this case, DNSSEC check should always fail and report error, 
so it is weird why it passed.


Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
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 long should it take to propagate user role changes?

2017-04-06 Thread Martin Bašti 



On 06.04.2017 01:57, Greg Gilbert wrote:
Hey. I'm a bit new to FreeIPA, so apologies if this has already been 
addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, 
and FreeIPA client 4.3.1 on Ubuntu nodes.


I've noticed that when I make changes to policies, it either takes a 
long time to propagate out to the client nodes, or requires a manual 
restart of the sssd service. In this case, I'm testing adding and 
removing a user from a sudo rule. Is this the correct behavior, or is 
there a misconfiguration on my part somewhere?


- greg



Hello,

it is caused by SSSD caches, to refresh particular objects in cache see 
`man sss_cache`.


You can lower TTL for records in cache, but the lower TTL, the higher 
load on server (`man sssd.conf` search for cache).


Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

--
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] Upgrade from IPA 4.2

2017-04-05 Thread Martin Bašti 



On 04/04/2017 02:23 AM, Lachlan Musicman wrote:


On 4 April 2017 at 04:28, Andrey Ptashnik > wrote:


Hello,

We have Centos 7.2 and IPA 4.2 version.
I remember that in previous versions in order to upgrade to the
latest one I had to run IPA upgrade scripts that would separately
upgrade LDAP database. Is that the same procedure if I need to
upgrade from version 4.2?



Andrey,

That wasn't my experience. We just did a yum update and it all seemed 
to work.


Given it's role, I presume you have or can set up a test env you can 
try it on?


cheers
L.

--
The most dangerous phrase in the language is, "We've always done it 
this way."


- Grace Hopper





Yum upgrade should run upgrade script automatically.

Now we have just one script ipa-server-upgrade

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