multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Users mailing list
Hello,

First of all I would like to thank everyone involved in writing the apcupsd software.
It is a great and reliable piece of software!

The challenge I am facing is when using the multimon.cgi to monitor multiple hosts.

The program seems to call out each daemon in sequence, therefore if I specify too many hosts in the "C:\etc\apcupsd\hosts.conf" configuration file, it would often take too long before it would be done gathering the data from each UPS and the site would refresh.

Looking at the source code I quickly realized that I was able to pass the refresh http meta variable via POST (in seconds) and fix this problem.
For example: "http://myserver.local:8080/multimon.cgi?refresh=1200" and increase it several minutes from the default 30 seconds.

Great! Now I was able to monitor 10s of hosts effectively!

Next problem I faced was being able to maintain multiple "hosts.conf" files for different geographical sites, regions or datacenters etc.

And here is where I got stuck.

There was no way for me to spin up multiple HTTP server instances. Seems like the "<Drive Letter>:\etc\apcupsd\hosts.conf" is hard coded into the program.

Even using the SUBST command didn't turn out to be an elegant solution.


Has anyone run into the same limitation?

Would it be possible to implement a "hosts=something" POST variable similar to refresh and add support for being able to monitor 100s if not 1000s of hosts more effectively?

For example:

  • "http://myserver.local:8080/multimon.cgi?refresh=1200&hosts=datacenter1"  --> "C:\etc\apcupsd\datacenter1.conf"
  • "http://myserver.local:8080/multimon.cgi?refresh=1200&hosts=california"   --> "C:\etc\apcupsd\california.conf"
  • "http://myserver.local:8080/multimon.cgi?refresh=1200&hosts=myserverroom" --> "C:\etc\apcupsd\myserverroom.conf"

Unfortunately, my low-level programming (C language) skills are not sufficient to be able to modify the source code myself or propose a code change solution without risking breaking the code.

Is this something a seasonal C programmer could easily accomplish?

Or is there a more elegant solution?

Thank you again for all your help, suggestions and the excellent contributions to the apcupsd project,

Andrej


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Trevor Roydhouse
Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 12:29:
> Next problem I faced was being able to maintain multiple "hosts.conf"
> files for different geographical sites, regions or datacenters etc.
>
> And here is where I got stuck.
>
> There was no way for me to spin up multiple HTTP server instances.
> Seems like the "<Drive Letter>:\etc\apcupsd\hosts.conf" is hard
> coded into the program.
[...]
> Would it be possible to implement a "hosts=something" POST variable
> similar to refresh and add support for being able to monitor 100s if
> not 1000s of hosts more effectively?
[...]
> Or is there a more elegant solution?

If I wanted to do this on a UNIX system, there's a couple of ways.

1. The easiest would be to simply create a number of virtual Apache
hosts. Does your comment about not being able to spin up multiple HTTP
server instances rule this out? There would only be one instance, the
rest would be virtual (different names and/or ports).

2. Alternatively, I would create a wrapper for multimon.cgi for each
location which would simply copy the relevant hosts.conf file into place
overwriting the existing one each time before calling multimon.cgi.

It's many years since I've used IIS so I'm not sure whether it does
virtual hosts (... my friend Google says it does). For the wrapper
script, I imagine you could use WSH.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Lars Täuber
In reply to this post by Users mailing list
Fri, 21 Jul 2017 02:29:47 +0000 (UTC)
Andrej Scholtz via Apcupsd-users <[hidden email]> ==> "[hidden email]" <[hidden email]> :
> Or is there a more elegant solution?

Maybe apcupsd should cache the results of other instances and the webserver only displays the known statuses or "unknown". This could mean a new variable to be necessary to the config for a time period the distant hosts are asked for their status.
But I haven't looked into the code.

Cheers
Lars

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Users mailing list
In reply to this post by Trevor Roydhouse
Yes Trevor. I forgot to mention. Preferably Windows using a simple http server such as mongoose with old school cgi support. Additionally, I need to be able to edit or add more configuration files often or dynamically due to number of hosts or sites being monitored and to be able to open up a page for multiple sites at the same time on the same box (so overwriting a single conf file may not be ideal).

I can look into UNIX alternative but in the current environment Windows would be preferred.

Andrej

> On Jul 20, 2017, at 10:09 PM, Trevor Roydhouse <[hidden email]> wrote:
>
> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 12:29:
>> Next problem I faced was being able to maintain multiple "hosts.conf"
>> files for different geographical sites, regions or datacenters etc.
>>
>> And here is where I got stuck.
>>
>> There was no way for me to spin up multiple HTTP server instances.
>> Seems like the "<Drive Letter>:\etc\apcupsd\hosts.conf" is hard
>> coded into the program.
> [...]
>> Would it be possible to implement a "hosts=something" POST variable
>> similar to refresh and add support for being able to monitor 100s if
>> not 1000s of hosts more effectively?
> [...]
>> Or is there a more elegant solution?
>
> If I wanted to do this on a UNIX system, there's a couple of ways.
>
> 1. The easiest would be to simply create a number of virtual Apache hosts. Does your comment about not being able to spin up multiple HTTP server instances rule this out? There would only be one instance, the rest would be virtual (different names and/or ports).
>
> 2. Alternatively, I would create a wrapper for multimon.cgi for each location which would simply copy the relevant hosts.conf file into place overwriting the existing one each time before calling multimon.cgi.
>
> It's many years since I've used IIS so I'm not sure whether it does virtual hosts (... my friend Google says it does). For the wrapper script, I imagine you could use WSH.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Users mailing list
I've tried apache on Windows in hopes of setting up virtual hosts and the same issue remains. I cannot get the multimon.cgi look for the hosts.conf file in any other location than the hard coded one of C:\etc\apcupsd or whatever drive letter the httpd process runs from.
I can't seem to be able to place the hosts.conf anywhere in the ServerRoot or DocumentRoot. As soon as I change the location from the root of C: I get "Error: Cannot open hosts file" from the multimon.cgi page.

Andrej

> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users <[hidden email]> wrote:
>
> Yes Trevor. I forgot to mention. Preferably Windows using a simple http server such as mongoose with old school cgi support. Additionally, I need to be able to edit or add more configuration files often or dynamically due to number of hosts or sites being monitored and to be able to open up a page for multiple sites at the same time on the same box (so overwriting a single conf file may not be ideal).
>
> I can look into UNIX alternative but in the current environment Windows would be preferred.
>
> Andrej
>
>> On Jul 20, 2017, at 10:09 PM, Trevor Roydhouse <[hidden email]> wrote:
>>
>> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 12:29:
>>> Next problem I faced was being able to maintain multiple "hosts.conf"
>>> files for different geographical sites, regions or datacenters etc.
>>>
>>> And here is where I got stuck.
>>>
>>> There was no way for me to spin up multiple HTTP server instances.
>>> Seems like the "<Drive Letter>:\etc\apcupsd\hosts.conf" is hard
>>> coded into the program.
>> [...]
>>> Would it be possible to implement a "hosts=something" POST variable
>>> similar to refresh and add support for being able to monitor 100s if
>>> not 1000s of hosts more effectively?
>> [...]
>>> Or is there a more elegant solution?
>>
>> If I wanted to do this on a UNIX system, there's a couple of ways.
>>
>> 1. The easiest would be to simply create a number of virtual Apache hosts. Does your comment about not being able to spin up multiple HTTP server instances rule this out? There would only be one instance, the rest would be virtual (different names and/or ports).
>>
>> 2. Alternatively, I would create a wrapper for multimon.cgi for each location which would simply copy the relevant hosts.conf file into place overwriting the existing one each time before calling multimon.cgi.
>>
>> It's many years since I've used IIS so I'm not sure whether it does virtual hosts (... my friend Google says it does). For the wrapper script, I imagine you could use WSH.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Apcupsd-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/apcupsd-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Trevor Roydhouse
> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users <[hidden email]> wrote:

>
> Yes Trevor. I forgot to mention. Preferably Windows using a simple
> http server such as mongoose with old school cgi support.
> Additionally, I need to be able to edit or add more configuration
> files often or dynamically due to number of hosts or sites being
> monitored and to be able to open up a page for multiple sites at
> the same time on the same box (so overwriting a single conf file
> may not be ideal).
>
> I can look into UNIX alternative but in the current environment
> Windows would be preferred.
 > Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 19:04:
 > I've tried apache on Windows in hopes of setting up virtual hosts and
 > the same issue remains. I cannot get the multimon.cgi look for the
 > hosts.conf file in any other location than the hard coded one of
 > C:\etc\apcupsd or whatever drive letter the httpd process runs from.
 > I can't seem to be able to place the hosts.conf anywhere in the
 > ServerRoot or DocumentRoot. As soon as I change the location from the
 > root of C: I get "Error: Cannot open hosts file" from the
 > multimon.cgi page.

Do a quick and dirty hack by renaming the multimon.cgi binary to
multimon1.cgi, multimon2.cgi etc and editing the "hosts.conf" string in
the binary to be host1.conf, host2.conf etc.

(I tested this hack on my FreeBSD system and it works as advertised this
time :)



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Users mailing list
: D Thank you Trevor! As a quick and dirty hack I think this will work, although seems like I will have to also replace the *.conf and *.cgi string cross references across all other .cgi files namely the upsfstats.cgi, upsimage.cgi and upsstats.cgi while of course keeping the filename strings the same length in order to avoid additional "Access to host 1.2.3.4 is not authorized." errors when following links from the multimonX.cgi main page. And do this programmatically in order to generate so many more copies of otherwise same binaries for each site or group of UPSes being monitored.
Also I cannot get the renamed upsimage.cgi to work correctly so clicking the system details doesn't show the bar chart graphics properly. I will keep researching.
Otherwise, initial test (modified one set of binaries) looks promising so thank you again for the hack suggestion.

Just wish that I would know C well enough to bake in support for multiple hosts.conf strings straight into the source code as a variable that could be part of the url request string (perhaps even have the site(s) 2 hosts config in an additional etc apcupsd 'sites.conf' file for extra safety).

Andrej

On Jul 21, 2017, at 3:24 AM, Trevor Roydhouse <[hidden email]> wrote:

>> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users <[hidden email]> wrote:
>>
>> Yes Trevor. I forgot to mention. Preferably Windows using a simple
>> http server such as mongoose with old school cgi support.
>> Additionally, I need to be able to edit or add more configuration
>> files often or dynamically due to number of hosts or sites being
>> monitored and to be able to open up a page for multiple sites at
>> the same time on the same box (so overwriting a single conf file
>> may not be ideal).
>>
>> I can look into UNIX alternative but in the current environment
>> Windows would be preferred.
>
>> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 19:04:
>> I've tried apache on Windows in hopes of setting up virtual hosts and
>> the same issue remains. I cannot get the multimon.cgi look for the
>> hosts.conf file in any other location than the hard coded one of
>> C:\etc\apcupsd or whatever drive letter the httpd process runs from.
>> I can't seem to be able to place the hosts.conf anywhere in the
>> ServerRoot or DocumentRoot. As soon as I change the location from the
>> root of C: I get "Error: Cannot open hosts file" from the
>> multimon.cgi page.
>
> Do a quick and dirty hack by renaming the multimon.cgi binary to multimon1.cgi, multimon2.cgi etc and editing the "hosts.conf" string in the binary to be host1.conf, host2.conf etc.
>
> (I tested this hack on my FreeBSD system and it works as advertised this time :)
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Users mailing list
Trevor,

This worked well, although not very elegant.
I ended up with 500+ .conf files and ~3500 modified .cgi binaries.
Was able to utilize Python to get this done rather quickly as well as create several landing html pages to sort the UPSes being monitored by state, region, site, etc.
The upsimage.cgi did not need modifications after all and works as expected.

Thank you again for the suggestion!

Andrej



From: Andrej Scholtz via Apcupsd-users <[hidden email]>
To: [hidden email]
Cc: Andrej Scholtz <[hidden email]>
Sent: Friday, July 21, 2017 4:33 AM
Subject: Re: [Apcupsd-users] multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

: D Thank you Trevor! As a quick and dirty hack I think this will work, although seems like I will have to also replace the *.conf and *.cgi string cross references across all other .cgi files namely the upsfstats.cgi, upsimage.cgi and upsstats.cgi while of course keeping the filename strings the same length in order to avoid additional "Access to host 1.2.3.4 is not authorized." errors when following links from the multimonX.cgi main page. And do this programmatically in order to generate so many more copies of otherwise same binaries for each site or group of UPSes being monitored.
Also I cannot get the renamed upsimage.cgi to work correctly so clicking the system details doesn't show the bar chart graphics properly. I will keep researching.
Otherwise, initial test (modified one set of binaries) looks promising so thank you again for the hack suggestion.

Just wish that I would know C well enough to bake in support for multiple hosts.conf strings straight into the source code as a variable that could be part of the url request string (perhaps even have the site(s) 2 hosts config in an additional etc apcupsd 'sites.conf' file for extra safety).

Andrej

On Jul 21, 2017, at 3:24 AM, Trevor Roydhouse <[hidden email]> wrote:

>> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users <[hidden email]> wrote:
>>
>> Yes Trevor. I forgot to mention. Preferably Windows using a simple
>> http server such as mongoose with old school cgi support.
>> Additionally, I need to be able to edit or add more configuration
>> files often or dynamically due to number of hosts or sites being
>> monitored and to be able to open up a page for multiple sites at
>> the same time on the same box (so overwriting a single conf file
>> may not be ideal).
>>
>> I can look into UNIX alternative but in the current environment
>> Windows would be preferred.
>
>> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 19:04:
>> I've tried apache on Windows in hopes of setting up virtual hosts and
>> the same issue remains. I cannot get the multimon.cgi look for the
>> hosts.conf file in any other location than the hard coded one of
>> C:\etc\apcupsd or whatever drive letter the httpd process runs from.
>> I can't seem to be able to place the hosts.conf anywhere in the
>> ServerRoot or DocumentRoot. As soon as I change the location from the
>> root of C: I get "Error: Cannot open hosts file" from the
>> multimon.cgi page.
>
> Do a quick and dirty hack by renaming the multimon.cgi binary to multimon1.cgi, multimon2.cgi etc and editing the "hosts.conf" string in the binary to be host1.conf, host2.conf etc.
>
> (I tested this hack on my FreeBSD system and it works as advertised this time :)

>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Trevor Roydhouse
Andrej Scholtz via Apcupsd-users wrote on 23/07/2017 07:52:
> Trevor,
>
> This worked well, although not very elegant.
> I ended up with 500+ .conf files and ~3500 modified .cgi binaries.
> Was able to utilize Python to get this done rather quickly as well as
> create several landing html pages to sort the UPSes being monitored by
> state, region, site, etc.

Wow - 500+ and ~3,500. I didn't realise the scale of your issue!

> The upsimage.cgi did not need modifications after all and works as
> expected.

I was wondering about that.

> Thank you again for the suggestion!

You're most welcome!

------------------------------------------------------------------------

> *From:* Andrej Scholtz via Apcupsd-users
> <[hidden email]>
> *To:* [hidden email]
> *Cc:* Andrej Scholtz <[hidden email]>
> *Sent:* Friday, July 21, 2017 4:33 AM
> *Subject:* Re: [Apcupsd-users] multimon.cgi limitations - monitoring
> multiple (100s) of systems running upsd
>
> : D Thank you Trevor! As a quick and dirty hack I think this will work,
> although seems like I will have to also replace the *.conf and *.cgi
> string cross references across all other .cgi files namely the
> upsfstats.cgi, upsimage.cgi and upsstats.cgi while of course keeping the
> filename strings the same length in order to avoid additional "Access to
> host 1.2.3.4 is not authorized." errors when following links from the
> multimonX.cgi main page. And do this programmatically in order to
> generate so many more copies of otherwise same binaries for each site or
> group of UPSes being monitored.
> Also I cannot get the renamed upsimage.cgi to work correctly so clicking
> the system details doesn't show the bar chart graphics properly. I will
> keep researching.
> Otherwise, initial test (modified one set of binaries) looks promising
> so thank you again for the hack suggestion.
>
> Just wish that I would know C well enough to bake in support for
> multiple hosts.conf strings straight into the source code as a variable
> that could be part of the url request string (perhaps even have the
> site(s) 2 hosts config in an additional etc apcupsd 'sites.conf' file
> for extra safety).
>
> Andrej
>
> On Jul 21, 2017, at 3:24 AM, Trevor Roydhouse <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>>> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>>>
>>> Yes Trevor. I forgot to mention. Preferably Windows using a simple
>>> http server such as mongoose with old school cgi support.
>>> Additionally, I need to be able to edit or add more configuration
>>> files often or dynamically due to number of hosts or sites being
>>> monitored and to be able to open up a page for multiple sites at
>>> the same time on the same box (so overwriting a single conf file
>>> may not be ideal).
>>>
>>> I can look into UNIX alternative but in the current environment
>>> Windows would be preferred.
>>
>>> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 19:04:
>>> I've tried apache on Windows in hopes of setting up virtual hosts and
>>> the same issue remains. I cannot get the multimon.cgi look for the
>>> hosts.conf file in any other location than the hard coded one of
>>> C:\etc\apcupsd or whatever drive letter the httpd process runs from.
>>> I can't seem to be able to place the hosts.conf anywhere in the
>>> ServerRoot or DocumentRoot. As soon as I change the location from the
>>> root of C: I get "Error: Cannot open hosts file" from the
>>> multimon.cgi page.
>>
>> Do a quick and dirty hack by renaming the multimon.cgi binary to
> multimon1.cgi, multimon2.cgi etc and editing the "hosts.conf" string in
> the binary to be host1.conf, host2.conf etc.
>>
>> (I tested this hack on my FreeBSD system and it works as advertised
> this time :)
>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Apcupsd-users mailing list
> [hidden email]
> <mailto:[hidden email]>
> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Apcupsd-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Ted Mittelstaedt-5

Last year I happened to be leaving my bank only to see an APC 1500RM
sitting next to the garbage.  I asked the bank staff about it and
they said "Oh our IT person said that's broken"  I offered to take it to
the recycling and they said "sure"  Needless to say it just needed new
batteries.  Loads better than the free toaster for opening a new account!

Stuff like that comes from Andrej's world.  With 3500 UPSes on
monitoring and an average battery life of 3 years he would have a
failure rate of around 3 UPSes a day.  The only possible way to
keep up would be to issue a policy to just replace any existing
failed UPS with new ones.  That would likely be cheaper than the
labor costs of hiring people who could actually replace the batteries
instead of minimum wage grunts you can just call and walk through
the process over the phone of unboxing the new UPS you drop-shipped
out there and swapping it out when you remotely turn the server off.

Ted

On 7/22/2017 3:22 PM, Trevor Roydhouse wrote:

> Andrej Scholtz via Apcupsd-users wrote on 23/07/2017 07:52:
>> Trevor,
>>
>> This worked well, although not very elegant.
>> I ended up with 500+ .conf files and ~3500 modified .cgi binaries.
>> Was able to utilize Python to get this done rather quickly as well as
>> create several landing html pages to sort the UPSes being monitored by
>> state, region, site, etc.
>
> Wow - 500+ and ~3,500. I didn't realise the scale of your issue!
>
>> The upsimage.cgi did not need modifications after all and works as
>> expected.
>
> I was wondering about that.
>
>> Thank you again for the suggestion!
>
> You're most welcome!
>
> ------------------------------------------------------------------------
>> *From:* Andrej Scholtz via Apcupsd-users
>> <[hidden email]>
>> *To:* [hidden email]
>> *Cc:* Andrej Scholtz <[hidden email]>
>> *Sent:* Friday, July 21, 2017 4:33 AM
>> *Subject:* Re: [Apcupsd-users] multimon.cgi limitations - monitoring
>> multiple (100s) of systems running upsd
>>
>> : D Thank you Trevor! As a quick and dirty hack I think this will work,
>> although seems like I will have to also replace the *.conf and *.cgi
>> string cross references across all other .cgi files namely the
>> upsfstats.cgi, upsimage.cgi and upsstats.cgi while of course keeping the
>> filename strings the same length in order to avoid additional "Access to
>> host 1.2.3.4 is not authorized." errors when following links from the
>> multimonX.cgi main page. And do this programmatically in order to
>> generate so many more copies of otherwise same binaries for each site or
>> group of UPSes being monitored.
>> Also I cannot get the renamed upsimage.cgi to work correctly so clicking
>> the system details doesn't show the bar chart graphics properly. I will
>> keep researching.
>> Otherwise, initial test (modified one set of binaries) looks promising
>> so thank you again for the hack suggestion.
>>
>> Just wish that I would know C well enough to bake in support for
>> multiple hosts.conf strings straight into the source code as a variable
>> that could be part of the url request string (perhaps even have the
>> site(s) 2 hosts config in an additional etc apcupsd 'sites.conf' file
>> for extra safety).
>>
>> Andrej
>>
>> On Jul 21, 2017, at 3:24 AM, Trevor Roydhouse <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>>> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users
>> <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Yes Trevor. I forgot to mention. Preferably Windows using a simple
>>>> http server such as mongoose with old school cgi support.
>>>> Additionally, I need to be able to edit or add more configuration
>>>> files often or dynamically due to number of hosts or sites being
>>>> monitored and to be able to open up a page for multiple sites at
>>>> the same time on the same box (so overwriting a single conf file
>>>> may not be ideal).
>>>>
>>>> I can look into UNIX alternative but in the current environment
>>>> Windows would be preferred.
>>>
>>>> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 19:04:
>>>> I've tried apache on Windows in hopes of setting up virtual hosts and
>>>> the same issue remains. I cannot get the multimon.cgi look for the
>>>> hosts.conf file in any other location than the hard coded one of
>>>> C:\etc\apcupsd or whatever drive letter the httpd process runs from.
>>>> I can't seem to be able to place the hosts.conf anywhere in the
>>>> ServerRoot or DocumentRoot. As soon as I change the location from the
>>>> root of C: I get "Error: Cannot open hosts file" from the
>>>> multimon.cgi page.
>>>
>>> Do a quick and dirty hack by renaming the multimon.cgi binary to
>> multimon1.cgi, multimon2.cgi etc and editing the "hosts.conf" string in
>> the binary to be host1.conf, host2.conf etc.
>>>
>>> (I tested this hack on my FreeBSD system and it works as advertised
>> this time :)
>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Apcupsd-users mailing list
>> [hidden email]
>> <mailto:[hidden email]>
>> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Apcupsd-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Apcupsd-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

William P.N. Smith
It's more complicated than that. Many times I've put a new battery in a failed low-end UPS (BE550, et al) and been unsuccessful in the repair, (as the charging culircuit has failed?). Now your repair process is replace the battery, run a full calibration cycle to determine that it charges and discharges, and then put it back in service if it passed.

In a big company, it's probably way easier to throw it out and buy a new one. Especially if you're buying batteries from APC, which cost close to the price of a new UPS. 

If you are buying aftermarket batteries, IME, you are getting only about half the lifetime of APC batteries... 


Sent from my iPhone

On Jul 23, 2017, at 3:22 PM, Ted Mittelstaedt <[hidden email]> wrote:

The only possible way to
keep up would be to issue a policy to just replace any existing
failed UPS with new ones.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Pavel Boček
I wonder which crap has half the lifespan of Long or CSB which is in the majority of APC units, can you elaborate?

Panasonic which are still way cheaper than APC-rebranded crap have, on the contrary, about 50 % to twice the lifespan.

--
S uctivým pozdravem/best regards,

Pavel Boček
Jabber: [hidden email]
+420 739 190 151
http://www.hwworld.cz (kondenzátory, akumulátory, baterie aj./capacitors and more)
http://www.hardwareinsights.com (power supply reviews and more)


It's more complicated than that. Many times I've put a new battery in a failed low-end UPS (BE550, et al) and been unsuccessful in the repair, (as the charging culircuit has failed?). Now your repair process is replace the battery, run a full calibration cycle to determine that it charges and discharges, and then put it back in service if it passed.

In a big company, it's probably way easier to throw it out and buy a new one. Especially if you're buying batteries from APC, which cost close to the price of a new UPS. 

If you are buying aftermarket batteries, IME, you are getting only about half the lifetime of APC batteries... 


Sent from my iPhone

On Jul 23, 2017, at 3:22 PM, Ted Mittelstaedt <[hidden email]> wrote:

The only possible way to
keep up would be to issue a policy to just replace any existing
failed UPS with new ones.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

William P.N. Smith
I tend to buy batteries from RefurbUPS.com, which seem to be a random manufacturer every time.  One I have here is UPS Energy, whoever that is.  8*)

I’d be more than happy to have a recommendation for RBC-110 batteries in the $20 price range, along the lines of:


with a 5-year battery life like the new ones have…

Thanks!

On Jul 23, 2017, at 10:27 PM, Pavel Boček <[hidden email]> wrote:

I wonder which crap has half the lifespan of Long or CSB which is in the majority of APC units, can you elaborate?

Panasonic which are still way cheaper than APC-rebranded crap have, on the contrary, about 50 % to twice the lifespan.

--
S uctivým pozdravem/best regards,

Pavel Boček
Jabber: [hidden email]
+420 739 190 151
http://www.hwworld.cz (kondenzátory, akumulátory, baterie aj./capacitors and more)
http://www.hardwareinsights.com (power supply reviews and more)


It's more complicated than that. Many times I've put a new battery in a failed low-end UPS (BE550, et al) and been unsuccessful in the repair, (as the charging culircuit has failed?). Now your repair process is replace the battery, run a full calibration cycle to determine that it charges and discharges, and then put it back in service if it passed.

In a big company, it's probably way easier to throw it out and buy a new one. Especially if you're buying batteries from APC, which cost close to the price of a new UPS. 

If you are buying aftermarket batteries, IME, you are getting only about half the lifetime of APC batteries... 


Sent from my iPhone

On Jul 23, 2017, at 3:22 PM, Ted Mittelstaedt <[hidden email]> wrote:

The only possible way to
keep up would be to issue a policy to just replace any existing
failed UPS with new ones.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Trevor Roydhouse
In reply to this post by Pavel Boček
Pavel Boček wrote on 24/07/2017 12:27:
> Panasonic which are still way cheaper than APC-rebranded crap have, on
> the contrary, about 50 % to twice the lifespan.

That is also my experience with Panasonic batteries.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Pavel Boček
In reply to this post by William P.N. Smith
Panasonic UP-VW1245P1 is the best choice

--
S uctivým pozdravem/best regards,

Pavel Boček
Jabber: [hidden email]
+420 739 190 151
http://www.hwworld.cz (kondenzátory, akumulátory, baterie aj./capacitors and more)
http://www.hardwareinsights.com (power supply reviews and more)


I tend to buy batteries from RefurbUPS.com, which seem to be a random manufacturer every time.  One I have here is UPS Energy, whoever that is.  8*)

I’d be more than happy to have a recommendation for RBC-110 batteries in the $20 price range, along the lines of:


with a 5-year battery life like the new ones have…

Thanks!

On Jul 23, 2017, at 10:27 PM, Pavel Boček <[hidden email]> wrote:

I wonder which crap has half the lifespan of Long or CSB which is in the majority of APC units, can you elaborate?

Panasonic which are still way cheaper than APC-rebranded crap have, on the contrary, about 50 % to twice the lifespan.

--
S uctivým pozdravem/best regards,

Pavel Boček
Jabber: [hidden email]
+420 739 190 151
http://www.hwworld.cz (kondenzátory, akumulátory, baterie aj./capacitors and more)
http://www.hardwareinsights.com (power supply reviews and more)


It's more complicated than that. Many times I've put a new battery in a failed low-end UPS (BE550, et al) and been unsuccessful in the repair, (as the charging culircuit has failed?). Now your repair process is replace the battery, run a full calibration cycle to determine that it charges and discharges, and then put it back in service if it passed.

In a big company, it's probably way easier to throw it out and buy a new one. Especially if you're buying batteries from APC, which cost close to the price of a new UPS. 

If you are buying aftermarket batteries, IME, you are getting only about half the lifetime of APC batteries... 


Sent from my iPhone

On Jul 23, 2017, at 3:22 PM, Ted Mittelstaedt <[hidden email]> wrote:

The only possible way to
keep up would be to issue a policy to just replace any existing
failed UPS with new ones.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: multimon.cgi limitations - monitoring multiple (100s) of systems running upsd

Users mailing list
In reply to this post by Ted Mittelstaedt-5
Ted,

No failures yet (other than out-of-box which were promptly warrantied), although we've been deploying APCs only since January.
We will see in time what the failure rate is once we reach 1,000s of devices, however APC seems to stand behind their products including the standard warranty on expected battery life.
After all, they were the ones to recommend taking a look at apcupsd project (although they cannot understandably support it).

The only issue I've seen during the high volume deployment on Windows client machines that I had to work around and script for was when the daemon would start flooding with "Communications with UPS restored" every few seconds.
Using original APC signaling cables, but I suspect it has to do something with the signaling cables being to close proximity of other power sources/cables.

My fix was to detect two consecutive "Communications with UPS restored" events via grep, stop the apcupsd service, disable/unplug the Battery USB device via devcon, then start the service back up and reenable/replug the device via devcon.

As far as labor costs, the RS1000G units and possible many others now  have a reversible battery (no more screws or connecting the cables) so any user can do this and hot-swap easily.

Andrej



From: Ted Mittelstaedt <[hidden email]>
To: [hidden email]
Sent: Sunday, July 23, 2017 12:25 PM
Subject: Re: [Apcupsd-users] multimon.cgi limitations - monitoring multiple (100s) of systems running upsd


Last year I happened to be leaving my bank only to see an APC 1500RM
sitting next to the garbage.  I asked the bank staff about it and
they said "Oh our IT person said that's broken"  I offered to take it to
the recycling and they said "sure"  Needless to say it just needed new
batteries.  Loads better than the free toaster for opening a new account!

Stuff like that comes from Andrej's world.  With 3500 UPSes on
monitoring and an average battery life of 3 years he would have a
failure rate of around 3 UPSes a day.  The only possible way to
keep up would be to issue a policy to just replace any existing
failed UPS with new ones.  That would likely be cheaper than the
labor costs of hiring people who could actually replace the batteries
instead of minimum wage grunts you can just call and walk through
the process over the phone of unboxing the new UPS you drop-shipped
out there and swapping it out when you remotely turn the server off.

Ted

On 7/22/2017 3:22 PM, Trevor Roydhouse wrote:

> Andrej Scholtz via Apcupsd-users wrote on 23/07/2017 07:52:
>> Trevor,
>>
>> This worked well, although not very elegant.
>> I ended up with 500+ .conf files and ~3500 modified .cgi binaries.
>> Was able to utilize Python to get this done rather quickly as well as
>> create several landing html pages to sort the UPSes being monitored by
>> state, region, site, etc.
>
> Wow - 500+ and ~3,500. I didn't realise the scale of your issue!
>
>> The upsimage.cgi did not need modifications after all and works as
>> expected.
>
> I was wondering about that.
>
>> Thank you again for the suggestion!
>
> You're most welcome!
>
> ------------------------------------------------------------------------
>> *From:* Andrej Scholtz via Apcupsd-users
>> <[hidden email]>
>> *To:* [hidden email]
>> *Cc:* Andrej Scholtz <[hidden email]>
>> *Sent:* Friday, July 21, 2017 4:33 AM
>> *Subject:* Re: [Apcupsd-users] multimon.cgi limitations - monitoring
>> multiple (100s) of systems running upsd
>>
>> : D Thank you Trevor! As a quick and dirty hack I think this will work,
>> although seems like I will have to also replace the *.conf and *.cgi
>> string cross references across all other .cgi files namely the
>> upsfstats.cgi, upsimage.cgi and upsstats.cgi while of course keeping the
>> filename strings the same length in order to avoid additional "Access to
>> host 1.2.3.4 is not authorized." errors when following links from the
>> multimonX.cgi main page. And do this programmatically in order to
>> generate so many more copies of otherwise same binaries for each site or
>> group of UPSes being monitored.
>> Also I cannot get the renamed upsimage.cgi to work correctly so clicking
>> the system details doesn't show the bar chart graphics properly. I will
>> keep researching.
>> Otherwise, initial test (modified one set of binaries) looks promising
>> so thank you again for the hack suggestion.
>>
>> Just wish that I would know C well enough to bake in support for
>> multiple hosts.conf strings straight into the source code as a variable
>> that could be part of the url request string (perhaps even have the
>> site(s) 2 hosts config in an additional etc apcupsd 'sites.conf' file
>> for extra safety).
>>
>> Andrej
>>
>> On Jul 21, 2017, at 3:24 AM, Trevor Roydhouse <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>>> On Jul 21, 2017, at 12:25 AM, Andrej Scholtz via Apcupsd-users
>> <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Yes Trevor. I forgot to mention. Preferably Windows using a simple
>>>> http server such as mongoose with old school cgi support.
>>>> Additionally, I need to be able to edit or add more configuration
>>>> files often or dynamically due to number of hosts or sites being
>>>> monitored and to be able to open up a page for multiple sites at
>>>> the same time on the same box (so overwriting a single conf file
>>>> may not be ideal).
>>>>
>>>> I can look into UNIX alternative but in the current environment
>>>> Windows would be preferred.
>>>
>>>> Andrej Scholtz via Apcupsd-users wrote on 21/07/2017 19:04:
>>>> I've tried apache on Windows in hopes of setting up virtual hosts and
>>>> the same issue remains. I cannot get the multimon.cgi look for the
>>>> hosts.conf file in any other location than the hard coded one of
>>>> C:\etc\apcupsd or whatever drive letter the httpd process runs from.
>>>> I can't seem to be able to place the hosts.conf anywhere in the
>>>> ServerRoot or DocumentRoot. As soon as I change the location from the
>>>> root of C: I get "Error: Cannot open hosts file" from the
>>>> multimon.cgi page.
>>>
>>> Do a quick and dirty hack by renaming the multimon.cgi binary to
>> multimon1.cgi, multimon2.cgi etc and editing the "hosts.conf" string in
>> the binary to be host1.conf, host2.conf etc.
>>>
>>> (I tested this hack on my FreeBSD system and it works as advertised
>> this time :)
>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Apcupsd-users mailing list
>> [hidden email]
>> <mailto:[hidden email]>
>> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Apcupsd-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/apcupsd-users

>>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Apcupsd-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/apcupsd-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Loading...