ucsd-anf / puppet-antelope Goto Github PK

The README is missing documentation for some of the newer defined types.

From the BRTT man page notes_licensing(5):

A special program, ald_proxy, is part of the standard distribution and is included to provide a license proxy mechanism. This program, like the other licensing programs, is statically linked, does not require an Antelope license to run and does not depend in any way on the Antelope distribution and can therefore be run on any host computer with or without an installed Antelope distribution or license. ald_proxy provides an internet proxy for connections to external Antelope license servers. This would be used in a very secure environment in which most of the Antelope host computers had no access to the outside internet. ald_proxy would be run on a machine outside of the firewall on port 6599 and would connect to license servers in the normal manner using all of the configuration environment variables. Hosts inside the firewall would connect to ald_proxy through the use of the ANTELOPE_LICENSE_SERVER_ADDRS environment variable which would be set to the proxy host address. A single hole in the firewall to the proxy host computer would be the only necessary outside connection.

Clients can also use an Antelope parameter file called license_env.pf to control the ANTELOPE_LICENSE_SERVER_ADDRS variable.

The ald_proxy process does not need to run inside of an rtexec process, and really doesn't need a site.pf, so it's a prime candidate for creating it's own service instance.

For clients, there probably ought to be some hooks to control license_env.pf at the distribution level, similar to the antelope::versioned_site_pf defined type that ships with this module already.

The stock antelope init script as provided by BRTT makes the assumption that multiple rtexec instances on a server are not tightly coupled - that is, any of the rtexec instances can be started stopped independently of one another. Based on this assumption, the init script starts and stops all rtexec instances in parallel.

This leads to problems when a process in one rtexec instance runs processes that have hard-dependencies on a process supervised by another rtexec process. An example of this is:

• system 1, named admin, runs the Datascope Database ID Server, dbids
• system 2, named project, runs database writing processes, such as orb2db, orb2dbt, orb2wf

What happens is that the admin rtexec will stop dbids before the database writing processes have a chance to finish their write operations. Once dbids stops responding, orb2db and friends will wait indefinitely until it returns. The project rtexec will wait a timeout interval and then forcibly terminate (SIGKILL) orb2db, resulting in database gaps.

A workaround would be to combine the admin and project realtime systems, and make use of rtexec's Shutdown_order parameter, but there are situations where that isn't desirable.

One solution is to add an option to the current SYSV init script that makes it start and stop systems sequentially. Another would be to do this using SystemD on EL7 systems. See GH-2 for the EL7 work.

This module needs to be made compatible with Puppet 4. Various fixups are required due to language changes, including replacing all empty string checks with undef. The puppet-lint checker doesn't really get all of these, just variable assignments.

This module needs to work on CentOS 7 / RedHat Enterprise Linux (RHEL) 7.

The biggest change that this will entail is converting the system init script from SYSV format to the SystemD manifest format.