Re: [Freeipa-devel] [PATCH] 702 add entitlement API
Rob Crittenden rcrit...@redhat.com wrote: The entitlement plugin was being skipped completely if the python-rhsm package wasn't installed. We want to let it limp through if the package isn't installed but we're doing API validation. ticket 919 rob Patch looks and applies ok, installation and subsequent behavior works as expected (both with and without python-rhsm package), validation as well. ACK Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 78 Use ldapi: instead of unsecured ldap: in ipa core tools.
The patch also corrects exception handling in some of the tools. Fix #874 Pavel freeipa-pzuna-78-toolsldapi.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 73 Update config doc to reflect that 0 is not allowed for search time limit.
On 02/08/2011 12:34 AM, David O'Brien wrote:
Pavel Zuna wrote:
Fix #837
Pavel
/me hesitantly asks...
Doesn't this mean that 1 is illegal?
doc=_('Max. amount of time (sec.) for a search ( 1 or -1 for unlimited)'),
Neither is there any mention of zero being illegal. It may be implicit
or self-evident, but I don't rely on that in doc. I'd be inclined to
change it to ( 0, or -1 for unlimited) but remember, I'm not a coder :)
cheers
You're right. :)
Fixed version attached.
Pavel
freeipa-pzuna-73-2-configdoc.patch
Description: application/mbox
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 72 Set minimum for Kerberos policy max life and max renew
On Mon, Feb 07, 2011 at 02:10:40PM +0100, Pavel Zuna wrote: On 02/07/2011 01:10 PM, Jakub Hrozek wrote: On Mon, Feb 07, 2011 at 11:13:56AM +0100, Pavel Zuna wrote: Fix #847 Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Nack, please update API.txt Forgot about that, sorry. Version with updated API.txt attached. Pavel Ack ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 703 389-ds startup with krb config
If /etc/krb5.conf doesn't exist or contains no default kerberos realm then 389-ds won't start at all. This is a problem during installation because we configure 389 first. This patch will let the server come up, you just won't be able to do any joins or password changes until you configure kerberos. ticket 606 rob freeipa-rcrit-703-startup.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 77 Update krbtpolicy doc to inform that restarting krb5kdc might be needed.
David O'Brien wrote: Dmitri Pal wrote: On 02/07/2011 06:46 PM, David O'Brien wrote: Jenny Galipeau wrote: Pavel Zuna wrote: It seems that restarting krb5kdc is only needed when changes to the global policy are made. Per-user policies take effect immediately for newly requested tickets. Can someone please confirm? Yes, in testing this is the behavior. If the help could specify that a ipactl restart is required after global policy change, that would be great. Thanks Jenny Please raise a suitable bugzilla to get this included in the user doc. So far I only have doc about restarting IPA services after ipa krbtpolicy-reset. Isn't it the same thing? I took changes to mean using krbtpolicy-mod and any others, not just -reset, which is the info I received last time. The bottom line is that any change to the global Kerberos ticket policy requires a restart of the KDC to see the changes (/sbin/service krb5kdc restart). IMHO restarting the entire IPA world for this is overkill. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1 Remove unnecessary BuildRequires
Removed 2 unnecessary BuildRequires from freeipa.spec.in: * e2fsprogs-devel: obsoleted by libuuid-devel * libcap-devel: not needed to build the RPM diff --git a/freeipa.spec.in b/freeipa.spec.in index 9da5809..84c9e8c 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -29,10 +29,8 @@ BuildRequires: svrcore-devel BuildRequires: nspr-devel BuildRequires: openssl-devel BuildRequires: openldap-devel -BuildRequires: e2fsprogs-devel BuildRequires: krb5-devel BuildRequires: nss-devel -BuildRequires: libcap-devel BuildRequires: python-devel BuildRequires: autoconf BuildRequires: automake ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] drop the group.upg NIS map
The group.upg NIS map was an experiment in providing UPG groups
dynamically, and is not one of the maps that I'd ever expect a NIS
client to know to search. We should probably just drop it.
---
install/share/nis.uldif | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/install/share/nis.uldif b/install/share/nis.uldif
index f23b49e..639c88a 100644
--- a/install/share/nis.uldif
+++ b/install/share/nis.uldif
@@ -45,18 +45,6 @@ default:nis-map: group.bygid
default:nis-base: cn=groups, cn=accounts, $SUFFIX
default:nis-secure: no
-dn: nis-domain=$DOMAIN+nis-map=group.upg, cn=NIS Server, cn=plugins, cn=config
-default:objectclass: top
-default:objectclass: extensibleObject
-default:nis-domain: $DOMAIN
-default:nis-map: group.upg
-default:nis-base: cn=users, cn=accounts, $SUFFIX
-default:nis-filter: (objectclass=posixAccount)
-default:nis-key-format: %{uid}
-default:nis-value-format: %{uid}:*:%{gidNumber}:%{uid}
-default:nis-secure: no
-default:nis-disallowed-chars: :,
-
dn: nis-domain=$DOMAIN+nis-map=netid.byname, cn=NIS Server, cn=plugins,
cn=config
default:objectclass: top
default:objectclass: extensibleObject
--
1.7.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Moved add dialog into search facet.
Previously the add dialog is added into entity. The dialog is only
used by the search facet, so it's now moved into the search facet.
--
Endi S. Dewata
From b05f930e7538c69658b9cb3711584ef745dd3548 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Tue, 8 Feb 2011 15:41:24 -0600
Subject: [PATCH] Moved add dialog into search facet.
Previously the add dialog is added into entity. The dialog is only
used by the search facet, so it's now moved into the search facet.
---
install/ui/aci.js | 135 +++--
install/ui/details.js |3 +
install/ui/entity.js | 23 +-
install/ui/group.js| 59 +++--
install/ui/hbacrule.js | 14 ++--
install/ui/hbacsvc.js | 13 ++--
install/ui/hbacsvcgroup.js | 13 ++--
install/ui/host.js | 12 ++--
install/ui/hostgroup.js| 50 ++--
install/ui/netgroup.js | 51 ++--
install/ui/policy.js | 199 +---
install/ui/search.js | 52
install/ui/service.js | 15 ++--
install/ui/sudocmd.js | 13 ++--
install/ui/sudocmdgroup.js | 13 ++--
install/ui/sudorule.js | 13 ++--
install/ui/user.js | 22 +++---
17 files changed, 355 insertions(+), 345 deletions(-)
diff --git a/install/ui/aci.js b/install/ui/aci.js
index fbfb6ba3aebaa12a76156c9140573f4d1a6e2db6..e515902c5c83451389b5c9dde8115e087f9686f3 100644
--- a/install/ui/aci.js
+++ b/install/ui/aci.js
@@ -523,26 +523,26 @@ IPA.entity_factories.permission = function() {
return IPA.entity({
'name': 'permission'
-}).add_dialog(
-IPA.add_dialog({
-name: 'add',
-title: 'Add New Permission',
-width: '700px'
-}).
-field(IPA.text_widget({
-name: 'cn',
-undo: false
-})).
-field(IPA.rights_widget({name: 'permissions', label: 'Permissions', join: true, undo: false})).
-section(IPA.target_section({name: 'target', label: 'Target', undo: false}))).
-facet(IPA.search_facet().
- column({name:'cn'})).
-facet(IPA.permission_details_facet({ name: 'details' }).
- section(
- IPA.stanza({name:'identity', label:'Identity'}).
- input({name: 'cn', 'read_only': true})).
- section(IPA.rights_section()).
- section(IPA.target_section({name: 'target', label: 'Target'})));
+}).
+facet(
+IPA.search_facet().
+column({name:'cn'}).
+dialog(
+IPA.add_dialog({
+name: 'add',
+title: 'Add New Permission',
+width: '700px'
+}).
+field(IPA.text_widget({name: 'cn', undo: false})).
+field(IPA.rights_widget({name: 'permissions', label: 'Permissions', join: true, undo: false})).
+section(IPA.target_section({name: 'target', label: 'Target', undo: false}.
+facet(
+IPA.permission_details_facet({ name: 'details' }).
+section(
+IPA.stanza({name:'identity', label:'Identity'}).
+input({name: 'cn', 'read_only': true})).
+section(IPA.rights_section()).
+section(IPA.target_section({name: 'target', label: 'Target'})));
};
@@ -554,19 +554,20 @@ IPA.entity_factories.privilege = function() {
facet(
IPA.search_facet().
column({name:'cn'}).
-column({name:'description'})).
+column({name:'description'}).
+dialog(
+IPA.add_dialog({
+name: 'add',
+title: 'Add Privilege'
+}).
+field(IPA.text_widget({ name: 'cn', undo: false})).
+field(IPA.text_widget({ name: 'description', undo: false}.
facet(
IPA.details_facet({name:'details'}).
section(
IPA.stanza({name:'identity', label:'Privilege Settings'}).
input({name:'cn'}).
input({name: 'description'}))).
-add_dialog(
-IPA.add_dialog({
-name: 'add',
-title: 'Add Privilege'}).
-field(IPA.text_widget({ name: 'cn', undo: false})).
-field(IPA.text_widget({ name: 'description', undo: false}))).
association({
name: 'permission',
other_entity: 'privilege',
@@ -585,22 +586,23 @@ IPA.entity_factories.role = function() {
return IPA.entity({
'name': 'role'
}).
-facet(IPA.search_facet().
- column({name:'cn'}).
- column({name:'description'})).
+
Re: [Freeipa-devel] [PATCH] 77 Update krbtpolicy doc to inform that restarting krb5kdc might be needed.
Rob Crittenden wrote: David O'Brien wrote: Dmitri Pal wrote: On 02/07/2011 06:46 PM, David O'Brien wrote: Jenny Galipeau wrote: Pavel Zuna wrote: It seems that restarting krb5kdc is only needed when changes to the global policy are made. Per-user policies take effect immediately for newly requested tickets. Can someone please confirm? Yes, in testing this is the behavior. If the help could specify that a ipactl restart is required after global policy change, that would be great. Thanks Jenny Please raise a suitable bugzilla to get this included in the user doc. So far I only have doc about restarting IPA services after ipa krbtpolicy-reset. Isn't it the same thing? I took changes to mean using krbtpolicy-mod and any others, not just -reset, which is the info I received last time. The bottom line is that any change to the global Kerberos ticket policy requires a restart of the KDC to see the changes (/sbin/service krb5kdc restart). IMHO restarting the entire IPA world for this is overkill. rob ok, so we're still talking about any changes to the global ticket policy, not just using ipa krbtpolicy-reset, which is what I had before. I'll update this bit and just recommend krb5kdc restart like you say. cheers -- David O'Brien Red Hat Asia Pacific Pty Ltd +61 7 3514 8189 He who asks is a fool for five minutes, but he who does not ask remains a fool forever. ~ Chinese proverb ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Hosts, A recs, and AAAA recs
The current process to add a host today is: Create an A record run add host We have --force which will allow us to add the host even if the A record doesn't exist, but do we have a way to say, add this host, A record, and record all at the same time? From a cloud perspective, it seems like we are going to get a lot of short lived VMs that will need all three at once. I can see a work flow like this: User requests a number of VMs. VMs get clones from templates and spun up VMs get IP address from DHCP server. DHCP server notifies IPA server of new hosts IPA server adds host entries, A and records VM runs ipa-client install as part of firstboot The IPA server might even get notified earlier. I could see the cloud provider pushing the info to ipa prior to cloning the VM. How would we go about doing that today? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 705 make main selfservice aci visible
The main aci that grants user's the ability to manage themselves wasn't visible to the selfservice plugin. Move the location of the aci and fix the description. ticket 934 rob freeipa-rcrit-705-aci.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Hosts, A recs, and AAAA recs
On Tue, 08 Feb 2011 22:10:16 -0500 Adam Young ayo...@redhat.com wrote: The current process to add a host today is: Create an A record run add host We have --force which will allow us to add the host even if the A record doesn't exist, but do we have a way to say, add this host, A record, and record all at the same time? From a cloud perspective, it seems like we are going to get a lot of short lived VMs that will need all three at once. I can see a work flow like this: User requests a number of VMs. VMs get clones from templates and spun up VMs get IP address from DHCP server. DHCP server notifies IPA server of new hosts What do you mean by this ? Do you want to give the DHCP server the power to perform DNS updates ? Can be done although I am not sure DHCP Servers know how to do GSS-TSIG protected updates, we may have to open up DNS access control to accept everything from the DHCP Server. IPA server adds host entries, A and records Host entries must be added by the cloud engine as it needs to set the enrollment password it passes down to the VM. VM runs ipa-client install as part of firstboot ipa-client-install could also add DNS records, but there is a credential problem if it is an automated process. The IPA server might even get notified earlier. I could see the cloud provider pushing the info to ipa prior to cloning the VM. This might be a better choice as long as the cloud provider can also change the DHCP configuration to assign the right IP address to the VMs using the MAC address. How would we go about doing that today? I think we are missing the part that creates the VMs yet, so ... Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
