topic Re: copyobjects change target name in Administration and Deployment

copyobjects change target name

Ebele — Thu, 25 Jul 2013 13:38:01 GMT

Hi,

Is it possible to change the target name of an object when you copy a metadata object using the copyobjects util in SASPlatformObjectFramework?

For instance, when you copy a Application Server Context from /System/Servers to the same location, you get "Copy of" in the name of the new Application Server Context:

The command:

"C:\Program Files\SASHome\SASPlatformObjectFramework\9.3\copyobjects.exe" -host "xxx" -user="sasadm@saspw" -password="xxx" -port=51000 -domain DefaultAuth -objects "/System/Servers/_POV_(ApplicationServer)" -target "/System/Servers/"

Kind regards,

Ebele

Re: copyobjects change target name

jakarman — Thu, 25 Jul 2013 16:11:19 GMT

Hi ebele,

Copying Application Server Contexts will probably technical working as copy option, only..
You are introducing a lot of possible issues if you want to add additonal appservers this way.
That are:

- Missing OS files (they will be created with the Deployment wizzard.

- Conflicting port number issues.

- Possible broken missing associations to .....

When needing a new appserver context it would be better to use the deployment wizard and plan ports.
For the SASwork question, this day, I have put all references in. As expecting the need for additional app-servers.

Copy SP definition with related SP processes can be copied to an other location and set up with a different App-server context with the copy.

Re: copyobjects change target name

Ebele — Fri, 26 Jul 2013 06:56:51 GMT

Hi Jaap,

We have approx. 10-15 application server contexts defined for authorization purposes. The corresponding OS files are created by scripts, including the security on these files.

Of course you can create a application server interactively using the management console, but since there are 10 levels, this is quite a bit of clickwork.

One approach would be to create all applicition server in one lev and promote them to next. You can use the -subprop file to dynamically change settings f.i. port numbers.

The most easiest way is to create one template "Application Server Context" and copy this. But then you manually need to change the names (or write a sas program to do this) of the copied metadataobjects, since I can't see a way to have copyobjects.rexx doing this...

Ebele

Re: copyobjects change target name

jakarman — Fri, 26 Jul 2013 11:16:33 GMT

Ebele,

I am reading "copyobjects.rexx", I position the environment as z/OS (hopefully 64-bit). It will mean RACF, HFS, BPXAS, bound libraries (z/OS classic 3390) DB2 etc. A lot of users must be there, as there are 10 levels and 15 appservers. Knowing you I could have a idea... With this sizing it makes a lot sense to have all kind of procedures for maintenance, configuration and support being scripted. The advantages:

- avoiding manual errors .

- the scripting can be use as the documentation of the change process.

- in case of migrations the scripting can serve as central point to rebuild to a new design. (yes: NO SMU usage)

We agree about that. That means:

- leaving aside (not using) the SMC and SDW for that kind of work and replace that with scritps as applicable.

- better conformation to normal IT "best practices" and Standard of Good Practice - Wikipedia, the free encyclopedia

- It is not conform the approach that people of SAS institute are commonly claiming it should be implemented.

What do we have:

- You must have implemented a version of user-import and synchronisation macros.

SAS(R) 9.4 Intelligence Platform: Security Administration Guide (User Import Macros)

That is User-identity management without SMC

- With 9.3 copying more with metadata became possible, yes the -subprop file.

SAS(R) 9.4 Intelligence Platform: System Administration Guide (Using the Batch Import Tool)

With this promotion and ship and also parts of configuration can be automated.

- With own build programs in Java .Net and SAS it is possible to update the metadatabase.

This part is documented but not extensively. It is sayin you can build your own SMC functionality as you like.

SAS(R) 9.4 Open Metadata Interface: Reference and Usage

New in 9.4

- more batch interfaces are coming,

SAS(R) 9.4 Intelligence Platform: Security Administration Guide (About the Batch Tools for Metadata Authorization)

I tried to automated some configurations steps as you wanted, it stopped for political issues.
As a schema for ports is needed I have put that with applicationnames in a table like registration. (macro-list like)

From that point I generated a lot of neede code for interactive called processes or for bach like ones or configfiles to be uploaded to a operational location (segregated in dtap/changeproces).

Your proposal of -subpro file usage.

I could think of one generating all variations of -subprop filecontents.

Than by calling a batch-script referencing a named combination to a -subpropfile will do the job.

Jaap

Re: copyobjects change target name

ronan — Fri, 26 Jul 2013 14:30:46 GMT

Hi Ebele,

I think Jaap is right : the copyobject utility (and the SMC Package Export/Impot Wizard as well) shall put you into trouble if you attempt to use it in order to replicate Application Servers :

using the SDW looks more apropriate.

See the following note to help you through the complete process :

43276 - Adding an application server to an existing SAS® Intelligence Platform configuration

This is a robust method we have used many times (EBI 9.2, VDD 9.2 & 9.3).

Be careful, also ; Step 18 in the note sometimes does not prove effective if you specify a new account other than SASSRV (tested with SDW 9.2TS2M3 on Linux x64).

As Jaap said, the SMC Server Assistant cannot create the corresponding phyical "sasconfig" content on the application server. There are however some implementations

which do not need any of this content for special purpose.

For instance, we have a EBI / DI platform installed on the same (dual) machines.

Machine no1 Metadata/MidTier : 2 SASCONFIG root directories with two MD Servers (a) & (c)

a) "8561" MD server for storing BI content

-- multiple Application Contexts with their own dedicated Object Spawner + STP, Wk Space, OLAP server

c) "8562" MD server alongside for storing ETL content separately.

-- the same Application Contexts + Object Spawners + Wk Space, DATA Step Batch Server (for DIS job deployment)

Machine no2 AppServer/OLAP : 1 SASCONFIG root directoy

b) multiple Application Contexts with their own dedicated Object Spawner Directories & Scripts

1st stage : BI Application Contexts (a) & (b) have been installed with SDW replay mode

2nd stage : ETL "8562" MD Server created with the same credentials accounts/passwords (sasadm@saspw, sastrust@saspw, sassrv etc.) used with the 8561 BI Server

3rd stage : ETL Application Contexts objects (c) have been installed manually in Metadata only with the SMC Server Plug-in assistant

When a ETL developer launches a workspace session on the 8562 DI Server platform, the ETL Object Spawner he uses communicates with the BI Spawer daemon running on the server

with the sastrust@saspw account 'as if' the request was coming from the 8561 server (SAS Object Spawner daemons in 9.2 do not verify that the lauching request comes from an identified MD

server once the sastrust account uses the same password stored in the metadataConfig.xml, it seems) .

conclusion : In this special case, yes you can associate multiple metadata servers references with single physical directories & daemon

What's the purpose of all this ? Keeping BI & ETL users + metadata strictly apart and minimizing the number of SAS Daemons server-side. Replicating Object Spawners specifically for the ETL instance

would have been tedious and costly to maintain (new ports numbers etc.). Since ETL & BI servers are accessing the same physical Data, it is not necessary.

Ronan

Re: copyobjects change target name

jakarman — Fri, 26 Jul 2013 15:39:20 GMT

Ronan,
That are good additions. I could add the following on sassrv and the StoredProcess Part.
The need to avoid using a generic sassrv is mostly a result of the business requirement to have a well secured enviroment.

Running everything by sassrv is a possible backdoor for hackers intended and unintended. The bisecag (and others) is filled with cautions to have your hostlayer controls (security) well defined. The SP-s are running by a dedicated key that is needing host acces.

It is following: Category:Principle - OWASP

This key for the SP must be defined as login at the "general servers" group.

Sounds strange, it is how it works. You can login with a group.

SAS(R) 9.3 Intelligence Platform: Security Administration Guide (How Logins Are Used)

Knowing that corrections afterwards are more easy to do and test for the SP functionality.

Re: copyobjects change target name

Ebele — Tue, 30 Jul 2013 07:52:58 GMT

Hi,

I didn't expect this kind of discussion, when I dropped the question about the copyobjects utility 🙂
We strive to have standardized installations and configurations on all levs, including all customized metdata: groups, roles, application servers. To achieve this, we script and automate as much as possible.
Installations and configurations are manufactured in a infrastructural development environment and promoted to the target environment:Dev,Test,Prod1,Prod2,Demo, etc...all z/os 64 bit.
There are many improvements in 9.4 in this area, but even in 9.4, I can't find any documenation on the copyobjects utility (except /?).
I guess I need to write a sas program and change the name of the logical server definitions with the METADATA_SETATTR function....

Kind regards,
Ebele

Re: copyobjects change target name

ronan — Tue, 30 Jul 2013 11:41:49 GMT

Hi Ebele,

There are many ways to skin a cat, of course. At my office, we have sucessfully implemented a large EBI/DI 9.2 Linux platform deployed in several environments like yours using the SDM -record/replay features.

This is the standard method to install SAS Application Context in a BI platform as far as I know. I am not even sure that

using the PlatFormObject Framework utilities like copyobjects is supported by SAS. You might ask

SAS technical support to validate your choice.

Beginning in SAS 9.3, in addition to the SDM, you can use the SMC export/import package with system objects like

Application Contexts servers; however, it is unlikely to copy also the physical components server-side. It can help you

migrating the metadata part only.

Paul Homes' excellent blog had an entry about one of these PlatForm Object Framewor utilities ("makefolder") :

SAS Platform Object Framework MakeFolder Metadata Utility - platformadmin.com

If you're interested in replicating a full environment, you may also consider using SDM change hostname features or

the SMU utility :

SAS(R) 9.3 Intelligence Platform: System Administration Guide, Second Edition

There is no unique recipe for implementing a BI platform, but to ensure the integrity of my installments I'd rather use standard methods since I am very cautious.

Hope this helps

Ronan