Today I was still configuring a Fedora-based server, and I noticed that SELinux was not enabled by default. To make sure not to mess up and lose access to the server, I followed the guide on the Fedora website and I enabled the Permissive mode first, set the files to be relabeled after reboot, and rebooted. After reboot, I checked for errors using this command:
I saw one error related to the SSH port, and I learned that I needed to explicitly tell SELinux when SSH runs on a different port (which, in this case, I had changed as part of the setting up process):
$ semanage port -a -t ssh_port_t -p tcp 2222
Having fixed this, I finally set SELinux to Enforcing.
Today I was performing a very common ritual of the software development world: using SSH to log onto a server.
Although I always use SSH keys, for a couple of reasons today I needed to temporarily enable password access. I made sure that password authentication was enabled by setting PasswordAuthentication yes in the sshd_config file and restarting the sshd service, but this didn't seem to work.
After a little debugging, I learned that there might be additional SSH configuration files in the /etc/ssh/sshd_config.d directory; sure enough, there was a file which was overriding my configuration with PasswordAuthentication no. After getting rid of such file, I finally got password access.
Inspecting SSH logs
Another thing I learned today: I was used to inspect the /var/log/auth.log file (or the /var/log/secure file in CentOS), but there was neither on this server whose OS was Fedora 39. Since systemd is now the default, the standard way of inspecting service logs is to use journalctl as follows:
The recent demise of a server because of a hard drive failure inspired me to brush up my knowledge of command-line monitoring tools. I have used smartmontools in the past, and I needed a refresher on smartctl.
Given a /dev/sdX device, you can get a quick health report as follows:
$ smartctl -H /dev/sdX
For a full report, do this:
$ smartctl -a /dev/sdX
The values to be worried about are in the WHEN_FAILED column of the SMART Attributes table. To see this table only, run the following command:
$ smartctl -A /dev/sdX
What I didn't remember, and I relearned today, is that you can run tests (both short and long) in the background:
$ smartctl -t short /dev/sdX (or -t long)
Most importantly, you can poll the test progress with the following:
$ smartctl -a /dev/sdX | grep -A 1 "Self-test execution"
Now that the server is back to life (well, at least for the blog), I am back to my commitment: a blog entry per day for at least a month.
Today it has been a really good day as I finally found the book (or, rather, the reference) I had forgotten and have been looking for for so many days. It turns out my photographic memory was better than my “content” memory: I remembered more the physical look of the page and the paragraph than the text. Actually, the text I seemed to remember sort of misled me.
In case you're wondering, I was looking for Crossing to safety, as cited in Test-driven development.
This should have been the 14th post this year, as I promised to myself I'd write a post per day for at least one month. Obviously, life being unpredictable as well as coincidences existing, the server's hard disk failed before I could take a backup – which I scheduled for this upcoming week. As a result, for now the previous posts are lost. Another lesson for me.