quarta-feira, 21 de fevereiro de 2018

Creating custom ISO images for Fedora, CentOS or RHEL

TL;DR: This post is about creating custom ISO images with custom made RPM packages.

Motivation: My motivation was VERY specific. I had to debug a package that had an issue only on first execution after a fresh clean installation - https://bugzilla.redhat.com/show_bug.cgi?id=1518498. This means I had to create a new package and include it on a new custom ISO image every time I wanted to debug a new line or test a new solution.

Also, during the course of this, I faced error messages like:

09:58:3,721 DEBUG packaging: Member: hypervkvpd.x86_64 0:0-0.32.20161211git.e17 - u

09:58:3,727 ERR packaging: Error populating transaction after 10 anaconda retries: 
failure: Packages/hypervkvpd-0-0.32.20161211git.e17.x86_64.rpm from anaconda: 
[Errno 256] Mo more mirrors to try

09:58:3,727 DEBUG packaging: file:///run/install/repo/Packages/hypervkvpd-0-0.32.
20161211git.e17.x86_64.rpm: [Errno -1] Header is not complete.

The trick is very simple, first create your RPM package - here I assume you already know how to do that. Make sure your package has the same name and same dependencies than the one you want to replace. After that, you're ready to start building the new custom ISO image:

1. Download and mount the ISO image you want to customize:
# mount -t iso9660 -o loop RHEL-7.5-20180206.n.0-Server-x86_64-dvd1.iso temp/

2. Create the root directory for the new ISO image:
# mkdir iso_build

3. Copy everything from the original ISO to your newly created root directory:
# cp -pRf temp* iso_build/

4. Place your newly created RPM inside the iso_build/Packages/ directory;

5. Remove all hash data from repodata/ directory, but KEEP the comps file:
# rm -rfv repodata/*.gz repodata/*.bz2;

6. Create the new repository hash information, using as a reference the old comps file you didn't delete:
# createrepo /root/iso_build/Packages -g /iso_build/repodata/ -o /iso_build/ \
-u file:///run/install/repo/Packages/;

7. From inside iso_build/, generate the new ISO image:
# genisoimage -U -r -v -T -J -joliet-long -V 'RHEL-7.5 Server.x86_64'         \
-volset 'RHEL-7.5 Server.x86_64' -A 'RHEL-7.5 Server.x86_64'                  \
-b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot                   \
-boot-load-size 4 -boot-info-table -eltorito-alt-boot                         \
-e images/efiboot.img -no-emul-boot -o /RHEL-7.5-DEBUG-Server-x86_64-dvd1.iso .

Enjoy your debugging.

sexta-feira, 9 de fevereiro de 2018

QEMU Sandboxing for dummies

DevConf is an annual conference that takes place in Brno, Czech Republic. This year I applied for a talk to go over my work that I develop since mid 2012: Security on QEMU/KVM Virtual Machines using SECCOMP. Since then I became the maintainer of this feature on QEMU and released the second and better version not long ago. On this post you'll find the slides and the full video of the presentation.

So here we go, very first experience lecturing in English, what a catastrophe! In my defense the audience was very peculiar, not only the guy that very started libseccomp was there, but my manager and the director of the department as well. Anxiety apart, I think it was an outstanding experience, would do it again in the future. :-)

sexta-feira, 19 de janeiro de 2018

Xen synchronicity between frontend and backend devices

So I bumped into a problem last month and it took me too much time to figure out the big picture of the problem since I didn't find too much documentation about that. The help I could find when trying to figure out this was mostly from good people on the channel #xendevel @ Freenode, mostly maintainers. So if you want to understand a little bit of Xen without pinging people on IRC, that's the place.

The problem is the following: I'm running RHEL on Xen Hypervisor and whenever I try to unload and reload xen_netfront kernel module I see outputs like that on dmesg:
# modprobe -r xen_netfront

# dmesg|tail
[ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
[ 105.236839] deferring g.e. 0x903 (pfn 0x35805)
[ 105.237156] xen:grant_table: WARNING: g.e. 0x904 still in use!
[ 105.237160] deferring g.e. 0x904 (pfn 0x35804)
[ 105.237163] xen:grant_table: WARNING: g.e. 0x905 still in use!
[ 105.237166] deferring g.e. 0x905 (pfn 0x35803)
[ 105.237545] xen:grant_table: WARNING: g.e. 0x906 still in use!
[ 105.237550] deferring g.e. 0x906 (pfn 0x35802)
[ 105.237553] xen:grant_table: WARNING: g.e. 0x907 still in use!
[ 105.237556] deferring g.e. 0x907 (pfn 0x35801)

Moreover, the interface is not usable as well:

# dmesg|tail
[ 105.237163] xen:grant_table: WARNING: g.e. 0x905 still in use!
[ 105.237166] deferring g.e. 0x905 (pfn 0x35803)
[ 105.237545] xen:grant_table: WARNING: g.e. 0x906 still in use!
[ 105.237550] deferring g.e. 0x906 (pfn 0x35802)
[ 105.237553] xen:grant_table: WARNING: g.e. 0x907 still in use!
[ 105.237556] deferring g.e. 0x907 (pfn 0x35801)
[ 160.050882] xen_netfront: Initialising Xen virtual ethernet driver
[ 160.066937] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 160.067270] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 160.069355] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready

# ifconfig eth0
eth0: flags=4098 mtu 1500
ether 00:00:00:00:00:00 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

# ifconfig eth0 up
SIOCSIFFLAGS: Cannot assign requested address

The first problem happens because the backend part of the module (xen_netback) is still using some pieces of memory (g.e. which states for grant entries) that are shared between guest and host. The ideal scenario would be to wait for the netback to free those entries and only then unload the netfront module. This was actually a bug on the synchronicity of the netfront and netback parts.

The state of the drivers are kept in separate structs, as defined in include/xen/xenbus.h:69:

/* A xenbus device. */
struct xenbus_device {
    const char *devicetype;
    const char *nodename;
    const char *otherend; 
    int otherend_id;
    struct xenbus_watch otherend_watch; 
    struct device dev;
    enum xenbus_state state;
    struct completion down;
    struct work_struct work; 

And the netfront state can be seen from the hypervisor with the command:

# xenstore-ls -fp
/local/domain/1/device/vif/0/state = "4" (n1,r0)

The number 4 indicates XenbusStateConnected (as defined in include/xen/interface/io/xenbus.h:17). So it means everything is a matter of wait for one end to finish using the memory region and the other to free, this first piece of the puzzle is solved by this patch:

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8b8689c6d887..391432e2725d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,8 @@ struct netfront_cb {
 /* IRQ name is queue name with "-tx" or "-rx" appended */
+static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
 struct netfront_stats {
        u64                     packets;
        u64                     bytes;
@@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbus_device *dev,
        case XenbusStateClosed:
+               wake_up_all(&module_unload_q);
                if (dev->state == XenbusStateClosed)
                /* Missed the backend's CLOSING state -- fallthrough */
        case XenbusStateClosing:
+               wake_up_all(&module_unload_q);
@@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_device *dev)
        dev_dbg(&dev->dev, "%s\n", dev->nodename);
+       if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
+               xenbus_switch_state(dev, XenbusStateClosing);
+               wait_event(module_unload_q,
+                          xenbus_read_driver_state(dev->otherend) ==
+                          XenbusStateClosing);
+               xenbus_switch_state(dev, XenbusStateClosed);
+               wait_event(module_unload_q,
+                          xenbus_read_driver_state(dev->otherend) ==
+                          XenbusStateClosed ||
+                          xenbus_read_driver_state(dev->otherend) ==
+                          XenbusStateUnknown);
+       }

The second piece of the problem is that the interface is not usable when reloaded back. And that's a lack of initializing the state of the device so the backend notices it, and hence, connects the two drivers together (frontend and backend). This was easily solved by the following patch:

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index c5a34671abda..9bd7ddeeb6a5 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1326,6 +1326,7 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
+       xenbus_switch_state(dev, XenbusStateInitialising);
        return netdev;

sexta-feira, 6 de novembro de 2015

Save radio shows in podcasts so you can listen later!

The story behind this project is that, since I moved to Germany I miss some old news shows on the radio that I use to listen in Brazil. Yeah, I know I can listen to them online. But due to the difference on the timezone, sometimes I just don't want to listen to it while I have my lunch, or work. Saving them into a podcast is much easier and gives me the freedom to listen whenever I want.

The idea is pretty simple: Use ffmpeg to save the stream online, copy it to your podcast server and enjoy. Let's work to put everything together:

First thing you're gonna need is some scripts. The first one captures the stream of audio and dumps into a ts file:

otubo@deathstar /opt/ $ cat capture_stream.sh 

TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S");
/usr/bin/ffmpeg -i URL -c copy /opt/radio_show_${TIMESTAMP}.ts

Next, you're going to need a script to encode the transport stream into mp3:

otubo@deathstar /opt/ $ cat encode_stream.sh 

LAST_TS_FILE="$(ls -1t /opt/|grep ts|head -1)"
NEW_MP3_FILE="$(echo $LAST_TS_FILE|sed -e 's/ts/mp3/g')"
/usr/bin/ffmpeg -i "${LAST_TS_FILE}" -acodec mp3 -write_xing 0 "${NEW_MP3_FILE}"
/usr/bin/id3 -t "$(date)" "${NEW_MP3_FILE}"
/usr/bin/id3 -a "News" "${NEW_MP3_FILE}"
wget -O- http://GENERATOR SERVER ADDR/html/pg-cron.php?key=YOUR KEY >/dev/null 2>&1
rm "${LAST_TS_FILE}"

Little gotcha: I had this issue with the iPhone podcast app, according to this ticket, adding the option -write_xing 0 solves the problem.

Note that in the last script, there's the "Podcast Generator" server. That's a really neat and simple to use podcast server made with php5. You can download it here: http://podcastgen.sourceforge.net/. The instructions to install and configure are very easy, and as they say: Newbie-proof.

Let's dig down a little bit on the last script: First you run ffmpeg to convert the transport stream into mp3, then you set the title id3 tag for the title of this podcast "episode", than set the artist id3 tag for the description. After that you call wget to reload your podcast library and update the RSS. And it's done!

Now let's put everything on the crontab:

30 10 * * * /opt/capture_stream.sh
2  12 * * * killall -9 ffmpeg
3  12 * * * /opt/encode_stream.sh

Easy and simple: The show starts at 10:30 (my germany time) and ends at 12h00 (I added 2 more minutes, just in case). Three minutes after the dump is finished I start the encoding script. And that's all! Podcast generator also gives you RSS url to put on your smartphone. Pretty easy :D

RetroPie: Play snes games on your Raspberry Pi!

So I wanted to play some old Super Nintendo games and also share this special retro gaming style with my daughter. So I decided to put it on my Raspberry Pi and have some fun. So let's do it!

The process is pretty easy, but the controllers configuration are a little tricky. Follow this guide to install RetroPie on an SD card and boot up your Raspberry Pi. This documentation explains everything you need to know about configuring wifi, setting up everything to have all up and running.

Now to the controller configuration:
I bought two ordinary snes controllers, they work pretty fine. The configuration is done via the file /opt/retropie/configs/all/retroarch.cfg, find this file and open it with your favorite text editor. Now find the input_player and erase everything related to it and make it look like this:

input_device_p1 = "0"
input_libretro_device_p1 = "0"
input_player2_analog_dpad_mode = "0"
input_player1_joypad_index = "0"

input_player1_b_btn = "2"
input_player1_y_btn = "3"
input_player1_select_btn = "8"
input_player1_start_btn = "9"
input_player1_up_axis = "-1"
input_player1_down_axis = "+1"
input_player1_left_axis = "-0"
input_player1_right_axis = "+0"
input_player1_a_btn = "1"
input_player1_x_btn = "0"
input_player1_l_btn = "4"
input_player1_r_btn = "5"

input_device_p2 = "1"
input_libretro_device_p2 = "0"
input_player2_analog_dpad_mode = "0"
input_player2_joypad_index = "1"

input_player2_b_btn = "2"
input_player2_y_btn = "3"
input_player2_select_btn = "8"
input_player2_start_btn = "9"
input_player2_up_axis = "-1"
input_player2_down_axis = "+1"
input_player2_left_axis = "-0"
input_player2_right_axis = "+0"
input_player2_a_btn = "1"
input_player2_x_btn = "0"
input_player2_l_btn = "4"
input_player2_r_btn = "5"

input_enable_hotkey_btn = "8"

input_exit_emulator_btn = "9"

This is all you're going to need to make those USB controllers work. If you bought a different controller, you can try to configure them using this command:

sudo ./retroarch-joyconfig -j 1 -p 2 >> /opt/retropie/configs/all/retroarch.cfg

This will interactively ask you to push every button in order to map it to the correct values. Always remember to double check your /opt/retropie/configs/all/retroarch.cfg to avoid duplicates, this got me in trouble for quite some time.

After that, you can copy all your ROM files into /home/pi/RetroPie/roms/snes, or if you have ROMs for different console, just copy into the correct folder.

That's it. Enjoy :D

segunda-feira, 8 de junho de 2015

GSM bridge between two raspbx hosts

Disclaimer: I know there's a lot of options on the market for free long distance calls like Skype, Viber, WhatsApp and so on. The goal of this personal project was all along to come up with a proof of concept that actually works, study something different other than my actual job and, why not, have some fun :) BUT, yes, there's one single use case that this setup will be useful: You're in the middle of nowhere, no internet connection and you need to call someone in the other side of the planet but you don't want to pay a long distance call: BINGO!

Disclaimer2: For this tutorial you'll have to be prepared for Asterisk terminologies like trunks and channels. If you're not familiar with this vocabulary, please take a quick look at this documentation.

Description of the environment: The server1 is placed on the Brazilian side. It's a Raspberry Pi model B that runs an asterisk-modded-for-raspberry-pi distro called raspbx. Attached to it there's an USB GSM dongle with a SIM card for the local Brazilian operator. In the same network of my server1 there's a Cisco PAP2t Internet Phone Adapter and, attached to it, a regular land line telephone. The same setup is duplicated on the German side, except that the Raspberry Pi is model B+.

What it does: This is the list of features that this project performs right now:
  1. Someone in Brazil calls my Brazilian number, the dongle1 answers the call, redirects to an IAX2 trunk directly to server2. The server2 takes this incoming call and uses the dongle2 to place a new call to my german cellphone. The other way is still pinned to a single phone -- like, call my dongle2 to reach a single number in Brazilian side -- but improvements are coming.
  2. Someone uses phone1 on Brazilian side to call extension phone2 on German side (and vice-versa) like a regular landline phone.
  3. Someone uses phone1 or phone2 to reach my german cellphone.

Ok, so LET'S DO IT!!

I'm gonna skip the PAP2t configuration because I think it's too much. This is only needed if you want to use land line telephones, it's not required for the GSM bridge. If anyone is interested in doing that, please leave a comment and I'll write a new post only for that configuration.

Important note: All the configuration explained from now on is identical on both servers.
  1. Install raspbx on your RPi's SD card. Also take a time to read through the raspbx documentation, which is very useful
  2. Use the script install-dongle (built-in inside raspbx) to install your dongle on your RPi. Important notes regarding problems I got:
    1. There's a list of GSM dongles that are tested with voice, SMS and USSD. I bought the Huawei E160;
    2. I had to unlock the voice feature with DC-Unlocker for Windows;
    3. Plug your dongle and only after that plug your RPi power. If you try to plug your dongle while the RPi turned on, you may experience your RPi to reboot due to power consumption failures;
    4. If your RPi starts rebooting it's because it can't handle the gsm dongle power consumption, in this case, use a proper powered USB hub. I bought the D-Link Dub-H7
    5. Find out the IMEI and the IMSI code of your dongle and set the correct values under /etc/asterisk/dongle.conf because /dev/ttyUSB1 or /dev/ttyUSB2 may change;
  3. Before you start configuring raspbx itself, it's important that you have both sides with network configured properly with static IPs and (in my case) DynDNS. I didn't want to open too many ports on the routers on both sides so I just setup an OpenVPN vpn; 
  4. Setup a new custom trunk for your dongle under Connectivity  Trunks  Add Custom Trunk and set these values:

    Trunk Name: to-my-cellphone
    Outbound CallerID: Your SIM card number with country code (with a plus sign at the beginning)
    Custom Dial String: dongle/dongle0/$OUTNUM$

    Note: This is the trunk that will actually place the inbound calls to your personal telephone.

  5. Setup a new IAX2 trunk under Connectivity  Trunks  Add IAX2 Trunk and set these values:

    General Settings:
    Trunk Name: Something that would remember the incoming connection from the other server
    Outbound CallerID: Your personal phone number

    Outgoing Settings:
    Trunk Name: (same as above, I also used the same name and it's ok)

    host=static IP under vpn of the remote server
    username=any username
    secret=any password

    Note: The IAX2 trunk is responsible for redirecting calls from this server to the other.

  6. Setup a new inbound route under Connectivity  Inbound Routes → Add Incoming Route:

    DID Number: Your SIM card number with country code (with a plus sign at the beginning)
    CallerID Number: Your personal cell phone number
    Set Destinations: Trunk and your recently created IAX2 trunk.

    Note: This is the route responsible to redirect an inbound call on your local dongle over the IAX2 trunk and then to your remote server.
If you noticed any omitted fields in the above configurations, it's because I didn't fill with anything or it's not important. I also did some extra work on Claning the SIM card memory for SMS every once in a while, I set a static IP for the OpenVPN so each server can always see each other, an additional service to check my credit balance every month and so and so forth. If you also want details like that please let me know in the comments :-) 

That's it! You did it! If you need more help setting up anything else please let me know in the comments of this post. Good luck and have fun! :-)

quinta-feira, 9 de janeiro de 2014

Vendo: Placa Beagleboard rev C4 + Placa de expansão BeagleBuddy Zippy

tl;dr: R$200,00 por fora do Mercado Livre. Interessados deixem contato nos comentários.

Pessoal, estou vendendo esta placa de desenvolvimento apenas por que os repositórios de software que costumava usar foram descontinuados para este modelo (parou no Ubuntu Server 12.03, ainda da pra instalar e atualizar os pacotes, mas não tem versões mais novas). Apesar disso, é uma placa de baixíssimo consumo de energia, ideal para desenvolvimento de aplicações embarcadas e testes com processadores ARM.

Como mostram as fotos, a BeagleBoard já está soldada à placa de expansão BeagleBuddy Zippy e ambas estão muito bem cuidadas e funcionando normalmente. Já acompanha a bateria de 3V para o RealTime Clock.

Junto com as paquinhas vão:

  • Caixa original
  • Fonte de alimentação de 5V
  • Case de acrílico + um case fosco (na época que eu comprei veio um de brinde que eu nunca usei)
  • Cabo USB-serial
  • Bateria 3V para o RealTime Clock

Tudo isso por apenas R$200,00!

(tenho conta no ITAU, aceito PayPal e Bitcoin)

Interessados: Deixem o contato nos comentários.

BeagleBoard rev C4:
  • Package on Package POP CPU/Memory chip.
    • Processor TI OMAP3530 Processor - 720 MHz ARM Cortex-A8 core
    • 'HD capable' TMS320C64x+ core (520 MHz up to 720p @30 fps)
    • Imagination Technologies PowerVR SGX 2D/3D graphics processor supporting dual independent displays
    • 256 MB LPDDR RAM
    • 256 MB NAND Flash memory
  • Peripheral connections
    • DVI-D (HDMI connector chosen for size - maximum resolution is 1280×1024)
    • S-Video
    • USB OTG (mini AB)
    • 1 USB port
    • SD/MMC card slot
    • Stereo in and out jacks
    • RS-232 port
    • JTAG connector
    • Power socket (5 V barrel connector type)
    • Development
      • Boot code stored in ROM
      • Boot from NAND memory, SD/MMC, USB, or serial
      • Alternative boot source button.

BeagleBuddy Zippy:
  • 10BaseT Ethernet 
  • Additional SD/MMC interface 
  • Battery backed-up Real Time Clock (RTC)
  • Additional RS-232 serial port
  • 5V I2C expansion interface.