Apache Strongmail


Error

You must log in or register to view this page

Apache Strongmail is an Apache httpd‑based Strongmail webserver component identified by its strongmail configuration (strongmail-server.conf). It is designed to help developers and operators manage and deliver Strongmail email services, enabling versioned discovery of the running Strongmail webserver instance for inventory and monitoring.

Platforms supported by the pattern

The pattern discovers Apache Strongmail deployments on the UNIX system.

Software instance triggers

The following table gives details about the pattern triggers:

Pattern

Triggers on

Cmd

Argument

ApacheStrongmail

process 

bin/httpd$

(?i)-(?:d|f) *[^ ]*/strongmail(?:\b|_)

Software Instance type attributes

The pattern in this module sets the following attributes:

Pattern name

SI type

ApacheStrongmail

Apache Strongmail Webserver

Simple identification mappings

The following components or processes are identified by using the simple identity mappings that map the product's known processes:

Name

Command

Apache Strongmail Webserver

(?i)strongmail(?:_|/|-|)?(\d(?:[\-_\.]?\d+)*)

Versioning

The pattern first attempts path versioning: it inspects the process command path and its arguments for a strongmail configuration reference and then applies the regex:
(?i)strongmail(?:_|/|-|)?(\d(?:[\-_\.]?\d+)*)
Explanation:
(?i)            Case-insensitive.
strongmail      Literal product name.
(?:_|/|-|)?     Optional single separator: underscore, slash, hyphen, or nothing.
(               Capturing group for the version:
  \d            Initial digit.
  (?:[\-_\.]?\d+)*  Zero or more sequences of an optional separator (- _ .) followed by one or more digits.
)

Captured group examples:
strongmail1                -> 1
strongmail_1.2.3           -> 1.2.3
strongmail/2-5_7           -> 2-5_7
strongmail-10.11.12        -> 10.11.12
strongmail_3_4-5.6         -> 3_4-5.6

Normalization (internal convention): separators -, _, multiple are typically converted to '.' when forming the Software Instance version string (e.g. 2-5_7 -> 2.5.7). If no normalization logic runs, raw captured text is used.

Fallback:
If no path match is found, the pattern scans the package list for entries containing strongmail and applies the same regex to the package name to derive the version.

Failure:
If neither path nor package yields a match, the Software Instance is created without a version attribute.

Edge cases:
- strongmail.conf (no digits) => no version.
- strongmail_v1.2 (v breaks pattern) => no version unless alternate package source contains a valid form.

Package versioning

Package Versioning
After path versioning fails (no path_version), the pattern invokes:
check_packages := [regex'(?i)^strongmail-apache'];
full_version := DiscoveryFunctions.packageVersioning(host, check_packages);

Mechanism:
1. Iterate host package inventory.
2. Find first package name matching ^strongmail-apache (case-insensitive).
3. Extract its version component (implementation in DiscoveryFunctions). Typically strips name and architecture, returning the upstream version-release.

Examples (package name -> full_version):
strongmail-apache-1.2.3-4.el7.x86_64    -> 1.2.3-4.el7
strongmail-apache-2.0.0.x86_64          -> 2.0.0
strongmail-apache-10.11.12-1            -> 10.11.12-1

Product version derivation:
product_version := first match of (\d+(?:\.\d+)?) in full_version.
Examples:
full_version: 1.2.3-4.el7    -> product_version: 1.2
full_version: 2.0.0          -> product_version: 2.0
full_version: 10.11.12-1     -> product_version: 10.11

If the regex fails (rare), product_version defaults to full_version.

Failure:
If no matching package is found, full_version remains empty and no version attributes are set on the Software Instance.

Testing

Test SI creation on Linux host

Test SI creation and package versioning on Linux host

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Discovery content reference