Merge remote-tracking branch 'origin/main' into hardening

docs/API.md

@@ -59,6 +59,8 @@ http://<server>:<GRAPHQL_PORT>/
 * [Events](API_EVENTS.md) – Device event logging and management
 * [Sessions](API_SESSIONS.md) – Connection sessions and history
 * [Settings](API_SETTINGS.md) – Settings
+* Messaging:
+    * [In app messaging](API_MESSAGING_IN_APP.md) - In-app messaging
 * [Metrics](API_METRICS.md) – Prometheus metrics and per-device status
 * [Network Tools](API_NETTOOLS.md) – Utilities like Wake-on-LAN, traceroute, nslookup, nmap, and internet info
 * [Online History](API_ONLINEHISTORY.md) – Online/offline device records

docs/API_MESSAGING_IN_APP.md

@@ -0,0 +1,173 @@
+# In-app Notifications API
+
+Manage in-app notifications for users. Notifications can be written, retrieved, marked as read, or deleted.
+
+---
+
+### Write Notification
+
+* **POST** `/messaging/in-app/write` → Create a new in-app notification.
+
+  **Request Body:**
+
+  ```json
+  {
+    "content": "This is a test notification",
+    "level": "alert"   // optional, ["interrupt","info","alert"]  default: "alert"
+  }
+  ```
+
+  **Response:**
+
+  ```json
+  {
+    "success": true
+  }
+  ```
+
+#### `curl` Example
+
+```bash
+curl -X POST "http://<server_ip>:<GRAPHQL_PORT>/messaging/in-app/write" \
+  -H "Authorization: Bearer <API_TOKEN>" \
+  -H "Accept: application/json" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "content": "This is a test notification",
+    "level": "alert"
+  }'
+```
+
+---
+
+### Get Unread Notifications
+
+* **GET** `/messaging/in-app/unread` → Retrieve all unread notifications.
+
+  **Response:**
+
+  ```json
+  [
+    {
+      "timestamp": "2025-10-10T12:34:56",
+      "guid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
+      "read": 0,
+      "level": "alert",
+      "content": "This is a test notification"
+    }
+  ]
+  ```
+
+#### `curl` Example
+
+```bash
+curl -X GET "http://<server_ip>:<GRAPHQL_PORT>/messaging/in-app/unread" \
+  -H "Authorization: Bearer <API_TOKEN>" \
+  -H "Accept: application/json"
+```
+
+---
+
+### Mark All Notifications as Read
+
+* **POST** `/messaging/in-app/read/all` → Mark all notifications as read.
+
+  **Response:**
+
+  ```json
+  {
+    "success": true
+  }
+  ```
+
+#### `curl` Example
+
+```bash
+curl -X POST "http://<server_ip>:<GRAPHQL_PORT>/messaging/in-app/read/all" \
+  -H "Authorization: Bearer <API_TOKEN>" \
+  -H "Accept: application/json"
+```
+
+---
+
+### Mark Single Notification as Read
+
+* **POST** `/messaging/in-app/read/<guid>` → Mark a single notification as read using its GUID.
+
+  **Response (success):**
+
+  ```json
+  {
+    "success": true
+  }
+  ```
+
+  **Response (failure):**
+
+  ```json
+  {
+    "success": false,
+    "error": "Notification not found"
+  }
+  ```
+
+#### `curl` Example
+
+```bash
+curl -X POST "http://<server_ip>:<GRAPHQL_PORT>/messaging/in-app/read/f47ac10b-58cc-4372-a567-0e02b2c3d479" \
+  -H "Authorization: Bearer <API_TOKEN>" \
+  -H "Accept: application/json"
+```
+
+---
+
+### Delete All Notifications
+
+* **DELETE** `/messaging/in-app/delete` → Remove all notifications from the system.
+
+  **Response:**
+
+  ```json
+  {
+    "success": true
+  }
+  ```
+
+#### `curl` Example
+
+```bash
+curl -X DELETE "http://<server_ip>:<GRAPHQL_PORT>/messaging/in-app/delete" \
+  -H "Authorization: Bearer <API_TOKEN>" \
+  -H "Accept: application/json"
+```
+
+---
+
+### Delete Single Notification
+
+* **DELETE** `/messaging/in-app/delete/<guid>` → Remove a single notification by its GUID.
+
+  **Response (success):**
+
+  ```json
+  {
+    "success": true
+  }
+  ```
+
+  **Response (failure):**
+
+  ```json
+  {
+    "success": false,
+    "error": "Notification not found"
+  }
+  ```
+
+#### `curl` Example
+
+```bash
+curl -X DELETE "http://<server_ip>:<GRAPHQL_PORT>/messaging/in-app/delete/f47ac10b-58cc-4372-a567-0e02b2c3d479" \
+  -H "Authorization: Bearer <API_TOKEN>" \
+  -H "Accept: application/json"
+```

docs/FIX_OFFLINE_DETECTION.md

@@ -31,10 +31,11 @@ To improve presence accuracy and reduce false offline states:
 
 ### ✅ Increase ARP Scan Timeout
 
-Extend the ARP scanner timeout to ensure full subnet coverage:
+Extend the ARP scanner timeout and DURATION to ensure full subnet coverage:
 
 ```env
 ARPSCAN_RUN_TIMEOUT=360
+ARPSCAN_DURATION=30
 ```
 
 > Adjust based on your network size and device count.

docs/HW_INSTALL.md

@@ -63,13 +63,28 @@ wget https://raw.githubusercontent.com/jokob-sk/NetAlertX/main/install/debian12/
 
 ## 📥 Ubuntu 24 (Noble Numbat)
 
+> [!NOTE]
+> Maintained by [ingoratsdorf](https://github.com/ingoratsdorf)
+
 ### Installation via curl
 ```bash
-curl -o install.ubuntu24.sh https://raw.githubusercontent.com/jokob-sk/NetAlertX/main/install/ubuntu24/install.ubuntu24.sh && sudo chmod +x install.ubuntu24.sh && sudo ./install.ubuntu24.sh
+curl -o install.sh https://raw.githubusercontent.com/jokob-sk/NetAlertX/main/install/ubuntu24/install.sh && sudo chmod +x install.sh && sudo ./install.sh
 ```
 
 ### Installation via wget
 
 ```bash
-wget https://raw.githubusercontent.com/jokob-sk/NetAlertX/main/install/ubuntu24/install.ubuntu24.sh -O install.ubuntu24.sh && sudo chmod +x install.ubuntu24.sh && sudo ./install.ubuntu24.sh
+wget https://raw.githubusercontent.com/jokob-sk/NetAlertX/main/install/ubuntu24/install.sh -O install.sh && sudo chmod +x install.sh && sudo ./install.sh
+```
+
+## 📥 Bare Metal - Proxmox
+
+> [!NOTE]
+> Use this on a clean LXC/VM for Debian 13 OR Ubuntu 24.
+> The Scipt will detect OS and build acordingly. 
+> Maintained by [JVKeller](https://github.com/JVKeller)
+
+### Installation via wget
+```bash
+wget https://raw.githubusercontent.com/jokob-sk/NetAlertX/main/install/proxmox/proxmox-install-netalertx.sh -O proxmox-install-netalertx.sh && chmod +x proxmox-install-netalertx.sh && ./proxmox-install-netalertx.sh
 ```

docs/PLUGINS_DEV.md

@@ -10,6 +10,9 @@ NetAlertX comes with a plugin system to feed events from third-party scripts int
 
 > (Currently, update/overwriting of existing objects is only supported for devices via the `CurrentScan` table.)
 
+> [!NOTE]
+> For a high-level overview of how the `config.json` is used and it's lifecycle check the [config.json Lifecycle in NetAlertX Guide](PLUGINS_DEV_CONFIG.md).
+
 ### 🎥 Watch the video:
 
 > [!TIP]

docs/PLUGINS_DEV_CONFIG.md

@@ -0,0 +1,146 @@
+## config.json Lifecycle in NetAlertX
+
+This document describes on a high level how `config.json` is read, processed, and used by the NetAlertX core and plugins. It also outlines the plugin output contract and the main plugin types.
+
+> [!NOTE]
+> For a deep-dive on the specific configuration options and sections of the `config.json` plugin manifest, consult the [Plugins Development Guide](PLUGINS_DEV.md).
+
+---
+
+### 1. Loading
+
+* On startup, the app core loads `config.json` for each plugin.
+* The `config.json` represents a plugin manifest, that contains metadata and runtime settings.
+
+---
+
+### 2. Validation
+
+* The core checks that each required settings key (such as `RUN`) for a plugin exists.
+* Invalid or missing values may be replaced with defaults, or the plugin may be disabled.
+
+---
+
+### 3. Preparation
+
+* The plugin’s settings (paths, commands, parameters) are prepared.
+* Database mappings (`mapped_to_table`, `database_column_definitions`) for data ingestion into the core app are parsed.
+
+---
+
+### 4. Execution
+
+* Plugins can be run at different core app execution points, such as on schedule, once on start, after a notification, etc. 
+* At runtime, the scheduler triggers plugins according to their `interval`.
+* The plugin executes its command or script.
+
+---
+
+### 5. Parsing
+
+* Plugin output is expected in **pipe (`|`)-delimited format**.
+* The core parses lines into fields, matching the **plugin interface contract**.
+
+---
+
+### 6. Mapping
+
+* Each parsed field is moved into the `Plugins_` database tables and can be mapped into a configured database table.
+* Controlled by `database_column_definitions` and `mapped_to_table`.
+* Example: `Object_PrimaryID → Devices.MAC`.
+
+---
+
+### 6a. Plugin Output Contract
+
+Each plugin must output results in the **plugin interface contract format**, pipe (`|`)-delimited values, in the column order described under [Plugin Interface Contract](PLUGINS_DEV.md)
+
+#### IDs
+
+  * `Object_PrimaryID` and `Object_SecondaryID` identify the record (e.g. `MAC|IP`).
+
+#### **Watched values (`Watched_Value1–4`)**
+
+  * Used by the core to detect changes between runs.
+  * Changes here can trigger **notifications**.
+
+#### **Extra value (`Extra`)**
+
+  * Optional, extra field.
+  * Stored in the database but **not used for alerts**.
+
+#### **Helper values (`Helper_Value1–3`)**
+
+  * Added for cases where more than IDs + watched + extra are needed.
+  * Can be made visible in the UI.
+  * Stored in the database but **not used for alerts**.
+
+#### **Mapping matters**
+
+  * While the plugin output is free-form, the `database_column_definitions` and `mapped_to_table` settings in `config.json` determine the **target columns and data types** in NetAlertX.
+
+---
+
+### 7. Persistence
+
+* Data is upserted into the database.
+* Conflicts are resolved using `Object_PrimaryID` + `Object_SecondaryID`.
+
+---
+
+### 8. Plugin Types and Expected Outputs
+
+Beyond the `data_source` setting, plugins fall into functional categories. Each has its own input requirements and output expectations:
+
+#### **Device discovery plugins**
+
+  * **Inputs:** `N/A`, subnet, or API for discovery service, or similar.
+  * **Outputs:** At minimum `MAC` and `IP` that results in a new or updated device records in the `Devices` table.
+  * **Mapping:** Must be mapped to the `CurrentScan` table via `database_column_definitions` and `data_filters`.
+  * **Examples:** ARP-scan, NMAP device discovery (e.g., `ARPSCAN`, `NMAPDEV`).
+
+#### **Device-data enrichment plugins**
+
+  * **Inputs:** Device identifier (usually `MAC`, `IP`).
+  * **Outputs:** Additional data for that device (e.g. open ports).
+  * **Mapping:** Controlled via `database_column_definitions` and `data_filters`.
+  * **Examples:** Ports, MQTT messages (e.g., `NMAP`, `MQTT`)
+
+#### **Name resolver plugins**
+
+  * **Inputs:** Device identifiers (MAC, IP, or hostname).
+  * **Outputs:** Updated `devName` and `devFQDN` fields.
+  * **Mapping:** Not expected.
+  * **Note:** Currently requires **core app modification** to add new plugins, not fully driven by the plugins’ `config.json`.
+  * **Examples:** Avahiscan (e.g., `NBTSCAN`, `NSLOOKUP`).
+
+#### **Generic plugins**
+
+  * **Inputs:** Whatever the script or query provides.
+  * **Outputs:** Data shown only in **Integrations → Plugins**, not tied to devices.
+  * **Mapping:** Not expected.
+  * **Examples:** External monitoring data (e.g., `INTRSPD`)
+
+#### **Configuration-only plugins**
+
+  * **Inputs/Outputs:** None at runtime.
+  * **Mapping:** Not expected. 
+  * **Examples:** Used to provide additional settings or execute scripts (e.g., `MAINT`, `CSVBCKP`).
+
+---
+
+### 9. Post-Processing
+
+* Notifications are generated if watched values change.
+* UI is updated with new or updated records.
+* All values that are configured to be shown in teh UI appear in the Plugins section.
+
+---
+
+### 10. Summary
+
+The lifecycle of `config.json` entries is:
+
+**Load → Validate → Prepare → Execute → Parse → Map → Persist → Post-process**
+
+Plugins must follow the **output contract**, and their category (discovery, specific, resolver, generic, config-only) defines what inputs they require and what outputs are expected.