Interlocks

Interlocks provide a mechanism for physical control of resources based on Colabmacs scheduling and policy decisions.

Interlocks may be installed in a variety of ways to prevent access to physical resources. Common configurations include:

• Interrupt equipment power
• Interrupt safety relays
• Interrupt keyboard or mouse signals
• Interrupt lid or door interlocks
• Interface with machine-specific enable/disable functions

The exact behavior depends on the hardware configuration and the resource it is connected to, and is outside the scope of this documentation. Colabmacs simply provides the ability to send commands and poll status from supported devices.

Interlocks are configured in:

Admin → Resources → Interlocks

Executive Summary

Interlocks extend Colabmacs from a scheduling and policy platform into physical infrastructure control.

When configured:

• Colabmacs initiates communication to the interlock device
• The device responds with current state information
• Administrators may manually invoke control actions
• The system periodically polls devices to update status

If an interlock cannot be reached:

• Bookings and session starts are not blocked
• Equipment may fail to activate depending on hardware configuration

Interlocks should therefore be deployed with proper network access and monitoring.

How Interlocks Work

Each interlock record represents a physical device accessible over the network.

Colabmacs:

1. Initiates communication to the configured hostname or IP
2. Sends control commands when required
3. Periodically polls the device to determine status
4. Updates the Interlock index and detail pages accordingly

Interlocks are polled:

• Periodically by the system
• When viewing the Interlock detail page
• When manually invoking actions
• State is cached for performance but may be refreshed on demand

Creating an Interlock

To create a new interlock:

1. Navigate to Admin → Interlocks
2. Click Create Interlock
3. Complete the configuration fields

Field Reference

Field	Description
Name	Internal display name
Hostname	Public-facing DNS name used by Colabmacs
Port	Network port (if applicable)
IP	Optional direct IP reference
Interlock Type	Defines supported command structure
Use HTTPS	Enables HTTPS communication
Allow Self Signed	Allows self-signed certificates
Pulse Mode	Enables pulse functionality if supported
Tags	Optional classification tags
Description	Internal documentation

Interlock Types are vendor-neutral abstractions. Additional types may be added over time as support expands.

Interlock Types

Colabmacs supports multiple interlock command structures.

Interlock Types define:

• How status is polled
• How enable/disable commands are issued
• Whether pulse functionality is supported

This page intentionally remains vendor-neutral. Refer to release notes for supported device types.

Pulse Mode

Pulse Mode is a manufacturer-specific capability available on some interlock devices.

When enabled:

• A pulse command can be issued instead of a persistent enable
• Pulse duration is configured on the interlock device itself
• Colabmacs triggers the pulse but does not control its duration

Pulse functionality is hardware dependent.

Interlock Index & Status

The Interlocks index displays:

• Current status
• Hostname
• Interlock type
• Relay information (if applicable)

Common status values:

Status	Meaning
ON	Device reports enabled state
OFF	Device reports disabled state
UNREACHABLE	Device could not be contacted

Status is updated through periodic polling and manual refresh actions.

Manual Controls

From the Interlock detail page, administrators can manually invoke:

• Poll
• Enable
• Disable
• Toggle
• Pulse (if supported)

These actions send immediate commands to the configured device.

Manual invocation is useful for:

• Testing configuration
• Troubleshooting network connectivity
• Verifying device response

Network Requirements

For interlocks to function, Colabmacs must be able to initiate communication to the interlock device.

This requires:

• A publicly resolvable DNS entry
• Controlled inbound access to a reverse proxy or gateway
• Optional but recommended SSL configuration

Overview

In order for the interlock solution to work, clients must allow inbound communication from the Colabmacs servers.

This is typically implemented using a reverse proxy.

General Setup

1. Host with nginx (or equivalent reverse proxy)
2. Control over DNS
3. SSL certificate (recommended)

DNS Entry

Each interlock has a public-facing DNS entry used by Colabmacs.

Example:

interlockHostName.clientdomain.tld 3600 IN A XXX.XXX.XX.XXX

This entry should resolve to the reverse proxy.

Sample nginx Configuration

HTTP Redirect Block

server {
    listen 80;
    server_name interlockHostName.clientdomain.tld;

    location / {
        return 301 https://$host$request_uri;
    }
}

HTTPS Reverse Proxy Block

server {
    listen 443 ssl http2;
    server_name interlockHostName.clientdomain.tld;

    ssl_certificate         <certificate_file>;
    ssl_certificate_key     <key_file>;
    ssl_trusted_certificate <chain_file>;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://internal_device_ip;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    access_log /var/log/nginx/interlock_access.log;
    error_log /var/log/nginx/interlock_error.log;
}

Access Control Example

allow 127.0.0.1;
allow 10.0.0.0/8;
allow XXX.XXX.XXX.XXX;
allow XXX.XXX.XXX.XXX;

deny all;

Replace IP addresses with the official Colabmacs host IPs.

Security Considerations

Warning

Interlocks expose infrastructure control endpoints. Proper network isolation is critical.

Recommended practices:

• Restrict access to Colabmacs IP addresses only
• Use HTTPS whenever possible
• Disable unused ports
• Log all access attempts
• Place devices behind a reverse proxy
• Avoid exposing devices directly to the public internet

Colabmacs does not require authentication credentials for supported interlocks. Network-level access control is therefore essential.

Best Practices

• Always test connectivity using the Poll action after configuration
• Validate enable/disable behavior before attaching to production resources
• Monitor for UNREACHABLE status conditions
• Document hardware wiring and relay behavior internally
• Ensure reverse proxy configurations are version-controlled

Interlocks bridge digital policy enforcement with physical control. Proper configuration ensures reliable and secure operation.