Giacomo Vacca

This is just a practical guide to have latest sipp on debian , to benefit from features that are not available in the stock package ( sip-tester  - version 3.2.1). For example support for playing pcap files or computing authentication hashes. Build sipp with pcap support apt-get install autoconf libncurses5-dev libpcap-dev g++ cd /usr/local/src/ git clone https://github.com/SIPp/sipp.git cd sipp/ ./build.sh --with-pcap ./sipp is the built binary. You can see the version and capabilities with './sipp -v', e.g.: $ ./sipp -v SIPp v3.6-dev-149-gb95f98f-PCAP-RTPSTREAM. ... This version will be able to use actions like exec rtp_stream="file.wav" or exec play_pcap_audio="pcap/g711a.pcap" (see details in current documentation ). A little caveat for 'rtp_stream' and WAV files . As the documentation says sipp expects a WAV file encoded with PCAM ('A-law'). You can also loop that audio for as long as you need, by adding '...

Fan of Homer ? So am I, and as sometimes happens I'm a fan who could join the team! If despite the title of this post you're still reading, then it's a good sign and we can move on. Homer is a vast project that aims to provide a tool, with a GUI, to correlate all the signalling, RTCP stats, events, logs in your RTC network. It focuses heavily on SIP , for historical reasons, but it's also an extendible framework to store other types of signalling, correlate data, and compute statistics. People browsing their github account are often heard saying "Do they have this too? And this ? Wow!". It is compatible off the shelf with common applications like Kamailio, opensips, FreeSWITCH, Asterisk, so if you're into VoIP, adding Homer to your platform is as easy as installing it and telling your apps where to send their data. There are also standalone tools like captagent ,  nodejs apps to parse and collect specific logs, to be associated with the re...

I recently had a scenario where I needed to connect servers belonging to: - Digitalocean , on data center X - Digitalocean, on data center Y - A private data center and each architecture needed to be replicated on a number of "logical" environments (e.g. 'development', 'testing', 'production'). They needed to "see" each other, in a secure way. Note that virtual machines on Digitalocean (they call them 'droplets') can belong to different data centers. When the droplets use the optional private interface there are two things to consider: 1. Traffic inside the same data center is potentially visible to any equipment on the same data center. In other words, the fact that two droplets belong to the same customer account doesn't mean that their private traffic is isolated from any other traffic belonging to droplets on other accounts. You are responsible to secure that traffic. 2. Droplets on different data centers cannot ...

This was tricky. I was setting up a VPN connection with a newly built DigitalOcean droplet (standard debian wheezy 64bit in the London1 data center). The connection is based on openvpn , and it's the same on many other nodes, but openvpn wasn't starting properly (no sign of the tun interface). Googling the problem brought me to this reported debian bug , where apparently the problem was associated to an older version of the linux kernel. But I had the latest installed: ii  linux-image-3.2.0-4-amd64          3.2.63-2+deb7u1               amd64        Linux 3.2 for 64-bit PCs The reason why this problem was present is that the version actually loaded was different! Apparently [...] it seems that grub settings are ignored on digital ocean, and that you instead have to specify which kernel is booted from the Digital Ocean control panel, loaded from outside the droplet [...] So to see w...

Almost three years ago I started automating the deployment of all server-side applications with Puppet . One of the key applications in Truphone's RTC platform (and arguably in most of VoIP/WebRTC platforms today) is Kamailio , so with some proper encapsulation it’s been possible to build a Puppet module dedicated to it. This is now publicly available on PuppetForge . Puppet Forge is a public repository of Puppet modules. We use many of them, and they can be incredibly useful to get you up to speed and solve common problems. You can also fork it on github , if you want. You can use this module in different ways: To quickly deploy a kamailio instance, with default configuration files. As the basis for a custom configuration, where you use the official debian packages but with your own configuration details and business logic. The first approach is very simple. Imagine you start from and empty VM or base docker container: all you have to do is install pup...

When using dch -i or -v, this tool will try to infer what name and email address the maintainer wants. The gist of this short post is: check the values of DEBEMAIL and DEBFULLNAME environment variables before running the build. And of course you can set them with a simple export command. From dch man page: If either --increment or --newversion is used, the name and email for the new version will be determined as follows. If the environment variable DEBFULLNAME is set, this will be used for the maintainer full name; if not, then NAME will be checked. If the environment variable DEBEMAIL is set, this will be used for the email address. If this variable has the form "name ", then the maintainer name will also be taken from here if neither DEBFULLNAME nor NAME is set. If this variable is not set, the same test is performed on the environment variable EMAIL. Next, if the full nam...

If you've ever installed a package from command line on Linux, you must have noticed two main prompts related to package configuration: one asking what to do with installed configuration files with local changes, and one providing feedback right after the installation/upgrade/removal/purge has completed. Under Debian the latter was most probably the postinst script, one of the Package Maintainer Scripts which is executed after installation and configuration. These diagrams are very useful to understand what happens to the Maintainer Scripts in different circumstances: first installation, upgrade, removal, purge. Their name is probably self-explanatory: preinst , postinst , prerm , postrm . Each of them takes zero or more arguments depending on the scenario. It can help to understand that those are really just scripts executed by dpkg - and typically they are shell scripts, sometimes with interactive prompts. If you're building your own packages, you surely already h...

The words in the title are not mine, but only a quote from Debian Wiki . However, if you're reading a debian/control file and wondering what Build-Depends-Indep means, starting from the assumption that it is useless may help. Otherwise you can follow the rule to put in Build-Depends all those packages that are absolutely necessary to build architecture-dependent files, while the rest goes into Build-Depends-Indep .

As suggested in Debian Cleanup Tip #1: Get rid of useless configuration files , it's worth using grep-status to retrieve information about configuration files left behind a package removal or upgrade. For example, on my Squeeze VM: $ grep-status -n -sPackage -FStatus config-files libjack-jackd2-0 You can confirm with 'dpkg -l' that's a package in 'rc' status: $ dpkg -l | grep libjack-jackd2-0 rc libjack-jackd2-0 1.9.6~dfsg.1-2 JACK Audio Connection Kit (libraries) You may probably want to remove definitely those configuration files; just purge the package. For example: $ dpkg -P libjack-jackd2-0 See also about debian configuration files, an important assumption Debian takes .

Not a big deal, but since the solution to this problem wasn't immediate to find, it's probably worth writing it down. Symptom : when you try to tab complete a command, you see a message like this: vi /et-sh: Cause : You're using sh, not bash, so even if tab completion is enabled on ~/.bashrc, it won't be available to you. Solution : change the default shell for the current user from sh to bash with chsh -s /bin/bash That's it.

It took me more than expected (and in fact someone found it for me) to explain why a file installed by a debian package and not listed inside debian/conffiles was handled as a standard configuration file. The file is installed in a subdirectory of /etc/, so intuitively you may assume it must be considered as a configuration file, although this wasn't clearly stated in a document until I read this from Debian New Maintainer's Guide , chapter 5: Since debhelper V3, dh_installdeb(1) will automatically flag any files under the /etc directory as conffiles, so if your program only has conffiles there you do not need to specify them in this file. For most package types, the only place there is (and should be conffiles) is under /etc and so this file doesn't need to exist. The conclusion is that if you install a file in a subfolder of /etc/, you don't need to list it inside debian/conffiles.

The good news is that building a debian package from the source of a CPAN module is easy, thanks to the dh-make-perl tool. The bad news is that the configuration of dh-make-perl can lead to the generation of a debian package containing unneeded files, and as a collateral effect preventing package installation as the files belong to more than one package. For example you can end up with something like: dpkg: error processing /var/cache/apt/archives/scnlibpoe-filter-stomp-perl_0.01_all.deb (--unpack): trying to overwrite `/usr/lib/perl/5.8/perllocal.pod', which is also in package scnlibpoe-component-client-stomp-perl Somebody suggests a change in the configuration file used by dh-make-perl . The same result can be achieved by applying this change to your debian/rules file: --- debian/rules (revision 32211) +++ debian/rules (working copy) @@ -51,8 +51,11 @@ - rmdir --ignore-fail-on-non-empty --parents $(TMP)/usr/lib/perl5 + rm -rfv $(TMP)/usr/lib

The goal is to make my life easier when the same package may go to different distributions. This is not useful per se, but it becomes so when you use custom distributions names to distinguish separate product branches. Let's assume you have an application app , which has different flavours, for example alpha and beta . You may want to have two separate debian repos for app , one called alpha and one called beta . Hosts within environment A may refer to the alpha repo, while hosts in another environment, let's say environment B, may want to refer to the beta repo. This keeps the small or big differences in app isolated. Now, assume app reaches a point when the only difference between A and B is the distribution name, so you can have the same version for the alpha and beta repo: how can you avoid building the package twice? Is there a way to make both repos happy? These are the questions that led me to the need of having a local debian repo , to experiment a little on this to...

... and you never dared asking. Enjoy .

What a good day. Not only I've got a new laptop from the company, but I've found also an extremely useful tool to build a debian package from a perl module: dh-make-perl . You just need to do 2 things: - Run dh-make-perl on the untarred module directory (this creates the necessary debian dir and files). - Inside the module directory, run debuild . Very nice. Now I wonder why most of the CPAN and POE components don't come with a debian package...

On debian/Ubuntu you can check the installationdate from the output of: ls /var/lib/dpkg/info/*.list -lh Just | grep the name of the package you're interested to. See this for important details.

curl is a powerful library available on different platforms - I use it on Linux debian . You can use it just to get http pages, or to post data and get a response from a server. HTTPS is available too. An example: curl -k --data @request.xml https://127.0.0.1/service posts the XML data contained by request.xml using a HTTPS connection (and ignoring invalid certificates, option ' -k ' - just for testing purposes). This is a more interesting usage: it's nice to get info from Twitter or even send messages ("update your status") with just a command line: Get status: curl http://twitter.com/users/show.xml?screen_name=giavac Send a message: curl -u user:password -d "status=describing how to use the Twitter API" http://twitter.com/statuses/update.xml To install curl on debian: apt-get install libcurl3 (install dependencies too, and I suggest to include libcurl3-gnutls-dev)