date:20100910

Re: [Freeipa-devel] [PATCH] 2. Enabling SUDO support

2010-09-10 Thread Dmitri Pal

Rob Crittenden wrote:
 Dmitri Pal wrote:
 See patch comment for more details.


 ACK with these exceptions:

 I made a few minor changes in the ldif syntax:
 - remove blank lines
 - add missing dn: cn=schema
 - move SYNTAX to just before X-ORIGIN in hostMask

 I also fixed the SUDO service group entry, it was missing the
 ipauniqueid attribute.

 If these changes are ok then I can go ahead and push this.

 rob
Thank you Rob!

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

Re: [Freeipa-devel] [PATCH] 524 spec file cleanup

2010-09-10 Thread Adam Young


On 09/09/2010 06:13 PM, Rob Crittenden wrote:

Clean up the spec file, add Requires for nss-pam-ldapd for F14+

Also do the following:
- Remove conflicts on mod_ssl
- Remove a lot of version checking for EOL'd Fedora versions
- Add a few conditionals for rhel6
- Add Requires of nss-tools on ipa-client

tickets 62, 153

rob


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

ACK



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

Re: [Freeipa-devel] Optimizing for the common case: automount and DNS

2010-09-10 Thread Rob Crittenden


Dmitri Pal wrote:

Adam Young wrote:

Both Automount and DNS are heirarchical entities.


DNS starts with a zone.  Usually, a zone is a domain name, like
redhat.com.  It might be more specific, like devel.redhat.com.

A DNS setup is going to have at a minimum one zone, and is likely to
only have a single zone.

A Zone is pretty much just a name, and then a collection of records.
The records are owned by the zone.  THere will be very little or no
crossover between zones.   Thus, I'm thinking that the most common
thing people are going to want to do is to manage the records for a
single zone.


So the question becomes, one tab or two?If we go two, we have DNS
zones and DNS records, with an association facet on the zone that
points to the record.  The difference that doesn't map to existing use
cases is that a given record is always associated with a zone, so
creating a records, and then later associating it with a zone does not
make sense.

We could put a UI element like the finder on the associations page on
the record page.  So to create a record, one of the steps you'd do
would be to run a zone search.  This seems awkward.

I'm thinking instead that we should have a single DNS tab.  If we have
a single zone, this tab defaults to the finder page for records for
that zone.  Clicking add creates a new record form, with the zone
hardcoded already to be the default one.

In the case where there are more than one zone, the default facet is
the zone search.  I suspect that this search should be automatically
executed with a blank filter upon load so that the set of zones is
available.  Selecting a zone then goes to the finder page for the
records , again, with the search pre-executed, and the name of the
zone hyperlinked at the top.


This approach also works with automounts.  The default case for
automounts is a single location.  There are two entities beyond
location to manage: maps and keys.  These two are hierarchical:
location owns map, map owns key.

For this entity, I think the default page should be the search page
for maps, with a search that specifies the default location.  Each map
entry has a hyperlink to its keys page, again a search pre-executed.

Once multiple locations are defined, the default page for automount
should be the location search page, pre-executed.


Here is the criticisms I've thought of so far.  It requires multiple
calls to the server to determine what to display.  The second is that
it is more complicated, and will take somewhat more time to
implement.  The user will not expect the content of a tab to change
out from under them.


An alternative approach is that we can make DNS and Automount top
level tabs, with zone and records tabs under DNS, and locations, maps
and keys as tabs under Automount.   Then, all we do is change which is
the default tab based on the above logic.  That would make the top
level tabs:

Identity DNS Automount Config

I'm not sure if this is a scalable approach, once we add entitlements,
sudo, hbac, hci, and so on.




I think we need to run this by Ben and make sure we are in agreement.
Is this blocking you?

I do not like the ideas of DNS and Automount on the top level, sorry.


I'm not sure about this either. I think that as the project continues 
we'll quickly run out of room if we do this.



May be we should look at the DNS zones (Z) and automount locations (L)
in the following way:
1) The fist page you get two when you go for DNS or Automount is search
for Z or L as in all other places. But...
2) At the beginning there are no Z or L so the code instead of
displaying the search page will redirect user to the non modal add Z

 or add L page respectfully automatically.

Actually there will always be both a Z and an L. The Z is created when 
the server is installed, though we do probably need to handle the case 
where all zones are deleted.


Same for L. We provide one named default.


3) If there is just one Z or L entry the search page will automatically
redirect user to the Z or L contents page
4) On the Z or L content page we will have a button add another Z or
add another L. This will be the way to add second Z or L in the first
place.
5) As soon as there are more than 1 Z or L the search page will present
the list rather than do automatic redirect.

This seems to be a pretty logical and consistent approach.
Now if we agree to this one it might make sense to consider doing the
same thing for some of the objects that by default will not be
prepopulated in the LDAP. For example netgroups or host groups. I am not
sure it makes sense for users and groups since there will be at least
one user and one group from the installation moment.


The thing is this is like a .0001% case. You probably will ever only see 
it once during an install. Assuming it doesn't take a lot of work to do 
it I'm fine with it, otherwise the search box where there is nothing to 
be found is fine by me.


rob

___
Freeipa-devel

Re: [Freeipa-devel] Optimizing for the common case: automount and DNS

2010-09-10 Thread Dmitri Pal

Adam Young wrote:
 On 09/10/2010 10:24 AM, Rob Crittenden wrote:
 Dmitri Pal wrote:
 Adam Young wrote:
 Both Automount and DNS are heirarchical entities.


 DNS starts with a zone.  Usually, a zone is a domain name, like
 redhat.com.  It might be more specific, like devel.redhat.com.

 A DNS setup is going to have at a minimum one zone, and is likely to
 only have a single zone.

 A Zone is pretty much just a name, and then a collection of records.
 The records are owned by the zone.  THere will be very little or no
 crossover between zones.   Thus, I'm thinking that the most common
 thing people are going to want to do is to manage the records for a
 single zone.


 So the question becomes, one tab or two?If we go two, we have DNS
 zones and DNS records, with an association facet on the zone that
 points to the record.  The difference that doesn't map to existing use
 cases is that a given record is always associated with a zone, so
 creating a records, and then later associating it with a zone does not
 make sense.

 We could put a UI element like the finder on the associations page on
 the record page.  So to create a record, one of the steps you'd do
 would be to run a zone search.  This seems awkward.

 I'm thinking instead that we should have a single DNS tab.  If we have
 a single zone, this tab defaults to the finder page for records for
 that zone.  Clicking add creates a new record form, with the zone
 hardcoded already to be the default one.

 In the case where there are more than one zone, the default facet is
 the zone search.  I suspect that this search should be automatically
 executed with a blank filter upon load so that the set of zones is
 available.  Selecting a zone then goes to the finder page for the
 records , again, with the search pre-executed, and the name of the
 zone hyperlinked at the top.


 This approach also works with automounts.  The default case for
 automounts is a single location.  There are two entities beyond
 location to manage: maps and keys.  These two are hierarchical:
 location owns map, map owns key.

 For this entity, I think the default page should be the search page
 for maps, with a search that specifies the default location.  Each map
 entry has a hyperlink to its keys page, again a search pre-executed.

 Once multiple locations are defined, the default page for automount
 should be the location search page, pre-executed.


 Here is the criticisms I've thought of so far.  It requires multiple
 calls to the server to determine what to display.  The second is that
 it is more complicated, and will take somewhat more time to
 implement.  The user will not expect the content of a tab to change
 out from under them.


 An alternative approach is that we can make DNS and Automount top
 level tabs, with zone and records tabs under DNS, and locations, maps
 and keys as tabs under Automount.   Then, all we do is change which is
 the default tab based on the above logic.  That would make the top
 level tabs:

 Identity DNS Automount Config

 I'm not sure if this is a scalable approach, once we add entitlements,
 sudo, hbac, hci, and so on.



 I think we need to run this by Ben and make sure we are in agreement.
 Is this blocking you?

 I do not like the ideas of DNS and Automount on the top level, sorry.

 I'm not sure about this either. I think that as the project continues
 we'll quickly run out of room if we do this.
 Yeah, I don't either.  I was just offereing it as an alternative.


 May be we should look at the DNS zones (Z) and automount locations (L)
 in the following way:
 1) The fist page you get two when you go for DNS or Automount is search
 for Z or L as in all other places. But...
 2) At the beginning there are no Z or L so the code instead of
 displaying the search page will redirect user to the non modal add Z
  or add L page respectfully automatically.

 Actually there will always be both a Z and an L. The Z is created
 when the server is installed, though we do probably need to handle
 the case where all zones are deleted.

 Same for L. We provide one named default.

Then it even reduces the logic to handling one and more than one and not
having to have case for 0.



 3) If there is just one Z or L entry the search page will automatically
 redirect user to the Z or L contents page
 4) On the Z or L content page we will have a button add another Z or
 add another L. This will be the way to add second Z or L in the first
 place.
 5) As soon as there are more than 1 Z or L the search page will present
 the list rather than do automatic redirect.

 That sounds pretty much like what I was recommending.  I think we are
 in violent agreement

We were in agreement from the very beginning. It is just that I tried to
use the wording that makes more sense for me and present the case in a
more algorithmic way.


 This seems to be a pretty logical and consistent approach.
 Now if we agree to this one it might make sense to consider doing the
 same thing

[Freeipa-devel] Javascript coding standards

2010-09-10 Thread Adam Young

I started a page on the Trac wiki for Javascrpt coding standards.  The 
old wiki does not accept my userid and password, otherwise, I would have 
put it next to the standards for C and Python.



https://fedorahosted.org/freeipa/wiki/Javascript_Coding_Standards


The standards are pretty meagre  thus far.  Please submit suggestions 
and references.


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

Re: [Freeipa-devel] [PATCH] Splitting service principal into service name and hostname.

2010-09-10 Thread Endi Sukma Dewata

- Adam Young ayo...@redhat.com wrote:

 ACK, although
 please add the following error check in add.js line 67ish
 if (response.error){
 if (response.error.message){
 alert(response.error.message);
 }else{
 alert(error adding entry);
 }
 return;
 }

OK, fixed in the new attachment. Thanks!

--
Endi S. Dewata
From cee21193e33900c2abaab6a581bc70baacfc1d83 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Thu, 9 Sep 2010 22:21:29 -0400
Subject: [PATCH] Splitting service principal into service name and hostname.

The EntityBuilder has been modified to obtain the pkey value by
invoking getPKey(). This function can be overriden for different
entities.

The addOptionsFunction() has been renamed to getOptions() and it
can be overriden for different entities. Each entity that uses this
function has been modified accordingly.

The addEdit(), addAnother(), add_fail() has been moved into the
EntityBuilder class. The global builders is no longer needed because
a reference to the builder object can be obtained via enclosure.

The ServiceForms has been modified to take service name and
hostname and combine them to generate the service principal by
overriding the getPKey().
---
 install/static/add.js   |  112 ++-
 install/static/hostgroup.js |   18 
 install/static/netgroup.js  |   20 
 install/static/service.js   |   17 +++
 install/static/user.js  |   14 +++--
 5 files changed, 92 insertions(+), 89 deletions(-)

diff --git a/install/static/add.js b/install/static/add.js
index 97f7666..fcbcc52 100644
--- a/install/static/add.js
+++ b/install/static/add.js
@@ -22,34 +22,31 @@
 
 /* REQUIRES: ipa.js */
 
-/*
- * An associatev array between entity names and their builders
- */
-var builders = {} ;
-
 
-function add_fail(desc){
-alert(desc);
-}
+//Process for managing the 'add' functionality
+function EntityBuilder(obj,addProperties){
 
+var builder = this;
 
-//Process for managing the 'add' functionality
-function EntityBuilder(obj,addProperties,addOptionsFunction ){
 this.obj = obj;
 this.addProperties = addProperties;
-if (addOptionsFunction){
-this.addOptionsFunction = addOptionsFunction;
-}else{
-this.addOptionsFunction = function(){
-var options = { };
-return options;
-}
+
+this.getPKey = function(){
+return $(#pkey).val();
+}
+
+this.getOptions = function(){
+return {};
+}
+
+this.add_fail = function(desc){
+alert(desc);
 }
 
-this.add = function(on_success){
-var options = this.addOptionsFunction();
-var params = [$(#pkey).val()];
-ipa_cmd( 'add', params, options, on_success, add_fail, this.obj );
+this.add = function(pkey, on_success){
+var params = [pkey];
+var options = this.getOptions();
+ipa_cmd( 'add', params, options, on_success, this.add_fail, this.obj );
 }
 
 this.setup = function(){
@@ -58,24 +55,53 @@ function EntityBuilder(obj,addProperties,addOptionsFunction ){
 $(div id='addForm' /div)
 .appendTo(#content);
 var label =$(spanAdd and /span).appendTo(#addForm)
-$(input \,
-  {id:'addEdit',
-   type:'button',
-   value:'Edit',
-   click: function(){
-   var params = ipa_parse_qs();
-   builders[params[tab]].add (addEdit)
-   }
-  }).appendTo(label);
+
+$(input \, {
+id:'addEdit',
+type:'button',
+value:'Edit',
+click: function(){
+var params = ipa_parse_qs();
+var pkey = builder.getPKey();
+builder.add(pkey, function(response){
+if (response.error){
+if (response.error.message) {
+alert(response.error.message);
+} else {
+alert(error adding entry);
+}
+return;
+}
+var hash= tab=
++params[tab]
++facet=detailspkey=
++pkey;
+window.location.hash = hash;
+});
+}
+}).appendTo(label);
+
 $(input\, {
 id:'addAnother',
 type:'button',
 value:'Add Another',
 click: function(){
-   var params = ipa_parse_qs();
-builders[params[tab]].add (addAnother)
+var params = ipa_parse_qs();
+var pkey = builder.getPKey();
+builder.add(pkey, function(response){
+if (response.error){
+if (response.error.message) {
+alert(response.error.message);
+} else {
+

Re: [Freeipa-devel] [PATCH] Splitting service principal into service name and hostname.

2010-09-10 Thread Adam Young


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

Splitting service principal into service name and hostname.

The EntityBuilder has been modified to obtain the pkey value by
invoking getPKey(). This function can be overriden for different
entities.

The addOptionsFunction() has been renamed to getOptions() and it
can be overriden for different entities. Each entity that uses this
function has been modified accordingly.

The addEdit(), addAnother(), add_fail() has been moved into the
EntityBuilder class. The global builders is no longer needed because
a reference to the builder object can be obtained via enclosure.

The ServiceForms has been modified to take service name and
hostname and combine them to generate the service principal by
overriding the getPKey().
   

pushed to master

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

[Freeipa-devel] [PATCH] 527 add --no-host-dns option to ipa-replica-install

2010-09-10 Thread Rob Crittenden

ipa-server-install has a --no-host-dns option but ipa-replica-install 
didn't. This evens the playing field.


rob
From e5982445330979fc711086e2be5933299b4bd213 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Fri, 10 Sep 2010 17:51:08 -0400
Subject: [PATCH] Add --no-host-dns argument to ipa-replica-install

The server installer has this option, the replica installer should have
it too.

ticket 146
---
 install/tools/ipa-replica-install   |9 ++---
 install/tools/man/ipa-replica-install.1 |   23 +--
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index 4bf1506..9249c9f 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -64,6 +64,9 @@ def parse_options():
   help=Add a DNS forwarder)
 parser.add_option(--no-forwarders, dest=no_forwarders, action=store_true,
   default=False, help=Do not add any DNS forwarders, use root servers instead)
+parser.add_option(--no-host-dns, dest=no_host_dns, action=store_true,
+  default=False,
+  help=Do not use DNS for hostname lookup during installation)
 
 options, args = parser.parse_args()
 
@@ -108,10 +111,10 @@ def read_info(dir, rconfig):
 rconfig.host_name = config.get(realm, destination_host)
 rconfig.subject_base = config.get(realm, subject_base)
 
-def get_host_name():
+def get_host_name(no_host_dns):
 hostname = installutils.get_fqdn()
 try:
-installutils.verify_fqdn(hostname)
+installutils.verify_fqdn(hostname, no_host_dns)
 except RuntimeError, e:
 logging.error(str(e))
 sys.exit(1)
@@ -285,7 +288,7 @@ def main():
 config = ReplicaConfig()
 read_info(dir, config)
 config.dirman_password = dirman_password
-host = get_host_name()
+host = get_host_name(options.no_host_dns)
 if config.host_name != host:
 try:
 print This replica was created for '%s' but this machine is named '%s' % (config.host_name, host)
diff --git a/install/tools/man/ipa-replica-install.1 b/install/tools/man/ipa-replica-install.1
index dd9a9ae..a150930 100644
--- a/install/tools/man/ipa-replica-install.1
+++ b/install/tools/man/ipa-replica-install.1
@@ -1,21 +1,21 @@
 .\ A man page for ipa-replica-install
 .\ Copyright (C) 2008 Red Hat, Inc.
-.\ 
+.\
 .\ This is free software; you can redistribute it and/or modify it under
 .\ the terms of the GNU Library General Public License as published by
 .\ the Free Software Foundation; version 2 only
-.\ 
+.\
 .\ This program is distributed in the hope that it will be useful, but
 .\ WITHOUT ANY WARRANTY; without even the implied warranty of
 .\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 .\ General Public License for more details.
-.\ 
+.\
 .\ You should have received a copy of the GNU Library General Public
 .\ License along with this program; if not, write to the Free Software
 .\ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-.\ 
+.\
 .\ Author: Rob Crittenden rcrit...@redhat.com
-.\ 
+.\
 .TH ipa-replica-install 1 Mar 14 2008 freeipa 
 .SH NAME
 ipa\-replica\-install \- Create an IPA replica
@@ -26,21 +26,21 @@ Configures a new IPA server that is a replica of the server that generated it. O
 
 The replica_file is created using the ipa\-replica\-prepare utility.
 .SH OPTIONS
-.TP 
+.TP
 \fB\-d\fR, \fB\-\-debug
 Enable debug logging when more verbose output is needed
-.TP 
+.TP
 \fB\-n\fR, \fB\-\-no\-ntp\fR
 Do not configure NTP
-.TP 
-\fB\-p\fR, \fB\-\-password\fR=\fIDM_PASSWORD\fR 
+.TP
+\fB\-p\fR, \fB\-\-password\fR=\fIDM_PASSWORD\fR
 Directory Manager (existing master) password
 .TP
 \fB\-\-setup\-dns\fR
 Generate a DNS zone if it does not exist already and configure the DNS server.
 This option requires that you either specify at least one DNS forwarder through
 the \fB\-\-forwarder\fR option or use the \fB\-\-no\-forwarders\fR option.
-.TP 
+.TP
 \fB\-\-forwarder\fR=\fIIP_ADDRESS\fR
 Add a DNS forwarder to the DNS configuration. You can use this option multiple
 times to specify more forwarders, but at least one must be provided, unless
@@ -48,6 +48,9 @@ the \fB\-\-no\-forwarders\fR option is specified.
 .TP
 \fB\-\-no\-forwarders\fR
 Do not add any DNS forwarders. Root DNS servers will be used instead.
+.TP
+\fB\-\-no\-host\-dns\fR
+Do not use DNS for hostname lookup during installation
 .SH EXIT STATUS
 0 if the command was successful
 
-- 
1.7.2.1

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

Re: [Freeipa-devel] [PATCH] 527 add --no-host-dns option to ipa-replica-install

2010-09-10 Thread Adam Young


On 09/10/2010 05:56 PM, Rob Crittenden wrote:
ipa-server-install has a --no-host-dns option but ipa-replica-install 
didn't. This evens the playing field.


rob


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

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

[Freeipa-devel] [PATCH] admiyo-freeipa-0023-user-whoami.patch

2010-09-10 Thread Adam Young


  user whoami
Added a whoami option to the user, allows the user to query their 
own information based on their Kerberos principal



https://fedorahosted.org/freeipa/attachment/ticket/47/admiyo-freeipa-0023-user-whoami.patch

This will be used to return the users principal and rolegroups.


Test with :

curl   -H Content-Type:application/json  -H 
Accept:applicaton/json -H Accept-Language:es--negotiate -u 
:  --cacert /etc/ipa/ca.crt   -d  
'{method:user_find,params:[[],{ all:true,whoami:True } 
],id:0}'  -X POST   http://127.0.0.1:/ipa/json




as well as

ipa user-find --whoami --all
From 903e9978c3a98f3746748b782a92136b75546a93 Mon Sep 17 00:00:00 2001
From: Adam Young ayo...@redhat.com
Date: Fri, 10 Sep 2010 21:25:04 -0400
Subject: [PATCH] user whoami
 Added a whoami option to the user, allows the user to query their own information based on their Kerberos principal

---
 ipalib/plugins/user.py |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 5841d7a..803ee10 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -51,6 +51,7 @@ from ipalib import api, errors
 from ipalib import Flag, Int, Password, Str
 from ipalib.plugins.baseldap import *
 from ipalib import _, ngettext
+from ipalib import util
 
 
 class user(LDAPObject):
@@ -241,6 +242,16 @@ class user_find(LDAPSearch):
 Search for users.
 
 
+takes_options = (
+Flag('whoami',
+label=_('Self'),
+doc=_('Display user record for current Kerberos principal'),
+),
+)
+def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
+if options.get('whoami', True):
+return ((objectclass=posixaccount)(krbprincipalname=+util.get_current_principal() + ))
+
 msg_summary = ngettext(
 '%(count)d user matched', '%(count)d users matched', 0
 )
-- 
1.7.1

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

Re: [Freeipa-devel] [PATCH] 2. Enabling SUDO support

Re: [Freeipa-devel] [PATCH] 524 spec file cleanup

Re: [Freeipa-devel] Optimizing for the common case: automount and DNS

Re: [Freeipa-devel] Optimizing for the common case: automount and DNS

[Freeipa-devel] Javascript coding standards

Re: [Freeipa-devel] [PATCH] Splitting service principal into service name and hostname.

Re: [Freeipa-devel] [PATCH] Splitting service principal into service name and hostname.

[Freeipa-devel] [PATCH] 527 add --no-host-dns option to ipa-replica-install

Re: [Freeipa-devel] [PATCH] 527 add --no-host-dns option to ipa-replica-install

[Freeipa-devel] [PATCH] admiyo-freeipa-0023-user-whoami.patch

10 matches

Site Navigation

Mail list logo

Footer information