vh/NetAlertX
1
0
Fork 0
mirror of https://github.com/jokob-sk/NetAlertX.git synced 2025-12-07 09:36:05 -08:00
Code Issues Actions Packages Projects Releases Wiki Activity

ntfy disable cert #1117, initial nics work #724

Browse Source
This commit is contained in:
jokob-sk
2025-07-12 15:40:08 +10:00
parent 7980554924
commit 6f536f9952
35 changed files with 539 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/DATABASE.md
View File

@@ -39,6 +39,8 @@
| `devSourcePlugin` | Source plugin that discovered the device. | `ARPSCAN` |
| `devCustomProps` | [Custom properties](./CUSTOM_PROPERTIES.md) related to the device. The value is a base64-encoded JSON object. | `PHN2ZyB...` |
| `devFQDN` | Fully qualified domain name. | `raspberrypi.local` |
| `devParentRelType` | The type of relationship between the current device and it's parent node. By default, selecting `nic` will hide it from lists. | `nic` |
| `devReqNicsOnline` | If all NICs are required to be online to mark teh current device online. | `0` |
To understand how values of these fields influuence application behavior, such as Notifications or Network topology, see also:

21
docs/UPDATES.md
View File

@@ -1,14 +1,14 @@
# Docker Update Strategies to upgrade NetAlertX
> [!WARNING]
> For versions prior to `v25.6.7` upgrade to version `v25.5.24` first (`docker pull ghcr.io/jokob-sk/netalertx:25.5.24`) as later versions don't support a full upgrade. Alternatovelly, devices and settings can be migrated manually, e.g. via [CSV import](./DEVICES_BULK_EDITING.md).
> For versions prior to `v25.6.7` upgrade to version `v25.5.24` first (`docker pull ghcr.io/jokob-sk/netalertx:25.5.24`) as later versions don't support a full upgrade. Alternatively, devices and settings can be migrated manually, e.g. via [CSV import](./DEVICES_BULK_EDITING.md).
This guide outlines approaches for updating Docker containers, usually when upgrading to a newer version of NetAlertX. Each method offers different benefits depending on the situation. Here are the methods:
- Manual: Direct commands to stop, remove, and rebuild containers.
- Dockcheck: Semi-automated with more control, suited for bulk updates.
- Watchtower: Fully automated, runs continuously to check and update containers.
- Portainer: Setup depending, mostly manual with UI.
- Portainer: Manual with UI.
You can choose any approach that fits your workflow.
@@ -122,13 +122,10 @@ This assumes you're using Portainer to manage Docker (or Docker Swarm) and want
2. Go to **"Containers"** in the left sidebar.
3. Find the container you want to update, click its name.
4. Click **"Recreate"** (top right).
5. ✅ **Tick**:
* **Pull latest image** (this ensures Portainer fetches the newest version from Docker Hub or your registry).
5. **Tick**: _Pull latest image_ (this ensures Portainer fetches the newest version from Docker Hub or your registry).
6. Click **"Recreate"** again.
7. Wait for the container to be stopped, removed, and recreated with the updated image.
---
### 4.2 For Docker Swarm Services
If you're using Docker Swarm (under **"Stacks"** or **"Services"**):
@@ -137,14 +134,16 @@ If you're using Docker Swarm (under **"Stacks"** or **"Services"**):
2. Select the stack managing the container.
3. Click **"Editor"** (or "Update the Stack").
4. Add a version tag or use `:latest` if your image tag is `latest` (not recommended for production).
5. Click **"Update the Stack"**.
> ⚠ Portainer will not pull the new image unless the tag changes OR the stack is forced to recreate.
5. Click **"Update the Stack"**. ⚠ Portainer will not pull the new image unless the tag changes OR the stack is forced to recreate.
6. If image tag hasn't changed, go to **"Services"**, find the service, and click **"Force Update"**.
## Summary
- Manual: Ideal for individual or critical updates.
- Dockcheck: Suitable for controlled, mass updates.
- Watchtower: Fully automated, best for continuous deployment setups.
| Method | Type | Pros | Cons |
|------------|--------------|----------------------------------|------------------------------|
| Manual | CLI | Full control, no dependencies | Tedious for many containers |
| Dockcheck | CLI Script | Great for batch updates | Needs setup, semi-automated |
| Watchtower | Daemonized | Fully automated updates | Less control, version drift |
| Portainer | UI | Easy via web interface | No auto-updates |
These approaches allow you to maintain flexibility in how you update Docker containers, depending on the urgency and scale of the update.