On 19.9.2014 17:06, Simo Sorce wrote:
On Fri, 19 Sep 2014 09:08:46 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:


On 09/18/2014 08:27 PM, Simo Sorce wrote:
On Thu, 18 Sep 2014 14:22:07 -0400
Nathaniel McCallum <npmccal...@redhat.com> wrote:

On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote:
On Thu, 18 Sep 2014 13:56:44 -0400
Nathaniel McCallum <npmccal...@redhat.com> wrote:

snip
NACK, you cannot move from MAY to MUST.
This is precisely what we have been discussing on IRC today. The
consensus was that this was acceptable because of the update plugin
and the rarity of the state in which a token would not have
ipatokenTOTPwatermark set (the token has to be created an never
used).
Sorry I was not around, but it is never acceptable, as it may cause
replication failures.
I agree that this shouldn't be done, although  replication should not
be  a problem, the consumer relies on the schema checking of the
server where the operation was originally applied.
But problems may show up for existing entries, if you have an an
entry without attr A, which now becomes MUST and then do any
modification on this entry, after the mod the entry will be schema
checked, the missing attribute detected and the mod rejected

This has been a long (albeit perhaps unspoken) rule in changing
schema in FreeIPA.
if you want to define the rules for schema change somewhere, you
should add this as well: never make a multivalued attribute
singlevalued

Ok I added this new page: http://www.freeipa.org/page/Schema_Handling

Thanks for the page, very helpful.


I would like to add a link to it in
http://www.freeipa.org/page/Contribute/Code if I get a review and an
ack for the page.


Existing objectlasses can *never* gain new MUST attributes. This
rule is rigid and is non-negotiable.

If you want to ensure that every entry has a specific attribute, but
connot enforce this by the schema, an option would be to define a CoS
rule for this attr which defines a default and gives the real attr
precedence

Yeah this is a good idea, should we add a section in that page with
advice on how to handle situations where you'd like to change an
objectclass/attribute but are not allowed by our rules ?


+1 Would be helpful as well.
--
Petr Vobornik

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

Reply via email to