Knowledge Partner
Knowledge Partner
223 views

Packaging PRD's between UA versions?

I just got a chance to do my first Provisioning package. Finding all
sorts of interesting things. (Only 2 bugs reported so far! Woo Hoo!)

But here is a question. I built my PRD/DAL/GCV package for UA 4.01,
which is against a Base package of 1.05.

Now I know the customer is going upgrade to UA 4.02 at some patch level,
which means a UA Base package of 2.2.0 or 2.30.

Well for testing a bug I found, I tried to apply my package against
those UA base packages, and got a pop up warning that I built against UA
4.01 and this is UA 4.02 and not allowed.

So what is my actual path, as a Package Developer, to build on Version X
of the UA, and then provide an updated version for UA Version X+1 and
later X+2?

I need to apply my package to driver config, and be able to use it
against a newer or older version as well.

Hmm, can I build a UA 1.05, add my package, then upgrade it to 2.20 and
then rebuild my package? Will that work?

Looks like it. Hmm, that is slightly less than obvious.
Labels (1)
0 Likes
5 Replies
Knowledge Partner
Knowledge Partner

Re: Packaging PRD's between UA versions?

On 10/21/2013 1:55 PM, Geoffrey Carman wrote:
> I just got a chance to do my first Provisioning package. Finding all
> sorts of interesting things. (Only 2 bugs reported so far! Woo Hoo!)
>
> But here is a question. I built my PRD/DAL/GCV package for UA 4.01,
> which is against a Base package of 1.05.
>
> Now I know the customer is going upgrade to UA 4.02 at some patch level,
> which means a UA Base package of 2.2.0 or 2.30.
>
> Well for testing a bug I found, I tried to apply my package against
> those UA base packages, and got a pop up warning that I built against UA
> 4.01 and this is UA 4.02 and not allowed.
>
> So what is my actual path, as a Package Developer, to build on Version X
> of the UA, and then provide an updated version for UA Version X+1 and
> later X+2?
>
> I need to apply my package to driver config, and be able to use it
> against a newer or older version as well.
>
> Hmm, can I build a UA 1.05, add my package, then upgrade it to 2.20 and
> then rebuild my package? Will that work?
>
> Looks like it. Hmm, that is slightly less than obvious.


Actually that does not work. So if I build a UA 1.05 driver (AKA UA
4.01 driver). Apply my PRD/DAL/GCV package to it. Cool.

Now I want to rebuild it for UA 2.2.0 (Aka UA 4.02). So I upgrade my
1.05 package to 2.2.0.

Then I go make version 2.2.0 of my package to match. Ok, so far so good.

Now I try to upgrade my custom package from 0.0.1 to my 2.2.0 and get
teh same error.

So it seems like the only way is to go destroy the package, by removing
the content from my 0.0.1 package, and then add it back into the 2.2.0
package one by one. Which destroys the old package. I suppose I could
make 0.0.2 of the old package and destroy that one?

That seems like there ought to be an easier way...


0 Likes
Knowledge Partner
Knowledge Partner

Re: Packaging PRD's between UA versions?

On 10/21/2013 2:18 PM, Geoffrey Carman wrote:
> On 10/21/2013 1:55 PM, Geoffrey Carman wrote:
>> I just got a chance to do my first Provisioning package. Finding all
>> sorts of interesting things. (Only 2 bugs reported so far! Woo Hoo!)
>>
>> But here is a question. I built my PRD/DAL/GCV package for UA 4.01,
>> which is against a Base package of 1.05.
>>
>> Now I know the customer is going upgrade to UA 4.02 at some patch level,
>> which means a UA Base package of 2.2.0 or 2.30.
>>
>> Well for testing a bug I found, I tried to apply my package against
>> those UA base packages, and got a pop up warning that I built against UA
>> 4.01 and this is UA 4.02 and not allowed.
>>
>> So what is my actual path, as a Package Developer, to build on Version X
>> of the UA, and then provide an updated version for UA Version X+1 and
>> later X+2?
>>
>> I need to apply my package to driver config, and be able to use it
>> against a newer or older version as well.
>>
>> Hmm, can I build a UA 1.05, add my package, then upgrade it to 2.20 and
>> then rebuild my package? Will that work?
>>
>> Looks like it. Hmm, that is slightly less than obvious.

>
> Actually that does not work. So if I build a UA 1.05 driver (AKA UA
> 4.01 driver). Apply my PRD/DAL/GCV package to it. Cool.
>
> Now I want to rebuild it for UA 2.2.0 (Aka UA 4.02). So I upgrade my
> 1.05 package to 2.2.0.
>
> Then I go make version 2.2.0 of my package to match. Ok, so far so good.
>
> Now I try to upgrade my custom package from 0.0.1 to my 2.2.0 and get
> teh same error.
>
> So it seems like the only way is to go destroy the package, by removing
> the content from my 0.0.1 package, and then add it back into the 2.2.0
> package one by one. Which destroys the old package. I suppose I could
> make 0.0.2 of the old package and destroy that one?
>
> That seems like there ought to be an easier way...


And I am having a ton of problems getting it to work.

This is really not fun. Other parts of packaging, you can just change
the requirements. Here it is buried in there somewhere where we have no
access to modify it.

0 Likes
Knowledge Partner
Knowledge Partner

Re: Packaging PRD's between UA versions?

On 10/30/2013 7:31 AM, Geoffrey Carman wrote:
> On 10/21/2013 2:18 PM, Geoffrey Carman wrote:
>> On 10/21/2013 1:55 PM, Geoffrey Carman wrote:
>>> I just got a chance to do my first Provisioning package. Finding all
>>> sorts of interesting things. (Only 2 bugs reported so far! Woo Hoo!)
>>>
>>> But here is a question. I built my PRD/DAL/GCV package for UA 4.01,
>>> which is against a Base package of 1.05.
>>>
>>> Now I know the customer is going upgrade to UA 4.02 at some patch level,
>>> which means a UA Base package of 2.2.0 or 2.30.
>>>
>>> Well for testing a bug I found, I tried to apply my package against
>>> those UA base packages, and got a pop up warning that I built against UA
>>> 4.01 and this is UA 4.02 and not allowed.
>>>
>>> So what is my actual path, as a Package Developer, to build on Version X
>>> of the UA, and then provide an updated version for UA Version X+1 and
>>> later X+2?
>>>
>>> I need to apply my package to driver config, and be able to use it
>>> against a newer or older version as well.
>>>
>>> Hmm, can I build a UA 1.05, add my package, then upgrade it to 2.20 and
>>> then rebuild my package? Will that work?
>>>
>>> Looks like it. Hmm, that is slightly less than obvious.

>>
>> Actually that does not work. So if I build a UA 1.05 driver (AKA UA
>> 4.01 driver). Apply my PRD/DAL/GCV package to it. Cool.
>>
>> Now I want to rebuild it for UA 2.2.0 (Aka UA 4.02). So I upgrade my
>> 1.05 package to 2.2.0.
>>
>> Then I go make version 2.2.0 of my package to match. Ok, so far so good.
>>
>> Now I try to upgrade my custom package from 0.0.1 to my 2.2.0 and get
>> teh same error.
>>
>> So it seems like the only way is to go destroy the package, by removing
>> the content from my 0.0.1 package, and then add it back into the 2.2.0
>> package one by one. Which destroys the old package. I suppose I could
>> make 0.0.2 of the old package and destroy that one?
>>
>> That seems like there ought to be an easier way...

>
> And I am having a ton of problems getting it to work.
>
> This is really not fun. Other parts of packaging, you can just change
> the requirements. Here it is buried in there somewhere where we have no
> access to modify it.
>


One thing for sure, your filter/schema map is not converting
DirXML-ADContext to an AD attribute, so you send to the shim this
snippet at least:

<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.0.1.1">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add cached-time="20131030093319.025Z" class-name="user"
dest-dn="CN=Gaikwad\, Dinesh
D,OU=Users,OU=HAVIGS-NorthAmerica,DC=dev-perseco,DC=com"
event-id="wdhidm01#20131030093319#1#1:8ac104d5-605d-4c85-e0b5-d504c18a5d60"
qualified-src-dn="O=havigs\OU=Users\OU=Internal\OU=NA\CN=dgaikwad"
src-dn="\HAVIGS-DEV\havigs\Users\Internal\NA\dgaikwad"
src-entry-id="58551" timestamp="1383125599#2">
<add-attr attr-name="sAMAccountName">
<value naming="true" timestamp="1382106357#42"
type="string">dgaikwad</value>
</add-attr>
<add-attr attr-name="co">
<value timestamp="1382106357#18" type="string">India</value>
</add-attr>
<add-attr attr-name="company">
<value timestamp="1382106357#22" type="string">SecurView</value>
</add-attr>
<add-attr attr-name="DirXML-ADContext">
<value timestamp="1382111291#6" type="string">CN=Gaikwad\,
Dinesh D,OU=Users,OU=HAVIGS-NorthAmerica,DC=dev-perseco,DC=com</value>



And the AD driver shim responds:

[10/30/13 04:33:19.660]:ActiveDirectory_Internal :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20111208_120000"
instance="\HAVIGS-DEV\havigs\Services\IDM\Havigs-DriverSet\ActiveDirectory_Internal"
version="3.5.16">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status
event-id="wdhidm01#20131030093319#1#1:8ac104d5-605d-4c85-e0b5-d504c18a5d60"
level="error" text1="schema violation" type="app-general">
<message>Attribute 'DirXML-ADContext' is not in the application
schema</message>

<xds-path>/nds/input/add[@event-id='wdhidm01#20131030093319#1#1:8ac104d5-605d-4c85-e0b5-d504c18a5d60'][@class-name='user'][@src-dn='\HAVIGS-DEV\havigs\Users\Internal\NA\dgaikwad'][@dest-dn='CN=Gaikwad\,
Dinesh
D,OU=Users,OU=HAVIGS-NorthAmerica,DC=dev-perseco,DC=com'][@class-name='user']</xds-path>
</status>
</output>
</nds>


Predictably:
<message>Attribute 'DirXML-ADContext' is not in the application
schema</message>

Why, yes, that is true.

That attr should probably NOT be in the filter at all. Is this an IDM
3.6 config that was upgraded at any point? (Not the shim, but rather
the policies? Via Packages, later configs (Pre IDM4) or whatever?)

The meaning of the DirXML-ADContext attribute changed between versions.
And the fact you have a full DN in it, means likely that you changed
it even further.

See how easy that is from the trace? (Kidding of course, learning to
read the trace is the hard part. Once you get used to it, like
everything else, it is easy).


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Packaging PRD's between UA versions?

Hey Geoffrey Carman, on 30.10.2013 12:31:01, you wrote:

> On 10/21/2013 2:18 PM, Geoffrey Carman wrote:
>
> And I am having a ton of problems getting it to work.
>
> This is really not fun. Other parts of packaging, you can just
> change the requirements. Here it is buried in there somewhere where
> we have no access to modify it.


When you do get it to work, please share your notes.
Had a customer who had heaps of problems going from 4.0.1 to 4.0.2 in
part because of problems with custom UA packages. Ended with a SR to
fix their broken UA.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Knowledge Partner
Knowledge Partner

Re: Packaging PRD's between UA versions?

On 10/30/2013 8:32 AM, Alex McHugh wrote:
> Hey Geoffrey Carman, on 30.10.2013 12:31:01, you wrote:
>
>> On 10/21/2013 2:18 PM, Geoffrey Carman wrote:
>>
>> And I am having a ton of problems getting it to work.
>>
>> This is really not fun. Other parts of packaging, you can just
>> change the requirements. Here it is buried in there somewhere where
>> we have no access to modify it.

>
> When you do get it to work, please share your notes.


Seriously? Of all people, you would say that to me? 🙂 I am insulted,
insulted i say! 🙂

> Had a customer who had heaps of problems going from 4.0.1 to 4.0.2 in
> part because of problems with custom UA packages. Ended with a SR to
> fix their broken UA.


I suppose I should try exporting the PRD to a XML config and see if I
can import it then. At least in principle then, if I needed too, I
could muck with the XML and change any requirements.

I get that stuff changes between 4.0, 4.01, and 4.02 User Apps, but
there has to be a migration/upgrade path that works... And works with
packaging.




0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.