Thursday, August 30, 2018

RabbitMQ on Docker with custom configuration

This is a quick tip.

I was thinking in a way of using RabbitMQ on a Docker container as part of an automatic integration tests for a application I was working with at my current job. That is easy, the Docker Hub has an official Docker image ready for use as rabbitmq:management-alpine.

My first thought was to automate the configuration of the RabbitMQ by using rabbitmqctl or rabbitmqadmin programs, but then I remembered that RabbitMQ can actually use a exported configuration backup in the form of a JSON file.

The problem was: how to load this configuration? I can't change the Dockerfile in order to do that because the broker must be running in order to load the configuration but then I would need to override the ENTRYPOINT, something that I was not willing to do.

Fortunately a good soul had already implemented a clever hack to the container configuration as you want, without doing many changes in the original Dockerfile.

So, at the end, the only thing I need to do is to write a Dockefile like the one below:

FROM rabbitmq:management-alpine
COPY rabbit_config.json /etc/rabbitmq/definitions.json

Tuesday, July 31, 2018

Dropping Archive::Tar::Wrapper support for Solaris

I recently adopt a Perl distribution: Archive::Tar::Wrapper.

Initially developed by Mike Schilli, this module is well know by the Perl community and it is being around since 2005. All started because I submitted a patch to Mike to make it work on OpenBSD.

From there, I tried to fix another known bugs (and introduced some!) and make it run on operational systems that were showing problems.

After fixing the distribution to run on MS Windows properly (with the help of Ingram Braun), the next step would be to fix it for Solaris. Carlos Guevara gave me some pointers and I decided to take a look.

First thing I thought was try to use a VM for it, of course. Vagrant VM's should be easier to use, and I was able to find one with, I think, a decent recent version.

That's is what I got after booting and logging in a shell:

Last login: Wed Jul 18 16:25:27 2018 from
Oracle Corporation      SunOS 5.11      11.3    September 2015
-bash-4.1$ perl -v

This is perl 5, version 12, subversion 5 (v5.12.5) built for i86pc-solaris-64int
(with 7 registered patches, see perl -V for more detail)

Copyright 1987-2012, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at, the Perl Home Page.

Oh, come on! perl 5.12?!? Really?

That gave me some thoughts about how old Perl 5.12 is and how little Oracle cares about Perl.

And brought back memories about the time I spent over there, when I was able to see that Perl was used everywhere inside the company, from day-to-day automation to specifically helping their own products. I was even able to find that in the past (and I don't remember how long it lasted) there was a group of people specialized in using Perl to automate anything, or even develop web applications using Catalyst. I wasn't able to contact any member of the group about that time.

Not long after that, I got a blog entry from Perl Weekly about a new release of DBD::Oracle. To my surprise, even after many years Oracle still makes the life of Perl programmers unnecessary miserable when they just need to connect their code to a Oracle database and have to do all sorts of configurations to just install a Perl module due binary dependencies.

Long story short: I gave up trying to support Solaris. Just put

if ( $^O eq 'solaris' ) {
    die "OS unsupported\n";

in the Makefile.PL and life goes on.

I won't reject a patch to make Archive::Tar::Wrapper on Solaris, as long it passes on the unit tests and don't break on other OSes, but from my perspective, the Perl community doesn't really need anything from Oracle.

I have the utmost respect about Sun Microsystems and all the contributions it gave to the community but for Oracle? Not really. At all.

Thursday, May 24, 2018

Quickly making a DEB from a Perl module

Recently I had to quickly create a DEB package for Ubuntu for a Perl module available on CPAN (not sure why REST::Client is not available anymore).

It has been a while since the last time I did, and honestly I couldn't remember what was required to.

After some frustating minutes trying to go over the documentation for dh-make-perl, I was able to reach those two simple lines in a shell:

$ export DEBFULLNAME='Alceu Rodrigues de Freitas Junior'
$ dh-make-perl --cpan REST::Client --arch all --depends libjson-xs-perl, liblwp-protocol-https-perl, liburi-perl libwww-perl --email --build

Documentation of dh-make-perl does have a lot of space of improvement... and for my dismay, it is not even easy to do make contributions for it: no available access to the repository as you would expect to do nowadays (git pull request), first you got to be accepted as a Debian contribuitor... which is not that easy too.

Tuesday, February 27, 2018

Perl on Windows... still not that good

Today I had to use Perl from Windows... it was a couple of years ago that I needed to do it so.

Frankly, it was never the best experience from a end user point of view. Strawberry Perl made it a lot easier, but to this day it is still an incomplete solution.

I don't want just to complain about it... if you don't like a opensource project, don't use it. Or try to improve it yourself.

Here are some notes for those willing to do the later:
  1. Install Git for Windows. You will get some other nice programs as tar and gzip. You will need those and what the heck, everybody uses git nowadays.
  2. Configure the cpan program. You can use the default configuration offered and set some items later.
  3. Configure cpan to use the tar and gzip programs from step 1. In the case you don't remember, type o conf tar and o conf gzip and setup the complete path to those guys. If you were unwise and setup Git for Windows use the suggested path (C:\Program Files\Git), you will have to do some quoting and escaping the backslash (like "C:\\Program Files\\Git\\usr\\bin\\tar.exe").
  4. Configure cpan to use the gmake.exe program (don't really know why it wasn't configured by default, considering that gmake.exe is part of Strawberry Perl): o conf make C:\\Strawberry\\c\\bin\\gmake.exe
  5. Configure cmd.exe to use Unicode by default: fire up the command REG ADD HKCU\Console /v CodePage /t REG_DWORD /d 0xfde9 with administrator privileges in order to do that. It avoids you having warnings all over because of Unicode characters.
  6. Configure cpan to use a SQLite database (which speeds up the process): o conf use_sqlite 1
  7. Install YAML::XS, which is faster than YAML.
  8. Be smart and add C:\Program Files\Git\usr\bin to your PATH variable.

Sunday, January 28, 2018

cron versus Crom

Do you know cron? If you ever worked on a UNIX-like OS, it's very likely you do!

But what do you know about Crom?

What have they in common besides the (almost) identical names?

Let's see how the venerable cron compares to the imortal Crom!

cron Crom
What is it? Software time-based job scheduler for UNIX-like OSes. Fictional Cimmerian deity of Hyborian Ages.
Uses Schedule tasks to be executed, per user, with granularity of one minute. Basically nothing.
Some believe that he bestow men and women at birth with the courage to survive, persevere, and vanquish adversity.
Creation 1979 (Version 7 UNIX). 1932. Crom is the most venerable indeed.
Versions Several (proprietary, open source and free software) implementations. There is only one Crom, you hound dog son of a thousand fathers!
How to use it Executing crontab -e, or editing the several files that comprises it's configuration Invoke his name during an oath or curse. That's the only know safe way to mention him.
Known problems It will issue error messages if you messed up with the expected syntax He has little patience for weakness, which means asking him for help will make him to ignore you (at best) or really f@#$%&! you (at worst).

Thursday, September 28, 2017

Getting Ubuntu, Python 2.7, Jedi and Vim playing nice to each other

This took me some hours to figure out: how to finally set Jedi with Vim to have a good editor for Python 2.7 code.

Ubuntu 16.04 by default install Vim compiled against Python 3.5 interpreter, which is not immediate obvious but becomes a pain in the ass after you discover that even after installing Jedi and python-jedi, you're still getting the error message:

Please install Jedi if you want to use jedi-vim.

When opening a file with Python code.

To get things working for your Python 2.7 code, you might need to uninstall your current Vim related packages and install the following:
  • vim-addon-manager
  • vim-common
  • vim-gnome-py2
  • vim-gtk3-py2
  • vim-gui-common
  • vim-nox-py2
  • vim-python-jedi
  • vim-runtime
You can check your current configuration with:

$ dpkg-query -l 'vim*'

Thursday, July 6, 2017

Moving away from Dist::Zilla @Basic

Today a got an issue registered at my distribution Linux::Info and decided to take a quickly look at it since it was quite a while since the last release.

The issue itself was not that interesting (looks like the distribution Pod could receive some more attention, which indeed I added), but also gave me a chance to try and add a cpanfile to it.

Some months ago I was notified that my distributions were not providing a cpanfile. I wasn't even aware what was it about and what I was missing.

The thing is that a cpanfile is just another way to declare the distribution dependencies. Not really interesting from this point of view.

The good part of it is to allow the developer to install the distribution without having to install Dist::Zilla (and it's quite large number of dependencies) before even being able to build the distribution (well, assuming that the distribution uses Dist::Zilla).

That means you can skip some minutes and download bandwitdh, ignoring whatever Dist::Zilla depends on. Which also means you can just git clone a Perl project and install the requisites automatically with cpanm with two steps:

  1. git clone
  2. cpanm --installdeps .
That's it! Well, almost, you might need to install cpanm first. And be sure to include the dot in the step 2, it matters.

If your distribution uses Dist::Zilla already, you can add the cpanfile automatically by just adding [CpanFile] to the dist.ini file. The plug-in does the rest for you. Almost.

In order to have this cool stuff available from your code repository, you will need to have the cpanfile available over there... that means you need to build the distribution and copy the file to the repository, where it is going to be source controlled as everything else.

To cover that, you can use Dist::Zilla::Plugin::CopyFilesFromBuild, another plug-in to make your life easier.

But if you have the [@Basic] declared at the dist.ini (as I did) to load the most basic Dist::Zilla plug-ins you need, you will have a nasty surprise:

[DZ] attempt to add cpanfile multiple times; added by: GatherDir (Dist::Zilla::Plugin::GatherDir line 100); CPANFile (Dist::Zilla::Plugin::CPANFile line 65)

And the distribution generation is aborted. I was able to even find a bug registered about that, but it is not really a bug after all: it happens because the GatherDir, automatically registered by [@Basic], is not configured to ignore the cpanfile over there.

I tried to to that, but instead of getting rid of the error, I got a lot more of them, all of them related to GatherDir. Don't know why, but I was able to fix by removing [@Basic] and putting only the plug-ins I was indeed using and the over automatically included by the bundle and adding the following two lines to configured GatherDir:

exclude_filename = cpanfile

So, fixing the errors were a nice side effect of review what I indeed need in my distribution in terms of plug-ins.

Bottom line: Dist::Zilla::PluginBundle::Basic is great to start from scratch, but keep in mind that once your dist.ini is not that "basic" anymore, you will need to start cutting-off plug-ins!