personal blog
git clone git://
Log | Files | Refs | README

commit 3d3b9b2c3685ac188bce06994bf8552c6b33d308
parent 062095f64d4cd85f47c9efca4597c4cc16e17729
Author: pyratebeard <>
Date:   Mon, 29 Aug 2022 21:02:22 +0100

Merge branch 'main' into a_well-fortified_position

Aentry/ | 23+++++++++++++++++++++++
Aentry/ | 25+++++++++++++++++++++++++
Aentry/ | 53+++++++++++++++++++++++++++++++++++++++++++++++++++++
Aentry/ | 68++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 169 insertions(+), 0 deletions(-)

diff --git a/entry/ b/entry/ @@ -0,0 +1,23 @@ +In 2009 while on deployment I picked up a battered old sci-fi novel from the shelf of books in our equipment tent. + +I remember something about a spaceship crashing on an alien world and the crew having to travel through a dangerous jungle. That is it. I don't remember the name of the novel or the author. I don't remember the characters, major plot points, or even what the cover looked like. + +In the back of my mind I thought I know what the cover was but could never quite bring that image forward. + +For years I have searched for this novel. It is very hard to search for "spaceship crash in alien jungle", there is a surprisingly large number of sci-fi novels with spaceships and jungles. + +Sometimes I think I have come close but have never stumbled upon "the one". That was until last week. As happens on occasion I was going through another bout of searching when I happened on one of the cover images for "The Legion of Space" by Jack Williamson ([ISFDB]({target="_blank" rel="noreferrer"}). The cover caught my eye and so I read the plot summary on [Wikipedia]({target="_blank" rel="noreferrer"} and while most of it didn't sound familiar there was one paragraph; + +> Through the machinations of his uncle, a powerful politician with a hidden agenda, John Ulnar is assigned to Aladoree's guard force at a secret fort on Mars. When she is kidnapped by a huge alien spaceship, John and the three other survivors of the guard force follow her kidnappers to a planet of Barnard's Star. They crash-land and must battle their way across a savage continent to the sole remaining citadel of the Medusae. + +I decided to give it a read, hoping for a moment of remembrance. First I had a look on [Project Gutenberg]({target="_blank" rel="noreferrer"} to no avail. They have some "Astonishing Stories", which Legion of Space was serialised in before being published, but I didn't know the issues and didn't really want to go digging through them all. + +I checked my local library but they also did not carry a copy. Thus I succumbed to Amazon. The novel was available on Kindle so I purchased it, excited that this may finally be it. + +My first thoughts were that my search had failed again. Nothing was sparking any memories. The plot, the characters, I didn't remember a thing. + +Soon the writing, Williamson's descriptive prose, started to feel familiar. Yet still no sudden recollection. Then the spaceship crash on a alien planet and the crew having to venture into a deadly jungle. The only plot points I vaguely remember, and yet, I couldn't be confident this was the same book. + +After finishing the novel a few days ago I have tried to accept that The Legion of Space is probably the novel I read back in 2009. I also am having to accept that for some reason I cannot, and probably never will, actually remember. There are lots of memories I have from that deployment, almost all of it (I think), but not the name, or even the cover art, of that novel. + +Hopefully by finding The Legion of Space I can finally lay this quest to rest. At the very least I have read a(nother) decent sci-fi adventure novel about a spaceship crash in an alien jungle. diff --git a/entry/ b/entry/ @@ -0,0 +1,25 @@ +You have an ssh session on a remote system and your network drops. Your terminal is now stuck. We've all been there. + +Instead of killing the terminal you can use an ssh escape sequence to terminate the session. The sequence we want is `~.` (tilde and period). + +First key Return, then key the sequence `~.`. Your terminal is free! + +This isn't the only ssh escape sequence. To see others open an ssh session to a remote system and key `~?`, you will be presented with this message +``` +Supported escape sequences: + ~. - terminate connection (and any multiplexed sessions) + ~B - send a BREAK to the remote system + ~C - open a command line + ~R - request rekey + ~V/v - decrease/increase verbosity (LogLevel) + ~^Z - suspend ssh + ~# - list forwarded connections + ~& - background ssh (when waiting for connections to terminate) + ~? - this message + ~~ - send the escape character by typing it twice +(Note that escapes are only recognized immediately after newline.) +``` + +On occasion I use `~.` when I experience network drop out. I have used `~^Z` before to suspend my ssh session, useful when you want to leave jobs running and don't have screen or tmux available (see my post "[this ssux](20220331-this_ssux.html) on how I use tmux with ssh). + +The other escape sequences I have not used, but it is good to know they are there. diff --git a/entry/ b/entry/ @@ -0,0 +1,53 @@ +It has now been [8 months](20220113-colemak_exp.html) since I started using the Colemak keyboard layout. After [a few initial issues](20220214-colemak_lvl_up.html) things are going well. + +Vim navigation is no longer a problem, I am comfortable with the new positions of h, j, k, and l. In the last month or so I have also acquired a second keyboard, so I have one permanently configured with QWERTY and can quickly switch them around. This has made dealing with VMs much easier. + +## patch all the things +A new issue that arose was on updating the xorg packages. The update replaced /usr/share/X11/xkb files, thus removing my colemak-ctrl custom config. + +After a bit of digging I found that I could put my colemak-ctrl setting into its own file under /usr/share/X11/xkb/symbols/, instead of the 'us' file. I also found that I don't necessarily need the entries in /usr/share/X11/xkb/rules/base.{lst,xml}. For reference /usr/share/X11/xkb/symbols/colemak-ctrl looks like this +``` +// colemak-ctrl +partial alphanumeric_keys +xkb_symbols "colemak-ctrl" { + // include standard colemak layout + include "us(colemak)" + + key <CAPS> { [ Control_L, Control_L, Control_L, Control_L ] }; +}; +``` + +Now instead of selecting the variant +``` +setxkbmap -option ctrl:nocaps us -variant colemak-ctrl +``` + +I can incant +``` +setxkbmap -option ctrl:nocaps colemak-ctrl +``` + +## these boots are made for typing +The keymap on boot issue was also resolved by adding the following to /etc/vconsole.conf +``` +KEYMAP=colemak-ctrl +``` + +Then I included the keymap hook before the encrypt hook in /etc/mkinitcpio.conf +``` +HOOKS=(base udev autodetect modconf block keymap encrypt lvm2 filesystems keyboard fsck) +``` + +I also set the keymap for X11 by adding the following to /etc/X11/xorg.conf.g/20-keyboard.conf +``` +Section "InputClass" + Identifier "keyboard" + MatchIsKeyboard "yes" + Option "XkbLayout" "colemak-ctrl" +EndSection +``` + +## neverending story +I can confidently say I am now a Colemak user. In the beginning I thought this little experiment wouldn't last and by now I would have returned to QWERTY, but quite the opposite in fact. I feel at home using Colemak as my daily driver, and even looked into replacing the keyboard on my laptop with Colemak. + +Hopefully my journey will inspire somebody else to give it a go. diff --git a/entry/ b/entry/ @@ -0,0 +1,68 @@ +It is common for system administrators to be thought of as strict gatekeepers, not allowing access to anybody. + +In my experience nobody bats an eye when you're unable to use the Administrator account on a company laptop, but having to run `sudo` without simply switching to root on a Linux server is absurd. + +The hardening and security of Linux servers is very important, yet so many people and companies fail to restrict access correctly. I have always been an advocate of enforcing the correct use of sudo, specifying commands instead of allowing full root access. Command exclusion is equally important, and in my opinion often overlooked. A good sudoers configuration will exclude users from running commands that could potentially allow them to get a root shell, this includes excluding all shells, management tools such as `chmod`, and even commands like `vim` and `tar`, which can easily be used for privilege escalation. + +## ed, edd, and edit +Excluding `vim` and `vi` poses an issue when users do need to edit files on the system. Thankfully the contributors to `sudo` came up with a solution, the `-e` option or `sudoedit`. + +The `sudoedit` option allows a user to edit files by making a temporary copy owned by the user. To give an example, lets say we have a user that requires permission to edit the Apache config file. They can be granted access in /etc/sudoers, or my preferred method is to put a file into /etc/sudoers.d/. The line would look like this +``` +bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf +``` + +The user can then edit the file in one of two ways +``` +sudo -e /etc/httpd/conf/httpd.conf +sudoedit /etc/httpd/conf/httpd.conf +``` + +This creates a copy of the file in /var/tmp, such as `"/var/tmp/httpdXXJkszaG.conf"`, which is owned by the user. Once the changes have been made the file can be saved and exited as normal. + +Wildcards can also be used to specify whole directories or multiple files +``` +bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf, sudoedit /etc/httpd/conf.d/*.conf +``` + +## (e)u:4(ia) +Recently I had a user who required access to read some of the system log files so they could debug an issue. As expected I didn't want to grant them sudo permission, overkill for reading some files. Instead I opted to use the file access control list tool `setfacl`. To grant a use read permissions to a file incant +``` +sudo setfacl -m u:bob:r /var/log/messages +``` + +Group permissions can also be set with +``` +sudo setfacl -m g:bob:r /var/log/messages +``` + +To view a file's ACLs incant +``` +sudo getfacl /var/log/messages +``` + +The output will look something like this +``` +getfacl: Removing leading '/' from absolute path names +# file: var/log/messages +# owner: root +# group: root +user::rw- +user:bob:r-- +group::--- +mask::r-- +other::---k +``` + +Removing a user's access once they no longer need it is done with the `-x` option +``` +setfacl -x u:bob /var/log/messages +``` + +The use of ACLs means you don't need to modify the file or directories ownership but can still safely give users the permissions they require. + +#### rotate me right round +Be careful if setting ACLs on log files as the permissions will be lost when the logs are rotated. If you require persistence add the `setfacl` line(s) to the relevant logrotate config file. + +## go forth and sudo +Using `sudo` should not be shied away from, but it should also not be used in an all or nothing manner. It may annoy your users but you will rest well at night knowing that you have control and no one can take that from you, something, something, gatekeeper.