netdata package maintainers

[ktsaou]

This issue has been converted to a wiki page

For the latest info check it here: https://github.com/firehol/netdata/wiki/netdata-package-maintainers

---

I think it would be useful to prepare a wiki page with information about the maintainers of netdata for the Linux distributions, automation systems, containers, etc.

Let's see who is who:

---

Official Linux Distributions

Linux Distribution	Netdata Version	Maintainer	Related URL
Arch Linux	Release	@svenstaro	netdata @ Arch Linux
Arch Linux AUR	Git	@SanskritFritz	netdata @ AUR
Gentoo Linux	Release + Git	@candrews	netdata @ gentoo
Debian	Release	@lhw @FedericoCeratto	netdata @ debian
Slackware	Release	@willysr	netdata @ slackbuilds
Ubuntu
Red Hat / Fedora / Centos
SuSe / openSuSe

---

FreeBSD

System	Initial PR	Core Developer	Package Maintainer
FreeBSD	#1321	@vlvkobal	@mmokhi

---

MacOS

System	URL	Core Developer	Package Maintainer
MacOS Homebrew Formula	link	@vlvkobal	@rickard-von-essen

---

Unofficial Linux Packages

Linux Distribution	Netdata Version	Maintainer	Related URL
Ubuntu	Release	@gslin	netdata @ gslin ppa #69 (comment)

---

Embedded Linux

Embedded Linux	Netdata Version	Maintainer	Related URL
ASUSTOR NAS	?	William Lin	https://www.asustor.com/apps/app_detail?id=532
OpenWRT	Release	@nitroshift	openwrt package
ReadyNAS	Release	@NAStools	https://github.com/nastools/netdata
QNAP	Release	QNAP_Stephane	https://forum.qnap.com/viewtopic.php?t=121518
DietPi	Release	@Fourdee	https://github.com/Fourdee/DietPi

---

Linux Containers

Containers	Netdata Version	Maintainer	Related URL
Docker	Git	@titpetric	https://github.com/titpetric/netdata

---

Automation Systems

Automation Systems	Netdata Version	Maintainer	Related URL
Ansible	git	@jffz	https://galaxy.ansible.com/jffz/netdata/
Chef	?	@sergiopena	https://github.com/sergiopena/netdata-cookbook

---

If you know other maintainers of distributions that should be mentioned, please help me complete the list...

cc: @mcnewton @philwhineray @alonbl @simonnagl @paulfantom

[candrews]

You can set the "Related URL" for Gentoo to https://github.com/gentoo/gentoo/tree/master/net-analyzer/netdata

[ktsaou]

You can set the "Related URL" for Gentoo to https://github.com/gentoo/gentoo/tree/master/net-analyzer/netdata

Thanks! Done.

[jasonwbarnett]

@ktsaou It should probably be:

RHEL == CentOS (just rebranded and a few other nuances)
Fedora is where things are tested before being released to RHEL

• RHEL/CentOS
• Fedora

[ktsaou]

RHEL == CentOS (just rebranded and a few other nuances)

ok, fixed that. Although there are differences. I decided to treat separately when I found this: https://github.com/firehol/netdata-demo-site/blob/28c7962d28a942c5321e8475f51d5b17dd48a884/install-required-packages.sh#L653

[ktsaou]

I meant this: https://github.com/firehol/netdata-demo-site/blob/28c7962d28a942c5321e8475f51d5b17dd48a884/install-required-packages.sh#L613-L616

[NAStools]

I'm maintaining netdata for NETGEAR ReadyNAS @ https://github.com/nastools/netdata

[ktsaou]

I'm maintaining netdata for NETGEAR ReadyNAS

nice. Thank you!

Please make sure the directory /var/lib/netdata/registry is empty on your distribution package. There is an embedded devices package that distributes netdata with the unique id file pre-installed. This makes all these netdata installations appear as the same one to the global registry..

[jasonwbarnett]

ok, fixed that. Although there are differences. I decided to treat separately when I found this: https://github.com/firehol/netdata-demo-site/blob/28c7962d28a942c5321e8475f51d5b17dd48a884/install-required-packages.sh#L653

I just submitted this PR to correct that repo. Not sure how those packages made it in the repo, but they're wrong.

[NAStools]

Please make sure the directory /var/lib/netdata/registry is empty on your distribution package.

I'm building with dh-autoreconf and don't end up with a registry directory. Do I need to be including this?

root@readynas:/apps/nastools-netdata# find . -name registry
root@readynas:/apps/nastools-netdata#

[ktsaou]

I'm building with dh-autoreconf and don't end up with a registry directory. Do I need to be including this?

The installation should only create /var/lib/netdata. The rest are created by netdata itself. It is ok.

[FedericoCeratto]

Can you please add https://anonscm.debian.org/git/collab-maint/netdata.git for Debian (and maybe put in my name as well?) Thanks

[ktsaou]

Can you please add https://anonscm.debian.org/git/collab-maint/netdata.git for Debian (and maybe put in my name as well?) Thanks

done. thanks!

I would love to provide a binary package and probably a PPA for users to install it easily on debian based distributions, until the distros include it. I am completely ignorant of the procedure - I have tried to do it a few times, but it is totally counter-intuitive for me. Can you help me?

[ktsaou]

oh! I replaced @lhw with @FedericoCeratto . Do you want me to add @lhw back, to list both of you?

[FedericoCeratto]

@ktsaou we are both maintaining the package and lhw did a lot of work :)

[ktsaou]

Added @lhw back, together with you.

[jffz]

Just updated the ansible role and uploaded it into ansible galaxy.

You can retrieve the whole playbook here : https://galaxy.ansible.com/jffz/netdata/

Direct usage with ansible-galaxy: ansible-galaxy install jffz.netdata

[ktsaou]

updated the link above to point to https://galaxy.ansible.com/jffz/netdata/

[jffz]

Maybe you can delete "
https://github.com/jffz/ansible-netdata/blob/master/tasks/main.yml" to
avoid any mistake.

But i guess both chef and ansible books should be linked somewhere in the readme / wiki for easier retrieving.

[ktsaou]

You mean https://github.com/firehol/netdata/blob/master/ansible/netdata.yml ?

[jffz]

yeah sorry, i pasted a wrong link

[ktsaou]

done is #1123

[thinrope]

I have been (trying to) following the (amazing amount of) development in this project... Quite a few new features were merged (fping, DBs, external backend come to mind), is there any timeframe for a new release?
It will help iron out a few more things, without having "old" users complain like when they had to switch between gnome2/3 or WinXP/7 :-)

[ktsaou]

I think in 1-2 weeks v1.5 will be out.
We need some time to test all new features.

[titpetric]

Done, hub version is published. Next/docker image will replace ssmtp most likely (a PR is in the works), so there will be some changes regarding readme and such.

[FedericoCeratto]

This might be useful: https://repology.org/metapackage/netdata/badges :)

[rickard-von-essen]

Add me as macOS Homebrew formula.

[ktsaou]

Add me as macOS Homebrew formula.

added you. Thank you for supporting netdata!

[ktsaou]

If you know who is the netdata package maintainer for alpine, please invite him here. It seems the latest package on alpine is broken #3897

[rickard-von-essen]

Alpine Linux netdata package source: https://git.alpinelinux.org/cgit/aports/log/?qt=grep&q=Netdata

[rickard-von-essen]

netdata/APKBUILD

# Contributor: Carlo Landmeter <clandmeter@gmail.com> 
# Maintainer:

[ktsaou]

nice finding!

@clandmeter are you the netdata package maintainer for alpine?

[paulfantom]

@ktsaou is list of maintainers from #651 (comment) up to date? I am currently in process of writing new ansible role for netdata as I've tried @jffz one some time ago, but he is unresponsive and my PRs are waiting and waiting. I want to include option to install netdata not only from source (I don't want to install build tools on multiple servers), but also from pre-built repository packages. While writing I need to checked some of those repos, and alternative ones as I want to support systems I usually support with my roles:

• Ubuntu 16.04 & 18.04
• Debian 8 & 9
• CentOS 7
• Fedora 27

What I found:

• "Related URL" for debian official distro doesn't work
• debian 8 doesn't have netdata included, so the table is a bit misleading
• Fedora and CentOS have natdata packages (1.10) in copr (https://copr.fedorainfracloud.org/coprs/baoboa/netdata/ and https://copr.fedorainfracloud.org/coprs/tartare/netdata/), maybe consider adding them?
• there is actually an official package for netdata (1.9.0) in ubuntu 18.04 maintained by @lhw, at least that's what apt show netdata says

There are possibly more things lacking, but I found that in current state it is impossible to support all those repo combinations in one ansible role, so I decided to use official releases and install it all by myself with ansible. Hopefully it will be ready soon and we all be able to install netdata faster on multiple devices at once (compile on one device - install on many). 😄

[lhw]

@paulfantom If you want to check debian package status it's actually easier to just go to the package tracker: https://tracker.debian.org/pkg/netdata
So for now its up-to-date but you are right it's not in debian 8 at least not officially and even in debian 9 it's only in the backports. And Ubuntu packages are simply pulled from debian testing which was 1.9.0 at the time.

@ktsaou The URL for debian has changed as debian switched to gitlab its now http://salsa.debian.org/debian/netdata but you could also use the tracker URL from above.

[ktsaou]

ok guys I converted this to a wiki page: https://github.com/firehol/netdata/wiki/netdata-package-maintainers

So, feel free to edit it to reflect the current status.

[ktsaou]

updated also the original post to divert to the wiki.

[paulfantom]

Wiki page is now at https://github.com/netdata/netdata/wiki/netdata-package-maintainers.

Closing as this information is tracked in wiki.

[paulfantom]

@lhw @FedericoCeratto do you need GPG signature for tar packages of netdata? If yes, why?

[FedericoCeratto]

@paulfantom the signature is optional and it's meant to ensure the authenticity and integrity of the tarball

[paulfantom]

Great! 👍 So it is not crucial if you are downloading from github via HTTPS. In such scenario source authenticity is achieved by downloading using github and transport security is achieved by using HTTPS. And if someone would gain access to our code on github, then GPG signature won't prevent anything since archive signing is in travis.

As for integrity there is always a checksum.

[FedericoCeratto]

HTTPS provides limited security (there has been many issues) and only for data in transit (not at rest). GPG signatures from Travis or other 3rd party services are not accepted - the tarball has to be signed directly by the author.

[paulfantom]

It is not provided directly by an author, that's why I want to remove GPG signature.

[philwhineray]

The GPG signatures are only on source files and are currently provided directly by an author.

I don't have a strong view about what happens going forwards but for reference, the current process is:

1. a GPG-signed tag is created
2. this is checked by the travis build. it does not add anything directly but just makes sure later steps should work
3. a script, sign-github-release from the firehol/infrastructure repo is run on the developer's machine where signing will take place. This takes a clean copy of the repo and checks the source signature. If then downloads the release source tar from github and if the contents match, prompts the dev to sign. It then uploads the signature back to the github release.

If you are thinking to replace the tagging with a system which does so automatically, e.g. based on the content of a PR, I think the signatures can still be produced without opening much of a hole.

The script in (3) would need to be updated not look for a signature, and any manual checks that the tag is good move from before tagging (otherwise the git gpg signature did nothing anyway) to after.

I should note as well at this point that the checks in said script are not perfect. They don't check files added by Travis since we have no way to independently verify them, much as with binary output. The key suspects I would suggest are those produced by autoconf/automake, so if you distrust Travis, or the possibility that the tar could be interfered with between upload by travis and download for checking before signing, whilst the sources should be sound, running autoreconf in your own trusted environment would be a good idea.

[philwhineray]

Source tar signatures could still be produced without changing much that is. I'm not suggesting signed tags from Travis, to be clear.

[paulfantom]

Plan is to have fully automated reproducible build and release system which could be easily extended to provide binary packages (via repository). Whole thing needs to be as simple as possible for two reasons. First is to allow other people see how it is created (without magic) and second is to allow for very fast release cycle, where we can have "nightly" packages every 24h and "stable" ones every 2-4 weeks. This means that system will probably be highly opinionated, so if something is only optional and doesn't have much value, it is just a complication which needs to be removed.

This doesn't mean that we won't sign packages, we will, but binary packages. In future we will probably drop tarball generation by travis since GitHub automatically creates archives with code when creating a release.

[ktsaou]

Dear all netdata release v1.11 is currently in draft.
We will do some tests during the weekend and publish it on Mon or Tue.

A lot have changed in this release. The whole release procedure has been rewritten, stock config files have been moved to /usr/lib/netdata, etc.

The draft release message describes everything in more detail.

[candrews]

Well, it's already in Gentoo: https://github.com/gentoo/gentoo/tree/master/net-analyzer/netdata