You can check which files a process has open using lsof, but sometimes during troubleshooting you just weant to know how many file descriptors a process has open.
That information can trivially be gleaned from /proc
When creating a unit file for a service, it's possible to increase various limits - Max number of File Descriptors etc - so that if your service is busy it doesn't end up exhausting the resources available to it.
This snippet details the directives and their ulimit equivalents.
A full (and hopefully up to date) list can be found in the SystemD documentation.
With git blame you can view the last commit which changed any given line, but what if you want to see the history/activity of a specific line - why was it added, who changed it and when?
Git 1.8.4 introduced the ability to do this with git log, you just need to know the (current) line number
One form or another of Two Factor Authentication - 2FA - (sometimes called Two step verification - 2SV) is becoming increasingly common. In particular, Time-based One Time Password (TOTP) is very widely used.
TOTP is implemented in products like Google Authenticator, Microsoft Authenticator and Authy (amongst others). You absolutely should use an app like this for your day-to-day needs. However, sometimes it's useful to have a CLI only option to serve as a backup.
In order to use this Python3 snippet, you'll need to have extracted your TOTP secret from whichever systems you're using it on - it's generally displayed wherever you'd normally go to view the QR code when setting up 2FA.
Ensure, though, that your secrets are stored securely - if they're easily compromised you may lose the benefit of the 2nd factor
Sometimes you want a BASH script to be able to fork itself, so that it continues to run in the background, so that it keeps running even if (say) the SSH session is disconnected.
Although you could trigger it manually when calling your script, sometimes you want it to be conditional - if a lock exists you may not want to fork
The mechanism this snippet uses is fairly simple, it checks to see if an environment variable is set, if not, it sets the variable and forks itself into the background, using nohup to ignore any session disconnects
You use the Dell Remote Access Controller (iDRAC) in order to communicate with the RAID array and fetch information about the underlying physical volumes. Unlike traditional spinning disks, Solid State Disks (SSDs) of course have a limited write lifetime, so it's useful to be able to check what percentage of their lifespan remains so that you can proactively arrange replacement.
There's a full cheatsheet for Dell's iDRAC elsewhere, this page simply details how to check the remaining write endurance for your SSDs
mdadm may sometimes send a "degraded array alert" reporting that at least one array is in auto-readonly
md1 : active (auto-read-only) raid1 sdc1[1] sdd1[0]
This most commonly happens after a restart/power-event and isn't usually an issue - MD arrays will be auto-read-only until they're first written too. It happens to try and help make array assembly a bit safer - nothing's written to disk until it actually needs to be
It's sometimes desirable to see whether a set of numbers can be reduced down proportionally - so that their value is reduced without changing the ratio between them. In order to do this, you need to find the largest number that all numbers in the set can be divided by - known as the greatest common multiple (the gcm) or highest common factor (HCF).
Once you've identified the HCF, it's simply a case of reducing each of the input numbers by dividing by that value.
Having PiHole pull a list of blocked ad domains is simple enough, but it gets a little bit more complicated if you want to pull a list of blocked zones (e.g. a block for *.foo.com)
This script (originally created in ADBLK-12) can be run as a cron to periodically pull down a list of zones, turn them into regexes and feed them into pihole so that every label under that name is also blocked
Ordinarily, you will not want to cache POST requests. RFC 2616 does allow, though, for the idea that responses to a POST may sometimes be cacheable.
Generally speaking, whether you consider POST cacheable will depend on what happens on the application back-end in response to that POST - if something is changed as a result then you'll almost certainly not want to cache, whereas if POST is being used to submit (say) search criteria, then you may be happy caching it.
My usecase was the one described above - on a search page, the search query is submitted via AJAX using POST - this means that if you navigate off the page and then click back, you need to wait for the search to run again. A short cache life on the request helps mitigate that.
In order to cache POST requests in NGinx you need to do two things
POST cacheablePOST in the cache keyThe latter of these is important - it means you'll have a different cached entity for different submissions. However, you should be aware that POST bodies can be quite large, so calculating the cache key for these could be quite expensive (i.e. there's a potential DoS vector here)