monitorix-general — Help and general discussion

Re: [Monitorix-general] Multihost don't reach nodes on local network

[Jordi S. <jo...@fi...>]

Hello Jon,

There is a typo with 'f001', it's defined as 'f001' in the 
'remotehost_list' but you referenced it as 'f011' in 'remotehost_desc'.

Can you, please, check if 'elinks' can reach 'f001' and 'f002' from a 
terminal session in 'gandalf'?

$ elinks http://f001:8080/monitorix
$ elinks http://f002:8080/monitorix

Just let me know.
Thanks.



On 8/2/20 2:07 PM, Jon Tegner wrote:
> Hi,
> 
> just starting using Monitorix, and having problem using multihost 
> reaching machines on local, 192-network.
> 
> Setup is the following:
> 
> * master hast two interfaces, one to the internet and one to a local 
> network, 192.168.56.0.
> * master (here called gandalf) is using apache (and I have disabled 
> builtin httpd on this).
> * The machines on 192.168.56.0 use builtin httpd.
> * Some relevant lines in monitorix.conf on the master are:
> 
> remotehost_list =gandalf,f001,f002
>    <remotehost_desc>
>       0 = http://gandalf,/monitorix,/monitorix-cgi
>       1 = http://f011:8080,/monitorix,/monitorix-cgi
>       2 = http://f002:8080,/monitorix,/monitorix-cgi
>    </remotehost_desc>
> 
> This enables me to see all the data from the master/gandalf, but nothing 
> from neither f001 nor f002.
> 
> Again, gandalf have two nics, and curl indicates that both f001:8080 and 
> f002:8080 are "working", i.e. they seem to generate relevant html.
> 
> I have probably missed something obvious, and any hints are greatly 
> appreciated!
> 
> Machines are running CentOS-8.2, and monitorix-3.12.0-1.el8.noarch is used.
> 
> Thanks,
> /jon
> 
> 
> 
> _______________________________________________
> Monitorix-general mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/monitorix-general
> 

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

[Monitorix-general] Multihost don't reach nodes on local network

[Jon T. <te...@re...>]

Hi,

just starting using Monitorix, and having problem using multihost 
reaching machines on local, 192-network.

Setup is the following:

* master hast two interfaces, one to the internet and one to a local 
network, 192.168.56.0.
* master (here called gandalf) is using apache (and I have disabled 
builtin httpd on this).
* The machines on 192.168.56.0 use builtin httpd.
* Some relevant lines in monitorix.conf on the master are:

remotehost_list =gandalf,f001,f002
   <remotehost_desc>
      0 = http://gandalf,/monitorix,/monitorix-cgi
      1 = http://f011:8080,/monitorix,/monitorix-cgi
      2 = http://f002:8080,/monitorix,/monitorix-cgi
   </remotehost_desc>

This enables me to see all the data from the master/gandalf, but nothing 
from neither f001 nor f002.

Again, gandalf have two nics, and curl indicates that both f001:8080 and 
f002:8080 are "working", i.e. they seem to generate relevant html.

I have probably missed something obvious, and any hints are greatly 
appreciated!

Machines are running CentOS-8.2, and monitorix-3.12.0-1.el8.noarch is used.

Thanks,
/jon

Re: [Monitorix-general] custom monitorix module to graph not yet supported data

[Jordi S. <jo...@fi...>]

Jehan,

Thank you very much for this well detailed HOWTO, it indeed will be a 
great help for those wanting to create their own custom module.

Best regards.



On 4/21/20 8:44 PM, Jehan PROCACCIA wrote:
> Hello list
> 
> I am very pleased with monitorix , it graphs most of what I need.
> but I have a proprietary ADSL router provided by my ISP that doesn't 
> provide local graph of In and Out trafic to the Internet .
> So I decided, with great help from monitorix developer,  to write my own 
> module
> as I didn't find much documentation on writing your own module, I 
> contribute to the project by publishing how I did it based on the 
> nginx.pm module
> It may inspire other contributions,
> here it is :
> https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:reseaux:services:monitorix_custom
> 
> regards .
> 
> 
> 
> 

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

[Monitorix-general] custom monitorix module to graph not yet supported data

[Jehan P. <jeh...@im...>]

Hello list 

I am very pleased with monitorix , it graphs most of what I need. 
but I have a proprietary ADSL router provided by my ISP that doesn't provide local graph of In and Out trafic to the Internet . 
So I decided, with great help from monitorix developer, to write my own module 
as I didn't find much documentation on writing your own module, I contribute to the project by publishing how I did it based on the nginx.pm module 
It may inspire other contributions, 
here it is : 
[ https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:reseaux:services:monitorix_custom | https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:reseaux:services:monitorix_custom ] 

regards . 

Re: [Monitorix-general] fail2ban filter for Monitorix

[Jordi S. <jo...@fi...>]

Sure, this filter probably lacks things here and there and it's far from 
being perfect, but it's a good start overall and works well for the 
majority of cases.

Feel free to improve it!

Regards.


On 4/4/20 10:04 AM, Narcis Garcia via Monitorix-general wrote:
> I've looked failures logged and I see it's recording source traffic IP
> but not visitor's one if it comes through a proxy (X-Forwarded-For):
> 
> $ sudo cat /var/log/monitorix-httpd | grep -ie AUTHERR
> Thu Apr  2 16:14:35 2020 - AUTHERR - [192.168.1.33] Authentication
> error: /monitorix/
> 
> This will produce fail2ban to block all visitors from same HTTP proxy.
> 
> I also want to warn about NOTEXIST key to filter:
> $ sudo cat /var/log/monitorix-httpd | grep -ie NOTEXIST
> Thu Apr  2 08:55:28 2020 - NOTEXIST - [192.168.1.33] File does not exist: /
> Sat Apr  4 09:50:16 2020 - NOTEXIST - [192.168.1.33] File does not
> exist: /favicon.ico
> Sat Apr  4 09:51:21 2020 - NOTEXIST - [192.168.1.33] File does not
> exist: /monitoric
> 
> 
> Thank you;
> 
> Narcis Garcia


-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

Re: [Monitorix-general] fail2ban filter for Monitorix

[Narcis G. <inf...@ac...>]

I've looked failures logged and I see it's recording source traffic IP
but not visitor's one if it comes through a proxy (X-Forwarded-For):

$ sudo cat /var/log/monitorix-httpd | grep -ie AUTHERR
Thu Apr  2 16:14:35 2020 - AUTHERR - [192.168.1.33] Authentication
error: /monitorix/

This will produce fail2ban to block all visitors from same HTTP proxy.

I also want to warn about NOTEXIST key to filter:
$ sudo cat /var/log/monitorix-httpd | grep -ie NOTEXIST
Thu Apr  2 08:55:28 2020 - NOTEXIST - [192.168.1.33] File does not exist: /
Sat Apr  4 09:50:16 2020 - NOTEXIST - [192.168.1.33] File does not
exist: /favicon.ico
Sat Apr  4 09:51:21 2020 - NOTEXIST - [192.168.1.33] File does not
exist: /monitoric


Thank you;

Narcis Garcia
El 3/4/20 a les 9:16, Jordi Sanfeliu ha escrit:
> Hello,
> 
> The following filter for fail2ban should suffice:
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> # Fail2Ban filter for Monitorix (HTTP built-in server)
> #
> 
> [INCLUDES]
> 
> before = common.conf
> 
> [Definition]
> 
> # Option:  failregex
> # Notes.:  regex to match the password failures messages in the logfile.
> The
> #          host must be matched by a group named "host". The tag
> "<HOST>" can
> #          be used for standard IP/hostname matching and is only an
> alias for
> #          (?:::f{4,6}:)?(?P<host>\S+)
> # Values:  TEXT
> #
> 
> _daemon = monitorix-httpd
> 
> failregex = NOTEXIST - \[<HOST>\] .*
>             AUTHERR - \[<HOST>\] .*
>             NOTALLOWED - \[<HOST>\] .*
> 
> # Option:  ignoreregex
> # Notes.:  regex to ignore. If this regex matches, the line is ignored.
> # Values:  TEXT
> #
> ignoreregex =
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Just let me know if it works for you, and if so, I'll push a new request
> to the fail2ban project to include it.
> 
> Regards.
> 
> 
> 
> On 4/2/20 10:09 AM, Narcis Garcia via Monitorix-general wrote:
>> htpasswd method with system's crypt() is pretty weak to face brute-force
>> attacks.
>>
>> Does somebody have written an adequate fail2ban filter for http attacks
>> to Monitorix?
>>
>> Thank you.
>>
> 

Re: [Monitorix-general] fail2ban filter for Monitorix

[Jordi S. <jo...@fi...>]

Hello,

The following filter for fail2ban should suffice:


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Fail2Ban filter for Monitorix (HTTP built-in server)
#

[INCLUDES]

before = common.conf

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag 
"<HOST>" can
#          be used for standard IP/hostname matching and is only an 
alias for
#          (?:::f{4,6}:)?(?P<host>\S+)
# Values:  TEXT
#

_daemon = monitorix-httpd

failregex = NOTEXIST - \[<HOST>\] .*
             AUTHERR - \[<HOST>\] .*
             NOTALLOWED - \[<HOST>\] .*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just let me know if it works for you, and if so, I'll push a new request 
to the fail2ban project to include it.

Regards.



On 4/2/20 10:09 AM, Narcis Garcia via Monitorix-general wrote:
> htpasswd method with system's crypt() is pretty weak to face brute-force
> attacks.
> 
> Does somebody have written an adequate fail2ban filter for http attacks
> to Monitorix?
> 
> Thank you.
> 

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

Re: [Monitorix-general] Automatic email reports: No password for local access

[Narcis G. <inf...@ac...>]

Done.

I can suggest you to label a link in website with a caption like
«Issues» or «Bug reports»
https://github.com/mikaku/Monitorix/issues


Narcis Garcia
El 2/4/20 a les 10:31, Jordi Sanfeliu ha escrit:
> Hello,
> 
> No, there is no way to do that.
> 
> I might introduce a modification to use 'hosts_allow' to bypass the
> Basic Authentication mechanism, even when it is enabled. But I'm not
> sure the implications this will have right now.
> 
> If you agree, please, file an issue at GitHub so we can track it.
> Thanks.
> 
> 
> On 4/2/20 9:54 AM, Narcis Garcia via Monitorix-general wrote:
>> Hello,
>>
>> /etc/monitorix/monitorix.conf
>> httpd_builtin -> auth -> enabled = y
>>
>> Is there some way to this only applies to non-localhost visitors?
>>
>> I need to not save clear passwords here:
>> emailreports -> url_prefix
>>
>> Thank you.
>>
> 

Re: [Monitorix-general] Automatic email reports: Default graphs

[Jordi S. <jo...@fi...>]

Hello,

As stated in the man page:

"graphs
               This is a comma-separated list of graph names you want to 
appear in the email report. The names are the same as their .rrd files. 
There is a list of them in the graph_name option in monitorix.conf.

               Default value: system, fs
"

So, just put the same graphs you have enabled in your 'monitorix.conf'.
Regards.



On 4/2/20 9:47 AM, Narcis Garcia via Monitorix-general wrote:
> Hello,
> 
> In /etc/monitorix/monitorix.conf
> emailreports -> monthly -> graphs
> 
> What value (or empty) must I set there to get same reports as visiting
> web UI?
> 
> Thank you.
> 

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

Re: [Monitorix-general] Automatic email reports: No password for local access

[Jordi S. <jo...@fi...>]

Hello,

No, there is no way to do that.

I might introduce a modification to use 'hosts_allow' to bypass the 
Basic Authentication mechanism, even when it is enabled. But I'm not 
sure the implications this will have right now.

If you agree, please, file an issue at GitHub so we can track it.
Thanks.


On 4/2/20 9:54 AM, Narcis Garcia via Monitorix-general wrote:
> Hello,
> 
> /etc/monitorix/monitorix.conf
> httpd_builtin -> auth -> enabled = y
> 
> Is there some way to this only applies to non-localhost visitors?
> 
> I need to not save clear passwords here:
> emailreports -> url_prefix
> 
> Thank you.
> 

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

[Monitorix-general] fail2ban filter for Monitorix

[Narcis G. <inf...@ac...>]

htpasswd method with system's crypt() is pretty weak to face brute-force
attacks.

Does somebody have written an adequate fail2ban filter for http attacks
to Monitorix?

Thank you.

-- 

Narcis Garcia

[Monitorix-general] Automatic email reports: Default graphs

[Narcis G. <inf...@ac...>]

Hello,

In /etc/monitorix/monitorix.conf
emailreports -> monthly -> graphs

What value (or empty) must I set there to get same reports as visiting
web UI?

Thank you.

-- 

Narcis Garcia

[Monitorix-general] Automatic email reports: No password for local access

[Narcis G. <inf...@ac...>]

Hello,

/etc/monitorix/monitorix.conf
httpd_builtin -> auth -> enabled = y

Is there some way to this only applies to non-localhost visitors?

I need to not save clear passwords here:
emailreports -> url_prefix

Thank you.

-- 

Narcis Garcia

Re: [Monitorix-general] Bug in 3.12.0

[Jordi S. <jo...@fi...>]

Izzy,

No, no need to do anything on your part.
Thank you very much.


On 2/28/20 8:35 AM, Andreas Itzchak Rehberg wrote:
> Ah, the other jail… Yes, that could be.
> 
> Is there anything you want me to change in packaging?
> 
> (I'm aware the mailing list will reject this again, but keeping it in
> makes it easier for you to answer ;)
> 
> Best,
> Izzy.
> 
> On Fri, 2020-02-28 at 08:25 +0100, Jordi Sanfeliu wrote:
>> Hello,
>>
>> (Izzy, your message was automatically discarded by the mailing list,
>> sorry.)
>>
>> As pointed by Baptiste (the package maintainer for newer Debian
>> versions) on freenode, [postfix-rbl] jail is not part of the default
>> configuration of Monitorix in Debian.
>>
>> So, it's probably that you already had such jail defined in
>> 'monitorix.conf' before updating to 3.12. Remember that in all
>> versions
>> prior to 3.12, Monitorix was not using the command 'fail2ban-client'
>> and
>> so undefined jails didn't generate warnings in the fail2ban log file.
>>
>> Frank, if you don't use such jail then just remove it from your
>> 'monitorix.conf' file (and restart Monitorix).
>>
>> Regards.
>>
>>
>>
>> On 2/27/20 10:32 PM, Andreas Itzchak Rehberg wrote:
>>>
>>> Are you two talking about those entries in the f2b log:
>>>
>>> 2020-02-24 08:41:05,901 fail2ban.comm   : WARNING Invalid command:
>>> ['status', 'apache']
>>> 2020-02-24 08:41:07,111 fail2ban.comm   : WARNING Invalid command:
>>> ['status', 'pam-generic']
>>>
>>> If so: I can confirm they pop up here as well. But I doubt they are
>>> specific to the Debian package. In my case, these two are the only
>>> ones
>>> showing up in the log – and both jails are indeed disabled on that
>>> machine. It would most likely help to disable them in the monitorix
>>> config as well (or to enable them in f2b).
>>>
>>> For the former, just copy the "<fail2ban>" block from
>>> "/etc/monitorix/monitorix.conf" to your site-specific
>>> "/etc/monitorix/conf.d/xxx.conf" and remove the "offending" jails
>>> from
>>> "<desc>" (that correct, Jordi?).
>>>
>>> If you were talking about something else, please specify :)
>>>
>>> Best,
>>> Izzy.
>>>
>>> On Thu, 2020-02-27 at 13:02 +0100, Jordi Sanfeliu wrote:
>>>>
>>>> Hello Frank,
>>>>
>>>> I've CCed Andreas 'Izzy' the package maintainer for Debian
>>>> systems,
>>>> to
>>>> let him know about this issue.
>>>>
>>>>
>>>> On 2/27/20 11:56 AM, Frank B wrote:
>>>>>
>>>>>
>>>>> This looked strange to me, since I've disabled the postfix-rbl
>>>>> jail.
>>>>> Activating this jail and reloading fail2ban stopped the
>>>>> warnings.
>>>>> As far
>>>>> as I know there were no changes on my system, so I started
>>>>> digging
>>>>> deeper and found in apt's history.log:
>>>>>
>>>>> ===
>>>>> Start-Date: 2020-02-24  09:28:55
>>>>> Commandline: apt upgrade
>>>>> Upgrade: monitorix:amd64 (3.11.0-izzy1, 3.12.0-izzy1)
>>>>> End-Date: 2020-02-24  09:28:57
>>>>> ===
>>>>>
>>>>> Notice the timestamps of the first warning and the upgrade of
>>>>> Monitorix
>>>>> to 3.12.0.
>>>> The new warnings in the fail2ban log are probably due the fact
>>>> that
>>>> since 3.12, Monitorix uses by default the command 'fail2ban-
>>>> client'
>>>> to
>>>> know about the number of IP bans per jail. It looks like such
>>>> command
>>>> routes directly these warnings to the fail2ban log.
>>>>
>>>>
>>>>>
>>>>>
>>>>> In monitorix.conf [postfix-rbl] was enabled in the fail2ban
>>>>> graph
>>>>> section. Disabling this and disabling the postfix-rbl jail
>>>>> again
>>>>> (the
>>>>> host of my VPS has limited the number of IP packet filtering
>>>>> entries, so
>>>>> I have to be very selective with my jail setup) fixed the
>>>>> situation. As
>>>>> an added "bonus" I lost the history of my fail2ban graph in
>>>>> Monitorix;
>>>>> all data in the graph before the upgrade is gone. The other
>>>>> graphs
>>>>> are fine.
>>>> As stated in the manpage:
>>>>
>>>> "WARNING: Every time the number of entries in this option
>>>> changes,
>>>> Monitorix will resize the fail2ban.rrd file accordingly, removing
>>>> all
>>>> historical data."
>>>>
>>>> Monitorix creates automatically a backup of the old file, so you
>>>> should
>>>> have all your historical data in the file
>>>> '/var/lib/monitorix/fail2ban.rrd.bak'.
>>>>
>>>> Just rename that file and reset the number of configured jails in
>>>> Monitorix to match with that file, and you will continue enjoying
>>>> your
>>>> historical data.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Summary: a disabled jail in fail2ban but enabled in the
>>>>> fail2ban
>>>>> graph
>>>>> section of Monitorix floods fail2ban.log with warnings. I did
>>>>> not
>>>>> try to
>>>>> reproduce this issue with other jails.
>>>> Yes apparently this is a fail2ban feature (perhaps configurable).
>>>>
>>>> To make sure, just try to force a warning in the fail2ban log by
>>>> requesting information of an nonexistent jail, like this:
>>>> 'fail2ban-client status jailnotexistent'.
>>>>
>>>>
>>>> Regards.
>>>>

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

La possible informació de caràcter personal que pugui contenir el 
present correu electrònic, està protegida degudament per la normativa 
del Reglament Europeu de Protecció de Dades (RGPD), que compromet no 
utilitzar-la per a finalitats diferents per la que s'ha remès al 
destinatari, a l’hora que la subjecta a una obligació de 
confidencialitat. En conseqüència, és d'ús exclusiu per al destinatari, 
quedant prohibida a qualsevol altra persona la seva revelació, còpia, 
distribució o l'exercici de qualsevol acció relativa al seu contingut. 
Si rebéssiu aquest correu electrònic erròniament o de forma incompleta, 
si us plau, procediu a reenviar-nos-el.

Informació Bàsica Política de Privacitat (RGPD). Responsable: FIBRANET 
NSP, SL. Finalitat: Gestió de l'execució de la prestació del servei i 
facturació del mateix. Legitimació: Execució d'un contracte/prestació de 
servei. Període de conservació: Les dades proporcionades es conservaran 
mentre es mantingui la relació comercial o durant els anys necessaris 
per complir amb les obligacions legals. Destinataris: No es cediran a 
tercers, a excepció d'obligació legal. Drets: Accedir, rectificar i 
suprimir les dades, així com els altres drets, tal i com s'explica en la 
informació addicional. Informació addicional: Es pot consultar la 
informació addicional i detallada sobre la nostra protecció de dades a 
la nostra pàgina web www.fibranet.cat.

Re: [Monitorix-general] Bug in 3.12.0

[Jordi S. <jo...@fi...>]

Hello,

(Izzy, your message was automatically discarded by the mailing list, sorry.)

As pointed by Baptiste (the package maintainer for newer Debian 
versions) on freenode, [postfix-rbl] jail is not part of the default 
configuration of Monitorix in Debian.

So, it's probably that you already had such jail defined in 
'monitorix.conf' before updating to 3.12. Remember that in all versions 
prior to 3.12, Monitorix was not using the command 'fail2ban-client' and 
so undefined jails didn't generate warnings in the fail2ban log file.

Frank, if you don't use such jail then just remove it from your 
'monitorix.conf' file (and restart Monitorix).

Regards.



On 2/27/20 10:32 PM, Andreas Itzchak Rehberg wrote:
> Are you two talking about those entries in the f2b log:
> 
> 2020-02-24 08:41:05,901 fail2ban.comm   : WARNING Invalid command:
> ['status', 'apache']
> 2020-02-24 08:41:07,111 fail2ban.comm   : WARNING Invalid command:
> ['status', 'pam-generic']
> 
> If so: I can confirm they pop up here as well. But I doubt they are
> specific to the Debian package. In my case, these two are the only ones
> showing up in the log – and both jails are indeed disabled on that
> machine. It would most likely help to disable them in the monitorix
> config as well (or to enable them in f2b).
> 
> For the former, just copy the "<fail2ban>" block from
> "/etc/monitorix/monitorix.conf" to your site-specific
> "/etc/monitorix/conf.d/xxx.conf" and remove the "offending" jails from
> "<desc>" (that correct, Jordi?).
> 
> If you were talking about something else, please specify :)
> 
> Best,
> Izzy.
> 
> On Thu, 2020-02-27 at 13:02 +0100, Jordi Sanfeliu wrote:
>> Hello Frank,
>>
>> I've CCed Andreas 'Izzy' the package maintainer for Debian systems,
>> to
>> let him know about this issue.
>>
>>
>> On 2/27/20 11:56 AM, Frank B wrote:
>>>
>>> This looked strange to me, since I've disabled the postfix-rbl
>>> jail.
>>> Activating this jail and reloading fail2ban stopped the warnings.
>>> As far
>>> as I know there were no changes on my system, so I started digging
>>> deeper and found in apt's history.log:
>>>
>>> ===
>>> Start-Date: 2020-02-24  09:28:55
>>> Commandline: apt upgrade
>>> Upgrade: monitorix:amd64 (3.11.0-izzy1, 3.12.0-izzy1)
>>> End-Date: 2020-02-24  09:28:57
>>> ===
>>>
>>> Notice the timestamps of the first warning and the upgrade of
>>> Monitorix
>>> to 3.12.0.
>> The new warnings in the fail2ban log are probably due the fact that
>> since 3.12, Monitorix uses by default the command 'fail2ban-client'
>> to
>> know about the number of IP bans per jail. It looks like such
>> command
>> routes directly these warnings to the fail2ban log.
>>
>>
>>>
>>> In monitorix.conf [postfix-rbl] was enabled in the fail2ban graph
>>> section. Disabling this and disabling the postfix-rbl jail again
>>> (the
>>> host of my VPS has limited the number of IP packet filtering
>>> entries, so
>>> I have to be very selective with my jail setup) fixed the
>>> situation. As
>>> an added "bonus" I lost the history of my fail2ban graph in
>>> Monitorix;
>>> all data in the graph before the upgrade is gone. The other graphs
>>> are fine.
>> As stated in the manpage:
>>
>> "WARNING: Every time the number of entries in this option changes,
>> Monitorix will resize the fail2ban.rrd file accordingly, removing
>> all
>> historical data."
>>
>> Monitorix creates automatically a backup of the old file, so you
>> should
>> have all your historical data in the file
>> '/var/lib/monitorix/fail2ban.rrd.bak'.
>>
>> Just rename that file and reset the number of configured jails in
>> Monitorix to match with that file, and you will continue enjoying
>> your
>> historical data.
>>
>>
>>>
>>> Summary: a disabled jail in fail2ban but enabled in the fail2ban
>>> graph
>>> section of Monitorix floods fail2ban.log with warnings. I did not
>>> try to
>>> reproduce this issue with other jails.
>> Yes apparently this is a fail2ban feature (perhaps configurable).
>>
>> To make sure, just try to force a warning in the fail2ban log by
>> requesting information of an nonexistent jail, like this:
>> 'fail2ban-client status jailnotexistent'.
>>
>>
>> Regards.
>>

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

La possible informació de caràcter personal que pugui contenir el 
present correu electrònic, està protegida degudament per la normativa 
del Reglament Europeu de Protecció de Dades (RGPD), que compromet no 
utilitzar-la per a finalitats diferents per la que s'ha remès al 
destinatari, a l’hora que la subjecta a una obligació de 
confidencialitat. En conseqüència, és d'ús exclusiu per al destinatari, 
quedant prohibida a qualsevol altra persona la seva revelació, còpia, 
distribució o l'exercici de qualsevol acció relativa al seu contingut. 
Si rebéssiu aquest correu electrònic erròniament o de forma incompleta, 
si us plau, procediu a reenviar-nos-el.

Informació Bàsica Política de Privacitat (RGPD). Responsable: FIBRANET 
NSP, SL. Finalitat: Gestió de l'execució de la prestació del servei i 
facturació del mateix. Legitimació: Execució d'un contracte/prestació de 
servei. Període de conservació: Les dades proporcionades es conservaran 
mentre es mantingui la relació comercial o durant els anys necessaris 
per complir amb les obligacions legals. Destinataris: No es cediran a 
tercers, a excepció d'obligació legal. Drets: Accedir, rectificar i 
suprimir les dades, així com els altres drets, tal i com s'explica en la 
informació addicional. Informació addicional: Es pot consultar la 
informació addicional i detallada sobre la nostra protecció de dades a 
la nostra pàgina web www.fibranet.cat.

Re: [Monitorix-general] Bug in 3.12.0

[Jordi S. <jo...@fi...>]

Hello Frank,

I've CCed Andreas 'Izzy' the package maintainer for Debian systems, to 
let him know about this issue.


On 2/27/20 11:56 AM, Frank B wrote:
> This looked strange to me, since I've disabled the postfix-rbl jail. 
> Activating this jail and reloading fail2ban stopped the warnings. As far 
> as I know there were no changes on my system, so I started digging 
> deeper and found in apt's history.log:
> 
> ===
> Start-Date: 2020-02-24  09:28:55
> Commandline: apt upgrade
> Upgrade: monitorix:amd64 (3.11.0-izzy1, 3.12.0-izzy1)
> End-Date: 2020-02-24  09:28:57
> ===
> 
> Notice the timestamps of the first warning and the upgrade of Monitorix 
> to 3.12.0.

The new warnings in the fail2ban log are probably due the fact that 
since 3.12, Monitorix uses by default the command 'fail2ban-client' to 
know about the number of IP bans per jail. It looks like such command 
routes directly these warnings to the fail2ban log.


> In monitorix.conf [postfix-rbl] was enabled in the fail2ban graph 
> section. Disabling this and disabling the postfix-rbl jail again (the 
> host of my VPS has limited the number of IP packet filtering entries, so 
> I have to be very selective with my jail setup) fixed the situation. As 
> an added "bonus" I lost the history of my fail2ban graph in Monitorix; 
> all data in the graph before the upgrade is gone. The other graphs are fine.

As stated in the manpage:

"WARNING: Every time the number of entries in this option changes, 
Monitorix will resize the fail2ban.rrd file accordingly, removing all 
historical data."

Monitorix creates automatically a backup of the old file, so you should 
have all your historical data in the file 
'/var/lib/monitorix/fail2ban.rrd.bak'.

Just rename that file and reset the number of configured jails in 
Monitorix to match with that file, and you will continue enjoying your 
historical data.


> Summary: a disabled jail in fail2ban but enabled in the fail2ban graph 
> section of Monitorix floods fail2ban.log with warnings. I did not try to 
> reproduce this issue with other jails.

Yes apparently this is a fail2ban feature (perhaps configurable).

To make sure, just try to force a warning in the fail2ban log by 
requesting information of an nonexistent jail, like this: 
'fail2ban-client status jailnotexistent'.


Regards.

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

[Monitorix-general] Bug in 3.12.0

[Frank B <fr...@gm...>]

Hello,

Out of the blue my fail2ban.log got flooded with warnings:

===
2020-02-24 09:25:48,283 fail2ban.filter         [466]: INFO
 [wordpress-hard] Found *.*.105.83 - 2020-02-24 09:25:48
2020-02-24 09:25:48,950 fail2ban.actions        [466]: NOTICE
 [wordpress-hard] Ban *.*.105.83
2020-02-24 09:29:01,333 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:30:01,904 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:30:39,628 fail2ban.actions        [466]: NOTICE  [sshd] Unban
*.*.248.127
2020-02-24 09:31:01,421 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:31:45,704 fail2ban.actions        [466]: NOTICE  [sshd] Unban
*.*.88.77
2020-02-24 09:32:01,895 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:32:09,741 fail2ban.actions        [466]: NOTICE  [sshd] Unban
*.*.133.188
2020-02-24 09:33:01,246 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:34:01,661 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:35:01,283 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:36:01,671 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:37:01,375 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:38:02,241 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:39:02,118 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:40:01,766 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:40:34,032 fail2ban.filter         [466]: INFO
 [wordpress-hard] Found *.*.135.88 - 2020-02-24 09:40:33
2020-02-24 09:40:40,313 fail2ban.filter         [466]: INFO
 [wordpress-hard] Found *.*.135.88 - 2020-02-24 09:40:40
2020-02-24 09:40:46,220 fail2ban.filter         [466]: INFO
 [wordpress-hard] Found *.*.135.88 - 2020-02-24 09:40:45
2020-02-24 09:40:46,342 fail2ban.actions        [466]: NOTICE
 [wordpress-hard] Ban *.*.135.88
2020-02-24 09:41:01,277 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
2020-02-24 09:41:49,313 fail2ban.filter         [466]: INFO    [postfix]
Found *.*.176.82 - 2020-02-24 09:41:49
2020-02-24 09:41:49,582 fail2ban.filter         [466]: INFO    [postfix]
Found *.*.176.82 - 2020-02-24 09:41:49
2020-02-24 09:42:00,427 fail2ban.actions        [466]: NOTICE
 [wordpress-hard] Unban *.*.132.32
2020-02-24 09:42:01,672 fail2ban.transmitter    [466]: WARNING Command
['status', 'postfix-rbl'] has failed. Received
UnknownJailException('postfix-rbl',)
===

This looked strange to me, since I've disabled the postfix-rbl jail.
Activating this jail and reloading fail2ban stopped the warnings. As far as
I know there were no changes on my system, so I started digging deeper and
found in apt's history.log:

===
Start-Date: 2020-02-24  09:28:55
Commandline: apt upgrade
Upgrade: monitorix:amd64 (3.11.0-izzy1, 3.12.0-izzy1)
End-Date: 2020-02-24  09:28:57
===

Notice the timestamps of the first warning and the upgrade of Monitorix to
3.12.0.

In monitorix.conf [postfix-rbl] was enabled in the fail2ban graph section.
Disabling this and disabling the postfix-rbl jail again (the host of my VPS
has limited the number of IP packet filtering entries, so I have to be very
selective with my jail setup) fixed the situation. As an added "bonus" I
lost the history of my fail2ban graph in Monitorix; all data in the graph
before the upgrade is gone. The other graphs are fine.

Summary: a disabled jail in fail2ban but enabled in the fail2ban graph
section of Monitorix floods fail2ban.log with warnings. I did not try to
reproduce this issue with other jails.

With kind regards,
Frank B.

[Monitorix-general] Monitorix 3.12.0 released

[Jordi S. <jo...@fi...>]

Monitorix 3.12.0 has been released!

This new version introduces two new modules: the phpfpm.pm and the 
unbound.pm. The first one will allow to collect PHP-FPM statistics and 
monitor unlimited number of sites, while the unbound.pm module will 
collect a lot of statistics of the Unbound running in your local server. 
There is not possibility to collect Unbound statistics from remote 
servers. In all, both modules come with a fairly complete statistic graphs.

Besides these two new modules, this version includes some interesting 
new features. It has been finally fixed the bind.pm module to support 
newer versions of BIND. Now this module relies on Perl XML::LibXML to 
parse the output of BIND (instead of using Perl XML::Simple). Also, the 
gensens.pm module includes Battery as its third sensor, and there has 
been some improvements in the NFS graph for FreeBSD systems.

The fail2ban.pm module has also changed the way how the values are 
shown. From now on, you can choose between absolute and rate values, 
being the former the default one.

The ZFS graph has also changed the way how are shown the Operations and 
Bandwidth graphs.

The rest of new features, changes and bugs fixed are, as always, 
reflected in the Changes file.

Please, check the monitorix.conf(5) man page for all the details.

NOTICE: The configuration file monitorix.conf has been extended with 
important changes.

All users still using older versions are encouraged to upgrade to this 
version.

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
http://www.fibranet.cat

Re: [Monitorix-general] Odd issue with libvirt MACs

[Jordi S. <jo...@fi...>]

Hello,

Yes, this is an known issue in 3.11.0 that is already fixed in the 
official tree, so it will be fixed in the next Monitorix version.

For more information check the issue 260:

<https://github.com/mikaku/Monitorix/issues/260>

Thanks for your feedback!
Best regards.


On 12/20/19 7:39 PM, mr2dave wrote:
> On a Fedora 30 box running a bunch of libvirt VMs and monitorix 3.11.0
> from Fedora's repo monitorix failed to monitor VM network usage, and I
> saw things like "libvirt::libvirt_update: invalid MAC address
> '52:54:00:56:3f:6f' in 'pihole'." in the log.
> 
> So I double check the MAC address:
> [root@saturn ~]# virsh domiflist pihole
>   Interface   Type     Source   Model    MAC
> -----------------------------------------------------------
>   vnet3       bridge   br0      virtio   52:54:00:56:3f:6f
> 
> I also checked /var/log/audit/audit.log but didn't see anything related
> and tried making selinux permissive just to be sure, but selinux isn't
> the problem.
> 
> I commented out the MAC validation section in libvirt.pm and changed
> $vnet to $vn thrice in the domifstat section just below that, and it
> works properly now.
> I don't know why the validation is failing, but I'd love to help fix
> it.
> Is there anything else I can provide or test?
> 
> 
> 
> _______________________________________________
> Monitorix-general mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/monitorix-general
> 


-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
http://www.fibranet.cat

[Monitorix-general] Odd issue with libvirt MACs

[mr2dave <mr...@gm...>]

On a Fedora 30 box running a bunch of libvirt VMs and monitorix 3.11.0
from Fedora's repo monitorix failed to monitor VM network usage, and I
saw things like "libvirt::libvirt_update: invalid MAC address
'52:54:00:56:3f:6f' in 'pihole'." in the log.

So I double check the MAC address:
[root@saturn ~]# virsh domiflist pihole
 Interface   Type     Source   Model    MAC
-----------------------------------------------------------
 vnet3       bridge   br0      virtio   52:54:00:56:3f:6f

I also checked /var/log/audit/audit.log but didn't see anything related
and tried making selinux permissive just to be sure, but selinux isn't
the problem.

I commented out the MAC validation section in libvirt.pm and changed
$vnet to $vn thrice in the domifstat section just below that, and it
works properly now.
I don't know why the validation is failing, but I'd love to help fix
it.
Is there anything else I can provide or test?

[Monitorix-general] Monitorix 3.11.0 released

[Jordi S. <jo...@fi...>]

Monitorix 3.11.0 has been released!

Important notice for people that is still using versions 3.10.0 or 
older: This one fixes a cross-site scripting (XSS) vulnerability that 
was already announced and fixed in the 3.10.1 version.

This new version introduces one new graph: the Ambient Sensors graph. 
This graph is intended for gathering temperature values from any kind of 
external sensors. Each defined sensor is associated to a command line 
that will be executed by Monitorix to get the temperature. It also 
support alerts to notify when the value is above or below from a defined 
threshold.

Besides the fact that this new version only comes with one new graph, it 
really includes interesting new features. One of the most important is 
the new option 'autocheck_responsiveness' (enabled by default), that 
hopefully should fix those so annoying hangups in the HTTP built-in server.

Another interesting change is the new way of how the memory graph will 
be shown in Linux systems. The value used will be recalculated as used = 
MemTotal - MemFree - Buffers - Cached - SReclaimable - SUnreclaim which 
will ensure that Monitorix will be in sync with the Used column in the 
output of newer free command, and with the -/+ buffers/cache row of the 
older free command.

The ZFS graph has also changed, it now includes more information for 
each pool defined with the number of operations and the bandwidth used.

By popular demand, I've finally included in Multihost mode the ability 
to show all graphs of a single server and even all graphs from all 
remote servers. In the later case, you must keep in mind that in order 
to see all graphs, the remote servers must have the same configuration 
file than the host from where you are viewing them all.

It's important to notice that this new feature has a potential risk if 
there is defined a considerable amount of remote servers and the user 
selects the option "All" in the Hostname list and "All graphs" in the 
Graph list. This is something that may happen now accidentally and the 
browser may hang for a while due to the huge amount of images to 
download remotely from different servers.

In order to prevent precisely that, this new feature comes with a new 
option called default_option_when_all that defines which option in the 
Graph list ('System load" by default) will be selected automatically 
when the user selects 'All' in the Hostname list. Of course, the user is 
still able to change it to "All graphs" at any moment, and at his own 
risk :-).

The rest of new features, changes and bugs fixed are, as always, 
reflected in the Changes file.

Please, check the monitorix.conf(5) man page for all the details.

NOTICE: The configuration file monitorix.conf has been extended with 
important changes.

All users still using older versions are advised and encouraged to 
upgrade to this version.
Regards.

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
http://www.fibranet.cat

Re: [Monitorix-general] Freebsd 12 vs Monitorix

[Jordi S. <jo...@fi...>]

Kamil,

OK, after reading these messages I think it's better to remove the 
entropy support for FreeBSD systems. So, no one will experience these 
same errors you had.

Thank you very much.
Best regards.


On 2/18/19 4:49 PM, cr...@lo... wrote:
> all i found is : 
> http://freebsd.1045724.x6.nabble.com/Querying-entropy-state-td6257051.html
> so i tried to comment out these lines 293 to 296 in system.pm and seems 
> it started to work again, al lerrors in log are gone
> 
> On 18.02.2019 12:46, Jordi Sanfeliu wrote:
>> Hello Kamil,
>>
>>
>> On 2/15/19 3:48 PM, cr...@lo... wrote:
>>> OK, 2nd issue is gone now, i just reinstalled monitorix from ports 
>>> with all dependencies so now i'm able to generate graphs. but still 
>>> having issues with SYSTEM monitoring as described earlier ...
>>>
>>> - Kamil
>>>
>>>
>>> On 15.02.2019 13:29, cr...@lo... wrote:
>>>> Hi,
>>>>
>>>> i'm using Monitorix since FreeBSD 7 and its simply great. BUT 
>>>> recently i've installed FreeBSD 12 on new machine and having two 
>>>> problems now ...
>>>>
>>>> 1st - cannot monitor SYSTEM, the rest of monitors i'm using are OK. 
>>>> i can see lots of these errors in logfile:
>>>>
>>>> Use of uninitialized value in lc at /usr/local/bin/monitorix line 714.
>>>> Use of uninitialized value in lc at /usr/local/bin/monitorix line 740.
>>
>> Looks like you removed some parts ('traffacct' and 'emailreports') 
>> from the configuration file that you won't use. Monitorix expects to 
>> read the original configuration file, and you think you won't use an 
>> option, just leave it disabled (with 'n').
>>
>>
>>>> sysctl: unknown oid 'kern.random.sys.seeded'
>>>> Use of uninitialized value $entropy in scalar chomp at 
>>>> /usr/local/share/monitorix/system.pm line 296.
>>>> Use of uninitialized value $entropy in chomp at 
>>>> /usr/local/share/monitorix/system.pm line 361.
>>>> Use of uninitialized value $entropy in concatenation (.) or string 
>>>> at /usr/local/share/monitorix/system.pm line 401.
>>>> Fri Feb 15 13:16:00 2019 - ERROR: while updating 
>>>> /var/db/monitorix/system.rrd: /var/db/monitorix/system.rrd: Function 
>>>> update_pdp_prep, case DST_GAUGE - Cannot convert '' to float
>>>>
>>>> according to man page "kern.random.sys.seeded" is not in FreeBSD 11 
>>>> and newer, last seen in 10: 
>>>> https://www.freebsd.org/cgi/man.cgi?query=random&apropos=0&sektion=4&manpath=FreeBSD+10.4-stable&arch=default&format=html 
>>>>
>>>> i can confirm that as previous machine was running 10 with no issue 
>>>> (i skipped 11 to 12 now)
>>
>> It seems then that FreeBSD folks have removed (or perhaps changed the 
>> name) of the option 'kern.random.sys.seeded'. Do you know if there 
>> exist a different way to know the entropy on a FreeBSD system?
>>
>> Meanwhile as a work-around comment out the lines from 293 to 296 in 
>> the 'system.pm' file of your FreeBSD system. I believe that the last 
>> error about 'unable to convert '' to float is just a consequence of 
>> the previous problem.
>>
>>
>>>>
>>>> 2nd - i'm not able to generate graphs, when i try this:
>>>> monitorix.cgi mode=localhost graph=all when=day color=black
>>>>
>>>> i'll get:
>>>> Use of uninitialized value $ENV{"HTTP_HOST"} in concatenation (.) or 
>>>> string at ./monitorix.cgi line 260.
>>>>
>>>> as i said i had no issue before (FreeBSD 7 8 9 10) but started after 
>>>> instalation of 12 ...
>>>>
>>>> thanks!
>>>> Kamil
>>>>
>>>>
>> Regards.
>>

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

Re: [Monitorix-general] Freebsd 12 vs Monitorix

[<cr...@lo...>]

all i found is : 
http://freebsd.1045724.x6.nabble.com/Querying-entropy-state-td6257051.html
so i tried to comment out these lines 293 to 296 in system.pm and seems 
it started to work again, al lerrors in log are gone

On 18.02.2019 12:46, Jordi Sanfeliu wrote:
> Hello Kamil,
>
>
> On 2/15/19 3:48 PM, cr...@lo... wrote:
>> OK, 2nd issue is gone now, i just reinstalled monitorix from ports 
>> with all dependencies so now i'm able to generate graphs. but still 
>> having issues with SYSTEM monitoring as described earlier ...
>>
>> - Kamil
>>
>>
>> On 15.02.2019 13:29, cr...@lo... wrote:
>>> Hi,
>>>
>>> i'm using Monitorix since FreeBSD 7 and its simply great. BUT 
>>> recently i've installed FreeBSD 12 on new machine and having two 
>>> problems now ...
>>>
>>> 1st - cannot monitor SYSTEM, the rest of monitors i'm using are OK. 
>>> i can see lots of these errors in logfile:
>>>
>>> Use of uninitialized value in lc at /usr/local/bin/monitorix line 714.
>>> Use of uninitialized value in lc at /usr/local/bin/monitorix line 740.
>
> Looks like you removed some parts ('traffacct' and 'emailreports') 
> from the configuration file that you won't use. Monitorix expects to 
> read the original configuration file, and you think you won't use an 
> option, just leave it disabled (with 'n').
>
>
>>> sysctl: unknown oid 'kern.random.sys.seeded'
>>> Use of uninitialized value $entropy in scalar chomp at 
>>> /usr/local/share/monitorix/system.pm line 296.
>>> Use of uninitialized value $entropy in chomp at 
>>> /usr/local/share/monitorix/system.pm line 361.
>>> Use of uninitialized value $entropy in concatenation (.) or string 
>>> at /usr/local/share/monitorix/system.pm line 401.
>>> Fri Feb 15 13:16:00 2019 - ERROR: while updating 
>>> /var/db/monitorix/system.rrd: /var/db/monitorix/system.rrd: Function 
>>> update_pdp_prep, case DST_GAUGE - Cannot convert '' to float
>>>
>>> according to man page "kern.random.sys.seeded" is not in FreeBSD 11 
>>> and newer, last seen in 10: 
>>> https://www.freebsd.org/cgi/man.cgi?query=random&apropos=0&sektion=4&manpath=FreeBSD+10.4-stable&arch=default&format=html 
>>>
>>> i can confirm that as previous machine was running 10 with no issue 
>>> (i skipped 11 to 12 now)
>
> It seems then that FreeBSD folks have removed (or perhaps changed the 
> name) of the option 'kern.random.sys.seeded'. Do you know if there 
> exist a different way to know the entropy on a FreeBSD system?
>
> Meanwhile as a work-around comment out the lines from 293 to 296 in 
> the 'system.pm' file of your FreeBSD system. I believe that the last 
> error about 'unable to convert '' to float is just a consequence of 
> the previous problem.
>
>
>>>
>>> 2nd - i'm not able to generate graphs, when i try this:
>>> monitorix.cgi mode=localhost graph=all when=day color=black
>>>
>>> i'll get:
>>> Use of uninitialized value $ENV{"HTTP_HOST"} in concatenation (.) or 
>>> string at ./monitorix.cgi line 260.
>>>
>>> as i said i had no issue before (FreeBSD 7 8 9 10) but started after 
>>> instalation of 12 ...
>>>
>>> thanks!
>>> Kamil
>>>
>>>
> Regards.
>

Re: [Monitorix-general] Freebsd 12 vs Monitorix

[Jordi S. <jo...@fi...>]

Hello Kamil,


On 2/15/19 3:48 PM, cr...@lo... wrote:
> OK, 2nd issue is gone now, i just reinstalled monitorix from ports with 
> all dependencies so now i'm able to generate graphs. but still having 
> issues with SYSTEM monitoring as described earlier ...
> 
> - Kamil
> 
> 
> On 15.02.2019 13:29, cr...@lo... wrote:
>> Hi,
>>
>> i'm using Monitorix since FreeBSD 7 and its simply great. BUT recently 
>> i've installed FreeBSD 12 on new machine and having two problems now ...
>>
>> 1st - cannot monitor SYSTEM, the rest of monitors i'm using are OK. i 
>> can see lots of these errors in logfile:
>>
>> Use of uninitialized value in lc at /usr/local/bin/monitorix line 714.
>> Use of uninitialized value in lc at /usr/local/bin/monitorix line 740.

Looks like you removed some parts ('traffacct' and 'emailreports') from 
the configuration file that you won't use. Monitorix expects to read the 
original configuration file, and you think you won't use an option, just 
leave it disabled (with 'n').


>> sysctl: unknown oid 'kern.random.sys.seeded'
>> Use of uninitialized value $entropy in scalar chomp at 
>> /usr/local/share/monitorix/system.pm line 296.
>> Use of uninitialized value $entropy in chomp at 
>> /usr/local/share/monitorix/system.pm line 361.
>> Use of uninitialized value $entropy in concatenation (.) or string at 
>> /usr/local/share/monitorix/system.pm line 401.
>> Fri Feb 15 13:16:00 2019 - ERROR: while updating 
>> /var/db/monitorix/system.rrd: /var/db/monitorix/system.rrd: Function 
>> update_pdp_prep, case DST_GAUGE - Cannot convert '' to float
>>
>> according to man page "kern.random.sys.seeded" is not in FreeBSD 11 
>> and newer, last seen in 10: 
>> https://www.freebsd.org/cgi/man.cgi?query=random&apropos=0&sektion=4&manpath=FreeBSD+10.4-stable&arch=default&format=html 
>>
>> i can confirm that as previous machine was running 10 with no issue (i 
>> skipped 11 to 12 now)

It seems then that FreeBSD folks have removed (or perhaps changed the 
name) of the option 'kern.random.sys.seeded'. Do you know if there exist 
a different way to know the entropy on a FreeBSD system?

Meanwhile as a work-around comment out the lines from 293 to 296 in the 
'system.pm' file of your FreeBSD system. I believe that the last error 
about 'unable to convert '' to float is just a consequence of the 
previous problem.


>>
>> 2nd - i'm not able to generate graphs, when i try this:
>> monitorix.cgi mode=localhost graph=all when=day color=black
>>
>> i'll get:
>> Use of uninitialized value $ENV{"HTTP_HOST"} in concatenation (.) or 
>> string at ./monitorix.cgi line 260.
>>
>> as i said i had no issue before (FreeBSD 7 8 9 10) but started after 
>> instalation of 12 ...
>>
>> thanks!
>> Kamil
>>
>>
Regards.

-- 
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat

Re: [Monitorix-general] Freebsd 12 vs Monitorix

[<cr...@lo...>]

OK, 2nd issue is gone now, i just reinstalled monitorix from ports with 
all dependencies so now i'm able to generate graphs. but still having 
issues with SYSTEM monitoring as described earlier ...

- Kamil


On 15.02.2019 13:29, cr...@lo... wrote:
> Hi,
>
> i'm using Monitorix since FreeBSD 7 and its simply great. BUT recently 
> i've installed FreeBSD 12 on new machine and having two problems now ...
>
> 1st - cannot monitor SYSTEM, the rest of monitors i'm using are OK. i 
> can see lots of these errors in logfile:
>
> Use of uninitialized value in lc at /usr/local/bin/monitorix line 714.
> Use of uninitialized value in lc at /usr/local/bin/monitorix line 740.
> sysctl: unknown oid 'kern.random.sys.seeded'
> Use of uninitialized value $entropy in scalar chomp at 
> /usr/local/share/monitorix/system.pm line 296.
> Use of uninitialized value $entropy in chomp at 
> /usr/local/share/monitorix/system.pm line 361.
> Use of uninitialized value $entropy in concatenation (.) or string at 
> /usr/local/share/monitorix/system.pm line 401.
> Fri Feb 15 13:16:00 2019 - ERROR: while updating 
> /var/db/monitorix/system.rrd: /var/db/monitorix/system.rrd: Function 
> update_pdp_prep, case DST_GAUGE - Cannot convert '' to float
>
> according to man page "kern.random.sys.seeded" is not in FreeBSD 11 
> and newer, last seen in 10: 
> https://www.freebsd.org/cgi/man.cgi?query=random&apropos=0&sektion=4&manpath=FreeBSD+10.4-stable&arch=default&format=html
> i can confirm that as previous machine was running 10 with no issue (i 
> skipped 11 to 12 now)
>
> 2nd - i'm not able to generate graphs, when i try this:
> monitorix.cgi mode=localhost graph=all when=day color=black
>
> i'll get:
> Use of uninitialized value $ENV{"HTTP_HOST"} in concatenation (.) or 
> string at ./monitorix.cgi line 260.
>
> as i said i had no issue before (FreeBSD 7 8 9 10) but started after 
> instalation of 12 ...
>
> thanks!
> Kamil
>
>
>
> _______________________________________________
> Monitorix-general mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/monitorix-general