DEV Community: Christopher

Blocking Bing at Home with Pi-Hole (Without Breaking Edge)

Christopher — Sat, 21 Feb 2026 17:55:11 +0000

🚫 Blocking Bing at Home with Pi-hole (Without Breaking Edge)

Microsoft Bing has a habit of inserting itself into browsers, operating systems, and “helpful” search features — even when you didn’t ask for it.

This guide shows how to block Bing network-wide using Pi-hole, while still allowing Microsoft Edge, Windows Update, and sync features to work normally.

🧠 What This Guide Covers

Blocking Bing at the DNS level using Pi-hole
Preventing Bing reinjection in Microsoft Edge
Keeping Edge updates and Windows Update working
Optional hardening steps for privacy-focused setups

🛠 Prerequisites

A working Pi-hole instance
Pi-hole configured as the primary DNS for your network
Admin access to Pi-hole
Optional: Microsoft Edge installed on at least one client

1️⃣ Blocking Bing with Pi-hole (Network-Wide)

This blocks Bing for every device on your network — desktops, phones, tablets, smart TVs, etc.

🔒 Domains to Block

In Pi-hole Admin → Group Management → Domains → Blacklist, add the following:

bing.com www.bing.com api.bing.com bingapis.com www.bingapis.com c.bing.com th.bing.com www.msn.com ntp.msn.com

https://github.com/lancer1977/DataSeeds/blob/master/block_lists/bing.list

Why These Domains?

bing.com, api.bing.com → core search endpoints
c.bing.com, th.bing.com → tracking, suggestions, thumbnails
msn.com, ntp.msn.com → Bing-powered Edge new tab content

This combination stops:

Direct Bing searches
Address bar fallback searches
MSN news / trending reinjection

2️⃣ Domains You Should NOT Block

Blocking these will break Edge or Windows updates.

❌ Do NOT block:

edge.microsoft.com msedge.api.cdp.microsoft.com update.microsoft.com windowsupdate.microsoft.com

These are required for:

Edge updates
Extension installs
Profile sync
Windows Update

3️⃣ Restart Pi-hole DNS

After adding domains, restart DNS:

pihole restartdns

If clients cache DNS aggressively, flush client DNS as well.

Linux (systemd-resolved)
sudo resolvectl flush-caches
4️⃣ Configure Microsoft Edge to Stop Using Bing

You can keep Edge — you just need to disable its Bing hooks.

🔍 Set a Different Search Engine

Edge → Settings → Privacy, search, and services → Address bar and search

Set:

Search engine used in the address bar → DuckDuckGo (or Google)
Search on new tabs → Address bar
Address bar search engine suggestions → Off

🔕 Disable Bing Reinjection Features

Edge → Settings → Privacy, search, and services

Turn OFF:

Show me search and site suggestions using my typed characters
Show me personalized ads
Improve Microsoft products by sending optional diagnostic data
Search and service improvement

These settings are commonly used to route searches back to Bing.

5️⃣ Clean Up the Edge New Tab Page

Open a new tab → ⚙️ Settings

Set:

Layout → Focused
Content → Content off
Quick links → Off

This disables:

MSN news
Trending Bing searches
Sponsored tiles

6️⃣ (Optional) Extra Privacy Hardening
Block Microsoft Search Telemetry

Add these optionally if you want deeper privacy control:

self.events.data.microsoft.com
browser.events.data.microsoft.com

⚠️ This may reduce “smart” suggestions but does not break Edge.

7️⃣ Verifying It Works
Test DNS Resolution
ping bing.com

Expected result:

ping: bing.com: Name or service not known
Pi-hole Query Log
Open Query Log
Filter for bing

Requests should show Blocked (gravity)

✅ Result

Bing is blocked network-wide
Edge remains fully functional
Windows Update continues working
No browser extensions required
No per-device configuration needed

*Note: Made with the help of AI (I'm not this smart!)

Making an Ollama Mesh with Nginx

Christopher — Fri, 06 Feb 2026 18:14:53 +0000

Load Balancing Ollama with NGINX: Handling Long GPU Jobs and Dead Nodes Gracefully

Running Ollama on a single machine is easy. Running multiple Ollama instances across your LAN—and surviving GPU stalls, reboots, or long outages—is where things get interesting.

This post walks through a production-grade NGINX upstream configuration for Ollama, explains how it behaves under load, and shows how to tune it when one machine might be down for minutes or hours.

Why Ollama Needs Special Load Balancing

Ollama workloads are not typical web traffic:

Requests are long-lived
Execution time varies wildly (model + prompt dependent)
GPUs saturate before CPUs
A “slow” request is not a failure
Nodes can vanish mid-generation

Classic round-robin load balancing performs poorly here.

What you want instead:

Adaptive request distribution
Fast eviction of dead nodes
Minimal retry thrashing
Connection reuse

Baseline NGINX Upstream Configuration

upstream ollama_pool {
    least_conn;

    server 192.168.0.169:11434 max_fails=2 fail_timeout=60s;
    server 192.168.0.156:11434 max_fails=2 fail_timeout=60s;
    server 192.168.0.141:11434 max_fails=2 fail_timeout=60s;

    keepalive 64;
}

`least_conn`: The Right Algorithm for GPUs

least_conn routes new requests to the backend with the fewest active connections.

Why this works so well for Ollama:

LLM requests are long-running
Faster GPUs finish sooner
Finished nodes naturally get more work

This gives you implicit weighting without hardcoding values.

Failure Handling for Long Downtime Nodes

server 192.168.0.169:11434 max_fails=2 fail_timeout=60s;

Meaning:

After 2 failures within 60 seconds
The node is marked down for 60 seconds
No traffic is sent during that time
Afterward, NGINX retries automatically

For known long outages, consider fail_timeout=300s.

Connection Reuse Matters (`keepalive`)

keepalive 64;

This enables TCP reuse between NGINX and Ollama.

Benefits:

Fewer handshakes
Lower latency
Better streaming stability

⚠️ Requires:

proxy_http_version 1.1;
proxy_set_header Connection "";

Detecting Failures Quickly (Timeouts)

proxy_connect_timeout 2s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;

Notes:

proxy_connect_timeout handles dead hosts fast
proxy_read_timeout must be tuned:
- Streaming → lower OK
- Blocking generations → higher needed

Retrying Failed Requests

proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;

NGINX will retry failed requests on other nodes.

⚠️ LLM responses are not guaranteed idempotent.

Planned Maintenance: Disable a Node

server 192.168.0.141:11434 down;

Reload NGINX to immediately remove the node from rotation.

Recommended Production Baseline

Upstream

upstream ollama_pool {
    least_conn;
    server 192.168.0.169:11434 max_fails=2 fail_timeout=60s;
    server 192.168.0.156:11434 max_fails=2 fail_timeout=60s;
    server 192.168.0.141:11434 max_fails=2 fail_timeout=60s;
    keepalive 64;
}

Proxy Location

proxy_http_version 1.1;
proxy_set_header Connection "";

proxy_connect_timeout 2s;

proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;

Tune proxy_read_timeout based on streaming vs blocking usage.

What This Setup Does Not Do

This configuration does not:

Share model state
Provide session stickiness
Add authentication
Expose Ollama safely to the internet

Use it on trusted networks or behind TLS + auth.

Final Thoughts

This setup provides:

Smart GPU-aware load balancing
Automatic failover
Graceful handling of dead machines
Minimal operational overhead

It’s a solid foundation for any serious Ollama deployment.

Blazor Behind Nginx – Addendums

Christopher — Thu, 05 Feb 2026 16:25:17 +0000

Blazor Behind Nginx – Addendums

This document is intended as add-on material to the main article:
“Fixing Blazor Apps Behind Nginx: Reverse Proxy Headers, WebSockets, and Redirect Hell”.

It covers:

Blazor WebAssembly–specific considerations
Hosting Blazor under a sub-path (e.g. /dashboard)

Addendum 1: Blazor WebAssembly Behind Nginx

Blazor WebAssembly (WASM) behaves very differently from Blazor Server when placed behind Nginx — mostly because there is no persistent server connection.

What Problems Go Away with Blazor WASM

Because Blazor WASM runs entirely in the browser:

No SignalR
No WebSockets
No long-lived server connections
No proxy timeouts freezing the UI

This removes an entire class of reverse-proxy issues.

However, redirects, auth, and absolute URLs can still break if forwarded headers are incorrect.

Minimal Nginx Config for Blazor WASM

location / {
    proxy_pass http://127.0.0.1:5000;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;
}

No WebSocket upgrades or extended timeouts are required.

When Blazor WASM Still Breaks

Common failure modes:

OAuth / OIDC Redirect Failures

Wrong scheme (http vs https)
Incorrect host
Missing forwarded headers

API Calls Fail

Absolute URLs generated incorrectly
CORS misconfiguration
Hardcoded ports or protocols

Mixed Content Errors

App served over HTTPS, APIs resolving to HTTP

These are still proxy metadata problems — not Blazor problems.

When WASM Is the Better Choice

Choose Blazor WASM if:

You don’t need server push
You don’t need per-user server state
You want simpler infrastructure
You want fewer reverse-proxy edge cases

Choose Blazor Server if:

You need tight server control
You need real-time server interaction
You’re willing to manage WebSockets correctly

Addendum 2: Hosting Blazor Under a Sub-Path

Hosting Blazor under a sub-path instead of / introduces additional complexity.

Example:

Public URL: https://example.com/dashboard
Kestrel app: running at /

This requires explicit configuration in both Nginx and Blazor.

Nginx Sub-Path Proxy Configuration

location /dashboard/ {
    proxy_pass http://127.0.0.1:5000/;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;

    proxy_redirect off;
}

Key points:

Trailing slashes matter
proxy_redirect off prevents broken Location headers
The path must be consistent everywhere

Blazor Server: Configure PathBase

app.UsePathBase("/dashboard");

This must be applied before routing and endpoints.

Missing this results in:

Broken navigation
Incorrect links
Static asset failures

Blazor WASM: Configure Base Href

In wwwroot/index.html:

<base href="/dashboard/" />

If incorrect:

Routing fails
Static assets 404
JS interop breaks

Authentication Cookie Gotchas

When hosting under a sub-path, cookies may not be sent correctly.

Symptoms:

Login works once
Refresh logs the user out
Auth state disappears unexpectedly

Root causes:

Cookie path mismatch
Incorrect redirect URIs
Missing PathBase configuration

(This is covered fully in the Keycloak deep dive.)

Common Sub-Path Failure Matrix

Symptom	Likely Cause
Navigation breaks	Missing PathBase or base href
Static assets 404	Trailing slash mismatch
Login loop	Cookie path mismatch
Redirects drop sub-path	Proxy redirect rewriting
API calls hit wrong URL	Absolute path assumptions

Recommendation

If possible, avoid sub-path hosting.

Prefer subdomains instead:

dashboard.example.com
api.example.com

This dramatically reduces routing, auth, and proxy complexity.

Get back inserted Id

Christopher — Thu, 05 Feb 2026 15:39:53 +0000

Getting the Inserted ID in SQL Server (INT vs UNIQUEIDENTIFIER)

When inserting rows into SQL Server, it’s common to immediately need the primary key that was just created—whether to return it from an API, insert related records, or log activity.

The correct approach depends on your primary key type.

This article covers:

INT IDENTITY primary keys
UNIQUEIDENTIFIER (GUID) primary keys
Common mistakes to avoid
Best-practice SQL patterns
How this maps cleanly to Dapper / ADO.NET

Case 1: INT IDENTITY Primary Keys

Table definition

CREATE TABLE Topics (
    Id INT IDENTITY(1,1) PRIMARY KEY,
    Name NVARCHAR(100),
    Description NVARCHAR(MAX),
    Image NVARCHAR(255)
);

❌ The common mistake

SELECT @@IDENTITY;

This is unsafe. If triggers or parallel inserts exist, it can return the wrong value.

✅ Correct: SCOPE_IDENTITY()

INSERT INTO Topics (Name, Description, Image)
VALUES (@Name, @Description, @Image);

SELECT CAST(SCOPE_IDENTITY() AS INT);

Why this works:

Scoped to your insert
Safe from triggers
Cheap and fast
Returns only the identity value

When to use this

Simple inserts
Single-row inserts
Tables with INT IDENTITY

Case 2: UNIQUEIDENTIFIER Primary Keys (GUIDs)

Table definition

CREATE TABLE Topics (
    Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID() PRIMARY KEY,
    Name NVARCHAR(100),
    Description NVARCHAR(MAX),
    Image NVARCHAR(255)
);

❌ Why SCOPE_IDENTITY() does NOT work

SELECT CAST(SCOPE_IDENTITY() AS UNIQUEIDENTIFIER);

SCOPE_IDENTITY() only works with numeric identity columns.

GUIDs are not identities.

✅ Correct: OUTPUT INSERTED.Id

INSERT INTO Topics (Name, Description, Image)
OUTPUT INSERTED.Id
VALUES (@Name, @Description, @Image);

This returns the actual GUID generated by SQL Server.

Bonus: Multi-row Inserts

SCOPE_IDENTITY() fails here.

INSERT INTO Topics (Name, Description, Image)
OUTPUT INSERTED.Id
SELECT Name, Description, Image
FROM @TopicBatch;

Returns all generated IDs correctly.

Dapper Usage

INT

var id = connection.ExecuteScalar<int>(sql, parameters);

GUID

var id = connection.ExecuteScalar<Guid>(sql, parameters);

Summary Cheat Sheet

PK Type	Correct Method	Trigger Safe	Multi-Row Safe
INT IDENTITY	SCOPE_IDENTITY()	✅	❌
UNIQUEIDENTIFIER	OUTPUT INSERTED.Id	✅	✅

Best Practices

Use SCOPE_IDENTITY() only for INT IDENTITY
Use OUTPUT INSERTED.Id for GUIDs
Never use @@IDENTITY

Happy querying 🚀

NGINX Security

Christopher — Fri, 31 Mar 2023 07:05:38 +0000

Fixing Blazor Apps Behind Nginx: Reverse Proxy Headers, WebSockets, and Redirect Hell

If you’ve ever deployed a Blazor app behind Nginx and thought:

“It kind of works… but redirects are broken, auth is weird, and the UI randomly stops responding”

—you’re not alone.

This post documents the issues I hit running Blazor behind an Nginx reverse proxy, why they happen, and the minimal set of fixes that actually made things stable.

The Problem

Blazor apps (especially Blazor Server) behave badly behind a reverse proxy unless the proxy correctly forwards request metadata.

Common symptoms:

Infinite HTTP ↔ HTTPS redirect loops
Auth callbacks failing (OIDC / OAuth / Twitch / Okta / Keycloak)
Incorrect absolute URLs being generated
Blazor Server disconnects or frozen UI
Client IPs always showing as 127.0.0.1

At first glance, everything looks fine — the app responds — but things slowly fall apart.

Why This Happens

Nginx terminates TLS and forwards traffic to Kestrel.

By default, ASP.NET Core has no idea:

What hostname the user actually hit
Whether the request was HTTPS
What port was used
Who the real client IP is

Without that information, ASP.NET Core makes bad assumptions — and Blazor magnifies those mistakes.

The First Fix: Forwarded Headers

This is the bare minimum most people discover first.

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

What this fixes

Preserves the public hostname
Preserves client IPs
Tells ASP.NET Core whether the original request was HTTP or HTTPS

This improves things, but in many cases it does not fully fix them.

“Still having some issues, but this seems to be part of the solution.”

That’s because it is only part of the solution.

The Missing Headers Most Guides Don’t Mention

In practice, you usually also need:

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;

Why?

Some stacks rely on X-Forwarded-Host more than Host
Port mismatches can break redirects and auth callbacks
Multi-proxy setups behave more consistently with explicit forwarding

Blazor Server-Specific Gotcha: WebSockets (SignalR)

Blazor Server requires WebSockets (SignalR).

Without explicit upgrade headers, the UI may:

Load but not respond
Randomly disconnect
Freeze after navigation

You must include:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Long-Lived Connections Need Timeouts and Buffering Tweaks

Blazor Server keeps long-running connections open.

Default Nginx buffering and timeouts can eventually kill them.

These settings often help:

proxy_read_timeout 3600;
proxy_send_timeout 3600;
proxy_buffering off;

A “Known-Good” Nginx Config for Blazor Server

This is the configuration that finally stopped the weird behavior:

location / {
    proxy_pass http://127.0.0.1:5000;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;

    proxy_read_timeout 3600;
    proxy_send_timeout 3600;
    proxy_buffering off;
}

Assumptions:

TLS is terminated at Nginx
Kestrel is running HTTP internally
You’re hosting at / (not a sub-path)

Important: Nginx Alone Is Not Enough

Even with perfect headers, ASP.NET Core must be configured to trust them.

If your app doesn’t enable forwarded headers middleware, it will ignore what Nginx sends.

Typical symptoms when this is missing:

HTTPS redirects still broken
Auth callbacks still wrong
Scheme mismatches persist

Make sure forwarded headers are enabled and your proxy/network is trusted.

Common Failure Modes (and What They Mean)

Symptom	Likely Cause
HTTP ↔ HTTPS redirect loop	`X-Forwarded-Proto` not honored
OAuth callback mismatch	Host / scheme incorrect
Blazor UI freezes/disconnects	WebSocket upgrade missing or timeouts
Random disconnects	Proxy timeouts / buffering
Client IP always localhost	Missing forwarded IP headers

Final Thoughts

Blazor behind Nginx can be rock-solid, but only if:

Forwarded headers are complete
WebSockets are explicitly supported (Blazor Server)
Timeouts are adjusted for long-lived connections
The app actually trusts the proxy

Most guides cover some of this. Very few cover all of it.

Hopefully this saves someone else a few hours of head-scratching.

Easier Lets Encrypt SSL Certs

Christopher — Fri, 31 Mar 2023 06:55:27 +0000

I've been using a combination of Cloudflare and Nginx Proxy Manager to simplify various internal and external services over the past year. Adding SSL to externally exposed sites has been pretty straight forward, add a CNAME record in Cloudflare that points to my router, and my router uses Nginx for a reverse proxy. Simply enough, plus the traffic gets auto wrapped in Cloudflares certs.

The issue has been adding and maintaining SSL for internal only apps. I've been following the same workflow as external apps but turning on/off the cloudflare record. This also doesn't provide me real SSL from cloudflare anymore and I've had to generate it from letsencrypt while the external port was exposed. Not optimal, and renew breaks in this pattern.

Solution: Wildcard certs. This was less that straight forward as I tried to manually use certbot to create a wildcard cert which works, but I still have to manually renew, and the import process is even more long winded. So Nginx Proxy Manager has the ability to create a SSL certificate from the tab, and use LetsEncrypt.
Settings should be as follows:

Domain name - *.[yourdomain].com
Tick on Use a DNS Challenge
I tested cloudflare as my DNS provider but there are a lot of others in the dropdown that work similarly I expect. Once you select this it will want a token. Grab that from Cloudflare -> My Profile -> Api Tokens and create a new custom token.
Call it whatever you like, imortant part is the permissions. They should be set to [Zone] [Zone Settings][Edit],
Include whichever zones you want, and continue to summary below.
Agree to the terms.

You can now update/add endpoints and use this new cert. It hasn't been long enough to require renewal but it should follow the same renew pattern as the non-wildcard certs.

Register for Notifications on Android SDK 33

Christopher — Mon, 20 Mar 2023 14:14:43 +0000

Problem: Notifications are not being received after upgrading to Android SDK 33.

Solution: In Android SDK 33 you now have to request permissions to display Notifications. Asking for POST_NOTIFICATIONS alone wasn't sufficient, and some of these maybe overkill but this is what worked for me.

To get the notifications permission, you need to first request permission for the following items:

private string[] PermissionsForNotifications =
            {
                Manifest.Permission.ReceiveBootCompleted,
                Manifest.Permission.WakeLock,
                Manifest.Permission.Vibrate,
                Manifest.Permission.Internet,
                Manifest.Permission.AccessNetworkState,
                Manifest.Permission.PostNotifications,
                Manifest.Permission.ForegroundService,
                "com.google.android.c2dm.permission.RECEIVE",                "com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE",                "android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS",
                "android.permission.REQUEST_COMPANION_RUN_IN_BACKGROUND"
            };

When calling the registration it seemed the Channel ID was also required.

private int RequestNotificationId = 1000;
ActivityCompat.RequestPermissions(CurrentActivity, PermissionsForNotifications, RequestNotificationId);

Blazor WASM Linking

Christopher — Fri, 10 Feb 2023 18:09:35 +0000

Problem:
Your WASM application works fine in debug, but when you deploy you start seeing issues where methods and other such things are missing.

Possible Solution: Blazor WASM is similar to Xamarin development in that you want to ensure your app is as small as possible. To that goal, by default the build will strip out any perceived unneeded code from your project. This can have some unforeseen consequences unfortunately. To avoid this consider adding the following properties to your project file:

Disable ALL linking

<PropertyGroup> 
<BlazorWebAssemblyEnableLinking>false</BlazorWebAssemblyEnableLinking>
</PropertyGroup>

Disable linking in a more nuanced fasion

<ItemGroup>
  <BlazorLinkerDescriptor Include="LinkerConfig.xml" />
</ItemGroup>

If you go with the LinkerConfig.xml please review the reference for guides on how to populate the LinkerConfig.xml

Reference: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/configure-linker?view=aspnetcore-3.1

SQL Primary Keys

Christopher — Sun, 05 Feb 2023 04:57:24 +0000

Problem:
You need to add a primary Key to a table.

Solution:
Heres a few types I've run across.

Manual Primary Key

CREATE TABLE [dbo].[HtmlDtos]([Id] [int] PRIMARY KEY)

Auto Sequential Int Primary Key

CREATE TABLE [dbo].[HtmlDtos]([Id] [int] IDENTITY(1,1) PRIMARY KEY)

Auto Sequential GUID PK

CREATE TABLE [dbo].[HtmlDtos] ([Id] UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY)

Auto Random GUID PK

CREATE TABLE [dbo].[HtmlDtos]([Id] UNIQUEIDENTIFIER DEFAULT NEWID() PRIMARY KEY)

SonarQube Docker with PostGres issues

Christopher — Wed, 25 Jan 2023 15:05:19 +0000

Problem: Created a new docker container for SonarQube and it failed with the error:

bootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

Solution:

edit the file /etc/sysctl.conf
change or add a line vm.max_map_count=262144
then run sysctl --system

https://stackoverflow.com/questions/41064572/docker-elk-vm-max-map-count

Get the last directory a file with bash

Christopher — Wed, 25 Jan 2023 15:04:45 +0000

Problem:
You need to get the last directory a file is in,

Solution (one of many I'm sure):
using the full filename "/path/to/file/filename.txt"
dirname /path/to/file/filename.txt

this produces /path/to/file, then we use shell replacement as such:
echo ${INPUT##*/}

which produces
file

Creating Multi-platform nugets for Xamarin

Christopher — Tue, 24 Jan 2023 17:54:25 +0000

Problem:
You want to create nuget packages that have different dependencies for multiple platforms such as Xamarin iOS and Android and beyond.

Solution:
Create a nuspec file that includes dependencies and files that match the platforms you want to target as such.

<?xml version="1.0"?>
<package >
  <metadata>
    ... 
 <dependencies>

      <group targetFramework="Xamarin.iOS10"> 
        <dependency id="Microsoft.AspNetCore.SignalR.Client" version="5.0.9" />
        <dependency id="Microsoft.Extensions.Http" version="5.0.0" />
        <dependency id="System.Reactive" version="5.0.0" /> 
      </group>

      <group targetFramework="MonoAndroid10"> 
        <dependency id="Microsoft.AspNetCore.SignalR.Client" version="5.0.9" />
        <dependency id="Microsoft.Extensions.Http" version="5.0.0" />
        <dependency id="System.Reactive" version="5.0.0" /> 
      </group>

      <group targetFramework="net7.0"> 
        <dependency id="Microsoft.AspNetCore.SignalR.Client" version="5.0.9" />
        <dependency id="Microsoft.Extensions.Http" version="5.0.0" />
        <dependency id="System.Reactive" version="5.0.0" /> 
      </group>
    <group targetFramework="netstandard2.1"> 
        <dependency id="Microsoft.AspNetCore.SignalR.Client" version="5.0.9" />
        <dependency id="Microsoft.Extensions.Http" version="5.0.0" />
        <dependency id="System.Reactive" version="5.0.0" /> 
      </group>
    </dependencies>

  </metadata>
    <files>    
      <file src="[dllpath]" target="lib\netstandard2.1" />
      <file src="[dllpath]" target="lib\net7.0" />
      <file src="[dllpath]" target="lib\MonoAndroid10" />
      <file src="[dllpath]" target="lib\Xamarin.iOS10" />
    </files>
</package>

DEV Community: Christopher

Blocking Bing at Home with Pi-Hole (Without Breaking Edge)

Making an Ollama Mesh with Nginx

Load Balancing Ollama with NGINX: Handling Long GPU Jobs and Dead Nodes Gracefully

Why Ollama Needs Special Load Balancing

Baseline NGINX Upstream Configuration

least_conn: The Right Algorithm for GPUs

Failure Handling for Long Downtime Nodes

Connection Reuse Matters (keepalive)

Detecting Failures Quickly (Timeouts)

Retrying Failed Requests

Planned Maintenance: Disable a Node

Recommended Production Baseline

Upstream

Proxy Location

What This Setup Does Not Do

Final Thoughts

Blazor Behind Nginx – Addendums

Blazor Behind Nginx – Addendums

Addendum 1: Blazor WebAssembly Behind Nginx

What Problems Go Away with Blazor WASM

Minimal Nginx Config for Blazor WASM

When Blazor WASM Still Breaks

OAuth / OIDC Redirect Failures

API Calls Fail

Mixed Content Errors

When WASM Is the Better Choice

Addendum 2: Hosting Blazor Under a Sub-Path

Nginx Sub-Path Proxy Configuration

Blazor Server: Configure PathBase

Blazor WASM: Configure Base Href

Authentication Cookie Gotchas

Common Sub-Path Failure Matrix

Recommendation

Get back inserted Id

Getting the Inserted ID in SQL Server (INT vs UNIQUEIDENTIFIER)

Case 1: INT IDENTITY Primary Keys

Table definition

❌ The common mistake

✅ Correct: SCOPE_IDENTITY()

When to use this

Case 2: UNIQUEIDENTIFIER Primary Keys (GUIDs)

Table definition

❌ Why SCOPE_IDENTITY() does NOT work

✅ Correct: OUTPUT INSERTED.Id

Bonus: Multi-row Inserts

Dapper Usage

INT

GUID

Summary Cheat Sheet

Best Practices

NGINX Security

Fixing Blazor Apps Behind Nginx: Reverse Proxy Headers, WebSockets, and Redirect Hell

The Problem

Why This Happens

The First Fix: Forwarded Headers

What this fixes

The Missing Headers Most Guides Don’t Mention

Blazor Server-Specific Gotcha: WebSockets (SignalR)

Long-Lived Connections Need Timeouts and Buffering Tweaks

A “Known-Good” Nginx Config for Blazor Server

Important: Nginx Alone Is Not Enough

Common Failure Modes (and What They Mean)

Final Thoughts

Easier Lets Encrypt SSL Certs

Register for Notifications on Android SDK 33

Blazor WASM Linking

SQL Primary Keys

Manual Primary Key

Auto Sequential Int Primary Key

Auto Sequential GUID PK

Auto Random GUID PK

SonarQube Docker with PostGres issues

Get the last directory a file with bash

Creating Multi-platform nugets for Xamarin

`least_conn`: The Right Algorithm for GPUs

Connection Reuse Matters (`keepalive`)