Re: [Freeipa-devel] [PATCH] 993 disable UPG for migration

2012-04-02 Thread Martin Kosek
On Fri, 2012-03-30 at 09:05 -0400, Rob Crittenden wrote:
 Martin Kosek wrote:
  On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote:
  Martin Kosek wrote:
  On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote:
  Martin Kosek wrote:
  On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote:
  We don't want to create private groups automatically for migrated 
  users,
  there could be namespace overlap (and race conditions prevent us from
  trying to check in advance).
 
  Check the sanity of groups in general, warn if the group for the
  gidnumber doesn't exist at least on the remote server.
 
  Fill in the user's shell as well.
 
  This will migrate users that are non-POSIX on the remote server.
 
  rob
 
  This patch fixes the problem of creating UPGs for migrated users, but
  there are several parts which confused me.
 
  1) Confusing defaults
 
  +if 'def_group_gid' in ctx:
  +entry_attrs.setdefault('gidnumber', ctx['def_group_gid'])
 
  This statement seems redundant, because the account either is posix and
  has both uidnumber and gidnumber or it is non-posix and does not have
  any.
 
  Now, we don't touch gidNumber for posix user, and non-posix users are
  made posix with this statement:
 
  +# migrated user is not already POSIX, make it so
  +if 'uidnumber' not in entry_attrs:
  +entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999]
 
 
  2) Missing UPG
  When UPG is disabled, the following statement will result in a user with
  a GID pointing to non-existent group.
 
  +# migrated user is not already POSIX, make it so
  +if 'uidnumber' not in entry_attrs:
  +entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999]
 
  We may want to run ldap.has_upg() and report a add this user to failed
  users with appropriate error.
 
  3) Check for GID
  The patch implements a check if a group with the gidNumber exists on a
  remote LDAP server and the result is a warning:
 
  -(g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], 
  ['gidnumber'])
  +(remote_dn, remote_entry) = ds_ldap.find_entry_by_attr(
  +'gidnumber', entry_attrs['gidnumber'][0], 
  'posixgroup', [''],
  + search_bases['group']
  +)
 
  I have few (minor-ish) questions there:
  a) Is the warning in a apache log enough? Maybe it should be included in
  migrate-ds output.
  b) This will be a one more remote LDAP call for every user, we may want
  to optimize it with something like that:
 
  valid_gids = []
  if user.gidnumber not in valid_gids:
run the check in remote LDAP
valid_gids.append(user.gidnumber)
 
  That would save us 999 LDAP queries for 1000 migrated with the same
  primary group.
 
  4) Extraneous Warning:
  When non-posix user is migrated and thus we make it a posix user, we
  still produce a warning for non-existent group:
 
  [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID
  number 999 does not point to a known group.
 
  5) Extraneous LDAP call
 
  Isn't the following call to LDAP to get a description redundant? We
  already have the description in entry_attrs.
 
  +(dn, desc_attr) = ldap.get_entry(dn, ['description'])
  +entry_attrs.update(desc_attr)
  +if 'description' in entry_attrs and NO_UPG_MAGIC in
  entry_attrs['description']:
 
 
  Martin
 
 
  I think this covers your concerns.
 
  I can't do anything but log warnings at this point in order to maintain
  backwards compatibility. I looked into returning a warning entry and it
  blew up in validate_output() on older clients.
 
  rob
 
 
  This patch is much better and covers my previous concerns. I just find
  an issue with UPG. It is not created for non-posix users when UPGs are
  enabled:
 
  # echo Secret123 | ipa migrate-ds ldap://ldap.example.com
  --with-compat --base-dn=dc=greyoak,dc=com
  ---
  migrate-ds:
  ---
  Migrated:
  user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg
  group: ipagroup
  Failed user:
  Failed group:
  --
  Passwords have been migrated in pre-hashed format.
  IPA is unable to generate Kerberos keys unless provided
  with clear text passwords. All migrated users need to
  login at https://your.domain/ipa/migration/ before they
  can use their Kerberos accounts.
 
  # ipa user-show mnonposix
  User login: mnonposix
  First name: Mister
  Last name: Nonposix
  Home directory: /home/mnonposix
  Login shell: /bin/sh
  UID: 328000195
  GID: 328000195
  Org. Unit: Product Testing
  Job Title: Test User
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: False
 
  # ipa group-show mnonposix
  ipa: ERROR: mnonposix: group not found
 
  Yes, I was always disabling UPG. I now allow it when migrating a
  non-POSIX user.
 
  I am also thinking if we need to ask if UPG is enabled for every
  migrated user - every ldap.has_upg() 

Re: [Freeipa-devel] [PATCH] 1000 fix upgrade crash when updating replication agreements

2012-04-02 Thread Martin Kosek
On Fri, 2012-03-30 at 14:13 -0400, Rob Crittenden wrote:
 We check existing agreements to see if they are missing memberof in the 
 EXCLUDE list. It would crash if this list wasn't present at all.
 
 So we need to catch this and add in the missing exclusions if they 
 aren't there at all.
 
 rob

ACK, the attribute is now correctly fixed even when its not present in
the agreement. Pushed to master, ipa-2-2.

Martin

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


Re: [Freeipa-devel] [PATCH 69] Use indexed format specifiers in i18n strings

2012-04-02 Thread Rob Crittenden

John Dennis wrote:

Translators need to reorder messages to suit the needs of the target
language. The conventional positional format specifiers (e.g. %s %d)
do not permit reordering because their order is tied to the ordering
of the arguments to the printf function. The fix is to use indexed
format specifiers.


I guess this looks ok but all of these errors are of the format: string 
error, error number (and inconsistently, sometimes the reverse). Do 
those really need to be re-orderable?


rob

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


Re: [Freeipa-devel] [PATCH] 0032 Move DNS test skipping to class setup

2012-04-02 Thread Rob Crittenden

Petr Viktorin wrote:

On 03/29/2012 10:18 PM, Rob Crittenden wrote:

Petr Viktorin wrote:


Currently, each DNS test case first checks if DNS is configured
by creating and deleting a test zone. This takes quite a lot of time.

This patch moves the check to the setUpClass method, so the check is
only done once for all the tests.



On my VM, this makes the DNS plugin tests 50% faster, saving about half
a minute for each test run.



This fails if the test XML-RPC server is not running. While working on
that issue I found a few other places that weren't handling this as
well. Here is my working patch on top of yours.

rob


Thank you! I see the other place is one I added recently.

This updated patch includes your diff, and also makes sure a context is
created for the DNS test skipping.




ACK, pushed to master and ipa-2-2

rob

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


Re: [Freeipa-devel] [PATCH] 998 certmonger restarts services on renewal

2012-04-02 Thread Martin Kosek
On Tue, 2012-03-27 at 17:40 -0400, Rob Crittenden wrote:
 Certmonger will currently automatically renew server certificates but 
 doesn't restart the services so you can still end up with expired 
 certificates if you services never restart.
 
 This patch registers are restart command with certmonger so the IPA 
 services will automatically be restarted to get the updated cert.
 
 Easy to test. Install IPA then resubmit the current server certs and 
 watch the services restart:
 
 # ipa-getcert list
 
 Find the ID for either your dirsrv or httpd instance
 
 # ipa-getcert resubmit -i ID
 
 Watch /var/log/httpd/error_log or /var/log/dirsrv/slapd-INSTANCE/errors 
 to see the service restart.
 
 rob

What about current instances - can we/do we want to update certmonger
tracking so that their instances are restarted as well?

Anyway, I found few issues SELinux issues with the patch:

1) # rpm -Uvh freeipa-*
Preparing...### [100%]
   1:freeipa-python ### [ 20%]
   2:freeipa-client ### [ 40%]
   3:freeipa-admintools ### [ 60%]
   4:freeipa-server ### [ 80%]
/usr/bin/chcon: failed to change context of `/usr/lib64/ipa/certmonger' to 
`unconfined_u:object_r:certmonger_unconfined_exec_t:s0': Invalid argument
/usr/bin/chcon: failed to change context of 
`/usr/lib64/ipa/certmonger/restart_dirsrv' to 
`unconfined_u:object_r:certmonger_unconfined_exec_t:s0': Invalid argument
/usr/bin/chcon: failed to change context of 
`/usr/lib64/ipa/certmonger/restart_httpd' to 
`unconfined_u:object_r:certmonger_unconfined_exec_t:s0': Invalid argument
warning: %post(freeipa-server-2.1.90GIT5b895af-0.fc16.x86_64) scriptlet failed, 
exit status 1
   5:freeipa-server-selinux ### [100%]

certmonger_unconfined_exec_t type was unknown with my selinux policy:

selinux-policy-3.10.0-80.fc16.noarch
selinux-policy-targeted-3.10.0-80.fc16.noarch

If we need a higher SELinux version, we should bump the required package
version spec file.


2) Change of SELinux context with /usr/bin/chcon is temporary until
restorecon or system relabel occurs. I think we should make it
persistent and enforce this type in our SELinux policy and rather call
restorecon instead of chcon

Martin

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


Re: [Freeipa-devel] [PATCH] 349 Fixed boot.ldif permission.

2012-04-02 Thread Rob Crittenden

Endi Sukma Dewata wrote:

The server installation failed on F17 due to permission problem.
The /var/lib/dirsrv/boot.ldif was previously owned and only readable
by root. It is now owned by DS user dirsrv.

Ticket #2544


ACK, pushed to master

rob

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


Re: [Freeipa-devel] [PATCH] 998 certmonger restarts services on renewal

2012-04-02 Thread Nalin Dahyabhai
On Mon, Apr 02, 2012 at 03:47:20PM +0200, Martin Kosek wrote:
 On Tue, 2012-03-27 at 17:40 -0400, Rob Crittenden wrote:
  Certmonger will currently automatically renew server certificates but 
  doesn't restart the services so you can still end up with expired 
  certificates if you services never restart.
  
  This patch registers are restart command with certmonger so the IPA 
  services will automatically be restarted to get the updated cert.
  
  Easy to test. Install IPA then resubmit the current server certs and 
  watch the services restart:
  
  # ipa-getcert list
  
  Find the ID for either your dirsrv or httpd instance
  
  # ipa-getcert resubmit -i ID
  
  Watch /var/log/httpd/error_log or /var/log/dirsrv/slapd-INSTANCE/errors 
  to see the service restart.
 
 What about current instances - can we/do we want to update certmonger
 tracking so that their instances are restarted as well?

You can use the not-exactly-well-named start-tracking command to add a
post-save command:

  ipa-getcert start-tracking \
-d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert \
-C /usr/bin/logger BeenThereDoneThat

Or use the ID, as Rob did above.

HTH,

Nalin

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


Re: [Freeipa-devel] [PATCHES] 0025-26 Test improvements

2012-04-02 Thread Rob Crittenden

Petr Viktorin wrote:

On 03/26/2012 10:44 PM, Rob Crittenden wrote:

Petr Viktorin wrote:

Patch 25 fixes errors I found by running pylint on the testsuite. They
were in code that was unused, either by error or because it only runs on
errors.

Patch 26 adds a test for the batch plugin.


In patch 25 the second test_internal_error should really be
test_unauthorized_error. I think that is a clearer name. Otherwise looks
good.

Patch 26 needs a very minor rebase to fix an error caused by improved
error code handling:

expected = Fuzzy(uinvalid 'gidnumber'.*, type 'unicode', None)
got = uinvalid 'gid': Gettext('must be an integer', domain='ipa',
localedir=None)

I tested this:

diff --git a/tests/test_xmlrpc/test_batch_plugin.py
b/tests/test_xmlrpc/test_bat
ch_plugin.py
index e4280ed..d69bfd9 100644
--- a/tests/test_xmlrpc/test_batch_plugin.py
+++ b/tests/test_xmlrpc/test_batch_plugin.py
@@ -186,7 +186,7 @@ class test_batch(Declarative):
dict(error=u'params' is required),
dict(error=u'givenname' is required),
dict(error=u'description' is required),
- dict(error=Fuzzy(uinvalid 'gidnumber'.*)),
+ dict(error=Fuzzy(uinvalid 'gid'.*)),
),
),
),

rob


Thank you! Fixed, attaching updated patches.



These look ok but it is baffling to me why tuple needs to be added to 
the Output format in batch. Do you know when it is being converted into 
a tuple?


rob

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


[Freeipa-devel] [PATCH] 245 Forbid public access to DNS tree

2012-04-02 Thread Martin Kosek
Test instructions are attached to ticket.
--
With a publicly accessible DNS tree in LDAP, anyone with an access
to the LDAP server can get all DNS data as with a zone transfer
which is already restricted with ACL. Making DNS tree not readable
to public is a common security practice and should be applied
in FreeIPA as well.

This patch adds a new deny rule to forbid access to DNS tree to
users or hosts without an appropriate permission or users which
are not members of admins group. The new permission/aci is
applied both for new installs and upgraded servers.

bind-dyndb-ldap plugin is allowed to read DNS tree without any
change because its principal is already a member of DNS
Servers privilege.

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

From 478c8ff30f2d31d630b4d1494f3897b475b768d6 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Mon, 2 Apr 2012 14:57:33 +0200
Subject: [PATCH] Forbid public access to DNS tree

With a publicly accessible DNS tree in LDAP, anyone with an access
to the LDAP server can get all DNS data as with a zone transfer
which is already restricted with ACL. Making DNS tree not readable
to public is a common security practice and should be applied
in FreeIPA as well.

This patch adds a new deny rule to forbid access to DNS tree to
users or hosts without an appropriate permission or users which
are not members of admins group. The new permission/aci is
applied both for new installs and upgraded servers.

bind-dyndb-ldap plugin is allowed to read DNS tree without any
change because its principal is already a member of DNS
Servers privilege.

https://fedorahosted.org/freeipa/ticket/2569
---
 install/share/dns.ldif   |   12 
 ipaserver/install/plugins/dns.py |   57 -
 2 files changed, 55 insertions(+), 14 deletions(-)

diff --git a/install/share/dns.ldif b/install/share/dns.ldif
index 3fd8cfb87f12c815eafd749b8a310f1f37baa1b4..a8d27788a67def4bfefedd87722894cc10cbad16 100644
--- a/install/share/dns.ldif
+++ b/install/share/dns.ldif
@@ -4,6 +4,7 @@ objectClass: idnsConfigObject
 objectClass: nsContainer
 objectClass: top
 cn: dns
+aci: (targetattr = *)(version 3.0; acl No access to DNS tree without a permission; deny (read,search,compare) (groupdn != ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;) and (groupdn != ldap:///cn=read dns entries,cn=permissions,cn=pbac,$SUFFIX);)
 
 dn: $SUFFIX
 changetype: modify
@@ -56,6 +57,17 @@ description: Update DNS entries
 member: cn=DNS Administrators,cn=privileges,cn=pbac,$SUFFIX
 member: cn=DNS Servers,cn=privileges,cn=pbac,$SUFFIX
 
+dn: cn=read dns entries,cn=permissions,cn=pbac,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: groupofnames
+objectClass: ipapermission
+cn: read dns entries
+description: Read DNS entries
+ipapermissiontype: SYSTEM
+member: cn=DNS Administrators,cn=privileges,cn=pbac,$SUFFIX
+member: cn=DNS Servers,cn=privileges,cn=pbac,$SUFFIX
+
 dn: cn=Write DNS Configuration,cn=permissions,cn=pbac,$SUFFIX
 changetype: add
 objectClass: groupofnames
diff --git a/ipaserver/install/plugins/dns.py b/ipaserver/install/plugins/dns.py
index 84b7b23a5ad185b045901ef3d0f552272af37581..a9846fa84f12fcc9cab75cf6b1ece789c0e873fe 100644
--- a/ipaserver/install/plugins/dns.py
+++ b/ipaserver/install/plugins/dns.py
@@ -87,6 +87,39 @@ class update_dns_permissions(PostUpdate):
 enabled DNS. LDIF loaded by DNS installer would fail because of duplicate
 entries otherwise.
 
+
+_write_dns_perm_dn = DN('cn=Write DNS Configuration',
+api.env.container_permission,
+api.env.basedn)
+_write_dns_perm_entry = ['objectClass:groupofnames',
+ 'objectClass:top',
+ 'cn:Write DNS Configuration',
+ 'description:Write DNS Configuration',
+ 'member:cn=DNS Administrators,cn=privileges,cn=pbac,%s' \
+ % api.env.basedn,
+ 'member:cn=DNS Servers,cn=privileges,cn=pbac,%s' \
+ % api.env.basedn]
+
+_read_dns_perm_dn = DN('cn=read dns entries',
+api.env.container_permission,
+api.env.basedn)
+_read_dns_perm_entry = ['objectClass:top',
+'objectClass:groupofnames',
+'objectClass:ipapermission',
+'cn:read dns entries',
+'description:Read DNS entries',
+'ipapermissiontype:SYSTEM',
+'member:cn=DNS Administrators,cn=privileges,cn=pbac,%s' \
+ % api.env.basedn,
+'member:cn=DNS Servers,cn=privileges,cn=pbac,%s' \
+ % api.env.basedn,]
+
+_write_dns_aci_dn = DN(api.env.basedn)
+

Re: [Freeipa-devel] [PATCH] (master) Support case-insensitive searches for principals during TGS request processing

2012-04-02 Thread Sumit Bose
On Thu, Mar 29, 2012 at 05:02:31PM -0400, Simo Sorce wrote:
 On Thu, 2012-03-29 at 16:30 +0300, Alexander Bokovoy wrote:
  This is due to some krbtgt/realm@REALM searches performed in KDC
  without
  allowing for principal aliases and therefore no chance to our
  case-insensitive searches to kick in. Additional discussion is needed,
  I
  think, if we want to support case-insensitive realms.
  
 I do not think we want to support case-insensitive realm lookups just
 yet. So what you have now seem sufficient to me.

Patch looks good and is passing my testing.

ACK

bye,
Sumit

 
 Simo.
 
 -- 
 Simo Sorce * Red Hat, Inc * New York
 
 ___
 Freeipa-devel mailing list
 Freeipa-devel@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-devel

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


Re: [Freeipa-devel] [PATCH] 245 Forbid public access to DNS tree

2012-04-02 Thread Rob Crittenden

Martin Kosek wrote:

Test instructions are attached to ticket.
--
With a publicly accessible DNS tree in LDAP, anyone with an access
to the LDAP server can get all DNS data as with a zone transfer
which is already restricted with ACL. Making DNS tree not readable
to public is a common security practice and should be applied
in FreeIPA as well.

This patch adds a new deny rule to forbid access to DNS tree to
users or hosts without an appropriate permission or users which
are not members of admins group. The new permission/aci is
applied both for new installs and upgraded servers.

bind-dyndb-ldap plugin is allowed to read DNS tree without any
change because its principal is already a member of DNS
Servers privilege.

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


ACK, pushed to master and ipa-2-2

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


Re: [Freeipa-devel] [PATCH] 993 disable UPG for migration

2012-04-02 Thread Rob Crittenden

Martin Kosek wrote:

On Fri, 2012-03-30 at 09:05 -0400, Rob Crittenden wrote:

Martin Kosek wrote:

On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote:

Martin Kosek wrote:

On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote:

Martin Kosek wrote:

On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote:

We don't want to create private groups automatically for migrated users,
there could be namespace overlap (and race conditions prevent us from
trying to check in advance).

Check the sanity of groups in general, warn if the group for the
gidnumber doesn't exist at least on the remote server.

Fill in the user's shell as well.

This will migrate users that are non-POSIX on the remote server.

rob


This patch fixes the problem of creating UPGs for migrated users, but
there are several parts which confused me.

1) Confusing defaults

+if 'def_group_gid' in ctx:
+entry_attrs.setdefault('gidnumber', ctx['def_group_gid'])

This statement seems redundant, because the account either is posix and
has both uidnumber and gidnumber or it is non-posix and does not have
any.

Now, we don't touch gidNumber for posix user, and non-posix users are
made posix with this statement:

+# migrated user is not already POSIX, make it so
+if 'uidnumber' not in entry_attrs:
+entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999]


2) Missing UPG
When UPG is disabled, the following statement will result in a user with
a GID pointing to non-existent group.

+# migrated user is not already POSIX, make it so
+if 'uidnumber' not in entry_attrs:
+entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999]

We may want to run ldap.has_upg() and report a add this user to failed
users with appropriate error.

3) Check for GID
The patch implements a check if a group with the gidNumber exists on a
remote LDAP server and the result is a warning:

-(g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], 
['gidnumber'])
+(remote_dn, remote_entry) = ds_ldap.find_entry_by_attr(
+'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''],
+ search_bases['group']
+)

I have few (minor-ish) questions there:
a) Is the warning in a apache log enough? Maybe it should be included in
migrate-ds output.
b) This will be a one more remote LDAP call for every user, we may want
to optimize it with something like that:

valid_gids = []
if user.gidnumber not in valid_gids:
   run the check in remote LDAP
   valid_gids.append(user.gidnumber)

That would save us 999 LDAP queries for 1000 migrated with the same
primary group.

4) Extraneous Warning:
When non-posix user is migrated and thus we make it a posix user, we
still produce a warning for non-existent group:

[Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID
number 999 does not point to a known group.

5) Extraneous LDAP call

Isn't the following call to LDAP to get a description redundant? We
already have the description in entry_attrs.

+(dn, desc_attr) = ldap.get_entry(dn, ['description'])
+entry_attrs.update(desc_attr)
+if 'description' in entry_attrs and NO_UPG_MAGIC in
entry_attrs['description']:


Martin



I think this covers your concerns.

I can't do anything but log warnings at this point in order to maintain
backwards compatibility. I looked into returning a warning entry and it
blew up in validate_output() on older clients.

rob



This patch is much better and covers my previous concerns. I just find
an issue with UPG. It is not created for non-posix users when UPGs are
enabled:

# echo Secret123 | ipa migrate-ds ldap://ldap.example.com
--with-compat --base-dn=dc=greyoak,dc=com
---
migrate-ds:
---
Migrated:
 user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg
 group: ipagroup
Failed user:
Failed group:
--
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.

# ipa user-show mnonposix
 User login: mnonposix
 First name: Mister
 Last name: Nonposix
 Home directory: /home/mnonposix
 Login shell: /bin/sh
 UID: 328000195
 GID: 328000195
 Org. Unit: Product Testing
 Job Title: Test User
 Account disabled: False
 Password: True
 Member of groups: ipausers
 Kerberos keys available: False

# ipa group-show mnonposix
ipa: ERROR: mnonposix: group not found


Yes, I was always disabling UPG. I now allow it when migrating a
non-POSIX user.


I am also thinking if we need to ask if UPG is enabled for every
migrated user - every ldap.has_upg() call means one query to host LDAP.
Maybe we should ask just in the beginning and store the setting in
ctx['upg_enabled']. I don't think that anyone needs to switch UPG
status during migration process.


I agree, nice 

Re: [Freeipa-devel] [PATCH] 998 certmonger restarts services on renewal

2012-04-02 Thread Rob Crittenden

Rob Crittenden wrote:

Martin Kosek wrote:

On Tue, 2012-03-27 at 17:40 -0400, Rob Crittenden wrote:

Certmonger will currently automatically renew server certificates but
doesn't restart the services so you can still end up with expired
certificates if you services never restart.

This patch registers are restart command with certmonger so the IPA
services will automatically be restarted to get the updated cert.

Easy to test. Install IPA then resubmit the current server certs and
watch the services restart:

# ipa-getcert list

Find the ID for either your dirsrv or httpd instance

# ipa-getcert resubmit -iID

Watch /var/log/httpd/error_log or /var/log/dirsrv/slapd-INSTANCE/errors
to see the service restart.

rob


What about current instances - can we/do we want to update certmonger
tracking so that their instances are restarted as well?

Anyway, I found few issues SELinux issues with the patch:

1) # rpm -Uvh freeipa-*
Preparing... ### [100%]
1:freeipa-python ### [ 20%]
2:freeipa-client ### [ 40%]
3:freeipa-admintools ### [ 60%]
4:freeipa-server ### [ 80%]
/usr/bin/chcon: failed to change context of
`/usr/lib64/ipa/certmonger' to
`unconfined_u:object_r:certmonger_unconfined_exec_t:s0': Invalid argument
/usr/bin/chcon: failed to change context of
`/usr/lib64/ipa/certmonger/restart_dirsrv' to
`unconfined_u:object_r:certmonger_unconfined_exec_t:s0': Invalid argument
/usr/bin/chcon: failed to change context of
`/usr/lib64/ipa/certmonger/restart_httpd' to
`unconfined_u:object_r:certmonger_unconfined_exec_t:s0': Invalid argument
warning: %post(freeipa-server-2.1.90GIT5b895af-0.fc16.x86_64)
scriptlet failed, exit status 1
5:freeipa-server-selinux ###
[100%]

certmonger_unconfined_exec_t type was unknown with my selinux policy:

selinux-policy-3.10.0-80.fc16.noarch
selinux-policy-targeted-3.10.0-80.fc16.noarch

If we need a higher SELinux version, we should bump the required package
version spec file.


Yeah, waiting on it to be backported.



2) Change of SELinux context with /usr/bin/chcon is temporary until
restorecon or system relabel occurs. I think we should make it
persistent and enforce this type in our SELinux policy and rather call
restorecon instead of chcon


That's a good idea, why didn't I think of that :-(


Ah, now I remember, it will be handled by selinux-policy. I would have 
used restorecon here but since the policy isn't there yet this seemed 
like a good idea.


I'm trying to find out the status of this new policy, it may only make 
it into F-17.


rob

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