You need to install the bsa client on the target. I don’t recommend this. why do you need to run blcli inside the blpackage ? what are you trying to do ? it may make more sense to use the webservices (rest/soap) interface to bsa instead. for that you would not need anything installed on the target other than something that can make ws calls – eg wget, curl, perl, etc.
Well, my client had the idea to set server custom attributes inside a blpackage that deploys also content. I saw in one of your posts that might be possible so I was just curios to see how this works.
They're using NSH script jobs for setting the attributes and then deploy jobs for installing sw. This is done using a batch job.
I tried to reduce the complexity by only having one job, for a blpackage, that includes also blcli calls.
i would look at web service calls and not the blcli - trying to install the gui across all your severs just to run blcli calls makes no sense to me.
one thing you might want to think about is that i believe most properties are resolved when the job starts to run, so unless your commands are pulling the property values during the deploy that they need, you won't be able to set a value in the blpackage then reference it like ??TARGET.BLAH?? - you'd need a ws call to resolve BLAH on the current server.
yes, it seems more logical to have web services that will trigger dedicated jobs
your assumption was right, the values are to be set, not read
I'll close this post here, I've got the answer I needed
thank you Bill