Skip to content

Standalone Configuration

ScriptLauncher Daemon

The following parameters must be adjusted in the configuration file bin/oneclickext.props:

oneclickext.mls.primary: <Main Location Server>
oneclickext.mls.backup: <Backup Location Server>
oneclickext.ss.host: <Main SpectroSERVER>
oneclickext.ss.user: <Spectrum User>
oneclickext.rmi.port: <RMI Port>
oneclickext.rmi.connport: <RMI Connection Port>

Configure as service

If the daemon is to be managed as a Windows service, the service must first be set up. The jsl64.ini file generated by the script must be copied to the bin directory and the service set up. When updating, the service must first be uninstalled as an administrator in the bin directory:

jsl64 -remove

The setup can then be performed:

jsl64 -install

The following parameters can be checked in jsl64.ini beforehand:

wrkdir=C:/DcsSL/DICOS/OneClickExt/bin
jrepath=C:/DcsSL/Java/jre
jvmtype=server

For jvmtype, you must check the name of the directory containing the jvm.dll file: server or client. This directory is located in the Java bin directory.

OneClickExt can then be started as a service:

net start oneclickextd

Navigate to the bin directory and execute the installSystemdFilesUser.sh script as root or with a user with sudo rights. To uninstall, execute the uninstallSystemdFilesUser.sh script accordingly.

Setting up users

Users can be created via the GUI or via the file webswing.config (see also 2.1 Post-installation).

Setting up authentication via LDAP

WebSwing does not support LDAP authentication out of the box. To authenticate via LDAP anyway, it must be enabled in Tomcat. Since a user logged in to Tomcat is unfortunately not transmitted to WebSwing, this must be implemented via a Custom Security Module. The entire authentication process can then be achieved via configuration.

LDAP configuration

The roles admin and scriptlauncher are used to control access to the different pages. Users are then assigned to the groups:

Standalone installation

Tomcat configuration

The configuration in Tomcat consists of two parts:

  • Setting up the LDAP realm
  • Setting up the security constraint for each web app

Tomcat LDAP realm

The realm is set up globally in the file <tomcat>/conf/server.xml. To do this, the existing configuration is commented out and replaced with a new one:

<Realm className="org.apache.catalina.realm.JNDIRealm"
  connectionName="cn=spectrum,dc=da,dc=dicos,dc=de"
  connectionPassword="<password>"
  connectionURL=“ldap://<Server>:<Port>”
  userPattern="cn={0},ou=users,dc=da,dc=dicos,dc=de"
  roleBase="ou=groups,dc=da,dc=dicos,dc=de"
  roleName="cn"
  roleSearch="(member={0})" />

Tomcat Security Constraint

For each web app, the permitted roles must be defined for the desired pages. In our case, we have the following pages (web apps):

http://localhost:8080
http://localhost:8080/sl

For http://localhost:8080, a redirect to http://localhost:8080/sl is set up. To do this, the file <tomcat>/webapps/ROOT/index.jsp is replaced by an index.jsp with the following content:

<% response.sendRedirect(“/sl”); %>

WebApp /sl

Access to /sl is restricted to the scriptlauncher and admin roles. To do this, the file <tomcat>/webapps/sl/WEB-INF/web.xml must be extended as follows:

<?xml version="1.0" encoding="UTF- 8 "?>
<web-app>
  ...
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Scriptlauncherpage</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>admin</role-name>
      <role-name>scriptlauncher</role-name>
    </auth-constraint>
  </security-constraint>
  <security-role>
    <role-name>scriptlauncher</role-name>
  </security-role>
  <security-role>
    <role-name>admin</role-name>
  </security-role>
  <login-config>
    <auth-method>BASIC</auth-method>
  </login-config>
</web-app>