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.

It should be pretty self explanatory.. just edit the variables in the parameter section and call the function.

Cheers!

Github: https://github.com/jonhowe/Virtjunkie.com/blob/master/Deploy-VM.ps1

function New-VirtJunkieLinkedClone {
    [CmdletBinding()]
    <#
    Github: https://github.com/jonhowe/Virtjunkie.com/blob/master/Deploy-VM.ps1
    Link: https://www.virtjunkie.com/?p=774
    #>
    param (
        #vCenter Info
        $vCenter            = 'vcsa.home.lab',
        $username           = 'administrator@vsphere.local',
        $password           = 'VMWare1!',
        $TemplateCustomSpec = 'WS16to19',

        #Parent VM Info
        $ParentVMName       = 'WS16-GUI',
        $SnapshotName       = "Base",

        #New VM Info
        $VMName             = "vra-iaas-2",
        $VMIP               = "192.168.86.214",
        $VMNetmask          = "255.255.255.0",
        $VMGateway          = "192.168.86.1",
        $VMDNS              = "192.168.86.232"
    )
    
    begin {
        $vc_conn = Connect-VIServer -Server $vCenter -User $username -Password $password
    }
    
    process {
        # Get the OS CustomizationSpec and clone
        $OSCusSpec = Get-OSCustomizationSpec -Name $TemplateCustomSpec | 
            New-OSCustomizationSpec -Name 'tempcustomspec' -Type NonPersistent

        #Update Spec with IP information
        Get-OSCustomizationNicMapping -OSCustomizationSpec $OSCusSpec |
            Set-OSCustomizationNicMapping -IPMode UseStaticIP `
                -IPAddress $VMIP `
                -SubnetMask $VMNetmask  `
                -DefaultGateway $VMGateway `
                -Dns $VMDNS

        $mySourceVM = Get-VM -Name $ParentVMName
        $myReferenceSnapshot = Get-Snapshot -VM $mySourceVM -Name $SnapshotName 
        $Cluster = Get-Cluster 'Cluster'
        $myDatastore = Get-Datastore -Name 'Shared'

        New-VM -Name $VMName -VM $mySourceVM -LinkedClone -ReferenceSnapshot $myReferenceSnapshot -ResourcePool $Cluster `
        -Datastore $myDatastore -OSCustomizationSpec $OSCusSpec
    }
    
    end {
        Get-OSCustomizationSpec -Name $OSCusSpec | Remove-OSCustomizationSpec -Confirm:$false
    }
}

The post PowerCli – Deploy Linked Clone with Static IP 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.

Anyways, more to the point. In this post I will demonstrate how to do a base configuration of Horizon Workspace using an internal Microsoft Certificate Authority with Nginx as a frontend. This setup is only acceptable for setting up workspace in a lab environment, since in a production environment you’ll need a trusted third party cert. Doing this in a lab environment is important because it will allow you to set up and test every feature you’ll be using in a production environment.

Requirements:

• Microsoft Active Directory Certificate Services
• Linux Machine running Nginx
• Horizon Workspace 1.5 Downloaded and installed with no configuration.
  • We’ll be using the workspace FQDN of hzn.test.in (This obviously assumes the domain of test.in)

1. On Linux machine, generate private key(1) and CSR(2)

   1. openssl genrsa -out hzn.test.in.key 1024

   2. openssl req -new -key hzn.test.in.key -out hzn.test.in.csr

2. Take CSR and get a certificate from your internal Domain CA. Download the certificate. Rename it as hzn.test.in.crt
3. Download your internal Domain CA root key
   1. On the machine running AD Cert Services, open the command line and type the following command:
   2. [text]certutil -ca.cert %userprofile%\Desktop\test.in-root.cer[/text]
4. Ensure that Nginx is forwarding traffic correctly to the gateway-va. Below is a snippet (Entries in square brackets need to be changed]:
   1. [text]
      server {
      listen [load balancer IP];
      server_name hzn.test.in;
      ssl on;
      ssl_certificate [path to]hzn.test.in.crt
      ssl_certificate_key [path to]hzn.test.in.key

      location / {
      proxy_pass https://gateway-va.test.in:443/;
      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_read_timeout 1800;
      proxy_connect_timeout 1800;
      }
      [/text]

5. Place your domain root ca key (gathered in step 3) into the configurator web interface
   1. Open the web interface and navigate to the FQDN & SSL section
   2. Select Yes under External Load Balancer
   3. Enter: hzn.test.in:443 in the Horizon Workspace FQDN section
   4. Paste the domain root ca key in the “Load Balancer Root CA Certificate” section.
6. You’re all set!  You can now log into the Horizon Workspace Admin page by navigating to https://hzn.test.in/admin

I’d be happy to answer any questions on this. Feel free to post a comment if you like. I’ll answer any questions I can.

The post VMware Horizon Workspace – Part 2 – Configure Nginx as Frontend with Microsoft CA appeared first on VirtJunkie.

In this series, I will be covering how I configured each part of this suite. I would expect that this process will become exponentially easier as time goes on. One thing to note is that I will write these posts assuming that you are at least moderately familiar with linux and Workspace. I will not go into details on how to install packages, deploy the VA, use the web interface. Use Google if you’re looking for that boring stuff Here we go!

Due to the reliance that the business will put on the Workspace, my definition of Production is as follows:

1. Externally Accessible
   1. One URL to rule them all, both internal and external
2. Load Balanced from within DMZ
   1. Multiple Load Balancers – no single point of failure!
3. Multiple Virtual Appliances
   1. At LEAST 2 of every VA that comes with Workspace (Gateway, Connector, Service, Data)
4. External Postres SQL Database
5. Third Party SSL Certificate
   1. I used Godaddy, but if I had to do it again, I’d go with Verisign, or a more reputable CA. This should be fixed in Workspace 1.5, which should be released by the end of July.
6. Data is stored on NFS rather than on local vmdk

Throughout this (we’ll call it an adventure) I’ve learned a lot about the product.Most importantly, it’s become clear to me that this is not a product easily administered by a “VMware Admin”. Horizon Workspace is built on top of Suse Enterprise Linux 11, relies heavily on Zimbra for the data component, and uses nginx for everything else.

Sound like greek? Don’t panic, you can set up a good amount of Horizon Workspace without being a linux guru, however, imho, most of the things you’ll need to do in a production environment will require at least a moderate familiarity with the linux command line.

The post VMware Horizon Workspace – Part 0 – Intro appeared first on VirtJunkie.

While I could use PowerShell to get the status of volumes from only each individual filer replacing  using the following snippet:

if (!(Get-Module dataontap)) { Import-Module DataOnTAP }
$filer1 = Connect-NaController filer1 -Credential (Get-Credential)
$filer2 = Connect-NaController filer2 -Credential (Get-Credential)
Get-NaVol -controller $filer1
Get-NaVol -controller $filer2

But that’s two commands… why would you want to enter two commands when you can enter one?!  Assuming you set up the controller objects in lines 2 and 3 above, you can simply run the command below to get all volumes from both Filer1 and Filer2:

($filer1,$filer2) | % { Get-NaVol -Controller $_ }

While this gets volumes from all controllers, why on EARTH would you want to see the size in bytes?? Seriously…

Below is a finished script that gathers volume information from multiple filers, but also formats the output in a human readable format. If you have uniform naming convention for volumes in your filers, you can un-comment (remove the <# and #> ) and enter the prefix of your volume on line 15.

# ========================================================================
# Created on:	7/11/2013 9:10 PM
# Created by:	Jon Howe
# URL: http://45.63.13.214/?p=510
# Filename:		Get-MultipleFilerVolStats.ps1
# ========================================================================

if (!(Get-Module dataontap)) { Import-Module DataOnTAP }

$filer1 = Connect-NaController filer1 -Credential (Get-Credential)
$filer2 = Connect-NaController filer2 -Credential (Get-Credential)
#$filer3 = Connect-NaController filer3 -Credential (Get-Credential)

($filer1,$filer2) | 
Foreach-object { Get-NaVol <#-name volPrefix #> -Controller $_ } | 
Select-Object Name,Used,Available | 
Format-Table -AutoSize -Property 
@{label="Volume";Expression={$_.Name}}, 
@{label="Percent Used";expression={$_.Used}}, `
@{label="Available";expression={[math]::round($_.Available / 1gb, 2)}
}