Intro and Musings

Ok. Here we go. Let me start off as I usually do and reinforce that this is a complex subject and some details/nuance sf more than likely glossed over/missed. The point of these missives is never to be a definitive source, but an enthusiast's ramblings in an effort to educate, and selfishly force myself to slow down, research, and make sure I understand the subject as best I can. Now that I’ve totally projected my insecurities, let’s begin. ;)

Building The Foundation

The AI agent that’s my current go to for coding is Claude. This workflow can likely be used for any agent/service that supports coding but I’ll be focusing on Anthropic. You’re going to need to to pony up some cash to do this, let’s define some terms and make sure we’re making the right choices.

Claude has several primary features.

Chat - general purpose agent, can work with files that are uploaded but does not connect to local files on the workstation. Totally headless. The only option in the free tier. Not a lot of tokens to work with, times out quickly.

CoWork - “Agentic” chat. It can be scheduled, tasked, and run basic routines. E.G. “scan these services at a certain day/time and email me the results” kind of thing. It does way more, but we’re focusing on Code. Anthropic has recently moved the module into the chat modal as an inline tab.

Claude Design - Terrible at making power-point? Hate making diagrams? Need a web page? Design is for you. It does do a lot more, but out of scope for this.

Claude Code - Ok, here we go. Code can work with local files, it can connect to GitHub, and natively works with the git framework. It’ll show the PR you’re on, diff counts, etc. Nifty-schwifty.

Claude Code

Ok there are four basic ways to work with Code.

Web

There’s now a button the web to go to code on the web. I think we’ll focus on using this on our examples. When you start code on the web, it fires up a container, and then clones the repo to work on the files. Like chat, it does not interact with local file stores. We’ll dive into this more later.

Claude Desktop

A local install of the Claude “harness”. I think I’ll get into that in future AI 101 post. For now, it’s an application you install locally. It can work directly with local files, and (I just found this out) you can also start a session with a web container. Whether or not you can resume a Desktop Web session with Web Code seems to be a bit fuzzy, and I have not tested it. When using the local option all software must be installed for that environment to compile and test. If you don’t have something, it will tell you.

Claude CLI

This is a totally different install process than Claude Desktop, and to be honest, I kind of hate it. Skills import differently, it seems in my experience to use tokens/less efficiently than Desktop or Web, and I find the interface to be a pain. At this point it’s not for me and I won’t be covering it.

IDE Extensions

IDEs like VS Code and JetBrains can run Claude as an extension, but we won’t be getting into it.

Where’s My Money, Man?

Code, Cowork, Design. Really anything other than chat is going to require some sort of payment. There are two primary methods.

API Based

An API based account is going to consume tokens based on the model you use. It’s “pay as you go”. Let’s look at the Pros/Cons

Pros:

• You can use any harness you want. Cursor, VS Code Agent, etc.

• No interruptions, unless you run out of paid tokens. You can enable a faucet of cash straight to Anthropic to enable auto re-up if you want.

• Direct API integration with other tooling.

• Use a LLM Gateway like Open Router

Cons:

• You have to be very mindful of what you’re using for a model and be aware of your running tasks. This can get expensive, quick.

• More of a learning curve, not as simple as the “turnkey” solution the subscriptions are.

Let’s look at Open Router to see the costs. This is a third party “LLM Gateway” I’ve been using on the side. Primarily what we care about is the price per input/output tokens. Don’t get me wrong, it all counts but I feel that‘s a good baseline. Looks how much more expensive Opus is than Sonnet. I find Sonnet to be terrible at coding, so Opus is my standard.

Now this is still abstract, so let me put in a bit more perspective. KimiK3 is a Chinese model at half the cost and is supposed to be equal-ish to Opus. I bought 10 bucks of credit on Open Router, set up VS Code Agent, and took the ol’ girl for a spin.

My task was debugging a Home Assistant integration I worked up with Claude. It wasn’t that intensive a task in theory but I used 14 Million tokens and spent most of my 10 bucks to do it. Claude at the same price? Twice that.

Subscriptions

A flat rate regardless of what model you use (Fable is not available in the Pro subscription, you have to pay as you go) Has a rate limit based on token consumption in five hour sessions and consumption via a week timeframe. Higher model = faster session burn rate. If you hit your session limit you have to wait until it resets.

Pros:

• Use almost any Anthropic model you want without added cost concerns.

• Multiple plan options. We’ll focus on Pro.

• Simple to use.

• While there is no API for subscriptions, there are some IDE extensions you can use for applications like VS Code, JetBrains. Not the same as using one of those as the full harness.

Cons:

• When you hit the session/week limit it’s a hard stop unless you enable a faucet of cash straight to Anthropic to enable usage credits if you want to continue the session.

• No API at all. You’re locked in. You can have an API account under the same email, but they are structurally separate.

• No other harness, it’s Claude applications only. This mean Claude Web, Desktop or CLI only. Remember the extensions mentioned in Pro are not full harnesses.

• Higher model use can burn through sessions quickly based on the task.

What to do?

If you’re reading this you’re probably fairly new to this. I do not recommend API, go with the pro subscription. It’s 20 dollars a month. And the value is insane. I was looking at my past sessions and each one is almost 20 bucks a shot, bear in mind I was doing quite a bit in those sessions.

These plans are highly subsidized and a very affordable way to get your feet wet. Even the MAX at 100 a month is kind of amazing, when you understand the actual costs. I can’t imagine these prices will last forever.

Sign up, and go with Pro to start, that’s my recommendation. Now we need to talk a little bit of AI 101 for a base understanding of some concepts.

I Have No Memory Of This Place

Ok, so right off the bat know that the model is simply the inference engine. It has no memory, nothing installed. The model is locked into its learned state at the time of release, basically read only. It’s the harness (our Pro account use case Claude itself is the harness) that maintains state, tools, skills, memory. The conversation to the model must be stateful in order to get useful data out. Let me explain that in an easier to understand way.

Cool Operator

Let’s segue and talk about air conditioning. That’s right, AC. So I have these Mitsubishi Minisplits, and I was working on adding some automations to Home Assistant and my commands aren’t being received correctly when learning the IR codes. That’s when I find out that the system is stateless. It has no idea or ability to compare a difference in its established state.

So lets say I have the settings set to:

Swing: Full
Temperature: 70f
Fan: Medium
Mode: Cool

And I want to change the temperature to 71f. The remote only sends that change of 71f, right? Nope. It sends the full state of the remote at once. So that one button press sent:

Swing: Full
Temperature: 71f
Fan: Medium
Mode: Cool

That’s the new state of the unit. If I change the speed:

Swing: Full
Temperature: 71f
Fan: Low
Mode: Cool

Again, it sends way more information that what I’m changing on every press, overwriting the previous active state. Pretty damned inefficient, but SIMPLE. This is very close to what happens when you are using AI.

As The AI Turns

So back to the main subject, when you enter data into the field and hit enter, that’s a turn. Every turn is a state submission, and wholly new to the model on every go. So the token use becomes higher on every turn, outside of the amount of new submissions on a turn. Loaded skills, MCP connections, tools, the conversation from the top are sent to the model fresh every time. Let’s talk about some behaviors to assist on keeping our conversations as efficient as possible.

• Don’t switch models in the same session unless at the beginning. That’s a lot of data to resend, kind of obviates the benefit.

• If a conversation is getting long, ask for a hand off summary. It will summarize the entire conversation that you can paste into a new session. Great option to use if you need to switch a model because the scope of the task has changed. E.G., you coded with Opus but Sonnet can do the PR check and release notes. As it is a summary you may lose some resolution to the conversation, and it might re-review some sections to try and get that context back.

• Be aware of your context window. In Pro, the context window is 200k. If you click on the little circle next to the model you can see the contents of the window. Once it hits 84% it will “compact” the conversation automatically which is basically an internal handoff. So if your session suddenly stops, look for some text that says “compacting conversation” and the it will give you some indications of how many tokens it “saved.” The resolution statement applies here as well. Compaction is important because with an AI when you go past the window shit gets…weird and from a hallucination standpoint kind of goes on a spiritual journey. Remember how you got on those 2AM change windows in person at a datacenter? Yea, not at your best. Same here.

Sounds Like a Skill Issue

So we’ve connected to our GitHub, we made a repo and we started to build an app. Only a strange thing is happening. It’s making changes, adding features after what only was supposed to be a discussion, making commits without asking, creating and merging PRs, dogs and cats, living together, MASS HYSTERIA! Now your repo is a mess, there’s no tags, no release notes, and you have to burn a bunch of tokens to fix it.

The thing is, it’s doing exactly what you asked of it and BY GOD IT’S GOING TO DO IT. You provided no instructions or guardrails.

Well this is where the concept of skills come in. A skill is simply a set of repeatable instructions that you want the session to abide by. I have spent the last three weeks learning and with Claude, refining my “dev skills” skill. And it is massive, so using it will cause more tokens to be used, but it’s optimized into a primary skill and reference skills that only load on a certain “gate”. We will use this skill for this series.

The .skill file can be downloaded from releases.
https://github.com/darthrater78/claude-vibe-skills

Quick Note: Claude Code and Desktop allow for upload of the.md files as .skill zips. So the zip on my GitHub will import fine. Other harnesses/Claude CLI are going to want it unzipped though most will do it for you if you upload it to the chat window and say “install this skill.”

NOTE: SKILLS CAN BE MALICIOUS LIKE ANY MALWARE AND CONTAIN DANGEROUS INSTRUCTIONS. NEVER INSTALL A 3RD PARTY SKILL YOU HAVE NOT AUDITED. THE SKILL ON MY GITHUB IS WELL DOCUMENTED AND FREELY OPEN TO AUDITING.

To install a skill in Claude Web go to Code, and Customize> Skills>Add>Upload.

After upload, you can see it in “Yours”.

If you then look at the skill further, you can see more details. I always version my code, so you can see what rev you are running. To update to a new version delete and re-upload. Skills also will copy down to Claude Desktop.

In theory installed skills are loaded in each chat, but I have found invoking it right away works best.

See that “updated dev-skills-gates” file? That tracks the state of the gates on the repo so the harness doesn’t have to remember it. Basically says nothing to do here, the previous release is solid. New feature in the skill.

This skill is designed to be a guide for development and focus on security, quality and process. We’ll get into this in Part 4.

Conclusion

So I really wanted to get into starting some app development in this post, but I realized there was just so much to cover, I could not fit it here. You should leave this post with a much firmer understanding of AI and Claude in general from a basic use case.

So in part 4, we make an APP!

Until next time.

Intro and Musings

As somebody once said “This is where the fun starts, something something.” Once you realize what you can do with a coding agent, the whole world kind of opens up with new possibilities. Have a process you find tedious? Make an app. Have a docker image you love but the dev has kind of walked away from it? “Take it, it’s yours!” Iterate, improve and add features. But remember “With power comes great responsibility.” (I’m in a very meme-y mood today, and will likely continue. My apologies. )

Let’s establish a “citizen” code of conduct.

• Always code with security and software quality in mind

• If you fork someone else’s project ensure you update the main readme, explaining you used AI to code it. Be transparent, don’t be this guy.

• Have a thick skin, and keep learning.

• Have fun, otherwise what’s the point?

Here’s a few examples of projects I’ve made/forked which just looks like shameless plugs but totally aren’t. Review these and look at the release notes/main readme to get sense of what I’m going for here as an overall philosophy.

My Projects:
https://github.com/darthrater78/cert-generator
I found the routine process of making certs and SSH Keys to be a bit of a pain. So I made a tool. (In the process of also making it a docker image)

https://github.com/darthrater78/proxmoxspicemanager
API/Password connection to Proxmox for easy access to Spice console sessions.

Forked Project:
https://github.com/darthrater78/dockge
Here the example of someone else’s project I adapted and added new features to. For dockge I added an API and a compose drift sync feature. If you look at the page, I made sure to explicitly call out how these changes were made and to give proper attribution.

So the point of this overly long “soapbox of musings” is to illustrate what you can do, and set some ground rules. As always, this is how I do things. You may do things differently, and that’s cool. One last note. I’ve been “Mr. Linux” lately after moving to Fedora. However, my job insists I use Windows and my customers all use it as well for the most part.

So you’ll notice that this series will focus mainly on Windows as the platform, and most of the tools I made are Windows compatible. Proxmox Spice Manager is available as a python script, though. Let’s begin.

Git ‘er done!

Ok we may not be software developers by trade, but that doesn’t mean we shouldn’t develop like one. And the first thing we should do is operate via a Git framework. If you don’t have a Github account go open one. Git is an incredibly deep topic and we will not be going terribly deep into it. (okay, maybe a little) What you need to know is that it tracks software versions, allows for easy collaboration and makes publishing easy-ish. Let’s get some definitions set.

Repo (Repository) - those projects I shared? Those are Github Repos. Its a fancy folder for your stuff. Each project gets its own repo. A Github repo can be edited on the website directly, or you can pull down a local copy via clone.

Repo Actions

Fork - You’ve seen me mention this several times. When you fork a repo, you make an out of line copy of someone else’s work to your own repo. Nothing you do affects the upstream directly, though you can submit your commits to the fork(ee) for consideration. Its part of the beauty of open source software, when you can take someone’s code and build off it. You’ll see that sometimes someone will take someone’s project and build something totally new. For example, Jellyfin is a transformational fork of Emby. Your fork is visible from the parent repo, and can also be compared.

Clone- When you clone a repo, you are working on a copy of the upstream code, including its full git history. You typically clone your own repos (even forks) to work on them locally. Any public repo can be cloned. Unlike a fork, an unforked clone has no ability to submit changes to the original.

Git Commands

Commit/push - When you make a change to a repo, you store those changes in a commit. It’s important to understand changes are ephemeral until committed. You should commit after work is completed. Think of it as a snapshot. It will show changes, and assign that commit a unique value. A commit can eventually be merged into the main branch to be active in the codebase if committed to a different branch. If you are working with the repo locally, you would commit the change locally and then “push” the commit upstream.

Branch - The primary branch is usually called Main/Master. I’ll refer to it as Main in this document going forward. Typically, as a best practice when you start new work, you would open a new branch and add commits there. Commits to a branch are active to the current branch at the time. Once you’re happy with the work, you can merge into Main after a pull request. More on this later.

Pull Request (PR) - This is the concept I found most confusing at first. Let’s say you made a change to the repo. It could be a readme change, code update, feature addition, anything. When you commit and push the change, those changes are sent and committed to the branch it was made on. If you want that code to become a permanent part of Main, you have to ask the repo owner to review and “pull” your changes into that branch via a Pull Request. They can then decide to “merge” your changes into the codebase, reject it, or just totally ignore it. And man, PRs get ignored a LOT.

Merge - When a PR is accepted, the commits are merged. The two basic merge types are standard and squash. Standard takes all the the commits and merges them separately. Visually noisy, but granular history. A “squash” collapses all the commits down into one. You lose the commit history and the ability to more accurately target code tied to a particular commit. I use standard for the history.

Tags - we'll be using tags quite a bit for releases. When we use a tag, we are marking a specific commit. We can then create a “release” around that tag and add an artifact (if needed) and release note text. A tag can also be used to kick off an automated workflow as part of a release. In the picture below, you can see that I am telling users that this tagged commit is the code I want them to use as the current standard.

Artifact- Let’s focus on this for a second. We’re developing for ourselves and others. As a good citizen, we should be presenting users with compiled and easy to run code. Whether it’s an .exe, .sh, or a .zip. Let’s not make the users have to worry taking your code and building it from scratch. Present a completed product. If we’re making a docker container that’s a bit different. In that instance there would still be a tag and release but typically no artifact. Docker images are hosted elsewhere.

Workflows - These are automations we can tie to a repo. They are yaml config files, under the “Actions” tab. There’s a lot to it. Thankfully there are templates. Claude is really great at helping us shape and refine these templates. Many actions can kick off a workflow. Push, PR, release, fork, watch, etc. Go take a look at your favorite repo and check out actions, see if there are workflows.

CI (Continuous Integration) - I recently learned about this and it’s kind of amazing. You can build your code locally, and have all the software you need to compile. For Android, the SDK, Windows .NET, Docker, …Docker, etc. OR you can have Github compile the code for you via actions as you wait. Look at the screenshot below. See how it’s building the artifact and publishing the release? Neat stuff. Githhub accounts are free, and the CI part is also free for Public repos. Private repos do have limits on usage, but your standard hobbyist is unlikely to hit it.

I need to stress that Git is so much more than this. Commits can be moved, deleted, “rewound”, Claude is going to to do a lot of it for us. What I outlined is the basics you need to know to be familiar.

If you want to approach this better armed with some more education watch this: Git Tutorial for Beginners: Learn Git in 1 Hour

Conclusion

I have learned much since I’ve published part one. I must have rewritten this section three times adding things. It’s quite the journey, but I feel you can’t be a Citizen Developer without having a working knowledge of the basics. As mentioned above, Git is so much larger than this article. Do yourself a favor and watch the video I linked.

In the next part, we’ll go over using Claude and Git to make a software project.

Until next time.

Sometimes you need to run something weird, something that stubbornly refuses to die, the cockroach of the enterprise/business world. If a software was considered to be undead, it would be the IBM 3270 terminal. And while the physical terminal has been long dead, it’s been lovingly(?) resurrected as a standalone application/docker container. The big question is why? Well, maybe you need to demo something, maybe you’re looking to…actually I have no idea. I needed it for a demo.

But I found it interesting, so here we are. Terminal emulators are still widespread in many verticals. Casinos, retail, healthcare, it’s still there. So we’ll cover how to get this running.

Terminal Velocity

The docker example can be found as always on my Github.

Ok, the first part is the 3270 Web Docker. This is neat, because it’s a web terminal client that also has sample apps to play around in. Swell, right?

So this is pretty nifty, but what if you need to connect to this from a thick client. Well, you can’t. All the samples are internal to that docker instance. What to do? Install another server endpoint in the same stack! I love docker.

Hercules, Hercules!

https://github.com/skunklabz/tk4-hercules You could install these in different composes, but no need for this use case. Port 8038 is used as a management port. Which you’ll likely never use, just know that it’s there.

Once that’s running, you’ll be able to connect to it from 3270web.
Don’t use “local host: 3271” it will not work. Note in the compose the port is shifted as to not conflict with 3270 web.

Taa daa! Now, I’m not going to lie. I’m like the dog that caught the car at this point. What to do with it? No idea! This is purely connectivity validation. Terminal emulator over the web! YAY!

Thick and Thin

Now, let’s say you want to connect to this with a thick app and not via the web. There’s a 3270 emulator! I went to the latest version and downloaded the “no install.” Unzip and look at the folder.

https://sourceforge.net/projects/x3270/files/x3270/

That’s…a lot of options. But it’s actually easy. Choose wc3270wiz.exe to pop up a wizard to configure.

Create a session, and give it a name. Now, you’re going to want to use ip:port here. Don’t do that. Put the port separately in 3 on the next page.

Once done, hit enter for “none” and it will ask you to save and then create a shortcut. It’ll be on the desktop, and it will just connect. There’s that car again!

Conclusion

That’s it. This was defintely more of a mini ramble for something I found interesting. So…here it is!

Until next time.

You know the drill. Spin up new server, create username, create password. Use system, forget password, search for “Linux password reset.” OR, use something like SecureCRT that can store the password…use system, forget password, can’t use SUDO, search for “Linux password reset.” Fun times. Even with a password manager this can be a PIA. There’s a better way. Use an encrypted keypair.

Note: I will not be talking about SSH keypairs on routers or switches. I’m focusing on Linux OS, it’s more straightforward.

What is SSH?

Let’s start with “what is telnet” first. Both are ways to remotely log into a system and work with it. Think “RDP for Cavemen”. Telnet and SSH can do largely the same thing, but Telnet is horribly insecure. Everything sent over the wire is cleartext, with no authentication verification.

You may as well stand on your chair and yell out your password while logging in. But for a long time, “this was the way.” And then a better way came along. Secure Shell, also known as SSH.

SSH in comparison, will establish an encrypted session before credentials are transmitted, and then once the user is validated everything over the wire is encrypted. Vastly more secure.

Now, you’ve been using an encrypted keypair every time you’ve used SSH but you probably didn’t realize it, just not for authentication.

The Process

Let’s kick off a SSH session to a server we haven’t talked to before.

I’m sure you’ve seen this before. It’s the “yea yea yea” get out my way, let’s do this. You accept and save, and never see it again.

But let’s take a closer look. This is the server, reaching out to your client saying, “this is who I am. This is the public key I give everybody so you know that it’s me.” It’s what your side uses to help create the encrypted session before authentication.

You can have your client store the key locally, so you don’t have to accept it every time. There is no “private” key for us to manage in this use case. We are only accepting to encrypt our communication to the server, not authenticate as a user.

NOTE: This process is reversed for authentication. The server will have our public key in its store, and we use our private key for a challenge-response. More on this later.

Now if we choose password authentication, once the session is established the credentials are securely sent across the wire to the server to validate. It’s important to note this. “credentials are securely sent across the wire to the server to validate”

That does give a malicious actor an opportunity. Keyloggers, malware. Grabbing credentials from memory. There is a non-zero chance of compromise.

Let’s take a look at a packet capture.

Note: I am glossing over a whole hell of a lot here.

So our initial connection, and our subsequent data is safely snuggled up in an encrypted session. Now let’s talk about key pairs.

Key Pairs

Let me start with what key pairs are not. Key pairs are NOT certificates. Certificates utilize encryption schemes to secure data but there’s a lot more to it. Certificates are key pairs that have embedded metadata, and require a Certificate Authority for validation. SSH Keypairs will have none of that.

With SSH keypairs, there will be a public key and a private key. The public key can be given to anyone, but your private key is the one you must keep secure at all times. You will need both the public and private key, while the server only needs the public.

With keypairs, no private credentials are sent over the wire. The username and a key identifier are sent to the server. The server checks to see if the public key is in the “authorized keys” section and if so, sends a challenge back to the client.

The client uses the private key to sign the challenge and returns it. The server uses the public key to validate the challenge (which can only be signed by someone with the private) and if validated logs the user in.

The important part here is that no “credentials” were ever sent. Just an encrypted challenge. And this is a unique conversation every time. Nothing is stored or repeated.

OK now that we’ve covered some history and process, let’s get this going.

Generating Key Pairs

So there’s any number of ways to generate a keypair. You can use putty, Secure CRT, OpenSSH, but recently I’ve found a drop dead simple way that not only lets you create pairs but easily and securely store them.

Bitwarden. How long did I not know this was a feature?!

In the vault, right there, staring me in the face.

Simply click “add”
Holy crap. That was easy. Let’s copy these values out to two files.

The public to a .pub and the private to a file with no extension. The names must be the same. If you take a look at each they look very different.

Note how the private actually says “Private Key”

Installing the Public

Ok, let’s go over installing a key at install and after install.

After install: so the public must go into the “Authorized Keys” file under the user profile. Here’s a super easy script.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo “your-public-key-here” >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

If you paste in the public key in the echo, it’ll throw it right in there for you. Easy peasy. Feel free to cat the file to validate.

NOTE: if you’re on a Linux or Mac workstation with OpenSSH, ssh-copy-id does all of this in one command.

ssh-copy-id -i ~/.ssh/mykey.pub user@server

Now, let’s setup the client. I’ll use SecureCRT, but the process isn’t terribly different for other clients.

Move public key to the top, don’t forget to put the correct username in.

Point it to the folder with the pair

Hit ok, and if all was right you’ll pop right into the session! Let’s look at the log with:

sudo tail -f /var/log/auth.log

Oct 25 19:07:55 prod-docker sshd[2784705]: Accepted publickey for serveradmin from 10.0.0.56 port 63171 ssh2: ED25519 SHA256:StqvGmDA6rxPWAc+88BCZBzS8aWQWtNG7gb7uFf

Oct 25 19:07:55 prod-docker sshd[2784705]: pam_unix(sshd:session): session opened for user serveradmin(uid=1000) by (uid=0)

Oct 25 19:07:55 prod-docker systemd-logind[722]: New session 283 of user serveradmin.

Right there you can see we’ve successfully SSH’ed in! Wait, but what about sudo? Now in Debian sudo isn’t a thing, but in Ubuntu it is. And we’re trying to get away from typing out credentials, right? Easy fix.

Using our credentials one last time, let’s su to root and sudo visudo.

NOTE: This is a convenience thing and represents a downgrade in security. While suitable for a home enterprise, I might not do this in Prod at work since you’ll likely be against your security policy.

Change that line to %sudo ALL=(ALL:ALL) NOPASSWD: ALL as shown above. Log out, log in and you should be able to sudo nice and easy.

Note: You will still need that password to login if using the direct console! Don’t lose it!

Usage and Security

Remember what I said. You can use the same public key on many devices. I like to meet somewhere in the middle. I’ll make a key pair for a use case. One for VMs, one for LXCs, one for a very purposeful use case like maybe a DMZ server, etc.

It’s up to you. One thing you may have noticed though, is the “free and easy” nature of the private key. If anyone gets the key and knows the user name well then they can log in, unchallenged.

Private keys can be set with a passphrase, that forces a password to unlock/decrypt it before it can be used. Bitwarden doesn’t provide this option, but any Linux box can use OpenSSH to set one.

I copied my private key to a file and then chmod to 600. If you don’t change the permissions first:

So in my example:
chmod 600 test
ssh-keygen -p -f test

Now, I copy that key back down:

You can also use Secure CRT to set a passphrase.

Be aware that SecureCRT will cache the passphrase once you’ve set it for ease of use. So if you doubt it worked, test on a fresh profile.

BONUS LEVEL

I find the aforementioned method of creating SSH Keys to be a pain, honestly. I vibed together an app that makes this process far easier. It can also handle actual certs as well. This and more of my tools can be found at my Github.

Cert Generator

Conclusion

Ok, so I hope that laid everything out in an easy to understand and implement sort of way. It’s a much more secure and flexible way to connect to your servers.

Until next time.

Intro and Musings

“Dread it, run from it... AI Coding arrives all the same” - some Purple Guy, probably.

Where to start with AI coding? Let’s start with an admission. I can’t code. I've tried to learn python at least three times, and it just doesn't grab me. My brain isn’t wired for it, but that doesn’t mean I’m an idiot. It’s just not where my talents lie. I’m an idea guy. I have concepts, thoughts of what I want to use for tools, application usages, etc.

Sure, I understand the basics. Dictionaries, libraries, integers, floating point. That rudimentary understanding really helped me get outside of the turnkey mindset and realize just how malleable computing really is. And decades of time in IT provide me with a clear understanding of how things work, for the most part. It’s what drives me to keep learning new things, and acknowledging what strengths I need to play to.

But the ability to create has always been frustratingly out of reach, until now.

“VIBE”

Let’s be honest, “vibe coding” is an insult. So was “script kiddie.” And I get it. Both are shortcuts that established practitioners of the dark art of programming look down their nose at. Trust me, I GET IT. But there are differences between a vibe coder and a citizen developer. Let’s get into what that is, because as you go on this journey with me, I need you to be less vibe and more citizen. And that’s all about responsibility and humility. Citizens, you will not replace programmers. If anything you'll free them up to work on more complex solutions as your reliance on them for basic things wane. But blind coding is giving a chimp a machine gun and then feeding him energy drinks.

We need a structure to build on. One based on software quality, security and transparency. This little bit of Rambling Nonsense is going to focus on these goals and empower you to approach this in the safest way possible.

Clauding Around

I use Claude Code, so that’s the workflow I’m going to focus on. Let’s work out some terminology. This will be a longer section.

Claude Code - An AI tool that focuses on writing software. When installed locally, it works from a local folder/files. Recently, Code has been extended to mobile and web, which uses a cloud container as its local working source. Is fantastic at using a Git framework to manage development. We’ll do a broad overview of Git later.

Claude Chat - General purpose chat client. You can direct it to look at software repos if you want, but it’s not what it’s made for and doesn’t work with local file systems, and cloud containers are limited.

Claude Cowork - Lately Anthropic has collapsed this into chat, making it the same platform. This makes chat “agentic” in that you can schedule actions to happen automatically.

Claude Design - If you’re terrible at PowerPoint, diagrams, or web, Design is for you. There’s more nuance to this, but we aren’t focusing on this.

Token - You’ve probably heard of this. A token is the currency of the AI world. One token consists of roughly 3-4 English characters. Every model has a different price per token rate. Every skill, every tool, every MCP connection accelerates this usage. As a Citizen Developer we are going to learn some common sense principles to optimize our token use to minimize cost.

Context Window - A model can only hold so many tokens in a conversation at once. The context window for a Pro account is 200k. During a coding session once you start to hit that limit, you’ll see the session halt and start to compact, saving you x number of tokens. It essentially summarizes the key points of the conversation and restarts the session. This is important, because you need to realize a session is a state. What that means is every time you reply or use a “turn” you send the entire conversation back to the model every time. Imagine you’re talking to to your kid and every time you tell them something you need to repeat everything before hand. Okay, maybe I don’t have to imagine it, but you get the point. This also includes skills and MCP connections. Even MCPs connections you aren’t using are eating up tokens on every turn. You can see details on your context at any time.

Model - Opus, Sonnet, Haiku. These are some of the models that are available. A model is the thinking part of AI. It’s a giant prediction engine, that uses billions, trillions of learned parameters to aid in the prediction. Really not too different from people if you think about it. Our daily lives work around predicting outcomes based on life experience. Hold on… existential dread is loading…loading…ok I’m good. Each model as we mentioned has different costs and use cases. We talk about using the “right” ones later.

Prompt - What you ask the agent to do. Prompts are much more complicated than most think. A simpler request is worse in most occasions. One of the most important distinctions between a vibe and a citizen is understanding of how to make a better request. More details is almost always better. Also, you must try and keep bias out!

E.G. “what’s the best” or “why is this better” is going to lean the answer towards your bias and turn into an echo chamber and lead to a poorer result. A better prompt is “compare these two”, or “what’s the consensus, and provide sources.” If you feel the need to be constantly validated in your prompts, seek therapy not AI coding.

Hallucination - AI is like a teenager. It can be confidently, provably wrong with a level of hubris that’s alarming. It can also make things up out of whole cloth, and can also try and charm you with delusions of your own awesomeness. This is where you need to be aware that it must be challenged when wrong, and learn how to make your prompts with an engineer mindset. The bias issue I mentioned is important to minimize (not eliminate) hallucinations. If the answer feels wrong, challenge it. Sometimes it’s working on faulty reasoning from elsewhere in the conversation, and it’s as simple as saying “I’m going to need you to look that up again.”

Skills - A skill is simply a set of repeatable instructions. You can ask AI to create a skill and then operate by those guardrails/instructions. What’s important to understand about skills is that they need to always be improved on. I can give my teenage son instructions and he sometimes totally ignores parts of it to get to the end result. THIS IS NO DIFFERENT. Take a look at my repo for my “vibe skills.” (I might change the name for that)

https://github.com/darthrater78/claude-vibe-skills

Now review the releases. There have been TWELVE. THIRTEEN. I am trying to maintain a strict discipline in my coding, but there’s sometimes a loophole or flaw in logic that thinks it can move past the gates I’ve set. I then go back and show it what the result was, and it tightens it down again. You need to pay attention as the projects go about their business so you know when a skill needs tweaking.

Tools - A tool is an application that AI uses to get your request completed. Maybe it’s doing a web scrape, or using open excel, or using npm etc. AI will pull whatever tool it can find to get the job done. And half the time it doesn’t tell you what it’s doing. Take a look at what it took to edit the skill just now. I did this on the web, so these were loaded against the container. With local Code it would all run locally. Tools are a huge reason why AI governance and visibility is critical.

MCP - No, not “Master Control Program” you nerd. It’s “Model Context Protocol”, though I suspect the acronym isn’t a mistake. So what is a MCP? This is important to understand. Let’s start with one of my favorites, the good ol’ analogy. Back in the day, if you had a printer, a keyboard, a mouse, or dog help you a scanner each device likely had a different connector, different IRQ, each one its own tiny little nightmare. Nothing worked together to unify these external devices into the internal system.

Then USB, “Universal Serial Bus” entered the picture. Now everything used the same connector and “artisanal” hardware was standardized to one platform. The connectors did change, but the underlying framework remained the same. The MCP is no different. It takes previously “artisanal” API frameworks and distilled them down to a software interface that you connect to. What the MCP can do with that application is coded into the MCP itself, the end user does not have to manage that. It’s the “easy” button that allows us to plug us into services and platforms with AI.

** Cough ** Governance, ** Cough **. Sorry, I think a malicious MCP connection got in my throat.

Conclusion

I think that covers the basics. We are just scratching the surface, this is by no means exhaustive, I think it barely covers “adequate.” As always the goal here is to introduce, demystify, reinforce, and excite you enough to start exploring on your own. Claude Academy is free is you want a deeper dive into these concepts.

On the next one, we’ll cover setting up our coding environment and working in the git framework.

Until next time.

As a network/server engineer working with SSH is an almost daily event, especially when you move your server infrastructure to Linux. There’s a whole slew of SSH clients out there as well.

Lazy sadists (you know who you are) use Putty, others use X-Term, etc. For the longest time I was a SecureCRT user. It was full of features, and ran well. It wasn’t free but hey that’s ok for a quality solution. As time went on though, SecureCRT got a bit tedious. Making new hosts is kind of a pain, and moving to cert based auth just felt…clumsy. In a lot of way it was tied to the Windows app framework and all its inherent clunkiness.

And then I moved to Fedora, and they don’t provide a native client. I was able to use the Ubuntu snap but it felt fragile and just…ew. I had just started my frenzy of “docker-ize all the things” so I googled Docker based SSH, and up came Termix.

New Paradigms

So what I was looking for was to separate the app from the OS and make SSH reachable from any device I chose, but over the web. And Termix was the first solution that made this a reality. It was a bit rough, and I had some early security concerns after looking at the volume in Docker after I started it for the first time. (It has come so far since then) But this is exactly what I wanted. And let me tell you the devs over at Termix are an absolute delight. Karmaa, Zac, p3rf3ction, etc embody what open source projects are supposed to be. They take all feedback and never insult or demean anyone. And the quality of the project shines through because of it. Enough gushing, let’s get to the app.

Warning: What follows is more of a feature…ramble if you will.

The Main Event

An example compose.yaml can be found at the Rambing Nonsense GIT. The formal project page is at Termix, and the Discord link here. I’m not going to cover every feature, but let’s get started.

• ACME/LE support. Certain critical services like Proxmox and SSH, I don’t like putting them behind NPM. If the proxy has issues, I’ll use those services to troubleshoot. Being able to manage my cert directly is a game changer for me.

Credential Manager/SSH Cert Generation

Termix comes with centralized credential management, and you can use it to generate your key pairs and/or store the passwords. You can then easily assign the credential template to different hosts.

Embedded File Manager

I’m sorry but SCP/SFTP is a major PIA. Termix fixes this completely. You can even live edit files from within the same session, with a rich set of copy/paste/compress tools.

SNIPPETS!

Have repeatable code, those routine or arcane commands that you want to invoke easily? Use snippets! Use them for one session, or multiple.

Multi Screen Support

Right click and easily split open sessions.

Command Broadcast

Send live text to multiple open sessions

RDP/VNC Support Via Internal GUAC Server

You may have noticed in the compose, there’s an optional GUAC server for added functionality.

Server Tunneling

I don’t use this, but it’s worth calling out.

Built In Homepage

Not something I use either, but worth calling out.

SSO Provider Support

Desktop Clients

If you don’t have Docker, or want to run a local client that syncs back to Docker, you can do that too! It’s also on the roadmap to allow the client to sync to Docker for “offline mode” so you can still work with your sessions locally if the instance is down.

Conclusion

I’ll cut it short here. There’s just so much. On the main Github page they have more pictures and videos. I just wanted to give my personal impression. Do yourself a favor, and try Termix today. You’re going to love it.

Until next time.

I’m now in the SASE/SSE space, but my career history started with System Administration and then went to networking. So I naturally acquired lots of experience with Windows and Active Directory. Honestly, I was aware of the two main authentication methods, Kerberos and NTLM but because it just “worked” a deeper dive wasn’t the topic of the day. A machine joined the domain, a shared secret was established between the endpoint and AD, then Kerberos tickets could be shared with NTLM as a failback.

Onsite failures with this process were very rare, and often were caused by an endpoint having a losing trust with AD, and re-joining would fix it. Failures of Kerberos while on legacy VPN were far more common, but “NTLM fallback” would mask these failures since communication to resources weren’t typically affected. Visibility was also a major pain as we didn’t have the tools we have today.

Legacy VPN firewall rules (and I saw this everywhere) tended to be fairly loose when it came to DCs and their policy. Some just allowed a /32 to the servers, and some allowed some ports, not others, or too many. Moving to a “Zero Trust Architecture” and Entra Only Machines have really brought these concepts back to the forefront and this deepish-dive analysis is what we’ll focus on today.

NTLM (New Technology LAN Manager)

There’s plenty of resources that will go in depth about this, so we’ll just cover the basics.

• No tickets involved

• Uses the locally stored hash derived from the user’s password to authenticate

• Requires authentication for every access attempt (lots of challenge-response handshakes over the wire)

• Currently at V2, in a never ending state of feature deprecation

• Local hash is static, does not change until the password changes. Big security implications there.

• No mutual authentication — the client cannot verify the server is legitimate.

• DNS resolution for domain services not required

• No dedicated port

We’ll stop there, but none of that seems great, does it? Probably why Kerberos replaced it as the default way back in 2000. So why is NTLM still around? The usual suspects, mainly backward compatibility for apps that simply don’t support Kerberos.

Kerberos
(AKA The Goodest Boy in Hades)

So let’s discuss Kerberos in comparison.

• Ticket based, requires successful exchange

• DNS resolution required for service records

• Dedicated port TCP/UDP port 88

• Tickets are time based and expire after 10 hours, renewable up to 7 days by default

• Time skew must not exceed five minutes from AD.
  Just minutes, hours do not matter. You may have noticed the wrong time zone doesn’t affect Kerberos. Time is UTC behind the curtain.

• User hash is used only during the ticket granting process. So that’s once per login, not on every access.

• Can delegate auth for other services

A better and secure solution. Let’s take some packet captures!

Down To The Wire

There’s two important commands we can run here. Klist and klist purge. One to display tickets, and to delete them to force refresh. I vibed together a SMB-Diag app, because troubleshooting this can be tedious, so now I have a tool to make it easier and more readable.

Before doing anything, we can see I already have two tickets. The primary TGT “Ticket Granting Ticket” and the ticket used for AD auth. I’m going start a capture, then purge them.

So here’s the conversation for that first ticket. (ignore the yellow in the responses)

And the conversation for the second one.

Ok now let’s access a share. Many more tickets! One for each server/resource. We will use these tickets until the lifetime expires/purged/logon event.

Now, when accessing the share we can see where SMB gets involved.

Let’s take a look at the overall diag output to see what’s needed. The srv record for Kerberos/LDAP is especially important, and it cannot be resolved by IP.

Now, let’s block DNS/port 88 and see what happens. I also purged tickets beforehand.

Now this was interesting and I expected a silent fallback, but received a password prompt instead. I entered the user’s password and then saw the NTLM flow, with no Kerberos captured.

I removed the blocks, and where I did get a silent NTLM fallback is when I accessed the share by IP and not FQDN. As I mentioned earlier, Kerberos requires DNS for not just the SRV record, but share names as well. Great finding, and something I overlooked.

Entra The Dragon

Now let’s talk about Entra only joined machines, and let’s be super specific here. A machine that is is domain joined and has a user that that is also replicated up to Entra for IDP/Application access is no different than the situation we just went over.

The machine/user are both fully a member of the domain. Kerberos, NTLM, that all still applies.

Entra only machines where you sign into to the Entra Tenant at OOBE, is an entirely different situation. The user may be an AD object, but the machine actually never joins the domain, and therefore cannot exchange tickets with AD. To effect, the user has no NTLM hash to fall back on whatsoever. This is purely a Kerberos environment.*

*See: “Challenging Assumptions” at the end for a correction here.

Paradoxically, an AD user on an Entra Only machine CAN access shares when in line of sight to AD, or when connected via ZTNA/VPN.

The way this works is that when the user signs in for the first time, Windows Hello For Business forces the creation of a PIN or Biometrics, or both. It then uses the local TPM to create an independent asymmetric key pair. After that the password is irrelevant for login and and after a successful PIN/Biometric login the private key is unlocked for authentication.

Entra/On Prem AD use a “Cloud Kerberos Trust” connection to facilitate trust for AD based resource access.

When a user signs into a device that’s registered with Entra — whether Entra-joined, hybrid-joined, or just Entra-registered — the device obtains a PRT (Primary Refresh Token) from Entra ID. This token proves the user has completed primary authentication to the cloud identity provider. The client can take the PRT, and ask Entra for a “partial TGT” which is then used by the client to send to AD for proper access to on-prem resources, by way of exchanging for a full TGT. AD will accept the partial TGT signed by Entra as a bootstrap to kickstart traditional Kerberos communications. The Cloud Kerberos Trust is not setup by default, and must be configured in AD.

The SMB-DIAG tool will auto-detect the type of machine and show the relevant results.

You cannot easily see the PRT (Primary Refresh Token) in CLI so I had the tool pull it for easier troubleshooting.

Challenging Assumptions

One of the main reasons for this blog as I’ve stated in the past is that it forces me to sit still, think more critically and challenge my confirmation biases. When I’m in my normal workflow and just flying along I lose some nuance in the noise. I just encountered a flaw in my Entra NTLM assumption, which bears mentioning.

So, when I signed onto the Entra machine initially, what did I use? My AD password. And what did that do? Created a hash, of course. Because (sigh) of course it did. As this is a lab and not a true production environment I did not set up a process like a Group Policy/Credential Guard, etc.

An actual Production level environment that wants to be as password-less as possible would likely have other mechanisms to prevent the hash from being cached for use. Such mechanisms like SCRIL for hash randomization, and daily hash rotation via fine-grained password policy to start.

Conclusion

So I think we’ll end here, and hopefully you found this whole exercise as useful as I did. From Entra to the “Atomic” policies of ZTNA that can expose requirements for communication for secure access in a way that perhaps we didn’t have to think about in the past, a review and testing of previously held assumptions is never a bad thing.

One thing that stood out to me is how using IPs to access resources instead of FQDN represents a real weakness in a way I never really considered. Hardcoded IPs in scripts, printer configs, monitoring tools, etc can be a path to insecure access that wasn’t planned for if you were expecting proper Kerberos methods.

I’ll tell you one last thing. Visibility is key to be able to effectively troubleshoot and challenge what we think is happening. I have used AI to build tools for situations such as these where no real formal tool exists for my needs.

If I had to ask someone to build this for me, they’d pour sugar in my gas tank after a day. And I think we’d experience the heat death of the universe before I was able to do it myself.

SMB-DIAG can be found here:
https://github.com/darthrater78/smb-diag

I’m a big believer in trying to vibe as transparently and safely as possible, and the skills I use to assist my efforts are here:
https://github.com/darthrater78/claude-vibe-skills

Until next time.

This is going to be a shorter post, as the bulk of the content is on my GitHub.
In Proxmox, for the VM console you have two primary ways of accessing the hosts.

noVNC, which is the devil, (I mean it’s right there in the name!) and SPICE. Let’s discuss the pros and cons of both.

noVNC:

Pros:
Immediate access from Proxmox. It just pops up, easy peazy.
No other pre-reqs are required.
Default option
This now concludes the “Pros” section.

Cons:
Cannot resize windows/change resolution
No Clipboard (serious PIA to make it work)
Hates you and everything you stand for.

SPICE:

Pros:

• Clipboard for days!

• Supports multiple screens

• Resolution aware, screen can be dynamically resized

• Not noVNC

Cons:

• On the local machine “virt viewer” is required.
  Easy for Linux, Windows can be tricky.

• Not browser native, clicking the console button prompts a download that you then open with virtviewer to use.

  

• For all features, the SPICE driver must be installed on the VM. In Linux they are already there, for Windows you’ll need virtio tools. The SPICE driver is part of the overall QEMU tools package.

• The hardware of the VM display must be set to SPICE.

  

  Man, that’s alot of cons…but it’s easy to setup and then you never have to deal with noVNC again.
  
  Here’s details SPICE and virtio tools.
  Proxmox Spice
  Windows_VirtIO_Drivers
  

Let’s Vibe.

So I use Proxmox for a lot of testing. Going back and forth, downloading the VV files (they auto delete after use) every time I want to hit console gets to be really tedious. So I worked with Claude and vibed up a python script. And so far, it’s worked really well.

You can use passwords or API, and I have the script as well as the full instructions up at: https://github.com/darthrater78/proxmoxspicemanager

It’s Linux only and works on Fedora/Debian. It’s got themes, “Install to app menu”, dependency checks/install assistance, etc. Hopefully you find it as nifty as I do.

UPDATE: Fully functional Windows version now on the repo!

Until Next Time.

I have long had a love/hate relationship with Ubiquiti. While I hold them as one of the best solutions in the prosumer/SMB market, personally I would never use them in Enterprise. They have a long, frustrating history in which every new hardware release is a public beta, and new code trains are a complete train wreck.

That being said, I quite like the Unifi Controller software, and I think it does an admirable job running my APs. Very full featured, dare I say even…”neat.” I first ran it on a (shudder) Windows server, then on a LXC, and now in a docker container. Progress! The APs, while mostly solid have also been victim to the bad software release quality.

Some innocence was lost, I think when after an update and implementing MPSK to consolidate my SSIDs. Then it just decided to randomly drop traffic off into different vlans. Because, that’s what I want my solution to do, the opposite of what it’s asked.

But, this section isn’t really about that. What inspires me to write a new article is something I think that’s really neat, or something that tripped me up and frustrated me. I’ll share those experiences in the hope of helping others, while at the same time venting in free tele-therapy. ;)

Fetch Me A Switch

While my fellow Gen-Xers and I work through the shared trauma of that title, lately I decided I wanted to buy a new switch. And I figured I’d give Ubiquiti a shot. I decided on the USW Pro Max 48 PoE. The specs are great. A bunch of 2.5Gb ports, PO+ and POE++ on the 2.5 ports, and four 10Gb modules. Just what I was looking for. It can also do L3, but I got it purely for L2 use. I don’t want the other bits and bobs you need for a “unified” solution thank you very much. OPNsense FTW.

I also really liked the idea of managing it in the Unifi Controller, especially because the mobile app is really well thought out. They also have this feature called “Etherlighting” which turns the front into a RGB wonderland. It’s quite a useful gimmick, in my opinion. You can have the ports light up different colors for speed, or for vlans. They even have a locate feature which makes the port you’re looking for glow bright white. I lowkey love it.

The AR feature of the app is kinda nifty too.

So I unbox it, rack it up and connect it to my current switch. As I don’t want to perform a hard cutover, and moving things gradually is my usual MO, a trunk is what’s required. So I start off with an access port, get the thing on-boarded, and that’s where my trouble began.

Note: if you’ve been working with Ubiquiti gear for a while, this may seem like common sense. This is about what might trip someone up after a lifetime in CLI on Enterprise gear.

Trunking Ridiculous

Ok, so let’s start off with…maybe I should RTFM’ed, sure. I’ve been doing this for a while though and the conventional knowledge for this kind of operation is console in, set the mgmt IP on the SVI of your choosing, set trunk allowed all with a native vlan of 1 on both sides. Or, if you’re using something that tags/untags do that. Pretty basic stuff. If you screw up, it’s trivial to break out the ol’ console cable and figure it out.
SSH in, and get going.

This was NOT my experience. Way more nuance here. A couple things.

• Keep a paperclip handy. There is no console port, no safety net. You screw this up and lock yourself out, you’ll be factory resetting it.

• Don’t lean forward and configure everything. Wait until you’re sure you’re all set.

• Once you factory reset, the certificate on the device changes. So you’ll have to remove it from the controller. Once you do that, the config cannot be restored. You have to start over. The “use mac to replace” is only for gear that has already been on-boarded.

• Once the IP is set by DHCP initially, the SSH user name/password is usually “ubnt”

• If the controller isn’t picking up the device you can SSH in and run:
  set-inform http://[IP]:8080/inform
This will force registration to be adopted.

• EVERY SWITCH PORT IS A TRUNK BY DEFAULT. It’s opt-out which is mind-boggedly insipid.

• Before you upgrade code go to the forums. More often that not there’s horrific bugs about real basic stuff. E.G. in 7.2 there’s a bug in which new vlans won’t pass traffic. Come on, you have ONE job, people.

• TURN OFF AUTO UPDATES!!!! You’ll thank me later.

Ok, here’s what tripped me up. On the IP settings, you’ll see this by default

Clicking on it, presents a warning followed by a list of configured vlans to choose from.

And I found that link to be incredibly useless. It didn’t explain that part at all in my opinion. Plus, I see the word “magic” in a document and I check right out. “Network Override” Meh. So let’s talk about it. With it unchecked, that’s basically the the SVI of VLAN1. So when I connect that to vlan 777 on the opposite switch who cares, we aren’t tagging at that point. Connections for days.

I misinterpreted that to be the DEFAULT VLAN for a trunk. Yea that’s not right at all. “Network Override” changes the vlan the SVI is tied to. Le Sigh.

So next, we need to go to the uplink port in the UI. To add to the confusion a bit, vlan1 has an SVI that you can’t turn off or remove. I can see the use case perhaps and maybe you can use it to SSH? I’ll be honest I did not try.

Now native vlan/network is doing double duty here. Instead of being separate commands like we’re used to, all ports are a trunk, with the native vlan acting as the untagged access. Thanks, I hate it. Perfect for the trunk, terrible for regular access as a standard.

When I want it to be regular access port, the phrasing here is also confusing. “Block All” isn’t blocking traffic persay it just means drop tagged traffic. Only allow untagged traffic like a friggin access port. (sorry some anger came through just then)

For something like an AP, i think it does make logical sense.
(I did rename vlan1 since it’s also named “mgmt” by default)

At the end of the day, all I had to do was set my IP, change the Override to the right vlan, and change the other side to the typical allow all/vlan 1 scheme.

Instead what I did was throw a totally undignified babyfit, invent new combinations of swear words and start a return process until I calmed down and figured it out. This is sometimes my process.

Conclusion

Ok with all said and done, after these issues I am happy so far with the switch and APs. I have negative interest in going further into the ecosystem, but for AP and L2 switching so far I like it a lot.

It really comes down to both code and hardware quality at the end of the day. Ubiquiti seems to be just barely functional with new gear/code most times, but for the stuff that’s established, as long as you know what to do and what to research I think you’ll be ok. The forums are an excellent place to start, and Claude/Gemini is a good way to get a summary of issues with code, and what’s the most stable.

Just keep it out of the Enterprise. There be dragons.

Until next time.

Intro and Musings

I’m going to keep this one short, I’ve already had a lot to say in the previous parts. We’re going to get into the install and some nuance to start with. I chose Fedora for reasons I already outlined, but if you want to use a different distro like Mint, that’s fine. As long as you use Plasma (KDE) as the DE, about 95% of what I go into here should be covered.

And don’t forget, Fedora upgrades its version every six months. KDE upgrades every quarter. If you want a lower tempo, go to KDE Debian, or Mint.

Note: Mint Or Debian will just have the default KDE. Any third party repos and the flatpack infrastructure will need to be installed manually.

Ok, let’s go.

We’ll Do It Live!

Once thing Linux DE distros are really good at is the live install. Basically, you can boot to the ISO and get a fully functioning DE environment to poke around in. It all loads from USB (or if you want to party like it’s 1999 a burnt disc) and into memory. It doesn’t involve your primary boot disk at all. It’s a great way to spend some quality time before making a decision. You can test out different spins this way as well if you like.

You can use Rufus, Balena Etcher, or the tool Fedora makes themselves. Both the tool and ISO can be found here.

Install And Setup

When you boot to USB, you’ll see this. Pick the first option.

When the Welcome Center pops up, click on “Install To Hard Drive”. Don’t proceed through the Welcome Center just yet, we’ll do that after install. Usually something like this is a waste of time, but not in this use case.

Onto Step 3. Some people like to dual boot, not me. Hot take, make the full commitment and “Use Entire Disk.” This is of course, destructive so ensure files you want are backed up first.

I would skip disk encryption on the next step unless you really have a use case for it.

On Step5, make your user account here. I would avoid making a root account. Your user will be an admin in the sudo group you can do everything from there. If you have a burning need to run as root, you can always do sudo su to elevate to root when needed.

On the review, you’ll notice that the default for home and root are “btfrs.” This is great as you can leverage snapshots to roll back the OS when needed. It’s a great little file system. It is a bit more write intensive than ext4, so it’s recommended that ext4 be used for secondary drives.

Install!

Welcome!

Once back up and logged in let’s work our way through the Welcome Center.

Go ahead and next your way through the prompts until you hit this screen. You absolutely want third party repos, so yes to this.

Feel free to click the link, but here’s what this entails. My understanding is that with KDE, this is a bit of an “easier” button.

After this, you’ll see “Discover” pop up about updates. This is the next thing you need to do. It’s a biggin’ so get going.

The update process apart from the download is surprisingly quick. I think you’ll find everything with Linux is so much faster than what you’re used to.

Feel The G…Force

Next step, let’s get those Nvidia drivers installed! If you’re AMD this obviously doesn’t apply to you.

There’s this useful guide on installing the drivers, but our Welcome Center action already did most of it. Still review it though, especially if you have Secure Boot enabled.

I’m going to assume you have a 2014 or higher card. Open up terminal (Konsole)
and run:

Fun Fact: Man, KDE loooooves the letter K. It means nothing from what I’ve read.
Krita, Konsole, Kontact, Kmines, Kfind, ketc, ketc, ketc. If it starts with K, KDE made it. And honestly, they’re really good applications.

sudo dnf install akmod-nvidia (answer yes at every prompt)

sudo dnf install xorg-x11-drv-nvidia-cuda #for cuda and nvidia-smi 

Reboot.

Open terminal, and run:

modinfo -F version nvidia

and the driver version should show.

For a bunch of other details run:

nvidia-smi

The last thing we’ll do in terminal right now is install the multimedia group.
Note: I noticed while doing this, the file size was zero. It appears as though our third party repo already did this part for us. Awesome. In case you need it:

sudo dnf group install multimedia

Mounting Pressure

Ok, let’s talk about mounting disks. This process is pretty different from Windows. Let’s take a look at my current drives. “Old” is an internal SSD, and “Fedora-KDE” is a USB drive. The orange symbol means that the drive is unmounted. If I click it, I’ll get an admin prompt to authorize a temporary mount for the internal drive, while USB should just mount.

Now that they are mounted, let’s look further.

If I navigate to the usb drive and expand the path I get:

Likewise with the SSD:

Now for USB this is fine. That drive will come and go. For the internal drive though I want that to be more predictable and also automount. Now there’s several ways to do this. We’ll try to stay out of terminal for this, so we’ll use the KDE partition Manager Tool.

First thing though, let’s create our mount folder for the partition. You may recall in other guides for server based use cases I always use /mnt as the folder. That’s simply a good standard. In truth any folder can be used. For this use case my base folder will be “disks” because that makes sense.

Most of / that’s not the home dir is exclusive to the root user, so you’ll need to open the folder as admin. Yes, you could use sudo to make the folder, but we’re trying to stay out of terminal for this.

Now, lets open KDM and take a look. I want you to look to the right of each disk, at the /dev locations. nvm, sda,sdb. These are not partitions they are the actual device locations.

If we take a look at the partitions on the right the nomenclature is sbd1, 2, etc. It’s the partitions we’ll mount and not the physical disks. I hope it’s a bit more clear about how Windows obfuscates this process.

Now obviously this disk is from my previous Windows install and I want to delete and reformat. You can unmount any locked partition by clicking on it.

Note: no action is performed until the end. You can back out or undo at any time before activating the changes.

Ok, I’ve deleted everything.

Click on “New” and create the partition. I’m using ext4 for my extra internal drives. I also change the permissions to “Everyone” for ease of use. Hit ok, and then “apply.”

Sanity check!

Now we have bright shiny new partition. Almost done. Right click the partition and choose “Edit Mount Point.”

I’d recommend using UUID as the ID, as it will never change. Change “Pass Number” to 2, all other settings can be left at default. Hit “ok.”

Look at that! Our old friend fstab. We’ll review that next.

After this is done, right click on the partition and mount it. The mounting should now persist after reboot. Let’s review fstab. We can see on the final line, there’s our new drive. Linux will use the this file to mount these drives at each boot or if you invoke mount at terminal.

Explore!

That wraps up what we need to get a functioning install and mount our extra disks. In the meantime explore this new OS! It’s a lot of fun to poke around and find all these new features you always wished Windows had.

Dynamic monitor dimming? Feature!

Volume controls in taskbar tabs? Feature!

A system and application fuzzy search feature that actually works and returns results without ads or other unrelated nonsense? FEATURE!

Badass wallpaper plugins? Feature!

And so much more.

Conclusion

What a ride. The next part will focus on applications. Flatpaks, Windows equivalents/workarounds and other neat OS stuff.

Until next time.

Intro and Musings

Ok, we’re about to get into it, but first let’s have a chat. Real talk. We’re all pretty damn comfortable when it comes to our long term OS choice of Windows. We know it, inside and out for the most part. Working with files, network shares, navigating the registry etc. Windows is the Cisco of the operating system world, in that we’ve been doing it their way for decades.

Just like with Cisco, the actual underpinnings of the OS has been hidden from you, abstracted away by a happy gui and in the case of Cisco, their proprietary shell. Let me explain further. I was a Cisco guy for a long time, and then had to work on my first Aruba switch. (this was about five years ago, things have changed.) I was totally lost. What the hell? A trunk is actually a portchannel? Tagged/Untagged, what madness is this?

And to top it off, why can’t I make a L3 Routed port with “no switch”? This was the one that threw me. Then my mentor Igor tells me “You’ve been doing things the Cisco way, here’s how it actually works.” The “routed port” is simply a SVI tied to a “hidden/reserved” vlan with bpdu filter turned off. Cisco just made it “easy” by obfuscating the logic to “no switch”. This was huge for me, eye opening.

My other equivalent is VMWare. Lots of obfuscation there too. When I started to use Proxmox, all of a sudden I felt “closer” to the hardware, and things made way more sense. It was the removal of the veil, an opening of the black box they want us in. The less you know, the more they can steer you where they want you to go.

Now the reason for this little screed is that I want you to be aware of this, of what power and new understanding Linux is going to give you. But understand this.

”With great power comes not knowing what the hell you’re doing at first, coupled with a fair amount of frustration.”

This is likely new to you, you will be uncomfortable, you will be frustrated, at some times you’ll be ripping pissed. Be prepared to challenge concepts you thought you knew, and make compromises for what you need to work. (at least to start)

STICK WITH IT. It’s worth it, and by the end you’ll be a better engineer and technologist for the effort. This will cover some of the things I think you need to know before we get into install and configuration, to attempt to mitigate those pain points.

File(damentals)

Ok, we need to cover some base concepts about the file system. There’s some stark differences from what you’re used to and the first one is how drives are handled. There are no drive letters. No A, no B, no C. (gasp). Join a support group if you need to, but get over the fact that there are none.

Remember that Linux is a system of files. And all files originate from root. Even drives. And root is: /

That slash is the core of the OS. Watch the below for the overview.

So, for example let’s say I’m at the terminal and I want to get to my Downloads folder. I would use: cd /home/nathaniel/Downloads/

Note that I have the root at the beginning of that command. If I omit it:

This is a mistake I make more often than I’d like to admit. Why the hell can’t I find that file?! Oh. Forgot to add root. Now there is a use case for when you don’t have to add root and that’s our friend tilde! ~ is the alias for “home” and that includes root.

It’s crazy important to note the case sensitivity. It matters.

Now if you’re already hyperventilating about the terminal, relax. A modern DE like Plasma greatly reduces the need to be in terminal, but to ignore it completely is foolish. It’s absurdly powerful, and you should get some time in it. I’ve covered this in my docker post, but here’s some basic commands.

pwd : where am I right now?
ls -la : list files where I’m at (or pointing to) and put them in a list and show
permissions/hidden files

cd: change current directory focus (don’t forget root!)

tab: not a command, the key. This is the unsung hero of Linux, autocomplete! You can
also use this to show all matches in a directory

du -h -d[integer] : what’s the disk usage for where I’m at, break it into readable
numbers, and how deep in the directory do we want to go?

So some examples: if I do du /home/nathaniel/ it will vomit out every file in the directory, including folders and subfolders. And the numbers won’t be easy to read.

If I do: du -h -d0 /home/nathaniel/ It will give me the space in readable numbers and the overall size of the folders.

And using d1:

Next, double dash help. (dumb substack shows it as one long hyphen)
After any command use double dash help to bring up the man page.

rm -rf: murder (delete) everything you tell me to, do it recursively, and force it. That little joke that’s the cover image of Part1? Yea, if you sudo that command, and simply do “root” you’re done. Bye-bye every file on the disk. And terminal has no recycle bin.

I warned about this in my Part2 about docker. ;)

Let’s finish with….

sudo: Look at me. I’m the captain now.

Your first user will be an admin, which puts you in the sudo group. Think of it as a more effective UAC in Windows. It is god mode in a command. Anytime the DE pops up asking for your creds, that’s sudo being invoked.

If you try and do a command in terminal that requires admin rights like dnf update, it’ll say you’re denied if you didn’t start with sudo.

With great power, something something.

Ok, let’s wrap this section up and we’ll talk more about mounting drives in Part3.

MSI, EXE, and BAT oh MY!

Let’s talk about installing applications. Those three extensions are now worthless to you. Yes, yes, WINE, (Wine is not an emulator)) we’ll talk about that later.

Windows has this “scavenger hunt” aspect to applications that we’re all just used to. Installing applications on Linux is so much simpler. Much like docker and the container repos, there are software repositories that we can just pull applications from. No hunting required. Let’s say I want to install “btop” which is a fabulous terminal task manager.

Let’s go to google, search for btop and then let’s not do any of that.

Instead, go to terminal and simply: sudo dnf install btop

Ok, let’s type “btop” into terminal now.

The first time I saw this method of installation, my concept of reality shifted just a bit. I don’t have to hunt for files? I don’t have to click “next” 10 times? Incredible. But not every application is in the default repo. Take docker for instance. With docker you actually add their repo to the OS and then you can install via terminal. And because the repo is present, updates to the non default applications happen through this method as well. Wild stuff.

About that command “dnf”. It’s the modern replacement for “yum” and manages installs and updates. Debian uses “apt”.

Dnf is nice because it collapses update and upgrade into one command, dnf update.
Apt is split into update and upgrade. The logic makes sense for the most part, install, update, remove.

If there are releases you don’t want, (I’m looking at you, Docker 29) you can exclude them from the update. For example:

sudo dnf update --exclude=*docker-*,containerd*

Now, there are exemptions to even this. Some applications can be downloaded as a whole file as .rpm files. (Debian uses .deb) Those use the local package manager to install. They are outside of the repo framework though, so will not get updated with everything else. It’s more manual of a process.

So while all this is great, there is an enormous caveat to be aware of.

Dependency Hell

When you install an application you also need its dependencies. Other files it need to run will be present too. Let’s take a closer look at btop. The package manager is telling you the extra files that it needs from the repo. The problem arises when a required dependency will break an existing application because it’s older or newer than what’s there. It’s a shared library, so this can be an issue. Or a certain kind of hell, I’m told. This is one reason why docker/podman is a thing. The applications and their dependencies are abstracted away into the container so it’s a non issue.

Windows doesn’t rely on shared libraries and has other file strategies that largely avoid this issue, but was a problem in the past with “DLL hell”.

Oh, SNAP

One of the solutions to this is SNAP (Ubuntu) and Flatpak (Fedora). These are containerized versions of applications that solve for the dependency issues. They are little sandboxes of happiness that keep the applications sequestered away and functional.

The main reason why snaps are a dirty word is that Ubuntu has a policy of auto-updating. Oh, you don’t want that snap updated? Tough shit it’s already done. You can defer an update to about 90 days from what I’m reading, but still. Canonical also owns and updates the snap store. Corporate decisions, remember?

Flatpaks however, are completely user controlled. We can still download apps from within the OS via the Discover app and you can look at the store externally at https://flathub.org/en. The flatpak store is totally community owned and curated. The interesting thing about flatpaks is that they are supposed to to be distro agnostic. In Fedora, the flatpak management/install tool is built in. You can install it on other distros like Ubuntu to get some control back.

There’s more nuance to each method, these are the broad strokes.

While many, many, apps you use today are available via Flatpaks not every one is a perfect fit due to the sandbox nature. We’ll get further into this in Part3.

Conclusion

I think that’s the bare minimum we need to go over before getting into the install. There’s other things I want to bring up, but I think it makes more sense to show in context as we go.

Until next time.

Intro and Musings

Well hello there! It’s happened, and I’ve moved to Linux as both my server and desktop OS in my environment. This is going to be similar to my Proxmox series where I document the journey.

That means this first part is going to be an explanation and exploration of why I made these decisions with some education along the way. After this, I’ll get into the technical weeds.

Hey, I like to tell a story and the blog is appropriately named. ;)

Up Until Now

For the entirety of my career, up until about five years ago I was hell bent for Windows.

Started with 98, and then eventually was managing and supporting large enterprise Windows AD domains. I went through every tick and tock release. I got certified, really learning the ins and outs of the OS, I even wrote a practical 75 page guide on imaging correctly with MDT.

But Linux was always lurking right out of sight. This was a dark magic, a witchcraft at which coders would pray at the black alter of the flashing white prompt. I didn’t have a use case, and at the time the Linux desktop experience was some rough business. Then as the years went on, Windows started to enter its true enshittification stages and my devotion to the OS started to weaken.

(Seriously who the hell puts a touch interface on a Server OS?!)

Fast forward to a few years ago and I’m talking to my boss Mike, and I’m complaining about how my Windows Servers were thirsty pigs. He says to me, he says “you need to look at Linux.” Then I went on about how confusing it was and how weird it was that it had no registry.

He got quiet for a second and said “Nate, Windows is weird because it has a registry. Linux is a flat file system, no one needs that crap.” Then when Proxmox came along, I had to learn some basics. I started with replacing my servers with LXCs for some of the applications I was running that used to be on Windows servers. Night and day difference. I was blown away. I was on the path from now on.

Distro Inferno

One thing about Windows is that the versions are largely easy to discern. There’s Desktop and uhhhh Server. Simple. There’s versions like Home, Professional, Enterprise etc but those are feature sets not actual different versions per say. I mean, it’s all “Windows.”

Oh boy, not with Linux though. It’s the Baskin Robbins of OSes. There.are.so.many. This is the first part that stops a lot of people. Paralysis of choice. It definitely stopped me for a long time.

To illustrate this, Linux consists of distribution “families”. I’m not going to list them all, but here’s the key ones.

Debian, RedHat/Fedora, Arch, Alpine, etc.

Now you can run those or their “derivatives.”

As for derivatives let’s take a look at Debian:
Ubuntu, Kali, Proxmox VE, SteamOS, etc.

And to make things even more confusing, some derivatives have their own derivatives!

Ubuntu has:
Mint, PopOs, Kubuntu, etc.

For RedHat/Fedora:
CentOS, Rocky, Nobara, etc.

I’m going to stop here, the list just goes on and on to infinity. Linux is less of a family tree than a bush. Let’s talk desktops and “spins.”

Spin Me Right Round

A spin isn’t a derivative. It’s a modification to one of the base OSes. It’s usually referring to the DE “Desktop Environment”.

Here’s some of the usual suspects for DE options:

GNOME (pronounced guh-nome)
Plasma
Xfce
Cinnamon
MATE

GNOME is the grandaddy DE, and the one that ships as default on many OSes. While you can install any of these manually it’s highly recommend you download a version with your desired DE baked in. A distribution like Debian offers your choice at install, while others offer discrete versions.

They all have major differences in how the desktop experience works. I definitely chose one, we’ll get into that shortly.

Server OS

I started with Ubuntu Server for almost a year. It was…fine, I guess? But it just seemed bloated with a bunch of things I didn’t need. It may be counter-intuitive to say a headless CLI driven could feel bloated, but even with minimal settings the install takes forever, and I find the installer to be a chore. I also wasn’t a fan of the yaml driven netplan for network configuration.

Then I found out about the whole derivative thing and my buddy Alex said “go regular Debian.”

I did, and I like it much better. The setup was simpler, install seems to be much faster and while Debian isn’t the fastest to get new features it’s rock solid. And that what I need from servers. Stability. Also the network config is pretty traditional, and not yaml based. So now all my servers and LXCs run Debian.

Desktop

So I did try Ubuntu for a while. The whole thing was very “meh” for me. I tried Mint. “meh.” I tried Zorin. “meh, again.”

Turns out I really don’t like GNOME, or Cinnamon. So I plugged along with Windows for another year. Then Windows 11 happened. And then Copilot. And then the really stupid “recall” feature. More and more it felt like I was renting my OS and not owning it. So much tracking. And then ads?! There’s a script from Chris Titus I was using to remove all this crap and while it worked, then the machine itself started to act oddly.

This nonsense runs so deep trying to mitigate or remove it just makes the whole thing unstable. I kind of sat back and realized if I need to go to these kind of lengths to keep my computer mine, it was time to be done. But where to go? I went to Claude and asked for advice.

My requirements:
Gaming support (long a difficult thing with Linux)
A Windows like desktop experience
The ability to run Windows apps if needed.
A general, all purpose machine that excels at overall takes.
And it came back with:

Windows 11.

I’m kidding. It said Fedora 43 with KDE Plasma.

My first reaction was what the hell is that?! I’d never heard of Fedora outside of Indiana Jones and Redhat. I went back and forth arguing with some other solutions like Ubuntu, PopOS, etc.

And it came back with YOU WANT FEDORA YOU ARGUMENTATIVE FOOL.

(I may have given Claude instructions to not sugarcoat responses and just tell me what I want to hear.)

And it was right. This is the way. For my Linux journey I’ll use the base OS, no derivatives. So that means Debian for servers, and Fedora for desktop. Now why a separate foundation for each use case?

Simple.

Debian is the slow but steady guy. Stability is key. Major updates are years apart. You’ll get bug fixed as point releases, and constant security updates. Perfect for servers.

Fedora is the one that supports modern hardware. It updates every six months. It’s the racecar of the two. For my desktop, that’s the ideal place to be for me. One of the key reasons to choose Fedora over something “easy” like Ubuntu is that Canonical owns Ubuntu. It’s a corporate product that makes corporate decisions. As an example of those decisions we’ll get into “snaps” in part two and why for many it’s a dirty word.

Fedora though, is almost entirely community driven, though sponsored by RedHat. There’s a whole internal governance structure to ensure that Fedora sticks with the user base, not the sponsored overlords. These days that’s probably as good as it’s going to get. This was a big reason I made the choice for Fedora.

Conclusion

That about wraps it up for this one. I hope my explanation and reasoning provides some insight into the whole situation. The next part, we’ll get into install and covering what tripped me up and the main differences from Windows.

Until next time.

Intro and Musings

So in Part 3, I discussed adding a secondary IP to allow a service to exist on the same Docker host, with the same port. And hey, that worked great. Up until it had to cross my firewall zone. This was fun (haha), so let’s discuss it.

Zoning Out

Ok, so let’s say we’re on the same L2 network and trying access WUD as in the previous article’s example on the secondary IP.

No issue. Life is good. But, when we want to cross vlans across a firewall zone, say from DMZ to Prod, things go sideways. With a secondary IP, we share the default host bridge, so any inter vlan traffic needs to out the primary IP, (where the default gateway is) where it NATs and then presents traffic that doesn’t match the source session, which gets dropped/blackholed.

Driving To A Solution

Docker networking is intensely interesting. There’s a solution here, and that’s using a different network driver. There’s several, but we will cover three.

bridge: default, secondary IPs configured on the host. Issues on the intervlan/firewall flows as shown above.

macvlan: this driver will actually act a separate interface in docker and give the clients in the network their own mac addresses. Requires your hypervisor support promiscuous mode for the extra macs coming from one port. This fixes our traffic issue.

ipvlan: this driver will actually act a separate interface in docker and will use the same mac address as the parent interfaace. A good alternative since its the same mac coming out of the port. This also fixes our traffic issue.

With both ip and mac vlans, the network is defined on the stack/compose and not on the host interface. It’s only active when the container that has the network configured is up.

Driving Into a Brick Wall

So great, right? Let’s configure the ip/mac vlan and go about our day. Not so fast. There is a huge caveat we need to cover. A better name for this feature is mac/ip vrf.

When a container is configured with the vlan option, it cannot talk to any other container on the same host. So if you’re you’re using a proxy that talks to other containers on the same host, it’s not going to work. Traffic leaving the host is unaffected. Also unaffected are any tools that monitor docker socket.

So my situation was that I have a proxy in my DMZ and a Cloudflare tunnel. I need NPM to use a vlan driver but I also need to be able to talk to the CF container as well. Luckily there is a solution. We’ll use the same driver for each.

Configuration

OK, the driver config can only be on one container. Let’s see what that looks like.

Notice that even though we’re using a parent interface, we get our own default gateway for this traffic. This allows us to not have to NAT out the bridge driver. We can use the same network as our parent, just make sure the IPs are unique on the network.

Once the network/gateway is configured now we actually set the IP under the service section. Once this is deployed, you should be able to ping that new address. As the note says there are no ports to expose, it’s all open.

Here’s what it looks like together.
NOTE: volumes and other settings are not in the examples

Sharing The Love

Ok, let’s add our other container. We set the network, but as external and we map to the name of the vlan network.

Look in Portainer networks or via sudo docker network ls

Then under the service we define the IP of the container.

Lather, rinse, repeat for any other containers that you need to talk to each other. If you want/need to use ipvlan instead simply use “ipvlan” as the driver. The documentation suggests ipvlan is the better way to go as well. But for home enterprise? macvlan is fine provided your hypervisor supports promiscuous mode on the vswitch.

Proxmox seems to have it enabled by default.

ip -details link:

There’s also other drivers, where you can tag traffic, L3 IPVLAN, etc. That’s way out of scope for my use case, so but there’s extensive documentation here.

Conclusion

Well, this was a journey well worth taking. The vlan bridge drivers are really useful when homing the same services with the same port on the same host. But the use case needs to carefully planned for, due to the natural isolation between drivers. But there’s a use case for mac/ip vlan, secondary IPs on the bridge driver, it’s up to you.

The flexibility of what Docker gives us is what makes the application so useful.

Until next time.

I might have a container addiction. I think I’m up to 40 or so. But, man what a ride. My Docker journey has been amazing and I’m so close to where I want to be. But you know what’s not fun about containers? Logs. Man, that’s tedious. Whether it’s Portainer bouncing you out of a log after you restart a container, or trying to avoid going blind by staring and trying to parse out the logs via CLI…BLEH. Once again, the universe provides with Dozzle.

Dozzle!

Ok so what is Dozzle? It’s a container (shocker) that simply streams the logs from other containers! It doesn’t store them, it streams. And you can search them all at once via regex, regular text, and I think sql or some such madness. And it also has a agent mode so you can streamline it all to one GUI.

Here what it looks like:

So the top one is the host the GUI is on, and the three “satellites” is where I have agents reporting. Right off the bat, it shows container stats, which is rad. Let’s search real quick, using the “search” under the lil Dozzle bug. This will return containers.

Now if I click on that container, in the upper right I get a menu. It’s a bit vague that it’s there. There’s a lot to use here.

In the search menu, you can filter and search the current log as well.

That’s awesome, but check this out,

You can get ALL the logs in one live, searchable view. But wait, that’s not all!

YOU CAN STACK MULTIPLE CONTAINERS IN ONE VIEW FROM DIFFERNT HOSTS!

And you can pin containers as favorites…

Finally in the settings...

Seeing the logs of containers that are stopped is actually surprisingly useful.

Ok enough gushing, let’s get into the stack configs.

Config Time!

Ok, my setup is fairly simple. I did find the agent config to be a bit confusing at first, so I’ll show both examples.

Full details with all options are here: https://dozzle.dev/guide/getting-started

Let’s split this into sections.

NOTE: I’m using WUD for updates, so I use tagged releases. Feel free to replace with “latest” if that’s your jam.

Pretty basic, though I changed the sock to be RO. I don’t have a need or want in my use case for any actions by Dozzle.

For the environment variables, see the remote agent section. The agents are comma separated. As of right now Dozzle doesn’t like starting if the agents aren’t reachable so maybe set them up first.

AGENT CONFIG

The agent config is pretty straightforward. Note the port and “agent” command.

Full examples are on my GitHub.

Conclusion

Not much more to say, apart from finding a solution that meets another need I had. Pulse for detailed host usage/alerts, Kuma for easy uptime alerts, and now Dozzle for easy consumption of container logs! I think the only thing now missing is some way to gather all the patch information in one place about all my Linux hosts.

I don’t know, sounds like Rambling Nonsense to me. ;)

Until next time.

Intro and Musings

Well hello there! Doing a part three on this kind of surprised me, but as I learn new things I like to put fingers to keyboard and further document my journey in the hope that others will also find it useful. I think that this may be one of the more important posts I've made as it will highlight a nuance to the docker solution that isn’t as obvious as it should be.

So let’s start off with the use case that brought us here.

Making A Case

Ok, so. I have my one docker host at 10.0.0.10. I have about 35 containers and they all use the standard host:container convention to make the resources available. I’ve never seen a different convention, in any other compose, ever.

So at 10.0.0.10 I have WUD on port 30010 and NPM (Nginx Proxy Manager) on port 443. I have the same setup on 10.0.0.11. My eye in the sky, Uptime Kuma keeps tabs on everybody for downtime notifications.

So, lately I’m been having an issue where across vlans my firewall is having issues sending traffic to the right destinations where the FQDNs have the same IP and causing havoc with my firewall rules due to some dopey DNS cache.

For example, abs.nscriven.net and pulse.nscriven.net both go to Nginx at 10.0.0.10. So my initial solution was to build another docker host, just to proxy that IP from a unique address. A total waste of resources and a major PIA as now I need to duplicate WUD, DNS entries, Proxy entries, blah blah blah. But I did it, because my son was on me because he couldn’t access these resources externally. (Home Enterprise, remember ;) )

So I did this as a stopgap measure. I told my buddy Alex (who I work with) about this and he told me, “why not just use a second IP on your first host and use that for your conflicting containers?”

Me: /dumb look…”I didn’t know I could do that.”

IP Address Value Meal

Ok, so adding the secondary address on the same vlan is really easy it turns out. For Ubuntu, you edit netplan, and add a second address under the first and then save and “apply netplan”. They should respond to a ping right away.

So my thought was, I’ll decom 10.0.0.11 and add that IP to the 1st host, light up Nginx and profit. I won’t have to redo firewall rules, DNS, etc. So the new design looks like:

Note: There’s more other ways to this with macvlans, we’ll cover this in a future post.

So now I have this plan, right? How do I get it done? Well it turns out you can bind containers to IPs! The convention is IP: host port: container port.

And it worked! Now it’s important to note in this fashion I did not make a new bridge, this is a 1:1 mapping to the new IP. No other containers will use this combination. It’s a very specific use case for a very specific problem. I replicated it for another service for the same issue to great success.

System Of A (Not Going) Down

So…my task completed I waited for Kuma to send my glorious down alert for WUD, since that container no longer exists on 10.0.0.11 as a host. And….it didn’t arrive. I check Kuma, and it is willfully, defiantly, mockingly GREEN.

This didn’t make sense…WUD isn’t configured on .11, just .10! Why is it still up?! Then something hit me based off some other conversations I had seen on Redditt recently. And it has to do with the way docker does networking, and the arguably sloppy way developers make compose files.

The Tyranny Of The Default

So, if you have one IP on your box I’d say what follows isn’t likely a concern but the education is important. It is disturbingly easy to be so enamored with a technology like Docker and not realize you’re glossing over important nuance because it feels like magic when it works. So let’s shine some light here.

When you see host:container, what you’re saying is that those ports can be reached BY ANY IP ON THE BOX. To put it another way:

0.0.0.0:host:container

Now, I’ve seen that stated elsewhere and scoffed “why does that matter?” I WANT the port to be reached. That’s the whole point.” And the scoffing wasn’t just me, many others were making this flawed logical assumption.

I work in the security space, and once I saw this in the flesh all of a sudden everything made sense. What was happening was WUD was now reachable over port 30110 from BOTH IPs! I call this “unintended access” in my opinion there is no greater sin than unintended access, and even worse when you did it unknowingly.

If I wasn’t such a control freak and treated my network as pseudo-Enterprise I would have NEVER have known about it. Here’s what this now looked like.

The plan was in no way, shape or form intended for this type of access. But there it was. Now, I’ve seen people say:

• Put it behind a proxy, who cares

• Don’t you have a firewall?

I don’t like these arguments. I have both. People forget L2 is a thing, and segmentation at L2 is complex and expensive. If I am exposing anything, it must be intentional, and the risk/tradeoff fully known and understood. Security is in layers and it starts as close to the resource as possible and radiates outwards with other controls.

So this must be fixed. Luckily it’s simple.

The Fix Is In

Ok so the cardinal rule here is, if your box has one IP, host:container is likely fine. (I’ve seen arguments that 127.0.0.1 can be a concern but I’d need to see a use case) But the second you add any network resource every.container.forevery.port should be tied to an IP, even the first IP on the box.

So for WUD I updated my compose to 10.0.0.10:30010:3000. And then Kuma gave me the down alert I was looking for. I then repeated this for every container on that box to ensure access I wanted was intended and narrow.

Also, in Portainer you may have noticed your published ports section when clicked on, always sent you to: 0.0.0.0:[port]. Binding in the compose file fixes that too, for some added convenience.

Conclusion

So I hope I’ve properly communicated the use case, resulting issue, and fix. This is one of those things you find by accident; or are knowledgeable about due to time and study because you’re an expert. Think if you’re running a container in a VPS or shared environment that has more than one IP and you’re unwittingly exposing a service to the outside world in a way you didn’t intend or protect for. For me, it’s a re-dedication to learning more about the solutions I use in my Home Enterprise and paying more heed to peers that may be trying to say something important.

Until next time.

When it comes to Docker, there’s three main “legs of the stool” I’ve been concerned with and learning about solutions for. Despite my best efforts, I’m not a CI/CD automation guy. I just haven’t found the spark to really ignite my interest yet. So my solutions are a bit more traditional at this time. If I do have that “AH HA!” moment, I’ll cover that revelation here. As always, you’re welcome to comment and point out better ways to do things that maybe I didn’t realize/think about.

1. Management/deployment - Solved for now with Portainer

2. Updating containers - Solved for now with WUD, the point of this article :)

3. Backing Up Containers - this is on my list. Most of my docker hosts are on VMs,
   which takes care of the backup inherently with Proxmox Backup Server. I do have one physical host for my ZWAVE container/Frigate so that needs to be taken care of.

WUD - What’s Up Docker

So what is WUD? It’s a container, purpose built to update other containers. There’s other solutions out there, like Watchtower but I keep hearing about WUD. I really do like a functional GUI for things and while it is very compose/stack heavy it does the job quite well. But man, are there nuances to this solution. And the documentation, while decent really glosses over some key points in my opinion, which makes the use more difficult. I actually had a false start about six months ago and dropped it after getting frustrated.

I moved to the free license of Business Edition for Portainer, which shows when there’s an update available but over times that process got very tedious so I picked WUD back up and figured it out.

My goal, by the end of this article is that you'll be able to effectively have WUD monitor, update (either automatically or manually) and notify you of changes. Before we get going though I think we need to talk about repos and registries. We’re going to handle our containers in a much different way than maybe you're used to.

The Repo, Man

Ok so what’s a repo/container registry?

Repo: source code, documentation, issue tracking, E.G, Github,Gitlab
Container Registry: Stores pre-built Docker images (binaries)
E.G. docker.io/syncthing/syncthing

There’s several registries out there, and let’s look at what that means. In your stack/compose it’s the prefix. For FOSS apps, these are the three I primarily see:

• Docker Hub: docker.io/ or none

• GHCR: ghcr.io/ (GitHub’s registry, free, integrated with repos)

• LinuxServer.io: lscr.io/ (LinuxServer’s own registry, with repos on Github )

So for example some of my containers:

docker.io/jc21/nginx-proxy-manager
syncthing/syncthing
ghcr.io/lukegus/termix

See? I have two different prefixes since no prefix and docker.io are identical. A good rule of thumb is to use the prefix that’s in the compose example for their documentation.

From what I understand (and am probably not 100% right on) is that each one has a reason why devs use one over the other. Workflows and such. It’s all witchcraft to me.

Most projects use GitHub for documentation regardless of which registry hosts their images. Next question, why the hell do I care about all this?

Because, when it comes to updating dockers, we need to talk about “latest”. This subject turned out to be quite the rabbit hole.

Latest, This Just In

When we’re using our containers, the format is:

registry/container:tag

So for the most part, setting the tag to be “latest” is the best practice. This allows the developer to essentially control the version you run. They will set a tag of “latest” to whatever numbered version they prefer.

But, you can also set a tag to a specific release like:

ghcr.io/homarr-labs/homarr:v1.43.0 or
ghcr.io/rcourtman/pulse-docker-agent:4.26.2

Note: see one of those values has a “v” in it. We’ll come back to that.

I posit that if you’re not doing any kind of utility like WUD, latest is fine, but you may find you’re updating pretty frequently with no real feedback. Even in WUD with latest you won’t see what version, just the new SHA value. I’ve learned not to like that so I’ve largely moved to a specific version tag. I like seeing exactly where it’s going.

Note: When we set the tag like this and use WUD to update the container, we effectively “orphan” the compose/stack in term of versions. You can get well ahead of the compose/stack over time since WUD updates the container, not our deployment file. So if you go and update your compose/stack and redeploy you should update the number to what you're currently running. If you forget, WUD will definitely remind you. Example:

If I deploy this, 1.1.2 will replace 1.2.2. When WUD detects it, it will notify you’re out of date and you’ll feel silly. Better to make them match.

In comparison, latest can include breaking changes, deprecated features, config changes, updated dependencies, digest updates, etc.

Here’s an example.

I’m using a semver tag to specify the version. WUD shows me what kind of update it is, and old>new. I also have a template that will take me to the Github for the patch. We’ll cover that later.

Note: Semver: follows the format: MAJOR.MINOR.PATCH (e.g., 2.4.1)

Using a tag with version shows a nice progression.

If the tag was “latest” is it would not show a version progression, but just the SHA. Eh, I don’t like it.

So how do you know what tags are available? For most projects, look at their github under releases.

Now if you click on releases, you’ll also see a tag button.

Now remember the v? If the v is there, usually you’ll need it. If you try the v and it doesn’t pull the image, try it without it. I’ve ran into some projects where the semver format was a bit funky.

Now one thing you should absolutely do, is subscribe to all the projects you follow for releases updates at the very least.

This way, you’ll get convenient email alerts about the details.

USING WUD

Ok, let’s get to it. So this app is very powerful and the documentation is decent, but can be confusing. There is no GUI config, just a GUI result of the compose/stack config. Everything you can configure is in the compose/stack.

Let’s take a look at my WUD stack in stages. Examples will be on my Github.

Pretty much by the numbers here.

It’s the environment variables that matter here. You primarily have Registry, Watchers, and Triggers.

Registry:

There are a number of ones that are built in, these are where WUD will pull updates from.

For dockerhub, there are a limited amount of pulls you can do on an anonymous account per day. Make a free account, spin up an API key and use it in the compose/stack. The limit is far higher.

- WUD_REGISTRY_HUB_PUBLIC_LOGIN=
- WUD_REGISTRY_HUB_PUBLIC_PASSWORD=

Watchers:

This is how often WUD polls for updates, don’t leave this as default you’ll burn through your pull requests even on an authenticated account. I set mine for every six hours.

- WUD_WATCHER_LOCAL_CRON=0 */6 * * *

Triggers: This is the fun stuff.

- WUD_TRIGGER_DOCKER_UPDATE_AUTO=false

Set to true to autoupdate, but set to false and it provides the button for manual actions.

- WUD_TRIGGER_DOCKER_UPDATE_PRUNE=true

Will auto delete the old container on update.

- WUD_TRIGGER_APPRISE

This is to setup our notifications with Apprise. Lots of other options, this is what I use. We’ll cover this soon.

LABELS

Now if we leave these at defaults, WUD will work but it’ll be messy. Let’s use labels to tell WUD exactly what to do. Now, we will place these labels on every container including WUD itself.

wud.tag.include: ^v?\d+\.\d+\.\d+$

So this is regex, and should work for most use cases and only alert of updates in standard semver context and not sha digests and other stuff. If you know there’s an update and WUD isn’t catching it you may need to tweak this. This should also account for the option of “v” at the beginning of a tag.

wud.link.template: https://github.com/getwud/wud/releases/tag/$${major}.$${minor}.$${patch}

This provides the link in the WUD output for release information. Change to the link of the container’s tag page if it exists. Not a requirement, just convenient.

Now for the containers, you just need the labels. It’s a pain to go back and retroactively edit all the containers for labels and tags, but I think it’s worth it.

Now there’s some oddballs like Exalidraw that doesn’t have anything other than latest so I went another route. That should keep me from pulling down weird intermittent releases.

wud.tag.include: ^sha-[a-f0-9]+$

Notifications

Okay, so. Lots of options here. I use Apprise to send to Home Assistant.

I cover that here:
Home Assistant Notifications With Node Red

I also cover setting up Apprise here:
Notifications for Audio Bookshelf Using Apprise and Home Assistant

Now the neat thing here, as I found out with Uptime Kuma is that I can use the exact same notify URL that I use for Home Assistant anywhere! In hind sight of course you can, but give me break. :)

So an example trigger for this:

- WUD_TRIGGER_APPRISE_MYNOTIFY_URL=http://10.0.0.x:32768
- WUD_TRIGGER_APPRISE_MYNOTIFY_CONFIG=abs

Set the IP/Port for Apprise and and the config path. Every app does this part a little different by the way. When this is deployed, you’ll get an entry in the GUI along with a very handy test button.

Let’s fire off a test alert. If it doesn’t work make sure you check your WUD logs.

Ok, it works but that’s hella wordy. I want to shorten it, and add some identifying information so I know which WUD box it’s coming from and provide something unique to grab in Node Red so I can send the message to my phone.

Note that I have “WUD Prod” and a bunch of variables, let’s see what it looks like now.

To Node Red!

Here’s my current setup for Audio Bookshelf/Kuma

I’m going to slap a debug node onto the Apprise node and fire off a notification.

Ok I need to make a new switch node, as I’m pulling from payload.event.service_data.title, not message.

Now, I’m going to make a new action node with some custom json. I used Claude to help with this.

See: Not A Programmer.

My flows now look like:

Let’s fire off an alert…

Oh, and here’s my oddball. *shrug*

Conclusion

Ok, that was a lot. I hope by the end of this you have a working configuration that works for you. Now this is the way I do it. There is much more functionality to be had if that’s your goal. Take a look at the documentation and go nuts!

Until next time.

When it comes a busy Home Enterprise environment basic monitoring it can be a challenge to find a solution that’s light and easy to configure. I want lots of monitoring options with flexible notification schemes, that’s easy to setup and configure. A nice GUI doesn’t hurt either. Kuma Uptime hits all these boxes.

Looking Inside The Pick-A-Nic Basket

Right away, we see a nice “Add New Monitor” button on the top left.

Adding Monitors

That’s a great array of monitoring modes we can pick from. I particularity like the TCP port, it’s great for Docker containers.

Note: You’ll notice there’s a Docker Option, but I like TCP port to keep things separate.

Notification Setup

Notification types are an embarrassment of riches. I can’t get all of them in one screenshot, it goes all the way to “Z”. I particularly like the Apprise support! Even though Home Assistant is represented here, I prefer to use Apprise.

I have a post here about setting up Apprise with Home Assistant.

To my surprise, this was dead simple since Apprise was already setup, so I could just use the same link as I use for ABS! Also, I love that you can make a notification as default for new and current monitors.

So that got the alert to the HA dashboard, but sending to devices via notifications was a bit trickier than I expected.

For whatever reason, the notification would cycle and send hundreds out.

I put in trigger nodes to limit to one.

For my switch node:

And the json for the notification nodes:

Once that was done, it worked wonderfully.

Groups

You can add monitors singly or group them together. I really like groups as you can see uptime as a whole and individually. You can also set the notification for the overall group as well.

As for uptime, I really like this display.

Other Settings

I just wanted to add this for reference. So many cool options. Built-in Cloudflare tunnel support? That, as we said back in the day, is “rad.”

Portainer Stack

The stack is really, really, simple. The github is: Uptime Kuma

This stack example as always, is at my Github.

Note: Kuma recently went to 2.x. For whatever reason “latest” still pulls 1.x, so I used a version tag here instead.

Conclusion

This is a great addition to my monitoring suite, and is a nice companion to Pulse.
I hope you find it as useful and easy to use as I do.

Until next time.

As I’m sure you’re aware I absolutely adore Proxmox and Docker. They are, in my opinion the core technologies in Home Enterprise setups.

Note: Uh oh, rambling rant incoming.

You’ll notice I didn’t say “home lab.” I despise that catch all term. A lab is a place for experimentation and scenario wish fulfillment. There are no customers or users in a lab, save for the mad scientist playing God inside of it.

I have labs. Outside of that lab is my Home Enterprise. I have users who expect uptime, I have deliverables on myself to improve my workflow, etc. I put new solutions into testing phases before adopting, etc.

Not.a.lab. Fight me. :)

Ok, now that I have that out of my system…one thing I’ve always wanted is a solid way to monitor and alert on all of my VM/Docker services. Uptime, resource usage, etc. I never really found any of the solutions out there that was compelling. So as I’m want to do, I sat back for a while and waited for the universe to deliver a solution. And it did!

What Is Pulse?

Pulse is an application I stumbled upon by way of the ugh…”home lab” subreddit. It does everything I mentioned above and a little bit more. This is an outstanding application. Very easy to deploy with Docker, and very full featured. Let’s take a look.

The Nickel Tour

First, we have Proxmox. Overview, Storage, Backups! It integrates not only with PXE, but also Proxmox Backup Server!

If you want more details on a VM/CT, click to open.

For Backups, it shows you local backups, PBS backups and size/status and…

It.shows.the.presence.of.SNAPSHOTS! No more do I have to question whether or not I remembered to clear that snapshot and where it was, I can go straight to Pulse.
I can’t tell you how much I love this.

Note: There is no alerting for this, but I submitted a feature request to the Github.

Ok, what about Docker? Yup, I can see all the details on my containers!

I can even click into them and see more details.

Alerting

The alerting thresholds are easy to set, and very human. I have any number of templates/VMs I don’t want want to be bothered about, so I just turn those alerts off. Or maybe I have a Linux box that is high on memory usage but I’m fine with it. Simply raise the threshold.

For Notification Destinations, you get email or webhooks. No Apprise support , but I’ve submitted a feature request.

Note: I guess there IS Apprise support but it’s not built in. Feature request stands.

Here’s an example of some alerts I received.

And the email.

Previously, I would have to had stumble upon this, but now issues are proactive, not reactive. Wonderful.

Setup And Install

Setting this up is not hard at all, and I have a process that worked great for me.

As always, I have my Portainer Stack examples up on my GitHub.

The stack is about as simple as it gets.

Inside of the directory, you must create a .env file with the following attributes.

Inside of your volume directory, create a .env file with these attributes:
Ensure the user and pass are filled out, this will be your login. The api token is a seed, and you’ll replace in the GUI afterwards.

PULSE_AUTH_USER=
PULSE_AUTH_PASS=
API_TOKEN=c4b7c4c059e1ed51cf590d74b6ef8c33684b473486de0146a8b22e70a44955c1

Adding Proxmox

Go to Settings>Proxmox VE Nodes, and “Add Nodes” It will present a wizard that will provide what you need to add the monitoring user and privileges/token creation. This process is very well thought out. If you have a cluster, you only need to add one node. Adding others does cause some duplication which can be confusing.

Adding the Proxmox Backup Server is the same process.

Adding Docker

This requires an agent be installed on the Docker box. There’s several ways to do this, including a binary but I struggled with that. Luckily, there’s a far easier way to do this, and there a container available!

The first thing you should do is go to Security>API Tokens and regenerate that API key.

The docker file looks like this:

Pop in your new IP token and URL

There’s nothing else to do, they just “wink” into existence.

Conclusion

That’s about it! Now this is my Fisher-Price super easy way to get this setup. I encourage you visit https://github.com/rcourtman/Pulse and look over the documentation, it’s very well done. I hope you find this tool as useful as I have.

Until next time.

A couple of years ago, notifications in HA were a bit of a mess. We didn’t really have a solid phone app, and had to rely on third party solutions like Pushover, which was a bit of a kludge and required notifications to not be local, but be pushed to the cloud service and back again. Then in v0.7 we were given native notifications support, and in 2022.2 local push support was introduced. Notifications could be configured using the built in automations engine or with Node Red. As I’ve only ever used NR, this is what this guide will focus on. It’s more complicated, but I’d argue far more flexible.

HA (Companion) Mobile App Setup

When you first install the mobile app, it asks you to name it. Here’s where you can accidentally trip up your future self. I would advise you make something specifically generic. (words, what do they mean?) What I mean by that is instead of “Dad’s Pixel 10” use “Dad’s Pixel”. That way when you get a new phone, you can name it the same and not have to go through all of your automations and update the reference.

HA stores the name as an entity you can’t search for or see like you’re used to. It’s notify.mobile_app_[name at setup].

You can see it in Node Red, though.

There’s also the concept of “Channels”. Included with the app there is General, Sensor Sync, and Sensor Updates. You can create custom channels, but there first must be an initial notification sent to the device using that channel before the phone will see it and be available for customization of different sounds.

To get to the notification section in the app >Settings>Companion App>Notifications

The Channels section is where the customization of alerts like sounds, vibrations, is configured.

Node Red Configuration

I’m going to assume you have some knowledge of NR. I do have a brief intro about it here but it’s in no way comprehensive.

I’m going to include some samples of several custom scenarios I have setup. Typically, it will be a state node, a switch, and the notification entities.

The flow for my front door notification is shown above. To get the values for the switch, I tied a debug node to the state and activated it.

The debug node is an indispensable tool to see the messages so you can switch them correctly.

If you have a smartwatch, notifications can be sent there as well.

Now you may have noticed the Data section in the notification area…yup it’s JSON.
Here you can see the structure of this message, where I’m repeating the payload of what’s being received into the body of the notification. Also the Channel, Priority and Color. Not every device honors the color value, as you can see above. Examples of all these can be found on my Github.

Let’s look another more complex example for my Garage Doors.

Now let’s look at a debug of the door.

So this device sends the interim and final state of the door, and I use the switch node to send the packets to the right output. NR doesn’t have a “does not contain” option which is why i had to use regex for that.

Testing and And Initializing Channels

So the easy way to send these channels down for customization is to wire up an inject node to the notification entities. The message doesn’t really matter as all we’re trying to do it successfully generate the alert.

There’s the notification, with the default timestamp as the payload.

Setting Up a New Phone

So, a new device will not have your channels. All the backend stuff will still be on NR, what I did was create an unholy tentacle monster inject node wired to all of my notification entities that had a unique channel and just fired off a mass notification wave which then pushed all my channels down. I set all my sounds and was good to go.

Oh, and one final note. If after setup of your phone your mobile app name doesn’t show up in NR, reboot the add-on so it can re-query the database right away and fetch the new node name.

More details on the overall notification system can be found here.

Until next time.

I’ve used One Note, Google Keep, Evernote, Notepad++, etc over the years for note taking/storage. Recently I got the itch to bring this in-house. I always thought Evernote was too expensive for what it was, and the other solutions were too locked into an ecosystem to ever truly be “yours”. I recently POC’ed a couple of strong contenders with a solid winner.

Me and Dockey MCGee

Joplin was the first one I tried out. The docker compose had multiple dependencies and was a bit too complex I thought, for what it was going to do. The app, a frontend, a separate database container, and optional transcription service container.

So I got it up and running and went to the front end and set up my user. I didn’t set up email, but they require a email confirmation all the same. So I went through the log and found the email with token and completed it.

So then I logged into the app…only to find there’s no app. It turns out Joplin Server is just a sync point. The app is a thick install only. Grumble Grumble. I installed the app, synced it up, and it was okayyy. Sure you could encrypt the database and some other bells and whistles but it didn’t “wow” me and the requirement of a thick app closed the door on this one.

Trilium Notes, Now With More Flower Power!

(apparently Trillium is a flower. TIL)

Initially I passed over Trillium, I confused it with an old IM I used to use, Trillian. On second look however, I found it has a very interesting story.

TL;DR, developer puts app into maintenance mode, community responds, damn near rewrites the whole thing, and developer hands off the entire product.

A few details had advantages over Joplin right away. The docker was simple. One container, no fluff. As always, there is an example on my Github. It’s also a web app OR you can sync with the server using a thick app. Best of both worlds.

NOTE: there is no support for multiple users right now. It’s covered in the FAQ. Not a big deal IMHO, and the reasons are sound. Need another user? Spin up another instance. I did that for this guide, easy.

SETUP

Setup is simple. On launch of the web app we get:

Pick the first option, then set a password. It doesn’t get much simpler.

The on login, you get this. Me being…me I just deleted all the examples because I wanted to go my own way. I then had to find stuff myself, I recommend you take this tour first, then delete it.

OK where to start. There’s so many options it’s kind of overwhelming at first. Let’s start with a right-click.

Let’s start with note types. There’s a lot here but I’m going to focus on the three I’m using.

Text: Completely boring, delightfully usable. LOTS of options here.
Canvas: This was an unexpected delight.

THIS.IS. EXACLIDRAW! I love excalidraw, and host an instance locally. My only issue with it was storing drawings. It saves them in the browser session until you save to file. This was always clumsy to me, and I’ve lost/accidentally overwritten things before. This completely fixes that. I can store each drawing as a separate note. I’m seriously considering shutting down that instance.

Note: EVERYTHING in this app is a “note”. They call it a “hierarchical note” app. Settings? Note. Calendar? Note. AI Chatbot? Note.

And I first discovered this by accident with canvas, though it’s applicable for all notes. Revisions! By default it takes a snapshot of the note every 600 seconds. In the upper right, you get this charming little fellow.

Mermaid

Before this, mermaids for me were all dinglehoppers and thingamabobs. I don’t think I’ve ever seen this before but it’s SUPER interesting and another way to make a network diagram. (one of it’s many, many, uses.) Here’s an example. Be warned, this is a deep well. There’s a tons of formatting and style nuance.

Here’s a guide: https://docs.mermaidchart.com/mermaid-oss/intro/getting-started.html

But let’s start reaaaaal simple. Check out below. You simply make logical connections via text.

Now you could just do switch===pc without all of the prefix ids but then you cant assign any values to them like shapes or colors.

Note: “IDx” is not a requirement it can be anything as long as it’s unique.

As you can see, the sky’s the limit. You can even take this into Excalidraw!
Note: You’ll have to use the standalone version, Excalidraw proper uses an older version of mermaid, where Trillium uses a newer module.

Calendar

For me, I’m terrible at taking notes and organizing my date. I think this is going to fix that, easy. I mean…it’s a calendar, not much else to see.

Secret Agent Man

A tree, a subtree, an individual note. They can be “Protected". This will encrypt the information and require a password to be re-entered if you leave the protected session or after 10 minutes idle.

There’s also another neat feature, “hoist”.

This will hide all other notes until you “un hoist. Which has its use cases especially if you’re screen sharing.

X, Never, Ever , Marks The Spot.

We’ll close this out on search. Maybe you have notes on notes. Technical references, obscure CLI commands, etc.

You can do a quick search:

Or a ridiculous search:

Or maybe you want to see a logical representation of where your notes are at? Enter the “Note Map”.

So that’s kind of it. I scratched the surface here, and I hope you find this as useful as I did.

Until next time.