Child pages
  • Welcome to the Wiki of
Skip to end of metadata
Go to start of metadata


Hey there, my name is Alex and this is my Wiki. 

I'm currently interested in all things about Leadership, DevOps and craft beer brewing.   

Feel free to browse my blog posts (on the right), or any of the Wiki articles below. You can also browse via space links on the left.

Latest wiki updates

OS-Installationen in einer KVM VM können auf einem entfernten Linux Server (z.B. dedizierter oder Rootserver) ziemlich nervig sein. Besonders dann, wenn man per Konsole nicht in die VM zugreifen kann. Dann bleibt nur noch das alte VNC-Protokoll. Und das von einem Mac via Screen Sharing App nutzen zu können, erfordert eine entsprechende Konfiguration. 

Ohne Passwort wird's nix

Die Screen Sharing App unter MacOS funktioniert, mindestens mit der KVM VM als VNC Server, nur mit einem Passwort. Ohne Passwort kann man zwar eine Verbindung herstellen, allerdings wird der Bildschirm nicht angezeigt.

KVM VM Konfiguration

Die QEMU KVM Konfiguration der VM erfolgt durch eine XML-Datei in /etc/libvirt/qemu/ , z.B. für eine Rancher VM  rancher.xml. Um VNC für die VM zu aktivieren und mit einem Passwort zu versehen, muss folgende Zeile eingefügt werden:

<graphics type='vnc' port='-1' autoport='yes' passwd='DEIN-PASSWORT' />

Eine vollständige Konfiguration kann z.B. dann so aussehen:

<domain type='kvm'>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static'>1</vcpu>
    <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
    <boot dev='cdrom'/>
    <boot dev='hd'/>
  <clock offset='utc'/>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/vg0/rancher_root'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/isos/rancheros.iso'/>
      <target dev='hdc' bus='ide'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    <interface type='bridge'>
      <mac address='52:54:00:54:b7:66'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    <serial type='pty'>
      <target port='0'/>
    <console type='pty'>
      <target type='serial' port='0'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' passwd='passwort'/>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>

Dann klappt's auch danach über ein SSH Portforwarding mit dem Zugriff auf die VM. Also, immer schön Passwörter für die VNC-Verbindung setzen (smile)

Eine virsh console Sitzung kann mit einem deutschen Tastaturlayout auf einem Mac im Terminal genauso beendet werden, wie eine telnet Sitzung:


So, und jetzt geht's endlich nicht mehr vergessen (smile)

The problem

You want to preserve your dotfiles for the future, and most likely also want to distribute them among different machines and accounts, but keeping them in sync as well. For this, nowadays it's common practice to manage your dotfiles in a git (or some other) version control system.

Now, in the beginning it may be easy to simply push some .'s to your simple git repository. As your dotfiles grow, there may come the time, that you want to differentiate them a little bit, like having a gitconfig for work and for your private git fun. Now things can start to get more complex from this point, as this scenario for example requires you to have either multiple gitconfigs with some duplicated lines, or use some 'fancy' script with some if-else-logic to include/exclude certain lines.

The solution - dots, the dotfiles management utility

dots fixes this issue through the following features:

  • Configuration groups
    When installing your dotfiles onto a new machine, dots offers you the ability to select a specific 'group' of dotfiles that you would like to have installed into that environment. By organizing dotfiles into logical groups (such as 'machine' groups) it's possible to only install the dotfiles that are required by that environment.
  • Cascading file structure
    By selecting multiple configuration groups there is the possibility that two groups both contain a dotfile with matching names. For example, if two configuration groups both contain a bashrc file then the dots utility will automatically merge these two files together. A special syntax is also offered to allow for one file to override another or for the cascading files to be merged into the files at specific points.
  • Installation time includes
    Some configuration file formats do not support a way to natively 'include' other configuration files into them. The dots utility allows for files to be inserted into a specific configuration file using a special include syntax (Known as "explict named append points"). The included file will also follow the cascading file structure previously mentioned.
  • Follows XDG Base Directory Standard
    The XDG Base Directory Standard specifies that all configuration files should be located in the $XDG_CONFIG_HOME directory. By default, this is where all configuration files and directories will be installed. While this does require a little extra work to ensure all programs read their configuration files from here it offers a much more organized view of user dotfiles.

Getting started

First of all, we clone the dots repository from Github:

cd ~ && git clone dotfiles

After that, you should create your own dotfiles repository on Github (or some other git hosting website). I created mine on Github and named it 'dotfiles'. It is wise to change the remote repository, where all your changes shall be pushed to your newly created dotfiles repo. You can do it like so:

git remote add upstream

This has the advantage that you can still fetch updates from the original 'dots-template' repository like this:

git pull origin master

while still pushing & pulling on your own repo as you're probably familiar with.

Now starts the real fun. First of all, you should edit the and push it back to your repo:

git add
git commit -m "From template to personal readme"
git push -u upstream master

After that, you probably want to add some dotfiles to your dotfiles repository.

Adding your bin's

The most easiest task is probably adding your personal bins to the repository. All binaries that shall be available on all machines can be placed in the base directory:

cp -r ~/bin ~/dotfiles/base

Then commit with git, of course:

cd ~/dotfiles && git add . && git commit -m "Added public bins"

Cascading gitconfig

to be continued...

  • No labels
Write a comment…