Kushal Das

FOSS and life. Kushal Das talks here.

kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion

Announcing lymworkbook project

In 2017, I started working on a new book to teach Linux command line in our online summer training. The goal was to have the basics covered in the book, and the same time not to try to explain things which can be learned better via man pages (yes, we encourage people to read man pages).

Where to practice

This one question always came up, many times, the students managed to destroy their systems by doing random things. rm -rf is always one of the various commands in this regard.

Introducing lymworkbook

Now, the book has a new chapter, LYM Workbook, where the reader can set up VMs in the local machine via Vagrant, and go through a series of problems in those machines. One can then verify if the solution they worked on is correct or not. For example:

sudo lymsetup copypaste
sudo lymverify copypaste

We are starting with only a few problems, but I (and a group of volunteers) will slowly add many more problems. We will also increase the complexity by increasing the number of machines and having setup more difficult systems. This will include the basic system administration related tasks.

How can you help

Have a look at the issues, feel free to pick up any open issue or create issues with various problems which you think are good to learn. Things can be as easy as rsync a directory to another system, or setting up Tor Project and use it as a system proxy.

Just adding one problem as an issue is also a big help, so please spend 5 minutes of your free time, and add any problem you like.

tunir 0.7 is out

Today I have released Tunir 0.7. Tunir is a simple CI which developers can even use in their laptops. There are few major changes in this release. The first one is about no database support. Tunir itself will not save any data anywhere, this also means --stateless command line argument is now unnecessary. Even if you do not pass that option, tunir will print out the output of the tests on STDOUT.

Second, and the biggest change is the ability to test on Vagrant boxes using vagrant-libvirt plugin. On a Fedora 22 system, you can install vagrant by the following command.

$ sudo dnf install vagrant-libvirt

The following is an example job configuration on Vagrant. This of course assumes that you have already downloaded that box file somewhere in the local filesystem. In case you have not noticed, we are now generating vagrant images for both Cloud base, and Atomic image in Fedora Project. You can download them from here.

{
  "name": "fedora",
  "type": "vagrant",
  "image": "/home/Fedora-Cloud-Atomic-Vagrant-22-20150521.x86_64.vagrant-libvirt.box",
  "ram": 2048,
  "user": "vagrant",
  "port": "22"
}

I have already built the rpms for Fedora, they are right now in the testing repo.

storage volume error in libvirt with Vagrant

I was working on adding Vagrant based tests in tunir, and hit an issue without any informative error message.

$ sudo vagrant up
Bringing machine 'tunirserver' up with 'libvirt' provider...
/usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/tmp/orbit-kdas' (Libvirt::RetrieveError)
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `volume_to_attributes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:10:in `block (2 levels) in list_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `each'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `block in list_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:44:in `block in raw_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `each'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `raw_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:8:in `list_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/models/compute/volumes.rb:11:in `all'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:43:in `block in call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `synchronize'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:24:in `block in call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `synchronize'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/set_name_of_domain.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
    from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
    from /usr/share/vagrant/lib/vagrant/action/builtin/call.rb:53:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
    from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
    from /usr/share/vagrant/lib/vagrant/machine.rb:214:in `action_raw'
    from /usr/share/vagrant/lib/vagrant/machine.rb:191:in `block in action'
    from /usr/share/vagrant/lib/vagrant/environment.rb:516:in `lock'
    from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `call'
    from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `action'
    from /usr/share/vagrant/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

Found a bug, but that did not give any information on how to fix it. Then in the middle of night (around 1am) Dusty Mabe gave the right solution :). I have to refresh all the available storage pools in libvirt. It had nothing to do with Vagrant, but I wish that the error message was a little bit less cryptic. In my case I did the following.

$  sudo virsh pool-list
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 tmp                  active     yes 

Then refreshing each pool manually.

$  sudo virsh pool-refresh tmp
Pool tmp refreshed
$  sudo virsh pool-refresh default
Pool default refreshed