Trying to build packetbeat for Raspberry PI (arm64)

Posted by On Filed under IoT, Security No Comments

After my previous article on building filebeat for Raspberry PI 3 B+ (arm64), I now wanted to get a binary for packetbeat, the second most interesting module of elastic beats. I tried the same approach with cross-compiling using GOARCH=arm64 but it fails, while a straight compile for amd64 works. It fails with a message that it excludes all Go files due to build constraints. Issue is that there is probably native C code involved and you cannot cross-compile this beat. I searched posts and tried all options for 2 hours, it does not work.

I tried again on the PI directly, the build is running but if you do a “go install”, it finally gets out of memory (“cannot allocate memory”). Problem is that the PI 3 has only 1 GB of memory and that does not seem to be enough. I tried all kinds of tricks, like setting GOMAXPROC=1, GOGC=70 but njet. The problem also seems to be related to the C build using gcc. You need to install “libpcap-dev” for the “pcap.h” header file using “apt-get install”, otherwise one gets a compile error earlier.  If using “go build -v -x” directly you get this “cannot allocate memory” message from gcc. When using “make” the build gets killed instead. Nevertheless it’s rare are there are reports from people that compile Kubernetes on arm64 RPI 3B like mine. Probably K8s does not contain native C parts like the libpcap in packetbeat. So I finally gave up, because …

But … there is good news ahead! Since a few days, the new Raspberry PI 4 Model B has been released! With up to 4 GB memory that will hopefully work. Also it has now true GB LAN, which is for network sniffing, not a bad idea either, when attaching it to a real network tap. So that is a clear buying plan for Juli!

Gradle

Posted by On Filed under Technology No Comments

For all my professional career, I have been involved in software build systems, starting with Make, Imake, Ant, Maven etc. Currently we use Ant at blue elephant but the build is huge, hard to maintain and totally unmodular. No point, that one could also do it better in Ant or let yourself subjugate on the rigid conventions of Maven. But what I was looking for is to minimize efforts of migration, be flexible to do things a bit adapted but still have the nice convention based build and especially the dependency management of maven.
It turns out that there is indeed a optimal solution for it and it comes with the name Gradle. We are anyhow using a lot of Groovy (see earlier posts), which is for me the optimal scripting language. Gradle is well documented, in contrast to the ever mystic maven, it is non-XML using a Groovy DSL as notation and it can use Ant tasks and scripts, which eases migration a lot. And anyhow, there some things in Ant that are unparelleled elsewhere, like the fileset-based operations and there are tons of Ant tasks out there, like xmltask, scp etc. that it would be dump to re-implement just for the fun of it.

Also there seem to be a lot of enthusiastics for Gradle, like this blog. And there is one fan more, so we will soon see some Gradle in MIDAS probably …