six demon bag
Wind, fire, all that kind of thing!
2022-05-21
A Convenience Wrapper for the Puppet Agent
At work we're doing config management with Puppet, and although using the Puppet agent is mostly fine, I have some workflows where it becomes rather unwieldy. For example, when debugging something or developing a new role I usually want to keep the agent disabled, but still do manual (dry-)runs every now and then to check what Puppet would change in the config or apply changes selectively. Which tends to look somewhat like this:
Posted 12:09 [permalink]
2021-01-22
Generate a Solr Password Hash With a Shell Script
In 2017 I published a small Java utility for generating Solr password hashes, because I didn't like launching Solr with well-known credentials. I would've preferred doing it with just a shell script, but found myself unable to replicate the hash creation process with sha256sum
.
A couple days ago user rmalchow contacted me on Github with a solution for that, which I want to share here.
Posted 15:28 [permalink]
2020-06-11
Installing Discourse on Devuan
Before deciding on setting up my Q&A site with Question2Answer I evaluated several programs, one of them being Discourse. And even though I ultimately decided against Discourse (because the setup was too complex and it doesn't have all the features I wanted) I don't want my experiences go to waste, so I'll publish them here.
Posted 19:57 [permalink]
2020-05-23
Shell Patterns (5) - Locking
This is a short series describing some Bash constructs that I frequently use in my scripts.
Sometimes you need to ensure that a script is doing an operation exclusively, to avoid race conditions in case it had been launched several times in parallel. This kind of concurrency control is called mutual exclusion, or mutex for short. In Bash a mutex can be implemented by terminating or suspending execution unless the script is able to create a lock file.
Posted 15:33 [permalink]
2020-04-30
Shell Patterns (4) - Limiting Execution Time
This is a short series describing some Bash constructs that I frequently use in my scripts.
Sometimes you want a script to give up on what it's trying to do after some period of time. The simplest way for limiting the time a given statement may take for execution is the timeout
command.
$ timout 2 ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms $ echo $? 124
However, timeout
is only useful for limiting the execution time of a single (blocking) command. Consider for instance a situation where you deployed a VM or an LXD container, and need to wait for cloud-init to complete on that system. Or a situation where you sent an asynchronous request to a REST API. timeout
won't help you there. You need to poll the system or API repeatedly until the respective "operation completed" indicator appears.
Posted 22:35 [permalink]
2020-03-23
Shell Patterns (3) - Structured Output
This is a short series describing some Bash constructs that I frequently use in my scripts.
On Linux (and many other operating systems) it's common to have regular and error output written to stdout and stderr respectively. In shell scripts you'd use the echo
or printf
commands for displaying messages, and redirect stdout to stderr for having the message displayed on stderr.
echo 'foo' # output goes to stdout
echo 'bar' 1>&2 # output goes to stderr
There may be different levels of information that you want to separate from each other, though, like having additional debug output that you don't want to pollute stdout or stderr. For that you can use the file descriptors 3 through 9.
Posted 15:22 [permalink]
2020-03-06
Shell Patterns (2) - Error Handling
This is a short series describing some Bash constructs that I frequently use in my scripts.
When writing scripts for automation purposes you normally want the scripts to terminate when something goes wrong. Because terminating in a controlled way is usually better than blindly continuing execution when the assumptions subsequent commands are based on aren't valid anymore.
Bash provides several options for controlling error handling, the most commonly used ones being
-e
(or-o errexit
): Exit immediately when a command terminates with a non-zero exit code.-u
(or-o nounset
): Treat unset variables and parameters (except for$@
and$*
) as errors when expanding them. This prevents problems due to misspelled variables.
There are some issues with using just these two options, though:
Posted 17:25 [permalink]
2020-02-29
Non-interactive MongoDB Commandline
MongoDB provides an interactive command shell for working with the database. Which is all nice and dandy, but from an admin and automation perspective it's desirable to also be able to run commands non-interactively. The mongo
commandline tool does have a parameter --eval
that kind of allows you to do that:
--eval <javascript>
Evaluates a JavaScript expression that is specified as an argument. mongo does not load its own environment when evaluating code. As a result many options of the shell environment are not available.
except that it doesn't play nice when you also want to automatically authenticate via the config file .mongorc.js
.
Posted 01:29 [permalink]
2020-02-24
Shell Patterns (1) - Logging
This is a short series describing some Bash constructs that I frequently use in my scripts.
What do you do when you run fully automated scripts in the background, but still want to keep track of what they're doing and, more importantly, when something goes wrong? The answer is, of course, you log what the script is doing (or is about to do).
There are two commonly used ways of implementing logging in Bash scripts:
- redirecting output to files
- invoking the
logger
command for logging to syslog
Personally, I prefer the latter, since it allows not only for managing log files independently of the process creating the log output, but also for filtering log data and/or forwarding it to a central loghost.
Posted 20:47 [permalink]
2015-12-31
Barracuda Backup Agent for Linux Unattended Installation
Barracuda Networks provide agents for their backup appliance for various operating systems. Unfortunately the Linux agent (unlike the Windows agent) does not come with an option for a silent installation, and it doesn't look like the vendor can be bothered to do anything about it.
Instead of being able specify a path on the commandline (or at least force a silent installaton to the default path) you're always prompted for the path where the agent should be installed:
/tmp # tar xzf barracuda_backup_agent-x.x.x.tar.gz
/tmp # cd barracuda_backup_agent-x.x.x
/tmp/barracuda_backup_agent-x.x.x # ./install
Please choose an installation path, or press enter for default.
[/usr/local/barracuda/bbs]: _
Posted 01:13 [permalink]