Skip to main content

Set Firefox to Default Browser in xdg Settings

If you use firefox nightly and chromium you've likely ran into the issue where some apps launch chromium as the default browser for URLs. This is ultimately due to firefox nightly not having a true installer which would create the firefox.desktop file that xdg-settings uses to set/determine the browser to open on xdg-open events.

To verify the current settings you can use: xdg-settings get default-web-browser which will likely return chromium.desktop.

To change this, you will need to create a firefox.desktop file and use the xdg-settings command:

  • in a terminal, clear BROWSER: export BROWSER=""
    • just to make sure it is not set which can cause other issues
  • create a firefox.desktop file in /usr/share/applications/ with the following content:
[Desktop Entry]
Name=Firefox Browser
GenericName=Web Browser
Comment=Access the Internet
Exec=/PATH_TO_FIREFOX_BIN/firefox %U

[Desktop Action new-window]
Name=New Window

[Desktop Action new-private-window]
Name=New Incognito Window
Exec=/PATH_TO_FIREFOX_BIN/firefox --incognito

NOTE: you will need to change /PATH_TO_FIREFOX_BIN/ to the path to your firefox binary.

  • change xdg to use firefox: xdg-settings set default-web-browser firefox.desktop
  • check xdg setting: xdg-settings get default-web-browser
  • test the change: xdg-open ""
    • this should open the URL in firefox

Also note you should check the default application (update-alternatives) gnome and default browsers settings:

  • default: update-alternatives --config x-www-browser
  • gnome: update-alternatives --config gnome-www-browser
  • kde: check System Settings > Applications > Default Applications > Web Browser

Graylog Syslog Grok Extractor

I have several apps in my k8s cluster which run behind a lighttpd web server where I wanted the access logs to be sent to graylog. The setup of lighttpd is relatively basic:

# /etc/lighttpd/lighttpd.conf

var.basedir  = "/var/www/localhost"
var.logdir   = "/var/log/lighttpd"
var.statedir = "/var/lib/lighttpd"

server.modules = (

include "mime-types.conf"

server.username      = "lighttpd"
server.groupname     = "lighttpd"

server.port          = 80
server.document-root = var.basedir + "/htdocs"      = "/run/"

server.indexfiles    = ("index.html")

server.errorlog-use-syslog = "enable"
accesslog.use-syslog       = "enable"

Next we need to tell rsyslog to send logs to graylog:

# /etc/rsyslog.d/dxc-graylog.conf

*.* @graylog-udp.graylog.svc.cluster.local:5410;RSYSLOG_SyslogProtocol23Format

Note that you will need to change the URL and port to match the graylog syslog URL and port you have. Also notice that we are using RSYSLOG_SyslogProtocol23Format format. This results in a log message with a message value similar to the following in graylog: - [28/Oct/2020:06:28:06 -0400] "GET / HTTP/1.1" 200 6341 "-" "kube-probe/1.16"

This should all work; however, we would like to have the message parsed - enter the grok pattern! In Graylog, go to your Syslog Input and click Manage Extractors. Add an Extractor with the following info:

  • select extractor type for the message field with a Grok Pattern
  • enter grok pattern:
%{SYSLOGHOST:host} %{SYSLOGHOST:referer} - \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})" %{NUMBER:response} (?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:agent}
  • Condition: Always try to extract
  • Extraction strategy: Copy
  • Extractor title: RFC5424
  • click the Create extractor

That should be all that is needed, go to your syslog stream and check (make sure you pick a message that came in after you created the extractor) to ensure the new fields are being created!

Minimalistic Coding Standard

Minimalistic applications require sound design and development which produce applications that are easier to run, use, support, and maintain over the life of the application.

The Minimalistic Coding Standard (MCS) is a simple coding (design, development, deployment) philosophy which emphasizes minimalism in all aspects of coding.

Core concepts of MCS:

  • simple over complex
  • one good way over multiple ways
  • simply secure over not

KIM = Keep it minimal

Setup SAR on Alpine Linux

There are several good articles on setting up SAR for debian (sar on ubuntu/debian) and redhat systems but I could find few on Alpine (perhaps because it is simple).

In any event, here's my process for setting up sar to run periodically via cron to track server stats.


Install with: apk add sysstat


Not a lot of setup is required, you may want to review the /etc/sysconfig/sysstat file for options.

Running Via cron

Create a cron task as you like to kick off sar periodically, the following will run sar every 2 minutes.

# Run sar to gather stats
*/2 * * * *   /usr/lib/sa/sa1 1 1
# Additional run at 23:59 to rotate the statistics file
59 23 * * *   /usr/lib/sa/sa1 60 2


Alpine's sysstats logs are in /var/log/sa

spw - simple, light, cli password manager

spw is a python application that stores and retrieves passwords in a secure maner. spw is designed to be quick, light on resources/dependencies, and command line/script driven.

Passwords are stored in an encrypted format using PKCS1_OAEP encryption. This means you use a public and private key to encrypt and decrypt items stored within the store. This is a secure method of password storage and there is virtually no chance someone (including yourself) can view decrypted passwords without the private key.

spw is intended to provide a secure mechanism to store (and more importantly retrieve) passwords. spw's command-line interface allows easy integration into openbox's keyboard shortcut functionality (or similar tools). spw provides an easy mechanism for copying a password to the clipboard (e.g. C+A+j will copy the gmail junk account's password to your clipboard). - spw - about

I have used spw daily for several years, the password generator is extremely useful/quick to generate passwords!

Use sendmail over mail

mail (from mailutils) is a common sysadmin tool for sending system mail, however, it brings in unneeded/undesired packages (e.g. mysql/mariadb tools). sendmail is much lighter and can usually get the job done.

Typical mail Scenario

The following cron entry runs deborphan every Monday at 14:33, emailing the results to the drad user.

33 14 * * Mon   deborphan --guess-all | mail -s "Weekly deborphan Report" drad

Using sendmail Instead

sendmail does not have a -s (subject parameter). You need to preface your message with "Subject: {your subject}" followed by a new line and then the body such as follows:

33 14 * * Mon   ( echo "Subject: Weekly deborphan Report"; echo; deborphan --guess-all ) | /usr/sbin/sendmail drad

The sendmail route is a little more verbose but gets the job done and now you do not need mailutils!


mail (mailutils) is a common and useful mail tool but depends on several packages which may not be desirable. You can fully replace mail with sendmail to avoid the dependencies and yet provide the same system mail functionality.

System Resource Monitoring

We often need to monitor a system during load testing to determine how heavily the system is being taxed (i.e. determining the proper AWS instance type) and to determine what is being hit (memory, cpu, etc.). Often the target system has monitoring features (e.g. Prometheus or other); however, there are times when we do not have a monitoring tool and, more often, times when we don't want the hit of the monitoring tool itself impacting the load test.

The need is typically to spin up a server, add the application and hit the server with a load test (, jmeter, ab, etc.). Adding node_exporter to an instance takes a few seconds but is useless if you do not have Prometheus setup or available to the instance. This typically leads to running the load test and periodically checking metrics of the resource as the test runs - not an optimal solution.

Our quest to automate this task had two key requirements:

  • easy to install (low dependencies)
  • small footprint (if the monitor itself takes 50% of memory/cpu its not real helpful)


Our first attempt to address this issue is basic and meets the requirement. sarmore uses SAR which is already on most Linux instances and may already be running.

sarmore is very basic, it simply starts 3 SAR instances (one each to monitor cpu, memory, and load) which run for a given amount of time and log to the LOG_DIR specified.

Quick Summary: no install, may already be running

  • typically no install
  • may already be running
  • output format is not the best to work with


Our second attempt to address this issue was a python-based solution given python is typically on most linux instances. pymore runs in a loop, polling system resources at a given interval and stores the results to log files.

Quick Summary: clone repo and run (no dependencies)

  • clone repo, no app dependencies
  • more detailed, customizable metrics can be captured
  • requires git/cloning
  • memory usage is relatively high


Our third attempt is a rust app which ships/runs as a simple binary. rumore runs much as pymore does, in a loop and writes to log files.

Quick Summary: put binary on server and run

  • single binary (no dependencies)
  • low memory usage
  • more detailed, customizable metrics can be captured
  • requires putting binary on server


All three solutions have benefits/drawbacks which should be considered for each application. We typically use rumore where possible due to its light resource usage and ease of install.

Resource Utilization

Resource utilization of the resource monitors themselves is as follows:

Application Bin Size VIRT RES SHR CPU%
sarmore n/a 16,140 2,292 2,076 0.0
pymore n/a 19,992 11,628 6,028 0.0
rumore 1.8M 2,928 888 768 0.0

Note that the above stats for sarmore are for running it directly, if you already have sar running you would not need to run sarmore but rather simply query sar.


We welcome feedback and enhancements to any of the three applications, keeping in mind the two key requirements. Feel free to fork one (or all) and submit a PR. We would also be interested if you are willing to write similar logic in another language (such as Java, C/C++, etc.) to compare against the sarmore, pymore, and rumore.