[Freeipa-users] New server install failing

2017-04-25 Thread Robert L. Harris 
   I'm trying to install freeipa-server on an ubuntu 16.04 box, fresh
install, but it keeps failing:

{0}:/etc/apt>lsb_release  -r
Release:16.04

{0}:/etc/apt>dpkg -l | egrep -i 'slapd|ipa'
ii  python-ipaddress 1.0.16-1
all  Backport of Python 3 ipaddress module (Python 2)


I added the apt repository:
{0}:/etc/apt> sudo add-apt-repository ppa:freeipa/ppa
   * This worked, it's far up in my history

{0}:/etc/apt>apt-get install freeipa-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  libodbc1 libslp1
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  freeipa-admintools freeipa-client freeipa-server-dns
Suggested packages:
  libpam-krb5
The following NEW packages will be installed:
  freeipa-admintools freeipa-client freeipa-server freeipa-server-dns
0 upgraded, 4 newly installed, 0 to remove and 6 not upgraded.
Need to get 0 B/853 kB of archives.
After this operation, 3669 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Selecting previously unselected package freeipa-client.
(Reading database ... 161356 files and directories currently installed.)
Preparing to unpack .../freeipa-client_4.3.1-0ubuntu1_amd64.deb ...
Unpacking freeipa-client (4.3.1-0ubuntu1) ...
Selecting previously unselected package freeipa-admintools.
Preparing to unpack .../freeipa-admintools_4.3.1-0ubuntu1_all.deb ...
Unpacking freeipa-admintools (4.3.1-0ubuntu1) ...
Selecting previously unselected package freeipa-server.
Preparing to unpack .../freeipa-server_4.3.1-0ubuntu1_amd64.deb ...
Unpacking freeipa-server (4.3.1-0ubuntu1) ...
Selecting previously unselected package freeipa-server-dns.
Preparing to unpack .../freeipa-server-dns_4.3.1-0ubuntu1_all.deb ...
Unpacking freeipa-server-dns (4.3.1-0ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
Setting up freeipa-client (4.3.1-0ubuntu1) ...
Setting up freeipa-admintools (4.3.1-0ubuntu1) ...
Setting up freeipa-server (4.3.1-0ubuntu1) ...
apache2_invoke: Enable module auth_gssapi
apache2_invoke: Enable module authz_user
apache2_invoke: Enable module deflate
apache2_invoke: Enable module expires
apache2_invoke: Enable module headers
apache2_invoke: Enable module proxy
apache2_invoke: Enable module proxy_ajp
apache2_invoke: Enable module proxy_http
apache2_invoke: Enable module rewrite
Running ipa-server-upgrade...
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command
ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
*IOError: [Errno 2] No such file or directory:
u'/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif.modified.out'*
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more
information
dpkg: error processing package freeipa-server (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of freeipa-server-dns:
 freeipa-server-dns depends on freeipa-server (>= 4.3.1-0ubuntu1); however:
  Package freeipa-server is not configured yet.


dpkg: error processing package freeipa-server-dns (--configure):
 dependency problems - leaving unconfigured
Processing triggers for dbus (1.10.6-1ubuntu3.3) ...No apport report
written because the error message indicates its a followup error from a
previous failure.

Errors were encountered while processing:
 freeipa-server
 freeipa-server-dns
E: Sub-process /usr/bin/dpkg returned an error code (1)


If I search around, that slapd-EXAMPLE-COM directoryand file can be created
by installing slapd but that requires 389-ds-base which conflicts with
slapd.

Thoughts?
-- 
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 do you have users be given a local group?

2017-04-25 Thread Jakub Hrozek 
On Tue, Apr 25, 2017 at 02:43:11PM -0400, g...@greg-gilbert.com wrote:
> I saw this question come up way back in the archives, so I thought I'd
> ask to see if there's a better way to do it. 
> 
> Basically I want users who log into my servers that run the FreeIPA
> client to be given the local usergroup DOCKER.

I think this is what you're looking for:
https://sourceware.org/glibc/wiki/Proposals/GroupMerging

If you're running a libc version that supports this feature, you'd
define the docker group on the IPA side with the same GID, then SSSD
would deliver the group to libc and libc would merge the results from
the local and the remote groups.

> Is there a way to do
> that? Is it controlled from the FreeIPA server, or is it something (e.g.
> PolicyKit?) that needs to be run on each client? 

PolicyKit is the piece that enforces a policy decision based on the
group membership, the trick here is to merge local and remove groups.

> 
> If it matters, the clients are running Ubuntu 16.04. 

I'm sorry, I don't know if this feature is present Ubuntu 16.04..

-- 
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] I think I lost my CA...

2017-04-25 Thread Bret Wortman 
I recently had to upgrade all my Fedora IPA servers to C7. It went well, 
and we've been up and running nicely on 4.4.0 on C7 for the past month 
or so.


Today, someone came and asked me to generate a new certificate for their 
web server. All was good until I went to the IPA UI and tried to perform 
Actions->New Certificate, which did nothing. I tried each of our 3 
servers in turn. All came back with no popup window and no error, either.


I suspect the problem might be that we no longer have a CA server due to 
the method I used to upgrade the servers. I likely missed a "--setup-ca" 
in there somewhere, so my rolling update rolled over the CA.


What's my best hope of recovery? I never ran this before, so I'm not 
sure if this shows that I'm missing a CA or not:


   # ipa ca-find
   
   1 CA matched
   
  Name: ipa
  Description IPA CA
  Authority ID: 3ce3346[...]
  Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
  Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM
   
   Number of entries returned 1
   
   # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA,
   O=DAMASCUSGRP.COM"
   ipa: ERROR: Failed to authenticate to CA REST API
   # klist
   Ticket cache: KEYRING:persistent:0:0
   Default principal: ad...@damascusgrp.com

   Valid starting  Expires  Service principal
   04/25/2017 18:48:26 04/26/2017 18:48:21
   krbtgt/damascusgrp@damascusgrp.com
   #


What's my best path of recovery?

--
*Bret Wortman*
The Damascus Group

-- 
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 do you have users be given a local group?

2017-04-25 Thread greg 
I saw this question come up way back in the archives, so I thought I'd
ask to see if there's a better way to do it. 

Basically I want users who log into my servers that run the FreeIPA
client to be given the local usergroup DOCKER. Is there a way to do
that? Is it controlled from the FreeIPA server, or is it something (e.g.
PolicyKit?) that needs to be run on each client? 

If it matters, the clients are running Ubuntu 16.04. 

Thanks!-- 
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] Fedora 25 - SSSD: Smart card login is broken

2017-04-25 Thread Michael Rainey (Contractor) 

Hello,

While using Fedora 25 we noticed smart card login is broken with the 
latest update to SSSD.  A month or so ago a patch was created to fix the 
same issue.  Here are some of the details:


Before Update:

sssd.x86_641.15.2-1.fc25sb1(was 1.15.2-1.fc25 before patch)

After Update:

sssd.x86_641.15.2-2.fc25

I was able to compared this to a freshly updated system to a system 
which didn't receive the same update so I am confident lies with the 
package update.


I have also noted the "lock screen when card removed" feature is not 
working.


Your help is greatly appreciated.

Thank you,

--
*Michael Rainey*
-- 
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] Default SELinux user changes on addition of replica?

2017-04-25 Thread Steve Huston 
On Tue, Apr 25, 2017 at 11:34 AM, Rob Crittenden  wrote:
> I guess the only way to know for sure would be to try to duplicate it.

I'll basically be doing that anyway, since I just found that there's
some issue with password migrations too (there wasn't before, it was
working, so now I'm trying to figure out why it's not) and I think I
slammed the server too hard with changes when they were linked and the
replica couldn't keep up.  So, I removed everyone again, broke the
replication, reinstalled the replica server again, and will try later
once I've got this all working.  Right now it has the right default
user, so I'll know for sure when I create another replica :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] Default SELinux user changes on addition of replica?

2017-04-25 Thread Rob Crittenden 
Steve Huston wrote:
> In the last of my testing before deployment, I had a replica server
> setup but things got out of sync somehow.  Yesterday I severed the
> link with the two servers, reimaged the "bad" one, and did some poking
> around on the "good" one while I was at it (clearing out all of the
> real user data in anticipation of making another migration run into
> it).  I remember at one point I had found the default selinux user was
> misconfigured, and I thought it was strange because that's on my
> checklist for installing a server so I know I'd done it.  Oh well,
> changed it to the proper context again and moved on.
> 
> Just this morning I made the new (previously bad) server a replica
> again, and after it finished I happened into the configuration page to
> find the default selinux user is back to unconfined_u:s0-s0:c0.c1023.
> Both servers report this the same, as I would expect, but I don't
> expect or understand why it changed again.
> 
> I don't know that I'll have time to spin up more instances and go
> through the testing to see what/when/how it changed, but I wanted to
> point it out in case someone who does have that time can run with the
> information.
> 

Seems like an update file could reset that but there isn't one that does
this that I can find.

I wonder if you fixed it on the "bad" one after replication had broken
but before you noticed it was broken, so the value was lost when the
"bad" one was dropped.

I guess the only way to know for sure would be to try to duplicate it.

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

[Freeipa-users] Default SELinux user changes on addition of replica?

2017-04-25 Thread Steve Huston 
In the last of my testing before deployment, I had a replica server
setup but things got out of sync somehow.  Yesterday I severed the
link with the two servers, reimaged the "bad" one, and did some poking
around on the "good" one while I was at it (clearing out all of the
real user data in anticipation of making another migration run into
it).  I remember at one point I had found the default selinux user was
misconfigured, and I thought it was strange because that's on my
checklist for installing a server so I know I'd done it.  Oh well,
changed it to the proper context again and moved on.

Just this morning I made the new (previously bad) server a replica
again, and after it finished I happened into the configuration page to
find the default selinux user is back to unconfined_u:s0-s0:c0.c1023.
Both servers report this the same, as I would expect, but I don't
expect or understand why it changed again.

I don't know that I'll have time to spin up more instances and go
through the testing to see what/when/how it changed, but I wanted to
point it out in case someone who does have that time can run with the
information.

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

2017-04-25 Thread Kat 

DOH!!

I'm an idiot -- yep - I see what I was misreading. It can't find 
python-zope-interface (which is required by python-zopy-component) and 
*THAT* is the real error. The conflicts are just yum/rpm saying - "Hey, 
there are other problems, but not related".


My bad - sorry to have troubled you.

Kat


On 4/25/17 9:30 AM, Martin Bašti wrote:
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.








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




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

[Freeipa-users] weird conflicts in AWS EC2 install

2017-04-25 Thread Kat 

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

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

--
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] CA Certificate didn't automatically transfer to replica(s)

2017-04-25 Thread Dewangga Bachrul Alam 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Master IPA Server:
- - I install 1 (one) server as master (self-signed) and add/modify
using external CA.
- - I am using ipa-cacert-manage install then ipa-certupdate on master

Replica IPA Server:
- - I install 1 (one) server as client and promoted to ipa-replica:
  - I run `ipa-client-install` and autodiscovery
  - Then `ipa-replica-install --principal admin --admin-password
`

I've hit ipa-certupdate -v to verbose the logs (attached at first
email). Then replica server aren't using external CA(s) like master did.

So, I did the same like master, using `ipa-cacert-manage` on replica,
and it's work fine. If it's normal, then thanks for clarifying this.

On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote:
> Hi,
> 
> As your email refers to self-signed and signed CA certificate, can
> you please clarify the exact steps that you followed? It looks
> like - you first installed FreeIPA with a self-signed CA - you
> added an external CA (did you use ipa-cacert-manage install on 1 
> server then ipa-certupdate on all replicas?) - you replaced the
> httpd/LDAP certificates with a cert signed from the external CA
> (you probably ran ipa-server-certinstall on one server).
> 
> In this case it is normal that the httpd/LDAP certificates on the 
> replica were not updated as they are different (each IPA server has
> his own httpd/LDAP cert which contains the hostname in its
> subject). You can check this by performing on each server: 
> ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert |
> grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM" 
> ^
> 
> If the goal is to replace the httpd/LDAP certificates on the
> replica, the command ipa-server-certinstall must also be run on the
> replica with the appropriate certificate.
> 
> HTH, Flo.
> 
> On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello!
> 
> Just update, manually add external CA(s) and signed certificated
> was successful, but why it's didn't automatically transferred to 
> replica(s) from master.
> 
> On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:
 Hello!
 
 I've successfully create replica, everything works fine but
 why my signed CA certificate didn't automatically transfer to
 another replica(s)? Is it normal?
 
 Trying to add manually, but the certificate in replica(s)
 still using self-signed. Here's the output from
 `ipa-certupdate -v` 
 https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdI
GYh
>
 
yR
 
 
> LivL9gydE=
 
 Interesting line was :
 
 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process
 ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n
 IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa:
 DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find
 cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found
 
 ipa: DEBUG: Starting external process ipa: DEBUG: 
 args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA
 cert -a ipa: DEBUG: Process finished, return code=255 ipa:
 DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find
 cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not
 found
 
 FYI: The replica server previously was a client and promoted
 to be a replica by hitting this command:
 `ipa-replica-install --principal admin --admin-password
 admin_password`
 
 Any hints?
 
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY/w9DGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcBkZD/wM9ia9854l7bIy7dHxKxc7WhduFmbW3AwW0Ren+aLLER/lqMhO
KPNA+fB9ojeoZagmA7JhpM9jblJ4BUaJjLnyf1vhJmOgIX0MgSfmNCr/f/EtfC9R
wZLBImntbGm8yQnsA4f21sdmqnQg9CZN6cg6R8TQ+OuAXdm8jU9Pv3RCLFXzS0mW
oxQdOZ9yNOC9chmfGl6Bz2oGFoEMHCsn1AcEoRHyIUU6jrCNhTVgYcHPVEz0PW73
DEY0ZkwNi9hMcGv5+5F8InYEOdOkS9Lp0juW47xRheztD/PRhYYn1m/FtOxmFa3z
3XS36/w6omSdfH2WOjBRwJduB4REmwHb9oGto7vu6FvWhwUHf9zWVjmJ6DH8tbYU
XgHLmmaSIfwHWc0iYnSLcbHuOaR+l2nOSOLJNg5FfUoIJy5qO51kV3u+pGGELCdr
GexkcXrEHxqk/OO9ioLlTfYIpd9NI6hdLzAsjJEbHuEVZe1B/nrkUOVy/yWOry0N
8muLkJlslMpRwGV4KRFlhcfd49mv9oylKrAxtZ843vz6F1WOKI6vbuS+SJ+wpoer
P1njVQyExrlKi3ruPBIOkxQ6fab9OvredesCo13wLqhfXvezsWpL1RkiqBaMzrsk
NDX/jqEEsk7gbYuawNazcQZP/NGzQZ6nBnVAkXV7vA8D/EV4y1CbW9YfXA==
=07Ri
-END PGP 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

Re: [Freeipa-users] ipa-replica-install failes on setup-ca

2017-04-25 Thread Florence Blanc-Renaud 

On 04/24/2017 09:37 AM, Bjarne Blichfeldt wrote:

We had problems with one idm replica complaining about different ldap
database versions and at the same time errors on starting pki-tomcat. I
decided to delete the ipa server and reinstall.

The ipa server delete went without problems, but the reinstall….



ipa-replica-install --setup-ca --setup-dns --forwarder 10.200.207.11
--forwarder  10.200.206.11 --principal admin --admin-password  “secret”



This fails on ca install, but without set-up ca the install was succesfull.

I tried both with the server enrolled as client and with the server not
enrolled – no difference.

The installation was successful in a different envirionment but same
software versions.





server is rhel 7.3, ipa: VERSION: 4.4.0, API_VERSION: 2.213



When ipa-replica-install fails  with –setup-ca  ipareplica-install.log
shows :

2017-04-23T19:44:45Z DEBUG Starting external process

2017-04-23T19:44:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X

2017-04-23T19:44:46Z DEBUG Process finished, return code=1

2017-04-23T19:44:46Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20170423214445.log

Loading deployment configuration from /tmp/tmpBLQe1X.



2017-04-23T19:44:46Z DEBUG stderr=Traceback (most recent call last):

  File "/usr/sbin/pkispawn", line 817, in 

main(sys.argv)

  File "/usr/sbin/pkispawn", line 501, in main

create_master_dictionary(parser)

  File "/usr/sbin/pkispawn", line 641, in create_master_dictionary

parser.compose_pki_master_dictionary()

  File
"/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py",
line 614, in compose_pki_master_dictionary

instance.load()

  File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line
595, in load

subsystem.load()

  File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line
129, in load

lines = open(self.cs_conf).read().splitlines()

IOError: [Errno 2] No such file or directory:
'/var/lib/pki/pki-tomcat/ca/conf/CS.cfg'



2017-04-23T19:44:46Z CRITICAL Failed to configure CA instance: Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X' returned non-zero exit status 1

2017-04-23T19:44:46Z CRITICAL See the installation logs and the
following files/directories for more information:

2017-04-23T19:44:46Z CRITICAL   /var/log/pki/pki-tomcat

2017-04-23T19:44:46Z DEBUG Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 449, in start_creation

run_step(full_msg, method)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 439, in run_step

method()

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
586, in __spawn_instance

DogtagInstance.spawn_instance(self, cfg_file)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 181, in spawn_instance

self.handle_setup_error(e)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 420, in handle_setup_error

raise RuntimeError("%s configuration failed." % self.subsystem)

RuntimeError: CA configuration failed.



2017-04-23T19:44:46Z DEBUG   [error] RuntimeError: CA configuration failed.

2017-04-23T19:44:46Z 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 310, in run

self.execute()

  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 332, in execute

for nothing in self._executor():





Nothing in /var/log/pki/pki-tomcat.



Further observations:

During changing the certificate to thirdparty ssl, I got the following
error in /var/log/httpd/error_log :

[Mon Apr 24 09:03:14.267871 2017] [:error] [pid 11004] Unable to verify
certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so
the server can start until the problem can be resolved.

p11-kit: couldn't open and map file:
/etc/pki/ca-trust/source/ipa.p11-kit: Permission denied



I changed the permission on /etc/pki/ca-trust/source/ipa.p11-kit from
600 to 644 and added “NSSEnforceValidCerts off” to
/etc/httpd/conf.d/nss.conf

After that ipa-certupdate succeeded.



Are there any way to install the ca without reinstalling the whole
ipa-server again?







Regards

Bjarne Blichfeldt.






Hi,

1/ you may find more information about the CA installation failure in 
/var/log/pki/pki-ca-spawn.$date.log


To enable debug logs, you can create the file /etc/ipa/server.conf:
$ cat /etc/ipa/server.conf
[global]
debug = True


2/ the error in httpd/error_log may indicate that your certificate 
expired, could you check if all the certificates are still valid?

$ sudo certutil -L -d /etc/httpd/alias/ -n Server-Cert | grep  Not
Not Before: Thu Apr 20 15:03:40 2017

Re: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s)

2017-04-25 Thread Florence Blanc-Renaud 

Hi,

As your email refers to self-signed and signed CA certificate, can you 
please clarify the exact steps that you followed? It looks like

- you first installed FreeIPA with a self-signed CA
- you added an external CA (did you use ipa-cacert-manage install on 1 
server then ipa-certupdate on all replicas?)
- you replaced the httpd/LDAP certificates with a cert signed from the 
external CA (you probably ran ipa-server-certinstall on one server).


In this case it is normal that the httpd/LDAP certificates on the 
replica were not updated as they are different (each IPA server has his 
own httpd/LDAP cert which contains the hostname in its subject). You can 
check this by performing on each server:
ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert | grep 
Subject:

Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM"
 ^

If the goal is to replace the httpd/LDAP certificates on the replica, 
the command ipa-server-certinstall must also be run on the replica with 
the appropriate certificate.


HTH,
Flo.

On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Just update, manually add external CA(s) and signed certificated was
successful, but why it's didn't automatically transferred to
replica(s) from master.

On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:

Hello!

I've successfully create replica, everything works fine but why my
signed CA certificate didn't automatically transfer to another
replica(s)? Is it normal?

Trying to add manually, but the certificate in replica(s) still
using self-signed. Here's the output from `ipa-certupdate -v`
https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYh

yR




LivL9gydE=


Interesting line was :

ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa:
DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a
ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA :
PR_FILE_NOT_FOUND_ERROR: File not found

ipa: DEBUG: Starting external process ipa: DEBUG:
args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a
ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert
: PR_FILE_NOT_FOUND_ERROR: File not found

FYI: The replica server previously was a client and promoted to be
a replica by hitting this command: `ipa-replica-install
--principal admin --admin-password admin_password`

Any hints?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY+xccGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcJAHEACO4nF7guN05MjmqYFDwDrjhvWgMN2sRn+Nxt/aA+xziIOJJGaA
Rr97TbODiTiefBkjVoiYM6dxr6VK5ViPZIbe0IAjafCRACAKggyCRtb2j8+vb7Jd
imJN/MC0zSMCdATSs2b95uT7QrUiVHwt/xmKzJ44ezIYON+YOtgndk0QXynXHqjm
H6HcQkh4ZcC8antiFdbC+H8z4Iv4Ypnhdr80RtqLqQ6esnZXnWdIg3X0aRb6w1fw
KEDHemhfKeu5hMxpi2AQdesO4j+XhvW6TfvKymScbWv1PoEuLAsgQGdoxVmhkjN8
LKixSghHlg8A61DXtA9J2uaPUUKjVMmoKH4CFD0RLQlQJ+f4KfApbNzHZTBnSL8D
64c5WjJdtAY5LUArakwZ/EJt5N5AJEFDIoSWM3if/jpDIVFEAaDzFKIQvyLKyMIn
yHxNIcWcSoP/YwzZXMttWx5dNRkermmWEcvPsqovoT9BRlI/e700o3xqQk7V0720
7TniU1uZaBpLkJOxHUoWssaWfVHcWEBnw0UeU7bl4nKnAo7hkQs3/iJXwQiLk4aw
338ZIniIrDSmUmmfqJuhQrFPNK+heCOno5O/99Sa1bs0lTQgRRjMq5Q7mIajEYYI
NedyVj0VQ8R42rbgomWJPJP/uU+kirN8CpEc+d/IWNQE2t+5hOX5nme5dw==
=anzk
-END PGP 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

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


--
Martin Bašti
Software Engineer
Red Hat Czech

-- 
Manage your subscription for the Freeipa-users mailing