This is a string from a list of valid values (empty, "hostonly", "fqdn"). So it is not correct to just gather a true/false value here.
(cherry picked from commit e93242eb2a)
Apparently gettext() does not behave correctly when passed an empty string, this commit ensures gettext() is called only with non-empty strings
(cherry picked from commit 6ae99aba5c)
This fixes the GUI inconsistency reported in the referenced bug. On edit of an OpenVPN server that has tun mode, not shared key, and the gwredir checkbox checked, the local_network fields are shown, but actually they should be hidden (because that is what happens on first data entry when gwredir is checked).
At least this makes the GUI consistent. Then the other issues mentioned in Redmine feature 6483 can be addressed separately.
(cherry picked from commit fa20dac1b5)
If _POST['members'] or _POST['groups'] is not set / none selected at GUI, it would give a warning on crash reporter (dev versions)
(cherry picked from commit 9f4722022f)
Currently if you delete your own user name, then the config ends up with a blank user tag in it. Rather than fix that up, it seems dangerous to be able to delete yourself anyway, because if you are the last user with admin privs for which you know the password (i.e. if you have not recorded the password for "admin" somewhere), then you can lock yourself out. That would require console access to fix, which for some people is a pain.
It seems reasonable to me to make the person login as some other user with admin privs to delete "themselves".
Bit of boots and braces done here:
1) Don't show the trash bin icon for "yourself", and also disable the delete_check checkbox. So you can't opt to delete yourself from the ordinary front-end GUI.
2) Enhance the back-end validation to prevent deleting yourself, just in case someone mucks about in the front-end code.
3) Put error messages to tell people when something is not deleted, and why.
4) In the success message for multi-deletion, tell which user names have actually been deleted.
(cherry picked from commit d6b79c398d)
1) Function can be simplified and all "if" statements removed, using intdiv (or casting result as int for PHP < 7) and % for calcs and sprintf for padding.
2) Input validity check before trying to convert format
3) If time represented is large (eg uptime might be several months) then hours becomes unhelpful, it's clearer to show "4921:02:06" as "205d 01:02:06". (Leading "days" value not shown unless >=1 for simplicity)
(cherry picked from commit 0bde6d1057)
Useful function in some circumstances - seems no reason not to have it.
Uses IP rather than hostname since not all ARP entries have hostnames.
Probably should also have "delete all" but not done that.
(cherry picked from commit 6ea0d41e3c)
backups should be a numeric int.
text hint for number of backups can now refer to the global value for this platform (and explains how to get that default, by leaving blank)
(cherry picked from commit 16b17c15f9)
At the same time the platform is being detected for PHP/GUI purposes, set the default number of backups. Also handle the case where (for any reason) detection fails, which it shouldn't, so the variables are still created
(cherry picked from commit 09a283948e)
Large keys are not "slower to use" in many cases, since they are only used to validate or set up a session. An ongoing session usually transfers to a symmetric algorithm once established, and the user won't notice the short extra delay in session startup.
(cherry picked from commit d4fdce4e2e)
Add key lengths to the OpenVPN options, for asymmetric keys of size 3072 (for current use), 7680, 15360 (for long term resistance), 8192 and 16384 (common binary exponents).
These are both supported by OpenVPN anyhow, and for certain uses are currently recommended (eg long term resistance to replay/decryption). See keylength.com for citations.
This PR would only affect OpenVPN, and OpenVPN supports these key sizes, so should not cause any issue.
(cherry picked from commit 0693c96797)
