Technical Support Engineer position in Warsaw (C++, Linux)

If you are an experienced programmer who:

• crosses inter-company and inter cultural boundaries with ease
• enjoys working directly with customer and partners (knows that a conf call could be not a boring waste of time, but an effective tool)
• is, like me, a "script guy" who automates everything in projects
• efficiently uses grep / sed / awk, and the command line in Linux
• knows that *.pcap is not another MS Office file format
• is willing to analyze the systems source code one has never contributed to
• uses many languages (C++ is a must, Java & JavaScript are nice to have)
• has Linux embedded background (preferably IPTV)
• is able to capture patterns where others see only noise (i.e.: effective scanning of gigabytes of log files)
• learns new things in real time
• owns "sixth sense" to reduce the entropy in IT projects

... then:

... in Warsaw office (Poland), for big, international, IPTV project. My team makes things happen by:

• analysis of stream of bugs effectively
• introducing automation
• improving development processes and flows
• squeezing everything possible (and more) from existing build systems
• pro-actively tracks and improves project health by (guess what?) AUTOMATION!!!

If you match the profile highlighted above do not hesitate to contact me via Skype: cieslakd or by e-mail: dariusz.cieslak at schange.com. I'll be glad to share more details about the position.

Tracking Integration With Yocto/OpenEmbedded

Yocto is an Open Source project (based, in turn, on OpenEmbedded and bitbake) that allows you to create your own custom Linux distribution and build everything from sources (like Gentoo does). It's mostly used for embedded software development and has support from many hardware vendors. Having source build in place allows you to customize almost everything. In recent years I was faced with problem of development integration - to allow distributed development teams to cooperate and to supply their updates effectively for central build system(s). The purpose of this process:

• to know if the build is successful after each delivery
• to have high resolution of builds (to allow regression tests)
• and (of course) to launch automated tests after each build

ssls.com review

Sometimes you need to provide encrypted traffic to your site. Besides proper configuration in web server you need to authenticate your server using some publicly trusted certificates, so your customer's browser won't show warnings about untrusted site. One of the cheapest SSL certificate solution is ssls.com. Let's check their price for 3 year lease: I used to pay $10 per year in the past for ComodoSSL certificates, this offer seems to cut the usual price in half. Sounds unrealistic? Let's check it!

Basic Hudson/Jenkins tutorial

Continuous Integration is a great thing. Allows you to monitor your project state on a commit-by-commit basis. Every build failure is monitored easily. If you connect your unit and integration tests properly also tell your runtime properties of the project, for example:

• Does it boot properly?
• Doesn't it crash in 1st 5 minutes?
• Are all unit tests 100% green?
• Are all static tests (think: FindBugs, lclint, pylint, ...) free of selected defect types?

The implementation:

• you encourage your team to push changes frequently to main development branch (having high quality unit testing suite you can even skip topic branches policy)
• you setup some kind of Continuous Integration tool to scan all the repositories and detect new changes automatically
• for each such change new build is started and tests are carries out automatically
• all the build artefacts (including tests outcomes) are collected
• the teams are notified by e-mail about build/test failures in order to allow them to carry out fixes quickly

OK, so we have outlined the plan above. Let's dig into details for every step. I'll use the most popular tool used named Hudson/Jenkins as implementation tool (there are two projects, but they're, actually, the same tool). I'm going to address all the features I expect from continuous integration system (based on my current experience with other CI systems).

CMake very basic tutorial

Writing Makefiles is a complicated process. They are powerful tools and, as such, show quite high level of complexity. In order to make typical project development easier higher level tools have been raised. One of such tools is CMake. Think of CMake for Make as C/C++ compiler for assembly language. CMake transforms project description saved in CMakeLists.txt file into classical Makefile that could be run by make tool. You write your project description in a high level notation, allowing CMake to take care of the details.
 

An Easy Executable Software Specification - A Proposal

Executable specification

is a "holly graal" of modern software engineering. It's very hard to implement as it requires:

• Formal specification of rules
• Transformation of those rules into real-system predicates
• Stimulating system under tests state changes in repeatable manner

FitNesse is one of such approaches that specifies function sample inputs and outputs then allow to run such test cases using special connectors and provide colour reports from test runs. It's easy to use (from specification point of view), but has the following drawbacks:

• Software architecture must be compatible with unit testing (what is very good in general: cut unnecessary dependencies, Inverse of Control, ...) - your current system might require heavy refactoring to reach such state
• Rules are written and evaluated only during single test execution - different scenario requires another test case (no Design By Contract style continuous state validation)

Above features are present in any other unit test framework: JUnit, unittest, ... All such testing changes state and checks output.

Setting up proper terminal size for serial connection to an embedded device

When you work over serial line on an embedded device usually the terminal size it set to 80x25.

There's an easy way, however, to setup your real terminal size, just add the following line to your profile script (~/.profile):

resize > /tmp/resize
. /tmp/resize

resize command detects real terminal size and sets COLUMNS and ROWS parameters accordingly:

# resize
COLUMNS=159;LINES=52;export COLUMNS LINES;

One just need to execute the output as sh commands (using source "." command).

Conflicting DHCP server locator under Linux

In order to locate conflicting DHCP server in your LAN execute the following command:

sudo dhcpdump -i eth4 | awk '/IP:/{SRC=$2 " " $3} /OP:.*BOOTPREPLY/{ print "DHCP server found:", SRC; }'

The restart your PC network (use DHCP to get new IP). If you see more than one IP address here:

DHCP server found: 192.168.4.1 (0:9:6b:a3:fc:4a)
DHCP server found: 192.168.1.1 (f8:d1:11:9e:1d:8b)
DHCP server found: 192.168.4.1 (0:9:6b:a3:fc:4a)
DHCP server found: 192.168.1.1 (f8:d1:11:9e:1d:8b)
DHCP server found: 192.168.4.1 (0:9:6b:a3:fc:4a)

Then you have two, conflicting DHCP servers in your network. You can use http://www.coffer.com/mac_find/ tool to locate the device type that causes the problems.

PlantUML - draw your diagrams declaratively

One picture is worth of thousand words. So true. Even if you describe some flow with many detailed paragraphs one sequence diagram might show the idea instantly to the reader much better than all the words.

Separation of diagram drawing software (Visio, Dia, ...) from your main documentation system (Google Docs, Latex, doxygen, ...) is not a good idea. Having no access to source of the diagram makes modification much harder to do (when original author is not available, you have, actually, re-draw the diagram from scratch to fix some minor change).

Text-based diagrams and some form of post-processing is the answer to above problem. You embed your documentation AND the diagrams in the document and tools change those into graphics when needed. Example of such systems cooperation is doxygen and plantuml.

Let's see how easy sequence diagram could be expressed in plantuml:

@startuml{sequence.png}
MainProcess -> Library: FacadeCall()
Library -> SSO: GetToken()
Library -> Server: CallService(token)
Server -> SSO: IsTokenValid(token)
@enduml

The result is rendered as diagram below:

There are more advanced functionality there, but I hope you have already caught the idea.

Next diagram type I'd like to explore is state diagram:

Meeting "minutes" in three simple steps

Nobody likes it. It's a boring duty you ought to do after a meeting. What? "Minutes", of course.

By "minutes" I mean: a note from the meeting (or a telco) that should be sent after a call to all participants involved in order to remind what has been agreed on the meeting and what action items are specified and who is responsible for implementation.



Is there a way to make this very useful tool more effective? The answer is: YES!

First of all: lets enumerate expected properties of those "minutes":

• easy to write
• do not skip/forget anything important
• allow to control if every action item has an assignee

Having above properties in mind I've implemented the following process using an online documents solution (Google Docs, to be specific):

• I send proposed agenda as online document link to every participants and I allow them to extend it if needed
• During the call I (or any participant) add action items and responsible persons to the document. Remember: concurrent editing is fun!
• A copy the document is sent after the call in the same e-mail thread as invitation
• And now: the previous step delivers your team "minutes"! Voila!

Everyone has R/W access to the document and this is the gag - you can delegate your job to add notes and complete document (including completeness checks) to meeting participants. They enjoy that as they're involved in the meeting flow and the output directly. Nobody is bored.

To speed things up you can add timestamp to each agenda item. Such meeting could never miss allocated time!

Implementation tracking is also easy - you can add ticket tracking ID (Jira, Redmine) to the minutes and assign appropriately.

Happy (not boring) meetings! :-)

Why EDID/HDCP information is important in monitoring solutions

EDID stands for "Extended Display Identification Data" and in IPTV solutions is used to provide detailed information on TV set capabilities and manufacturing information. HDCP ("High-bandwidth Digital Content Protection") is used for protecting high resolution content from being stolen by DVR. We typically count failed and successful HDCP connections.  This data is usually reported to central server using TR-69 protocol and/or proprietary protocols like Agama.

STB Development: TFTP+NFS boot methods - for dummies :-)

STB (Set Top Box) devices usually run from NAND partitions. All the rootfs is persisted in read-only filesystem (squashfs) and mounts additional R/W locations if needed (ramdisk for /tmp storage, at least). This setup works quite well for final deployment, but might be a bit problematic if you, actually, develop software stack and need to update and test many times per day.

This is the place where long-time forgotten network boot method comes to play.

In the old days (university) I remember "thin Solaris clients" that were used for programming classes. They had no hard disk and booted from network. What the boot process does look like?

Buildroot basics

If you are an embedded software developer like me chances are you use embedded Linux for the purpose. It's Open Source, has great tools support and is a great software environment where (almost) everything could be automated through command line interfaces.

Once you decide about operating system used the next step is to choose a build system that would be used for the task of building the software. There are few choices you can select from:

• use pre-built toolchain and rootfs and add your binaries and configuration files (i.e. STLinux for ST-based devices)
• use OpenEmbedded for full-featured buildsystem with packaging system included
• use BuildRoot for simple build system without packaging system included

Today I'm going to tell you about the 3rd option. Buildroot states their view on packaging systems for embedded development this way:

We believe that for most embedded Linux systems, binary packages are not necessary, and potentially harmful. When binary packages are used, it means that the system can be partially upgraded, which creates an enormous number of possible combinations of package versions that should be tested before doing the upgrade on the embedded device. On the other hand, by doing complete system upgrades by upgrading the entire root filesystem image at once, the image deployed to the embedded system is guaranteed to really be the one that has been tested and validated.

After few years with OpenEmbedded and few months with Buildroot I like the simplicity of Buildroot model. Below you can find basic (the most important in my opinion) concepts of Buildroot.

[SOLVED] VPN connectioin error: short read (-1): Message too long

If you encounter the following error during VPN connection:

pptp[12549]: nm-pptp-service-12543 warn[decaps_gre:pptp_gre.c:331]: short read (-1): Message too long

there's an easy fix. You have to lower your MTU (automatically obtained value was invalid).

First, you have to locate your VPN gateway address in syslog:

NetworkManager[11926]: <info> VPN Gateway: X.X.X.X

Then, you have to check minimum MTU toward this address:

$ traceroute --mtu X.X.X.X
traceroute to X.X.X.X (X.X.X.X), 30 hops max, 65000 byte packets
1  192.168.43.1 (192.168.43.1)  4.309 ms F=1380  4.042 ms  2.535 ms
2  * *^C

Then you have to change MTU it in your primary connection settings (network manager on Ubuntu below):



That's all!. No more spurious disconnects!

PayU apologizes for ...

The best idea PR guys from PayU might have:

Dear Sir or Madam,

We would like to apologize for the INCORRECT INFORMATION in our last communication.

During the break which will take place on 27 November 2014 from 05:00 am to 05:30 am you could not be able to log in into the system but all transactions WILL BE SETTLED. A message informing about unavailability of the service may be displayed during login attempt.

We are very sorry for the inconvenience and misrepresentation.
--
Kind regards,
PayU Team

The funny thing is that I haven't got any e-mail on the technical break in the first place.

LOL.

Easy SSLv3 "poodle" vulnerability test (and the fix for Jboss/Tomcat)

Recently new vulnerability ("poodle") has been discovered in SSLv3 protocol. "man in the middle" attack could be performed using protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 then exploit the "poodle" vulnerability.

In order to remove the threat from our servers we have to drop SSLv3 from negotiation list. Secured server should respond as follows:

$ echo | openssl s_client -connect 192.168.1.100:80 -ssl3 2>&1 | grep Secure
Secure Renegotiation IS NOT supported
$ echo | openssl s_client -connect 192.168.1.100:80 -tls1 2>&1 | grep Secure
Secure Renegotiation IS supported

We use openssl command to open HTTPS connection and check if requested protocol could be negotiated or not.

And the fix itself (for JBoss/Tomcat service): you have to locate Connector tag responsilble for HTTPS connection and:

• remove any SSL_* from ciphers attribute
• limit sslProtocols="TLSv1, TLSv1.1, TLSv1.2"

Example:

<Connector port="80" protocol="HTTP/1.1" SSLEnabled="true" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
maxThreads="100" scheme="https" secure="true" minSpareThreads="25" maxSpareThreads="50"
keystoreFile="${jboss.server.home.dir}/conf/tm.keystore" keystorePass="MyKeyStore1"
clientAuth="false" sslProtocols="TLSv1, TLSv1.1, TLSv1.2" />

It will effectively block any SSLv3 connections as visible by "openssl s_client" test above.

Simple mailing list on Debian in 3 simple steps

Few days ago I launched simple low-traffic mailing list using naive /etc/aliases method, but got the following error:

<example1@onet.pl> (expanded from <example@myserver.com>): host
mx.poczta.onet.pl[213.180.147.146] said: 554 5.7.1 <example1@onet.pl>:=
Recipient address rejected: Spf check: fail (in reply to RCPT TO command)

If you think for a moment the reason for error it's obvious. My server tried to forward e-mail using original From address.Onet.pl checked TXT record (using SPF standard) for my server domain myserver.com and noticed it's not allowed to send e-mails from me.

In order to make things work properly one have to rewrite envelope From field properly. Mailing list managers usually do that properly (/etc/aliases is not enough).