Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Kommentar: Corrections

Contents

Inhalt
maxLevel3
absoluteUrltrue
excludeContents

Introduction

The configuration of Apache Karaf osgi-runner itself as well as the configuration of all installed OSGi bundles are in files in osgi-runner's etc directory.

...

The configuration file htpasswd.d/osgi-htpaswd.htpasswd specifies one or more karaf usersosgi-runner users in the domain osgi, like this snippet from the default configuration shows:

Codeblock
titleusersosgi.propertieshtpasswd
collapsetrue
osgi:$apr1$a2pxQc6X$fc.1CQ0UO.rkhXwKXdWeZ.
karaf:$apr1$eQJ1yFFI$q/orCEOYMpcoplIBAxpcg/

...

We very strongly recommend to change the password to something worthy of being called a password, or restrict administrative access vectors by other means (Firewall, ReverseProxy font, ...).

In typical environment the authentication will be changed from JAAS to an auth backend like LDAP/ADS.

Optional: Configuring the embedded SSH Server

As mentioned Karaf , osgi-runner comes with an embedded SSH server.

The port and address to listen on can be configured in the configuration file  etc/conf.d/gogo-ssh.properties. The major lines of the default configuration are:

Codeblock
titleorg.apache.karaf.shell.cfggogo-ssh.properties
collapsetrue
# location of the authorized_keys file
gogo.ssh.etcPath = ${osgi.runner.etcPath}/sshd.d
# port and address to listen on
gogo.ssh.port = 8101
gogo.ssh.host = localhost

...

Optional: Configuring the osgi-runner HTTP Port

Our Karaf osgi-runner package comes with an integrated HTTP server in the form of the Felix HTTP bundle, based on Jetty (which is unfortunate because it is not as configurable as one might wish). There is also a newer approach org.ops4j.pax.web, but for now we stick with Felix.

Felix' HTTP port is configured in the configuration file file adm.d/org.apache.felix.http.cfg which looks like this:

...

Therefore it is common practice to “hide” the application server (in our case Karafosgi-runner) behind a legacy Web server like Apache, IIS, nginx acting as a reverse proxy and to only pass-through known sub URLs.

...

There are two approaches to disallow remote access to Karafosgi-runner's HTTP engine, both can be used together:

osgi-runner should only listen on localhost (127.0.0.1), which is achieved by adding the setting org.apache.felix.http.host=127.0.0.1 to org.apache.felix.http.cfg, see also http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html for more configuration options of the embedded HTTP server.

Alternatively, the local firewall should not allow remote access to osgi-runner's HTTP port.

...

If a Firewall is used (recommended) these are the common ports of our Karaf osgi-runner installations.

We usually open these ports to the network:

  • 80, for a minimal web host redirecting to the https counterpart

  • 443, for a web host acting as reverse proxy to the MDA server

  • Windows: 3389, remote desktop, for maintenance of Windows hosts, restricted to trusted hosts or networks

  • Linux: 22, ssh, DOS-protected by fail2ban

We usually do not open these ports:

  • 8080 or 8081 or other, osgi-runner HTTP server port

  • 8101, Karaf osgi-runner SSH server port

Bundle PIDs

...

As most web apps, config-managers require the user to identify and authenticate himself.

In Karaf osgi-runner they usually authenticate against the embedded JAAS authentication engine, which by default provides an admin user karaf / karaf in the domain osgi.

Our configuration UIs support other configuration mechanisms, but when bootstrapping an installation only JAAS is available.

Therefore access to the web-based config-managers should be restricted using the mechanisms of either a firewall, or a legacy web server acting as reverse proxy in front of karafosgi-runner, or the config-managers' own configuration.

...

Create and configure the configuration PID org.clazzes.login.ldap, for details see  https://confluence.clazzes.org/display/LOGIN/org.clazzes.login.ldap

Key
Value
Remarks
defaultDomainDOMAINReplace DOMAIN by your Windows domain name.
domain.DOMAIN.controllerUriads://domain.topLookup of LDAP server in DNS via _ldap._tcp SRV entries, adapt to your DNS domain name, replace DOMAIN in key name by your Windows domain name.
domain.DOMAIN.authMethodbindAdsBind to LDAP using ADS conventions, replace DOMAIN in key name by your Windows domain name.

After having set up the ADS connection you should be able to sign on the the given ADS domain using the login form given at http://localhost:8081/http-login/org.clazzes.login.ldap/login

...

Configure the configuration PID org.clazzes.dojo.configmanager and change the following settings:

Key
Value
Remarks
loginMechanismorg.clazzes.login.ldapChange to the above configured login adapter
allowedUser.2DOMAIN/<myuser><myuser> is the Windows logon name of an allowed user. Once LDAP access is working, you may also overwrite the allowedUser.1 entry. Replace DOMAIN by your Windows domain name.
allowedUser.3, AllowedUser.4,...DOMAIN/<yetanotheruser>

You may add additional entries allowedUser.3, AllowedUser.4,...
Replace DOMAIN by your Windows domain name.