suggestions for tiny changes in the systemvm templates

[Stephan Seitz <s....@heinlein-support.de>]

Hi!

Having 4.11.1 at the horizon (btw. Thank You!), I've recently built packages and systemvm templates and wanted to share some thoughts about the systemvm.

Here a few things i came across (I'ld provide a PR, but wanted to discuss that in prior)

a) Entropy
SystemVM are usually VM and VM generally do have problems to gather entropy.
-> We could install rng-tools or (slightly better) haveged by default in the templates.
pro: having a decent entropy pool available. Would improve SSL at all.
con: well, cost's a few kB and a lightweight daemon running

b) NTP
At least for isolated networks (say VR / RVR) one usually needs to allow tcp/123 udp/123 for NTP to the VM behind.
-> We could provide broadcast and/or manycast and/or even unicast at the VR's NTP by just changing the /etc/ntp.conf
pro: easier setup of NTP (well, will add Stratum+1) for VM in isolated networks. Could also be announced via dhcp?
con: in case of multi- or manycast a few more packets on the wire

c) Monitoring
We're using check-mk for monitoring most parts of our infrastructure. Thank's to the Cloudstack API we collect indirect (and sometimes very abstract) health data of the systemvm running.
since there's already communication between systemvm and management, we thought that implementing the check-mk-agent (listening via xinetd) into the template could improve monitoring by
piggyback the metrics on the management node(s).
I'ld see that point different, since - even if the check-mk-agent wont do anything without getting queried - I don't know if it's feasible to add monitoring support for a solution which might be not
as wide spread as we think here. Anyhow, installation and usage would be very simple and (if unused) no impact.


cheers,

- Stephan







Mit freundlichen Grüßen,

Stephan Seitz


--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

https://www.heinlein-support.de

Tel: 030 / 405051-44
Fax: 030 / 405051-19

Amtsgericht Berlin-Charlottenburg - HRB 93818 B
Geschäftsführer: Peer Heinlein - Sitz: Berlin

Re: suggestions for tiny changes in the systemvm templates

[Daan Hoogland <da...@gmail.com>]

Stephan, are you planning PRs for these chances?

On Mon, Jul 2, 2018 at 1:49 PM, Stephan Seitz <s....@heinlein-support.de>
wrote:

> Hi!
>
> Having 4.11.1 at the horizon (btw. Thank You!), I've recently built
> packages and systemvm templates and wanted to share some thoughts about the
> systemvm.
>
> Here a few things i came across (I'ld provide a PR, but wanted to discuss
> that in prior)
>
> a) Entropy
> SystemVM are usually VM and VM generally do have problems to gather
> entropy.
> -> We could install rng-tools or (slightly better) haveged by default in
> the templates.
> pro: having a decent entropy pool available. Would improve SSL at all.
> con: well, cost's a few kB and a lightweight daemon running
>
> b) NTP
> At least for isolated networks (say VR / RVR) one usually needs to allow
> tcp/123 udp/123 for NTP to the VM behind.
> -> We could provide broadcast and/or manycast and/or even unicast at the
> VR's NTP by just changing the /etc/ntp.conf
> pro: easier setup of NTP (well, will add Stratum+1) for VM in isolated
> networks. Could also be announced via dhcp?
> con: in case of multi- or manycast a few more packets on the wire
>
> c) Monitoring
> We're using check-mk for monitoring most parts of our infrastructure.
> Thank's to the Cloudstack API we collect indirect (and sometimes very
> abstract) health data of the systemvm running.
> since there's already communication between systemvm and management, we
> thought that implementing the check-mk-agent (listening via xinetd) into
> the template could improve monitoring by
> piggyback the metrics on the management node(s).
> I'ld see that point different, since - even if the check-mk-agent wont do
> anything without getting queried - I don't know if it's feasible to add
> monitoring support for a solution which might be not
> as wide spread as we think here. Anyhow, installation and usage would be
> very simple and (if unused) no impact.
>
>
> cheers,
>
> - Stephan
>
>
>
>
>
>
>
> Mit freundlichen Grüßen,
>
> Stephan Seitz
>
>
> --
> Heinlein Support GmbH
> Schwedter Str. 8/9b, 10119 Berlin
>
> https://www.heinlein-support.de
>
> Tel: 030 / 405051-44
> Fax: 030 / 405051-19
>
> Amtsgericht Berlin-Charlottenburg - HRB 93818 B
> Geschäftsführer: Peer Heinlein - Sitz: Berlin
>
>


-- 
Daan