Create a directory to share on the host (bind mounts should be located in /mnt/bindmounts):

mkdir -p /mnt/bindmounts/shared

Configure the bind mount on the container (for the container with ID 100): edit /etc/pve/lxc/100.conf (on the host) and add:

mp0: /mnt/bindmounts/shared,mp=/shared

Restart the container for the changes to take effect:

pct restart 100

The host directory /mnt/bindmounts/shared will be mounted as /shared in the LXC.

Reference: Proxmox Documentation - Linux Container - Bind Mount Points

Update the file /etc/netplan/50-cloud-init.yaml from

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: yes

to

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: no
      addresses: [192.168.x.x/24]
      routes:
        - to: default
          via: 192.168.x.1

Then restart the network interface:

ifdown ens18
ifup ens18

In the following 15-ish years, I’ve had (I almost typed “owned”, but the term would have been wrong) several Facebook and Twitter accounts, that I opened and closed a few times, tried Snapchat for a while but did not enjoy it, and lastly joined Instagram with, again, two separate accounts for specific confidentiality settings.

From 2015 to 2022, I started enjoying less and less Facebook, because of their privacy issues, and Twitter, because of the increasing toxicity on the platform. In 2020, I closed my 2 Facebook accounts. By January 2023, I had closed my 2 Twitter accounts. But I still had my Instagram account (opened in 2012), where I had a nice contact bubble, didn’t read too many comments on other posts, and led a relatively quiet online life.

Leaving Facebook was easy. In the last few years of my accounts, my activity decreased dramatically. I shared less and less, until it became obvious that I didn’t need an account anymore (I use the term “need” consciously). I recently re-opened an account after the birth of my daughter, because some services (child care, school…) only communicate on this platform. But I’m using this account as “read-only”, never posting anything on it.

Leaving Twitter was a mixed feeling. I had many good years on it, met really nice people. But I also got caught in the toxic “discussions” (if you want to call them that), hateful comments… Until I couldn’t take it anymore, and was only getting stress from the platform. At that time, a Mastodon instace was opened by a buddy, and some of us joined together.

Today I’m at a new crossroads. In the last few months, it has become obvious that Instagram was on a downward slope. The latest declarations of Mark Zuckerberg have shined a light of what should have been obvious (and probably was, for a lot of people), which is that, in the end, this network is not different from the others. The toxicity is there, always more uninhibited. Journalists, artists, are targeted for their opinions. Right-wing extremism is growing everyday. And the latest decision to basically remove moderation and fact-checking on the Meta networks is probably the nail in the coffin of whatever good remained.

In January of 2025, I created a Pixelfed account. Pixelfed, like Mastodon, is a decentralized social network. This means that you have to select an “instance” where you create your account. It can be linked to a location (I’ve created my account on pixelfed.fr, which is the main French instance), or a hobby (my Mastodon account is on masto.bike, which is, you guessed it, for cycling enthusiasts). An instance is managed by 1 or more admins, has some moderators who make a wonderful job at keeping the toxicity at bay, and regroups mostly like-minded people. Of course this means that it creates a new social bubble, but do we really want to be exposed to everybody and everything? I don’t. That’s why I’ve come to the decision to post first on Pixelfed, and maybe later on Instagram. But in the end, I think I will start using Instagram in a “read-only” mode, and at some point just stop using it altogether. This would be a major change, because Pixelfed is still a “niche” network, doesn’t have many users or content. It would mean losing a lot of social link.

If you decide to take the step, or already have, you can find me here:

• on Mastodon: @remygardette@masto.bike
• on Pixelfed: @remygardette@pixelfed.fr

When using multiple GitLab accounts (e.g. private account and work account) on the same computer, you can’t use the same SSH key for both. This can become problematic when Git has to decide which key to use to communicate with the distant repository.

There are 3 main solutions to this problem. You can specify the SSH key to use:

• based on the distant repository host,
• based on the project path,
• or locally for a specific repository.

The following examples assume that you have the 2 SSH keys ~/.ssh/id_rsa_perso and ~/.ssh/id_rsa_work.

Host-based configuration

The first solution requires you to change the URL of the repository when cloning it.

For example, when cloning a work project located at https://gitlab.com/my-org/my-project, the command would be:

git clone git@work-gitlab.com:my-org/my-project.git

and for a personal project located at https://gitlab.com/me/my-project:

git clone git@home-gitlab.com:me/my-project.git

Then, in the SSH configuration file (~/.ssh/config):

# Personal account:
Host home-gitlab.com
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_rsa_perso
  PreferredAuthentications publickey
  PasswordAuthentication no
  IdentitiesOnly yes

# Work account:
Host work-gitlab.com
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_rsa_work
  PreferredAuthentications publickey
  PasswordAuthentication no
  IdentitiesOnly yes

This works fine, but it requires you to always remember to modify the project URL when cloning it.

Path-based configuration

Since Git 2.13, a conditional include is available in the local Git configuration. This means that you can include a specific configuration file when your current path matches a specific filter.

For example, if your work projects are located in ~/work/sources and your personal project in ~/perso/sources, you can create a Git work-related configuration file ~/.gitconfig-work:

[user]
    email = "your.email@work.com"
[core]
    sshCommand = "ssh -i ~/.ssh/id_rsa_work"

and a personal configuration file ~/.gitconfig-perso:

[user]
    email = "your.email@home.com"
[core]
    sshCommand = "ssh -i ~/.ssh/id_rsa_perso"

Now you only need to include the correct configuration file based on your path, by modifying the global ~/.gitconfig file and including:

[includeIf "gitdir:~/work/sources/"]
    path = .gitconfig-work
[includeIf "gitdir:~/perso/sources/"]
    path = .gitconfig-perso

Repository-based configuration

I recently found a third solution, to specify the key to use for a specific repository, by Richard Smith.

This solution sets the core.sshCommand property:

git config --local core.sshCommand "/usr/bin/ssh -i /home/me/.ssh/id_rsa_foo"

You can’t use this command when cloning a remote repository (since you don’t have a local repository). The solution was proposed by drewbie18 :

git clone -c core.sshCommand="/usr/bin/ssh -i /home/me/.ssh/id_rsa_foo" git@github.com:me/repo.git

Conclusion

I personally find the path-based solution much easier to use, since you only need to change your configuration once, and it automatically works in the future (as long as you use the correct folders for your projects). The host-based solution requires you to always be careful to change the URL when cloning a repository. But it can be useful if you don’t want to group your projects in specific local directories.

The process was quite annoying, which is why I decided to set up a CI/CD (Continuous Integration and Delivery) pipeline, using GitLabCI.

Pipeline

The CI/CD pipeline I’ve implemented is the following:

The pipeline is defined in a file .gitlab-ci.yml at the root of the project:

image: ruby:2.5

cache:
  key: "jekyll"
  paths:
    - vendor

variables:
  JEKYLL_ENV: production
  LC_ALL: C.UTF-8
  NOKOGIRI_USE_SYSTEM_LIBRARIES: "true"

before_script:
- bundle install

test:
  stage: test
  script:
  - bundle exec jekyll build -d ./public
  - bundle exec htmlproofer ./public --only-4xx --check-favicon --check-html --assume-extension
  artifacts:
    paths:
    - public

deploy:
  stage: deploy
  before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_PRIVATE_KEY" | base64 -d)
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  - echo "$SSH_HOST_KEY" > ~/.ssh/known_hosts
  - chmod 644 ~/.ssh/known_hosts
  - which rsync || ( apt-get update -y && apt-get install rsync -y )
  script:
  - ssh -p$SSH_PORT $SSH_SRV "mkdir -p /tmp/jekyll"
  - ssh -p$SSH_PORT $SSH_SRV "rm -rf /tmp/jekyll_old"
  - ssh -p$SSH_PORT $SSH_SRV "mv /tmp/jekyll /tmp/jekyll_old"
  - rsync -rav -e "ssh -p $SSH_PORT" --exclude='.git/' --exclude='.gitlab-ci.yml' --delete-excluded ./public $SSH_SRV:/tmp/jekyll
  - ssh -p$SSH_PORT $SSH_SRV "sh /home/gitlabci/rsync-jekyll.sh"
  only:
  - master

It consists of 2 steps: test and deploy.

The test step builds the Jekyll project, then runs HTMLProofer on the generated files. This step will check and validate the HTML output.

The deploy step transfers the generated files to my home gateway, then runs a script (located on the gateway) to transfer those files to my web server (the web server is not exposed outside of my network).

SSH Configuration

The gateway is accessed via SSH. To do that, I’ve created a specific SSH key only used by GitLab CI.

To generate a new SSH key:

ssh-keygen -o -t rsa -b 4096 -C "gitlabci"

The public key needs to be added to the authorized keys before it can be used:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Configuration

The pipeline contains variables to improve the security:

• SSH_PRIVATE_KEY: a base-64 representation of the SSH private key used to access my gateway. The value is retrieved by running this command on the gateway:
  cat id_rsa > base64 -w0
• SSH_HOST_KEY: the RSA key of the gateway. Retrieved by running on the gateway:
  ssh-keyscan -t rsa server_ip
• SSH_SRV: the SSH connection information, like my_user@my_server
• SSH_PORT: the SSH port on the gateway

Usage

I can now follow the following process to publish changes to my website:

• if needed, clone the GitHub repo on my computer
• make the changes (create a new blog post,…)
• test the changes locally (the Docker compose file allows me to build and serve the website on my computer)
• commit and push the changes
  • if I push to a branch other than master, only the test step is executed
  • if I push to master, the whole pipeline is executed, so my site is built, tested and automatically deployed.

The requests are proxied by an NGINX reverse proxy, running in a Docker container on the gateway. It redirects the HTTP requests based on the host (eg. remyg.ovh runs on rpi1 when rss.remyg.ovh runs on rpi2).

NGINX Configuration

The main NGINX conf file (nginx.conf) looks like this:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/sites-enabled/*.*;
}

The only difference with the base conf file (from the default NGINX Docker image) is the last line:

include /etc/nginx/conf.d/*.conf;

is replaced by

include /etc/nginx/sites-enabled/*.*;

It ignores the default configuration (/etc/nginx/conf.d/default.conf) and uses the proxy configuration files that I defined.

Hosts Configuration

Each host has its own configuration file:

• for remyg.ovh, running on rpi1 (with a local IP 192.168.0.10, and port 8080):

server {
    listen 80;
    server_name remyg.ovh;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    location / {
        proxy_pass       http://192.168.0.10:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect   off;
    }
}

• for rss.remyg.ovh, running on rpi2 (with a local IP 192.168.0.11, and port 8081):

server {
    listen 80;
    server_name rss.remyg.ovh;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    location / {
        proxy_pass       http://192.168.0.11:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect   off;
    }
}

These files indicate that a request incoming to rss.remyg.ovh:80 (server_name and listen) will be redirected to 192.168.0.11:8081 (proxy_pass).

That’s all the configuration you need to serve websites on HTTP.

Running in Container

To run the reverse proxy in a Docker container, the file tree looks like this:

nginx-reverse-proxy
  -> conf
    -> nginx.conf
  -> sites
    -> remyg.ovh
       rss.remyg.ovh

With this structure, the command launching the container will be:

docker run --name mynginx-proxy \
  -v /home/pi/nginx-reverse-proxy/sites:/etc/nginx/sites-enabled:ro \
  -v /home/pi/nginx-reverse-proxy/conf/nginx.conf:/etc/nginx/nginx.conf:ro \
  -p 80:80 -d nginx:alpine

HTTPS

To enable HTTPS on the different sites, I’m using Let’s Encrypt, and their utility app Certbot.

I’m starting by installing the certbot package:

sudo apt install certbot

When generating a certificate, Certbot will need to validate that it can access a specific file that it generates, pointing to the URL http://your-host/.well-known/acme-challenge/{token}. To do that, start by creating and mounting a new volume on the reverse proxy container:

docker run --name mynginx-proxy \
        -v /home/pi/nginx-reverse-proxy/sites:/etc/nginx/sites-enabled:ro \
        -v /home/pi/nginx-reverse-proxy/conf/nginx.conf:/etc/nginx/nginx.conf:ro \
        -v /home/pi/letsencrypt_www:/var/www/letsencrypt \
        -p 80:80 -p 443:443 -d nginx:alpine

Then specify in the sites proxy configuration that this volume is used when pointing to /.well-known/acme-challenge/:

server {
    listen 80;
    server_name remyg.ovh;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }

    location / {
        proxy_pass       http://192.168.0.10:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect   off;
    }
}

And reload your NGINX config:

docker exec -it mynginx-proxy nginx -s reload

Now you can generate the certificate(s) :

sudo certbot certonly --authenticator webroot -w /home/pi/letsencrypt_www -d remyg.ovh -d rss.remyg.ovh

This will generate the ACME challenge files in /home/pi/letsencrypt_www, and validate the challenge. It will also generate the certificates, in /etc/letsencrypt/certs/live/remyg.ovh/ and /etc/letsencrypt/certs/live/rss.remyg.ovh/.

The last step is to use the new certificates, and only allow HTTPS requests.

Start by mounting a new volume, containing the certificates:

docker run --name mynginx-proxy \
        -v /home/pi/nginx-reverse-proxy/sites:/etc/nginx/sites-enabled:ro \
        -v /home/pi/nginx-reverse-proxy/conf/nginx.conf:/etc/nginx/nginx.conf:ro \
        -v /etc/letsencrypt:/etc/nginx/certs \
        -v /home/pi/letsencrypt_www:/var/www/letsencrypt \
        -p 80:80 -p 443:443 -d nginx:alpine

Then update your proxy configuration:

server {
    listen 80;
    server_name remyg.ovh;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name remyg.ovh;

    ssl_certificate certs/live/remyg.ovh/fullchain.pem;
    ssl_certificate_key certs/live/remyg.ovh/privkey.pem;

    location / {
        proxy_pass       http://192.168.0.10:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect   off;
    }
}

Reload the NGINX configuration, and you’re all set!

Items

This project is very similar to my previous one, except it doesn’t use any display :

• ESP8266 development board
• DS18B20 temperature sensors
• 4.7K resistor
• breadboard
• jumper wires

Wiring

Just follow the wiring instructions from my previous project, without the LCD of course.

Code

For this project, I’m using PlatformIO on VSCode, instead of the Arduino IDE. PlatformIO has a much nicer interface, and offers a lot of tools and improvements over the Arduino IDE.

One of the advantages of PlatformIO is that you can put configuration variables in a separate file platformio.ini, and directly use these variables in your code. For example, I put my WiFi and MQTT configuration as externalized variables :

build_flags = '-DWIFI_SSID="my_wifi_ssid"' '-DWIFI_PASS="my_wifi_password"' '-DMQTT_SERVER="my_mqtt_server_ip"' '-DMQTT_TOPIC="my_mqtt_server_topic"' '-DDEVICE_NAME="my_device_name"'

The data sent to the MQTT server is a JSON object, containing the device IP, its name, and the temperature value:

{
  "d": "device_name",
  "ip": "192.168.1.1",
  "t": 20.5
}

You need 3 libraries for this project :

• DallasTemperature
• PubSubClient
• ESP8266WiFi (included in the ESP8266 framework on PlatformIO)

In the setup, we initialize the one-wire bus, the temperature sensor, and the LCD.

In the loop, we get the temperature, and display it on the LCD if its value changed since the last loop.

#include <Arduino.h>
#include <DallasTemperature.h>
#include <PubSubClient.h>
#include <ESP8266WiFi.h>

// WiFi config - WIFI_SSID and WIFI_PASS are passed as variable

// MQTT server - MQTT_SERVER and MQTT_TOPIC are passed as variable

// DEVICE_NAME is passed as variable
const String deviceName = DEVICE_NAME;

// Data wire is plugged into pin D3 on the ESP8266
#define ONE_WIRE_BUS D3

#define TEMP_SIZE 7

// Setup a oneWire instance to communicate with any OneWire devices
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature DS18B20(&oneWire);

WiFiClient espClient;
PubSubClient client(MQTT_SERVER, 1883, espClient);

String localIP;

char temperatureCString[TEMP_SIZE];
char previousTemp[TEMP_SIZE] = "init";

void setup_wifi() {

  delay(10);
  // We start by connecting to a WiFi network
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(WIFI_SSID);

  WiFi.begin(WIFI_SSID, WIFI_PASS);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  localIP = WiFi.localIP().toString();
  Serial.println(localIP);
}

void setup() {

  Serial.begin(115200);

  setup_wifi();

  delay(2000);

  DS18B20.begin();
}

void reconnect() {
  // Loop until we're reconnected
  while (!client.connected()) {
    Serial.print("Attempting MQTT connection...");
    // Attempt to connect
    // If you want to use a username and password, change next line to
    //if (client.connect("ESP8266Client", mqtt_user, mqtt_password)) {
    if (client.connect("ESP8266Client")) {
      Serial.println("connected");
    } else {
      Serial.print("failed, rc=");
      Serial.print(client.state());
      Serial.println(" try again in 5 seconds");
      // Wait 5 seconds before retrying
      delay(5000);
    }
  }
}

void getTemperature() {

  float tempC;
  do {
    DS18B20.requestTemperatures();
    tempC = round(DS18B20.getTempCByIndex(0) * 2.0) / 2.0;
    dtostrf(tempC, 3, 1, temperatureCString);
    if (tempC == (-127)) {
      delay(100);
    }
  } while (tempC == (-127.0));
}

void loop() {

  getTemperature();

  if (!client.connected()) {
    reconnect();
  }
  client.loop();

  Serial.println(temperatureCString);

  if (strcmp(previousTemp,temperatureCString) != 0) {
    strncpy(previousTemp, temperatureCString, TEMP_SIZE);
  }

  String tempAsString = temperatureCString;
  String totalLine = "{\"d\":\"" + deviceName + "\", \"ip\":\"" + localIP + "\", \"t\":" + tempAsString + "}";
  Serial.println(totalLine.c_str());
  client.publish(MQTT_TOPIC, totalLine.c_str(), true);

  delay(30000);
}   

The WiFi capabilities of the ESP8266 are not required in this project, but I intent to send the temperature values to an MQTT instance in a future version.

Items

• ESP8266 development board
• DS18B20 temperature sensors
• I2C LCD 16x2 display
• 4.7K resistor
• breadboard
• jumper wires

Wiring

The wiring for this project is quite simple.

• The DS18B20 sensor DATA pin is wired to the ESP8266 D3 pin.
• The LCD I2C SDA pin is wired to the ESP8266 D4 pin, and the SCL pin to the D5 pin.

Code

You need 3 libraries for this project :

• OneWire
• DallasTemperature
• LiquidCrystal_I2C

You can find the code on GitHub here.

In the setup, we initialize the one-wire bus, the temperature sensor, and the LCD.

In the loop, we get the temperature, and display it on the LCD if its value changed since the last loop.

#include <LiquidCrystal_I2C.h>
#include <DallasTemperature.h>
#include <OneWire.h>

// Data wire is plugged into pin D3 on the ESP8266
#define ONE_WIRE_BUS D3

// LCD pins
#define SDA_PIN D4
#define SCL_PIN D5

#define TEMP_SIZE 7

// Setup a oneWire instance to communicate with any OneWire devices
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature DS18B20(&oneWire);

char temperatureCString[TEMP_SIZE];
char previousTemp[TEMP_SIZE] = "init";

LiquidCrystal_I2C lcd(0x27, 16, 2); // The I2C address may be different in your project, see the notes below.

void setup() {

  Serial.begin(115200);

  Wire.begin(SDA_PIN, SCL_PIN);

  lcd.init();
  lcd.backlight();
  lcd.setCursor(5, 0);
  lcd.print("HELLO");
  lcd.setCursor(5, 1);
  lcd.print("WORLD");

  delay(2000);

  DS18B20.begin();

  lcd.clear();
  lcd.setCursor(0, 0);
  lcd.print("Temp.:");
}

void getTemperature() {

  float tempC;
  do {
    DS18B20.requestTemperatures();
    tempC = DS18B20.getTempCByIndex(0);
    dtostrf(tempC, 3, 1, temperatureCString);
    if (tempC == (-127)) {
      delay(100);
    }
  } while (tempC == (-127.0));
}

void loop() {

  getTemperature();

  Serial.println(temperatureCString);

  if (strcmp(previousTemp,temperatureCString) != 0) {
    lcd.setCursor(7, 0);
    lcd.print(temperatureCString);
    strncpy(previousTemp, temperatureCString, TEMP_SIZE);
  }

  delay(2000);
}

Notes

If nothing appears on the LCD, it could be due to several factors:

• the I2C board has a contrast adjustment potentiometer, which looks like a screw in a small blue cube on the back of the board.
• the I2C address used in the command LiquidCrystal_I2C lcd(0x27, 16, 2); (0x27) may be different for you, preventing anything to be displayed on the LCD. If it’s the case, you can find several I2C address scanner projects to run on your board (eg. on Instructables).

Some time ago, I read this comic on xkcd: Source: xkcd

It explains that a passphrase, that can be easily remembered, is actually much more difficult to guess for an attacker than a password with every “extra” security recommendation (caps, special characters, numbers…).

Generating a passphrase

A common method to generate a random passphrase is the Diceware method.

Diceware™ is a method for picking passphrases that uses dice to select words at random from a special list called the Diceware Word List. Each word in the list is preceded by a five digit number. All the digits are between one and six, allowing you to use the outcomes of five dice rolls to select a word from the list.

The regular way to generate a passphrase is to throw a dice 5 times in a row. This will give you a five-digit number, that you can lookup on the word list, and get the matching word. Repeat the operation as many times as you want words, and you get your randomly generated passphrase.

Automating the generation

Throwing dice 30+ times can be boring. So I’ve decided to write a passphrase generator based on the Diceware method.

The program, written in Python, asks you to choose the number of words in your passphrase, and the words separator (you can use any character for this).

$ python passgen.py                              
How many words will the password contain?  > 6
What character should separate the words?  > .
Generating a 6 words password, with >.< as separator.
thyme.gear.plum.dogma.yore.rubric

The program is based on the random.SystemRandom class to generate random numbers.

You can find the sources on GitHub.

A 5 part video series by Docker, explaining how to move a Java EE app to a Docker container.