i think the filter syntax in the bonsai config might be slightly off.
I'm not sure if its a problem with how the back end is interpretting the yaml and converting it to json. or what.

But when I pull from bonsai, the resulting config is malformed linux needs to be in quotes to prevent errors.

I found that the Dockerfile in this repository build on alpine:latest, that match 3.9.4 as of today and this ruby runtime build doesn't work with Alpine 3.8 official sensu image.

I only changed to alpine:3.8 and it's working.

Is it expected to have a repository that doesn't match the official sensu docker image ?

The docker images should be pruned enough so they can be used as a blank slate for building gems that need native extensions in a clean manner to avoid packaging conflicts if altnerative library implementations need to be used.

Ex: Alpine image includes openssl-dev which conflicts with ressl-dev as ressl and openssl are ABI incompatible implementations on ssl's API.

This is my Docker file.
FROM arm64v8/centos:7

ARG RUBY_VERSION=2.4.4
ARG ASSET_VERSION=local_build
ARG GREP_EXCLUDE='(ld.so|ld-linux-x86-64.so|libBrokenLocale.so|libSegFault.so|libanl.so|libc.so|libdl.so|libm.so|libmvec.so|libnss_compat.so|libnss_dns.so|libnss_files.so|libpthread.so|libresolv.so|librt.so|libthread_db.so|libutil.so|vdso.so)'

RUN yum update -y && yum groupinstall -y "Development Tools" && yum install -y curl
ENV http_proxy=http://172.20.22.18:1081
ENV https_proxy=https://172.20.22.18:1081

RUN curl -L https://github.com/postmodern/ruby-install/archive/v0.7.0.tar.gz -o ruby-install-0.7.0.tar.gz &&
tar -xzvf ruby-install-0.7.0.tar.gz &&
cd ruby-install-0.7.0/ &&
make install &&
ruby-install ruby ${RUBY_VERSION} -- --enable-load-relative --disable-install-doc

RUN PATH=$PATH:/opt/rubies/ruby-${RUBY_VERSION}/bin/ && gem install ffi

Add by luke

RUN PATH=$PATH:/opt/rubies/ruby-${RUBY_VERSION}/bin/ && gem install -E sensu-plugins-process-checks
sensu-plugins-network-checks sensu-plugins-memory-checks sensu-plugins-load-checks sensu-plugins-cpu-checks
sensu-plugins-disk-checks sensu-plugins-ssl sensu-plugins-io-checks sensu-plugins-filesystem-checks
sensu-plugins-load-checks sensu-plugins-raid-checks sensu-plugins-uptime-checks

RUN yum install -y sysstat
RUN mv /usr/bin/iostat /opt/rubies/ruby-${RUBY_VERSION}/bin/

end

RUN LIBS=$(find /opt/rubies/ruby-${RUBY_VERSION} -type f -executable -exec ldd {} 2>/dev/null ;| grep "=>" | egrep -v ${GREP_EXCLUDE} | awk '{print $3}'| sort -u ) &&
for f in $LIBS; do if [ -e $f ]; then echo "Copying Library: $f" && cp $f /opt/rubies/ruby-${RUBY_VERSION}/lib/; fi; done

RUN mkdir /assets/ &&
export SENSU_ASSET="/assets/sensu-ruby-runtime_${ASSET_VERSION}ruby-${RUBY_VERSION}$(source /etc/os-release && echo $ID$VERSION_ID)_$(uname -s | tr '[:upper:]' '[:lower:]')_amd64.tar.gz" &&
tar -czf $SENSU_ASSET -C /opt/rubies/ruby-${RUBY_VERSION}/ .

ENV PATH=$PATH:/opt/rubies/ruby-${RUBY_VERSION}/bin

when I create the asset. it can not running okay.

Then I test on the system, if I change the /var/cache/sensu/sensu-agent/338b88b568a3213fa234640da2e037d1487fc3c639bc62340f2fb71eac8af9a90566cffc768d15035406ac5c049350006d73f3a07ae15f9528e1c6a9af2944cb to some short path, It works fine.

How can I fix the problem.

We have users and customers who monitor OSX devices. Currently, neither the runtime or the embedded Sensu project are available for OSX. Can we build the runtime for OSX?

@jspaleta is there any way we can get an Ubuntu build going here?

Alpine is unique, and defaults to using ressl as its preferred ssl implementation.

We should build against ressl on alpine to avoid later package conflicts when people try to build against ssl libs. This cropped up trying to get sensu-plugins-postgres up and running.

Status: Downloaded newer image for sensu/sensu-ruby-runtime-2.4.4-centos6:latest
--
940 | ---> e4b4eafe3204
941 | Step 2/12 : ARG ASSET_GEM
942 | ---> Running in 47b0628b19d3
943 | Removing intermediate container 47b0628b19d3
944 | ---> 4c64dedc58e7
945 | Step 3/12 : ARG GIT_REF
946 | ---> Running in b8e4b704e0d4
947 | Removing intermediate container b8e4b704e0d4
948 | ---> 2fb2949fe8a0
949 | Step 4/12 : ARG GIT_REPO
950 | ---> Running in aeb29587434a
951 | Removing intermediate container aeb29587434a
952 | ---> c4c179141207
953 | Step 5/12 : WORKDIR /assets/build/
954 | ---> Running in 4ea5252b3b3b
955 | Removing intermediate container 4ea5252b3b3b
956 | ---> d1a843a991a6
957 | Step 6/12 : RUN yum install -y git
958 | ---> Running in af676f3156b0
959 | Loaded plugins: fastestmirror, ovl
960 | Setting up Install Process
961 | Determining fastest mirrors
962 | Error: Cannot find a valid baseurl for repo: base
963 | YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
964 | Eg. Invalid release/repo/arch combination/
965 | removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
966 | The command '/bin/sh -c yum install -y git' returned a non-zero code: 1
967 | Unable to find image 'ruby-plugin-centos6:latest' locally
968 | Error response from daemon: pull access denied for ruby-plugin-centos6, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
969 | must specify at least one container source

https://drone.m-cloud.cz/VeselaHouba/sensu-plugins-disk-checks/42/2/3

So now that we have some ruby plugins out in the wild that rely on this, there's a question of versioning.

right now we encode the ruby version in the docker images generated from this repository.
But maybe we should encode both the ruby version and the asset version?

Perhaps what we need is to docker tag names like:

<asset-version>-<ruby-version>-<platform>
or
<ruby-version>-<platform>-<asset-version>

we need the asset version because we build against latest platform base image and might run into a regression.

I can then find a way to have the plugin build automation select/override the asset version to use.

Expected behavior

The Centos 6 asset is able to run ruby code using native extensions compiled against Centos 6 glibc.

Current behavior

The centos 6 asset errors when running ruby code using native extensions.

Reproduction steps

1. Stand up a Centos 6.10 host running the Sensu agent
2. Add assets for version 0.0.10 of sensu-ruby-runtime for centos 6 and version 5.0.0 of sensu-plugins-disk-checks
3. add a check which uses those runtime assets, with check-disk-usage.rb
4. Observe that the check results show an error related to GLIBC_VERSION 2.14 not found -- centos 6.10 is expected to have GLIBC version 2.12

Context

I feel like I've run into similar behavior in the past where using Docker containers to compile binaries for platforms with one version of glibc actually results in binaries linked to the docker host glibc. It might be the case that we cant use Docker for our build process here?

I'm having issues with any ruby sensu plugin that tries to use the sensu-ruby-runtime asset on Ubuntu 18.04. Things work fine on my 16.04 system that is running my sensu backend, but my 18.04 agent throws a library error:

$ check-ports.rb -p 22 -H desire
ruby: relocation error: /var/cache/sensu/sensu-agent/31a3b54b8dabedac5253c07b6c8f11f49a42c0f5a92193675b9c9d02ae00369f15909451ed914b499fe2ad9d67fbed10dd78f4091c00310516ad6c8492a0170b/lib/libpthread.so.0: symbol __libc_dl_error_tsd version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

Installing a libc.so.6 from a 16.04 system into the lib directory above causes a segfault. Trying the libpthread.so.0 from 18.04 causes ruby to segv in lib/ruby/2.4.0/x86_64-linux/enc/encdb.so. I'm assuming this is as simple as getting the right libc.so.6 into the asset, but I'm stumped as to what version that needs to be.

Instead of using the default upstream alpine,centos,debian images, use the latest official Sensu container images as a base image if possible for the platforms we support.

OS Version
CentOS 7.6.1810

Release
0.1.0

Issue
Requiring 'yaml' in an asset fails. Attempting to run a require statement manually from irb gives the following output

[root@my_neat_host bin]# ./irb
irb(main):001:0> require 'yaml'
/var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/yaml.rb:5:in `<top (required)>':
It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.
LoadError: libyaml-0.so.2: cannot open shared object file: No such file or directory - /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/x86_64-linux/psych.so
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/psych.rb:8:in `<top (required)>'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/yaml.rb:6:in `<top (required)>'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from /var/cache/sensu/sensu-agent/2d7800432f90625a02aec4a10b084bc72e253572970694e932b5ccdc72fb30f5cf91ed4b51f90942965df5228e521b8f5f06da3d52b886b172ba08d4130251dc/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'

Don't know if this is expected behavior but it seems to be hit or miss whether or not standard libraries load correctly. Running ./gem also fails in a similar fashion. Please let me know if I can provide any more info here. Thanks

Hi Sensu Dev,

According to the official ruby site, the current version will be EOF.
Are you going to do something with it?

Thanks.

https://www.ruby-lang.org/en/news/2019/10/02/ruby-2-4-9-released/

Ruby 2.4 is now under the state of the security maintenance phase, until the end of March of 2020. After that date, the maintenance of Ruby 2.4 will be ended. We recommend you start planning the migration to newer versions of Ruby, such as 2.6 or 2.5.

Not sure what is going on, as I thought the alpine 3.8 base image was the fix for this problem.
as described in issue #15

Quick steps to reproduce...
build alpine and alpine3.8 runtime docker images locally using ./build.sh
edit the platform list down if you want to save time

you should get docker images:
sensu-ruby-runtime-2.4.4-alpine:local-build
sensu-ruby-runtime-2.4.4-alpine3.8:local-build

now try to locally compile assets for sensu-plugins-http:

from inside the sensu-plugins-http directory run:

bash -c "[ ! -d bonsai/ ] && git clone https://github.com/sensu/sensu-go-bonsai-asset.git bonsai || echo 'bonsai/ exists, skipping git clone'

then edit bonsai/ruby-runtime/Dockerfile.alpine and bonsai/ruby-runtime/Dockerfile.alpine3.8 to use the local-build of the runtime you just did

edit the bonsai/ruby-runtime/travis-build-ruby-plugin-assets.sh and reduce the platforms to just alpine and alpine3.8

run the bonsai/ruby-runtime/travis-build-ruby-plugin-assets.sh script and watch it fail to compile a native ext.

In the end, the trick which made this work was a Ruby make configure flag called load-relative which causes ruby to resolve load paths at runtime (dynamically): https://github.com/ruby/ruby/blob/d48783bb0236db505fe1205d1d9822309de53a36/configure.ac#L145-L147

The ruby-install project does provide some niceties in the form of features (and anti-features) as it describes in its readme:

## Features

* Supports installing arbitrary versions.
* Supports downloading the latest versions and checksums from [ruby-versions].
* Supports installing into `/opt/rubies/` for root and `~/.rubies/` for users
  by default.
* Supports installing into arbitrary directories.
* Supports downloading from arbitrary URLs.
* Supports downloading from mirrors.
* Supports downloading/applying patches.
* Supports specifying arbitrary `./configure` options.
* Supports downloading archives using `wget` or `curl`.
* Supports verifying downloaded archives using `md5sum`, `md5` or `openssl md5`.
* Supports installing build dependencies via the package manager:
  * [apt]
  * [dnf]
  * [yum]
  * [pacman]
  * [zypper]
  * [pkg]
  * [macports]
  * [brew]
* Has tests.

## Anti-Features

* Does not require updating every time a new Ruby version comes out.
* Does not require recipes for each individual Ruby version or configuration.
* Does not support installing trunk/HEAD.

...but we don't need all of these features. If we wanted to reduce ruby-install as an external dependency, we would likely need to refactor the Dockerfile to fetch and validate source SHAs, and recreate the required ./configure options (including --enable-load-relative).

Please add license information to this repo, as it may be used as a template for other Sensu/Bonsai assets

Hello Sensu team.
When you are planning to add support for Windows?

Current Centos builds are based on Centos 7 and won't run on Centos 6:

ruby: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ruby) ruby: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by ruby) ruby: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /var/cache/sensu/sensu-agent/1c9f0aff8f7f7dfcf07eb75f48c3b7ad6709f2bd68f2287b4bd07979e6fe12c2ab69d1ecf5d4b9b9ed7b96cd4cda5e55c116ea76ce3d9db9ff74538f0ea2317a/lib/libcrypt.so.1)

Problem:
the ruby-install process installs several dynamically linked C libraries as part of the ruby install.
Inspecting these shared libraries indicates several system libraries are being linked and we are basically hoping that the running environment will provide them.

Right now we aren't making an effort to include the system libraries in the built asset, but this is going to lead to problems for specific gems that end up required impacted ruby modules. Not all gems...so its hard to predict what will fail.

Currently manifests as missing openssl shared library in the sensu-plugins-http asset.

Solution:
use ldd in scripted fashion to determine the full set of system libraries to include in the asset.

Complication
Need to do something with regard to providing licensing information for each included library

The ruby build environment has a error causing the build of some native extensions like unf_ext to fail with errors like:

error: 'int isinf(double)' conflicts with a previous declaration RUBY EXTERN int isinf(double)

Found this trying to use bundle install to install ruby-plugins-http from inside the alpine docker image

This problem doesn't impact the debian container

Not sure how to fix this... it has something to do with setting

ac_cv_func_isnan=yes ac_cv_func_isinf=yes

Reference:
gliderlabs/docker-alpine#261

When running check-ping.rb from sensu-plugins-network-checks, using the --report flag shells out to mtr.

On Ubuntu 18.04 using Debian builds sensu-ruby-runtime 0.10, this combination causes a linking error:

mtr: /var/cache/sensu/sensu-agent/a28952fd93fc63db1f8988c7bc40b0ad815eb9f35ef7317d6caf5d77ecfbfd824a9db54184400aa0c81c29b34cb48c7e8c6e3f17891aaf84cafa3c134266a61a/lib/libz.so.1: version `ZLIB_1.2.9' not found (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16)

• Reproduce on 0.11
• Fix it

Instead of using 'platform' we should use 'platform family' for debian and rhel so runtime assets can be used across more linux distributions without modification.

Example ubuntu is debian family Centos is rhel family

Hi Team,

I created the runtime asset as follows
{
"type": "Asset",
"api_version": "core/v2",
"metadata": {
"name": "sensu-ruby-runtime",
"namespace": "default",
"labels": {},
"annotations": {}
},
"spec": {
"url": "$URL",
"sha512": "$sha512",
"filters": [
"entity.system.os == 'linux'",
"entity.system.arch == 'amd64'"
]
}
}

hello world asset as follows

{
"type": "Asset",
"api_version": "core/v2",
"metadata": {
"name": "helloworld-v0.1",
"namespace": "default",
"labels": {},
"annotations": {}
},
"spec": {
"url": "$URL",
"sha512": "$SHA512",
"filters": [
"entity.system.os == 'linux'",
"entity.system.arch == 'amd64'"
]
}
}

Created check configuration as follows

{
"type": "CheckConfig",
"api_version": "core/v2",
"metadata": {
"name": "helloworld",
"namespace": "default",
"labels": {},
"annotations": {}
},
"spec": {
"command": "helloworld.rb",
"runtime_assets": ["sensu-ruby-runtime", "helloworld-v0.1"],
"publish": true,
"interval": 10,
"subscriptions": ["linux"]
}
}

Ran sensuctl create -f on all files

Still I am not able to see the check is working
It is giving the error "sh: helloworld.rb: command not found"

Please let me know what I am missing here

libpthread should be taken from OS system not included...for correct operation.

Alpine 3.14 is current alpine container.

This should solve some interesting alpine packaging problems with curl as seen with sensu-plugins-aws latest release