Re: [Freeipa-devel] [PATCH 0038] Fix two memory leaks in ldap_query()

2012-07-23 Thread Adam Tkac 
On Fri, Jul 20, 2012 at 02:28:09PM +0200, Petr Spacek wrote:
 Hello,
 
 this patch fixes two memory leaks in ldap_query(). Both memory leaks
 occurs after non-success queries.
 
 It effectively re-implements fix for ldap_query can incorrectly
 return ISC_R_SUCCESS even when failed:
 http://git.fedorahosted.org/git/?p=bind-dyndb-ldap.git;a=commitdiff;h=a7cd8ae747b3a81a02ab9e5dbefe1c595aa24ff6
 
 Please double-check this approach.

Ack, please push it to master.

A

 From c8718b98641e7537b2350a625b03b0b7fec6f206 Mon Sep 17 00:00:00 2001
 From: Petr Spacek pspa...@redhat.com
 Date: Fri, 20 Jul 2012 14:18:41 +0200
 Subject: [PATCH] Fix two memory leaks in ldap_query().
 
 Signed-off-by: Petr Spacek pspa...@redhat.com
 ---
  src/ldap_helper.c |   14 --
  1 files changed, 8 insertions(+), 6 deletions(-)
 
 diff --git a/src/ldap_helper.c b/src/ldap_helper.c
 index 
 6ac76faecbc250deb28203256fa13d83ae6c80f4..daffac7c7825a99a07c333217638d3beaddfaad2
  100644
 --- a/src/ldap_helper.c
 +++ b/src/ldap_helper.c
 @@ -1753,28 +1753,30 @@ retry:
  ldap_qresult-ldap_entries);
   if (result != ISC_R_SUCCESS) {
   log_error(failed to save LDAP query results);
 - return result;
 + goto cleanup;
   }
  
   *ldap_qresultp = ldap_qresult;
   return ISC_R_SUCCESS;
 + } else {
 + result = ISC_R_FAILURE;
   }
  
   ret = ldap_get_option(ldap_conn-handle, LDAP_OPT_RESULT_CODE,
 (void *)ldap_err_code);
 - if (ret == LDAP_OPT_SUCCESS  ldap_err_code == LDAP_NO_SUCH_OBJECT)
 - return ISC_R_NOTFOUND;
 - /* some error happened during ldap_search, try to recover */
 - else if (!once) {
 + if (ret == LDAP_OPT_SUCCESS  ldap_err_code == LDAP_NO_SUCH_OBJECT) {
 + result = ISC_R_NOTFOUND;
 + } else if (!once) {
 + /* some error happened during ldap_search, try to recover */
   once++;
   result = handle_connection_error(ldap_inst, ldap_conn,
ISC_FALSE);
   if (result == ISC_R_SUCCESS)
   goto retry;
   }
  cleanup:
   ldap_query_free(ISC_FALSE, ldap_qresult);
 - return ISC_R_FAILURE;
 + return result;
  }
  
  /**
 -- 
 1.7.7.6
 


-- 
Adam Tkac, Red Hat, Inc.

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

Re: [Freeipa-devel] [PATCH] 0066 Arrange stripping .po files

2012-07-23 Thread Petr Viktorin 

On 07/20/2012 07:14 PM, John Dennis wrote:

On 07/20/2012 12:28 PM, Petr Viktorin wrote:

On 07/20/2012 05:39 PM, John Dennis wrote:

Great I agree with everything you said.

I'm happy to have the file list be derived from the directory contents.
Are you planning on doing that in another patch?


Yes, I want to do it in a new patch.
It's a bit more complicated than it looks: creating a new translation
will work differently than just adding it to LINGUAS and running
create-po. The ticket is for beta 2 so I'd rather not start a new round
of reviews.


Fine with me to do that in another patch.

As for create-po, I think that's also holdover from pre-Transifex days.
With Transifex I'd don't ever see a need to create an empty po file. Do
you? Maybe we should just nuke the po creation in the Makefile.


As a translator (for another project), I don't like Transifex and prefer 
to send good old Git pull requests. I understand a traditional 
workflow is hard to coordinate with others that use Transifex, but still 
I'd hate it if we became dependent on Tx.


[...]

But... I do have one final issue/question. I missed this in the first
review. po_files is now dependent on update-pot instead of the pot file.
We had decided that we were only going to regenerate the pot file on
demand at specific times. Won't this dependency change cause the pot
file to be updated frequently? (I realize only in the local tree). Note
that when we run the validations we generate a temporary pot file from
the current contents of the tree specifically to avoid overwriting the
pot file.


Are the po files updated more often? I don't really see a reason to
merge the po files with an old pot.


What merge are you referring to? The only merge I'm aware of at the
moment is during validation, but that merge is done from a temporary
updated pot file that is current with the tree.


I'm referring to a manual merge-po.
po_files are only rebuilt from merge-po, which merges the po files with 
the pot and adds all the missing translations and line numbers. This is 
not needed with Transifex workflow, as Tx should do this internally when 
a pot is pushed to it.



Any other merging is done by Transifex at the time we pull a po file.

The frequency of po update doesn't seem relevant, what is your concern
in this regard?


Is there another cause for the po_files to get rebuilt?


I suppose having a conversation about when the pot file gets updated is
a good one to have, we don't do it often enough IMHO. But I'm not sure
it's correct to modify a file under SCM control if it wasn't
intentional.


How is Transifex set up here? If it automatically picks up changes when
the pot file is modified, then we should back up the translations before
changing the pot, so we can't do it automatically.
Another wart is the line number cruft in the pot file -- any time it's
updated we'll get a huge diff, so it makes sense to update sparingly.


Transifex gives you two options for your pot file, either you tell TX
the location of your pot file in a public SCM and it watches for updates
and automatically pulls it when it changes in SCM -or- you manually push
the pot file to TX.

We've been using the watch the pot file in git option. Thus whenever
we commit a new version of the pot file all developers and TX get it
simultaneously (well sort of).

If we do the manual push method the maintainer has to *both* commit to
git *and* push to TX, so the former seems less error prone and more
automated.


Well, if the pot file is not in the repo, the maintainer only has to 
push it to Tx (after building it of course, but that needs to be done 
anyway).



The idea was we would have a string freeze prior to release and/or
periodic intervals during branch development to update the pot. But we
haven't been good about hitting these. However, note a manual push
suffers from the same somebody has to do it at the right moment problem.


Is this idea documented anywhere? It's hard to do a string freeze if 
it's not enforced automatically, let alone if people don't know there 
should be one.



If Transifex is not wired to the pot, we could even go as far as
removing it from SCM entirely -- it's entirely generated, and rebuilding
it takes less than a second.
We'd just have to update Transifex manually.


It currently is wired to the pot. You make a valid point about currently
not needing to maintain the pot in SCM. When we first set up
translations we weren't using TX so having the pot file in SCM was a
necessity.

Personally I don't trust TX's data storage and I think there is value in
having each pot we push to TX be recoverable from our SCM. When things
blow up (and they do) it's really nice to be able to reassemble the
pieces or at lease follow the trail of how things changed. In the past
I've had to answer questions like How the heck did this string get into
this po file? Such questions can only be answered if we have the pot
file we gave the translator. TX doesn't maintain it so we have

Re: [Freeipa-devel] [PATCH 0038] Fix two memory leaks in ldap_query()

2012-07-23 Thread Petr Spacek 

On 07/23/2012 12:03 PM, Adam Tkac wrote:

On Fri, Jul 20, 2012 at 02:28:09PM +0200, Petr Spacek wrote:

Hello,

this patch fixes two memory leaks in ldap_query(). Both memory leaks
occurs after non-success queries.

It effectively re-implements fix for ldap_query can incorrectly
return ISC_R_SUCCESS even when failed:
http://git.fedorahosted.org/git/?p=bind-dyndb-ldap.git;a=commitdiff;h=a7cd8ae747b3a81a02ab9e5dbefe1c595aa24ff6

Please double-check this approach.


Ack, please push it to master.

A


Pushed to master: 
http://git.fedorahosted.org/git?p=bind-dyndb-ldap.git;a=commitdiff;h=77c06ea1910a9737bf7e2d9f5c53eeb83827c332


Petr^2 Spacek

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

[Freeipa-devel] [PATCH] 174 Fix autoscroll to top in tables in IE

2012-07-23 Thread Petr Vobornik 
In IE when a window is small (horizontal scrollbar is displayed) click 
or keyboard input on various parts of UI makes search tables scroll to 
top. It prevents from selecting items in a table. This issue happens 
when using absolute positioned element with overflow style. It's a bug 
in IE.


Two workarounds were added to make UI usable in IE.
Adding position:relative; style to body element fixes the problem in 
search pages. It doesn't help in association dialogs though.
The bug doesn't occur when some child element has focus. It's possible 
to set focus to first visible checkbox while scrolling down but user 
experience is very bad. Better solution seems to scroll back when IE 
scrolls to top on mousedown. That way mouse click event happens on the 
target element and it can gain focus and therefore be selected. Some 
glitches still remains but is usable.


https://fedorahosted.org/freeipa/ticket/2835
--
Petr Vobornik

From 8791f87f6fa5a8747b64ce3c34528f7815086124 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 23 Jul 2012 10:32:26 +0200
Subject: [PATCH] Fix autoscroll to top in tables in IE

In IE when a window is small (horizontal scrollbar is displayed) click or keyboard input on various parts of UI makes search tables scroll to top. It prevents from selecting items in a table. This issue happens when using absolute positioned element with overflow style. It's a bug in IE.

Two workarounds were added to make UI usable in IE.
Adding position:relative; style to body element fixes the problem in search pages. It doesn't help in association dialogs though.
The bug doesn't occur when some child element has focus. It's possible to set focus to first visible checkbox while scrolling down but user experience is very bad. Better solution seems to scroll back when IE scrolls to top on mousedown. That way mouse click event happens on the target element and it can gain focus and therefore be selected. Some glitches still remains but is usable.

https://fedorahosted.org/freeipa/ticket/2835
---
 install/ui/ipa.css   |1 +
 install/ui/widget.js |   12 
 2 files changed, 13 insertions(+)

diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index 76ce265f0f5c90404046726fe55bd54d73c9b365..4f9d35c1d2a5e458903793423c6fad4de657554e 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -39,6 +39,7 @@ html {
 
 body {
 overflow: auto;
+position: relative;
 background: url(images/outer-background.png);
 background-repeat: repeat-x;
 background-position: left top;
diff --git a/install/ui/widget.js b/install/ui/widget.js
index 6864d88f5f08a4064b9b5b1cded527d5e99504ff..3002ede556385c16e86952d0c933a334ffdae175 100644
--- a/install/ui/widget.js
+++ b/install/ui/widget.js
@@ -1371,6 +1371,18 @@ IPA.table_widget = function (spec) {
 
 that.tbody = $('tbody/').appendTo(that.table);
 
+// workaround for #2835
+if ($.browser.msie) {
+that.tbody.mousedown(function(event) {
+that.scroll_top = that.tbody.scrollTop();
+window.setTimeout(function() {
+if (that.tbody.scrollTop() === 0) {
+that.tbody.scrollTop(that.scroll_top);
+}
+}, 0);
+});
+}
+
 if (that.height) {
 that.tbody.css('height', that.height);
 }
-- 
1.7.10.4

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

[Freeipa-devel] slow response (was: 2.20 dirsrv memory usage)

2012-07-23 Thread John Dennis 
Stephen provided Alexander and myself with debug output. I quickly wrote 
a little script to parse the output looking for the session timestamps, 
what commands were executed for each RPC, and computed the duration of 
the RPC. Note the timestamps only have 1 second resolution, something 
which would be easy to fix, so bear that in mind when looking at the 
output of the script.


The script first lists every command executed in the RPC (including 
internal commands), which is then followed by the duration for the RPC.


From the error_log it appears as if the session cache is being used for 
all RPC commands.



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

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


commands:
batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[], 
{u'all': True, u'whoami': True}], u'method': u'user_find'}, {u'params': [[], 
{}], u'method': u'env'}, {u'params': [[], {}], u'method': u'dns_is_enabled'}))
i18n_messages()
user_find(None, whoami=True, all=True)
env(None)
dns_is_enabled()
command duration: 0:00:02

commands:
json_metadata(None, None, command=u'all')
json_metadata(None, None, object=u'all')
command duration: 0:00:03

commands:
user_find(None, sizelimit=0, pkey_only=True)
command duration: 0:00:01

commands:
batch(({u'params': [[u'admin'], {u'all': True}], u'method': u'user_show'}, 
{u'params': [[u'alyce'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'apickens'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'carolyn'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'carolynvm'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'cwoodring'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'cyrus'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'dawnselleck'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'doug'], {u'all': True}], u'method': u'user_show'}, {u'params': [[u'erika'], 
{u'all': True}], u'method': u'user_show'}, {u'params': [[u'jbn'], {u'all': 
True}], u'method': u'user_show'}, {u'params': [[u'jessica'], {u'all': True}], 
u'method': u'user_show'}, {u'params': [[u'jimmy'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'john'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'jschiefer'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'jshirkani'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'kaline'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'kaline2'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'kbiorac'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'ken'], {u'all': True}], u'method': 
u'user_show'}))
user_show(u'admin', all=True)
user_show(u'alyce', all=True)
user_show(u'apickens', all=True)
user_show(u'carolyn', all=True)
user_show(u'carolynvm', all=True)
user_show(u'cwoodring', all=True)
user_show(u'cyrus', all=True)
user_show(u'dawnselleck', all=True)
user_show(u'doug', all=True)
user_show(u'erika', all=True)
user_show(u'jbn', all=True)
user_show(u'jessica', all=True)
user_show(u'jimmy', all=True)
user_show(u'john', all=True)
user_show(u'jschiefer', all=True)
user_show(u'jshirkani', all=True)
user_show(u'kaline', all=True)
user_show(u'kaline2', all=True)
user_show(u'kbiorac', all=True)
user_show(u'ken', all=True)
command duration: 0:00:01

commands:
user_find(None, sizelimit=0, pkey_only=True)
command duration: 0:00:01

commands:
batch(({u'params': [[u'kenbrisbin'], {u'all': True}], u'method': u'user_show'}, 
{u'params': [[u'lbrown'], {u'all': True}], u'method': u'user_show'}, 
{u'params': [[u'lew'], {u'all': True}], u'method': u'user_show'}, {u'params': 
[[u'lisa'], {u'all': True}], u'method': u'user_show'}, {u'params': [[u'liz'], 
{u'all': True}], u'method': u'user_show'}, {u'params': [[u'manerriza'], 
{u'all': True}], u'method': u'user_show'}, {u'params': [[u'mastering'], 
{u'all': True}], u'method': u'user_show'}, {u'params': [[u'mustangsally27'], 
{u'all': True}], u'method': u'user_show'}, {u'params': [[u'nancy'], {u'all': 
True}], u'method': u'user_show'}, {u'params': [[u'ngimblin'], {u'all': True}], 
u'method': u'user_show'}, {u'params': [[u'om'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'orderskb'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'pmccuin'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'reinmiller'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'reinmiller2'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'renee'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'robertson'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'robertson2'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'royer'], {u'all': True}], u'method': 
u'user_show'}, {u'params': [[u'ruben'], {u'all': True}], u'method': 
u'user_show'}))
user_show(u'kenbrisbin', all=True)
user_show(u'lbrown', all=True)
user_show(u'lew', all=True)
user_show(u'lisa', all=True)

Re: [Freeipa-devel] slow response

2012-07-23 Thread John Dennis 
Darn it. I just realized I did something really dumb. I posted material 
to a public list that should have been kept private. I'm even the one 
who asked Stephen to keep the information private.


I offer Stephen my sincerest apology for being a complete idiot and I 
hope I didn't create any problems for you.


John (with his tail between his legs)

--
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] slow response

2012-07-23 Thread John Dennis 

On 07/23/2012 01:23 PM, Stephen Ingram wrote:

On Mon, Jul 23, 2012 at 9:37 AM, John Dennis jden...@redhat.com wrote:

Stephen provided Alexander and myself with debug output. I quickly wrote a
little script to parse the output looking for the session timestamps, what
commands were executed for each RPC, and computed the duration of the RPC.
Note the timestamps only have 1 second resolution, something which would be
easy to fix, so bear that in mind when looking at the output of the script.

The script first lists every command executed in the RPC (including internal
commands), which is then followed by the duration for the RPC.

 From the error_log it appears as if the session cache is being used for all
RPC commands.


I see the times all appear to be smaller than what is experienced in
the Web UI itself. So what is happening the rest of the 3-4 seconds?
Is that taken up by the ticket request?


No, based on what I see in the error_log file the ticket request is not 
a factor. The error_log shows you acquired a ticket exactly once on the 
first command and from that point forward your credentials were served 
from the session cache (as we would hope/expect).


Caveat, I did not examine the network traffic log, just the error_log.

I don't know where the lost time seems to be or if the execution times 
seen by the analysis are expected (we should also increase the 
resolution of the timestamp). I was hoping other developers might chime 
in with their own thoughts.


--
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] slow response

2012-07-23 Thread John Dennis 

On 07/23/2012 12:37 PM, John Dennis wrote:

Note the timestamps only have 1 second resolution, something
which would be easy to fix, so bear that in mind when looking at the
output of the script.


This is partially as a note to myself, but also to others who want to 
test. The following patch should produce timestamps in the debug output 
with microsecond resolution.




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

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


diff --git a/ipalib/session.py b/ipalib/session.py
index 4b783bb..1cff222 100644
--- a/ipalib/session.py
+++ b/ipalib/session.py
@@ -628,9 +628,9 @@ mod_auth_kerb. Everything else remains the same.
 
 default_max_session_duration = 60*60 # number of seconds
 
-ISO8601_DATETIME_FMT = '%Y-%m-%dT%H:%M:%S' # FIXME jrd, this should be defined elsewhere
+ISO8601_DATETIME_FMT = '%Y-%m-%dT%H:%M:%S.%f' # FIXME jrd, this should be defined elsewhere
 def fmt_time(timestamp):
-return time.strftime(ISO8601_DATETIME_FMT, time.localtime(timestamp))
+return datetime.fromtimestamp(timestamp).strftime(ISO8601_DATETIME_FMT)
 
 #---
 
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-23 Thread Rob Crittenden 

Rob Crittenden wrote:

Andrew Wnuk wrote:

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem
seemed fine (it complained wildly when I had the wrong trust in the
NSS db).

Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.


Ok, added a bit to update CS.cfg with the new certificate.


This should fix some SELinux issues preventing certmonger from 
monitoring the dogtag certificate database in /var/lib/pki-ca/alias.


rob
From e2e7ed28946cabd47dfdb74b071125a3ec123446 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 11 Jul 2012 15:51:01 -0400
Subject: [PATCH] Use certmonger to renew CA subsystem certificates

Certificate renewal can be done only one one CA as the certificates need
to be shared amongst them. certmonger has been trained to communicate
directly with dogtag to perform the renewals. The initial CA installation
is the defacto certificate renewal master.

A copy of the certificate is stored in the IPA LDAP tree in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX, the rdn being the nickname of the
certificate, when a certificate is renewed. Only the most current
certificate is stored. It is valid to have no certificates there, it means
that no renewals have taken place.

The clones are configured with a new certmonger CA type that polls this
location in the IPA tree looking for an updated certificate. If one is
not found then certmonger is put into the CA_WORKING state and will poll
every 8 hours until an updated certificate is available.

The RA agent certificate, ipaCert in /etc/httpd/alias, is a special case.
When this certificate is updated we also need to update its entry in
the dogtag tree, adding the updated certificate and telling dogtag which
certificate to use. This is the certificate that lets IPA issue
certificates.

On upgrades we check to see if the certificate tracking is already in
place. If not then we need to determine if this is the master that will
do the renewals or not. This decision is made based on whether it was
the first master installed. It is concievable that this master is no
longer available meaning that none are actually tracking renewal. We
will need to document this.

https://fedorahosted.org/freeipa/ticket/2803
---
 freeipa.spec.in|7 +-
 install/Makefile.am|1 +
 install/certmonger/Makefile.am |   14 +++
 .../certmonger/dogtag-ipa-retrieve-agent-submit|   79 +
 install/conf/Makefile.am   |3 +-
 install/conf/ca_renewal|6 +
 install/configure.ac   |1 +
 install/restart_scripts/Makefile.am|3 +
 install/restart_scripts/renew_ca_cert  |   81 +
 install/restart_scripts/renew_ra_cert  |   82 +
 install/restart_scripts/restart_dirsrv |   24 
 install/restart_scripts/restart_httpd  |   20 
 install/restart_scripts/restart_pkicad |   44 +++
 install/share/bootstrap-template.ldif  |6 +
 install/share/default-aci.ldif |   11 ++
 install/tools/ipa-upgradeconfig|   29 +
 install/updates/21-ca_renewal_container.update |9 ++
 install/updates/40-delegation.update   |4 +
 install/updates/Makefile.am|1 +
 ipalib/x509.py |8 ++
 ipapython/certmonger.py|   68 +++
 ipapython/ipautil.py   |   23 
 ipapython/platform/base.py |2 +-
 ipapython/platform/fedora16.py |1 +
 ipaserver/install/cainstance.py|  125 +++-
 selinux/ipa_dogtag/ipa_dogtag.te   |   10 +-
 26 files changed, 656 insertions(+), 6 deletions(-)
 create mode 100644 install/certmonger/Makefile.am
 create mode 100644 install/certmonger/dogtag-ipa-retrieve-agent-submit
 create mode 100644 install/conf/ca_renewal
 create mode 100644 install/restart_scripts/renew_ca_cert
 create mode 100644 install/restart_scripts/renew_ra_cert
 create mode 100644 install/restart_scripts/restart_pkicad
 create mode 100644 install/updates/21-ca_renewal_container.update

diff --git a/freeipa.spec.in b/freeipa.spec.in
index f4903c01354764f0c6b8755824512edbc1ff930b..ce6c21aa3d9a6d92f6125e36905df5d3cf7b1a74 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -247,7 +247,7 @@

Re: [Freeipa-devel] [PATCH] 0056 Framework for admin/install tools, with ipa-ldap-updater

2012-07-23 Thread Rob Crittenden 

John Dennis wrote:

On 07/20/2012 12:34 PM, Petr Viktorin wrote:

On 07/20/2012 05:59 PM, John Dennis wrote:

A fair amount of the code in the framework is doing this now, but the
install code was never cleaned up. That was left for another day, I
guess that day is here.


Updated. I also added the necessary lint exception.
I'm curious as to why it works that way, though. Normally, to put
methods in a class, you would use a base class/mixin. Why this dynamic
magic?


Good question. I don't like dynamic magic either, it makes static code
reading difficult and diminishes the value of static code
analysis/checking. Jason who originally wrote the framework used dynamic
magic a fair amount, including the initialization of the logging methods
in the plugins. When I wrote the log manager I kept Jason's existing
strategy (how many things do change at once?). In hindsight a mixin
would have been a better solution, something we should probably fix down
the road.


Thinking more about this, composition would probably be cleaner than
inheritance here (i.e. using self.logger.warn(...) instead of mixing the
functionality into the class itself).
Well, one day the time to fix it will come.


Everything looks good, although there might be one minor thing that
needs fixing. Shouldn't the logging setup be done first? That way any
code that executes has the ability to emit a message. For example what
if validate_options() wants to emit a message?



That's a good question.
If we set up logging before validating the options, we'll log all
invocations, including those with misspelled option names and forgotten
sudos. Do we want that?



Sure, hard to say. Why don't we leave it the way it is now and down the
road if it shows up as an issue we'll tweak it then.

ACK.



pushed to master

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

Re: [Freeipa-devel] [PATCH] 0066 Arrange stripping .po files

2012-07-23 Thread John Dennis 

On 07/23/2012 06:27 AM, Petr Viktorin wrote:

On 07/20/2012 07:14 PM, John Dennis wrote:

On 07/20/2012 12:28 PM, Petr Viktorin wrote:

On 07/20/2012 05:39 PM, John Dennis wrote:

Great I agree with everything you said.

I'm happy to have the file list be derived from the directory contents.
Are you planning on doing that in another patch?


Yes, I want to do it in a new patch.
It's a bit more complicated than it looks: creating a new translation
will work differently than just adding it to LINGUAS and running
create-po. The ticket is for beta 2 so I'd rather not start a new round
of reviews.


Fine with me to do that in another patch.

As for create-po, I think that's also holdover from pre-Transifex days.
With Transifex I'd don't ever see a need to create an empty po file. Do
you? Maybe we should just nuke the po creation in the Makefile.


As a translator (for another project), I don't like Transifex and prefer
to send good old Git pull requests. I understand a traditional
workflow is hard to coordinate with others that use Transifex, but still
I'd hate it if we became dependent on Tx.

[...]

But... I do have one final issue/question. I missed this in the first
review. po_files is now dependent on update-pot instead of the pot file.
We had decided that we were only going to regenerate the pot file on
demand at specific times. Won't this dependency change cause the pot
file to be updated frequently? (I realize only in the local tree). Note
that when we run the validations we generate a temporary pot file from
the current contents of the tree specifically to avoid overwriting the
pot file.


Are the po files updated more often? I don't really see a reason to
merge the po files with an old pot.


What merge are you referring to? The only merge I'm aware of at the
moment is during validation, but that merge is done from a temporary
updated pot file that is current with the tree.


I'm referring to a manual merge-po.
po_files are only rebuilt from merge-po, which merges the po files with
the pot and adds all the missing translations and line numbers. This is
not needed with Transifex workflow, as Tx should do this internally when
a pot is pushed to it.


Any other merging is done by Transifex at the time we pull a po file.

The frequency of po update doesn't seem relevant, what is your concern
in this regard?


Is there another cause for the po_files to get rebuilt?


Using the TX model there is never a reason to build po files. We just 
pull them from TX.





I suppose having a conversation about when the pot file gets updated is
a good one to have, we don't do it often enough IMHO. But I'm not sure
it's correct to modify a file under SCM control if it wasn't
intentional.


How is Transifex set up here? If it automatically picks up changes when
the pot file is modified, then we should back up the translations before
changing the pot, so we can't do it automatically.
Another wart is the line number cruft in the pot file -- any time it's
updated we'll get a huge diff, so it makes sense to update sparingly.


Transifex gives you two options for your pot file, either you tell TX
the location of your pot file in a public SCM and it watches for updates
and automatically pulls it when it changes in SCM -or- you manually push
the pot file to TX.

We've been using the watch the pot file in git option. Thus whenever
we commit a new version of the pot file all developers and TX get it
simultaneously (well sort of).

If we do the manual push method the maintainer has to *both* commit to
git *and* push to TX, so the former seems less error prone and more
automated.


Well, if the pot file is not in the repo, the maintainer only has to
push it to Tx (after building it of course, but that needs to be done
anyway).


The idea was we would have a string freeze prior to release and/or
periodic intervals during branch development to update the pot. But we
haven't been good about hitting these. However, note a manual push
suffers from the same somebody has to do it at the right moment problem.


Is this idea documented anywhere? It's hard to do a string freeze if
it's not enforced automatically, let alone if people don't know there
should be one.


It was discussed in the developer conference calls.




If Transifex is not wired to the pot, we could even go as far as
removing it from SCM entirely -- it's entirely generated, and rebuilding
it takes less than a second.
We'd just have to update Transifex manually.


It currently is wired to the pot. You make a valid point about currently
not needing to maintain the pot in SCM. When we first set up
translations we weren't using TX so having the pot file in SCM was a
necessity.

Personally I don't trust TX's data storage and I think there is value in
having each pot we push to TX be recoverable from our SCM. When things
blow up (and they do) it's really nice to be able to reassemble the
pieces or at lease follow the trail of how things changed. In the past
I've had to answer

Re: [Freeipa-devel] [PATCH] 0066 Arrange stripping .po files

2012-07-23 Thread John Dennis 

On 07/23/2012 06:27 AM, Petr Viktorin wrote:

As a translator (for another project), I don't like Transifex and prefer
to send good old Git pull requests. I understand a traditional
workflow is hard to coordinate with others that use Transifex, but still
I'd hate it if we became dependent on Tx.


For better or worse we are dependent on TX (Transifex). Fedora has 
adopted TX as it's translation tool, RHEL's translation tools integrate 
with TX (as well as other translation portals). And SSSD and IPA have 
made a a commitment to TX based on the direction of Fedora and RHEL.


Given that we've adopted TX I don't see the value in maintaining tools 
that support both TX and non-TX workflows. I'd rather see us delete the 
non-TX elements. If we have just one workflow it's easier to understand 
and maintain the code. If we ever decide we need to go back to a non-TX 
workflow we can always retrieve the deleted code from git.


--
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] [PATCH] 173 IDs and names for dialogs

2012-07-23 Thread Endi Sukma Dewata 

On 7/19/2012 8:07 AM, Petr Vobornik wrote:

It's hard to detect if or which type of dialog is displayed because not
all dialogs have IDs.

On dialog open, it's id or name (if id is not set) is used for
containing element id. Many of dialog types were missing id or name so
name was added to each dialog type.

In HTML, element's id should be unique. Our framework allows opening two
dialogs with the same id. It may lead to state where getElementById
method may have unpredictable behavior. Therefore attribute 'data-name'
with dialog's name was added to dialog's containing element. Automation
framework can search more reliable by using this attribute instead of id.

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


ACK.

If possible we should replace all element ID's with paths. So the 
element name itself is not unique, but the element can still be uniquely 
identified by following a path from the top to the element itself. The 
path could be a combination of element type, class, or name, for example:


   div[name=container] .entity[name=user] .facet[name=search]

The automation tool should use the path instead of ID.

--
Endi S. Dewata

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

Re: [Freeipa-devel] [PATCH] 174 Fix autoscroll to top in tables in IE

2012-07-23 Thread Endi Sukma Dewata 

On 7/23/2012 9:05 AM, Petr Vobornik wrote:

In IE when a window is small (horizontal scrollbar is displayed) click
or keyboard input on various parts of UI makes search tables scroll to
top. It prevents from selecting items in a table. This issue happens
when using absolute positioned element with overflow style. It's a bug
in IE.

Two workarounds were added to make UI usable in IE.
Adding position:relative; style to body element fixes the problem in
search pages. It doesn't help in association dialogs though.
The bug doesn't occur when some child element has focus. It's possible
to set focus to first visible checkbox while scrolling down but user
experience is very bad. Better solution seems to scroll back when IE
scrolls to top on mousedown. That way mouse click event happens on the
target element and it can gain focus and therefore be selected. Some
glitches still remains but is usable.

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


ACK.

Separate issue, I noticed that on IE the background of the dialog box 
title is black. On Firefox it's green. Same thing for the 
Available/Prospective header in the association dialog.


--
Endi S. Dewata

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