Beats: Move to Debian 8 instead of using Debian 7 for building beats

[ph]

Debian 7 life has ended, our build process depends on Debian7 to build the artifacts since we want to make sure we have an older version of libc. So we have to take the following decision:

• Either we move from Debian 7 to Debian8, we already build our dockers images on top of it. (

• Or if we want to make sure to have an older version of libc around we might consider using Centos for our base docker images instead.

• Skip ahead of Debian8 for libc dependency.

[ph]

See PR https://github.com/elastic/golang-crossbuild/pull/19

[hholst80]

Debian 7 EOL was April 26, 2016. Debian 8 EOL has passed, June 6, 2018, and moving to Debian 8 will not improve the situation. [[1]]

EDIT: Well, somewhat improved situation since Debian 8 will also receive Long Term Support for five years after its initial release with support ending on June 30, 2020. The supported architectures include amd64, i386, armel and armhf. [[2]] My point is - why not skip ahead if you are going to break peoples assumption about what OS underpins the libc dependency why do it in a way that would force you to do the same change within less than one year?

[ph]

@hholst80 All valids points, what we want to do initially is to assess our matrix to make sure what kind of jumps we can do. I will update the description with your suggestion.

[ph]

@mikemadden42 You might want to have that on your radar.

[mikemadden42]

Thanks @ph ; I'll keep this on my radar.

[mikemadden42]

Does it make sense to consider switching to something other than Debian?

CentOS 7 is supported for 10 years, and builds should be pretty compatible.
https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule

Ubuntu also touts 10 years of support, but the last 5 years are marked _Extended security maintenance for customers_. This may mean updates only for paid customers?
https://ubuntu.com/about/release-cycle

[mikemadden42]

If we choose to move from Debian 7, we need to be mindful of glibc versions. If we move to a distro with a newer glibc, binaries built on that operating system will not run on distros with an older glibc version.

For example, if we move to centos 7 for builds, binaries will no longer run on ubuntu 12.04.

| operating system | glibc |
| :----------- | :----------- |
| centos 6 | 2.12 |
| centos 7 | 2.17 |
| rhel 8 | 2.28 |
| ubuntu 12.04* | 2.15 |
| ubuntu 14.04 | 2.19 |
| ubuntu 16.04 | 2.23 |
| ubuntu 18.04 | 2.27 |
| ubuntu 20.04 | 2.31 |
| sles 12 | 2.22 |
| debian 7* | 2.13 |
| debian 8 | 2.19 |
| debian 9 | 2.24 |
| debian 10* | 2.28 |
| amazon linux | 2.17 |
| amazon linux 2 | 2.26 |

• Not currently in the support matrix.

[urso]

Havign run into more problems with debian 7 based build I have had a quick look into glibc and building via debian8. For building I think we can safely switch to either debian 8 or centos 7.

For reference see ABI/API compatibility: https://abi-laboratory.pro/?view=timeline&l=glibc
CentOS glibc: 2.12
Debian 8 glibc: 2.19
Centos 7 glibc: 2.17

Glibc differences (2.12 - 2.19):

• Symbols: 26new, 1 removed
• Backwards compatibility other:
  
  
  
  • Ptrace_request: not use by go runtime
  
  
  • Posix_spawn: darwin syscall code defined, but posix_spawn is not used
  
  
  • clock_x changes: not used by go runtime
  
  
  • Pthread_mutex_s:
  
  
  • On linux One single mutex only used when bootstrapping the runtime. Golang mutexes are build on linux futex
  
  
  • new field has been added, but will not be initialized by older libc
  
  

Notes:

• Go runtime implements most functionality by itself (uses cgo mostly for network)
• Beats won't start if the runtime uses a symbol not available in an older glibc
• the pthread_mutex change could in worst case lead to a crash on startup with very old glibc (not exactly sure, would need to compare implementations between glibc versions to verify)

For testing I used filebeat, by cross building and packaging Filebeat with an debian 8 image. I did unpack and run filebeat from the tar.gz on centos 6 and debian 7 without any problems.

Checking the filebeat binaries build on debian 7, debian 8, and archlinux (glibc 2.31) via objdump -T it looks like the go compiler pins the runtime versions for glibc to an older version anyways. The max ABI is GLIBC_2.3.2. The ABI compatiblity is the same, no matter which glibc version has been used to compile Beats.