Using Pode as a Service in Windows, MacOSX and Linux (Systemd)

.github/workflows/ci-powershell.yml

@@ -51,8 +51,18 @@ jobs:
     - name: Run Pester Tests
       shell: powershell
       run: |
-        [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
-        Invoke-Build Test
+        # Check if the runner is in debug mode
+        if ($env:RUNNER_DEBUG -eq '1') {
+            $debug = $true
+        } else {
+            $debug = $false
+        }
+
+        if ($debug) {
+            Invoke-Build Test -PesterVerbosity Diagnostic
+        } else {
+            Invoke-Build Test
+        }
 
     - name: Build Packages
       shell: powershell

.github/workflows/ci-pwsh7_5.yml

@@ -71,7 +71,18 @@ jobs:
     - name: Run Pester Tests
       shell: pwsh
       run: |
-        Invoke-Build Test
+        # Check if the runner is in debug mode
+        if ($env:RUNNER_DEBUG -eq '1') {
+            $debug = $true
+        } else {
+            $debug = $false
+        }
+
+        if ($debug) {
+            Invoke-Build Test -PesterVerbosity Diagnostic
+        } else {
+            Invoke-Build Test
+        }
 
     - name: Build Packages
       shell: pwsh

.github/workflows/ci-pwsh_lts.yml

@@ -71,7 +71,18 @@ jobs:
     - name: Run Pester Tests
       shell: pwsh
       run: |
-        Invoke-Build Test
+        # Check if the runner is in debug mode
+        if ($env:RUNNER_DEBUG -eq '1') {
+            $debug = $true
+        } else {
+            $debug = $false
+        }
+
+        if ($debug) {
+            Invoke-Build Test -PesterVerbosity Diagnostic
+        } else {
+            Invoke-Build Test
+        }
 
     - name: Build Packages
       shell: pwsh

.github/workflows/ci-pwsh_preview.yml

@@ -71,7 +71,18 @@ jobs:
     - name: Run Pester Tests
       shell: pwsh
       run: |
-        Invoke-Build Test
+        # Check if the runner is in debug mode
+        if ($env:RUNNER_DEBUG -eq '1') {
+            $debug = $true
+        } else {
+            $debug = $false
+        }
+
+        if ($debug) {
+            Invoke-Build Test -PesterVerbosity Diagnostic
+        } else {
+            Invoke-Build Test
+        }
 
     - name: Build Packages
       shell: pwsh

.gitignore

@@ -268,6 +268,8 @@ examples/PetStore/data/PetData.json
 packers/choco/pode.nuspec
 packers/choco/tools/ChocolateyInstall.ps1
 docs/Getting-Started/Samples.md
+examples/HelloService/*_svcsettings.json
+examples/HelloService/svc_settings
 
 # Dump Folder
 Dump

Pode.sln

@@ -7,6 +7,8 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "src", "src", "{41F81369-868
 EndProject
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Pode", "src\Listener\Pode.csproj", "{772D5C9F-1B25-46A7-8977-412A5F7F77D1}"
 EndProject
+Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "PodeMonitor", "src\PodeMonitor\PodeMonitor.csproj", "{A927D6A5-A2AC-471A-9ABA-45916B597EB6}"
+EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution
 		Debug|Any CPU = Debug|Any CPU

docs/Hosting/PortsBelow1024.md

@@ -0,0 +1,55 @@
+# Using Ports Below 1024
+
+#### Introduction
+
+Traditionally in Linux, binding to ports below 1024 requires root privileges. This is a security measure, as these low-numbered ports are considered privileged. However, running applications as the root user poses significant security risks. This article explores methods to use these privileged ports with PowerShell (`pwsh`) in Linux, without running it as the root user.
+There are different methods to achieve the goals.
+Reverse Proxy is the right approach for a production environment, primarily if the server is connected directly to the internet.
+The other solutions are reasonable after an in-depth risk analysis.
+
+#### Using a Reverse Proxy
+
+A reverse proxy like Nginx can listen on the privileged port and forward requests to your application running on an unprivileged port.
+
+**Configuration:**
+
+* Configure Nginx to listen on port 443 and forward requests to the port where your PowerShell script is listening.
+* This method is widely used in web applications for its additional benefits like load balancing and SSL termination.
+
+#### iptables Redirection
+
+Using iptables, you can redirect traffic from a privileged port to a higher, unprivileged port.
+
+**Implementation:**
+
+* Set up an iptables rule to redirect traffic from, say, port 443 to a higher port where your PowerShell script is listening.
+* `sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080`
+
+**Benefits:**
+
+* This approach doesn't require changing the privileges of the PowerShell executable or script.
+
+#### Using `setcap` Command
+
+The `setcap` utility can grant specific capabilities to an executable, like `pwsh`, enabling it to bind to privileged ports.
+
+**How it Works:**
+
+* Run `sudo setcap 'cap_net_bind_service=+ep' $(which pwsh)`. This command sets the `CAP_NET_BIND_SERVICE` capability on the PowerShell executable, allowing it to bind to any port below 1024.
+
+**Security Consideration:**
+
+* This method enhances security by avoiding running PowerShell as root, but it still grants significant privileges to the PowerShell process.
+
+#### Utilizing Authbind
+
+Authbind is a tool that allows a non-root user to bind to privileged ports.
+
+**Setup:**
+
+* Install Authbind, configure it to allow the desired port, and then start your PowerShell script using Authbind.
+* For instance, `authbind --deep pwsh yourscript.ps1` allows the script to bind to a privileged port.
+
+**Advantages:**
+
+* It provides a finer-grained control over port access and doesn't require setting special capabilities on the PowerShell binary itself.