Obteniendo los Archivos de Instalación

Cuando hice todo esto faltaban unas cuantas semanas para el lanzamiento de la versión 7.6 por lo que opté por descargar la versión snapshot y, de paso, forzarme a probar el proceso de upgrade de OpenBSD, que supuestamente asemeja al modo rolling release, i.e., no es necesario reinstalar el SO para un upgrade mayor.

Mi aparato es de arquitectura amd64 y usé wget(1) para descargar todos los archivos necesarios con los siguientes comandos:

$ mkdir ~/Downloads/openbsd
$ cd ~/Downloads/openbsd
$ wget -r --no-parent --no-clobber "https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/"
$ mv cdn.openbsd.org/pub/OpenBSD/snapshots/amd64 snapshot-amd64
$ rm -r cdn.openbsd.org
$ cd snapshot-amd64
$ shasum -c SHA256

Preparando Dispositivos de Instalación

Yo usé 2 USB para mi instalación, por lo que mis dispositivos eran los siguientes:

1. USB (“sdb”), ext2, paquetes de software
2. USB (“sdc”), imagen de disco booteable (install76.img)
3. SSD, disco en el que instalaré el SO

Noté que al usar el formato FAT para la USB con los paquetes de software ocasiona un error al momento de verificar la integridad. Específicamente, el programa de instalación no reconoce los archivos INSTALL.amd64 ni SHA256.sig.

NOTA: OpenBSD tiene soporte nativo para ext2 pero tengo entendido que no tiene soporte para ext3 ni ext4.

Desde un sistema Linux:

% fdisk /dev/sdb
# crea una particion en la USB, e.g., sdb1
% mkfs.ext2 /dev/sdb1
% mount /dev/sdb1 /mnt/usb
% mkdir -p /mnt/usb/7.6/amd64
% cp -r ~/Downloads/openbsd/snapshot-amd64/* /mnt/usb/7.6/amd64/
% umount /dev/sdb1
% dd if=~/Downloads/openbsd/snapshot-amd64/install76.img of=/dev/sdc bs=1m

NOTA: al momento que descargué los archivos, la ultima versión estable era 7.5, por lo que la versión snapshot se referencía como 7.6.

Proceso de Instalación

Aun no tengo un modelo mental claro de como el sistema operativo mapea los discos a archivos, pero logré instalar el sistema creando archivos especiales con el script MAKEDEV(8).

Primero listé los discos encontrados por el kernel y después llamé al script para crear los archivos especiales:

% sysctl hw.disknames
hw.disknames=sd0:,sd1:f0bda3e4b66f6f9c,sd2:
% cd /dev
% for my_dev in sd0 sd1 sd2 ; do sh MAKEDEV $my_dev ; done ; cd /
% for my_dev in sd0 sd1 sd2 ; do fdisk $my_dev ; done
# [...] contenido de tablas de partición de los 3 discos

Con los discos en su lugar, procedí con la instalación automática que ofrece el instalador. No recuerdo como se llama el script, pero ejecutando ls / deberá ser aparente la ubicación.

Problemas Encontrados

Firmware

Al finalizar la instalación y bootear el sistema por primera vez me encontré con un sistema roto: el proceso de arranque abortaba por no encontrar el firmware (DRM) para mi GPU de AMD. El error decía, entre otras cosas: “openbsd amdgpu_discovery_init failed”

Para solucionar este problema tuve que repetir el proceso de instalación pero esta vez configurando una interfaz de red durante el proceso y que así el firmware pudiera ser instalado automaticámente gracias al comando fw_update(8).

Reloj

Apenas pude bootear a la nueva instalación, tuve problemas al buscar paquetes con pkg_info -Q pues por algún motivo no se configuró correctamente la hora de mi sistema. Esto se corrigió fácilmente con los siguientes comandos:

% rcctl stop ntpd
% /usr/sbin/rdate time.cloudflare.com

NOTA: como regla, prefiero configurar la hora de BIOS a UTC y dejar que los sistemas operativos configuren la zona horaria.

Instalación Base

Una vez con el sistema funcionando, instalé obsdfreqd siguiendo los pasos indicados por Solène. No funcionó a la primera, por lo que tuve que modificar su configuración a través de rc.conf.local(8):

% rcctl enable obsdfreqd
% echo 'obsdfreqd_flags="-T 45 -S hw.sensors.km0.temp0"' >> /etc/rc.conf.local

No hice mi tarea a fondo por lo que fuera del comando rcctl(8) no sabía como funcionan los servicios en OpenBSD. Puesto que tiene un sistema init similar al de Slackware, o sea, /etc/rc.d/, encontré el script de configuración /etc/rc.d/obsdfreqd que inicialmente modifiqué para echarlo a andar, pero abrí los scripts por curiosidad y me sorprendió la simplicidad de rcctl(8). Muy elegante y facil de seguir.

Access Point

Quería configurar mi equipo como Access Point siguiendo el ejemplo 1 de pf(4) pero descubrí despues de varias horas que no es posible replicarlo exactamente:

• La antena de mi equipo usa el driver iwm(4), diferente al driver athn(4) del ejemplo
• iwm(4) cuenta con los modos BSS y monitor, que le permiten asociarse con un Access Point y recibir paquetes sin asociarse a un AP, respectivamente.
• No soporta el modo Host AP necesario para que funcione como Access Point

Conclusión

Me gustaría seguir escribiendo aquí a medida que vaya configurando mi sistema pero esta publicación ya incluye mas de lo anticipado y ha perdido orden.

Estoy muy satisfecho con el script de instalación automática de OpenBSD, es muy rapido y deja un margen de error pequeño comparandolo con el de Slackware (no tengo experiencia con otros). El manejo del sistema base me parece una chulada, es tan simple que mi instinto fue modificar los scripts para arrancar los daemons que quería y a medio camino recapacité para no seguir hackeando y mejor leer los manuales.

Y los manuales hasta ahora me parece que sostienen su reputación. Quise habilitar un servicio con rcctl así que leí su manual, lo que me llevó a rc.conf(4) y ahí mismo explican rc.conf.local(4).

Por defecto usa ksh a la que no estoy acostumbrado pero para mi usuario la cambié facilmente a bash(1) con chsh(1).

Subiendo y bajando en el
seno de tus días.

Poco a poco el pulso baja
y el ritmo aumenta.

Me arrepiento, perdono.
Quiero hacer mas y lamento el tiempo.

Quiero ser un grano de arena
y no de plomo.

Siento alivio. No hay diferencia.

For context, our periodic jobs are basically invocations of bundle exec rake <task> commands, so each task is running within a ruby process and Sentry provides an easy to use API via their SDK.

The “Set Up Crons” document is straightforward and easy to follow. Given we’re not using Sidekiq we couldn’t just include their modules and call it a day. Instead we used the “Manual Setup” approach but it quickly became a repetitive task to do a check-in for every job.

Upserting Cron Monitors

We already have a YAML file used to provision the nomad jobs with a cron schedule, command and per-environment resources. We added a few more properties to support “upsert” easily:

• slug: used to identify Sentry monitors
• max_runtime: to let Sentry know how long the job is expected to run
• checkin_margin: we trust Nomad to spin-up the job on time but it doesn’t hurt to add this measure.

So the YAML file ended up looking like the following:

# config/nomad_jobs.yml
default: &default
  cron: "* * * * *"
  # Sentry cron monitors settings
  checkin_margin: 5 # Optional check-in margin in minutes
  max_runtime: 15 # minutes

send_daily_reports:
  <<: *default
  cron: "30 15 * * *"
  command: "bundle exec rake geckox:send_daily_reports"
  slug: "daily-reports"
  max_runtime: 3

# ...

And with this in place, we fully took advantage of Sentry’s capture_check_in method:

module Geckox
  class << self
    # Execute block within a Sentry cron check-in for the given slug.
    #
    # This will "upsert" the monitor if <code>slug</code> is found in
    # <code>config/nomad_jobs.yml</code>.
    #
    # @param slug [String] Slug matching a manually created Sentry monitor
    # @yield [] Block receives no arguments
    #
    # @see https://docs.sentry.io/platforms/ruby/crons/#manual-setup
    # @see https://docs.sentry.io/platforms/ruby/crons/#upserting-cron-monitors
    def sentry_check_in(slug)
      monitor_config = nil
      nomad_job = Rails.configuration
        .nomad_jobs
        .select { |key| Rails.configuration.nomad_jobs.dig(key, "slug") == slug }

      if nomad_job.present?
        nomad_config = nomad_job.values.first
        monitor_config = Sentry::Cron::MonitorConfig.from_crontab(
          nomad_config["cron"],
          checkin_margin: nomad_config["checkin_margin"],
          max_runtime: nomad_config["max_runtime"]
        )
      end

      check_in_id = Sentry.capture_check_in(slug, :in_progress, monitor_config: monitor_config)
      yield
      Sentry.capture_check_in(slug, :ok, check_in_id: check_in_id, monitor_config: monitor_config)
    rescue => e
      if defined?(check_in_id)
        Sentry.capture_check_in(slug, :error, check_in_id: check_in_id)
      end
      raise e
    end
  end
end

# To trigger a monitored job
Geckox.sentry_check_in("daily-reports") do
  SendDailyReportsJob.perform_now
end

And with this in place, we got a nice UI informing us if something isn’t right at a glance.

Additionally, whenever an error is raised from a periodic job, it’s automatically linked from the monitor page to a Sentry issue with the relevant context at hand. Great product integration!

For over a year I’ve been working on an old Ruby on Rails application that started around 2009, so it has many in-house Rails features because they were not part of Rails yet.

Several years ago it started using React (and Elm, but thankfully that’s no longer the case) with webpacker 3.5 and the JS instrumentation grew explosively but webpacker was never updated — according to the main branch of git, maybe there ware attempts but weren’t merged.

From my first day I had issues with tech debt as I was provided an M1 laptop and couldn’t get the application running, as the dependencies were:

• Ruby 2.6.6 – not compatible with M1. Maybe compatible with Rosetta? I preferred the slow process of upgrading ruby rather than hoop around.
• Node 10 – not compatible with M1
• Elm 19 – not compatible with M1 and no community. Not even with Docker did the compiler work
• Webpacker 3.5 – abandoned project, replaced by Shakapacker
• Ruby on Rails 5.2

After a couple of months I upgraded ruby to v2.7 so that was running natively in the hardware, but the huge front-end codebase lacked behind with lots of flavors and dependencies intertwined: jQuery, React, in-house, Elm, SASS, LESS, SCSS. A senior developer on the team removed the Elm portions of the app right before leaving the company and without him I don’t think I would’ve been able to do this, I would’ve tagged this project as abandonware in my mind and moved on.

Hundreds of internal source files, thousands of vendor assets & countless NPM dependencies… it was a dire situation.

Different Experiments, Multiple Attempts

The adage says that we should upgrade one major version at a time. In this case, though, I started by trying to upgrade node 10 to node 12 as it’s the next LTS (Long Term Support) version – both versions were unmaintained at the time.

This didn’t work as some NPM dependencies required node <= 10 and upgrading dependencies broke a bunch of other things.

Next attempt was going to node 14 (unmaintained LTS) which allowed to upgrade a lot of dependencies but there were still a crucial few which crushed this attempt, node-sass among them which is also unmaintained.

I spent about a month installing thousands of dependencies, seeing log errors and clearing busted docker images and cache layers… At this point I felt defeated and abandoned the effort for a few months.

I continued working on other ruby/rails aspects of the application which gave me confidence on how the application worked, how it failed and overall set expectations on what was working and what didn’t, but none the less was expected behavior.

Another Shot With Clear Expectations

So after about a 3 month long rest, I decided to give it another shot and to look at webpacker as a black box and care only for the output assets, i.e., the output might be syntactically different but should otherwise produce “equivalent” JS code. So I tried upgrading to node 18 (LTS and works on the M1).

It’s important to note I was prepared for the thousands of lines of error logs, cryptic error messages and slow change-compile-repeat cycles. I consider morale the most important factor for maintenance upgrades. Seeing so many errors coming from files you didn’t know exist sucks the life out of you.

With this in mind, I set these expectations for myself:

• JS MUST compile
• CSS MUST compile
• MUST work natively on the M1
• MUST NOT change the test suite expectations — as much as I dislike how cumbersome selenium is, it’s an invaluable investment the previous developers did for this application
• Minor customer-facing features MIGHT break and I will fix them iteratively after the fact

It became so much easier to chew the problem. It was still boring seeing a compiler error, changing a file and checking again ad nauseam but it wasn’t frustrating anymore. Most of the issues were SCSS syntax used in SASS files and some asset location joggling, e.g., images, but after a few weeks the code was compiling successfully and it became a red-green cycle with the test suite. All in all, it took about a month to get a release candidate branch which was daunting to review with around 650 files changed.

Simplifying the Pull Request

I like fixing things along the way when I work on something (who knows when another opportunity will present itself) but with this PR (Pull Request) I decided to make as few changes as possible AND also slip simple changes to other PRs which were being merged regularly so instead of not fixing issues along the way, I was fixing them earlier, e.g.:

   <%- content_for(:js) do %>
     <script>
-      initFeatureSPA();
+      window.addEventListener('DOMContentLoaded', function() { initFeatureSPA(); });
     </script>
   <% end  -%>

Something changed in the way JS assets were being loaded which meant <script> elements were being executed before scripts finished loading (now they’re deferred?). I don’t care enough to go and understand why but changing these JS snippets to the Correct™ way fixed a lot of the failing tests albeit added a lot of noise to the PR, so I merged them to the main branch before the big upgrade, which made the review process much more manageable.

After all was said and done, the PR went from 656 files down to 140 – not messing too much with webpack configuration being the biggest factor at play.

Conclusions

It’s a daunting process and it may seem like an unworthy effort, but with the right mindset it becomes an almost easy process. It’s just slow as hell. I spent about 6 months with the multiple experiments and keeping the problem in the back burner of my mind when not working on it – it’s an iterative process!

On Management

Development aspects aside, Management™ was never onboard with all of this. They weren’t openly against it but didn’t see the upside. From my perspective, it improved my workflow tremendously as I no longer work with the overhead of Docker’s VM (still use it for DB & Redis) and the battery life of my laptop is longer than a day now.

That’s probably why management doesn’t care. It doesn’t add business value directly. But as part of this, I upgraded a bunch of dependencies, found the root cause of recurring production issues and fixed many long-hanging-fruit problems that would’ve otherwise remained in this codebase on the brink of abandonware.

All this to say, as Developers™ we should try to address tech debt at least indirectly even when lacking support from Management™ — it makes our day to day much more enjoyable and allows us to add business value at a faster rate.

"Beetle Buggy" by Ryan McGuire is marked with CC0 1.0 .

The Setup

At my current job we have a CI/CD pipeline that builds a Docker image that is later deployed to replace the current version in production. It is a multi-step process (workflows, in GH parlance) that used to consist of:

1. Run CI workflow (~50 minutes)
   1. Make sure application is installable (using cache to optimize dependencies downloads)
   2. Unit tests
   3. Integration tests (selenium)
2. Run CD workflow (~30 minutes)
   1. Build image: some dependencies need to be compiled (~25 minutes)
   2. Deploy to production

The second workflow is run automatically by GH Actions when the first workflow completes, i.e., on: workflow_run in the Workflow spec, so we would need to wait for about 1 hour and a half before we actually see our changes in production.

The Refactor

Since we use Docker for the build process, there’s already a tried and tested cache layer that I know we were not taking advantage of. After ducking around a bit, I arrived at Docker’s GitHub Actions cache documentation which outlines the (currently experimental) integration with Actions’ cache. To optimize image caching I decided to split the image into two:

1. base: install system dependencies, e.g., runtimes and dependencies that need to be compiled and don’t change as often, e.g., HTTP server.
2. application: install dependencies that can simply be downloaded or change more often.

After testing locally this reduced the build process from 20 to ~5 minutes, but when merged to the main branch and tested in the GH Actions servers, the cache didn’t work as expected.

This is because GH Actions cache was being created on the feature branch but, after merging, it would not be picked up by the main branch build process. There were multiple ways to solve this but I decided to restructure the pipeline to run some steps in parallel:

1. Run CI workflow (~50 minutes): all steps in parallel
   1. Build image only for main branch
   2. Unit tests
   3. Integration tests
2. Run CD workflow (~5 minutes)
   1. Deploy to production

With the new layout the CI process still takes a long time (due to selenium tests) but the whole pipeline runtime was reduced by about 30 minutes.

The above mentioned pipeline doesn’t illustrate that the “Build image” step is actually building both the base image and the application image which can be improved further by NOT building the base (i.e., go straight to cache) image unless specific files changed. In our case, we want to build the base image only if the base Dockerfile changes. To achieve this, I used the dorny/paths-filter action to detect changes on specific files, further reducing the processing needed to build the application image.

The Rails

This setup was conceived specifically for a Ruby on Rails application with several gems that require a compilation with native extensions which is a redundant step for dependencies like puma or sassc that rarely change. So at the end of Dockerfile.base, after all “OS” dependencies have been installed, we install these gems individually which will become CACHED layers for the image build process, e.g.:

FROM --platform=linux/amd64 debian:12-slim AS geckox

RUN apt-get update -q && apt-get install -qqqqy ...

...

RUN gem install --no-document puma -v 6.4.0
RUN gem install --no-document sassc -v 2.4.0

As a rule of thumb (which I break when my setup grows), I DO NOT include ADD or COPY statements in my Dockerfile.base file to avoid unintentional layer cache expiration; I add those to the Dockerfile.app image which usually copies the application code to the image.

The CI Workflow

After all was said and done, the CI workflow looked something like this:

name: CI
on: push

jobs:
  setup:
    steps:
      - Download dependencies...

  tests:
    steps:
      - ...

  integration_tests:
    steps:
      - ...

  # Build docker images only for main
  build_base_image:
    if: ${{ github.ref == 'refs/heads/main' }}
    env:
      REGISTRY: ghcr.io
      IMAGE_NAME: orgname/geckox/geckox-base-image
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      # dorny/paths-filter (git) errors out because of "dubious ownership in repository"
      - name: "Change repository directory permissions"
        run: |
          git config --global --add safe.directory /data/runners/geckox/work/geckox/geckox || true

      # https://github.com/dorny/paths-filter
      - name: Check Dockerfile.base
        id: changes_filter
        uses: dorny/paths-filter@v2
        with:
          filters: |
            dockerfile_base:
              - added|modified: 'build/Dockerfile.base'

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Log in to the Container registry
        uses: docker/login-action@v2
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Skip image build process for Dockerfile.base
        if: steps.changes_filter.outputs.dockerfile_base == 'false'
        run: echo "Skipping..."

      # https://github.com/docker/build-push-action/tree/v4
      - name: Build and push Docker image
        if: steps.changes_filter.outputs.dockerfile_base == 'true'
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          cache-from: type=gha
          cache-to: type=gha,mode=max
          file: build/Dockerfile.base
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest

  build_image:
    needs: build_base_image
    if: ${{ github.ref == 'refs/heads/main' }}
    env:
      REGISTRY: ghcr.io
      IMAGE_NAME: orgname/geckox/geckox-app
      GITHUB_SHA: ${{ github.sha }}
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Log in to the Container registry
        uses: docker/login-action@v2
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Set IMAGE_TAG variable
        run: |
          echo "IMAGE_TAG=$GITHUB_SHA"
          echo "IMAGE_TAG=$GITHUB_SHA" >> $GITHUB_ENV

      # https://github.com/docker/build-push-action/tree/v4
      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          cache-from: type=gha
          cache-to: type=gha,mode=max
          file: build/Dockerfile.app
          build-args: |
            BASE_TAG=latest
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}

Update 2024-10-01: I got a Framework Laptop 13 because the Thinkpad’s display quality was jarring after interchanged use with macbook laptops. A lot of the steps detailed here have been revisited for slackware64-current unless noted otherwise.

This isn’t as straightforward compared to other distros, but once you’re familiar with the process it isn’t too complicated. First of all you need to get an ISO for the version you want to install. If you go to the Get Slack page you’re told to download from one of the mirrors, i.e., https://mirrors.slackware.com/. After a few more clicks you end up in the official mirror’s directory for slackware ISOs. I’m gonna use slackware64-15.0-iso.

Making the Bootable USB

These ISOs are intended to be used for DVD installation, which isn’t very common as of this writing. After you download the ISO you can mount it in your computer to get the USB installation image by reading the usb-and-pxe-installers/README_USB.txt file. I’m gonna summarize what I do:

• Mount the ISO, i.e.: $ mount $HOME/downloads/slackware-15.0-install-dvd.iso /mnt/dvd
• Burn the bootable image to an USB drive, i.e.: $ dd if=/mnt/dvd/usb-and-pxe-installers/usbboot.img of=/dev/sdb bs=1M status=progress
• Burn the ISO itself to another USB drive, i.e.: $ dd if=$HOME/downloads/slackware-15.0-install-dvd.iso of=/dev/sdc bs=1M status=progress

My bootable USB couldn’t load the kernel properly (not enough memory to load initrd), so I had to pass some parameters to the boot line:

boot: huge.s noapic mem=2048M

Installation

The idea is to mount the second USB in a directory before running setup and then entering that directory path when asked:

% mkdir /usb
% mount /dev/sdc1 /usb
% ls /usb/slackware64
CHECKSUMS.md5 CHECKSUMS.md5.asc FILE_LIST MANIFEST.bz2 PACKAGES.TXT
a/ ap/ d/ e/ f/ k/ kde/ l/ n/ t/ tcl/ x/ xap/ xfce/ y/

When asked for the SOURCE pre-mounted directory, you should input /usb/slackware64.

After booting the installation USB (UEFI, legacy BIOS or whatever) and following the partitioning instructions (read the Slackware-HOWTO file at least twice), you will run the setup program.

After selecting your TARGET partition table, you need to specify a SOURCE for the programs you want in your system, which is where the second USB comes to play.

NOTE: if you don’t see all the series options in the SELECT step, the pre-mounted directory wasn’t configured correctly.

Kernel Parameters

After the setup program completes installing the software series, you might want to generate an initrd (read the README.initrd file).

For this hardware I also needed to append some parameters to the kernel on boot via lilo.conf(5), after all is said and done, my append line looks like this:

append = "noapic resume=/dev/slax/swap acpi_osi=Linux acpi_backlight=vendor i8042.direct i8042.dumbkbd "

• noapic is set so the kernel can detect the hardware properly
• resume=/dev/slax/swap where to look for an image after suspension
• acpi_osi=Linux acpi_backlight=vendor are set so the kernel can change the display’s brightness
• i8042.direct i8042.dumbkbd A485’s keyboard [hardware] interface is messed up, this helps. You also need to update your BIOS because the keyboard will send your key presses to the kernel out of order — I don’t know why the hardware behaves this way, but it does

Slackware 14.2 and older

For starters, the slackware 14.2 ISO uses linux kernel 4.4.16 (?), which does NOT support the wireless card, so you need to upgrade the kernel using an ethernet connection.

And after that, you need to install the wireless card drivers separately, since they’re not in the linux tree yet. Fortunately, lwfinger uploaded the driver code to github: lwfinger/rtlwifi_new. Which seems to be down as of this writing but if you contact me I can send you the code. The README explains it all: minimum kernel version requirement, you need to rebuild the driver whenever you change kernel version, etc.

X

The default sensitivity for the touchpad is way too high, i.e., it’s very sensitive. Whenever I’m typing something if something as thin as a hair touches (okay, maybe not so thin) the touchpad, it will move the cursor AND click on stuff. Annoying things happen, like pasting of clipboard’s content, random text selection, input focus loss, etc.

Browsing around I stumbled upon a Linux Mint forum thread, which in turn points to synaptics(4) where you can read the driver’s configuration options. Someone pointed out that you the Synaptics Finger option affects touchpad sensitivity (someone else says the “Hysteresis” options help, I think those are tweaked via de Noise Cancellation option)

As per the man page, Synaptics Finger takes three 32-bit values, from reading between lines I gather that those values represent:

1. FingerLow: when pressure goes below this value, count as release.
2. FingerHigh: when pressure goes above this value, count as touch.
3. Pressure Motion: read the man page, it’s a bit nuanced (or it may be something else ¯\_(ツ)_/¯).

As a rule, FingerLow MUST be lower than FingerHigh (duh).

% echo "Check your hardware and it's id"
% xinput --list
...
>   * SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
>   * TPPS/2 IBM TrackPoint                     id=13   [slave  pointer  (2)]
...
% echo "So we know that the touchpad is using synaptics and it's id is 12"
% xinput --list-props 12 | less
Device 'SynPS/2 Synaptics TouchPad':
        Device Enabled (134):   1
...
        Synaptics Finger (267): 24, 36, 48
...
% echo "The idea is to play around with these values, so play"
% xinput --set-prop 12 267 42 48 192
```

Honestly, I’m still not sure how the third value affects the touchpad’s behaviour, so I still tweak these values from time to time.

Screen Brightness

A feature I love from phones is that automatic screen color temperature on the environment or time of day. Something similar can be achieved for X11 using the sct (screen color temperature) utility; can be done manually or via a cron job.

I use the following ruby script:

#!/usr/bin/env ruby
# Change screen color temperature (sct(1)) automatically depending
# on current time of day.
#
# Meant to be invoked by crontab(1), e.g.: `0 * * * * /path/to/ruby-script`
#
# @see https://crontab.guru/ Sensical cron schedule editor

COLD_TEMPERATURE = 6500
WARM_TEMPERATURE = 5000

require 'time'

now = Time.now
temperature = COLD_TEMPERATURE
temperature = WARM_TEMPERATURE if now.hour < 8 || now.hour >= 18

exec("sct #{temperature}")

Window Manager

awesomewm via slackbuilds.

Screen Resolution

The framework laptop has a big display. The biggest I’ve ever used on a laptop, so as great as the resolution is, I can’t see shit. Since I’m not using XFCE or KDE which have controls to adjust the rendering scale, I had to figure out how to increase the size of text for the whole system. Naturally, this is configured via the X server.

I found a great tutorial to do just that. These are the steps I did while following the instructions:

$ xdpyinfo | grep -B2 resolution
screen #0:
  dimensions:    2256x1504 pixels (596x397 millimeters)
  resolution:    96x96 dots per inch
$ echo "Calculating ideal DPI for screen dimensions"
$ irb
irb(main):001> inches = [59.6 / 2.54, 39.7 / 2.54] # convert cm to in
=> [23.46456692913386, 15.62992125984252]
irb(main):002> dimensions = [2256, 1504]
=> [2256, 1504]
irb(main):003> dimensions.zip(inches).map { |x, y| x / y }
=> [96.14496644295302, 96.22569269521411]
$ echo 'Xft*dpi: 128' >> $HOME/.Xresources
$ xrdb -merge $HOME/.Xresources

So my system is correctly setting the DPI to 96 but I find it too small, so I increased it to 128. I saw a recommendation somewhere about using multiples of 96 but setting it to 192 was way too big so I preferred multiples of 32.

I also found a tutorial to change the scale of specific displays when using multiple monitors which I’ll probably revisit later.

SLiM

From the package description:

SLiM is a lightweight login manager based on GNUstep’s Login.app. It makes a great replacement for XDM for those who want something that looks good, but still do not want Gnome or KDE.

I boot directly to a graphical environment and use SLiM to start awesome WM via my user’s $HOME/.xinitrc. For this, I set the default runlevel to 4 in /etc/inittab.

I also create the following file:

% cat <<EOF > /etc/rc.d/rc.4.local
#!/bin/bash

# Start SLiM...
if [ -x /usr/bin/slim ]; then
  exec /usr/bin/slim
fi
EOF
% chmod +x /etc/rc.d/rc.4.local

And change the login_cmd line in /etc/slim.conf to run $HOME/.xinitrc:

% cat /etc/slim.conf
...
login_cmd           exec /bin/bash -login ~/.xinitrc %session
# login_cmd           exec /bin/bash -login /usr/share/slim/Xsession %session
...

Running per-user applications

To run applications after logging in, I run a few programs and then send them to the background via xinitrc by including this snippet:

# $HOME/.xinitrc
...
[ -f $HOME/.xinit_private ] && sh "$HOME/.xinit_private"
...

And in $HOME/.xinitrc_private I run some applets, e.g.:

# $HOME/.xinitrc_private

nm-applet & # XFCE4 NetworkManager applet loaded to system tray

File Manager

I’ve been using Thunar lately. At first I found it too bright compared to what I’m used to, so I duckduckgoed around and discovered you can configure it via lxappearance(1) and that there are a lot of themes from the community, I picked Dark Olympic as I find it compact and not so dark.

Thunar allows you to add custom actions to interact with files (e.g., extract a zip archive) and I used to do just that, but now I simply install the thunar-archive-plugin as they recommend:

% myslack install -y thunar-archive-plugin

Default Applications

I try to use xdg-open(1) which will try to open a file depending on it’s MIME type, one can easily override system defaults by using a file in $HOME/.local, e.g.:

$ mkdir -p ~/.local/share/applications
$ cat <<EOF > ~/.local/share/applications/defaults.list
application/pdf=okular.desktop
EOF

Just make sure you specify a .desktop file that exists in /usr/share/applications!

ACPI

Hotkeys also do not work properly. Some keys work out of the box but others, like the volume and screen brightness do not. These, of course, are system (and hardware) dependent. I’ve configured my system to properly handle brightness by using acpid(8), adding actions for each key and updating /etc/acpi/acpi_handler.sh to handle the video/brightnessdown and video/brightnessup events:

# /etc/acpi/acpi_handler.sh

case "$1" in
  ...
  video)
    case "$2" in
      brightnessdown) /etc/acpi/actions/FnF5-brightnessdown.sh
         ;;
      brightnessup) /etc/acpi/actions/FnF6-brightnessup.sh
         ;;
      *) logger "ACPI action $2 is not defined"
         ;;
  ...
esac

• FnF6-brightnessdown.sh
• FnF6-brightnessup.sh

Sound

I run pulseaudio system-wide. I enable the pulseaudio service and have my /etc/asound.conf look like the following:

% cat /etc/asound.conf
pcm.default pulse
ctl.default pulse

pcm.pulse {
	type pulse
}

ctl.pulse {
	type pulse
}
% chmod u+x /etc/rc.d/rc.pulseaudio
% /etc/rc.d/rc.pulseaudio start

polkit (PolicyKit) for privileged actions

PolicyKit is used to grant authorization to restricted actions via policies that can match user ID, group or other contextual variables. Per the package description:

PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems.

NetworkManager

I use NetworkManager for easier handling when WiFi is disconnected: it’s much simpler to click stuff than going to a root terminal and running /etc/rc.d/.rc.inet1 restart.

I setup my X session (~/.xinitrc) to run nm-applet which is a tray applet to interact with NM (NetworkManager). Normally you would get a permission denied error when trying to disable an interface or (dis)connect to a wifi network because NM is started by root and the X session is running as a different user, so we need a special policy to grant our user authorization for NM actions.

With the following policy we allow users in the netdev group to manage NM:

// /etc/polkit-1/rules.d/10-org.freedesktop.NetworkManager.rules

polkit.addRule(function(action, subject) {
  if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0
    && subject.isInGroup("netdev")
  ) {
    return polkit.Result.YES;
  }
});

And with the following command my user (geckox) is added to the netdev group:

% usermod -a -G netdev geckox

I assume this policy would also allow to control NM via the CLI command (nmcli) and the terminal UI (nmtui).

Thanks to atelszewski for the LinuxQuestions post!

Suspension

Suspension is acomplished via elogind. For this to work, I added my user to the “power” group and added a polkit rule for power management:

% usermod -a -G power geckox

% cat /etc/polkit-1/rules.d/10-enable-session-power.rules
polkit.addRule(
  function(action, subject) {
    if (
      (action.id == "org.freedesktop.login1.reboot" ||
       action.id == "org.freedesktop.login1.power-off" ||
       ...
       action.id == "org.freedesktop.login1.suspend"
      )
      && subject.isInGroup("power")
    ) {
      return polkit.Result.YES;
    }
  }
)

TL;DR

Remove config.include RSPec::Rails::ViewRendering from your rspec configuration.

Lately I’ve been working on a ruby codebase that runs since at least 2009, which entitles it to the term legacy.

Needless to say, this application was developed as Ruby on Rails was developed so a lot of the RoR framework stuff is implemented in-house since it was used before Rails added first-party support (e.g., enum model attributes). To make my life easier as I get with the day-to-day stuff I follow a TDD workflow because:

1. I don’t know the whole codebase
2. I don’t wanna know the whole codebase
3. I don’t wanna understand the codebase via production errors

This application, thank the developers before me, has an extensive test suite which includes unit tests (model & business logic tests) and integration tests (selenium/cucumber) but, as fortune would have it, I’m temporarily a solo developer and, as I’m not proficient using Selenium (and it really slows down CI runtime), I try to stick to rspec.

Anyway, I had to update an existing data flow to consider an additional parameter that would create an extra database record as a result under arbitrary conditions so, naturally, I looked for the existing tests and found out there were only a subset of tests written on cucumber.

I wrote me a request spec to test in-between classes and save me some time and, lo and behold, my tests passed when run individually but failed when the whole spec/file was run.

After a couple of days ducking around and finding no answer, I turned to Google for Rails 5 now-sunken knowledge and found this StackOverflow entry detailing my situation which, thank the gods, unblocked me with a single line code change after 3 days of scratching my head with frustration.

The error itself was:

ActionController::UnknownFormat:
  MyController#show is missing a template for this request format and variant.

  request.formats: ["text/html"]
  request.variant: []

And the app had this in its rspec configuration:

# spec/rails_helper.rb
RSpec.configure do |config|
  ...

  config.include RSPec::Rails::ViewRendering
end

After removing this view rendering configuration mixin, my request specs passed when running with the whole suite and not just when running individually.

Conclusion

• ChatGPT is NOT ready to solve my day-to-day problems (please generate documentation for my codebase!)
• Sadly, DuckDuckGo hasn’t phased out AdStore Google
• Big ol’ G is still a necessary evil

class MyModel < ApplicationRecord
  has_one_attached :file
end

class DownloadRemoteImageJob
  def perform(my_model)
    ...
    response = http_conn.get(my_model.url) # remote file
    pathname = Pathname.new(my_model.url)
    mime = Rack::Mime.mime_type(pathname.extname) # this is a poor way of getting the mime-type

    # store response in tempfile
    tmpfile = Tempfile.new(pathname.basename.to_s)
    tmpfile.binmode
    tmpfile.write(response.body)
    tmpfile.rewind

    my_model.file.attach(
      io: tmpfile,
      filename: pathname.basename.to_s,
      content_type: mime
    )
    my_model.save!
  ensure
    tmpfile.close! if defined?(tmpfile)
  end
end

Credits

• "File:'Attached to the Village' by Javad Alizadeh.jpg" by Javad Alizadeh is licensed under CC BY-SA 3.0 .
• This closed issue (rails/32711) from a couple of years ago.

A few reasons made this difficult to figure out:

1. Everyone uses Nginx
2. The DFS book covers Nginx but I managed to get an Apache VHost to mimic most of the configuration
3. My Rails app is running as a service, albeit managed and proxied to via a Unix socket, not the common HTTP reverse proxy configuration, i.e., HTTP servers communicating via TCP sockets
4. I couldn’t find anything online for the WebSocket connection upgrade when reverse proxying to a Unix socket! I’m sure I’m not the only one who’s done it but DuckDuckGo didn’t get me anywhere (not to mention AdSearch G00gle)

There are several posts about setting up a reverse proxy and then adding a RewriteRule to change the URL’s scheme to ws instead of http because Apache will override the request’s Connection header and simply not pass the Upgrade header to the origin server.

So, without further ado:

Apache VHost Configuration

# websocket_app.conf

<VirtualHost *:443>
  ServerAdmin admin@websocket-app.com
  ServerName websocket-app.com
  DocumentRoot /srv/websocket_app/rails/app/public
  ProxyRequests off

  <Directory /srv/websocket_app/rails/app/public>
    AllowOverride all
    Require all granted
  </Directory>

  <Location />
    ProxyPass unix:/srv/websocket_app/rails/app/tmp/puma.sock|http://%{HTTP_HOST}/
    ProxyPassReverse unix:/srv/websocket_app/rails/app/tmp/puma.sock|http://%{HTTP_HOST}/
    ProxyPassReverseCookieDomain "websocket-app.com" "websocket-app.com"
    ProxyPassReverseCookiePath  "/"  "/"
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
  </Location>

  # URL where ActionCable is mounted
  <Location /cable>
    ProxyPass unix:/srv/websocket_app/rails/app/tmp/puma.sock|ws://%{HTTP_HOST}/cable # `/cable` at the end here is important
    ProxyPassReverse unix:/srv/websocket_app/rails/app/tmp/puma.sock|ws://%{HTTP_HOST}/cable
    ProxyPassReverseCookieDomain "websocket-app.com" "websocket-app.com"
    ProxyPassReverseCookiePath  "/"  "/"
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
  </Location>
</VirtualHost>

Basically, it boils down to adding a specific proxy to the URL where ActionCable is mounted, /cable by default, and instead of using a RewriteRule we reverse proxy using ws protocol instead of http.

And now it pays off that I picked ext2 (I don’t need extensive logging nor datacenter capabilities) as my file system format, since cloning and growing the partition is a pretty straightforward operation. What needs to be done is basically:

TL;DR

1. Copy/clone the old disk to the new disk
2. Run e2fsck(8) on the ext2/ext3/ext4 partition in the new disk (use the -f option to be safe)
3. Rewrite/modify the partition table in the new disk; can be done with fdisk(8). DANGER: you need to pay close attention to the “Start block”, because the ext2 metadata is located there. If you overwrite it or start somewhere else, the files location will be lost and your data might be lost forever.
4. Run resize2fs(8) on the ext2/ext3/ext4 partition in the new disk

Copy/Clone the Disk

This is done very easily with dd(1), we just specify the input file the old disk (/dev/sdb) and the new one (/dev/sdc) as output file, I also pass the block size parameter to speed up the process:

# dd if=/dev/sdb of=/dev/sdc bs=4K

The command doesn’t print anything when things are going well, but you can print the progress to the tty executing dd by sending the USR1 signal to the process (see dd(1)):

# kill -s USR1 $(pidof dd)

Run fdisk on the New Disk

Most linux distributions include an interactive implementation of fdisk(8) which is what I used and cannot write about the scriptable implementation. What you want to do is:

# fdisk /dev/sdc

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p

Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk model: ADATA SU630
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbe4e4347

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1          2048   2099199   2097152   111G 83 Linux

Command (m for help):

1. Print the existing partition table by issuing the p (print) command and check the start block
2. Delete the existing partition (DO NOT WRITE CHANGES YET)
3. Create a new partition with the new desired size. Make sure you use the same “Start block” used by the old/existing partition (now deleted) and the same type
4. Write the new configuration to disk (this is what could destroy your data)

Run e2fsck on the Ext2/Ext3/Ext4 Partition

This is to check data integrity and, I think, to re-order files to continuous blocks for better performance. Let’s assume my new partitition is located on /dev/sdc1:

# e2fsck -f /dev/sdc1

Run resize2fs on the Ext2/Ext3/Ext4 Partition

This is the command that will actually grow the file system size to match the partition size, which we increased with fdisk previously:

# resize2fs /dev/sdc1

And that’s it! You can mount the partition and check the file system size with df to verify it worked. If the size is not updated, you may have not run e2fsck before resize2fs.