Packaging the eDirectory Schema

Hi folks,

Over the years I've worked on lots of projects where a Development / User Acceptance Testing / Production environment model is utilised.

Packages make moving drivers / resources through that model really easy. One thing keeps coming back to bite me every now and then though is remembering to move the supporting schema updates into the higher environments.

My thought "Wouldn't it be awesome to include your vault schema in an Identity Vault package"

Just wanted to canvas thoughts really on whether you agree, and if not, I'd be interested to hear how you version control and manage your schema between environments?

Cheers!

Jim
Parents
  • jimgoodall wrote:

    > My thought "Wouldn't it be awesome to include your vault schema in an
    > Identity Vault package"
    >
    > Just wanted to canvas thoughts really on whether you agree, and if not,
    > I'd be interested to hear how you version control and manage your schema
    > between environments?


    You can package schema as a generic resource objects at ID Vault level and
    package them. Copy/paste the classes and/or attributes required for your driver
    as SCH or LDIF and you'll always have the correct schema right where you need
    it. Of course this does not deploy the schema automatically, but it's easy
    enough to save it to a file, then import into the ID Vault with Designer and
    deploy it.

    So basically you have schema under version control and distribite it with the
    drivers that require it. Only the actual process of extending the schema
    remains a manual process. Would be nice to have that automated as well, you
    could probably create a service driver that reads all your schema resources and
    uses ldapmodify to deploy their contents. Would I want this in my production
    environments? Not sure... ;-)

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • Thanks - I hadn't considered using a resource object. More elegant than forgetting to deploy the schema ;)

    Not sure how you'd make that work with an IDV level package though as a DirXML-Resource objects can only be contained in a Driver, Driver Set, Library, Publisher or Subscriber. Unless of course I am misunderstanding you.

    Would work if the resource object was added as a driver set object and packaged there though. Not perfect, but good enough.

    I'd agree, whilst we could write a service driver to unpack the resource object, IMHO it'd be overkill, and as you say, could be the source of sleepless nights! :eek:
  • jimgoodall wrote:

    > Not sure how you'd make that work with an IDV level package though as a
    > DirXML-Resource objects can only be contained in a Driver, Driver Set,
    > Library, Publisher or Subscriber. Unless of course I am
    > misunderstanding you.


    Create new library at tree level, e.g. "Schema Extensions"m then create
    resource of content type "text/ text" inside. Create tree level package, add
    the resource to it and make tha package a dependency to the driver/driverset
    packages that rely on this schema extension. I'd probably create one package
    per aux class.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • Thank you sir!

    Again, I had not considered adding a library outside of the driver set :)
  • On 7/5/2018 10:24 AM, jimgoodall wrote:
    >
    > Thanks - I hadn't considered using a resource object. More elegant than
    > forgetting to deploy the schema ;)
    >
    > Not sure how you'd make that work with an IDV level package though as a
    > DirXML-Resource objects can only be contained in a Driver, Driver Set,
    > Library, Publisher or Subscriber. Unless of course I am
    > misunderstanding you.
    >
    > Would work if the resource object was added as a driver set object and
    > packaged there though. Not perfect, but good enough.
    >
    > I'd agree, whilst we could write a service driver to unpack the resource
    > object, IMHO it'd be overkill, and as you say, could be the source of
    > sleepless nights! :eek:


    Consider doing indexes you want added as well as an LDIF?

    I would do it as Driver Set level, even though logically it should be
    IDV level. But really who has more than one Driver Set these days anyway.


  • On 7/5/2018 10:52 AM, Lothar Haeger wrote:
    > jimgoodall wrote:
    >
    >> Not sure how you'd make that work with an IDV level package though as a
    >> DirXML-Resource objects can only be contained in a Driver, Driver Set,
    >> Library, Publisher or Subscriber. Unless of course I am
    >> misunderstanding you.

    >
    > Create new library at tree level, e.g. "Schema Extensions"m then create
    > resource of content type "text/ text" inside. Create tree level package, add
    > the resource to it and make tha package a dependency to the driver/driverset
    > packages that rely on this schema extension. I'd probably create one package
    > per aux class.


    In Lothars case, I agree with the one package per aux class, but I think
    I still might include a single consolidated case.

    I.e. If my package had a Grooup and User support set of packages, then I
    certainly would split up the schema extensions. But if it is one set of
    schema changes, I would just do one resource for simplicity.


  • Geoffrey Carman wrote:

    > But really who has more than one Driver Set these days anyway.


    But really, what would make a driverset package better (in any way) than a tree
    package?

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • On 7/5/2018 2:21 PM, Lothar Haeger wrote:
    > Geoffrey Carman wrote:
    >
    >> But really who has more than one Driver Set these days anyway.

    >
    > But really, what would make a driverset package better (in any way) than a tree
    > package?


    Nothing. But if it is awkward or out of 'sight' outside the driverset
    to use an IDV package, a driver set package should be fine as well.

    Both ways work perfctly well.


  • geoffc;2483537 wrote:
    On 7/5/2018 10:24 AM, jimgoodall wrote:
    >
    > But really who has more than one Driver Set these days anyway.


    You would be surprised...
Reply Children