hacks

Alternative view: by date.

Executive summary

It’s perfectly possible! Jump to the HTML demo!

Longer version

This started with a very simple need: wanting to improve the notifications I’m receiving from various sources. Those include:

changes or failures reported during Puppet runs on my own infrastructure, and on at a customer’s;
build failures for the Debian Installer;
changes in banking amounts;
and lately: build status for jobs in a customer’s Jenkins instance.

I’ve been using plaintext notifications for a number of years but I decided to try and pimp them a little by adding some colors.

While the XMPP-sending details are usually hidden in a local module, here’s a small self-contained example: connecting to a server, sending credentials, and then sending a message to someone else. Of course, one might want to tweak the Configuration section before trying to run this script…

#!/usr/bin/perl
use strict;
use warnings;

use Net::XMPP;

# Configuration:
my $hostname = 'example.org';
my $username = 'bot';
my $password = 'call-me-alan';
my $resource = 'demo';
my $recipient = 'human@example.org';

# Open connection:
my $con = Net::XMPP::Client->new();
my $status = $con->Connect(
    hostname       => $hostname,
    connectiontype => 'tcpip',
    tls            => 1,
    ssl_ca_path    => '/etc/ssl/certs',
);
die 'XMPP connection failed'
    if ! defined($status);

# Log in:
my @result = $con->AuthSend(
    hostname => $hostname,
    username => $username,
    password => $password,
    resource => $resource,
);
die 'XMPP authentication failed'
    if $result[0] ne 'ok';

# Send plaintext message:
my $msg = 'Hello, World!';
my $res = $con->MessageSend(
    to   => $recipient,
    body => $msg,
    type => 'chat',
);
die('ERROR: XMPP message failed')
    if $res != 0;

For reference, here’s what the XML message looks like in Gajim’s XML console (on the receiving end):

<message type='chat' to='human@example.org' from='bot@example.org/demo'>
  <body>Hello, World!</body>
</message>

Issues start when one tries to send some HTML message, e.g. with the last part changed to:

# Send plaintext message:
my $msg = 'This is a <b>failing</b> test';
my $res = $con->MessageSend(
    to   => $recipient,
    body => $msg,
    type => 'chat',
);

as that leads to the following message:

<message type='chat' to='human@example.org' from='bot@example.org/demo'>
  <body>This is a &lt;b&gt;failing&lt;/b&gt; test</body>
</message>

So tags are getting encoded and one gets to see the uninterpreted “HTML code”.

Trying various things to embed that inside <body> and <html> tags, with or without namespaces, led nowhere.

Looking at a message sent from Gajim to Gajim (so that I could craft an HTML message myself and inspect it), I’ve noticed it goes this way (edited to concentrate on important parts):

<message xmlns="jabber:client" to="human@example.org/Gajim" type="chat">
  <body>Hello, World!</body>
  <html xmlns="http://jabber.org/protocol/xhtml-im">
    <body xmlns="http://www.w3.org/1999/xhtml">
      <p>Hello, <strong>World</strong>!</p>
    </body>
  </html>
</message>

Two takeaways here:

The message is send both in plaintext and in HTML. It seems Gajim archives the plaintext version, as opening the history/logs only shows the textual version.
The fact that the HTML message is under a different path (/message/html as opposed to /message/body) means that one cannot use the MessageSend method to send HTML messages…

This was verified by checking the documentation and code of the Net::XMPP::Message module. It comes with various getters and setters for attributes. Those are then automatically collected when the message is serialized into XML (through the GetXML() method). Trying to add handling for a new HTML attribute would mean being extra careful as that would need to be treated with $type = 'raw'…

Oh, wait a minute! While using git grep in the sources, looking for that raw type thing, I’ve discovered what sounded promising: an InsertRawXML() method, that doesn’t appear anywhere in either the code or the documentation of the Net::XMPP::Message module.

It’s available, though! Because Net::XMPP::Message is derived from Net::XMPP::Stanza:

use Net::XMPP::Stanza;
use base qw( Net::XMPP::Stanza );

which then in turn comes with this function:

##############################################################################
#
# InsertRawXML - puts the specified string onto the list for raw XML to be
#                included in the packet.
#
##############################################################################

Let’s put that aside for a moment and get back to the MessageSend() method. It wants parameters that can be passed to the Net::XMPP::Message SetMessage() method, and here is its entire code:

###############################################################################
#
# MessageSend - Takes the same hash that Net::XMPP::Message->SetMessage
#               takes and sends the message to the server.
#
###############################################################################
sub MessageSend
{
    my $self = shift;

    my $mess = $self->_message();
    $mess->SetMessage(@_);
    $self->Send($mess);
}

The first assignment is basically equivalent to my $mess = Net::XMPP::Message->new();, so what this function does is: creating a Net::XMPP::Message for us, passing all parameters there, and handing the resulting object over to the Send() method. All in all, that’s merely a proxy.

HTML demo

The question becomes: what if we were to create that object ourselves, then tweaking it a little, and then passing it directly to Send(), instead of using the slightly limited MessageSend()? Let’s see what the rewritten sending part would look like:

# Send HTML message:
my $text = 'This is a working test';
my $html = 'This is a <b>working</b> test';

my $message = Net::XMPP::Message->new();
$message->SetMessage(
    to   => $recipient,
    body => $text,
    type => 'chat',
);
$message->InsertRawXML("<html><body>$html</body></html>");
my $res = $con->Send($message);

And tada!

<message type='chat' to='human@example.org' from='bot@example.org/demo'>
  <body>This is a working test</body>
  <html>
    <body>This is a <b>working</b> test</body>
  </html>
</message>

I’m absolutely no expert when it comes to XMPP standards, and one might need/want to set some more metadata like xmlns but I’m happy enough with this solution that I thought I’d share it as is. ;)

Posted @ 17/08/2019 Tags: debian hacks

Problem

Discussions are sometimes started by mailing a few different mailing lists so that all relevant parties have a chance to be aware of a new topic. It’s all nice when people can agree on a single venue to send their replies to, but that doesn’t happen every time.

Case in point, I’m getting 5 copies of a bunch of mails, through the following debian-* lists: accessibility, boot, cd, devel, project.

Needless to say: Reading, or marking a given mail as read once per maildir rapidly becomes a burden.

Solution

I know some people use a duplicate killer at procmail time (hello gregor) but I’d rather keep all mails in their relevant maildirs.

So here’s mark-read-everywhere.pl which seems to do the job just fine for my particular setup: all maildirs below ~/mails/* with the usual cur, new, tmp subdirectories.

Basically, given a mail piped from mutt, compute a hash on various headers, look at all new mails (new subdirectories), and mark the matching ones as read (move to the nearby cur subdirectories, and change suffix from , to ,S).

Mutt key binding (where X is short for cross post):

macro index X "<pipe-message>~/bin/mark-as-read-everywhere.pl<enter>"

This isn’t pretty or bulletproof but it already started saving time!

Now to wonder: was it worth the time to automate that?

Posted @ 11/08/2014 Tags: debian hacks

While investigating the case of some packages responsible for uninstallability on the s390x architecture, I stumbled upon one FTBFS on a single architecture, reported as #673590 (<insert some nice words about software shipping with a decent testsuite>).

Given the int versus size_t question was asked, I grabbed this old (it’s UNIX!) reference: 64-bit and Data Size Neutrality.

Among other things, it describes the “everything is 32-bit” to “64-bit is becoming the new standard” slow conversion process, where keeping compatibility with existing applications was a high priority. It has a nice description of so-called C data models, making it possible to refer to them quickly: LP32 and ILP32 in the 32-bit world; ILP64, LLP64, and LP64 in the 64-bit world. I won’t go into detail here, this page has a nice table and lots of explanations about pros and cons for those.

(On a personal note, I discovered those on xorg-devel@ when I saw patches floating around, which were about optimizing data sizes for this or that data model, by picking the right types.)

While standards may be boring, this page makes it really easy to understand which data types to use, to ensure the best 32/64-bit compatibility possible. It’s even full of dos and don’ts. See the second half (Porting Issues) for details.

Posted @ 21/05/2012 Tags: debian hacks

Keeping an eye on something with a webcam is really easy: just a matter of setting up for example (c)vlc to multicast from /dev/videoX to the network, and done.

Example:

# Streaming:
cvlc v4l2:///dev/video0 --no-audio --sout "#transcode{vcodec=mp2v,vb=3072}:std{access=udp,mux=ts,dst=224.0.0.1}"

# Playing, possibly on a remote machine:
vlc udp://@224.0.0.1:1234

Notes:

v4l2 vs. v4l depending on the distribution (sid vs. squeeze).
Triple slash needed, two for the v4l[2]:// part, one for the device (/dev/video0).
Why this address? See Wikipedia’s Multicast address article.

Possible problems:

If switches don’t have IGMP snooping enabled, throwing multicast at them turns it into plain broadcast. In other words: instead of having packets sent to the hosts subscribed to that multicast address, everyone gets those packets, polluting the network.
Trying to stream from multiple devices may fail, due to USB bandwidth issues. At least that can be seen with two random devices using the uvcvideo module, getting No space left on device when the second (c)vlc is started.

Where to go from here:

fswebcam to the rescue! It can capture a frame from a given device. The following options are particularly useful: --resolution to request a specific resolution (the device will fall back to another resolution if the requested one is unavailable); --frames to specify the number of frames to capture (lower noise, but possibly higher blurriness).
A tiny python wrapper around it makes it possible to set various webcams, with different options (number of frames, delay between two captures, resolution), operating at the same time thanks to the help of the threading module. To avoid encountering the same bandwidth issue, a tiny lock ensures a single fswebcam instance runs at a time.
That also makes it possible to save all images as videoX-timestamp.jpg and to “log”rotate them after a while, for further viewing/reviewing during a given time window.

Thanks to ImageMagick, it’s also trivial to process the captured images:

 # Only keep a rectangle of width W, height H, starting at the point (X,Y):
 convert -crop WxH+X+Y capture.jpg capture.jpg
 # Include a timestamp on the top-left corner:
 convert -box white -font Fixed -draw "text 2,12 \"$timestamp\"" capture.jpg capture.jpg

Keeping a videoX-current.jpg symlink for each /dev/videoX device is trivial.
Add to that a lightweight webserver and a single page showing the most recent capture for each device thanks to the symlinks, with a meta refresh of say 5 seconds, and tada! Keeping an eye on multiple things at once. Of course that’s not a real video, but that can fulfill some needs.

Posted @ 18/07/2011 Tags: debian hacks

Browse by tag:

Browse by date:

Executive summary

Longer version

HTML demo

Problem

Solution