Up-to-date filebeat for 32bit Raspbian (armhf)

Fiddling around with ELK recently, I’ve been setting up a log server. Deploying filebeat to my Raspbian (RPi 2, 3, 4, nano) systems turned out somewhat challenging, mostly since elastic doesn’t provide official releases for 32bit ARM. There’s been an open ticket since 2018 asking for official ARM builds, and it seems that elastic is now at least providing .deb packages for 64bit ARM.

This got me thinking, what if I just compile a filebeat armhf binary and repackage the given arm64 .deb file? Turns out, it’s quite easy. Here’s my all-in-one script, tested on x64 Debian 10 and Ubuntu 20.10:

https://gist.github.com/lazywebm/63ce309cffe6483bb5fc2d8a9e7cf50b

The interesting stuff happens in the four last functions. Here’s a rundown:

  • working directory is ~/Downloads/filebeat_armhf
  • get latest golang amd64 package for cross-compiling, extract to working dir, specifically use it’s given go binary (ignore any global installations)
  • get latest filebeat arm64 .deb package
  • clone beats repo, checkout latest release branch
  • build arm (armhf) filebeat binary with new go release
  • repackage given arm64 .deb with new filebeat binary, removing other binary (filebeat-god, seems to be irrelevant), update md5sums file, crontrol file
  • working dir cleanup

Result of this poor man’s CI (at the time of writing) is a new deb file, ready to be deployed on Raspbian: ~/Downloads/filebeat_armhf/filebeat-7.11.2-armhf.deb

I have some further automation in place, deploying the new deb to a publicly available web server. A small puppet module is taking it from there:

if $facts['os']['distro']['id'] == 'Raspbian' {
 
# 'archive' requires puppet-archive module
  archive { '/root/filebeat-7.11.2-armhf.deb':
    ensure => 'present',
    source => 'https://example.com/filebeat-7.11.2-armhf.deb';
  }
 
  package { 'beat':
    provider => 'dpkg',
    ensure   => 'installed',
    source   => "/root/filebeat-7.11.2-armhf.deb",
    require  => Archive['/root/filebeat-7.11.2-armhf.deb'];
  }
 
# fileconfig config with pcfens-filebeat module here
}

Detach running processes from SSH shells

After starting some process in a SSH shell, you’ll begin noticing it takes A LOT longer than anticipated. You want to close the session, but forgot to execute the process within a screen or tmux session. Silly you.

But there’s a solution – suspend the process, put it in the background, and disown it from the current shell. More info about bash’s job control.

To suspend a running process, press Ctrl + Z:

user@remotehost:~# rsync -av /backup/ ~/restore
sending incremental file list
file1
file2
...

Ctrl + Z

[1]+  Stopped                 rsync -av /backup/ ~/restore

Now put the process in the background:

user@remotehost:~# bg
[1]+ rsync -av /backup/ ~/restore

And disown the job, with the job ID given by bg:

user@remotehost:~# disown -h %1

That’s it. Your process has been disassociated from it’s session, and will continue after logging out & closing the shell. There’s one downside, though: stdin and stdout will be redirected to /dev/null, manual double checking after your process finished is recommended. Or use screen next time.

Scroll to top