Re: [Freeipa-devel] [PATCH 0011] Make sure selinuxusemap behaves consistently to HBAC rule

2012-09-11 Thread Martin Kosek 
On 09/06/2012 01:13 PM, Tomas Babej wrote:
 On 09/05/2012 01:56 PM, Martin Kosek wrote:
 On 09/03/2012 05:12 PM, Tomas Babej wrote:
 Hi,

 Both selinuxusermap-add and selinuxusermap-mod commands now behave
 consistently in not allowing user/host category or user/host members
 and HBAC rule being set at the same time. Also adds a bunch of unit
 tests that check this behaviour.

 https://fedorahosted.org/freeipa/ticket/2983

 Tomas

 I found few issues with this patch:

 1) Patch needs a rebase

 2) Patch does not expect attributes to be set to None, i.e. to be left empty 
 or
 to be deleted, e.g.:

 # ipa selinuxusermap-add foo --selinuxuser=guest_u:s0 --usercat=all 
 --hbacrule=
 ipa: ERROR: HBAC rule and local members cannot both be set

 # ipa selinuxusermap-add foo --selinuxuser=guest_u:s0 --usercat=all
 
 Added SELinux User Map foo
 
Rule name: foo
SELinux User: guest_u:s0
User category: all
Enabled: TRUE

 # ipa selinuxusermap-mod foo --usercat= --hbacrule=
 ipa: ERROR: HBAC rule and local members cannot both be set

 # ipa selinuxusermap-mod foo --usercat=
 ---
 Modified SELinux User Map foo
 ---
Rule name: foo
SELinux User: guest_u:s0
Enabled: TRUE

 # ipa selinuxusermap-mod foo --hbacrule=foo
 ---
 Modified SELinux User Map foo
 ---
Rule name: foo
SELinux User: guest_u:s0
HBAC Rule: foo
Enabled: TRUE

 # ipa selinuxusermap-mod foo --hbacrule= --usercat=all
 ipa: ERROR: HBAC rule and local members cannot both be set

 All these validation failures are not valid.

 3) Additionally, I think it would be more readable and less error prone that 
 if
 instead of this blob:

 +are_local_members_to_be_set  = 'usercategory' in _entry_attrs or \
 +   'hostcategory' in _entry_attrs or \
 +   'memberuser' in _entry_attrs or \
 +   'memberhost' in _entry_attrs

 You would use something like that:

 are_local_members_to_be_set  = any(attr in _entry_attrs
 for attr in ('usercategory',
  'hostcategory',
  'memberuser',
  'memberhost'))

 Martin
 1.) Done.
 2.) Corrected.
 3.) Fixed.
 
 Tomas

1) There are some (corner) cases where this approach still does not work:

# ipa selinuxusermap-show foo
  Rule name: foo
  SELinux User: guest_u:s0
  HBAC Rule: foo
  Enabled: TRUE
# ipa selinuxusermap-mod foo --usercat=all --hbacrule=
ipa: ERROR: HBAC rule and local members cannot both be set

HBAC rule attribute is being deleted and user category set, so this should not
be rejected.

2) There are also some styling issues (you can use pep8 tool present in Fedora
to locate them on your own, e.g.:

ipalib/plugins/selinuxusermap.py:247:32: E203 whitespace before ':'
ipalib/plugins/selinuxusermap.py:247:70: E225 missing whitespace around operator
ipalib/plugins/selinuxusermap.py:249:36: E221 multiple spaces before operator
...

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Petr Viktorin 

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing with them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still using a 
Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs.



The ipa package lacks any updated dogtag dependencies, so I abused it.


What should the updated dependencies be? Since it should work with both 
dogtag 9 and 10, I don't see how they should change.



I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?  This is
still required right now until I get the selinux policy all straightened
out.

There is also a separate dogtag ticket (which is currently being worked
on) to restart existing dogtag instances when dogtag is upgraded from
9-10.


In permissive mode, this upgrade works for me.


Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to 
communicate with CMS (Service Temporarily Unavailable)


Usually, waiting a couple of minutes clears this up. Perhaps we are not 
doing startup detection correctly. Ade mentioned that waiting for ports 
may not be ideal. How do we know if Dogtag is initialized?



Uninstalling failed because it tried to run pkidestroy and not pkiremove.


I was under the impression that pkidestroy was the correct command to 
remove an upgraded instance. I'll check with Ade.



I'll test this too.


The contents of the file passed to pkispawn should be logged so we can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll put it 
in the next version of the patch.



DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first updating
ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in it.


We can add that.


certificate renewal failed. I spent far too long trying to figure out
why tomcat wasn't listening on port 9180 but failed. I think 9180 is
actually the old server, right? So another missing dependency on a fixed
certmonger?

The best I could find was the certmonger error:

ca-error: Error 7 connecting to
http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect
to server.



I'll set the certmonger min version to 0.60 as per Nalin's mail.


Is this cert renewal on a dogtag 10 instance?  Or the upgraded dogtag 9?
If its dogtag 10, perhaps you do not have the certmonger version that
has the relevant fix?  If its dogtag 9, then we need to figure out whats
going on.  That reminds me - I need to file a bug to allow certmonger to
talk to the newly defined dogtag ports.  Do you have selinux permissive?


There is no man page for pkispawn/pkidestroy :-( According to the FHS
these should not be in /bin but in /usr/sbin (not end-user commands).


There is a trac ticket open for man pages for pkispawn and pkidestroy.
We plan to complete this ticket by the time f18 is released.

We'll look into the location of pkispawn/pkicreate.


The output of pkicreate/pkisilent was really terrible and not usable at
all so we didn't display it when failures occurred. It looks like that
has been addressed, at least for the case where a CA is already
configured and you try to install IPA. Perhaps we should capture stderr
and display that instead of the command-line of pkispawn? Again, a man
page would help with the integration.

2012-09-10T20:51:45Z DEBUG   [2/18]: configuring certificate server instance
2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq
2012-09-10T20:51:45Z DEBUG stdout=
2012-09-10T20:51:45Z DEBUG stderr=pkispawn: ERROR... PKI
subsystem 'CA' for instance 'pki-tomcat' already exists!

2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command
'/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1


That may be a good idea.  Of course. thats an IPA thing, right?


rob







--
Petr³

___
Freeipa-devel mailing list

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Rob Crittenden 

Petr Viktorin wrote:

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing with
them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still using a
Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs.


The ipa package lacks any updated dogtag dependencies, so I abused it.


What should the updated dependencies be? Since it should work with both
dogtag 9 and 10, I don't see how they should change.


I don't know either, but we need to prevent people from installing 
incompatible package combinations.



I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?  This is
still required right now until I get the selinux policy all straightened
out.

There is also a separate dogtag ticket (which is currently being worked
on) to restart existing dogtag instances when dogtag is upgraded from
9-10.


In permissive mode, this upgrade works for me.


I was in enforcing mode but saw no AVCs. What is the ETA on fixing this?




Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Service Temporarily Unavailable)

Usually, waiting a couple of minutes clears this up. Perhaps we are not
doing startup detection correctly. Ade mentioned that waiting for ports
may not be ideal. How do we know if Dogtag is initialized?


Years ago we had discussed with Andrew and Matt creating a URI that can 
be queried to determine dogtag status. I don't think that ever went 
anywhere.





Uninstalling failed because it tried to run pkidestroy and not
pkiremove.


I was under the impression that pkidestroy was the correct command to
remove an upgraded instance. I'll check with Ade.


I'll test this too.


The contents of the file passed to pkispawn should be logged so we can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll put it
in the next version of the patch.


The question to ask is: would you need the contents of this file if all 
you got were logs and needed to evaluate why installation failed? In 
most cases this is yes.



DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first updating
ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in it.


We can add that.


certificate renewal failed. I spent far too long trying to figure out
why tomcat wasn't listening on port 9180 but failed. I think 9180 is
actually the old server, right? So another missing dependency on a fixed
certmonger?

The best I could find was the certmonger error:

ca-error: Error 7 connecting to
http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect
to server.



I'll set the certmonger min version to 0.60 as per Nalin's mail.


Ok.


Is this cert renewal on a dogtag 10 instance?  Or the upgraded dogtag 9?
If its dogtag 10, perhaps you do not have the certmonger version that
has the relevant fix?  If its dogtag 9, then we need to figure out whats
going on.  That reminds me - I need to file a bug to allow certmonger to
talk to the newly defined dogtag ports.  Do you have selinux permissive?


There is no man page for pkispawn/pkidestroy :-( According to the FHS
these should not be in /bin but in /usr/sbin (not end-user commands).


There is a trac ticket open for man pages for pkispawn and pkidestroy.
We plan to complete this ticket by the time f18 is released.

We'll look into the location of pkispawn/pkicreate.


The output of pkicreate/pkisilent was really terrible and not usable at
all so we didn't display it when failures occurred. It looks like that
has been addressed, at least for the case where a CA is already
configured and you try to install IPA. Perhaps we should capture stderr
and display that instead of the command-line of pkispawn? Again, a man
page would help with the integration.

2012-09-10T20:51:45Z DEBUG   [2/18]: configuring certificate server
instance

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Ade Lee 
On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:
 Petr Viktorin wrote:
  On 09/11/2012 04:04 AM, Ade Lee wrote:
  On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:
  Petr Viktorin wrote:
  Attaching rebased and squashed patches. I've done some testing with
  them
  but please test some more.
 
 
  Most of these aren't IPA issues, but dogtag issues. I'll try to split
  them out.
 
  IPA:
 
  For the configuration files in install/conf to be updated at rpm update
  time the VERSION needs to be incremented.
 
  These files should stay the same since on upgrade we're still using a
  Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs.
 
  The ipa package lacks any updated dogtag dependencies, so I abused it.
 
  What should the updated dependencies be? Since it should work with both
  dogtag 9 and 10, I don't see how they should change.
 
 I don't know either, but we need to prevent people from installing 
 incompatible package combinations.
 
Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy this
requirement?  The main concern is that you must have ipa 3.0 if you have
dogtag 10.

Given that dogtag is consumed by IPA though, it makes more sense to put
the relevant conflicts in IPA rather than in dogtag.  So in this case,
that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
Recall that dogtag 10 will only be officially available in f18+.

  I installed IPA with dogtag 9 and created a replica.
 
  I updated the IPA bits, that worked fine.
 
  I updated to dogtag 10 and now the CA doesn't work on the master,
  including starting the dogtag instance. Note that the rpm update process
  worked, no notice that the CA service didn't restart.
 
  Did you try to restart the CA with selinux in permissive mode?  This is
  still required right now until I get the selinux policy all straightened
  out.
 
  There is also a separate dogtag ticket (which is currently being worked
  on) to restart existing dogtag instances when dogtag is upgraded from
  9-10.
 
  In permissive mode, this upgrade works for me.
 
 I was in enforcing mode but saw no AVCs. What is the ETA on fixing this?
 

Within the next week or two, I need to finish the IPA merge database
patch first, and then co-ordinate changes with the selinux guys.

 
 
  Sometimes I do get this error intermittently:
 
  ipa: ERROR: Certificate operation cannot be completed: Unable to
  communicate with CMS (Service Temporarily Unavailable)
 
  Usually, waiting a couple of minutes clears this up. Perhaps we are not
  doing startup detection correctly. Ade mentioned that waiting for ports
  may not be ideal. How do we know if Dogtag is initialized?
 
 Years ago we had discussed with Andrew and Matt creating a URI that can 
 be queried to determine dogtag status. I don't think that ever went 
 anywhere.
 
Petr, this happens only on reboot, right?  And not on regular service
ipa restart?

Yeah, I remember this conversation - and even created a bug for it at
some point.  This went away because the mechanism you were using seemed
to be working.  The timing may be very different now with tomcat 7 and
systemd.  I'll open a dogtag trac ticket for this.

 
  Uninstalling failed because it tried to run pkidestroy and not
  pkiremove.
 
  I was under the impression that pkidestroy was the correct command to
  remove an upgraded instance. I'll check with Ade.
 
  I'll test this too.
 
  The contents of the file passed to pkispawn should be logged so we can
  see exactly what was passed in.
 
  Its a pretty big file.  You might want to only log the modifications.
  Or save the file somewhere.
 
  Our logs are pretty verbose, so that shouldn't be a problem. I'll put it
  in the next version of the patch.
 
 The question to ask is: would you need the contents of this file if all 
 you got were logs and needed to evaluate why installation failed? In 
 most cases this is yes.
 
Up to you guys.  There is a patch I am working on in which I will be
logging the object that is being passed to the server from pkispawn.
That - and the diffs to the standard config file as I mentioned above -
will likely be sufficient to debug almost all cases.  

Make sure not to log any passwords.
 
  DOGTAG:
 
  When upgrading using the dogtag-devel repo I had to specify
  pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
  versions (and failed).
 
  I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
  --enablerepo=dogtag-devel --enablerepo=updates-testing
 
  We'll look into this.  I think I know why this happens.
 
  What happens if someone manually upgrades pki-ca without first updating
  ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in it.
 
  We can add that.
 
  certificate renewal failed. I spent far too long trying to figure out
  why tomcat wasn't listening on port 9180 but failed. I think 9180 is
  actually the old server, right? So another missing dependency on a fixed
  certmonger?
 
  The

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Rob Crittenden 

Ade Lee wrote:

On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing with
them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still using a
Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs.


The ipa package lacks any updated dogtag dependencies, so I abused it.


What should the updated dependencies be? Since it should work with both
dogtag 9 and 10, I don't see how they should change.


I don't know either, but we need to prevent people from installing
incompatible package combinations.


Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy this
requirement?  The main concern is that you must have ipa 3.0 if you have
dogtag 10.

Given that dogtag is consumed by IPA though, it makes more sense to put
the relevant conflicts in IPA rather than in dogtag.  So in this case,
that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
Recall that dogtag 10 will only be officially available in f18+.


That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to 
F-18 they would be able to install dogtag 10 and blow up their IPA server.





I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?  This is
still required right now until I get the selinux policy all straightened
out.

There is also a separate dogtag ticket (which is currently being worked
on) to restart existing dogtag instances when dogtag is upgraded from
9-10.


In permissive mode, this upgrade works for me.


I was in enforcing mode but saw no AVCs. What is the ETA on fixing this?



Within the next week or two, I need to finish the IPA merge database
patch first, and then co-ordinate changes with the selinux guys.




Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Service Temporarily Unavailable)

Usually, waiting a couple of minutes clears this up. Perhaps we are not
doing startup detection correctly. Ade mentioned that waiting for ports
may not be ideal. How do we know if Dogtag is initialized?


Years ago we had discussed with Andrew and Matt creating a URI that can
be queried to determine dogtag status. I don't think that ever went
anywhere.


Petr, this happens only on reboot, right?  And not on regular service
ipa restart?

Yeah, I remember this conversation - and even created a bug for it at
some point.  This went away because the mechanism you were using seemed
to be working.  The timing may be very different now with tomcat 7 and
systemd.  I'll open a dogtag trac ticket for this.


Ok.






Uninstalling failed because it tried to run pkidestroy and not
pkiremove.


I was under the impression that pkidestroy was the correct command to
remove an upgraded instance. I'll check with Ade.


I'll test this too.


The contents of the file passed to pkispawn should be logged so we can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll put it
in the next version of the patch.


The question to ask is: would you need the contents of this file if all
you got were logs and needed to evaluate why installation failed? In
most cases this is yes.


Up to you guys.  There is a patch I am working on in which I will be
logging the object that is being passed to the server from pkispawn.
That - and the diffs to the standard config file as I mentioned above -
will likely be sufficient to debug almost all cases.

Make sure not to log any passwords.


DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first updating
ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in it.


We can add that.


certificate renewal failed. I spent far too long trying to figure out
why tomcat wasn't listening on port 9180 but failed. I think 9180 is
actually the old server, right? So another missing

[Freeipa-devel] [PATCH] 212 Fix integer validation when boundary value is empty string

2012-09-11 Thread Petr Vobornik 
There was an error in number validation check. If boundary value was an 
empty string, validation of a number always failed. This patch fixes the 
problem by not performing the check in these cases.


Basic unit tests for IPA.metadata_validator created.
--
Petr Vobornik
From 4bde0e0f7dd1b02ce6ae1b37a2f6a97efbb99726 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 11 Sep 2012 13:52:10 +0200
Subject: [PATCH] Fix integer validation when boundary value is empty string

There was an error in number validation check. If boundary value was an empty string, validation of a number always failed. This patch fixes the problem by not performing the check in these cases.
---
 install/ui/field.js  |   4 +-
 install/ui/ipa.js|   4 ++
 install/ui/test/all_tests.html   |   1 +
 install/ui/test/index.html   |   1 +
 install/ui/test/jsl.conf |   3 +-
 install/ui/test/utils_tests.html |  24 
 install/ui/test/utils_tests.js   | 119 +++
 7 files changed, 153 insertions(+), 3 deletions(-)
 create mode 100644 install/ui/test/utils_tests.html
 create mode 100644 install/ui/test/utils_tests.js

diff --git a/install/ui/field.js b/install/ui/field.js
index 42da6f92cd102aa665b05b72783de9d04dcdcfb0..46113b8caac0026d6e8aefd9587552b2e88b9775 100644
--- a/install/ui/field.js
+++ b/install/ui/field.js
@@ -448,13 +448,13 @@ IPA.metadata_validator = function(spec) {
 
 if (number) {
 
-if (metadata.minvalue !== undefined  Number(value)  Number(metadata.minvalue)) {
+if (!IPA.not_defined(metadata.minvalue, true)  Number(value)  Number(metadata.minvalue)) {
 message = IPA.messages.widget.validation.min_value;
 message = message.replace('${value}', metadata.minvalue);
 return that.false_result(message);
 }
 
-if (metadata.maxvalue !== undefined  Number(value)  Number(metadata.maxvalue)) {
+if (!IPA.not_defined(metadata.maxvalue, true)  Number(value)  Number(metadata.maxvalue)) {
 message = IPA.messages.widget.validation.max_value;
 message = message.replace('${value}', metadata.maxvalue);
 return that.false_result(message);
diff --git a/install/ui/ipa.js b/install/ui/ipa.js
index 23c9933dfb97cb39a932f78d235fdaf844e42b7c..d704a0a562404d07f70d09e856f42fed224f9093 100644
--- a/install/ui/ipa.js
+++ b/install/ui/ipa.js
@@ -2021,6 +2021,10 @@ IPA.is_empty = function(value) {
 return empty;
 };
 
+IPA.not_defined = function(value, check_empty_str) {
+return value === null || value === undefined || (check_empty_str  value === '');
+};
+
 IPA.array_diff = function(a, b) {
 
 if (a === b || (!a  !b)) return false;
diff --git a/install/ui/test/all_tests.html b/install/ui/test/all_tests.html
index 5a5eae54b5c6606564fd0e7b2df8ccc606dccef2..e9061b6ca8802b83c8f99c234ad7311606672695 100644
--- a/install/ui/test/all_tests.html
+++ b/install/ui/test/all_tests.html
@@ -32,6 +32,7 @@
 script type=text/javascript src=aci_tests.js/script
 script type=text/javascript src=widget_tests.js/script
 script type=text/javascript src=ip_tests.js/script
+script type=text/javascript src=utils_tests.js/script
 /head
 body
 h1 id=qunit-headerComplete Test Suite/h1
diff --git a/install/ui/test/index.html b/install/ui/test/index.html
index 1b623d40f794b1ffda90f6c3352840acbaeec26a..0a135188e518913aa3f3a191ab340f2f5e820abf 100644
--- a/install/ui/test/index.html
+++ b/install/ui/test/index.html
@@ -34,6 +34,7 @@
 lia href=aci_tests.htmlAccess Control Interface Test Suite/a
 lia href=widget_tests.htmlWidget Test Suite/a
 lia href=ip_tests.htmlIP Addresses Test Suite/a
+lia href=utils_tests.htmlUtils Test Suite/a
 /ul
 /div
 
diff --git a/install/ui/test/jsl.conf b/install/ui/test/jsl.conf
index 4654b714f91cb00696043bf3042fccd2b2e394bc..768a295f1ac7c956f588b99c60eecdb2bfb06c67 100644
--- a/install/ui/test/jsl.conf
+++ b/install/ui/test/jsl.conf
@@ -146,4 +146,5 @@
 +process ipa_tests.js
 +process ordered_map_tests.js
 +process widget_tests.js
-+process ip_tests.js
\ No newline at end of file
++process ip_tests.js
++process utils_tests.js
\ No newline at end of file
diff --git a/install/ui/test/utils_tests.html b/install/ui/test/utils_tests.html
new file mode 100644
index ..5b81cc35930766907f8db310f1e6e77edee95034
--- /dev/null
+++ b/install/ui/test/utils_tests.html
@@ -0,0 +1,24 @@
+!DOCTYPE html
+html
+head
+titleIPA utils test suite/title
+link rel=stylesheet href=qunit.css type=text/css media=screen
+script type=text/javascript src=../jquery.js/script
+script type=text/javascript src=../jquery.ba-bbq.js/script
+script type=text/javascript src=../jquery-ui.js/script
+script type=text/javascript src=../jquery.ordered-map.js/script
+script type=text/javascript

[Freeipa-devel] [PATCH] 213 JSON serialization of long type

2012-09-11 Thread Petr Vobornik 
Numbers of long type were incorrectly serialized to JSON as empty 
strings when using json_serialize function. It caused problem in 
serialization of metadata for Web UI. This patch is fixing it.


Discovered after Cast DNS SOA serial maximum boundary to long
--
Petr Vobornik
From df9d2f4ae8696f655a4e35b73508a25483be39ad Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 11 Sep 2012 14:31:13 +0200
Subject: [PATCH] JSON serialization of long type

Numbers of long type were incorrectly serialized to JSON as empty strings when using json_serialize function. It caused problem in serialization of metadata for Web UI. This patch is fixing it.

Discovered after Cast DNS SOA serial maximum boundary to long
---
 ipalib/util.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipalib/util.py b/ipalib/util.py
index ca71e78dbe478f033e52e60ac9426d3b3f12b330..1d5900924135f427da48df6b5693b686ae89eb7f 100644
--- a/ipalib/util.py
+++ b/ipalib/util.py
@@ -43,7 +43,7 @@ def json_serialize(obj):
 return [json_serialize(o) for o in obj]
 if isinstance(obj, dict):
 return dict((k, json_serialize(v)) for (k, v) in obj.iteritems())
-if isinstance(obj, (bool, float, int, unicode, NoneType)):
+if isinstance(obj, (bool, float, int, long, unicode, NoneType)):
 return obj
 if isinstance(obj, str):
 return obj.decode('utf-8')
-- 
1.7.11.4

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 304 Allow localhost in zone ACIs

2012-09-11 Thread Petr Vobornik 

On 09/10/2012 09:12 PM, Endi Sukma Dewata wrote:

On 9/6/2012 7:00 AM, Martin Kosek wrote:

On 09/06/2012 01:35 PM, Petr Vobornik wrote:

On 09/06/2012 11:51 AM, Martin Kosek wrote:

Loopback address, localhost and localnets ACIs are no longer
an issue for bind-dyndb-ldap. Allow them in our validators.



Martin's patch works and looks good - ACK.


Attaching patch for Web UI part.


Web UI validator works fine too, ACK.

Pushed both patches to master, ipa-3-0.

Martin


Looks like there's a problem in DNS zone details page. The
idnssoaserial's maxvalue is an empty string so the validation fails even
if you are just opening an existing DNS zone. So either the server
should not return maxvalue or the UI should check for possible empty
string.


I fixed the problem on both sides in patches 212, 213.

212 is fixing Web UI to be able to work with empty strings.
213 is fixing python part: serialization of long
--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1054 new default SELinux user map user

2012-09-11 Thread Rob Crittenden 

Jakub Hrozek wrote:

On Mon, Sep 10, 2012 at 05:38:47PM -0400, Rob Crittenden wrote:

We've decided to change the default SELinux user map user to the OS
default which is unconfined_u. It would be too drastic to go from
one extreme to another.

rob


How does one set an empty default that the SSSD would treat as don't
create any login file whatsoever ?


Patch updated to support that.

rob

From bfd6f7215f35f203ee9c7535cb26a854e7a910b5 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Mon, 10 Sep 2012 17:07:54 -0400
Subject: [PATCH] Set SELinux default context to unconfined_u:s0-s0:c0.c1023

Don't require ipaselinuxdefaultuser to be set. If this is unset then
SSSD will use the system default.

https://fedorahosted.org/freeipa/ticket/3045
---
 install/share/bootstrap-template.ldif | 2 +-
 install/updates/50-ipaconfig.update   | 2 +-
 ipalib/plugins/config.py  | 9 ++---
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif
index aac3f059ad30130e085bfcf37a7a1a6f1b49dc8c..24804e475427ad7e5b2ae7c69d6cfb54cafbef38 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -383,7 +383,7 @@ ipaDefaultEmailDomain: $DOMAIN
 ipaMigrationEnabled: FALSE
 ipaConfigString: AllowNThash
 ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0-s0:c0.c1023$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023
-ipaSELinuxUserMapDefault: guest_u:s0
+ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
 
 dn: cn=cosTemplates,cn=accounts,$SUFFIX
 changetype: add
diff --git a/install/updates/50-ipaconfig.update b/install/updates/50-ipaconfig.update
index b08df1806c4d2561fd5b24263e0f1c16f8b6f72f..0992db4ec92c3cc254bf8d05892dd4abd9988d8c 100644
--- a/install/updates/50-ipaconfig.update
+++ b/install/updates/50-ipaconfig.update
@@ -1,5 +1,5 @@
 dn: cn=ipaConfig,cn=etc,$SUFFIX
 add:ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0-s0:c0.c1023$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023
-add:ipaSELinuxUserMapDefault: guest_u:s0
+add:ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
 
 add:ipaUserObjectClasses: ipasshuser
diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py
index ef0fd79facd644b485831c9a0c6e6d5574c71936..e02519d5759f4e4a6d6a7075fe896f8b2e69b451 100644
--- a/ipalib/plugins/config.py
+++ b/ipalib/plugins/config.py
@@ -185,7 +185,7 @@ class config(LDAPObject):
 label=_('SELinux user map order'),
 doc=_('Order in increasing priority of SELinux users, delimited by $'),
 ),
-Str('ipaselinuxusermapdefault',
+Str('ipaselinuxusermapdefault?',
 label=_('Default SELinux user'),
 doc=_('Default SELinux user when no match is found in SELinux map rule'),
 ),
@@ -274,7 +274,10 @@ class config_mod(LDAPUpdate):
 failedattr = 'ipaselinuxusermapdefault'
 else:
 config = ldap.get_ipa_config()[1]
-defaultuser = config['ipaselinuxusermapdefault'][0]
+if 'ipaselinuxusermapdefault' in config:
+defaultuser = config['ipaselinuxusermapdefault'][0]
+else:
+defaultuser = None
 
 if 'ipaselinuxusermaporder' in validate:
 order = validate['ipaselinuxusermaporder']
@@ -284,7 +287,7 @@ class config_mod(LDAPUpdate):
 config = ldap.get_ipa_config()[1]
 order = config['ipaselinuxusermaporder']
 userlist = order[0].split('$')
-if defaultuser not in userlist:
+if defaultuser and defaultuser not in userlist:
 raise errors.ValidationError(name=failedattr,
 error=_('SELinux user map default user not in order list'))
 
-- 
1.7.11.4

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Ticket #2866 - referential integrity in IPA

2012-09-11 Thread Martin Kosek 
On 09/04/2012 04:40 PM, Rich Megginson wrote:
 On 09/03/2012 08:42 AM, Martin Kosek wrote:
 On 08/27/2012 06:29 PM, Rich Megginson wrote:
...
 This is the plan I plan to take:
 1) Add pres,eq indexes for all un-indexed attributes that we want to check:
 sourcehost
 memberservice
 managedby
 memberallowcmd
 memberdenycmd
 ipasudorunas
 ipasudorunasgroup
 ok
...

Implementation of the Referential Integrity in IPA works OK so far, I just hit
a strange issue when indexing memberallowcmd and memberdenycmd attributes in 
IPA:

dirsrv errors log:
...
[11/Sep/2012:11:39:53 -0400] - The attribute [memberdenycmd] does not have a
valid ORDERING matching rule - error 2:s
[11/Sep/2012:11:39:58 -0400] - userRoot: Indexing attribute: memberdenycmd
[11/Sep/2012:11:39:58 -0400] - userRoot: Finished indexing.
...

This cause RI to fail to handle this attribute in IPA (which is expected based
on the error message).

I checked the attributes types, they look like that:

attributetypes: ( 2.16.840.1.113730.3.8.7.1 NAME 'memberAllowCmd' DESC 'Refere
 nce to a command or group of commands that are allowed by the rule.' SUP dist
 inguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch
  SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN
 'IPA v2' )

attributetypes: ( 2.16.840.1.113730.3.8.7.2 NAME 'memberDenyCmd' DESC 'Referen
 ce to a command or group of commands that are denied by the rule.' SUP distin
 guishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch S
 UBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'I
 PA v2' )

distinguishedNameMatch ORDERING rule looks wrong, it is only a matching rule.
Anyone knows why it was defined that way? Or what should be a correct setting
for this attribute instead? caseIgnoreOrderingMatch seems as a logical choice...

I will have to fix the attributeTypes definition in IPA before we can enable
index  RI for them.

Thanks,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Rob Crittenden 

Petr Viktorin wrote:

On 09/11/2012 04:38 PM, Rob Crittenden wrote:

Ade Lee wrote:

On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing with
them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to
split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm
update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still using a
Dogtag 9 style instance. The Dogtag 10 ports are only used in new
installs.


The ipa package lacks any updated dogtag dependencies, so I abused
it.


What should the updated dependencies be? Since it should work with
both
dogtag 9 and 10, I don't see how they should change.


I don't know either, but we need to prevent people from installing
incompatible package combinations.


Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy this
requirement?  The main concern is that you must have ipa 3.0 if you have
dogtag 10.

Given that dogtag is consumed by IPA though, it makes more sense to put
the relevant conflicts in IPA rather than in dogtag.  So in this case,
that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
Recall that dogtag 10 will only be officially available in f18+.


That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to
F-18 they would be able to install dogtag 10 and blow up their IPA
server.




I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update
process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?
This is
still required right now until I get the selinux policy all
straightened
out.

There is also a separate dogtag ticket (which is currently being
worked
on) to restart existing dogtag instances when dogtag is upgraded from
9-10.


In permissive mode, this upgrade works for me.


I was in enforcing mode but saw no AVCs. What is the ETA on fixing
this?



Within the next week or two, I need to finish the IPA merge database
patch first, and then co-ordinate changes with the selinux guys.




Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Service Temporarily Unavailable)

Usually, waiting a couple of minutes clears this up. Perhaps we are
not
doing startup detection correctly. Ade mentioned that waiting for
ports
may not be ideal. How do we know if Dogtag is initialized?


Years ago we had discussed with Andrew and Matt creating a URI that can
be queried to determine dogtag status. I don't think that ever went
anywhere.


Petr, this happens only on reboot, right?  And not on regular service
ipa restart?


I've now seen it happen right after a 9 → 10 upgrade.


Yeah, I remember this conversation - and even created a bug for it at
some point.  This went away because the mechanism you were using seemed
to be working.  The timing may be very different now with tomcat 7 and
systemd.  I'll open a dogtag trac ticket for this.


Ok.






Uninstalling failed because it tried to run pkidestroy and not
pkiremove.


I was under the impression that pkidestroy was the correct command to
remove an upgraded instance. I'll check with Ade.


I'll test this too.


The contents of the file passed to pkispawn should be logged so we
can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll
put it
in the next version of the patch.


The question to ask is: would you need the contents of this file if all
you got were logs and needed to evaluate why installation failed? In
most cases this is yes.


Up to you guys.  There is a patch I am working on in which I will be
logging the object that is being passed to the server from pkispawn.
That - and the diffs to the standard config file as I mentioned above -
will likely be sufficient to debug almost all cases.

Make sure not to log any passwords.



Thanks for the catch. Attaching updated patch that sanitizes the passwords.


DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first
updating
ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in
it.


We can add that.

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Rob Crittenden 

Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:38 PM, Rob Crittenden wrote:

Ade Lee wrote:

On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing
with
them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to
split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm
update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still using a
Dogtag 9 style instance. The Dogtag 10 ports are only used in new
installs.


The ipa package lacks any updated dogtag dependencies, so I abused
it.


What should the updated dependencies be? Since it should work with
both
dogtag 9 and 10, I don't see how they should change.


I don't know either, but we need to prevent people from installing
incompatible package combinations.


Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy
this
requirement?  The main concern is that you must have ipa 3.0 if you
have
dogtag 10.

Given that dogtag is consumed by IPA though, it makes more sense to put
the relevant conflicts in IPA rather than in dogtag.  So in this case,
that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
Recall that dogtag 10 will only be officially available in f18+.


That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to
F-18 they would be able to install dogtag 10 and blow up their IPA
server.




I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update
process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?
This is
still required right now until I get the selinux policy all
straightened
out.

There is also a separate dogtag ticket (which is currently being
worked
on) to restart existing dogtag instances when dogtag is upgraded
from
9-10.


In permissive mode, this upgrade works for me.


I was in enforcing mode but saw no AVCs. What is the ETA on fixing
this?



Within the next week or two, I need to finish the IPA merge database
patch first, and then co-ordinate changes with the selinux guys.




Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Service Temporarily Unavailable)

Usually, waiting a couple of minutes clears this up. Perhaps we are
not
doing startup detection correctly. Ade mentioned that waiting for
ports
may not be ideal. How do we know if Dogtag is initialized?


Years ago we had discussed with Andrew and Matt creating a URI that
can
be queried to determine dogtag status. I don't think that ever went
anywhere.


Petr, this happens only on reboot, right?  And not on regular service
ipa restart?


I've now seen it happen right after a 9 → 10 upgrade.


Yeah, I remember this conversation - and even created a bug for it at
some point.  This went away because the mechanism you were using seemed
to be working.  The timing may be very different now with tomcat 7 and
systemd.  I'll open a dogtag trac ticket for this.


Ok.






Uninstalling failed because it tried to run pkidestroy and not
pkiremove.


I was under the impression that pkidestroy was the correct command to
remove an upgraded instance. I'll check with Ade.


I'll test this too.


The contents of the file passed to pkispawn should be logged so we
can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the
modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll
put it
in the next version of the patch.


The question to ask is: would you need the contents of this file if
all
you got were logs and needed to evaluate why installation failed? In
most cases this is yes.


Up to you guys.  There is a patch I am working on in which I will be
logging the object that is being passed to the server from pkispawn.
That - and the diffs to the standard config file as I mentioned above -
will likely be sufficient to debug almost all cases.

Make sure not to log any passwords.



Thanks for the catch. Attaching updated patch that sanitizes the
passwords.


DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first
updating
ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Rob Crittenden 

Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:38 PM, Rob Crittenden wrote:

Ade Lee wrote:

On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing
with
them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to
split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm
update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still using a
Dogtag 9 style instance. The Dogtag 10 ports are only used in new
installs.


The ipa package lacks any updated dogtag dependencies, so I abused
it.


What should the updated dependencies be? Since it should work with
both
dogtag 9 and 10, I don't see how they should change.


I don't know either, but we need to prevent people from installing
incompatible package combinations.


Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy
this
requirement?  The main concern is that you must have ipa 3.0 if you
have
dogtag 10.

Given that dogtag is consumed by IPA though, it makes more sense to put
the relevant conflicts in IPA rather than in dogtag.  So in this case,
that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
Recall that dogtag 10 will only be officially available in f18+.


That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to
F-18 they would be able to install dogtag 10 and blow up their IPA
server.




I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update
process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?
This is
still required right now until I get the selinux policy all
straightened
out.

There is also a separate dogtag ticket (which is currently being
worked
on) to restart existing dogtag instances when dogtag is upgraded
from
9-10.


In permissive mode, this upgrade works for me.


I was in enforcing mode but saw no AVCs. What is the ETA on fixing
this?



Within the next week or two, I need to finish the IPA merge database
patch first, and then co-ordinate changes with the selinux guys.




Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Service Temporarily Unavailable)

Usually, waiting a couple of minutes clears this up. Perhaps we are
not
doing startup detection correctly. Ade mentioned that waiting for
ports
may not be ideal. How do we know if Dogtag is initialized?


Years ago we had discussed with Andrew and Matt creating a URI that
can
be queried to determine dogtag status. I don't think that ever went
anywhere.


Petr, this happens only on reboot, right?  And not on regular service
ipa restart?


I've now seen it happen right after a 9 → 10 upgrade.


Yeah, I remember this conversation - and even created a bug for it at
some point.  This went away because the mechanism you were using seemed
to be working.  The timing may be very different now with tomcat 7 and
systemd.  I'll open a dogtag trac ticket for this.


Ok.






Uninstalling failed because it tried to run pkidestroy and not
pkiremove.


I was under the impression that pkidestroy was the correct command to
remove an upgraded instance. I'll check with Ade.


I'll test this too.


The contents of the file passed to pkispawn should be logged so we
can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the
modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll
put it
in the next version of the patch.


The question to ask is: would you need the contents of this file if
all
you got were logs and needed to evaluate why installation failed? In
most cases this is yes.


Up to you guys.  There is a patch I am working on in which I will be
logging the object that is being passed to the server from pkispawn.
That - and the diffs to the standard config file as I mentioned above -
will likely be sufficient to debug almost all cases.

Make sure not to log any passwords.



Thanks for the catch. Attaching updated patch that sanitizes the
passwords.


DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first
updating
ipa? I think that pki-ca is going to need a Conflicts ipa  3.0 in

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Rob Crittenden 

Rob Crittenden wrote:

Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:38 PM, Rob Crittenden wrote:

Ade Lee wrote:

On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

On 09/11/2012 04:04 AM, Ade Lee wrote:

On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:

Petr Viktorin wrote:

Attaching rebased and squashed patches. I've done some testing
with
them
but please test some more.



Most of these aren't IPA issues, but dogtag issues. I'll try to
split
them out.

IPA:

For the configuration files in install/conf to be updated at rpm
update
time the VERSION needs to be incremented.


These files should stay the same since on upgrade we're still
using a
Dogtag 9 style instance. The Dogtag 10 ports are only used in new
installs.


The ipa package lacks any updated dogtag dependencies, so I abused
it.


What should the updated dependencies be? Since it should work with
both
dogtag 9 and 10, I don't see how they should change.


I don't know either, but we need to prevent people from installing
incompatible package combinations.


Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy
this
requirement?  The main concern is that you must have ipa 3.0 if you
have
dogtag 10.

Given that dogtag is consumed by IPA though, it makes more sense to
put
the relevant conflicts in IPA rather than in dogtag.  So in this case,
that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
Recall that dogtag 10 will only be officially available in f18+.


That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to
F-18 they would be able to install dogtag 10 and blow up their IPA
server.




I installed IPA with dogtag 9 and created a replica.

I updated the IPA bits, that worked fine.

I updated to dogtag 10 and now the CA doesn't work on the master,
including starting the dogtag instance. Note that the rpm update
process
worked, no notice that the CA service didn't restart.


Did you try to restart the CA with selinux in permissive mode?
This is
still required right now until I get the selinux policy all
straightened
out.

There is also a separate dogtag ticket (which is currently being
worked
on) to restart existing dogtag instances when dogtag is upgraded
from
9-10.


In permissive mode, this upgrade works for me.


I was in enforcing mode but saw no AVCs. What is the ETA on fixing
this?



Within the next week or two, I need to finish the IPA merge database
patch first, and then co-ordinate changes with the selinux guys.




Sometimes I do get this error intermittently:

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Service Temporarily Unavailable)

Usually, waiting a couple of minutes clears this up. Perhaps we are
not
doing startup detection correctly. Ade mentioned that waiting for
ports
may not be ideal. How do we know if Dogtag is initialized?


Years ago we had discussed with Andrew and Matt creating a URI that
can
be queried to determine dogtag status. I don't think that ever went
anywhere.


Petr, this happens only on reboot, right?  And not on regular service
ipa restart?


I've now seen it happen right after a 9 → 10 upgrade.


Yeah, I remember this conversation - and even created a bug for it at
some point.  This went away because the mechanism you were using
seemed
to be working.  The timing may be very different now with tomcat 7 and
systemd.  I'll open a dogtag trac ticket for this.


Ok.






Uninstalling failed because it tried to run pkidestroy and not
pkiremove.


I was under the impression that pkidestroy was the correct
command to
remove an upgraded instance. I'll check with Ade.


I'll test this too.


The contents of the file passed to pkispawn should be logged so we
can
see exactly what was passed in.


Its a pretty big file.  You might want to only log the
modifications.
Or save the file somewhere.


Our logs are pretty verbose, so that shouldn't be a problem. I'll
put it
in the next version of the patch.


The question to ask is: would you need the contents of this file if
all
you got were logs and needed to evaluate why installation failed? In
most cases this is yes.


Up to you guys.  There is a patch I am working on in which I will be
logging the object that is being passed to the server from pkispawn.
That - and the diffs to the standard config file as I mentioned
above -
will likely be sufficient to debug almost all cases.

Make sure not to log any passwords.



Thanks for the catch. Attaching updated patch that sanitizes the
passwords.


DOGTAG:

When upgrading using the dogtag-devel repo I had to specify
pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
versions (and failed).

I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
--enablerepo=dogtag-devel --enablerepo=updates-testing


We'll look into this.  I think I know why this happens.


What happens if someone manually upgrades pki-ca without first
updating
ipa? I think that pki-ca is going to need

Re: [Freeipa-devel] Ticket #2866 - referential integrity in IPA

2012-09-11 Thread Rich Megginson 

On 09/11/2012 10:51 AM, Martin Kosek wrote:

On 09/04/2012 04:40 PM, Rich Megginson wrote:

On 09/03/2012 08:42 AM, Martin Kosek wrote:

On 08/27/2012 06:29 PM, Rich Megginson wrote:

...

This is the plan I plan to take:
1) Add pres,eq indexes for all un-indexed attributes that we want to check:
sourcehost
memberservice
managedby
memberallowcmd
memberdenycmd
ipasudorunas
ipasudorunasgroup

ok

...

Implementation of the Referential Integrity in IPA works OK so far, I just hit
a strange issue when indexing memberallowcmd and memberdenycmd attributes in 
IPA:

dirsrv errors log:
...
[11/Sep/2012:11:39:53 -0400] - The attribute [memberdenycmd] does not have a
valid ORDERING matching rule - error 2:s
[11/Sep/2012:11:39:58 -0400] - userRoot: Indexing attribute: memberdenycmd
[11/Sep/2012:11:39:58 -0400] - userRoot: Finished indexing.
...

This cause RI to fail to handle this attribute in IPA (which is expected based
on the error message).

I checked the attributes types, they look like that:

attributetypes: ( 2.16.840.1.113730.3.8.7.1 NAME 'memberAllowCmd' DESC 'Refere
  nce to a command or group of commands that are allowed by the rule.' SUP dist
  inguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch
   SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN
  'IPA v2' )

attributetypes: ( 2.16.840.1.113730.3.8.7.2 NAME 'memberDenyCmd' DESC 'Referen
  ce to a command or group of commands that are denied by the rule.' SUP distin
  guishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch S
  UBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'I
  PA v2' )

distinguishedNameMatch ORDERING rule looks wrong, it is only a matching rule.
Anyone knows why it was defined that way? Or what should be a correct setting
for this attribute instead? caseIgnoreOrderingMatch seems as a logical choice...
Not sure.  The problem is that, in LDAP, there isn't a concept of 
ordering or substring matching on DN values.  
http://www.ietf.org/rfc/rfc4517.txt - there is only 
distinguishedNameMatch which is an EQUALITY rule.  Do you really need 
ordering and substring here?  The problem with using some other ordering 
or substring matching rule is that it will not properly normalize the DN 
valued string, so you may get incorrect results.


I will have to fix the attributeTypes definition in IPA before we can enable
index  RI for them.

Thanks,
Martin


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0078 ipa-client-install: Obtain host TGT from one specific KDC

2012-09-11 Thread Rob Crittenden 

Petr Viktorin wrote:

When installing the client, we need to take extra case to only contact
the one server we're installing against. Otherwise, in the real world,
we might hit a server that hasn't replicated info about the client yet.

This patch fixes a bug where kinit attempted to contact a KDC that
didn't have the host principal yet.


To reproduce:

- Install a master and replica
- Change the Kerberos DNS entries to only point to the replica:
 for REC_NAME in '_kerberos-master._tcp' '_kerberos-master._udp'
'_kerberos._tcp' '_kerberos._udp' '_kpasswd._tcp' '_kpasswd._udp'; do
 ipa dnsrecord-mod $DOMAIN $REC_NAME --srv-rec=0 100 88
$REPLICA_HOSTNAME
 done
 ipa dnsrecord-mod $DOMAIN _ldap._tcp --srv-rec=0 100 389
$MASTER_HOSTNAME
 ipa dnsrecord-find $DOMAIN  # check
- Sever communication between the hosts to disable replication:
 (on master)
 iptables -A INPUT -j DROP -p all --source $REPLICA_IP
- On client machine, put master as nameserver in /etc/resolv.conf 
install client

This will fail without the patch.


Thanks to Petr Spacek, Simo, and Scott for helping to reproduce and
explain the bug. I learned a lot.

https://fedorahosted.org/freeipa/ticket/2982


ACK, pushed to master and ipa-3-0

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0077 Check direct/reverse hostname/address resolution in ipa-replica-install

2012-09-11 Thread Rob Crittenden 

Petr Viktorin wrote:

On 09/04/2012 07:44 PM, Rob Crittenden wrote:

Petr Viktorin wrote:


https://fedorahosted.org/freeipa/ticket/2845


Shouldn't this also call verify_fqdn() on the local hostname and not
just the master? I think this would eventually fail in the conncheck but
what if that was skipped?

rob


A few lines above there is a call to get_host_name, which will call
verify_fqdn.



I double-checked this, it fails in conncheck. Here are my steps:

# ipa-server-install --setup-dns
# ipa-replica-prepare replica.example.com --ip-address=192.168.100.2
# ipa host-del replica.example.com

On replica, set DNS to IPA master, with hostname in /etc/hosts.

# ipa-replica-install ...

The verify_fqdn() passes because the resolver uses /etc/hosts.

The conncheck fails:

Execute check on remote master
Check connection from master to remote replica 'replica.example.com':

Remote master check failed with following error message(s):
Could not chdir to home directory /home/admin: No such file or directory
Port check failed! Unable to resolve host name 'replica.example.com'

Connection check failed!
Please fix your network settings according to error messages above.
If the check results are not valid it can be skipped with 
--skip-conncheck parameter.


The DNS test happens much further after this, and I get why, I just 
don't see how useful it is unless the --skip-conncheck is used.


ipa-replica-install ~rcrit/replica-info-replica.example.com.gpg 
--skip-conncheck

Directory Manager (existing master) password:

ipa : ERRORCould not resolve hostname replica.example.com 
using DNS. Clients may not function properly. Please check your DNS 
setup. (Note that this check queries IPA DNS directly and ignores 
/etc/hosts.)

Continue? [no]:

So I guess, what are the intentions here? It is certainly better than 
before.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] slow response

2012-09-11 Thread Stephen Ingram 
On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce s...@redhat.com wrote:
 On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote:
 On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce s...@redhat.com wrote:
  Quick heads up in this thread,
 
  apparently we have isolated the issue to libkrb5 and its selinux
  integration.
  I have made the whole delay go away by disabling selinux entirely (which
  makes libkrb5 stop trying to do some selinux related operations).
 
  We will be working on a fix to have libkrb5 not cause this delay (F17
  doesn't have it).
 
  You can follow progress on this bugzilla:
  https://bugzilla.redhat.com/show_bug.cgi?id=845125


 I could see this BZ for a couple of days, but now it says that I must
 log in to an account first with the appropriate permissions. Has this
 been moved or something?

 Steve

 Sorry Stpehen we have a stupid bot that sometimes decides to flag bugs
 as internal for reasons I do not understand, I removed the flag, you
 should be able to see it again now.

This must have happened again as I can no longer see the bug. This
must be a tough one as there seems to still be no update?

Steve

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] slow response

2012-09-11 Thread Rob Crittenden 

Stephen Ingram wrote:

On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce s...@redhat.com wrote:

On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote:

On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce s...@redhat.com wrote:

Quick heads up in this thread,

apparently we have isolated the issue to libkrb5 and its selinux
integration.
I have made the whole delay go away by disabling selinux entirely (which
makes libkrb5 stop trying to do some selinux related operations).

We will be working on a fix to have libkrb5 not cause this delay (F17
doesn't have it).

You can follow progress on this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=845125



I could see this BZ for a couple of days, but now it says that I must
log in to an account first with the appropriate permissions. Has this
been moved or something?

Steve


Sorry Stpehen we have a stupid bot that sometimes decides to flag bugs
as internal for reasons I do not understand, I removed the flag, you
should be able to see it again now.


This must have happened again as I can no longer see the bug. This
must be a tough one as there seems to still be no update?



Hmm, I can see it without logging into BZ. The short summary is that 
Nalin has a patch for it as of yesterday.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

2012-09-11 Thread Ade Lee 
On Tue, 2012-09-11 at 14:45 -0400, Rob Crittenden wrote:
 Petr Viktorin wrote:
  On 09/11/2012 04:38 PM, Rob Crittenden wrote:
  Ade Lee wrote:
  On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote:
  Petr Viktorin wrote:
  On 09/11/2012 04:04 AM, Ade Lee wrote:
  On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:
  Petr Viktorin wrote:
  Attaching rebased and squashed patches. I've done some testing with
  them
  but please test some more.
 
 
  Most of these aren't IPA issues, but dogtag issues. I'll try to
  split
  them out.
 
  IPA:
 
  For the configuration files in install/conf to be updated at rpm
  update
  time the VERSION needs to be incremented.
 
  These files should stay the same since on upgrade we're still using a
  Dogtag 9 style instance. The Dogtag 10 ports are only used in new
  installs.
 
  The ipa package lacks any updated dogtag dependencies, so I abused
  it.
 
  What should the updated dependencies be? Since it should work with
  both
  dogtag 9 and 10, I don't see how they should change.
 
  I don't know either, but we need to prevent people from installing
  incompatible package combinations.
 
  Would'nt the Conflicts: ipa  3.0 in pki-ca mentioned below satisfy this
  requirement?  The main concern is that you must have ipa 3.0 if you have
  dogtag 10.
 
  Given that dogtag is consumed by IPA though, it makes more sense to put
  the relevant conflicts in IPA rather than in dogtag.  So in this case,
  that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x.
  Recall that dogtag 10 will only be officially available in f18+.
 
  That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to
  F-18 they would be able to install dogtag 10 and blow up their IPA
  server.
 
We can add the Conflicts: freeipa-server  3.0 to the dogtag packages
(likely in pki-base).

But we should also add explicit dependencies to ipa.

For ipa 2.2, Conflicts: pki-ca = 10.0, Requires: pki-ca = 9.x
For ipa 3,   Requires: pki-ca = 10.0

This is of course assumes that ipa 3 is only officially released on f18
(which is what will happen for dogtag 10).  Just because we can support
d9 on ipa 3 does not mean we should.

As it is, in this case, we will have to support IPA 3 + d10, IPA 3 + d10
+ d9-style instance, IPA 2.x + d9.

 
  I installed IPA with dogtag 9 and created a replica.
 
  I updated the IPA bits, that worked fine.
 
  I updated to dogtag 10 and now the CA doesn't work on the master,
  including starting the dogtag instance. Note that the rpm update
  process
  worked, no notice that the CA service didn't restart.
 
  Did you try to restart the CA with selinux in permissive mode?
  This is
  still required right now until I get the selinux policy all
  straightened
  out.
 
  There is also a separate dogtag ticket (which is currently being
  worked
  on) to restart existing dogtag instances when dogtag is upgraded from
  9-10.
 
  In permissive mode, this upgrade works for me.
 
  I was in enforcing mode but saw no AVCs. What is the ETA on fixing
  this?
 
 
  Within the next week or two, I need to finish the IPA merge database
  patch first, and then co-ordinate changes with the selinux guys.
 
 
 
  Sometimes I do get this error intermittently:
 
  ipa: ERROR: Certificate operation cannot be completed: Unable to
  communicate with CMS (Service Temporarily Unavailable)
 
  Usually, waiting a couple of minutes clears this up. Perhaps we are
  not
  doing startup detection correctly. Ade mentioned that waiting for
  ports
  may not be ideal. How do we know if Dogtag is initialized?
 
  Years ago we had discussed with Andrew and Matt creating a URI that can
  be queried to determine dogtag status. I don't think that ever went
  anywhere.
 
  Petr, this happens only on reboot, right?  And not on regular service
  ipa restart?
 
  I've now seen it happen right after a 9 → 10 upgrade.
 
  Yeah, I remember this conversation - and even created a bug for it at
  some point.  This went away because the mechanism you were using seemed
  to be working.  The timing may be very different now with tomcat 7 and
  systemd.  I'll open a dogtag trac ticket for this.
 
  Ok.
 
 
 
  Uninstalling failed because it tried to run pkidestroy and not
  pkiremove.
 
  I was under the impression that pkidestroy was the correct command to
  remove an upgraded instance. I'll check with Ade.
 
  I'll test this too.
 
  The contents of the file passed to pkispawn should be logged so we
  can
  see exactly what was passed in.
 
  Its a pretty big file.  You might want to only log the modifications.
  Or save the file somewhere.
 
  Our logs are pretty verbose, so that shouldn't be a problem. I'll
  put it
  in the next version of the patch.
 
  The question to ask is: would you need the contents of this file if all
  you got were logs and needed to evaluate why installation failed? In
  most cases this is yes.
 
  Up to you guys.  There is a patch I am working on in which I will be
  logging the object that

Re: [Freeipa-devel] slow response

2012-09-11 Thread Stephen Ingram 
On Tue, Sep 11, 2012 at 7:31 PM, Rob Crittenden rcrit...@redhat.com wrote:
 Stephen Ingram wrote:

 On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce s...@redhat.com wrote:

 On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote:

 On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce s...@redhat.com wrote:

 Quick heads up in this thread,

 apparently we have isolated the issue to libkrb5 and its selinux
 integration.
 I have made the whole delay go away by disabling selinux entirely
 (which
 makes libkrb5 stop trying to do some selinux related operations).

 We will be working on a fix to have libkrb5 not cause this delay (F17
 doesn't have it).

 You can follow progress on this bugzilla:
 https://bugzilla.redhat.com/show_bug.cgi?id=845125



 I could see this BZ for a couple of days, but now it says that I must
 log in to an account first with the appropriate permissions. Has this
 been moved or something?

 Steve


 Sorry Stpehen we have a stupid bot that sometimes decides to flag bugs
 as internal for reasons I do not understand, I removed the flag, you
 should be able to see it again now.


 This must have happened again as I can no longer see the bug. This
 must be a tough one as there seems to still be no update?


 Hmm, I can see it without logging into BZ. The short summary is that Nalin
 has a patch for it as of yesterday.

I can see the bug again now too. Strange. Thanks for the update too.

Steve

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel