Do you want to erase alarms from the database, or simply acknowledge them so they won't be displayed by default in the Pending Alarms page?

The "Acknowledge All" option can only acknowledge alarms one page at a time. This can be time consuming if there are many pages of alarms. Note that alarms/events that occur on a regular schedule can be acknowledged automatically by creating a Maintenance Event in the Maintenance Events module.

I agree that sometimes there are too many pending alarms, and I often find that I want to acknowledge or silence some, but not all alarms. Currently the only way to acknowledge them is a one-or-all choice, so that if you want to acknowledge all but one of 100 alarms, you must acknowledge 99 alarms individually. It would be nice if we could filter the list before selecting "acknowledge all." It simply takes too long to acknowledge them individually, especially if we're connected over a high-latency link.

I think a good solution would be to implement the following:

• Rename the "Acknowledge All" link to "Acknowledge All This Page"
• Create a true "Acknowledge All" link
• Implement a filter to select which alarms to display, and acknowledge only those
• When selecting any of the "Acknowledge All" links, allow choosing the alarm level so that, for instance, you can acknowledge all Information in one go, but then acknowledge the Urgent events individually.

Extreme or incorrect values in the Mango data history have caused me a lot of problems (see the [url=http://mango.serotoninsoftware.com/forum/posts/list/1375.page Incorrect 0 point value...). We must have a way to locate and purge or modify selected data values in the PointValue history. I have deleted extreme values in the past via SQL, but these deletions are subject to errors (i.e. dangerous) and have often resulted in high-CPU usage problems that could only be rectified by restarting the Mango service.

While the "Discard extreme values" datapoint function is useful, it has limitations:

• It only applies to new values; it does not remove extreme values from the point history
• In most cases the Discard feature is not enabled until extreme values have already been stored in the history
• The discard value will not discard invalid 0.00000 values; it will only discard extreme values
• If the Discard function is enabled, there is no way to detect the time, frequency, or value of the discarded data, which makes it difficult to troubleshoot and prevent extreme values from occurring in the future.[/list]
  It would be helpful if an optional alarm event were initiated each time an extreme value is discarded. The alarm would include the time stamp, the discarded value, and the discard threshold.

What we need most of all is a point history editor that provides a means to select points based on their value and timestamp meeting certain criteria, and then either purge or modify those values (e.g. multiply or add to the point).

Extreme or incorrect values in the Mango data history have caused me a lot of problems (see the [url=http://mango.serotoninsoftware.com/forum/posts/list/1375.page Incorrect 0 point value...). We must have a way to locate and purge or modify selected data values in the PointValue history. I have deleted extreme values in the past via SQL, but these deletions are subject to errors (i.e. dangerous) and have often resulted in high-CPU usage problems that could only be rectified by restarting the Mango service.

While the "Discard extreme values" datapoint function is useful, it has limitations:

• It only applies to new values; it does not remove extreme values from the point history
• In most cases the Discard feature is not enabled until extreme values have already been stored in the history
• The discard value will not discard invalid 0.00000 values; it will only discard extreme values
• If the Discard function is enabled, there is no way to detect the time, frequency, or value of the discarded data, which makes it difficult to troubleshoot and prevent extreme values from occurring in the future.[/list]
  It would be helpful if an optional alarm event were initiated each time an extreme value is discarded. The alarm would include the time stamp, the discarded value, and the discard threshold.

What we need most of all is a point history editor that provides a means to select points based on their value and timestamp meeting certain criteria, and then either purge or modify those values (e.g. multiply or add to the point).

The nightly 'Medium Priority Work Items' that are causing 'datasource time value unchanged for 1 minute' alarms imply that there is a slowdown in the 1 second interval reading of the modbus data source. The problem isn't just the alarm, it is the data dropout that the alarm implies. This appears to be triggered every night by the automatic data purge:

INFO  2013-05-04 03:05:00,001 (com.serotonin.m2m2.rt.maint.DataPurge.executeImpl:60) - Data purge started  
INFO  2013-05-04 03:08:31,832 (com.serotonin.m2m2.rt.maint.DataPurge.executeImpl:70) - Data purge ended, 2001716 point samples deleted  

A simple solution may be to assign a low (or lower) priority to the data purge process, or assign it with ionice so that it does not tax the disk IO. When could something like this be implemented?
I have roughly 300 datapoints using Mango core 2.0.6
Thanks.

Whether I create a new meta datapoint or edit an existing one, when I click on Generate History that icon blinks for a while, and then a pop-up window displays the number of points generated. The number of points generated seems to correspond to the "Update event" interval and the inception of the first input context point; the wait time also seems to correlate to the number of points generated. However, the "Point Details" page does not show the newly generated points: neither in the point history nor in the graph. I suspect that the point history is being generated but not stored in the database. I use this feature a lot, both when fine tuning formulas or when creating new meta datapoints. Can you please look into this ASAP?

Relevant modules: core 2.0.6, meta 1.4.0

On a related note, when I was using Mango 1.12.4, it seemed that I often had to purge all data before generating history. Does "generate history" always generate from Inception to Latest, or do I have to purge old data first? What time interval does it generate over if I already have points in the history?
Thanks.

Whether I create a new meta datapoint or edit an existing one, when I click on Generate History that icon blinks for a while, and then a pop-up window displays the number of points generated. The number of points generated seems to correspond to the "Update event" interval and the inception of the first input context point; the wait time also seems to correlate to the number of points generated. However, the "Point Details" page does not show the newly generated points: neither in the point history nor in the graph. I suspect that the point history is being generated but not stored in the database. I use this feature a lot, both when fine tuning formulas or when creating new meta datapoints. Can you please look into this ASAP?

Relevant modules: core 2.0.6, meta 1.4.0

On a related note, when I was using Mango 1.12.4, it seemed that I often had to purge all data before generating history. Does "generate history" always generate from Inception to Latest, or do I have to purge old data first? What time interval does it generate over if I already have points in the history?
Thanks.

I have an event detector that raises an alarm if the time stamp register value obtained from a data source does not change in more than one minute (I read that source every second, over Ethernet). Shortly after 3am almost every night, the following occurs:

1. The time stamp unchanged alarm is raised,
2. The CPU idle goes down
3. CPU I/O wait goes up.
4. Points to write goes way up
5. Disk block writes goes up, but disk block reads goes way up
6. Medium Priority Work Items shoots up from zero into the thousands

Questions:

1. What are these Medium Priority Work Items? Why is the peak number so different each night?
2. How can I minimize the load or quantity of that 3am thread?
3. Can Mango be modified so the Medium Priority Work Items are assigned a priority that is low enough to not interfere with data source reading?
4. Can the Medium Priority Work items be staggered so they're not all submitted at 3am?
5. Can Mango be modified so that reading a data source is assigned a higher priority thread?

Thanks

I have an event detector that raises an alarm if the time stamp register value obtained from a data source does not change in more than one minute (I read that source every second, over Ethernet). Shortly after 3am almost every night, the following occurs:

1. The time stamp unchanged alarm is raised,
2. The CPU idle goes down
3. CPU I/O wait goes up.
4. Points to write goes way up
5. Disk block writes goes up, but disk block reads goes way up
6. Medium Priority Work Items shoots up from zero into the thousands

Questions:

1. What are these Medium Priority Work Items? Why is the peak number so different each night?
2. How can I minimize the load or quantity of that 3am thread?
3. Can Mango be modified so the Medium Priority Work Items are assigned a priority that is low enough to not interfere with data source reading?
4. Can the Medium Priority Work items be staggered so they're not all submitted at 3am?
5. Can Mango be modified so that reading a data source is assigned a higher priority thread?

Thanks

I'm using the free Fail2ban (https://en.wikipedia.org/wiki/Fail2ban) software to ban brute force ssh login attemps, and it is banning 1-3 IP addresses every day.

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email, or ejecting CD-ROM tray) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, curier, ssh, etc).
http://www.fail2ban.org/
If you can implement the first feature:

• Write failed login attempts to a log file, including originating IP address
  ... then we can use [url=http://www.fail2ban.org/] fail2ban to watch the Mango log file for repeated login failures. Fail2ban will take care of banning the IP address if the number of failed login entries exceeds the allowed number. This would be a fast track to improved security.
  How about it?
  Source code at https://github.com/fail2ban/fail2ban (not that you would need it).

Thanks.

I must determine whether it is safe to grant write access to Internet Mango users without creating unnecessary risks. To implement this without adding too much danger, I must know whether common security features have been implemented.

Which of the security features below have been implemented in Mango Automation 2.x?

• Write failed login attempts to a log file, including originating IP address
• Ban IP addresses with repeated login failures to prevent brute force attacks
• Salt the passwords to prevent a break-in via a user with a weak password from making all other users vulnerable
• Sanitize inputs to prevent SQL back door attacks as illustrated in [url=http://xkcd.com/327/]this cartoon

Thanks