Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the packaging metadata to build the netdata snap #1991

Closed
wants to merge 4 commits into from

Conversation

come-maiz
Copy link
Contributor

No description provided.

@come-maiz
Copy link
Contributor Author

To test this in ubuntu 16.04:

$ sudo apt install snapcraft git
$ git clone https://github.com/elopio/netdata
$ cd netdata
$ git checkout snapcraft
$ snapcraft
$ sudo snap install --dangerous --classic
$ netdata

Note that there is a big bug here because the path of the build machine gets hardcoded into the snap, so it can only be run in this machine and won't work if installed from the ubuntu store. I'm making this PR as suggested by @ktsaou to see if we can find a good solution.

@ktsaou
Copy link
Member

ktsaou commented Mar 21, 2017

thanks!

Regarding the bug: when a snap is installed from the ubuntu store, how it can find its path? At which point the path is known and how?

@come-maiz
Copy link
Contributor Author

Most projects use xdg, so the paths are not absolute, they are relative to $HOME, which will just work in the snap. When a project doesn't follow xdg, it usually has a flag to specify the data dir.

When snaps are run they have a set of environment variables that point to the right location for them to store files. You will see in this PR that I'm trying to use the config from $SNAP_USER_DATA/etc/netdata/netdata.conf, but that doesn't work because of the --install.

There are many ways to fix it. One way would be to add one option to netdata-installer.sh so we can split installation dir from data dir, and call it something like:

./netdata-installer.sh --dont-wait --dont-start-it --install $SNAPCRAFT_PART_INSTALL --data $SNAP_USER_DATA

This $SNAP_USER_DATA would have to be expanded only on runtime, and it will point to the right place in the user's home.

Another option would be for netdata to search for the files in $XDG_DATA_HOME or $XDG_CONFIG_HOME.

'm not really sure if this answers your question.

@ktsaou
Copy link
Member

ktsaou commented Mar 21, 2017

ok. The $HOME idea is very nice.

I also need some persistent storage. Something that will remain in the target system and will not be moved with the snap. I use this for 2 simple text files: a machine unique id and the alarms log.

Does snap support this?

@come-maiz
Copy link
Contributor Author

If it's machine specific, you can put it in $SNAP_COMMON. If it's user specific, you can put it in $SNAP_USER_COMMON. Here you can find more details about the variables: https://snapcraft.io/docs/reference/env I think that fits your use case, but also remember that we are on active development. If you need something that snaps don't yet provide, we'll put it in our backlog.

@ktsaou
Copy link
Member

ktsaou commented Mar 22, 2017

ok. I have 3 options:

  1. hardcode xdg or whatever in netdata - I don't like it since settings suitable for you, may break something else and forcing xdg in all cases might be too complex.

  2. support environment variable look ups for paths - a bit complex to do, to support it properly.

  3. provide command line parameters to set all the directories, when starting netdata, so the wrapper script will be able to do whatever it likes.

Will option 3 be good for you?

@come-maiz
Copy link
Contributor Author

come-maiz commented Mar 22, 2017 via email

ktsaou added a commit to ktsaou/netdata that referenced this pull request Mar 22, 2017
@ktsaou
Copy link
Member

ktsaou commented Mar 22, 2017

ok, this is what I did:

You can use command line parameters to overwrite any of netdata.conf settings.

The netdata.conf options that might be of interest for this are:

[global]
	config directory = /etc/netdata
	log directory = /var/log/netdata
	plugins directory = /usr/libexec/netdata/plugins.d
	web files directory = /usr/share/netdata/web
	cache directory = /var/cache/netdata
	lib directory = /var/lib/netdata
	home directory = /var/cache/netdata
	host access prefix = 
	run as user = netdata

[web]
	# web files owner = netdata
	# web files group = netdata
	# default port = 19999
	# bind to = *

[plugins]
	PATH environment variable = < by default same as $PATH >
	PYTHONPATH environment variable = < by default empty >

In detail:

config directory

the directory where all user configuration files should be. The default is determined at compile time.

log directory

the directory where netdata will save its log files. The default is determined at compile time.

plugins directory

the directory where all netdata plugins are. The default is determined at compile time.

web files directory

the directory where all static web files are. The default is determined at compile time.

cache directory

the directory where all chart data will be saved to. This is only used when memory more is ram or map. The default is determined at compile time.

I don't know if this should be persistent. If we decide that only one netdata should be running at a host at any given time, these could be persistent.

lib directory

the directory where a few key files about of the operation of netdata are kept. This should be persistent. The default is determined at compile time.

home directory

the directory netdata will be while running. It is not used for anything currently. The default is determined at compile time.

host access prefix

This is used when running in containers, to access the host's /proc or /sys. Since the snap will be --dangerous --classic we don't need it.

run as user

The user to run as.

If netdata is started as root, it will try to switch to this user.
If netdata is not started as root, this is internally set to the user netdata runs as.

web files owner and web files group

netdata checks the ownership of the files it serves. If their ownership does match the above, it refuses to serve them.

The default is to use run as user for both.


the others I think are self-explanatory.


how to set them on the command line

/path/to/netdata -W set section "option" "value"

You can add this, any number of times.

So, something like:

/path/to/netdata \
    -W set global "config directory" "/snap/X/etc" \
    -W set global "log directory" "/snap/X/log" \
    -W set global "plugins directory" "/snap/X/plugins" \
    -W set global "cache directory" "/snap/X/data" \
    -W set global "lib directory" "/path/to/persistent/storage" \
    -W set global "home directory" "/tmp" \
    -W set web "web files owner" "user" \
    -W set web "web files group" "group"

netdata also supports the option -c that sets the full path to netdata.conf. The position of -c in the command line is important:

  1. If you place -c /path/to/netdata.conf, before all -W set ... parameters, the user may use netdata.conf to overwrite your command line parameters.
  2. If you place it after all -W set ... parameters, the user will not be able to overwrite them.

Will these do?

@NatoBoram
Copy link

Any news on this?

@cakrit
Copy link
Contributor

cakrit commented May 28, 2019

@paulkatsoulakis can you please review this? It's been around forever.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Leo Arias seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

Copy link
Contributor

@paulkatsoulakis paulkatsoulakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A first few basic comments:

  1. Please move all contents under contrib/ubuntu and contrib/ubuntu/snap respectively
  2. Please sign the CLA

@cakrit
Copy link
Contributor

cakrit commented Sep 17, 2019

Closing due to CLA not signed and @paulkatsoulakis' request to move to a different directory not addressed. Please comment if you intend to do another commit and we'll reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants