Instaladores de Firma Digital de Costa Rica para GNU/Linux

Este proyecto de instaladores se ha creado en conjunto con Luis Zárate para facilitar la instalación de las herramientas necesarias de Firma Digital de Costa Rica en distribuciones GNU/Linux. Se trata de un desarrollo no oficial, creado voluntariamente para mejorar el soporte en diversas distribuciones este sistema operativo, inicialmente para Debian y Ubuntu y próximamente para Fedora, CentOS, openSUSE y Arch.

El mecanismo para instalar los instaladores se realiza mediante un repositorio. Esto permite facilitar la instalación de los paquetes y poder recibir actualizaciones de los mismos de la misma manera que el resto de software del sistema.

Los instaladores configuran el sistema para agregar confianza a los certificados de la jerarquía nacional en los diferentes programas que hacen uso de almacenes de certificados (NSS de Mozilla, OpenSSL, GnuTLS y Java), así como el controlador del lector de tarjetas y también el módulo para poder manejar la tarjeta de Firma Digital.

Basados en parte en las guías previas con diversas mejoras, se ha verificado que tras la instalación del paquete se pueden utilizar servicios de Firma Digital y se listan las autoridades de certificados de la jerarquía nacional en software como Mozilla Firefox, Mozilla Thunderbird, Chromium/Chrome, Evolution, Seahorse (contraseñas y claves) y aplicaciones Java.

Las instrucciones de instalación están disponibles en el sitio web

Ubuntu Testing Day wrap up - snapcraft and beers (20161216)

Today we had the last Ubuntu Testing Day of the year.

We invited Sergio Schvezov and Joe Talbott, to join Kyle and myself. Together we have been working on Snapcraft the whole year.

Sergio did a great introduction of snapcraft, and showed some of the new features that will land next week in Ubuntu. And because it was the last day of work for everybody (except Kyle), we threw some beers into the hang out and made it our team end of year party.

You can watch the full recording by clicking the image below.

Alt text

Snapcraft is one of the few projects that have an exception to land new features into released versions of Ubuntu. So every week we are landing new things in Xenial and Yakkety. This means that we need to constantly test that we are not breaking anything for all the people using stable Ubuntu releases; and it means that we would love to have many more hands helping us with those tests.

If you would like to help, all you have to do is set up a virtual machine and enable the proposed pocket in there.

This is the active bug for the Stable Release Update of snapcraft 2.24: bug #1650632

Before I shut down my computer and start my holidays, I would like to thank all the Ubuntu community for one more year, it has been quite a ride. And I would like to thank Sergio, Kyle and Joe in particular. They are the best team a QA Engineer could ask for <3.

See you next year for more testing days.

Test a stable release update

Ubuntu has a six month cycle for releases. This means that we work for six months updating software, adding new features and making sure that it all works consistently together when it’s integrated into the operating system, and then we release it. Once we make a release, it is considered stable and then we almost exclusively add to that release critical bug fixes and patches for security vulnerabilities. The exceptions are just a few, and are for software that’s important for Ubuntu and that we want to keep up-to-date with the latest features even in stable releases.

These bug fixes, security patches and exceptional new features require a lot of testing, because right after they are published they will reach all the Ubuntu users that are in the stable release. And we want the release to remain stable, never ever introduce a regression that will make those users unhappy.

We call all of them Stable Release Updates, and we test them in the proposed pocket of the Ubuntu archive. This is obviously not enabled by default, so the brave souls that want to help us testing the changes in proposed need to enable it.

Before we go on, I would recommend to test SRUs in a virtual machine. Once you enable proposed following this guide you will get constant and untested updates from many packages, and these updates will break parts of your system every now and then. It’s not likely to be critical, but it can bother you if it happens on the machine you need to do your work, or other stuff. And if somebody makes a mistake, you might need to reinstall the system.

You will also have to find a package that needs testing. Snapcraft is one of the few exceptions allowed to land in a stable release every week. So lets use it as an example. Lets say you want to help us testing the upcoming release of snapcraft in Ubuntu 16.04.

With your machine ready and before enabling proposed, install the version already released of the package you want to test. This way you’ll test later an update to the newer version, just what a normal user would get once the update is approved and lands in the archive. So in a terminal, write:

  $ sudo apt update
  $ sudo apt install snapcraft

Or replace snapcraft with whatever package you are testing. If you are doing it just during the weekend after I am writing this, the released version of snapcraft will be 2.23. You can check it with:

  $ dpkg -s snapcraft | grep Version
  Version: 2.23

Now, to enable proposed, open the Ubuntu Software application, and select Software & Updates from the menu in the top of the window.


From the Software & Updates window, select the Developer Options tab. And check the item that says Pre-released updates.


This will prompt for your password. Enter it, and then click the Close button. You will be asked if you want to reload your sources, so yes, click the Reload button.


Finally try to upgrade. If there is a newer version available in the proposed pocket for the packet you are testing, now you will get it.

  $ sudo apt install snapcraft
  $ dpkg -s snapcraft | grep Version
  Version: 2.24

Every time there is a proposed update, the package will have corresponding SRU bugs with the tag “verification-needed”. In the case of snapcraft this weekend, this is the bug for the 2.24 proposed update:

The SRU bugs will have instructions about how to test that the fix or the new features released are correct. Follow those steps, and if you are confident that they work as expected, change the tag to “verification-done”. If you find that the fix is not correct, change the tag to “verification-failed”. In case of doubt, you can leave a comment in the bug explaining what you tried and what you found.

You can read more about SRUs in the Stable Release Updates wiki page, and also in the wiki page explaining how to perform verifications. This last page includes a section to find packages and bugs that need verification. If you want to help the Ubuntu community, you can just jump in and start verifying some of the pending bugs. It will be highly appreciated.

If you have questions or find a problem, join us in the Ubuntu Rocket Chat.

Ubuntu Testing Day wrap up - Unity8 (20161209)

For the third session of the Ubuntu Testing Days, Kevin Gunn joined us to talk about the Unity8 snap.

This is a thriving project with lots of things to do and bugs to uncover, so it's the perfect candidate for newcomers eager to help Ubuntu.

If you are interested and didn't attend our meeting on Friday, click the image below to watch the recording.

Alt text

To install Unity 8 in the Ubuntu 16.04 cloned virtual machine that we prepared on the past session, enter the following commands in the terminal:

$ sudo add-apt-repository -u ppa:ci-train-ppa-service/stable-phone-overlay
$ sudo apt install unity8-session-snap
$ unity8-snap-install
$ sudo reboot

After reboot, on the login screen click the Ubuntu icon next to your user name and change the selection to Unity 8.

Kevin and his team have a google doc with the instructions to build and install the snap, and the current status. If you find a bug, you can talk to the developers joining the #ubuntu-touch IRC channel on freenode

While preparing the testing environment on this session we had a crash, and explained how easy it is to send the report to the Ubuntu developers by just clicking the Report problem... button. The reports from all our users are in the error tracker, along with a frequency graph and the links to bug reports where those crashes are being fixed.

We also showed two tricks to make faster and more pleasant the testing session in a virtual machine:

Thanks to Julia, Kyle and Kevin for the nice session.

Join us again next Friday at Ubuntu On-Air.

Set up a cache for deb packages

All Linux distributions are constantly updating the versions of the packages in their archives. That’s what makes them great, lots of people working in a distributed way to let you easily update your software and get the latest features or critical bug fixes.

And you should constatly update your operating system. Otherwise you’ll become an easy target for criminals exploiting known vulnerabilities.

The problem, at least for me, is that I have many many Ubuntu machines in the house and my badwidth is really bad. So keeping all my real machines, virtual machines and various devices up-to-date every day has become a slow problem.

The solution is to cache the downloaded deb packages. So only one machine has to make the downloads from the internet, and they will be kept in my local network to make much faster to get the packages in the other machines.

So let me introduce you to Apt-Cacher NG.

Setting it up is simple. First, choose a machine to run the cacher and store the packages. Ideally, this machine should be running all the time, and should have a good amount of storage space. I’m using my desktop as the cacher; but as soon as I update my router to one that runs Ubuntu, I will make that one the cacher.

On that machine, install apt-cacher-ng:

  sudo apt install apt-cacher-ng

And that’s it. The cacher is installed and configured. Now we need the name of this machine to use it on the other ones:

  $ hostname

In this example, calchas is the name of the machine I’m using as the cacher. Take note of the name of your machine, and now, in all the other machines:

  $ sudo gedit /etc/apt/apt.conf.d/02proxy

That will create a new empty configuration file for apt, and open it to be edited with gedit, the default graphical editor in Ubuntu. In the editor, write this:

  Acquire::http::proxy "http://calchas.lan:3142";

replacing calchas with the name of your cacher machine, collected above. The .lan part is really only needed when you are setting it up in a virtual machine and the host is the same as the cacher, but it doesn’t hurt to add it on real machines. That number, 3142, is the network port where the caching service is running, leave it unchanged.

After that, the first time you update a package in your network it will be slow just as before. But all the other machines updating the same package will be very fast. I have to thank apt-cacher-ng for saving me many hours during my updates of the past years.

Ubuntu Testing Day wrap up - 20161202

We have survived two testing days, and now we can safely say that it will become a Friday tradition :)

Last Friday our nice guest was Aaron Ogle, from Rocket Chat. He gave us a tour on the Rocket Chat UI and we discussed about how they packaged it as a snap.

If you missed it, click the image below to watch it.

Alt text

Building from what we saw on the first session, we tested the snap using a virtual machine again. But this time, we cloned it to keep a pristine machine and make following testing sessions faster. If you want to help the Ubuntu and Rocket Chat communities, this is an easy way to prepare your environment:

Once you have your clone ready, install the most recent and bleeding edge version of rocket chat with:

$ sudo snap install rocketchat-server --edge

Then you can follow this gist with the initial steps to start testing the Rocket Chat snap

Also you can test a real installation of Rocket Chat, joining our community channel, where we are available all day, every day. If you have a question, just ask. I am elopio in there.

During the session we took a look at the GitHub website, where many free software communities do their development in the open. They have a great guide to start contributing to open source projects. Go on and spread your love for free software in the form of bug reports :)

The gratitude this week goes to our newly acquired staff members Julia and Kyle, and of course to Aaron for letting us have a funny Friday evening. Make sure to take a look at the cool things he and his teammates are doing; and if you have some free time and want to join an exciting, open and nice community, give them a hand. Also try the Jitsi integration for video conference, it's mind-blowing that there are no closed components anywhere.

See you next Friday at Ubuntu On-Air.

Clone virtual machines to keep a pristine image

The basic idea of using virtual machines for testing is to always start from a clean state, as close as possible to what a user would get after freshly installing the system on their real machines.

So, every time we need to test something, we could create a new virtual machine and intall Ubuntu from scratch there, but that would take a considerable amount of time.

An alternative is to install a machine once, and keep it clean. Never test in that one, and instead clone it every time you need to test something. Use the clone to experiment, and delete it when you are done. Cloning the machine is a lot faster than reinstalling each time. The base machine, the one you clone everytime, is called a pristine machine. If you are careful with it, the only time you will need to reinstall is when you are testing the installer.

Cloning the pristine machine using Virtual Machine Manager is really simple, it’s done in like two clicks.

First, of course, you will need to install your pristine machine. I always put pristine in the name, to make it less likely that I will start using it for testing. Every time I forget and play with the pristine machine, I’m polluting its state, and have to recreate it.

With the pristine machine ready, I then recommend to open it and run in a terminal:

  sudo apt update && sudo apt upgrade

That will update all the packages installed, so your clone starts also in the most up-to-date state. If you do this step every time, you will never have to wait for long while your machine downloads and installs lots of packages, just wait a little every day.


Now shut down the pristine machine and don’t touch it again, only to update it.

To clone it, right click on it and then click the Clone... button.


A dialog will be opened, where you can enter the new virtual machine details.


I always write the date as part of the name, to remember when I created it. But the most important thing to do here is to make sure that the Storage option is set to Clone this disk. Otherwise, you will be sharing the disk with the pristine machine, which will pollute its state, the exact thing we are trying to avoid.

This will take some time while the whole disk is copied. But not long, and once it’s done you can freely play and pollute this clone, without affecting the pristine machine.

Ubuntu Testing Day wrap up - 20161125

Today we had our first testing day. We will keep doing this every Friday, and at the end of the session I will post a summary with links to follow up and learn more about the subject in case somebody is interested.

You can watch the video by clicking the image below.

Alt text

For this session we had Kyle Fazzari talking about his work as the maintainer of the Nextcloud snap.

You can find more info about the project in the Nextcloud main page and more info about the snap in Kyle's blog.

We tested the snap using a virtual machine. To set one up you can use the following guides:

After the virtual machine is ready, Nextcloud can be installed in there by just running in the terminal:

$ sudo snap install nextcloud

If you want to test an unreleased and unstable version to help the Nextcloud developers, you can add the flag --edge or --beta to that command.

I wrote some steps to guide you getting started with the testing in this gist.

And finally, if you want to join our community, we are usually in Rocket Chat. You can join the #community, #qa or #snapcraft channels, or any other that catches your attention.

Special thanks to Julia and CoderEurope for joining us during the session. And of course to Kyle and the Nextcloud community for this amazing piece of free software that encourages everybody to take control over their data, in a really simple way.

You are all invited to join us the next time, which will be Friday, December 2nd, again at Ubuntu On-Air. The time and theme will be announced soon. Or at least before it starts.

Install Ubuntu in a virtual machine

There are multiple ways to test Ubuntu. The most simple, and most dangerous is to just use your real Ubuntu machine to install and try things. I wouldn’t recommend this one to begin with, because we will be using experimental software that it’s likely to completely break your operating system every now and then.

This is not so terrible. Unless you are dealing with low-level stuff, the worst case scenario will be solved by reinstalling Ubuntu. And usually it won’t even come to that. My machines always have the unreleased unstable version of Ubuntu, and I’m often learning interesting things by trying to recover the mess I make. But let’s not get to that yet, let’s first see other options.

My preferred way to test graphical applications is to use Kernel-based Virtual Machine (KVM) and Virtual Machine Manager hosted on my real machine. A virtual machine emulates a real machine. It is completely isolated from the host where it runs, so you can freely experiment in it without the risk of breaking a machine that you will later need for something else. If things go crazy, just throw away the virtual machine and start again. The downside is that it’s slower than testing in some of the alternatives, like LXC or Docker. But I like it because it gives me an environment that’s really close to what a user would get when he installs Ubuntu on his machine. Also it’s really simple with the Virtual Machine Manager.

For this I’m going to assume that you have a machine with Ubuntu already. If you don’t have one, you can follow this guide to install Ubuntu by yourself, or you can contact somebody from your Local Community Team using the LoCo Portal. There’s always somebody who would like to meet and help a new Ubuntero or Ubuntera to get started. And in case of doubt, just ask your question in Ask Ubuntu and you will get quick help there too.

To install everything, let’s open a terminal, like Mr. Robot. Click the Ubuntu icon on the top-left of the screen, type terminal and click on the first result.


Many of the things we do with commands in the terminal can also be done using graphical applications. The terminal might seem overcomplicated at first, but soon you will notice that it’s easier to get lost trying to click buttons. In here we will do both; for some things I like commands, for some I like buttons. However, the first rule is to never enter a command that you don’t understand; and you should be specially suspicious if the command asks for your password. If you don’t understand what you are doing, search and ask.

Now, on the terminal, type:

  sudo apt install qemu-kvm libvirt-bin bridge-utils virt-manager

And press enter.

sudo is the command to execute other commands as a super user. You will need super user permissions to do administrative actions on the machine, like installing new software. apt is used to manage packages. So in here we are telling the machine to install 4 packages using apt as an administrator. The 4 packages are the software we will use to create and manage virtual machines.

The first thing that sudo will do is to ask for your password.


Again, make sure that you are only following command line instructions from a trusted source, like me ^_^ And make sure that you know what you are doing before pressing enter.

Type your user password in the terminal and press enter. The password will be hidden so nobody else can see it while you are typing it, but don’t worry, after pressing enter the command will proceed with the installation.

You will know that it finished because you will be presented with a prompt again, something like user@machine:~$ which indicates that the terminal is ready to receive a new command.

Now let’s jump back to the graphical user interface. Click again the top-left Ubuntu icon, type virtual machine manager and click the first result.

The Virtual Machine Manager window will be opened. So let’s create a new machine clicking the top-left shiny icon.


This will open a dialog to choose the installation method. We will install Ubuntu from an ISO image file. If you don’t have one, you can follow the previous guide to download the latest Ubuntu version with Long Term Support. Once you get it, select the Local install media option and click the Forward button.


In the next dialog page, click the Browse button, which will open a new dialog. In the new one, click Browse Local, which will open yet another dialog where you should select the downloaded Ubuntu ISO file (and now you see why I said that the command line was often easier :) Back at the first dialog, clilck the Forward button.


Next step is to select the amount of resources that you want to give to this virtual machine. If you give it a lot of resources, it will be faster, but then your real machine will be slower. So you have to balance both, another downside of using full virtual machines instead of ligher ways to simulate a machine. For your first machine, maybe just leave the default values. Pay attention at how the virtual and real machine feel, and next time choose a different value to compare.


So, Forward one more time and now we can choose the size of the disk of the virtual machine. I have found that 20GiB is generally enough, and you will throw away your machine long before you fill the space. Less than that and you will likely get the disk full and will have to resize it, which is kind of boring. I will paste the command for that some other day. Forward!


And this is the last step, at least for this post. Enter a name for the virtual machine and click Finish.

Here the interesting part begins, finally. You will see the virtual machine booting, just like a real one does. It will start the live Ubuntu system, which runs from volatile memory, so you have to install it in the hard disk of the virtual machine to make it permanent. And then again, as it emulates a real machine, the steps to install Ubuntu in a virtual machine are the same to install it in a real one, so the same guide to install a desktop machine that I linked earlier will be useful.

Once the virtual machine reboots, take some time to play with the user interface of Virtual Machine Manager. You will find controls to start, shutdown and reset the machine, and some more advanced options to change the hardware it is emulating. Remember that you can’t break your real machine, so play, make a mess, and start again.

If you want to learn some more about Ubuntu, and collaborate with the community, join us in the Ubuntu Testing Days, every Friday in Ubuntu On Air. We will use virtual machines and other tools to test cool free software projects.

Download the latest Ubuntu LTS

The Ubuntu Long Term Support (LTS) version is released every two years, on April; and it is supported for five years. So this version has to be super stable, it’s what most of our users have installed in their machines, and it often gets security fixes and some other stable release updates.

All of this means that it always needs to be tested, and by as many hands and on as many different machines as possible. If you want to start helping the Ubuntu community, I would suggest that testing the latest LTS is the place to start. There will be so many people around the world that will be positively affected by this work, and all of them will sincerely appreciate it. Well... not all of them, but most of them for sure :) I for one will invite you to a beer when you come for holidays to Costa Rica.

While testing Ubuntu you will learn about the many different aspects that build a free operating system. Then you can jump to collaborate in other areas that pique your interest, like support, programming, translations, packaging, planning, partying, etc. Or you can stay helping with the tests, maybe in some more unstable and rapidly changing projects.

This is the first post of a series I will write about contributing to different areas of Ubuntu. They will focus mostly on testing because that’s what I enjoy the most. And in addition, we will meet live every Friday on Ubuntu On-Air to explore cool free software projects and help the developers on their way to a stable release.

Let’s begin. The first thing you will have to do if you want to join our community is to download Ubuntu. To do that open your browser and go to

Click the Ubuntu Desktop link, or the download button next to it.


There are other different versions of Ubuntu. Newer and older releases, different user interface flavors, smaller versions for servers and connected devices, and some for specific phones and tablets. We will see some of them in following posts and meetings, but for now we will start with the basic and most common.

The next step shows you the recommended requirements that a machine should meet to run this Ubuntu version properly. Make sure that you have all of them and click the Download button.


This opens a page for optional donations. If you feel generous, you can give some money to the community and decide where it should be spent. If you can’t or don’t want to give any money, no problem, just click the link that says: Not now, take me to the download. Beers, hugs, bugs are all valid payment methods too.


And that’s it. A dialog should appear offering you to download the file. Make sure to choose the option to save it into your disk, and take into account that if you use a different browser than mine, your dialog might look different.


This was a first simple step. If it was too simple for you, don’t worry, next time we will do a few more complicated things. If on the other hand you got lost somewhere, also don’t worry because we will be around to answer any kind of doubts.

In both cases, come and join us next Friday, November 25th at 18:00 UTC on our first Ubuntu Testing Day! We will use this image to test the awesome Nextcloud snap. Kyle Fazarri has been making some great work to package Nextcloud for everybody, and he will be joining us to show off and answer questions.