AdvancedLinuxInstallation

Advanced Linux Installation

Here are the best practices to install JEM the BEE on a Linux OS. In the next sections we will see how to install the JEM under a Linux operative system having in mind security concerns. We will also see how it will be possible to set up the JEM to run batch with "su" (switch user) functionality. We suppused you have already installed a database for the JEM

Following are the command to use:

• Login as super user or switch to super user

	# sudo su -

• Create a jem user with home under /opt folder and assigne it to the jem group

	# groupadd -f jem
	# useradd -m -d /opt/jem -g jem jem

• Create the jemhome and add it to the environment variable

	# mkdir /opt/jem/jemhome

modify the /opt/jem/.bash_profile file as follow PATH=$HOME/bin:$PATH JEM_HOME=$HOME/jemhome export PATH export JEM_HOME

	# source .bash_profile

• Check if a jvm is installed otherwise set up one

	# java -version

if the java -version command does not identify a JVM install a jdk 1.6+ or 1.7+

• Install JEM

As jem user do the following:

	cp jem.zip /opt/jem/jem.zip

	cd /opt/jem/

	unzip jem.zip

	# chmod -R 770 jemhome

	# chmod -R 777 jemhome/bin
	# find jemhome -type d -exec chmod 775 {} \;

customize the /opt/jem/jemhome/config/create_node.properties install an environment:

	# cd /opt/jem/jemhome/bin

	# jem_create_node.sh -properties ../config/create_nodes.properties

give only to the jem user the possibility to inspect environment:

	# chmod -R 700 jemhome/[ENV_NAME]

now you should be able to start the jem node:

	# jem.sh console

if everithing is fine you can installed the JEM as a daemon under the OS

	# jem.sh install

to start the daemon:

    # jem.sh start

Security Considerations

The following considarion are valid if you choose to esecute the JEM not as a root (discorage choise), but using a "jem" user. Those considaration are valid only for nic (Linux expecially).

Global File System (GFS) security

If the GFS is rapresented by a NAS (and this could be most of the case), in which is possible to set up access security level, the most effective security configuration will be the following:

    # chown -R jem:jem ${path_to_gfs}
    # chmod -R 770 ${path_to_gfs}
    # chmod -R 700 ${path_to_gfs_persistence}

The persistence folder should be set to 700 because there you will find security information like keystores (environment and users certificates one).

Switch User

In a Unix-like system, typically, are defined specific users with specific privileges and configurations in order to perform certain processes, which depend on the installed applications. Consequently, the execution of a batch for these applications is greatly facilitated if executed with the appropriate user. On Unix-like systems, the JEM can be configured at the node level in order to use the technique of the sudo command to impersonate specific users, in which case, all batches are executed with the user specified level job (in the JCL ). Recall that this user does not always coincide with the user who submitted the job (see surrogate).

There are several ways to configure the sudo command, the more effective is the following:

    # sudo visudo

adding the following line at the bottom of the file, it gives to the jem user the possibility to impersonate the user $ {user} for any command

    jem ALL = (${user}) NOPASSWD: ALL

finally adding the following line enables the jem to run the sudo even when it is started as a process and not from the console.

    Defaults:jem !requiretty

In this way, for each user who should be able to submit a job, you need to edit the sudoers. Of course, you can enter groups or lists of users, in accordance with the level of security that you want to apply to the platform. At the time of the job execution, the JEM node will execute the following command:

    sudo -n -u ${user} -i ${command}

where ${command} is the start command of the job (ANT, SpringBatch, etc...) In addition, it is also necessary that each user authorized to perform jobs on the node is also a member of the same group to which the jem user belong. This is because the job reads from (and writes to) GFS. Be carefull that if you want to run job execution with "su" functionality you must tell it to JEM via configuration. In detail you must set in the jem-env.xml (under the GFS/persistence/TEST-Env/config folder) the following (that means you want to perform su command):

 <factories>
    <factory className="org.pepstock.jem.ant.AntFactory">
       <properties>
          <!-- abilitate su functionality -->
          <property name="jem.switch.user" value="true"/>
       </properties>
    </factory>
    <factory className="org.pepstock.jem.springbatch.SpringBatchFactory">
       <properties>
          <!-- abilitate su functionality -->
          <property name="jem.switch.user" value="true"/>
       </properties>
    </factory>
</factories>