Feature & Enhancement Suggestions for DynMHS

[Sunser]

Feature & Enhancement Suggestions for DynMHS
Hello, thank you for developing and maintaining DynMHS. I've been testing it to manage policy-based routing for multiple dynamic interfaces (using DHCP/IPv6 RA) and it largely fulfills its core purpose. During my evaluation, I identified a few areas where improvements would significantly enhance usability, flexibility, and reliability in production scenarios.

1. Granular Control over ip rule Priority
   Current Situation:
   DynMHS automatically creates ip rule entries for source-based routing. However, the priority for these rules is assigned automatically by the kernel or the tool, offering no user control.

Suggestion:
Extend the NETWORK configuration syntax to include an optional third field for specifying the rule priority.

Proposed Syntax:

# Current: NETWORK="interface:table_id"
# Proposed: NETWORK="interface:table_id:rule_priority"

NETWORK="eth0:1:32001"
NETWORK="eth1:2:32002"

Expected Behavior:
The command generated would be ip rule add from <interface_ip> lookup <table_id> priority <rule_priority>. If the priority field is omitted, DynMHS can fall back to its current automatic assignment.

2. Implement a reload Command for Dynamic Configuration Updates
   Current Situation:
   Any modification to the configuration file (like adding or removing a NETWORK entry) requires a full service restart (systemctl restart dynmhs). This process tears down all existing rules and routes before re-establishing them, causing momentary network disruption for all managed interfaces.

Suggestion:
Implement a SIGHUP handler or a dedicated command (e.g., systemctl reload dynmhs or dynmhs --reload-config) to re-read the configuration file and apply differences.

Expected Behavior:

The reload action compares the current active state with the new configuration.

It removes rules and routes only for interfaces no longer present in the config.

It adds rules and routes only for newly added interfaces.

Interfaces whose configuration hasn't changed remain completely untouched, ensuring zero disruption for them.

3. Support Multi-Instance Mode for Per-Interface Independence
   Current Situation:
   DynMHS runs as a single service managing all configured interfaces. A configuration error, a reload for one interface, or a crash affects the entire routing setup.

Suggestion:
Offer an optional multi-instance mode where a separate, isolated DynMHS process can be launched for each interface.

Proposed Usage:

dynmhs --loglevel=0 --network="eth0:1:32001" --logfile=/var/log/dynmhs/eth0.log
dynmhs --loglevel=0 --network="eth1:2:32002" --logfile=/var/log/dynmhs/eth1.log

Benefits:
Isolation & Stability: A problem in one instance's config or process only affects that specific interface.

Independent Management: Instances can be stopped, started, or reloaded individually without impacting others.

Simplifies Reload Logic: This model inherently solves the "targeted reload" need mentioned in point 2.

4. Enhance Package Distribution via GitHub Releases
   Current Situation & Appreciation:
   We appreciate that official package repositories already exist, such as the Launchpad PPA for Ubuntu and the COPR repository for Fedora. This greatly simplifies installation for users of those distributions.

Suggestion:
To complement the existing channels and reach a wider audience, we suggest also providing pre-built packages directly on the GitHub Releases page for each version.

Target Packages to Add on GitHub Releases:

Standalone .deb and .rpm packages.

A generic .tar.gz archive containing binaries, documentation, and sample configurations.

Expected Benefits:

Broader Accessibility: Users of other Linux distributions (or specific versions not covered by the main repositories) can install DynMHS without building from source.

Simplified Testing & Deployment: It allows for quicker testing of new releases and facilitates integration into custom or containerized environments where adding an external repository is not ideal.

Centralized Download Hub: GitHub Releases becomes a single, versioned location for all binary artifacts, improving project visibility and download convenience.

Summary of Benefits
These improvements aim to make DynMHS:

More Predictable: Through manual ip rule priority control.

More Robust & Operational: By enabling non-disruptive configuration updates via reload.

More Modular & Fault-Tolerant: Through optional multi-instance support.

More Accessible: By expanding package distribution options.

Thank you for considering these suggestions. I believe they would make an already useful tool even more powerful for advanced networking setups.