Operations and Upgrade Guide¶
This guide covers install layout, service behavior, and practical upgrade examples.
Recommended Directory Layout¶
Windows¶
C:\Rustinel\
├── rustinel.exe
├── config.toml
├── rules\
│ ├── sigma\
│ ├── yara\
│ └── ioc\
└── logs\
Linux¶
/opt/rustinel/
├── rustinel
├── config.toml
├── rules/
│ ├── sigma/
│ ├── yara/
│ └── ioc/
└── logs/
Use absolute paths in config.toml once you move beyond the default repo layout.
Working Directory Rules¶
config.tomlis loaded from the current working directory.- Relative rule and log paths resolve from that same directory.
- Windows services often start in
C:\Windows\System32; use absolute paths there. - Linux supervisors should also use absolute paths for predictable upgrades and restarts.
Windows Service Lifecycle¶
Rustinel includes built-in Windows service management commands:
.\rustinel.exe service install
.\rustinel.exe service start
.\rustinel.exe service stop
.\rustinel.exe service uninstall
Important behavior:
service installregisters the current executable path with the Service Control Manager.- Replacing the binary in the same directory is fine.
- Moving the binary to a new directory requires
service uninstallfollowed byservice install. - Service mode does not consume interactive CLI flags; configure it with
config.tomlandEDR__...environment variables.
Linux Runtime Model¶
Rustinel does not currently ship Linux service-management commands. Common deployment patterns are:
- Run it directly in a root shell for testing
- Wrap it in
systemd - Run it under another process supervisor
The binary itself is the same foreground application in all cases:
Example systemd Unit¶
Save as /etc/systemd/system/rustinel.service:
[Unit]
Description=Rustinel EDR Agent
After=network.target
[Service]
Type=simple
ExecStart=/opt/rustinel/rustinel run
WorkingDirectory=/opt/rustinel
Restart=on-failure
RestartSec=5s
User=root
[Install]
WantedBy=multi-user.target
Enable and start:
sudo systemctl daemon-reload
sudo systemctl enable rustinel
sudo systemctl start rustinel
sudo systemctl status rustinel
Because config.toml is loaded from WorkingDirectory, use absolute paths for all rules and log directories in that file when running under systemd.
Upgrade Examples¶
Windows: Replace Binary In Place¶
If the service already points to the final directory:
Set-Location C:\Rustinel
.\rustinel.exe service stop
Copy-Item C:\Staging\rustinel.exe .\rustinel.exe -Force
.\rustinel.exe service start
Windows: Move To A New Install Directory¶
Set-Location C:\OldRustinel
.\rustinel.exe service stop
.\rustinel.exe service uninstall
New-Item -ItemType Directory -Path D:\Rustinel -Force | Out-Null
Copy-Item C:\Staging\rustinel.exe D:\Rustinel\rustinel.exe -Force
Copy-Item C:\Staging\config.toml D:\Rustinel\config.toml -Force
Copy-Item C:\Staging\rules D:\Rustinel\rules -Recurse -Force
Set-Location D:\Rustinel
.\rustinel.exe service install
.\rustinel.exe service start
Linux: Rebuild From Source And Restart¶
Example with systemd as the supervisor:
cd /opt/src/rustinel
git pull
cargo build --release
sudo install -m 0755 ./target/release/rustinel /opt/rustinel/rustinel
sudo systemctl restart rustinel
Linux: Release Binary Upgrade¶
Linux: eBPF-Only Iteration¶
When you only changed ebpf/, rebuild the object and run with the override path:
cd /opt/src/rustinel/ebpf
cargo +nightly build --release --bin rustinel-ebpf
cp target/bpfel-unknown-none/release/rustinel-ebpf rustinel-ebpf.o
cd /opt/src/rustinel
sudo env RUSTINEL_EBPF_OBJECT=$PWD/ebpf/rustinel-ebpf.o ./target/release/rustinel run
This is useful for development because it avoids rebuilding the full userspace binary after every eBPF-only change.
Safe Upgrade Checklist¶
- Back up
config.tomland your customrules/. - Keep log and alert directories outside ephemeral build directories.
- Replace the binary.
- Restart the process or service.
- Confirm new startup logs in
rustinel.log.<date>. - Trigger a known benign rule such as the bundled
whoamiSigma rule.