Dennis Tanaka

Provisioning KVM Virtual Machines with Cloud Init

2020-11-08T00:11:39+00:00

KVM Provisioning with cloud-init
Introduction
Requirement
Guide
Branch from the Downloaded Image
Create the Provisioning Configuration
Bridge Networking
Creating a New Virtual Machine
Clean Up
References
- Additional Information

KVM Provisioning with cloud-init

Introduction

In a previous post, I showed how I installed KVM on a spare laptop and used Cockpit to remotely manage virtual machines. In this post, I will to through the steps I took to quickly provision VMs based on Ubuntu Cloud Image with cloud-init.

Ubuntu Cloud Images are official Ubuntu images meant to run on public clouds such as AWS. These images are usually used in conjunction with cloud-init, a tool created by Canonical that is used to customize cloud images when virtual machines are first run.

cloud-init runs a set of user-defined configurations in the instance’s first boot and can be used, for example, to generate and setup SSH private keys. In this example, we are going to have something similar to what we get on AWS: an Ubuntu virtual machine we can connect remotely through SSH, in which we can run passwordless sudo commands.

Ubuntu Cloud Images have shell access disabled by default, although we can customize this aspect as well.

Requirement

Having installed KVM, following Managing KVM Virtual Machines with Cockpit or a similar guide.

Guide

Install Required Packages

We first needd to install cloud-image-utils. This is needed to provision the client OS in the first boot.

$ sudo apt install cloud-image-utils

Download the Ubuntu Cloud Image

Ubuntu provides their cloud images at https://cloud-images.ubuntu.com/. In my case, I chose to use Bionic 18.04 LTS. I’ve created a ~/cloud_images folder to store such files:

~/cloud_images$ wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img

Verifying the Downloaded Image

To make sure the image is not corrupted nor has been tampered with, let’s execute the steps below. We use gpg to verify the image’s authenticity and sha256 to verify its integrity. The necessary tools are installed by default on Pop_OS! I’m using. For other cases, you can check the link below:

https://ubuntu.com/tutorials/how-to-verify-ubuntu#2-necessary-software

But first, also download both the SHA256SUMS and SHA256SUMS.gpg files to the same folder. Then:

# check if we need to download the public key used to authenticate the checksum file:
$ gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

For me, it returned something like:

gpg: Signature made <date and time>...
gpg:                using RSA key <key ID>
gpg: Can't check signature: No public key

From this message, we know the ID of the key we need to request to the Ubuntu key server:

$ gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com --recv-keys <key ID>

This command should report that the key was imported, what means that it was retrieved and added to the keyring. Now, we can inspect the key fingerprints:

$ gpg --keyid-format long --list-keys --with-fingerprint 0x<key ID>

It should display the key used to sign Ubuntu Cloud Images checksums. We can now verify the checksum file using the signature:

$ gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

This returned the following line in the output:

gpg: Good signature from "UEC Image Automatic Signing Key <cdimage@ubuntu.com>" [unknown]

A Good signature means the checksum file was indeed created by Ubuntu. So, now we can check that the image’s sha256 checksum matches the downloaded checksum:

$ sha256sum -c SHA256SUMS 2>&1 | grep OK

An output like the following indicates the ISO file matches the checksum and should be used without problems.

bionic-server-cloudimg-amd64.img: OK

Branch from the Downloaded Image

We can get the details of the image we just downloaded with the command below:

$ qemu-img info bionic-server-cloudimg-amd64.img

# Output
image: bionic-server-cloudimg-amd64.img
file format: qcow2
virtual size: 2.2 GiB (2361393152 bytes)
disk size: 343 MiB
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16

As we can see, the downloaded image is way too small for any practical purpose, so let’s create a new 20GB image based on the downloaded one:

$ qemu-img create -f qcow2 -F qcow2 -b bionic-server-cloudimg-amd64.img  vm_0001-bionic-server-cloudimg-amd64.qcow2 20G
$ qemu-img info vm_0001-bionic-server-cloudimg-amd64.qcow2

# Output
image: vm_0001-bionic-server-cloudimg-amd64.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 196 KiB
cluster_size: 65536
backing file: bionic-server-cloudimg-amd64.img
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Note: we could have also made a copy of the downloaded image and resized with qemu-img resize vm_0001-bionic-server-cloudimg-amd64.qcow2 20G

Create the Provisioning Configuration

Now, we are going to create the cloud-init configuration to be used in the guest provisioning. Let’s first create a user-data file containing the content below. The meta-data file may be used in the future but, for now, let’s keep it empty.

$ mkdir cloud-init
$ cd cloud-init
$ touch user-data
$ touch meta-data

#cloud-config

hostname: vm_0001
fqdn: vm_0001.localdomain
manage_etc_hosts: true

ssh_pwauth: false
disable_root: true

users:
  - name: ubuntu
    home: /home/ubuntu
    shell: /bin/bash
    groups: sudo
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh-authorized-keys:
      - <SSH public key>

The <SSH public key> needs to be replaced accordingly.

For networking, we create a file called network-config. This is an example for a fixed IP configuration:

version: 2
ethernets:
  enp1s0:
     dhcp4: false
     addresses:
     - 192.168.122.100/24
     gateway4: 192.168.122.1
     nameservers:
       addresses:
       - 192.168.122.1
       - 8.8.8.8

In my case, I’ve used the dynamic IP configuration below:

version: 2
ethernets:
  enp1s0:
     dhcp4: true

I had named the interface ens1, but the guest VM was not able to have an IP address assigned when started. In these failed VM starts, network information was displayed during the boot and I noticed the interface was being identified as enp1s0. So, I’ve changed the interface name in the network-config file and the guests started getting IP addresses from the DHCP server.

Let’s now create a disk image containing the provisioning configuration. This is where the cloud-image-utils package is used.

$ cloud-localds -v --network-config=network-config cloud-init-provisioning.qcow2 user-data meta-data

One of the tutorials uses genisoimage instead of cloud-localds

Bridge Networking

Before creating a new virtual machine, we are going to create a network bridge on the host first. This will allow our virtual machines to connect to the local network directly and become visible in this context. Let’s first install the necessary dependency:

$ sudo apt install bridge-utils

Next, let’s edit the /etc/network/interfaces file that was originally like this:

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

Add the following lines after the existing content:

auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
        bridge_ports enp6s0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

In my case, I opted for DHCP as I’ve reserved my host IP address in the router. Also, bridge_ports need to be replaced accordingly (in my case, the ethernet interface on the host is enp6s0).

Now, we just need to restart networking:

$ sudo /etc/init.d/networking restart

Just by restarting the network, my ethernet adapter was still showing up with an IP address assigned. So, I restarted the host and only the bridge is visible now, as it is supposed to be.

Creating a New Virtual Machine

Now, we can create the new virtual machine:

$ virt-install \
  --name vm_0001 \
  --virt-type kvm \
  --vcpus 2 \
  --memory 2048 \
  --disk path=cloud_images/vm_0001-bionic-server-cloudimg-amd64.qcow2,device=disk \
  --disk path=cloud-init/cloud-init-provisioning.qcow2,device=cdrom \
  --os-type Linux \
  --os-variant ubuntu18.04 \
  --graphics none \
  --network bridge=br0 \
  --import

The machine will start its initialization process until it reaches the login prompt. According to our configuration, we are supposed to access the guest through SSH and no user is allowed shell access to it. We can go back to our shell with the Ctrl + ] key combination.

In my case, my KVM host is not my main desktop, so the guest is on a separate machine, but accessing it from my desktop should not be a problem since the guest is using bridge networking. Since I set the SSH public key from my desktop in the cloud-init provisioning configuration, I can access the newly created guest with:

$ ssh ubuntu@<ip address of the guest>

We can discover the IP address of the guest during its boot process when network information is displayed. But, as far as I know, the only way to check the IP address assigned to the guest afterwards is to check the list of DHCP clienst on my router’s admin screen. So, in this case, it’s probably a better idea to set a static IP address for the guest or, maybe, fix the guest’s IP address in the router. The article below mentions the same limitation:

https://levelup.gitconnected.com/how-to-setup-bridge-networking-with-kvm-on-ubuntu-20-04-9c560b3e3991

Lastly, we can check some output generated by cloud-init in the following files:

/run/cloud-init/result.json
/var/log/cloud-init.log
/var/log/cloud-init-output.log

Clean Up

cloud-init is setup to run everytime the machine starts and it can be left this way if we want to enforce those settings. If that’s not the case, we can disable cloud-init.

# this file disables cloud-init execution
$ sudo touch /etc/cloud/cloud-init.disabled

# alternatively, we could remove the cloud-init package

References

Additional Information

The URL below provides a very friendly overview of cloud-init:

https://www.digitalocean.com/community/tutorials/an-introduction-to-cloud-config-scripting

Managing KVM Virtual Machines with Cockpit

2020-11-07T06:00:57+00:00

Introduction
Preparation
Installation
Cockpit Interface
Impressions
Edits
- Session Timeout
  - December 6th, 2020
- Update from Backports
  - December 6th, 2020
References

Introduction

Currently, I’m trying to use virtual machines and containers as much as possible. But, as I use multiple devices, I wanted to be able to manage those virtual machines easily from any of those machines. My idea was to use a laptop I had laying around for that purpose, so I started researching about the options I had and there were a couple of interesting options such as VMware, Proxmox and oVirt. I ultimately decided to use Cockpit to manage KVM virtual machines on the host. Cockpit is a web-based interface to manage servers, not a virtualization focused application like the mentioned options, but it has a module for VM management.

There’s not a strong reason for that choice and I may test the other options in the future. It’s just that it seemed faster to start using it since I already had Pop_OS! installed on the laptop and I decided to install Cockpit on top of that. I knew it lacks a lot in terms of features compared to the other options, but I thought it was OK because this was my first experience with KVM. I knew what KVM is and was interested in trying it out, so I thought it would good to have to do things manually whenever Cockpit didn’t support something I’d like to do.

Preparation

Lid

I first setup my laptop to work with its lid closed so I could save on space by putting it on a stand that keeps the laptop in the vertical position.

I just had to edit the /etc/systemd/logind.conf file and make sure HandleLidSwitch is uncommented with the ignore value as below:

HandleLidSwitch=ignore

And restart the corresponding service:

$ systemctl restart systemd-logind.service

SSH

Next, I instaled SSH:

$ sudo apt install ssh

# at this point, the server should be up and running. Checking it, just in case:
$ sudo systemctl status ssh

And created the authorized_keys file to allow access from the PC I use the most:

$ mkdir .ssh
$ cd .ssh/
$ touch authorized_keys
$ vim authorized_keys

Hostname

I also changed the hostname as the original name was not appropriate anymore:

# well, not sure I can consider this a homelab, but it's easy to remember :D
$ sudo hostnamectl set-hostname homelab

I also edited the /etc/hosts file and replaced the reference to the old hostname. That line looks like this now:

127.0.1.1       homelab

Checking Virtualization Support

A standard installation of Cockpit will not contain the module to manage virtual machines. Because my main goal is to use Cockpit for this specific purpose, I first checked that my CPU supports hardware virtualization.

This was done with the following command:

# if the command below returns 1 or more, it means virtualization is supported.
$ egrep -c '(vmx|svm)' /proc/cpuinfo

# Another alternative is to use the following command:
$ kvm-ok

In my case, as virtualization is supported, kvm-ok returned an output like this:

INFO: /dev/kvm exists
KVM acceleration can be used

kvm-ok will even show an alert in the case virtualization is supported, but it’s disabled in the BIOS. In this case, it should be activated to enable virtualization at full speed.

Installation

The Cockpit installation itself was extremely simple:

$ sudo apt update
$ sudo apt install cockpit

I also installed the following package, so I could manage virtual machines:

$ sudo apt install cockpit-machines

The corresponding service should be started after the installation and we can confirm through the command below:

$ systemctl status cockpit

Compared to the Ubuntu KVM installation tutorial, this procedure didn’t install the bridge-utils package which I may install later to allow virtual machines to access the local network directly.

That same tutorial also mentions the need to add the user to the libvirtd group, but it was already done after the installation without me having to do anything.

I could also have installed Virt-Manager that seems to be a much more feature-rich than the Cockpit’s VM management module. Although Red Hat is recommending the use of Cockpit instead of Virt-Manager, it’s still under development.

But, for now, I will stick to using Cockpit because, as I said before, I’m interested in doing everything Cockpit doesn’t support manually, through the command-line.

Cockpit Interface

We can access Cockpit through the port 9090 on the host:

https://ip-address:9090/

The browser will display a warning since we are dealing with a self-signed certificate. I safely skipped it since I’m only accessing Cockpit on my local network. Then, the login screen is displayed:

We just need to provide our credentials on that machine. The Reuse my password for privileged tasks option, as it suggests, makes the same credentials to be used for tasks such as installing updates, so we don’t have to provide the same credentials again.

Once logged in, we can check the VM management interface where we can check information about our machines and change their state:

We can also create new virtual machines and access them through the Consoles tab:

It also provides a Terminal menu that gives us shell access to the host what can prove to be convenient.

Impressions

For my impressions, at least in terms of virtual machine management, Cockpit certainly feels lacking for now and development doesn’t seem to be that fast. If it was not for my goal of knowing more about KVM it would probably not make that much sense.

That said, it seems enough for my home usage. It’s nice to be able to have a glance on the existing virtual machines as it gives visibility on what is going on in the host. I will probably not use much of its features outside managing virtual machines, but being able to do simple checks and management tasks from a web interface is very convenient.

Edits

Session Timeout

December 6th, 2020

Cockpit automatically log us out after 15 minutes of inactivity. We can configure this session timeout, in minutes, by editing the /etc/cockpit/cockpit.conf file (it may be necessary to create it) with a content like the following:

[Session]
IdleTimeout=180

Source: https://cockpit-project.org/blog/cockpit-209.html

Update from Backports

December 6th, 2020

As of now, 215 is the most recent version of Cockpit available in the Ubuntu 20.04 repositories, even though the most recent version of the application itself is 233. To update to a more recent version, the easiest way is to install the version (currently 231) from the Backports repository. I use the command below to update the Cockpit’s version and resolve its dependencies from Backports:

sudo apt install -t focal-backports cockpit cockpit-machines

Source: https://help.ubuntu.com/community/UbuntuBackports#Using_Backports

References

Creating a Portfolio Website with Jekyll (and Hosting it on GitHub) - Part 2

2019-03-21T11:31:46+00:00

In Part 1, we took a quick look at Jekyll and how to create and deploy a website to GitHub Pages. In this second and final part, let’s explore some of the customization features Jekyll provides us.

Layouts

In the previous example, you may have noticed the layout definition below in the front matter:

layout: post

While the markdown file provides the content of a page, the structure and appearance are defined in the layout file. We can create our own layout files, but because we are using an existing theme, we can customize the theme’s layout files instead.

First, let’s copy the layout files from the theme’s folder to our project (the specific folder to copy from will probably be different for you as it depends on the version of the packages installed).

cp -r vendor/bundle/ruby/2.3.0/gems/minima-2.5.0/_layouts .

If we take a look at the _layouts folder, we can see the 4 files below:

default.html
home.html
page.html
post.html

If we open the default.html file, we can see contents like the below:

<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: "en" }}">

  {%- include head.html -%}

  <body>

    {%- include header.html -%}

    <main class="page-content" aria-label="Content">
      <div class="wrapper">
        {{ content }}
      </div>
    </main>

    {%- include footer.html -%}

  </body>

</html>

It is an ordinary HTML file, but we can see a couple of the features provided by Jekyll and the Liquid template language it uses.

“Include” tags, like the below, allow us to include content from another file stored in the _includes folder:

{%- include header.html -%}

While the line below specifies where the content of a markdown file that uses the layout file will be injected:

{{ content }}

If we take a look at the contents of page.html:

---
layout: default
---
<article class="post">

  <header class="post-header">
    <h1 class="post-title">{{ page.title | escape }}</h1>
  </header>

  <div class="post-content">
    {{ content }}
  </div>

</article>

We can see that a layout itself can use another layout and that this layout can be used to display an article with a title in the top.

Now, we can also open the about.md file that ships with Jekyll. We can see in the front matter that this file uses the page layout.

---
layout: page
title: About
permalink: /about/
---

Also, the front matter defines a title and this title is injected in the line below in the page layout:

<h1 class="post-title">{{ page.title | escape }}</h1>

Now that we have an idea of how layouts work, let’s customize our website a little bit.

Includes

In the default.html layout file, we can see the line below:

{%- include header.html -%}

Because the default.html layout includes the header and all other layouts uses the default layout, it is obvious that all pages in our website includes the content in header.html.

Let’s take a look at the contents of the header.html file. Because it is also part of the minima theme, we need to copy this file as well:

mkdir _includes
cp vendor/bundle/ruby/2.3.0/gems/minima-2.5.0/_includes/header.html _includes

This include file is responsible for displaying the website header and shows many variables that Jekyll make available for us, as well as filters provided by the Liquid template language.

{%- assign default_paths = site.pages | map: "path" -%}

The line above, for example, shows the site.pages variable. It is an array of Jekyll’s Page variables (you can check the list of attributes a Page variable contains in Page Variables). Any .html or .md file in the root folder or a new subfolder that contains a front matter will be part of the site.pages variable. Then, we execute Liquid’s map filter on the site.pages to get an array of the paths of those pages.

{%- assign page_paths = site.header_pages | default: default_paths -%}

The next line creates a variable called page_paths. It is assigned the value in site.header_pages, but can also be assigned the value in default_paths in the case the former does not exist, what is possible with the use of Liquid’s default filter. We are going to come back to site.header_pages later.

{%- for path in page_paths -%}
  {%- assign my_page = site.pages | where: "path", path | first -%}
  {%- if my_page.title -%}
  <a class="page-link" href="{{ my_page.url | relative_url }}">{{ my_page.title | escape }}</a>
  {%- endif -%}
{%- endfor -%}

This last snippet iterates over the page_paths variable created before and creates a link in the header for each page that has a title (defined in the front matter).

To test what was just shown, let’s create a new page notes.md in the project’s root folder. Now, let’s add the content below to the new file:

---
layout: page
title: Notes
permalink: /notes/
---

If we refresh our website, we are going to see a new “Notes” link in the header. Add another page called contact.md to the root folder with the content below:

---
layout: page
title: Contact
permalink: /contact/
---

A new link is created as well. The problem is that the links are created in the alphabetical order, but we may want a different order to put the “Contact” page last, for example. In that case, we can use the site.header_pages mentioned before. This currently does not exist, but we can easily create this variable by adding the following lines to the _config.yml file:

header_pages:
  - about.md
  - notes.md
  - contact.md

You will notice the change will not be reflected immediately and will require the server to be restarted. After that, the header will look as expected.

The Resulting Header

Collections

Now, we are going to explore Collections that are a great way to group related content. Let’s use this feature to implement the “Notes” section in our website.

First, add the following content to _config.yml:

collections:
  - notes

Then, let’s create a _notes folder and add 2 files in it. The /_notes/note1.md:

---
menu_title: Note 1 Menu Item
title: Note 1 Title
---

Note 1 content

> A nice blockquote

A **formatted** line of *text*.

And the /_notes/note2.md:

---
menu_title: Note 2 Menu Item
title: Note 2 Title
---

Note 2 content

> A nice blockquote

A **formatted** line of *text*.

Now, let’s create a custom layout listing all our notes. It will be the /_layouts/note.html file and will contain the following content:

---
layout: default
---
<style>
.note {
  margin: 2rem 0;
  padding: 1rem 2rem;
}

.yellow {
  background-color: #fdf475;
}

.blue {
  background-color: #cbf0f8;
}

.note-date {
  font-size: 0.8rem;
  font-style: italic;
  color: gray;
}
</style>
<div class="notes-container">

  <header class="notes-header">
    <h1 class="notes-title">{{ page.title | escape }}</h1>
  </header>

  {%- for note in site.notes -%}
  <article class="note {{ note.background }}">

    <header class="note-header">
      <h2 class="note-title">{{ note.title | escape }}</h2>
      <p class="note-date">{{ note.date }}</p>
    </header>

    <div class="note-content">
      {{ note.content }}
    </div>

  </article>
  {%- endfor -%}
</div>

I added the styles directly in the layout, to keep things simple, as that is not the main focus of the article. As Jekyll has built-in support for Sass, please refer to the Docs to know how to manage your stylesheets.

You can see we were able to access our notes through the site.notes variable and even use a custom variable background we added to the front matter.

Restart the server and we can now access those notes in the /notes/ path.

The Notes Page

The files we created in the _notes folder does not generate corresponding files in Jekyll’s build process. If you need, you can change this behavior as shown in Add content. This would generate files such as /_notes/note1.html in the build output. In our example, we could, for example, display only part of the content of the notes in the list and link each note to a page where the user can see their whole content.

Data Files

In this final section, we are going to take a quick look at Data Files. It allows us to create files with custom data to be used in our templates. Those can be YAML, JSON, or CSV files. Let’s do an example to illustrate its use.

First, create a file named /_data/contacts.yml:

- type: Email
  value: me@dennistanaka.com

- type: Phone
  value: (00) 0000-0000

- type: Website
  value: http://github.com/dennistanaka

This is enough to make our data accessible in our templates in the site.data.contacts variable. So, we can now edit our /contact.md file with the following content:

---
layout: page
title: Contact
permalink: /contact/
---

<table>
  {%- for contact in site.data.contacts %}
  <tr>
    <td>{{ contact.type }}</td>
    <td>{{ contact.value }}</td>
  </tr>
  {%- endfor %}
</table>

This will generate the below output:

The Contact Page

As we could see, we can use Data Files to remove repetition in our pages by separating data and configuration. A practical use is illustrate in Navigation where it is used to create custom navigation for a website.

Conclusion

In these article, we could learn and practice basic Jekyll concepts such as Layouts, Collections and Data Files. There are plenty of content was not covered in the articles, so I highly recommend reading the documentation, as it is very well written and easy to understand.

Creating a Portfolio Website with Jekyll (and Hosting it on GitHub) - Part 1

2018-07-14T13:16:58+00:00

Repository Creation

Jekyll Installation

In this article, I won’t cover the installation process. It is very well documented in the Jekyll documentation and I assume you are going to follow that, but I will try to present some guidelines. I also assume you have a working Git installation.

Jekyll is distributed as a Ruby Gem and can be installed on most systems. It is recommended to work on a Unix-based system such as macOS or Linux, but you should not have problems working on Windows as well. By the way, this article was written on a Windows machine with Windows Subsystem for Linux enabled. You can take a look at the official documentation if you choose to go this path too.

Whatever system you choose to work on, the requirements are the same. You are going to need to have Ruby, RubyGems and build tools (GCC and Make) installed. If you, like me, are a Rails developer and already have a Ruby development environment installed, you should be good to go after installing Jekyll with the following commands (we are also installing bundler, a gem that helps us manage other Ruby gems in our project):

$ gem install jekyll bundler

New Project

Now, we are going to create a new Jekyll project:

$ jekyll new dennistanaka.github.io --skip-bundle

We passed the option --skip-bundle because we don’t want to install our dependencies system-wide. Instead, we want the installation of our dependencies to be limited to our project. But first, as we know we are going to host our website on GitHub, we want to setup up our project accordingly. First, open the Gemfile file created on your project’s root folder.

And remove the line declaring the dependency of the jekyll gem. It may differ depending on the version of the software you are working with, but in my case, I removed the following line:

gem "jekyll", "~> 3.6.2"

And uncomment the following line:

# gem "github-pages", group: :jekyll_plugins

Dependencies Installation

We can now install or dependencies locally with the following command:

$ cd dennistanaka.github.io
$ bundle install --path vendor/bundle

Local Server Startup

After that we can serve our website with the following command:

$ bundle exec jekyll serve

Just open a browser and access the following address:

http://127.0.0.1:4000/

Great! We already have a working website. You can see Jekyll comes with a pre-defined look & feel. Jekyll supports themes and it uses a theme called minima by default. You can check this fact by opening the Gemfile file, where there is a line setting the minima gem as a dependency:

gem "minima", "~> 2.0"

In this article, I will show you how we can start customizing our website. Although we can start our website from scratch, without a theme at all, it is probably easier to have a starting point, at least when using Jekyll for the first time.

But, before that, let’s add our website to GitHub to manage the changes in our website. You will see that, in the case of a Jekyll website, adding the project to GitHub not only means that we are controlling its versions, but also means that we are deploying our website for public access.

Before doing that, let’s edit our .gitignore file. The Jekyll project already comes with a .gitignore to prevent unnecessary files to be commited. But, as installing the gems locally is an optional step, it does not include entries to ignore the installed packages. So, let’s add the following lines to the .gitignore file:

.bundle
vendor

Now we can push our files to GitHub as usual:

$ git init
$ git add .
$ git commit -m "First commit"
$ git remote add origin git@github.com:dennistanaka/dennistanaka.github.io.git
$ git push -u origin master

You can now access your website at the URL provided by GitHub. In my case, it is: https://dennistanaka.github.io/. If you still can’t see your website, it may take some time for GitHub to build it.

Dennis Tanaka

Provisioning KVM Virtual Machines with Cloud Init

Table of Contents

KVM Provisioning with cloud-init

Introduction

Requirement

Guide

Install Required Packages

Download the Ubuntu Cloud Image

Verifying the Downloaded Image

Branch from the Downloaded Image

Create the Provisioning Configuration

Bridge Networking

Creating a New Virtual Machine

Clean Up

References

Additional Information

Managing KVM Virtual Machines with Cockpit

Table of Contents

Introduction

Preparation

Lid

SSH

Hostname

Checking Virtualization Support

Installation

Cockpit Interface

Impressions

Edits

Session Timeout

December 6th, 2020

Update from Backports

December 6th, 2020

References

Creating a Portfolio Website with Jekyll (and Hosting it on GitHub) - Part 2

Layouts

Includes

Collections

Data Files

Conclusion

Creating a Portfolio Website with Jekyll (and Hosting it on GitHub) - Part 1

Repository Creation

Jekyll Installation

New Project

Dependencies Installation

Local Server Startup