Jitsi is an open source video conferencing platform that I’ve been hearing about a lot lately, and finally had a chance to look into. In this post I’ll explain how to use Terraform to provision a Jitsi instance when you need a conference and tear it down when you are done. We’ll be using Vultr and their Jitsi “application” and AWS Route 53 for DNS.

Why Am I Writing This Article, and What Does It Accomplish?

Why am I writing this article?

1. We always want to have our apps and infrastructure defined in code
2. We pay for traditional web conferencing software 24 hours a day, 7 days a week, regardless of if we are are using running a conference or not. Why don’t we spin up conference infrastructure when we need it, and tear it down when we don’t?

At a high level, this project will accomplish the following:

1. Provision a Vultr VPS that is pre-configured with Jitsi
2. Take the IP Address that Vultr assigns the VPS and use it to create an A Record in Route 53
3. Copy a script to your VPS that will be used to finish the Jitsi configuration
4. Run the script that we copied and pass a few command line arguments that are specific to our environment

Prerequisites

In addition to having Terraform downloaded and installed, we’ll need the following items:

Vultr Account + API Access

Vultr is definitely my go-to for VPS’s these days. Not only because of their price/performance/feature availability ratio, but because they provide a number of pre-configured applications that are ready, or near ready for use. Jitsi is one of these applications. If you do use Vultr, please do me a favor and use this link to sign up. I’ll get a little kickback, but you’ll get $100 USD to use on the site in your first month.

Once you have a Vultr account, you’ll need to generate and record an API key to use with Terraform. Use the steps below to generate it.

1. Log into Vultr
2. Navigate to Settings, and then API
3. Generate an API key, and copy it somewhere safe, we’ll be using it later

AWS Account + API Access

We’ll be using AWS’s Route 53 service, which is really just a fancy DNS service that’s hooked into AWS. In order to automate Route 53 with Terraform, we’ll need to enable API access.

Use this link to access the IAM Management page

1. Expand the “Access Keys” blade
2. Select “Create New Access Key
3. Save the resulting file, as we’ll use the contents later

Domain Registrar Using Custom Nameservers

In addition to the above, the domain you want to use will need to be configured to use the Route 53 Name Servers. Route 53 will provide you the nameservers when you create a zone, and you’ll simply plug those into your registrar DNS settings page. I’m not going to explain how to create a zone in Route 53, or how to configure your registrar, but if you have questions, throw them in the comments and I’ll do my best to help.

Getting Started

Run This Project

1. Grab the files below, or copy them from my Github Repository
2. Enter the directory that contains the files
3. At a minimum, modify the fields in the auto.tfvars file
   1. vultr_api_key
   1. aws_access_key
   2. aws_secret_key
   3. domain
   4. email
4. Initialize Terraform by running terraform init
5. Create a terraform plan by running terraform plan
6. Apply the configuration by running terraform apply
7. Voila! In less than 5 minutes, you’ve got a functional, secure Jitsi instance, running on a server and domain you control. Upon successful creation, you’ll see text like what we see below giving you the URL and credentials. When you are done with your conference, just run terraform destroy to stop from receiving charges on a server/service you aren’t using.

null_resource.jitsi_config (remote-exec): ------------------------------
null_resource.jitsi_config (remote-exec): |                            |
null_resource.jitsi_config (remote-exec): |   JITSI SETUP COMPLETED!   |
null_resource.jitsi_config (remote-exec): |                            |
null_resource.jitsi_config (remote-exec): ------------------------------
null_resource.jitsi_config (remote-exec): JITSI URL: https://conference.yourdomain.com/

null_resource.jitsi_config (remote-exec): USERNAME: admin
null_resource.jitsi_config (remote-exec): PASSWORD: @#$asdfahgsd34579--23%4asdf

Code

Main.tf

This file does all of the work.

#main.tf
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53

#Conifugre the Vultr provider
provider "vultr" {
  api_key = var.vultr_api_key
  rate_limit = 700
  retry_limit = 3
}

#Configure the AWS Provider
provider "aws" {
  #profile    = "default"
  #shared_credentials_file = "/home/jhowe/storage/btsync/folders/Sync/awscredentials/credentials"
  region     = var.aws_region
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

#https://www.terraform.io/docs/providers/aws/d/route53_zone.html
data "aws_route53_zone" "selected" {
  name         = "${var.domain}."
  private_zone = false
}

#Provision Vultr Server
resource "vultr_server" "my_server" {
    plan_id = var.vultr_plan_id
    region_id = var.vultr_region
    app_id = var.vultr_app_id
    label = "${var.hostname}.${var.domain}"
    tag = var.vultr_tag
    hostname = "${var.hostname}.${var.domain}"
    enable_ipv6 = false
    auto_backup = false
    ddos_protection = false
    notify_activate = false

    connection {
        type     = "ssh"
        user     = "root"
        
        #https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
        password = self.default_password

        #https://www.terraform.io/docs/provisioners/connection.html#the-self-object
        host     = self.main_ip
    }

    provisioner "local-exec" {
      command = "echo SSH to this server with the command: ssh root@${vultr_server.my_server.main_ip} with the password '${vultr_server.my_server.default_password}'"
    }
}

#Create the Route 53 A Record
#https://www.terraform.io/docs/providers/aws/r/route53_record.html
resource "aws_route53_record" "conference" {
  zone_id = data.aws_route53_zone.selected.zone_id
  name    = "${var.hostname}.${data.aws_route53_zone.selected.name}"
  type    = "A"
  ttl     = "300"
  records = ["${vultr_server.my_server.main_ip}"]
}

#This null resource exists to handle configuration of the Vultr VPS after Route 53
resource "null_resource" "jitsi_config" {
    
    connection {
        type     = "ssh"
        user     = "root"
        
        #https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
        password = vultr_server.my_server.default_password

        #https://www.terraform.io/docs/provisioners/connection.html#the-self-object
        host     = vultr_server.my_server.main_ip
    }

    provisioner "file" {
        source      = "./configure_jitsi_param.sh"
        destination = "/root/configure_jitsi_param.sh"
    }

    provisioner "remote-exec" {
        inline = [
            "chmod +x /root/configure_jitsi_param.sh",
            "/root/configure_jitsi_param.sh ${var.hostname}.${var.domain} ${var.email} y"
        ]
    }
}

Variables.tf

This file defines the variables that we will use in main.tf

#variables.tf
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53

variable "vultr_api_key" {
    description = "API Key Used by Vultr (https://my.vultr.com/settings/#settingsapi)"
}

variable "vultr_region" {
    description = "Vultr Region Selection (curl https://api.vultr.com/v1/regions/availability?DCID=1)"
    default = 1
}

variable "vultr_plan_id" {
    description = "Vultr Plan for the VPS to use (curl https://api.vultr.com/v1/plans/list)"
    default = 202
}

variable "vultr_tag" {
    description = "Vultr Tag to apply to the new VPS"
    default = "jitsi-conference"
}

variable "vultr_app_id" {
    description = "Vultr App to pre-install. This should always be '47', if jitsi is being provisioned (curl https://api.vultr.com/v1/app/list)"
    default = 47
}

variable "hostname" {
    description = "Hostname to be used"
    default = "conferences"
}

variable "email" {
    description = "email to be used for let's encrypt acme config"
    default = "john.doe@email.com"
}

variable "domain" {
    description = "domain to be used"
    default = "aremyj.am"
}

variable "aws_access_key" {
    description = "AWS Access Key - get it here: (https://console.aws.amazon.com/iam/home?#security_credential)"
}

variable "aws_secret_key" {
    description = "AWS Secret Key - get it here: (https://console.aws.amazon.com/iam/home?#security_credential)"
}

variable "aws_region" {
    description = "AWS Region"
    default = "us-east-1"
}

[yourdomain].auto.tfvars

The auto.tfvars file provides values to the variables defined in the variables.tf file. You’ll have to create this file from scratch, and terraform best practices dictate that you exclude this file from source control. Here’s an example you can use. Modify this for your environment. The name doesn’t matter, as long as it ends with auto.tfvars.

vultr_api_key = "[fill this in]"
vultr_region = 1
vultr_plan_id = 202
vultr_app_id = 47
vultr_tag = "jitsi-conference"
hostname = "conference"
email = "your.email@address.org"
domain = "your-domain.com"
aws_region = "us-east-1"
aws_access_key = "[fill this in]"
aws_secret_key = "[fill this in]"

configure_jitsi_param.sh

Full disclosure, I did not create this script. Vultr created it, and provides it on your Jitsi VPS when you request it. Unfortunately, the version they provide is intended to be executed interactively, so I made a few very minor modifications to allow for us to run it with parameters.

#!/bin/bash
#This script was copied from /opt/vultr/configure_jitsi.sh on a Vultr VPS that has the one-click Jitsi App
#I added lines 7-9 to allow for adding parameters on the CLI and commented lines 11-13 to force the variables to be provided on the CLI
#https://www.vultr.com/docs/one-click-jitsi
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53
HOSTNAME=$1
EMAIL=$2
response=$3
# User choices
#read -ep "Please specify which domain you would like to use: " HOSTNAME
#read -ep "Please enter your email address for Let's Encrypt Registration: " EMAIL
#read -r -p "Would you like to enable password authorization? [y/N] " response
case "$response" in
    [yY][eE][sS]|[yY])
        AUTH=1
        ;;
    *)
        AUTH=0
        ;;
esac


PROSODYPATH=/etc/prosody/conf.avail/${HOSTNAME}.cfg.lua
JITSIPATH=/etc/jitsi/meet/${HOSTNAME}-config.js
JICOFOPATH=/etc/jitsi/jicofo/sip-communicator.properties

# Remove and purge (Stop first and wait to avoid race condition)
purgeold() {        
        /opt/vultr/stopjitsi.sh
        sleep 5
        apt -y purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2 jitsi*
}

# Reinstall
reinstalljitsi() {
        echo "jitsi-videobridge2 jitsi-videobridge/jvb-hostname string ${HOSTNAME}" | debconf-set-selections
        echo "jitsi-meet-web-config jitsi-meet/cert-choice string Generate a new self-signed certificate (You will later get a chance to obtain a Let's encrypt certificate)" | debconf-set-selections
        apt-get -y install jitsi-meet
}

# Remove nginx defaults
wipenginx() {
        rm -f /etc/nginx/sites-enabled/default
}

# Configure Lets Encrypt
configssl(){
    systemctl restart nginx
    sed -i -e 's/echo.*Enter your email and press.*/EMAIL=$1/' /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
    sed -i -e 's/read EMAIL//'  /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
    /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh ${EMAIL}
}

configprosody() {
  AUHTLINE='authentication = "internal_plain"'
  sed -i "s/authentication\ \=\ \"anonymous\"/${AUTHLINE}/g" ${PROSODYPATH}
  cat << EOT >> ${PROSODYPATH}

VirtualHost "guest.${HOSTNAME}"
    authentication = "anonymous"
    c2s_require_encryption = false

EOT
}

configjitsi() {
        sed -i "s/\/\/\ anonymousdomain\:\ 'guest.example.com',/anonymousdomain\:\ 'guest.${HOSTNAME}',/g" ${JITSIPATH}
}

configjicofo() {
        echo "org.jitsi.jicofo.auth.URL=XMPP:${HOSTNAME}" >> ${JICOFOPATH}
}

registeruser(){
        PASSWORD=$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-16};echo;)
        prosodyctl register admin ${HOSTNAME} ${PASSWORD}
}

restartjitsi() {
        /opt/vultr/stopjitsi.sh
        /opt/vultr/startjitsi.sh
}

completedsetup(){
    echo ""
    echo "------------------------------"
    echo "|                            |"
    echo "|   JITSI SETUP COMPLETED!   |"
    echo "|                            |"
    echo "------------------------------"
    echo "JITSI URL: https://${HOSTNAME}"/
    echo ""
}

outputUser(){
    echo "USERNAME: admin"
    echo "PASSWORD: ${PASSWORD}"
    echo ""
}

# Script start

purgeold
reinstalljitsi
wipenginx
configssl
if [ "$AUTH" == "1" ]; then
    configprosody
    configjitsi
    configjicofo
    registeruser
    restartjitsi    
fi
completedsetup
if [ "$AUTH" == "1" ]; then
    outputUser
fi

Summary + More Reading

There you have it! With this project you can have a fully functional Jitsi instance on your own domain with end to end encryption in less than 5 minutes. When you are done, there’s no harm in deleting it so you aren’t charged.

Here are some references I used while creating this:

• https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53
• https://www.vultr.com/docs/one-click-jitsi
• https://www.terraform.io/docs/providers/aws/d/route53_zone.html
• https://www.terraform.io/docs/providers/aws/r/route53_record.html
• https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
• https://www.terraform.io/docs/provisioners/connection.html#the-self-object
• Create Vultr API Key: https://my.vultr.com/settings/#settingsapi
• Create AWS Access/Secret Key: https://console.aws.amazon.com/iam/home?#security_credential
• Vultr API Reference – has examples that will get you plan, region, and app IDs. https://www.vultr.com/api/

The post Jitsi for Just in Time Conferencing using Terraform on Vultr with Route 53 appeared first on VirtJunkie.

That’s a heck of an ask, isn’t it? I’ve been a LastPass customer for a very, very long time.. I use it to share secrets with my family, I use it on my mobile device to log into apps. It’s a safe bet to say it’s a critical piece of how I operate, and they have never once let me down. That said, if they asked for money to continue using their service, I’d have to pay. If they had a security event where secrets were compromised or if they lost my data, I’d be in very, very bad shape.

In this article, I will talk about how to set up a WebDAV share that’s protected by HTTPS using Traefik, Let’s Encrypt, and a WebDAV container on your own server, and use it to sync your secrets with devices.

Before I begin, it’s important to understand that using WebDAV isn’t the only way to sync your secrets with Enpass. There are others:

• Dropbox
• Google Drive
• OneDrive (Personal/Business)
• iCloud
• Box
• Folder sync

Base Server Set Up

Get a VPS

First thing we need is a server that is public internet facing. The easiest way to do this is to use a service that provides virtual private servers. I like Vultr because of their price/performance/feature availability ratio. They are cheaper than DigitalOcean and AWS, as easy, if not easier to manage, and have the scale you need to put your data pretty much wherever you want. If you do use Vultr, please do me a favor and use this link to sign up. I’ll get a little kickback, but you’ll get $100 USD to use on the site in your first month.

The OS doesn’t really matter, as long as you can install docker on it. A very small VPS will suffice, and mine costs $3.50 USD/Month.

Harden the OS

I won’t go into very much depth with this subject, but here are a few general guidelines:

• Disable root login via SSH
• Require public key authentication for SSH sessions
• Enable multi factor authentication for your remote user
• Only install packages you need
• Ensure all updates are installed, and continue to do so on a regular basis

Set Up Docker, Traefik, and WebDAV

All code is on the GitHub repository I use to share all code for this site. You can find it here: https://github.com/jonhowe/Virtjunkie.com/tree/master/DitchLastPass

First and foremost, this will not be a tutorial on how to administer Docker, WebDAV, or especially Traefik, but I’ll give you the exact steps and code for setting this up yourself, and provide some links at the end you can use to learn more about these topics.

All of the following steps will be executed on your VPS, so please sure you are connected to it via SSH or a similar terminal window.

docker network create proxy

Create Traefik Configuration

First of all, let’s create the directory structure we’ll need for Traefik (line 1). We’ll also be creating a file that will be used for storing SSL certificates (line 2), and setting permissions on it (line 3).

mkdir -p $HOME/docker/traefik/data
touch $HOME/docker/traefik/data/acme.json
chmod 600 $HOME/docker/traefik/data/acme.json

Create Traefik Configuration

Create a new file in the traefik/data directory we just created called traefik.yml with the contents below.

Changes Required:

• Line 24: Modify your email address

#File Path
#$HOME/docker/traefik/data/traefik.yml

#http://www.virtjunkie.com/ditch-lastpass-for-enpass-webdav-https-traefik/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/DitchLastPass

api:
  dashboard: false

entryPoints:
  http:
    address: ":80"
  https:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

certificatesResolvers:
  http:
    acme:
      email: your.email@domain.com
      storage: acme.json
      httpChallenge:
        entryPoint: http

Define Traefik Container

Create a new file in the traefik/data directory called docker-compose.yml

Changes Required:

• Line 30: Modify to fit the hostname of your server
• Line 31: Add in credentials compatible with basic auth. You can use the output from the command below to achieve this.
  • echo $(htpasswd -nb [your user] [your pass]) | sed -e s/\$/\$\$/g
• Line 35: Modify to fit the hostname of your server

#File Path
#$HOME/docker/traefik/docker-compose.yml

#http://www.virtjunkie.com/ditch-lastpass-for-enpass-webdav-https-traefik/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/DitchLastPass

version: '3'

services:
  traefik:
    image: traefik:v2.0
    container_name: traefik
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    networks:
      - proxy
    ports:
      - 80:80
      - 443:443
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./data/traefik.yml:/traefik.yml:ro
      - ./data/acme.json:/acme.json
      - ./data/logs/:/logs/
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.entrypoints=http"
      - "traefik.http.routers.traefik.rule=Host(`custom.hostname.com`)"
      - "traefik.http.middlewares.traefik-auth.basicauth.users=traefikuser:htpasswd-encrypted-string"
      - "traefik.http.middlewares.traefik-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.traefik.middlewares=traefik-https-redirect"
      - "traefik.http.routers.traefik-secure.entrypoints=https"
      - "traefik.http.routers.traefik-secure.rule=Host(`custom.hostname.com`)"
      - "traefik.http.routers.traefik-secure.middlewares=traefik-auth"
      - "traefik.http.routers.traefik-secure.tls=true"
      - "traefik.http.routers.traefik-secure.tls.certresolver=http"
      - "traefik.http.routers.traefik-secure.service=api@internal"

networks:
  proxy:

Start Traefik Container

cd $HOME/docker/traefik
docker-compose up -d

Create WebDAV Configuration

Before we begin, we need to create the directory structure for the WebDAV container. Use the following command to do so.

mkdir -p $HOME/docker/webdav/dav/

We’ll be using a container authored by bytemark for this project. It’s essentially just apache with the webdav module installed. As of today, the container is less than 100MB.

Define WebDAV Application Configuration

Changes Required:

• Line 15: Username used to authenticate to the WebDAV service.
• Line 16: Password you’ll use to authenticate to the WebDAV service. This is stored in plaintext in this example, but storing the variable in an external file is best practice.
• Line 17: Modify to fit the hostname of your server
• Line 27: Modify to fit the hostname of your server
• Line 31: Modify to fit the hostname of your server

#File path
#$HOME/docker/webdav/docker-compose.yml

#http://www.virtjunkie.com/ditch-lastpass-for-enpass-webdav-https-traefik/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/DitchLastPass

version: '3'
services:
  webdav:
    image: bytemark/webdav
    container_name: webdav
    restart: unless-stopped
    environment:
      AUTH_TYPE: Basic
      USERNAME: your-username
      PASSWORD: secure-passsword
      SERVER_NAMES: your-dav.domain.com
    networks:
      - proxy
    security_opt:
      - no-new-privileges:true
    volumes:
      - ./dav:/var/lib/dav
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.webdav.entrypoints=http"
      - "traefik.http.routers.webdav.rule=Host(`your-dav.domain.com`)"
      - "traefik.http.middlewares.webdav-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.webdav.middlewares=webdav-https-redirect"
      - "traefik.http.routers.webdav-secure.entrypoints=https"
      - "traefik.http.routers.webdav-secure.rule=Host(`your-dav.domain.com`)"
      - "traefik.http.routers.webdav-secure.tls=true"
      - "traefik.http.routers.webdav-secure.tls.certresolver=http"
      - "traefik.http.routers.webdav-secure.service=webdav"
      - "traefik.http.services.webdav.loadbalancer.server.port=80"
      - "traefik.docker.network=proxy"
networks:
  proxy:
    external: true

Start the WebDAV Container

Run the following command to bring up the webdav container

cd $HOME/docker/webdav
docker-compose up -d

Bringing it all together

Summary

At this point you should have two containers running on your VPS. Traefik is acting as a reverse proxy for the WebDAV container, and is providing SSL encryption to it. The SSL certificate is provided by Let’s Encrypt.

Final Directory Structure

user@webdav-server:~/docker$ tree
.
├── traefik
│   ├── data
│   │   ├── acme.json
│   │   └── traefik.yml
│   └── docker-compose.yml
└── webdav
    ├── dav
    │   ├── data
    │   │   └── Enpass
    │   │       └── vault.enpassdbsync
    │   ├── DavLock
    │   ├── DavLock.dir
    │   └── DavLock.pag
    └── docker-compose.yml

6 directories, 8 files

Migrate to Enpass Using WebDAV

Now that we’ve got a functional and secure WebDAV instance, we just need to migrate to it. These steps are pretty easy, but I want to include them to be comprehensive.

Export Secrets From Lastpass

To make our transition from Lastpass as seamless as possible, we’ll export our secrets so we can import them into Enpass. The easiest way to do this is from the Lastpass Vault.

Step 1 – Open Your Vault

Step 2 – Export Secrets

1. Select “More Options”
2. Select “Advanced”
3. Select “Export”
4. If prompted, enter your Master Password, and note where the CSV export file name and path.

Import Secrets To Enpass

Pretty easy stuff here, just open enpass, and kick off the import.

Import Steps:

1. Open Enpass
2. Select Menu
3. Select File
4. Select Import
5. When prompted to “Select from where you want to import your data into Enpass”, select Lastpass
6. Navigate to the directory you exported the CSV to
7. Select continue to finish the import

Connect EnPass To WebDav Share

At this point you’ve got a functioning WebDAV service protected by SSL, as well as a local instance of Enpass that has your lastpass secrets. We just need to connect EnPass to your Webdav instance to allow us to sync to it. Once you have EnPass Installed, follow the steps below to connect it to your WebDAV Service.

Connection Steps:

1. Open Enpass
2. Select Settings
3. Select Vaults
4. Select the Vault you’d like to sync
5. Enter the URL of your server, and ensure to include the https:// prefix
6. Enter the username and password created in Section 2.2.1
7. Ensure that the checkbox for “Bypass SSL Certificate Validation” is unchecked. We want to validate the SSL certificate since we are using Let’s Encrypt.

Risks

There are some things that LastPass does for us that we don’t get with this solution. In particular, we are somewhat exposed to brute force attempts to the webdav service. Also, LastPass has a number of email notifications that go out when things happen in your vault. We are really only notified when a new client joins the vault in Enpass.

Trafeik Resources

https://medium.com/@containeroo/traefik-2-0-docker-a-simple-step-by-step-guide-e0be0c17cfa5
https://containo.us/blog/traefik-2-0-docker-101-fc2893944b9d/

The post Set Up Enpass With HTTPS Protected WebDAV and Ditch LastPass appeared first on VirtJunkie.

Identify Large Files
First thing’s first.. let’s figure out what’s taking up the space. The snippet below will locate large files

sudo find / -mount -ls | awk '{print $7, $11}' | sort -rn | less

Duplicate Snaps
Snapd by default keeps 2 copies of your snaps. Unfortunately, you can’t set the default amount to keep to anything less than 2. Since this is my personal machine, and some of my snaps are pretty large (~1G in come cases), I only want to keep a single copy of them. The snippet below will remove all but the latest copy of a snap.

snap list --all | while read snapname ver rev trk pub notes; do if [[ $notes = *disabled* ]]; then snap remove "$snapname" --revision="$rev"; fi; done

If you want to keep more than the default of 2 snaps, you can use this snippet:

sudo snap set system refresh.retain=5

Snapd Snapshots?
For some reason I had a number of snapd snapshots on my system. You can list them like this:

snap saved

The “Saved” column is a unique identifier that is required when removing a snap. To remove a snapshot with ID of 1, run the following snippet:

snap forget 1

Docker Logs Are Out Of Control!
When I identified the large files, I saw that a docker container was using >20G of space. I stopped the container, removed the log file, and then started the container again. To prevent this issue from happening in the future, start your container while specifying the max-file and max-size parameters like the snippet below:

docker run --log-opt max-size=15m --log-opt max-file=2 dockerapp

Journal is using way too much space
Since this is a personal workstation and logging isn’t my biggest priority, we can limit the journal. To see how much space you’re currently using, run the following snippet

journalctl --disk-usage

There are three ways you can limit the journal:

1. Limit by size of all journal files
2. Limit by amount of journal files
3. Limit by age of journal files

You can handle each one of these using the snippets below

# By Size - Specify values in bytes or use K, M, G, T, P, E as units 
# for the specified sizes
journalctl --vacuum-size=200M

# By amount of files
journalctl --vacuum-files=15

# By age of files - specified with the usual "s", "m", "h", "days", 
# "months", "weeks" and "years" suffixes
journalctl --vacuum-time=7days

You can check the manpage online here

Spotify Cache in Snap
I recently noticed that Spotify has been caching tons of data on my desktop. Since I pay them to be a streaming service, I don’t really appreciate this. Fortunately, there’s a way to limit how much they cache on my machine. The changes below will limit Spotify to only cache 256MB locally.

edit this file:
/home/$USER/snap/spotify/current/.config/spotify/prefs

add the line:
storage.size=256

In Conclusion
It should go without saying that you should adhere to completely different standards if you’re running out of space on a server, and that you should test these snippets on a mission critical system. These steps should all be non-intrusive on a desktop, if you’re concerned, test them on a less critical system first.

The post Quick Tips for freeing up space in Linux appeared first on VirtJunkie.

My company standardized on Cisco Webex Teams for persistent chat. Unfortunately, webex teams does not have a linux client, and recommends that people simply use the web client. Unfortunately, I’m more used to this answer than I’d like, but fortunately I don’t have to any more.

This morning I found a project called Nativefier. It allows you to make any web page a desktop application using electron and a handful of other tools.

Their github page has documentation on how to do the install, but i’ll also add my exact steps. Keep in mind, I’m using Ubuntu 19.04 so YMMV.

You’ll need to have npm installed, and use it to install nativefier.

1. sudo apt install npm
2. sudo npm install nativefier -g

I manually went to the internet to grab an icon for webex teams that I had the packager use. Feel free to download it and use it, however, from what I read in the documentation, nativefier should have the ability to find the icon automatically. I didn’t try it, but if you do, let me know how it works!

You can use the following snippet to convert convert webex teams into an application.

nativefier -n "Webex-Teams" -p linux -a x64 -e 4.2.3 -i [absolute-path-to]/cisco-webex-teams.png --tray https://teams.webex.com/

That will create a directory called “webex-teams-linux-x64”. To open webex teams, enter that directory and run the webex-teams binary.

The post Webex Teams on Linux appeared first on VirtJunkie.

 I found a popular role in Ansible Galaxy with a ton of installs, but the documentation that comes with it doesn’t work, which is fine… not a supported version, etc. I used the steps below to get it working.

Please be aware, the test branch is likely not stable, and shouldn’t be used for production. Follow this at your own risk.

1.) Run the command below to install the role

root@server:~$ ansible-galaxy install geerlingguy.docker

2.) Create a text file named “install-docker.yml”
  – The value assigned to docker_apt_release_channel being “test”.
  – Add your own username(s) under “docker_users”
(This yaml file is located on my github page here: https://github.com/jonhowe/Virtjunkie.com/blob/master/install-docker.yml)

---
- name: Install Docker
  hosts: all
  become: yes
  become_method: sudo
  tasks:
  - name: Install Docker and docker-compose
    include_role:
       name: geerlingguy.docker
    vars:
       - docker_edition: 'ce'
       - docker_apt_release_channel: test
       - docker_package_state: present
       - docker_install_compose: true
       - docker_compose_version: "1.22.0"
       - docker_users:
          - jhowe

3.) Then it’s as easy as running the playbook

root@server:~$ ansible-playbook -K install-docker.yml

The post Ubuntu Cosmic 18.10 – Use Ansible To Deploy Docker appeared first on VirtJunkie.

It allows you to specify the following options on the command line:

1. Username in the provisioned VM
2. Password in the provisioned VM
3. Source Template
4. Snapshot used for linked clone
5. Name of new VM

It completes the following tasks

1. Clones virtual machine
2. Modifies the new VM’s VMX file to show the correct name
3. Powers on the new VM (which also registers it to Workstation)
4. Copies a script from the host to the VM as soon as VMware tools is available
5. Copies output from the script from the VM to the host machine and prints output to the screen
6. Prints the IP of the VM as soon as it’s available

The output looks like this:

$ ./workstation-clone-vm.sh --user root --pass [obfuscated] \
--template /storage/virtual_machines/Ubuntu_1810_Template/Ubuntu_1810_Template.vmx \
--snapshot base-4 --name test1
Parameters are:
User=root
Pass=[obfuscated]
Template Name=/storage/virtual_machines/Ubuntu_1810_Template/Ubuntu_1810_Template.vmx
Snapshot Name=base-4
New VM Name=test1

Cloning Ubuntu_1810_Template to test1 and using the snapshot: base-4
Powering on test1
Waiting for VMware Tools to start
..
Copying script to change the hostname from the host to the guest
Running custom script in test1 to set the hostname and rebooting
Waiting for VMware Tools to start

Copying output to local machine

Below is the output from the OS Customization:
Current hostname is ubuntu_1810_template. Hostname will be changed to test1
Waiting for the VM to return an IP Address
......
VM is running and has the IP Address: 192.168.102.131

Script took 77 seconds to execute

You can find the script source code below and on github:

#Original Locations:
#Blog: http://www.virtjunkie.com/thin-provision-vms-on-workstation-pro-using-the-vmrun-command/
#Github: https://github.com/jonhowe/Virtjunkie.com/blob/master/workstation-clone-vm.sh

#Example:
#testgetopt.sh --user root --pass [pass] --template /storage/virtual_machines/Ubuntu_1810_Template/Ubuntu_1810_Template.vmx --snapshot base-4 --name test1

TEMP=`getopt -o u:,p:,n:,t:,s: --long user:,pass:,name:,template:,snapshot: -n 'clone_workstation_vm' -- "$@"`

if [ $? != 0 ] ; then echo "Terminating..." >&2 ; exit 1 ; fi

eval set -- "$TEMP"

VMRUN=/usr/bin/vmrun



#Do not edit below this line
SOURCEVM=
SOURCESNAPSHOT=
DESTINATIONVMNAME=
GUESTUSER=
GUESTPASS=
echo "Parameters are:"
while true; do
  case "$1" in
    -u | --user )
        GUESTUSER=$2;echo "User=$GUESTUSER"; shift 2 ;;
    -p | --pass )
        GUESTPASS=$2;echo "Pass=$GUESTPASS"; shift 2 ;;
    -n | --name )
        DESTINATIONVMNAME=$2;echo "New VM Name=$DESTINATIONVMNAME"; shift 2 ;;
    -s | --snapshot )
        SOURCESNAPSHOT=$2;echo "Snapshot Name=$SOURCESNAPSHOT"; shift 2 ;;
    -t | --template )
        SOURCEVM=$2;echo "Template Name=$SOURCEVM"; shift 2 ;;
    -- ) shift; break ;;
    * ) break ;;
  esac
done
echo

wait_for_vmware_tools() {
    CMD=$1
    USER=$2
    PASS=$3
    VM=$4
    echo "Waiting for VMware Tools to start"
    until ($CMD -T ws -gu $USER -gp $PASS CheckToolsState $VM | grep -q "running"); do 
        printf '.'
        sleep 5;
    done
    sleep 10
    echo
}

wait_for_vm_ip() {
    CMD=$1
    USER=$2
    PASS=$3
    VM=$4
    echo "Waiting for the VM to return an IP Address"
    until ($CMD -t ws -gu $USER -gp $PASS getGuestIPAddress $VM | grep -q -v "Error: Unable to get the IP address"); do
        printf "."
        sleep 5
    done
    sleep 10
    echo

    IP="$($CMD -t ws -gu $USER -gp $PASS getGuestIPAddress $VM)"
    echo "VM is running and has the IP Address: $IP"
    echo
}

clone_workstation_vm() {
    SOURCE=$1
    DESTINATION=$2
    SNAPSHOT=$3
    USER=$4
    PASS=$5

    SOURCEVMX="${SOURCE##*/}"
    SOURCEVMNAME="${SOURCEVMX%%.*}"
    NEWVM=/storage/virtual_machines/$DESTINATION/$DESTINATION.vmx

    echo "Cloning $SOURCEVMNAME to $DESTINATION and using the snapshot: $SNAPSHOT"
    $VMRUN -T ws -gu $USER -gp $PASS clone $SOURCE $NEWVM linked $SNAPSHOT

    sed -i "s/displayName = \"Clone of $SOURCEVMNAME\"/displayName = \"$DESTINATION\"/g" $NEWVM

    echo "Powering on $DESTINATION"
    $VMRUN -t ws -gu $USER -gp $PASS start $NEWVM

    wait_for_vmware_tools $VMRUN $USER $PASS $NEWVM

    echo "Copying script to change the hostname from the host to the guest"
    currentDir="${0%/*}"
    $VMRUN -t ws -gu $USER -gp $PASS copyFileFromHostToGuest $NEWVM $currentDir"/JH01_Set-Hostname.sh" /tmp/JH01_Set-Hostname.sh
    echo "Running custom script in $DESTINATION to set the hostname and rebooting"
    $VMRUN -t ws -gu $USER -gp $PASS runProgramInGuest $NEWVM /tmp/JH01_Set-Hostname.sh "$DESTINATION"

    wait_for_vmware_tools $VMRUN $USER $PASS $NEWVM

    echo "Copying output to local machine"
    $VMRUN -t ws -gu $USER -gp $PASS copyFileFromGuestToHost $NEWVM /var/log/oscustomization.log $currentDir"/"$DESTINATION"_Customization.log"
    echo
    echo "Below is the output from the OS Customization:"
    cat $currentDir"/"$DESTINATION"_Customization.log"

    wait_for_vm_ip $VMRUN $USER $PASS $NEWVM
}

start=`date +%s`

clone_workstation_vm $SOURCEVM $DESTINATIONVMNAME $SOURCESNAPSHOT $GUESTUSER $GUESTPASS

end=`date +%s`
runtime=$((end-start))

echo "Script took $runtime seconds to execute"

The post Thin Provision VMs on Workstation Pro using the vmrun Command appeared first on VirtJunkie.

We can do this pretty easily by adding a script to the /etc/profile.d directory. The script I’m currently using is below:

#!/bin/bash
#file /etc/profile.d/VirtJunkie.com-set_hostname.sh
FLAG="/var/log/firstboot.flag"
if [ ! -f $FLAG ]; then
    echo "Server will reboot after this process completes"
    echo -n "Current hostname is $(hostname). Enter the new hostname and press [ENTER]: "
    read newhostname
    sudo hostnamectl set-hostname $newhostname

    #the next line creates an empty file so it won't run the next boot
    sudo touch $FLAG
    sudo reboot now
fi

Just modify your parent image, clone your test VMs, and this will prompt you to set a new hostname the first time you log in.

The post Prompt For A New Hostname on Boot appeared first on VirtJunkie.

1. Download Raspbian and flash it to your SD card. Plenty of good guides out there, but there’s nothing quite like the source.
2. Mount the SD card to your machine and navigate to the boot directory
3. Create a blank file called “ssh” in the root of the boot partition
4. Create a new file called “wpa_supplicant.conf” and include the contents below. Replace [ssid] and [password] with the values pertaining to your network.
5. Safely unmount, and have fun!

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev

update_config=1
country=US

network={
ssid="[ssid]"
psk="[password]"
key_mgmt=WPA-PSK
}

If you want more information on this process – check out the Raspbian documentation on a headless install, and the wpa_supplicant documentation.

Until next time,

Jon

The post Set Up A Headless Raspberry Pi appeared first on VirtJunkie.

I realized that the small PSU’s that come with micro atx cases might not support my 3 HDDs and1 DVD+RW drive, so I found a great PSU need calculator that I wanted to share.

Here it is.

Jon

The post Power Supply Need Calculator appeared first on VirtJunkie.

It’s pretty simple, you just have a few parts to the command string.  The first command argument tells ssh to forward a local port (LP) to a remote machine Remote) on a remote port (RP).  The second part is something you’re probably familiar with, the destination that you’re connecting to (Destination).

An example with the abbreviations above would be:

ssh -L LP:Remote:RP Destination

Say for example, you ran the command “ssh -L 1234:myInternalServer.com:80 myExternalServer”.  In order to access port 80 on myInternalServer.com you’d open up your web browser and point it to It’s as easy as that!

The post SSH Local Port Forwarding Made Easy appeared first on VirtJunkie.