[Freeipa-devel] [PATCH] Check if attribute is single-value before trying to add values to it.

2010-10-13 Thread Pavel Zuna
This patch adds a check in ldap2 for single-value attributes. DS doesn't seem to 
care much about attributes being defined as SINGLE-VALUE except for things like 
uidNumber and gidNumber (I suspect this is handled by the DNA plugin).


Ticket #246

Pavel
From 94681f66292904979227bbe2fed058ba9b1a23a4 Mon Sep 17 00:00:00 2001
From: Pavel Zuna pz...@redhat.com
Date: Wed, 13 Oct 2010 12:40:51 -0400
Subject: [PATCH] Check if attribute is single-value before trying to add values to it.

Ticket #246
---
 ipalib/errors.py   |2 +-
 ipaserver/plugins/ldap2.py |   16 +++-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/ipalib/errors.py b/ipalib/errors.py
index 42d43ce..fd96e57 100644
--- a/ipalib/errors.py
+++ b/ipalib/errors.py
@@ -1162,7 +1162,7 @@ class DatabaseError(ExecutionError):
 
 
 errno = 4203
-format = _('%(desc)s:%(info)s')
+format = _('%(desc)s: %(info)s')
 
 
 class LimitsExceeded(ExecutionError):
diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py
index 2213df0..1c5a84f 100644
--- a/ipaserver/plugins/ldap2.py
+++ b/ipaserver/plugins/ldap2.py
@@ -690,13 +690,19 @@ class ldap2(CrudBackend, Encoder):
 adds = list(v.difference(old_v))
 rems = list(old_v.difference(v))
 
+is_single_value = False
+if self.schema:
+obj = self.schema.get_obj(_ldap.schema.AttributeType, k)
+is_single_value = obj and obj.single_value
+
+if is_single_value and len(adds)  1 or len(adds)  len(rems):
+raise errors.DatabaseError(
+info='attribute is single-value', desc=k
+)
+
 force_replace = False
-if k in self._FORCE_REPLACE_ON_UPDATE_ATTRS:
+if k in self._FORCE_REPLACE_ON_UPDATE_ATTRS or is_single_value:
 force_replace = True
-elif self.schema:
-obj = self.schema.get_obj(_ldap.schema.AttributeType, k)
-if obj and obj.single_value:
-force_replace = True
 elif len(adds) == 1 and len(rems) == 1:
 force_replace = True
 
-- 
1.7.1.1

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

[Freeipa-devel] [PATCH] 575 compare resolver and dns reverse lookups

2010-10-13 Thread Rob Crittenden
We check the resolver against the resolver and DNS against DNS but not 
the resolver against DNS so if something is wrong in /etc/hosts we don't 
catch it and nasty connection messages occur.


Also fix a problem where a bogus error message was being displayed 
because we were trying to close an unconnected LDAP connection.


ticket 327

Review this one carefully. It tested out ok on my relatively closed 
system but the implications are that you wouldn't be able to install at 
all or would have to pass --no-host-dns for installation to continue.


I tested by setting my own host entry in /etc/host to a bogus IP addr.

rob


freeipa-575-install.patch
Description: application/mbox
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 570 enforce max username length

2010-10-13 Thread Pavel Zuna

On 10/11/2010 05:19 PM, Rob Crittenden wrote:

Enforce the configurable max username length from cn=ipaconfig.

rob



This will raise an exception if the ipaMaxUsernameLength attribute isn't present 
in the config entry. I know it's not very likely, but it would be better to 
retrieve the attribute first and only do the length check if it is set.


Pavel

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


Re: [Freeipa-devel] [PATCH] 569 detect when DNS is not configured

2010-10-13 Thread Pavel Zuna

On 10/11/2010 04:55 PM, Rob Crittenden wrote:

Detect when DNS is not configured and return an error message when using
the command-line.

It would be nicer if we disabled the command altogether but this would
require checking the server to see every time the ipa command is
executed (which would be bad). We can't store this in a configuration
file because it is possible to add a DNS post-install (and it would
require adding this to every single client install).

ticket 147

rob



ACK.

Pavel

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


Re: [Freeipa-devel] [PATCH] 571 return non-zero on *-find when nothing is found

2010-10-13 Thread Pavel Zuna

On 10/11/2010 06:58 PM, Rob Crittenden wrote:

Return non-zero when the number of entries from *-find returned is zero.

ticket 325

rob



ACK.

Pavel

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


Re: [Freeipa-devel] [PATCH] 570 enforce max username length

2010-10-13 Thread Rob Crittenden

Pavel Zuna wrote:

On 10/11/2010 05:19 PM, Rob Crittenden wrote:

Enforce the configurable max username length from cn=ipaconfig.

rob



This will raise an exception if the ipaMaxUsernameLength attribute isn't
present in the config entry. I know it's not very likely, but it would
be better to retrieve the attribute first and only do the length check
if it is set.

Pavel


Ok, new patch attached. get_ipa_config() always returns a dict (unless 
things really go south in which case missing this attribute is the least 
of our problems).


rob


freeipa-570-2-length.patch
Description: application/mbox
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 570 enforce max username length

2010-10-13 Thread Pavel Zuna

On 10/13/2010 03:46 PM, Rob Crittenden wrote:

Pavel Zuna wrote:

On 10/11/2010 05:19 PM, Rob Crittenden wrote:

Enforce the configurable max username length from cn=ipaconfig.

rob



This will raise an exception if the ipaMaxUsernameLength attribute isn't
present in the config entry. I know it's not very likely, but it would
be better to retrieve the attribute first and only do the length check
if it is set.

Pavel


Ok, new patch attached. get_ipa_config() always returns a dict (unless
things really go south in which case missing this attribute is the least
of our problems).

rob


ACK.

Pavel

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


Re: [Freeipa-devel] DNS use cases

2010-10-13 Thread Simo Sorce
On Tue, 12 Oct 2010 17:44:24 -0400
Adam Young ayo...@redhat.com wrote:

 Really, there are two use cases for creating a zone:
 
 1.  I want the IPA server to manage the zone.  it will be the MNAME 
 field for the DNS record.
 
 2.   I want IPA to act as the caching server for the zone, which is 
 managed by a remote server.
 
 The two use cases are mutually exclusive.  It seems that really, only 
 the first makes sense.  The second case is really a degenerate case
 of act as a caching DNS server for remote server X  where all
 unresolved queries get forwarded to server X, and the results cached
 for future use.

Minor nitpick on zones and caching.

Being a secondary is technically not just caching. When you are a
secondary, you do zone transfers, and then are able to reply to any
request even those not seen before about a specific record in the zone.
Zones never expire, they just keep being used until the master updates
the zone serial record, at which point the zone is refreshed.

It also involves having the right to issue a zone transfer request.
Something normally not permitted to random clients.

Caching instead is done as part of the normal function of DNS servers
and is applied to all records regardless of where they come from.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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


Re: [Freeipa-devel] [PATCH] 569 detect when DNS is not configured

2010-10-13 Thread Rob Crittenden

Pavel Zuna wrote:

On 10/11/2010 04:55 PM, Rob Crittenden wrote:

Detect when DNS is not configured and return an error message when using
the command-line.

It would be nicer if we disabled the command altogether but this would
require checking the server to see every time the ipa command is
executed (which would be bad). We can't store this in a configuration
file because it is possible to add a DNS post-install (and it would
require adding this to every single client install).

ticket 147

rob



ACK.

Pavel


pushed to master

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


Re: [Freeipa-devel] [PATCH] 572 fix usage help of ipa-replica-install

2010-10-13 Thread Rob Crittenden

Pavel Zuna wrote:

On 10/11/2010 07:07 PM, Rob Crittenden wrote:

Include REPLICA_FILE in usage for ipa-replica-install

ticket 247

rob



ACK.

Pavel


pushed to master

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


Re: [Freeipa-devel] [PATCH] 571 return non-zero on *-find when nothing is found

2010-10-13 Thread Rob Crittenden

Pavel Zuna wrote:

On 10/11/2010 06:58 PM, Rob Crittenden wrote:

Return non-zero when the number of entries from *-find returned is zero.

ticket 325

rob



ACK.

Pavel


pushed to master

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


Re: [Freeipa-devel] [PATCH] 570 enforce max username length

2010-10-13 Thread Rob Crittenden

Pavel Zuna wrote:

On 10/13/2010 03:46 PM, Rob Crittenden wrote:

Pavel Zuna wrote:

On 10/11/2010 05:19 PM, Rob Crittenden wrote:

Enforce the configurable max username length from cn=ipaconfig.

rob



This will raise an exception if the ipaMaxUsernameLength attribute isn't
present in the config entry. I know it's not very likely, but it would
be better to retrieve the attribute first and only do the length check
if it is set.

Pavel


Ok, new patch attached. get_ipa_config() always returns a dict (unless
things really go south in which case missing this attribute is the least
of our problems).

rob


ACK.

Pavel


pushed to master

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


Re: [Freeipa-devel] [PATCH 17/17] Add new translations for es (Spanish) and pl (Polish)

2010-10-13 Thread Rob Crittenden

John Dennis wrote:

ipa.pot has 414 messages. There are 17 po translation files.
bn_IN: 24/414 5.8% 390 po untranslated, 0 missing, 390 untranslated
de: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
es: 414/414 100.0% 0 po untranslated, 0 missing, 0 untranslated
fr: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
id: 121/414 29.2% 293 po untranslated, 0 missing, 293 untranslated
he: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
it: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
ja: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
kn: 348/414 84.1% 66 po untranslated, 0 missing, 66 untranslated
ko: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
pl: 414/414 100.0% 0 po untranslated, 0 missing, 0 untranslated
pt: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
pt_BR: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
ru: 135/414 32.6% 279 po untranslated, 0 missing, 279 untranslated
uk: 414/414 100.0% 0 po untranslated, 0 missing, 0 untranslated
zh_CN: 185/414 44.7% 229 po untranslated, 0 missing, 229 untranslated
zh_TW: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated




This doesn't apply to the tip. I'm not sure if it is because of the C 
support that was added or not.


rob

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


Re: [Freeipa-devel] [PATCH 17/17] Add new translations for es (Spanish) and pl (Polish)

2010-10-13 Thread John Dennis

On 10/13/2010 01:05 PM, Rob Crittenden wrote:

John Dennis wrote:

ipa.pot has 414 messages. There are 17 po translation files.
bn_IN: 24/414 5.8% 390 po untranslated, 0 missing, 390 untranslated
de: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
es: 414/414 100.0% 0 po untranslated, 0 missing, 0 untranslated
fr: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
id: 121/414 29.2% 293 po untranslated, 0 missing, 293 untranslated
he: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
it: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
ja: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
kn: 348/414 84.1% 66 po untranslated, 0 missing, 66 untranslated
ko: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
pl: 414/414 100.0% 0 po untranslated, 0 missing, 0 untranslated
pt: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
pt_BR: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated
ru: 135/414 32.6% 279 po untranslated, 0 missing, 279 untranslated
uk: 414/414 100.0% 0 po untranslated, 0 missing, 0 untranslated
zh_CN: 185/414 44.7% 229 po untranslated, 0 missing, 229 untranslated
zh_TW: 0/414 0.0% 414 po untranslated, 0 missing, 414 untranslated




This doesn't apply to the tip. I'm not sure if it is because of the C
support that was added or not.


Simo's 3rd patch has a dependency on this patch. Simo's 3rd patch should 
be reverted. This patch applied, and then Simo should regenerate his 3rd 
patch. By 3rd patch I mean the 3rd patch file in the patch submission 
which was ACK'ed, in other words it's the patch which regenerated the 
pot file and merged all the .po files.


--
John Dennis jden...@redhat.com

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

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


Re: [Freeipa-devel] DNS use cases

2010-10-13 Thread Dmitri Pal
Adam Young wrote:
 Here is what I have so far.  Sorry so long.  I'll work to get this
 down to a more usable size, but would like feedback from any brave
 soul willing to read through this wall of text.

 DNS administration is like the story of the blindmen and the
 elephant.  Many people find that do a significant amount of DNS
 administration only perform a subset of activites that map to their
 companies business use of DNS.  Usage patterns include:

 A Large organization that provides a hostname for each users desktop
 system.

This is the main use IPA case and we should focus on it.


 An online service provider that maps subdomains from their clients to
 small number servers providing cutomized content.

I do not think it is the use case where IPA will be used. A stand alone
DNS is better for such use case.


 A ISP that hosts a large number of domains managed by the ISPs
 clients, each on a virtual server that runs on a smaller number of
 physical servers

IMO same as above.


 The clients of that ISP that need to create subdomains for specific
 uses (CMS, web services etc).

 Software development shops that create subdomains for a small subset
 of users who need to routinely create and destroy large numbers of
 host entries.

How this is different from use case 1 with desktops?

What about cloud and VMs? I suspect that is also similar to use case 1
and this one.
So I would generalize it as IPA DNS as a primary name server for manged
and not managed VM/BM hosts (servers/desktops)

 Typically, the usage falls into a small number of use cases:

 1.  View and edit all of the records associated with a single host
 2.  Create or edit a Zone based on a template or simple business rules


Ack.

 Of the record types we handle, it makes sense to look at their
 expected cardinality:

 A:  Typically, an A Record is canonical, not just for a public name,
 but for man y CNAME recordfs pointing to that host.  It hast the split
 identity of being the name that everyone uses to refer to some
 resources, but also acts as an insulation layer between a large number
 of CNAME record alias and a IPAddress that may change over time.

 CNAME:  Often these will refer to A records not even in the same
 domain.  While the recommended usage states that a CNAMe should onluy
 point to an A Record, in practice people can point one CNAME to
 another CNAME record.  This usage is common when the first CNAME is
 managed by one organization, and the second is managed by the ISP for
 the first.

 SRV Records are rare, but require much more information than a A,
 , CNAME, PTR etx record.  Like a CNAME or PTR, part of the SRC
 record is a pointer to another host, and again, this should be a
 Canonical target (A Record).

 It probably makes sense for us to force  A records to be HOST entries,
 and to use those to populate the values for CNAME, SRC, PTR, SRV, etc
 records.

 Certain large organizations are going to take a Zone based apporoach
 to DNS.  FOr an ISP, each customer is likely to have a Domain name and
 will need certain basica records.  At a minimum, they need an A or
 CNAME record for the main host that they manage, even if this host is
 shared buy other users.  Management of those Zones may be delegated to
 the customers.  They are also likely to want MX record for their
 domain.  This is likely to point to a centralized mail server for all
 customers, where the mail will be sorted based on spam filtering
 before delivery.  Again, it should point to an A record.  The RFC is
 pretty clear on this point, so it is unclear whether people actually
 have MX records which refer to CNAME records.

IMO not a use case to worry about at least now.


 PTR records typically are used for Reverse DNS lookups.  As such, DNS
 should return only one record for a given hostname, although different
 hostnames may all map to the same IP address.  It may not make sense
 to force this onto an IPA Host object, as it is likely  that the end
 user will want to move the IP address from one host to another, and
 have all of the PTR records remain valid.   However, without forcing
 it onto a host object, we have no way to say show me all of the
 hostnames that map to this IP address.


 Of the many forms of Key and certificate records, none of them seem to
 point to other hosts, but are instead associated with a zone.  For
 example, DNSSEC uses the Key record.  It is requested based on a
 Hostname, and returns a key.  The IPSEC record is an exception, but we
 do not currently support that record type.


 It is unlikely that we will need explicit records for NSEC* records,
 as they basically say The host you requested does not exist.  Since
 DNS provides a Canonical answer about existence, denying the existence
 of a host that does exist tends to break things.  Instead, I suspect
 that these records are autogenerated based on the set of hostnames
 that we *do* provide answers for.

 SIG records do not refer to hosts.  RRSIG records, which we support

[Freeipa-devel] Playing with UI

2010-10-13 Thread Dmitri Pal
Hi,

I took the liberty of playing with UI a bit and trying different things.
Below is some comments on what I observed. Some are cosmetic but they
annoy me a bit so I will list them anyways. They probably belong to one
(may be already existing) ticket


Self service case - logged as a newly created user:

a) I do no like the fonts on the tiles. The words Identity etc are
hard to see. They should be bigger font and bold.
b) The green tiles are ok in general but the gray line on them looks weird
c) Facets on the user details (and other pages) should be spread out.
Currently the are too close to each other
d) The mouse pointer does not turn into a hand or something usually
associated with clickability when I point to the identity tile, User
tile or on the undo marker or collapse section - sign on the details page
e) Tooltips on user details page show LDAP fields. Is this intended?
f) Password reset does not work on the user page
g) Account status toggle is confusing. It says inactive  for a newly
created user. Toggle should be a link or button.
h) Multiple phones and emails are still not implemented
i) GID/UID are not protected fields on the details page
j) Search should be definitely removed from the facets (at least for the
self service use case)

Admin use case
a) Identity-Users page
* Columns are very strangely aligned. The checkbox column is too wide
* User login though a link by the behavior it does not look like a link

c) In the User groups facet
* User groups is ok as a title of the facet but not ok as the title of
the list of the groups user is enrolled in. Suggest we change it to
Groups that the user is a member of or something like this. We have a
lot of space in the title to be less confusing
* The group names should be links in this list
* There is no way to remove user from a group
* There is no check box column on the a check box in the title. I think
the whole list is broken.
* Should there be quick links?

d) Enrolling into a group
The filter finds even the group that the user is already a member of and
dialog allows to add them to the results list.
No warning is shown later indicating that user is already in the group.

e) Facens for a host are confusing. It has users there.

f) For services the Hosts facet should not be there I think. There
should a link on the details page to jump to the host details page.

g) Back to top link at the bottom of the page brings you to the list
of users. This seems to be wrong.

h) Clicking on the Global password policy produces an error


Generally a lot of progress and a good foundation...
... but there is a lot of cleanup in front of us. I suggest as soon as
we agree on the design of the HBAC and DNS we start polishing the UI
section by section area by area.
 


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

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


[Freeipa-devel] [PATCH] #318 Use openldap's ldappasswd

2010-10-13 Thread Simo Sorce

The following patch makes the ldappasswd operation use the openldap's
ldappasswd command, as well as avoiding to put passwords in the command
line (visible through a ps) and instead using secure temporary files
that are deleted immediately after the operation.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 8cf4d7b2c8e497001f0bb16c448f955850816480 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Wed, 13 Oct 2010 12:21:48 -0400
Subject: [PATCH] dsinstance: avoid exposing passwords when invoking ldappaswd

Pass passwords to ldappasswd by using files.
Replace use of mozldap's ldappaswd with openldap's one.
---
 ipaserver/install/dsinstance.py |   42 ++
 1 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 0c79032..49762ed 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -27,6 +27,7 @@ import sys
 import os
 import re
 import time
+import tempfile
 
 from ipapython import ipautil
 
@@ -43,6 +44,7 @@ from ipaserver.plugins.ldap2 import ldap2
 
 SERVER_ROOT_64 = /usr/lib64/dirsrv
 SERVER_ROOT_32 = /usr/lib/dirsrv
+CACERT=/usr/share/ipa/html/ca.crt
 
 def find_server_root():
 if ipautil.dir_exists(SERVER_ROOT_64):
@@ -465,20 +467,34 @@ class DsInstance(service.Service):
 def change_admin_password(self, password):
 logging.debug(Changing admin password)
 dirname = config_dirname(self.serverid)
-if ipautil.dir_exists(/usr/lib64/mozldap):
-app = /usr/lib64/mozldap/ldappasswd
-else:
-app = /usr/lib/mozldap/ldappasswd
-args = [app,
--D, cn=Directory Manager, -w, self.dm_password,
--P, dirname+/cert8.db, -ZZZ, -s, password,
-uid=admin,cn=users,cn=accounts,+self.suffix]
+dmpwdfile = 
+admpwdfile = 
+
 try:
-ipautil.run(args)
-logging.debug(ldappasswd done)
-except ipautil.CalledProcessError, e:
-print Unable to set admin password, e
-logging.debug(Unable to set admin password %s % e)
+(dmpwdfd, dmpwdfile) = tempfile.mkstemp(dir='/var/lib/ipa')
+os.write(dmpwdfd, self.dm_password)
+os.close(dmpwdfd)
+
+(admpwdfd, admpwdfile) = tempfile.mkstemp(dir='/var/lib/ipa')
+os.write(admpwdfd, password)
+os.close(admpwdfd)
+
+args = [/usr/bin/ldappasswd,
+-ZZ, -x, -D, cn=Directory Manager,
+-y, dmpwdfile, -T, admpwdfile,
+uid=admin,cn=users,cn=accounts,+self.suffix]
+try:
+ipautil.run(args, env = { 'LDAPTLS_CACERT':CACERT })
+logging.debug(ldappasswd done)
+except ipautil.CalledProcessError, e:
+print Unable to set admin password, e
+logging.debug(Unable to set admin password %s % e)
+
+finally:
+if os.path.isfile(dmpwdfile):
+os.remove(dmpwdfile)
+if os.path.isfile(admpwdfile):
+os.remove(admpwdfile)
 
 def uninstall(self):
 if self.is_configured():
-- 
1.7.2.3

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

Re: [Freeipa-devel] [PATCH] Check if attribute is single-value before trying to add values to it.

2010-10-13 Thread Rob Crittenden

Pavel Zuna wrote:

This patch adds a check in ldap2 for single-value attributes. DS doesn't
seem to care much about attributes being defined as SINGLE-VALUE except
for things like uidNumber and gidNumber (I suspect this is handled by
the DNA plugin).

Ticket #246

Pavel


This is similar to ticket 220 which I have a pending patch for (patch 
552). I think both patches are valid but we should test them together to 
be sure. Can you do that?


rob

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


[Freeipa-devel] [PATCH] #316 Avoid installing files in /usr

2010-10-13 Thread Simo Sorce
The default setup-ds.pl configuration installs ds scripts in /usr

With this patch the customized scripts are kep
in /var/lib/dirsrv/scripts-instance-name instead of
/usr/lib/dirsrv/slapd-instance-name

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From d450b7da7a0f5ec7c967f3ad332235ffb1fdb631 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Wed, 13 Oct 2010 19:01:28 -0400
Subject: [PATCH] Avoid writing customized perl scripts in /usr

Keep instance specific data in /var/lib/dirsrv
---
 ipaserver/install/dsinstance.py |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 49762ed..ca04457 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -149,6 +149,7 @@ Suffix=   $SUFFIX
 RootDN=   cn=Directory Manager
 RootDNPwd= $PASSWORD
 InstallLdifFile= /var/lib/dirsrv/boot.ldif
+inst_dir=   /var/lib/dirsrv/scripts-$SERVERID
 
 
 BASE_TEMPLATE = 
-- 
1.7.2.3

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