Hi Community !
Currently working on EEM Policies - I need to restrict access to job details properties (like the command, machine, etc...) to users thru EEM. Documentation says : the as-job policy of the autosys instance will be applied. Users must have the read access to be allowed to access to all properties. Else, the job will be listed, but only a few properties will be listed.
First - i created an as-job policy (deny) for all the resources R12.* on my autosys instance, for a specific test identity. The as-job policy has been tested using the autosys client installed on the aai server :
--------------------------------------------------------
$ autosec_test JOB foobar R -usr ltual
Enter password:
CAUAJM_W_10417 Job Read Access Denied!
CAUAJM_W_10438 Explicit Deny Policy: "R12.* DENY TESTING for ltual"
CAUAJM_W_10440 Class: as-job Resource: R12.foobar User: ltual Access: read
CAUAJM_W_10442 Time: 1733825068 Delegator: None
CAUAJM_I_60216 Security check FAILED.
--------------------------------------------------------
Now, i suppose that the Autosys API must be configured on the scheduler object for this mechanic to work. The application server will apply the instance security policies for this specific instance...
Docs refers to the following prerequisites:
Prerequisites
-
The AutoSys client must be installed on the AAI server.
-
A 32-bit Java JDK must be set as default on the PATH environment variable of the AAI server.
If Java is running with 64-bit, a 32-bit Java must be set in addition to the 64-bit Java that the JAVA_HOME environment variable points to.
-
If AAI does not run directly from the install directory, set an environment variable called JAWS_HOME with the path to the AAI install directory.
The first one is obviously done. (note: during installaton process, i selected the system [not installing the embedded 64b jre one]).
The 32 bits jdk prerequisite seems outdated and suspicious. Is it an historical entry from the 11.3.6 32 bit autosys client era ? Or is it also mandatory for v12.(0|1) 64 bit cli binaries?
The third one is gibberish. What does "If AAI does not run directly from the install directory" mean ?
i checked the process envvars - AAI server was started from its application directory, and then the process chdir to the jboss directory....
$ sudo strings /proc/917018/environ | grep PWD
OLDPWD=/opt/aai
PWD=/opt/aai/jboss
CSAM_SOCKADAPTER, CASHCOMP, AUTOSYS_INSTALL_LOCATION envvar are also set, meaning /etc/profile.CA was sourced before jaws starts...
Anyway, with only the first prerequisite established. Testing the Autosys Api connection - Tells that there an error, but no error message.
2024-12-10 11:19:44,819 INFO [AutosysSessionHandler] SUCCESS: Testing autosys connection with 'ujo_' table prefix
2024-12-10 11:19:44,824 INFO [SchedulersService] Testing Auxiliary Connection with Host: t0asr12mgr.bo.itsgroup.com and Port: 9000
2024-12-10 11:19:45,073 WARN [AutosysApi] Autosys API error:
(note that the virtual port 9000 is the relevant "aux port").
[ltual@t0aai] WorkloadAutomationAE $ env |grep AUTO
AUTOSERV=R12
AUTOUSER=/opt/CA/WorkloadAutomationAE/autouser.R12
AUTOSYS=/opt/CA/WorkloadAutomationAE/autosys
AUTOSYS_INSTALL_LOCATION=/opt/CA/WorkloadAutomationAE
[ltual@t0aai] WorkloadAutomationAE $ egrep "^AutoServerPort" $AUTOUSER/config.$AUTOSERV
AutoServerPort=9000
So, i'm stalled. Does anybody have the autosys api working ok ? How did you do ?
L.