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

Move web assets to /usr/share/monitorix #294

Closed
lyknode opened this issue Oct 27, 2020 · 5 comments
Closed

Move web assets to /usr/share/monitorix #294

lyknode opened this issue Oct 27, 2020 · 5 comments

Comments

@lyknode
Copy link
Contributor

lyknode commented Oct 27, 2020

Currently, /var/lib/monitorix is used to store two types of content:

  • The rrd files (*.rrd)
  • The web asserts (www/ and reports/)

The FHS defines /var/lib as the location for "Variable state information".

Therefor I would suggest to move the web assets files to a more appropriate location, such as /usr/share/monitorix (Used for "Architecture-independent data").

@mikaku
Copy link
Owner

mikaku commented Oct 28, 2020

The reports/ directory only holds static data that was placed during the Monitorix installation. I think this directory can, indeed, be safely moved to a different location.

The www/ directory though is used to store variable information:

  • The file www/index.html is created everytime Monitorix is started.
  • The files www/cgi/monitorix.conf.path and optionally (depending if hptemp.pm is enabled) www/cgi/monitorix.hplog are also created everytime Monitorix is started. Maybe others.
  • The www/imgs/.png (or www/imgs/.svg) files that are the rendered images of the graphs being displayed.

I mean, all the tree under www/ is what forms the web files to be able see the Monitorix graphs.

@lyknode
Copy link
Contributor Author

lyknode commented Oct 28, 2020

Ah you're right, under www/, only the following files are installed from the Makefile:

  • monitorix.cgi
  • logo_bot.png
  • logo_top.png
  • monitorixico.png

It would be nice to be able to split that from the dynamic stuff, but I can already see that becoming more of a hassle than actually solving a minor issue. Might be better to drop that part and only do the reports/

@mikaku
Copy link
Owner

mikaku commented Nov 2, 2020

I've been thinking about moving reports/ out from the www/ tree, and it would bring some cumbersome changes.

The reason why reports/ is inside the www/ tree is because Monitorix can locate it easily by just using the option base_dir as a prefix. If you change it out from www/ tree and install it in /usr/share/monitorix, the option base_dir cannot be used anymore and, instead, it will be necessary to create a new specific option for this (something like base_reports_dir).

Such new option must be synced with the directory where reports/ will be installed, and this changes on BSD systems, and might change even between Linux distributions, forcing to adapt the default configuration file to that directory.

So, the question is: does this location change worth all this work?

Don't get me wrong, I'm with you that ideally the reports/ directory should go to a read-only part of the file system.

@lyknode
Copy link
Contributor Author

lyknode commented Nov 2, 2020

That's a valid point. Configuration file gets modified, requires a user intervention to work. Far from ideal.

In that case I would do the same as for the 8080 port issue. Keep that in the background until a new major/breaking version comes out. Maybe for monitorix 4.x then? ^^

Feel free to close the issue if you wish to.

@mikaku
Copy link
Owner

mikaku commented Nov 3, 2020

Keep that in the background until a new major/breaking version comes out. Maybe for monitorix 4.x then? ^^

You're right.

I've just created the new issue #295 for exactly this purpose.
Please, feel free to include those major/breaking new features.

Thanks!

@mikaku mikaku closed this as completed Nov 3, 2020
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

No branches or pull requests

2 participants