@penfold to answer your question, yes you can boot off ZFS, I believe.
it can be the root volume pointed at from grub2
you cannot peacefully cohabit a bootloader on the devices used for zfs
I remember a lot discussion back in the day about freebsd booting from zfs
And long guides about doing it
Seemed not worth the effort
a non-issue these days so long as you have somewhere grub can be loaded off of
usb stick on motherboard internal header is a popular choice for home servers
I love the idea of booting from ZFS for like a classroom or work environment
snapshot everyone's workstations daily kinda thing
but that's more a network boot thing
I usually stick 32gb USB nub in usb socket
it's really only useful for when you have dozens of workstations to manage
I think
eh, it depends
ZFS nets me like 500MB, which is neat
@fydel so let's turn this into a 'how to munin' general for now
so first stage stuff first - is rrdcached a thing on your munin master?
yes sure.
let me check.
and, as that says, you need to run it as the munin (or www-data) user, as that's in the loop for producing the output, and such security is good enough for most things
if you need something better, i'll have to get back to you sober and we'll first draft a contract
but, here is an example systemd file for running one of those as the munin user on debian ``` $ cat /etc/systemd/system/munin-rrdcached.service [Unit] Description=Munin rrdcached [Service] Restart=always User=munin PermissionsStartOnly=yes ExecStartPre=/usr/bin/install -d -o munin -g munin -m 0755 \ /var/lib/munin/rrdcached-journal /run/munin ExecStart=/usr/bin/rrdcached \ -g -B -b /var/lib/munin/ \ -p /run/munin/munin-rrdcached.pid \ -F -j /var/lib/munin/rrdcached-journal/ \ -m 0660 -l unix:/run/munin/rrdcached.sock \ -w 1800 -z 1800 -f 3600 ExecStartPost=/bin/sleep 1 ; /bin/setfacl -m u:www-data:rw /run/munin/rrdcached.sock [Install] WantedBy=multi-user.target ```
and then you just munin master config use that socket as the rrdcached socket
i'll dig other stuff up in the meanwhile so once you've had your munin master update on that one two or more times in a row, ping me back
okay. give me a couple of minutes.
does the journal directory exist and does that user have write permissions to it?
seems to work. i am just having trouble with the systemd stuff. maybe we check on that later.
root@SB35 /var/lib/munin/rrdcached-journal # sudo -u munin /usr/bin/rrdcached -p /run/munin/rrdcached.pid -B -b /var/lib/munin/ -F -j /var/lib/munin/rrdcached-journal/ -m 0660 -l unix:/run/munin/rrdcached.sock -w 1800 -z 1800 -f 3600 -g
no erros in /var/log/munin/munin-update.log
no errors on console.
so, how do you serve those html files munin generates?
default via cron.
no, http-wise
no. i don't think so.
it is generated all five minutes.
how exactly does a webrowser reach your munin?
the cronjob generates both html and the png
now, to get to the next step, we'll need to make the html generation not static
symlink. /var/www/html/munin -> /var/cache/munin/www
munin provides an oldschool cgi script for exactly that
do you have a `/usr/lib/munin/cgi/munin-cgi-html` ?
root@SB35 /var/www/html # ls /usr/lib/munin/cgi/munin-cgi-html /usr/lib/munin/cgi/munin-cgi-html
how do you prefer to serve cgi scripts these days?
cgi scripts are a web thing from before php was a thing
i dont know. :cry:
but not too unsimilar
kk
so install `spawn-fcgi`, that's useful for us here
done
and i also have a systemd bit for using that, which can be used for ballparking manual usability ``` $ cat /etc/systemd/system/munin-fcgi-html.service [Unit] Description=Munin FastCGI HTML Documentation=man:spawn-fcgi [Service] Type=forking PIDFile=/run/munin/fcgi-html.pid ExecStart=/usr/bin/spawn-fcgi -s /run/munin/fcgi-html.sock -U www-data -u munin -g munin /var/www/cgi-bin/munin-cgi-html -P /run/munin/fcgi-html.pid [Install] WantedBy=multi-user.target ```
and that's just a symlink `/var/www/cgi-bin/munin-cgi-html -> /usr/lib/munin/cgi/munin-cgi-html`
if you want your munin to rely on cgi for generating the html, you need to tell it to use that as the generation strategy
let's do that first as that's a bit easier than the graphs
and as i do not know which webfront you use, here are some relevant location snippets for nginx ``` location ^~ /munin-cgi/munin-cgi-graph/ { access_log off; fastcgi_split_path_info ^(/munin-cgi/munin-cgi-graph)(.*); fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass unix:/run/munin/fcgi-graph.sock; include fastcgi_params; } location /munin/static/ { alias /etc/munin/static/; } location /munin/ { fastcgi_split_path_info ^(/munin)(.*); fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass unix:/run/munin/fcgi-html.sock; include fastcgi_params; } ```
and you should cache those on disk for 5 minutes
and here's a systemd example for wrapping the graphs ``` $ cat /etc/systemd/system/munin-fcgi-graph.service [Unit] Description=Munin FastCGI Graph Documentation=man:spawn-fcgi [Service] Type=forking PIDFile=/run/munin/fcgi-graph.pid ExecStart=/usr/bin/spawn-fcgi -s /run/munin/fcgi-graph.sock -U www-data -u munin -g munin /var/www/cgi-bin/munin-cgi-graph -P /run/munin/fcgi-graph.pid [Install] WantedBy=multi-user.target ```
and if you get that going for you, the interactive graphs will work
so there you have all the facts assembled, i can help with specifics if you hit something
i am on it.
and of course only cache the html outputs, the graph ones need to be direct accesses to the cgi script
i'll be on the computer all evening, you're not in a rush
i am using apache2. same for apache instead of nginx?
well, yes, but you need to figure out those redirects of how to talk to the unix domain sockets of the fcgi wrapped scripts
fcgi wrappers can also usually provide you a tcp interface if that makes life easier to you
oh, man. that's too much for me.
i am not into webserver and this cgi stuff.
and i never used systemd before.
i have to read up about this stuff before we can continue.
well, you have it archived here now
but munin is just a pile of perl and cgi on top of rrd and rrdcached
did your munin master runs get faster at least?
yes. thanks so far.
no. :disappointed: