In the previous post I mentioned the planutils project as an easy way to try several PDDL planners. Today I learned about the planutils server, a simple Flask app that exposes an HTTP API to invoke planners remotely, and I thought it's a brilliant idea. As of now, the API can only be used to get information on installed planners and to invoke each of them with its basic parameters, namely the PDDL domain and problem.
The nice thing about it is that there is a setup script to set up a planutils server Docker container with a few representative planners (among which OPTIC for PDDL3 support, ENHSP-2020 for numeric planning, and TFD for temporal planning) and an exposed port (5555 by default).
With the server container running, the API can be used with any usual tool. An example with curl could be like this:
Prompted by a recent discussion, I went “back to the basics” and took a new look at PDDL.
The language, based on STRIPS (which I know from early courses in robotics), has undergone several improvements to make it more and more expressive. This means that, as it happened with RDFS, OWL, and their reasoners, there are different planners that make use of one version of the language or another, and finding what planner supports what version and what specific features of the language is not always easy.
The Planning.wiki website has a good review of the main versions of the languages as well as a list of (some of) the known planners. Today I also discovered the planutils project that aims to make trying different planners easier by packaging them with Docker. The setup is quite easy and using it is also relatively straightforward.
I began doing some experiments with PDDL myself, which I'll write about in another post.
Today I was looking for a way to easily backup data from my Android mobile phone onto a remote server. While there are plenty of apps that can be used to send data to a cloud service (and, obviously, to Google), there aren't many that can be used with one's server, or at least without a certain amount of fiddling (like Termux).
A seemingly good one I've come across is FolderSync.
Pros:
Supports SFTP both with credentials and with an SSH key.
It has many scheduling options, so it's easy to “set and forget”.
It gives some guarantees when it comes to privacy and data collection.
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.
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"