HowTos Journal Linux

Replace Snap Firefox with .deb on Ubuntu 22.04

Ubuntu 22.04 LTS (Jammy Jellyfish) ships Firefox as a snap, but some people (like me) may prefer installing it from .deb packages to retain control over upgrades or to keep extensions working.

Luckily there is still a PPA serving firefox (and thunderbird) debs at maintained by the Mozilla Team. (Thank you! 🙏)

Block Ubuntu’s Snap Version of Firefox

Block the Ubuntu archive’s version that just pulls in the snap by pinning it

$ cat /etc/apt/preferences.d/firefox-no-snap 
Package: firefox*
Pin: release o=Ubuntu*
Pin-Priority: -1

Remove Firefox Snap

Remove the transitional package and the Firefox snap itself

sudo apt purge firefox
sudo snap remove firefox

Install Firefox DEB

Install the DEB packaged Firefox from the Mozilla PPA

sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update
sudo apt install firefox

⚠️ Optional: Enable Unattended Upgrades

Since the package comes from a PPA unattended-upgrades will not upgrade it automatically, unless you enable this origin:

echo 'Unattended-Upgrade::Allowed-Origins:: "LP-PPA-mozillateam:${distro_codename}";' | sudo tee /etc/apt/apt.conf.d/51unattended-upgrades-firefox
HowTos Journal Linux

USB Boot Ubuntu 20.4.3 LTS on Raspberry Pi 4 FROM SSD


I have been using my raspberry pi 4 to monitor my network and my Synology NAS. So far, I’ve been using a SanDisk MicroSD card for storing all the data which died (remember: MicroSD cards have a limited number of writes)

After doing some research I learned that the Raspberry Pi 4 gained direct boot capabilities from USB Mass Storage (aka SSDs) with a bootloader (eeprom) update in 2020.

I struggled for about 2 nights to make it work despite following various how-tos/tutorials. The method outlined here is what worked for me as of 2021-10-23. It could change in the future. With new updates to the ubuntu image those steps might not be necessary anymore.

Preparation – Upgrade bootloader

The easiest way to upgrade the bootloader on the raspberry pi is to use the raspi-config tool built into the raspian os image. Therefore first write the Raspian OS image to an MicroSD Card to make use of raspi-config. Afterwards, write the Ubuntu Image to the MicroSD card You can use the raspberry image writer. Flash the image to a MicroSD card

Raspberry Image Writer: Choose Raspberry PI OS Lite (32-bit)

Boot the raspberry pi with raspian os, login with the default credentials and run

sudo raspi-config

raspi-config main screen

Choose Advanced Options –> Bootloader Version –> Latest

Select No when asked to restore Default Settings

Exit and Select Yes when asked to reboot

On Reboot the bootloader should be upgraded.

Check in the Terminal that the upgrade was applied

pi@raspberrypi:~ $ sudo rpi-eeprom-update
BOOTLOADER: up to date
   CURRENT: Tue Jul  6 10:44:53 UTC 2021 (1625568293)
    LATEST: Tue Jul  6 10:44:53 UTC 2021 (1625568293)
   RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable)
            Use raspi-config to change the release.

  VL805_FW: Dedicated VL805 EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

Use raspi-config to set the boot-order to USB-Boot by default

Choose: 6 Advanced Options

raspi-config, go to Advanced Options

Next choose: A6: Boot Order

Choose A6 Boot Order to set boot priority

Choose B2 USB Boot

B2 USB Boot

Check in the in the terminal that bootloader order has been modified. Confirm BOOT_ORDER statement is there.

pi@raspberrypi:~ $ sudo vcgencmd bootloader_config

pi@raspberrypi:~ $ 

Write Ubuntu to MicroSD Card


Clone MicroSD card to USB-SSD

To Clone the content of the MicroSD card to the USB-SSD I used rpi-clone script

Install rpi-clone

$ git clone 
$ cd rpi-clone
$ sudo cp rpi-clone rpi-clone-setup /usr/local/sbin

Check with fdisk -l or lsblk SDD device name (e.g. sda or sdb etc.)

Clone the content of the MicroSD card to USB-SSD

pi@rpi0: $ sudo rpi-clone sdb

Booted disk: mmcblk0 16.0GB                Destination disk: sdb 8.0GB
Part      Size    FS     Label           Part   Size    FS     Label
1 /boot   58.4MB  fat16  --              1       8.0GB  fat32  --
2 root    16.0GB  ext4   SD-RPI-s1                               
== Initialize: IMAGE mmcblk0 partition table to sdb - FS types mismatch ==
1 /boot     (22.5MB used)    : IMAGE     to sdb1  FSCK
2 root      (6.0GB used)     : RESIZE(8.0GB) MKFS SYNC to sdb2
Run setup script       : no
Verbose mode           : no
** WARNING **          : All destination disk sdb data will be overwritten!
                       : The partition structure will be imaged from mmcblk0.

Initialize and clone to the destination disk sdb?  (yes/no): yes
Optional destination rootfs /dev/sdb2 label (16 chars max): SD-RPI-8a

Update config.txt to enable booting from USB SSD

Mount the system-boot partition on the SSD drive in order to change config.txt

sudo mkdir /mnt/ssdboot
sudo mount /dev/sdb1 /mnt/ssdboot
cd /mnt/ssdboot

Add kernel=vmlinux & initramfs initrd.img followkernel in the [all] section. Leave the rest the way it was before.

initramfs initrd.img followkernel

Boot From USB-SSD

Shutdown the Raspberry PI, unplug the MicroSD Card and plug-in the power again to boot from USB SSD.

If it can’t find the bootloader the raspberry pi will default to PXE boot. In case the raspberry pi is unable to boot from the USB SSD try another USB – Port (e.g. USB 2 instead of 3 etc.)

A list of compatible / tested SSDs can be found here.


HowTos Journal Linux

Upgrading Debian 8 ‘Jessie’ to Debian 9 ‘Stretch’


Debian 9 Stretch was released as the latest stable version of the Linux Distribution: Debian. While it’s always possible to install Debian 9 fresh from scratch, it’s also possible to perform an in-place upgrade from Debian 8. The following post describes the necessary steps to do so.

For a incredibly thorough documentation of the process, I suggest you also read through the official release notes.


  • Upgrading to Debian 9 Stretch is only supported from Debian 8 Jessie. If you are running a version older than 8, you must first upgrade to 8 before working through this process.
  • The upgrade involves a kernel update, so a reboot will be required toward the end of the process.
  • It is strongly recommended that you have a full system backup or backup of any important data before proceeding with the upgrade, ensure that you have a plan to roll back. In the case of a virtual machine, take a snapshot before starting.

Performing the upgrade to Debian 9 Stretch

Before proceeding with the upgrade, please read through the list of issues to be aware of when upgrading to Stretch.

  1. It is recommended that you have your Debian 8 Jessie installation completely up to date before starting, to do this run “apt-get update” followed by “apt-get upgrade” and install available updates.
root@debian8:~# apt-get update
root@debian8:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

In this case all updates have been applied already, so it’s fine to proceed.

Edit the /etc/apt/sources.list file, my file is shown below. As you can see all of the lines are currently specifying “jessie”. Note that your mirror sources will likely be different which is fine.

deb jessie main
deb-src jessie main

deb jessie/updates main contrib
deb-src jessie/updates main contrib

# jessie-updates, previously known as 'volatile'
deb jessie-updates main contrib
deb-src jessie-updates main contrib

Change the instances of “jessie” to “stretch”, you can either do this manually, or automatically with the below sed command.

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

You can either use “stretch” or “stable”, as Debian 9 Stretch is now the current stable version as of writing. However note that if you use stable instead of the specific release name, in future when Debian 10 is released that will be the stable version so you may upgrade to that unintentionally.

The recommended way to upgrade Debian is with the ‘apt-get’ command. First update the list of available packages with the below command, as we’ve just updated the sources.list file.

apt-get update

Use “apt list –upgradable” command to quickly see what will be installed, updated, and removed during the upgrade process without affecting the system.

apt list --upgradable

Sample Output:

unattended-upgrades/stable 0.93.1+nmu1 all [upgradable from:]
util-linux/stable 2.29.2-1 amd64 [upgradable from: 2.25.2-6]
uuid-runtime/stable 2.29.2-1 amd64 [upgradable from: 2.25.2-6]
vim/stable 2:8.0.0197-4 amd64 [upgradable from: 2:7.4.488-7+deb8u3]
vim-common/stable 2:8.0.0197-4 amd64 [upgradable from: 2:7.4.488-7+deb8u3]
vim-runtime/stable 2:8.0.0197-4 all [upgradable from: 2:7.4.488-7+deb8u3]
vim-tiny/stable 2:8.0.0197-4 amd64 [upgradable from: 2:7.4.488-7+deb8u3]

Now that the list of available packages has been updated from the mirror, run the below command to perform a minimal upgrade.

apt-get upgrade

This is known as a minimal system upgrade as it only upgrades packages that can be upgraded without needing any other packages to be removed or installed, so it’s a safe place to start. This upgraded 932 packages requiring 412MB on my system.

Now you’re ready to do the complete system upgrade, this will upgrade to the latest available version for all packages installed.

apt-get dist-upgrade

Ensure that you have enough free disk space to complete the operation, in my case it notes that afterwards 1,048MB of additional disk space will be used with 639 package upgrades and 479 newly installed packages.

During the distribution upgrade, services installed on your system needs to be restarted after up gradation of each service packages (ex. Apache, NTP) which may cause you the service interruptions. You can choose to restart automatically during upgrade or manually after the upgrade. Here, I opted to do “an automatic restart of services during the OS upgrade“.

Verify upgrade:

Reboot your machine after the distribution upgrade.


Verify the current version of Debian operating system.

lsb_release -a

Distributor ID: Debian
Description: Debian GNU/Linux 9.0 (stretch)
Release: 9.0
Codename: stretch
HowTos Journal Linux

Users susceptible to man-in-the-middle attacks due to corporate https inspection

A large number of companies use “security” products to inspect HTTPS traffic for detecting malware and prevent other types of attacks. However, they might inadvertently make their user’s more susceptible to man-in-the-middle attacks by  decrypting and re-encrypting HTTPS connections.

The U.S. Computer Emergency Readiness Team (US-CERT) warns in an advisory that HTTPS inspection products don’t mirror the security attributes of the original HTTPS connections between the client and the server (Mirror: HTTPS Interception Weakens TLS Security | US-CERT).

HTTPS inspection is deployed in companies for checking the encrypted traffic coming from an HTTPS website to make sure it does not contain any malware or any other type of attacks. It basically performs a decryption and re-encryption of the client’s connection to an HTTPS server. The “security” products (proxy, web-gateway, firewall etc.) establish the connection on the client’s behalf by first decrypting the client’s HTTPS connection and re-encrypting the traffic sent to the HTTPS server. The client is served with a different, locally generated certificate by the security product which essentially perform a man-in-the-middle attack.

In some enterprise environments, an HTTPS connection may even be intercepted and re-encrypted multiple times. For example, at the network perimeter by a security gateway product and later, on the endpoint by a client’s antivirus program which needs to inspect the traffic for malware.

The problem revolves around the fact that the client’s browser no longer validates the real certificate issued by the server because its replaced with a locally generated certificate from the security product. In return, the task of validating the certificate now falls to the intercepting proxy.

According to the published advisory, those security products are evidently pretty bad at validating server certificates. An investigation conducted by researches from Google, Mozilla, Cloudfare, and multiple Universities states that the intercepted connections use weaker cryptographic algorithms (Source: interception-ndss17). The security products even advertise support for known-broken encryption ciphers that would allow an active man-in-the-middle attack by intercepting and downgrading a connection in order to decrypt it.

The analysis by the researches found that at least 32 percent of connections to e-comerce sites and 54 percent of Cloudflare HTTPS connections, which were intercepted, became less secure than they would have been if the user had connected directly to the server.

Browser makers had a long time to properly unterstand the quirks of TLS connections and certificate validation. Therefore, there is no better client-side implementation of TLS, the protocol used for encrypting HTTPS connection, than the one found in modern browsers.
In comparison, security product vendors use outdated, customised TLS libraries where they even back-port new protocol features. Re-implementing those features found in newer libraries makes them susceptible to serious vulnerabilities.

Furthermore, the US-CERT points out another widespread problem that many products intercepting HTTPS don’t properly validate the certificate chain presented by servers. Certificate-chain verification errors are infrequently forwarded to the client, leading the client to believe that operations were performed with the correct server.

The BadSSL website allows organisations and even employees to check if their HTTPS inspection products improperly validate certificates or allow for insecure ciphers. The client test from Qualys SSL Labs also provides checks for some known TLS vulnerabitiles and weakenesses.