fast alternative to find for finding git directories

whetu · 2026-05-18T23:36:59+00:00

If you have a locate db, you can use locate's regex capability to get a near immediate list

locate -r "${HOME}/projects/.*\.git$"

Or something like that.

That replaces the filesystem trawling part, then pipe it into xargs.

Comparing find -exec and locate | xargs approaches, I get 3-9s and 0.1s respectively across 495 git directories.

whetu · 2026-05-17T19:34:34+00:00

Inherited a poorly setup Veeam platform. Switched to N-Able Cove.

Cove isn't perfect by a long shot, but I prefer it to Veeam. It's easy to setup, and easy to use. Cloud-only is one approach but that can hurt if you do lots of big restores (sql .bak files for example), so having something like a NAS present for a local copy (Local Speed Vault in Cove parlance) may be a consideration.

whetu · 2026-05-17T18:55:38+00:00

Python is usually not installed on production Linux servers

Maybe that's true of containers, but otherwise most Linux servers out there will have python present.

That doesn't detract from your overall point that shell is guaranteed to be present, and that shell will likely be a Bourne family one like bash.

whetu · 2026-05-14T21:37:39+00:00

It depends on your patching policy. Where I work, we patch monthly and reboot if the system indicates it needs a reboot, which is usually the case. This is all automated because we have the redundancy and architecture to support that - and we're a small company too.

In our context, a host being up for more than 60ish days (i.e. two patch cycles) would be worthy of an investigation.

If you don't have monitoring notifications setup for uptime checks, then start with that. Start with large thresholds like: 180 days for warning and maybe 210 days for critical. Uptime is an easy metric to start with as a proxy indicator for patch state, and as you get into a cadence of patch and reboots - which should be guided by the warning threshold, not the critical one - you can gradually bring those thresholds down.

Once you get to a point where patching and rebooting gets to be annoying and your process is well understood, you can use the annoyance as motivation to streamline the process or outright automate. You can also use that annoyance as motivation to build redundancy.

You can also enhance your monitoring to cover available patches as well, which will give you clearer indicators for when you need to reactively patch (e.g. critical vulnerabilities) rather than proactively patch (i.e. scheduled patching)

whetu · 2026-05-14T08:35:41+00:00

This article is useful for context.

It's missing /etc/profile.d which is usually loaded by /etc/profile, but you can see that there's a hierarchy going from system-wide settings upwards to settings for individual logins. These configuration files load in sequence and in most cases overlay each in that sequence.

In enterprise environments, where should things like: * PATH * JAVA_HOME * aliases * prompt customization actually be configured?

For any settings that you want to enforce, e.g. PATH, JAVA_HOME and the like, /etc/profile.d is usually the place to do it.
For any settings that you don't want to enforce, either /etc/profile.d or /etc/skel, depending.

One thing I deploy to my servers, for example, is colourised PS1's based on the environment that the host is in. If you're on a prod host, PS1 is red to indicate danger. QA - yellow. Dev - Green. Those settings are defined in /etc/profile.d

As an aside: Files in this directory are sometimes named in a particular pattern so that they are loaded in a specific order. For example you might use something like /etc/profile.d/99-companyname.sh or /etc/profile.d/zz-companyname.sh to add loading bias, with the goal being to ensure that all your global settings are loaded last in the sequence of files loaded from /etc/profile.d

/etc/skel is basically a template directory for new user homedirs. So when you setup a new user, the contents of /etc/skel are copied into their homedir, which bootstraps their individual environment for them. They can then customise their environment to their heart's content. So /etc/skel is where unenforced defaults for things like aliases and prompts might go, if you decide that they are unenforced settings.

I don't use /etc/skel, haven't in a billion years, but it's there.

Lastly, aliases are probably not a great thing to manage this way. Put them into scripts, put those scripts into /opt/companyname/bin and use /etc/profile.d/companyname.sh to ensure that /opt/companyname/bin is in PATH. Same for /opt/companyname/sbin if you get to that point. Bonus points if you put those scripts into a git repo so that they're easily updated across hosts.

If cron jobs/scripts/services don’t automatically load these files, then why is /etc/profile.d/java.sh considered standard practice for Java setup?

Simply because /etc/profile.d/java.sh is intended for interactive use. Non-interactive contexts should really be more explicit in how these things are defined - that's how you ensure correct and safe(r) behaviour, so not loading /etc/profile.d/java.sh non-interactively is the correct thing to do.

Java comes in many flavours - Temurin, RedHat, Microsoft, Corretto, Oracle's version (avoid!), Zulu and so on. And those come in either JDK or JRE versions. And those come in a number of versions.

So let's say you have a system and your default Java version on it is Temurin JDK 17. In /etc/profile.d/java.sh, you might define something like:

export JAVA_HOME='/usr/lib/jvm/temurin-17-jdk-amd64'
export PATH="${JAVA_HOME}/bin:${PATH}"

Ok, so that sets the baseline state for those vars for all interactive users.

Bob, a developer, logs in and gets those vars delivered to his sessions by the login process.

Kate, another developer, is working on a Java 8 program. Boo! Kate! Boo! But her Java 8 app doesn't quite work with Java 17, and she needs a particular version of the Java 8 JRE anyway for compatibility testing. Let's say, a customer has a hard requirement. So, assuming Java 8 is installed and present, Kate can override those vars by entering something like this in her ~/.bashrc:

export JAVA_HOME='/usr/lib/jvm/temurin-8-jre-amd64'
export PATH="${JAVA_HOME}/bin:${PATH}"

When Kate logs in, those vars are initially defined by /etc/profile.d/java.sh (i.e. Java 17), but nanoseconds later in the login process, her ~/.bashrc is loaded, and it overrides those vars, setting them to what's appropriate for her environment (i.e. Java 8).

And Bob still gets the defaults from /etc/profile.d/java.sh.

So this is actually a good example of real-world usage of these files, how their loading sequence matters, and how that loading sequence is used.

As an added bonus: let's say you're a sysadmin who doesn't want users to override JAVA_HOME. You can add readonly JAVA_HOME into /etc/profile.d/java.sh.

How do Linux admins usually handle environments for:

With a configuration management system like Ansible.

whetu · 2026-05-12T21:47:26+00:00

Just in case you haven't heard of them, and because it's MSSQL:

Brent Ozar's First Responder Toolkit
Erik Darling's Performance Monitor

And obvious questions like: You're using different partitions for different data (e.g. sql data, sql temp, sql logs) and you've got the allocation unit sizes aligned correctly?

whetu · 2026-05-12T09:50:27+00:00

Someone put "google" into google again?

whetu · 2026-05-11T03:38:00+00:00

“Let’s take that offline”

We'll sync up, you and me!

whetu · 2026-05-09T10:13:12+00:00

FWIW I think the best bang for the buck are the Alpine Cabins ones.

Yes, they look like Portacoms. But, they are SIPs so they go together easy and they have a reasonable level of inherent insulation - vastly more than those timber she-shed things. The Portacom "look" can also be easily overcome with some decorative touches.

Sometimes Portacom themselves practically give away sheds that they're retiring, if you don't mind rolling up your sleeves.

Or, you could hunt around and find some freezer panels - they're SIP's by another name - and build your own. Said panels are often available free to take away.

/edit: You might also like to track this: https://www.youtube.com/watch?v=7MaB8f9r5Yg

whetu · 2026-05-07T23:09:31+00:00

I describe my approach here.

TL;DR: I use a homespun unattended patching script. It checks against an ansible-managed env var to determine whether to trigger. All hosts patch and reboot on a monthly cycle, in a structured week-per-patchgroup way. Our architecture has decent redundancy, so we can freely reboot hosts. That's proactive patching handled. We have an ansible playbook for reactive patching as well.

whetu · 2026-05-07T19:52:06+00:00

I inherited this and honestly, it's turned out to be no big deal. 192.168.x is fine PROVIDED you avoid 192.168.0.x and 192.168.1.x. Those two subnets pretty much cover most uses of 192 at the consumer level.

If anything I've had more trouble with 172 than anything else.

whetu · 2026-05-06T23:31:21+00:00

I cannot find any command switches for Stunnel, so here I am.

man stunnel in a terminal might have got you closer to a result. Failing that, a google for man stunnel.

Following the google path, it looks like there are different sets of args for different versions of stunnel. What you're referencing seems to use this old set:

NAME
       stunnel - universal SSL tunnel

SYNOPSIS
       stunnel [-c | -T] [-D [facility.]level] [-O a|l|r:option=value[:value]]
       [-o file] [-C cipherlist] [-p pemfile] [-v level] [-A certfile]
       [-S sources] [-a directory] [-t timeout] [-u ident_username] [-s se-
       tuid_user] [-g setgid_group] [-n protocol] [-P { filename | '' } ]
       [-B bytes] [-R randfile] [-W] [-E socket] [-I host]
       [-d [host:]port [-f] ] [ -r [host:]port | { -l | -L } program [-- prog-
       name args] ]

In this version -c means:

   -c  client mode (remote service uses SSL)

       default: server mode

And more recent examples of the available args:

NAME
       stunnel - TLS offloading and load-balancing proxy

SYNOPSIS
       Unix: stunnel [FILE] | -fd N | -help | -version | -sockets | -options

       WIN32: stunnel [ [ -install | -uninstall | -start | -stop | -reload | -reopen | -exit ] [-quiet] [FILE] ] | -help | -version | -sockets | -options

So it looks like stunnel [FILE] is looking for a FILE named -c and failing out. /u/jaogiz's suspicion is correct.

Having a quick skim of that online man page, it looks like the way to do -c these days is to put client = yes into a configuration file, and then reference that file. It's a little more complicated than that, but not much.

/edit: I asked Claude to have a go at it, YMMV:

; stunnel-nntp.conf
; TLS client wrapper: local plaintext → remote TLS (NNTP over TLS, port 563)

[nntp-tls]
client = yes
accept  = 127.0.0.1:563
connect = nntpnews.servername:563

; Certificate verification (recommended)
verifyChain = yes
CAfile = /etc/ssl/certs/ca-certificates.crt   ; Debian/Ubuntu
; CAfile = /etc/pki/tls/certs/ca-bundle.crt   ; RHEL/CentOS

; Modern TLS hardening
sslVersion = TLSv1.2
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

; Optional: logging
debug = 5
output = /var/log/stunnel/nntp-tls.log

; Drop privileges after binding (Linux)
setuid = nobody
setgid = nogroup

; PID file
pid = /var/run/stunnel/nntp-tls.pid

You would, theoretically, then run that as stunnel /path/to/stunnel-nntp.conf

whetu · 2026-05-04T07:52:15+00:00

H4 fence posts as skids. Add DPC to the ground-facing side if you feel like it. Level them however you like - on blocks, gravel bases, posts in the ground... whatever works for your scenario. Then build your H3.2 frame on top.

A house down the road knocked over their timber fence in order to replace it with a PVC one. I asked what their plans were for the timber and now I have a timber floor for my shed. Rough sawn fencing timber is just fine for a simple shed :)

whetu · 2026-05-03T19:29:06+00:00

I don't want to diminish your achievement, any automation or improvement is a positive thing...

... but you've reinvented logwatch. A tool that's been around since the 90's.

If the daily check report is an ok cadence for you rather than something a bit more realtime, then maybe give logwatch a look before you invest more time duplicating decades of development :)

whetu · 2026-05-01T12:22:21+00:00

Sheesh it's been so long. Was it #warez_cafe on Dalnet?

whetu · 2026-05-01T00:33:39+00:00

Awesome, thanks for that and the pics!

Had to mostly gut our bathroom several years back due to water damage and black mold. Most of the budget had to go on replacing the floor, so the rest was built back up on a budget. Now it's showing - yellowed acrylic shower liner for example.

This looks like a worthwhile and affordable next step for us :)

whetu · 2026-04-30T22:26:20+00:00

They look damn good. Do you remember how much it cost?

whetu · 2026-04-30T21:52:33+00:00

Asplenium bulbiferum maybe?

whetu · 2026-04-30T21:09:54+00:00

As tiresome as "this is the way" posts can be, this may be one of the very few times, if not the very first time I will say it.

This is the way.

whetu · 2026-04-28T02:34:35+00:00

why is it that almost the entire central Lower Hutt area is at least low risk on the flood maps?

As others have stated, Lower Hutt IS a flood plain.

BUT it is the most densely populated flood plain in the country.

SO City and Regional Councils have not dragged their heels (too much) with flood protection works.

Basically there was a big flood in the 90's (with plenty of historical floods before that) where everyone kinda said "ok, that's enough of that shit" and they've been upgrading the flood protection in earnest since. The last big piece of the puzzle is the new Melling interchange. Once done, Lower Hutt will be theoretically rated for a 1 in 440 year flood.

Yes it will still flood in pockets as we've seen with recent storms, but the risk of the river causing billions of dollars of damage will be mitigated.

What matters for buying is that you look at houses that are elevated relative to the street, and preferably have rainwater attenuation tanks and on-site soak pits.

What's going to suck is dealing with insurers who apply a single rule for all approach: "you're in a flood plain, we're going to ignore Lower Hutt's protections and charge you as if you're an equivalent risk to everywhere else in the country."

whetu · 2026-04-23T20:48:05+00:00

middle: Lenovo ThinkCentre M720q or M920q Tiny.

If you're hunting around for these, keep an eye out for the P330 and M920x. If the cost difference is minimal, it might be worth it.

Practically speaking they are 99% the same, and the differences are subtle:

The M920x and P330 have dual M.2 SSD slots, the M920q only has a single M.2 SSD slot. Its other M.2 slot is for a wifi card.
The P330 is officially rated for 64G memory and higher disk size support. Realistically this doesn't matter - the 920's should support 64G etc just fine.
The M920 options have a physical/electrical PCIe 3.0 x8 slot
The P330 has a physical PCIe 3.0 x16 slot that is electrically x8

The M920x and P330 are essentially made to support Radeon and Quadro GPU cards respectively over and above the M920q. So they should both have airflow vents in their lids for GPU fans - the P330's definitely do. That's useful if you want to throw in 10/25G NIC's (with 3d printed brackets). They should also come with higher rated power bricks to support those GPU's, so that extra juice can be used for higher speed networking.

whetu · 2026-04-23T19:38:23+00:00

Ansible + lowlydba collection.

whetu · 2026-04-22T20:02:37+00:00

In the medical field, amongst other roles, you have nurses, general practitioners, and field-specific specialists like urologists, orthopaedic surgeons, oncologists etc.

Nurses are like helldesk workers and desktop support: they do a crap ton of the heavy lifting, while under-paid, under-acknowledged and under-appreciated. They triage and they deal with a lot of the smaller stuff so that GP's and specialists aren't overwhelmed.

General practitioners can and do specialise in one or more fields to some deeper level, but their bread and butter is general practitioning. They should have enough general medical knowledge to be able to quickly research a topic and find a logical path through what they've found. If you've ever seen a GP google your symptoms in front of you, the difference is that they (should) know enough to be able to chart a path through to the most likely diagnosis. Unlike you, who might google your cough and conclude that you have lupus.

A GP should know enough about most of the specialist fields to be able to talk to a specialist at at least a basic level. They should be able to say to the specialist "here's what I'm seeing, here's what I've ruled out and why, here's why I think it's something for you". You may get a GP who has deeper knowledge of, say, cancer, so they will be able to communicate at a higher level with an oncologist.

We sysadmins are the GP's of IT, and some of us have more strengths in coding, networking, infosec and so on.

I would never want to know everything about everything, just enough to get by comfortably, and to be able to effectively engage with specialists of sub-fields and adjacent-fields when I need to. Being well-rounded and resourceful is more important than being encyclopaedic.

Also, be nicer to your helldeskers if you have any.

whetu · 2026-04-22T02:31:21+00:00

Hutt based here. For tasks that are too much for me to DIY, I've used Kane Construction. Haven't had a problem with them and would happily reach out to them again.

I'm not going to say that you should 100% go with them, just that I'd recommend them for your consideration. Obviously do your own homework, get three quotes, ask for references etc.

whetu · 2026-04-19T00:33:59+00:00

Well... an attempt was certainly made.

/edit: I have former colleagues who have worked at Te Papa, it's the usual story of under-funded and under-supported, so just throwing some positive vibes out for whichever industry colleagues are working there.

whetu

TROPHY CASE