Re: [Freeipa-devel] [PATCH] 478 better startup error handling
On 06/25/2010 01:52 PM, Rob Crittenden wrote: This patch will limit the amount of output in the Apache error log by default. It should suppress the traceback and just display the exception. This is mostly to handle LDAP connection issues during startup where we retrieve the schema but it could have other implications as well. I've added a new config file directive, startup_traceback, defaulting to False. If you want the full traceback you can add this to /etc/ipa/default.conf (or ~/.ipa/default.conf) and get full tracebacks. In lite-server.py this defaults to True. I was looking for a way to cause Apache startup to fail if something blew up in IPA but I couldn't find anything in mod_wsgi to support that. 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] A question of terminology for the User Experience....
Ben Dubrovsky wrote: > Hi, > > I am convinced that one of the most critical possible points of user > confusion has to do with the difference between the concept of an object > (user, group, netgroup, etc) as a *container* holding other objects and the > concept of an object being *contained* by another group. > > To design against this confusion, I would like to see us put in as many > points of disambiguation as possible. These include differentiation in icons, > perhaps colors, and, most important, in language. > > In particular - it is important the the term referring the "containing > others" and the term referring to "contained by others" be linguistically > different from each other. The terms "Member" and "Membership", for instance, > are too similar to provide much disambiguation. In the July 7 set of > skeletons, I introduced a consistent terminology in which these terms were > linguistically different. Dmitry pointed out to me yet another cause of > confusion that my terms added. After some discussion, we came up with a > different set of terms, that I would like to get some feedback on. > > First, the terms I introduced: > > >From the point of view of any given object: > The objects it contains are *Members* > The relationships to objects that contain it are *Enrollments* > > The actions related to them: > Contained objects are *added* and *removed* -- i.e. Members > Objects are *enrolled in* and *withdrawn from* containing objects -- i.e. > Enrollments > > Objects: > To create an object, use *New* > To delete an object, use *Delete* > > These terms form the basis of the grammar I used in the July 7 skeletons, and > commands, help strings, labels, and titles are derived from these. There are > several other clues that are designed in as well: > * The general action paradigm is to: >1) find one object out of many; >2) navigate to the proper element of that object; >3) either add to or delete from the list of objects stored in that > element > * For adding Members, I title the screen in the form: > "Add object(s) to thisObject itsName" (e.g. "Add Host Group(s) to > Netgroup foo") > * For adding Enrollments, I title the screen in a similar, but (hopefully) > disambiguated way: > "Enroll thisObject itsName in object(s)" (e.g. "Enroll User foo in > Netgroup(s)") > * Just because it seems extra weird to enroll an object in its own kind of > object, I add the word "other" in this case: > "Enroll Netgroup Foo in other Netgroup(s)" > * The navigation tabs to the separate elements in an object are also based > on this formula, and disambiguated by whether the > tab represents objects "contained" in this one, or pointers to other > "containing" object. > * For objects "contained" in this one, I use the form: > "Member objects" (e.g. "Member Hosts" or "Member Groups") > * For pointers to objects "containing" this, I use the form: > "Enrollment in objects" (e.g. "Enrollment in Host Groups" or > "Enrollment in Groups") > * I also use the word other when the relationship is for the same kind of > object: > "Enrollment in other Netgroups" > * For elements that do not present the ambiguity of contained vs. > containing, I just use the word: e.g. Details, or Roles. > * At the head of the list of tabs, I use the type of the current object > with a colon, suggesting a phase completion. > * For instance, on the element pages for the Group object, the word > "Group:" is at the head of the tabs. Possible completions (with the tab > names) are: > Group: Member Users > Group: Member Groups > Group: Enrollment in other Groups > Group: Enrollment in Netgroups > Group: Details > > So here's the challenge: The term "enroll" is overloaded. There are others > that the thesaurus has that are workable: Enlistment , Association and > Membership > > We also have to choose words that fit in the various parts of speech in which > the word is used in the UI. For instance, "Join" is great as a verb, but > there is no noun to describe it (Joinment?). > > (As a reference, I've put the list of all phrases that use these related > terms at the end of this note.) > > If we choose "Membership", then we need to change the notion of "Member". Not > that it's wrong -- but I want to use another term that is clearly > linguistically different than Membership -- to disambiguate. Possible words > are: affiliate, associate, and constituent. > > So: (*whew!!*) > > Do we use: > Member(s) and Enrollment (my first attempt, but conflicts with other > meanings of Enroll) > Member(s) and Enlistment > Member(s) and Association > > Associate(s) and Membership > Affilate(s) and Membership > Constituent(s) and Membership > > What do you think? > > Ben > > > > PS: The list of phrases that the words need to
[Freeipa-devel] A question of terminology for the User Experience....
Hi, I am convinced that one of the most critical possible points of user confusion has to do with the difference between the concept of an object (user, group, netgroup, etc) as a *container* holding other objects and the concept of an object being *contained* by another group. To design against this confusion, I would like to see us put in as many points of disambiguation as possible. These include differentiation in icons, perhaps colors, and, most important, in language. In particular - it is important the the term referring the "containing others" and the term referring to "contained by others" be linguistically different from each other. The terms "Member" and "Membership", for instance, are too similar to provide much disambiguation. In the July 7 set of skeletons, I introduced a consistent terminology in which these terms were linguistically different. Dmitry pointed out to me yet another cause of confusion that my terms added. After some discussion, we came up with a different set of terms, that I would like to get some feedback on. First, the terms I introduced: >From the point of view of any given object: The objects it contains are *Members* The relationships to objects that contain it are *Enrollments* The actions related to them: Contained objects are *added* and *removed* -- i.e. Members Objects are *enrolled in* and *withdrawn from* containing objects -- i.e. Enrollments Objects: To create an object, use *New* To delete an object, use *Delete* These terms form the basis of the grammar I used in the July 7 skeletons, and commands, help strings, labels, and titles are derived from these. There are several other clues that are designed in as well: * The general action paradigm is to: 1) find one object out of many; 2) navigate to the proper element of that object; 3) either add to or delete from the list of objects stored in that element * For adding Members, I title the screen in the form: "Add object(s) to thisObject itsName" (e.g. "Add Host Group(s) to Netgroup foo") * For adding Enrollments, I title the screen in a similar, but (hopefully) disambiguated way: "Enroll thisObject itsName in object(s)" (e.g. "Enroll User foo in Netgroup(s)") * Just because it seems extra weird to enroll an object in its own kind of object, I add the word "other" in this case: "Enroll Netgroup Foo in other Netgroup(s)" * The navigation tabs to the separate elements in an object are also based on this formula, and disambiguated by whether the tab represents objects "contained" in this one, or pointers to other "containing" object. * For objects "contained" in this one, I use the form: "Member objects" (e.g. "Member Hosts" or "Member Groups") * For pointers to objects "containing" this, I use the form: "Enrollment in objects" (e.g. "Enrollment in Host Groups" or "Enrollment in Groups") * I also use the word other when the relationship is for the same kind of object: "Enrollment in other Netgroups" * For elements that do not present the ambiguity of contained vs. containing, I just use the word: e.g. Details, or Roles. * At the head of the list of tabs, I use the type of the current object with a colon, suggesting a phase completion. * For instance, on the element pages for the Group object, the word "Group:" is at the head of the tabs. Possible completions (with the tab names) are: Group: Member Users Group: Member Groups Group: Enrollment in other Groups Group: Enrollment in Netgroups Group: Details So here's the challenge: The term "enroll" is overloaded. There are others that the thesaurus has that are workable: Enlistment , Association and Membership We also have to choose words that fit in the various parts of speech in which the word is used in the UI. For instance, "Join" is great as a verb, but there is no noun to describe it (Joinment?). (As a reference, I've put the list of all phrases that use these related terms at the end of this note.) If we choose "Membership", then we need to change the notion of "Member". Not that it's wrong -- but I want to use another term that is clearly linguistically different than Membership -- to disambiguate. Possible words are: affiliate, associate, and constituent. So: (*whew!!*) Do we use: Member(s) and Enrollment (my first attempt, but conflicts with other meanings of Enroll) Member(s) and Enlistment Member(s) and Association Associate(s) and Membership Affilate(s) and Membership Constituent(s) and Membership What do you think? Ben PS: The list of phrases that the words need to work within are below. This includes an example of why Enroll doesn't work -- see if you can find it! Enroll Group Foo in Netgroup(s) Enroll Group Foo in other Group(s) Enroll Host Group Foo in Netgroup(s) Enroll Host Group
Re: [Freeipa-devel] [PATCH] 479 add service-disable command
Rob Crittenden wrote: Add API to delete a service principal key, service-disable. This is so an admin can essentially revoke a service principal without deleting it. I have to do some pretty low-level LDAP work to achieve this. Since we can't read the key using our modlist generator won't work and lots of tricks would be needed to use the LDAPUpdate object in any case. The alternative is to add a function to the ldap2 backend that achieves this, or something similar like 'delete_attrs'. I just didn't see a general case for it. I pulled usercertificate out of the global params and put into each appropriate function because it makes no sense for service-disable. I added tests to verify that the certificate we issue is found in the service. This also double-checks that the service commands actually return certificate data. rob We need a similar functionality for hosts so I'm going to pull back this patch and do both at once. I'm going to move the magic that does the key deletion into ldap2 to make for a very simple call within the plugins. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Git devel approach
On Thu, 08 Jul 2010 14:41:51 -0400 Adam Young wrote: > I have a blog that I use as my programmers notebook. I recently > wrote up the approach I am using for working with git in our > distributed development. Please take a look, and tell me if this > matches what other people are doing, or if there are any obvious > errors. > > http://adam.younglogic.com/?p=885 This is more or less what I do daily for SSSD and Samba and used to do with the FreeIPA stuff when I was a bit more active. 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] 479 add service-disable command
Adam Young wrote: On 07/08/2010 02:57 PM, Rob Crittenden wrote: Add API to delete a service principal key, service-disable. This is so an admin can essentially revoke a service principal without deleting it. I have to do some pretty low-level LDAP work to achieve this. Since we can't read the key using our modlist generator won't work and lots of tricks would be needed to use the LDAPUpdate object in any case. The alternative is to add a function to the ldap2 backend that achieves this, or something similar like 'delete_attrs'. I just didn't see a general case for it. I pulled usercertificate out of the global params and put into each appropriate function because it makes no sense for service-disable. I added tests to verify that the certificate we issue is found in the service. This also double-checks that the service commands actually return certificate data. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Well, it builds and deploys. How do I test? I added test information to ticket https://fedorahosted.org/freeipa/ticket/52 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
