Is it sensible/better to extend the scheme before I start adding users? or
doesnt it matter? From my perspective extending a system in use carries risk
and impact to users, so its seems safer to extend it before I have any users,
even if its un-used for now/?
Apart from that I dont know....for now I would live with the extended schema
for the user....populating the fields would be something I would look at when
its decided what we will be doing....no one yet knows or at least have not told
me what they will be doing.
I suspect in the end we will draw the contents from AD with winsync?
or populate/inject it directly via our Oracle identity system......so I'm not
sure we will need the ui / gui....I dont expect to add content via it, I
suspect I might need to fault find to make sure the data is there but I assume
ldap search tools will return this anyway?
However for other sites they may well not have an AD or user provisioning
Technical Specialist - Linux RHCE
Victoria University, Wellington, NZ
0064 4 463 6272
From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on
behalf of Dmitri Pal [d...@redhat.com]
Sent: Tuesday, 20 March 2012 9:19 a.m.
Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.
On 03/19/2012 03:58 PM, Steven Jones wrote:
> Im starting from scratch here so bear with me......ie I dont know a lot of
> this....which should be obvious....
> Extending Easy? oh because it doesnt strike me as easy......
> Initially I am about to build our production IPA servers. These attributes
> are a requirement of the Federation system New Zealand wants to use and is
> probably the same for Australia. So I think the schema has to be
> done/extended for IPA to be viable in tertiary institutions in NZ, without it
> not many if anyone will use IPA they will stay with openldap. So each person
> should have these I think.....they may not be used initially but once
> extended initially then I dont have to extend the schema later.
> What connects to these is an apache/tomcat front end. There are two
> aspects/functions to this, the IdP and the SdP. The Idp allows remote
> tertiary organisations to query us and say our user is we legit....they then
> use their LDAP to provide resources via the SdP. So the Idp provides an
> identity to remote ppl and the SdP provides access to a resource at our end.
> later I expect we will have to to the SdP bit got our high performance
> cluster and storage...
> It maybe a year or more before we actually use this, but it strikes me as
> sensible that these are done on initial build.....I will put ina RH support
> case for this. We will probably also pull the actual fields/contents out of
> AD.....not sure yet.
The question is simple: how you plan to manage these attributes in IPA?
Do you expect them to be a part of the UI/CLI or they should be hidden
there and be managed via ldapmodify and other data sync tools?
This make the whole difference especially the UI part. Depending upon
these expectations the scope would be different.
> Steven Jones
> Technical Specialist - Linux RHCE
> Victoria University, Wellington, NZ
> 0064 4 463 6272
> From: Rob Crittenden [rcrit...@redhat.com]
> Sent: Tuesday, 20 March 2012 2:55 a.m.
> To: Steven Jones
> Cc: email@example.com
> Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.
> Steven Jones wrote:
>> Is it possible to expand IPA's schema to do this?
> Adding the schema is easy, doing something with it is where things get
> interesting. What do you want to do with these attributes/objectclasses?
> Freeipa-users mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list
Freeipa-users mailing list