| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
- Locations that are set to "never" or "only outside business hours"
will not be considered during WOL, and not delivered to the guacamole
proxy.
- If we cannot wake as much machines per remote group as configured,
we'll display a little number next to the WOL count setting.
|
| |
|
|
|
|
|
| |
This doesn't make any sense; we already account for this by looking at
the woltime column.
This reverts commit 0c561cd07c82d09ec5f6f1aa0a92ead403d0952b.
|
| |
|
|
|
|
|
|
| |
If a location is assigned to multiple groups, we potentially wake too
many machines, as the number of clients that received a WOL in that
location when processing group A is not accounted for when peocessing
arrives at location B. Keep track of the number of WOLed machines per
location to be able to avoid this situation.
|
| |
|
|
|
| |
.... so the proper location information can be displayed on the WOL task
status page.
|
| |
|
|
|
|
|
| |
* Auto-convert to utf8mb4_unicode_520_ci
* Use foreach instead of while to loop over results
* Drop useless statement caching
* Keep emulated prepares, as we sometimes loop over nested queries
|
| | |
|
| |
|
|
| |
References #3823
|
| |
|
|
|
|
|
|
| |
Enable rebootcontrol module in ensureMachinesRunning(),
so it works from the call in api.inc.php.
Consider machines that we sent a WOL packet to during the last 90
seconds as online when counting number of idle machines, so slow
booting machines won't cause us to wake too many machines.
|
| | |
|
| |
|
