This has been removed a long time ago and we should probably spend a
little bit more time on keeping the networking code tidy :)
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
* Translate string "Addon" in services.cgi
* Added EN/NL translations
* Correct existing plural DE translation for singular "Add-on"
* Fix usage of the incorrect strings "addon(s)" to correct
hyphenated "add-on(s)" also in other translation strings for
EN/NL/DE
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Some users assume that "check filesystem" does more than just
trigger a simple "fsck" run. This patch changes the button label to avoid
confusion. - NL translation
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
* addonctrl's new functionality to control explicit addon services was
implemented.
* Change 'Addon' column header to 'Addon Service' to be clear that
it's not addons but services listed here.
* Services not matching the name of the addon now display the addon
name between parentheses, so the user knows where the service comes
from.
* When no valid runlevel symlink is found by addonctrl for a service,
the 'enable on boot' checkbox is replaced by a small exclamation point
with alt-text "No valid runlevel symlink was found for the initscript of
this service." to inform user why a service can't be enabled.
* Added German and Dutch translation for above message.
Fixes: Bug#12935
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- Removed UI code from dblist function and refactor it making it return
a hash representing the pak db for easier handling of this data.
- Moved core update check in dblist to new seperate dbcoreinfo function
making it return a hash with current and possibly available core
version info.
- Update existing calls to dblist
- Bring UI parts previously in dblist to pakfire program itself,
pakfire.cgi and index.cgi with a few small enhancements:
- Translations for 'Core-Update', 'Release', 'Update' and 'Version'
- Add currently installed version numbers to installed paks list in
pakfire.cgi
- Add 'Installed: yes/no' to pakfire list output so people not using
colors have this information too. (Partly fixes Bug #12868)
- Add update available details to pakfire list output if package has
updates available.
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Since we dropped support for blocking P2P protocols, the corresponding translation strings
are no longer needed.
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
This has not been compiled into our version of wpa_supplicant (if it has
been ever) and so there is no danger to disable this without any further
ado.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
'bandwith...' should be 'bandwidth...'.
Despite being my favourite typo for the past few years(?),
today I decided to try to say 'Goodbye' to an old friend.
Similar to 'MB writen' its hard but I think it just about time.
'qos' and 'guardian' will never be the same for me... ;-)
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
While maintaining privacy when accessing web sites probably has never
been more important than it is today, faking Referer and User-Agent
headers is both obsolete and counterproductive:
(a) Most web sites require HTTPS, thwarting manipulation attempts to
HTTP headers in transit. Given todays' internet landscape, faking
these headers is unlikely to work for the vast majority of web
sites.
(b) It is trivial to detect faked HTTP User-Agent headers by obtaining
corresponding browser information via JavaScript. Any difference
most likely indicates (trivial) header manipulation attempts, hence
rendering this feature useless if browsers do not behave in the same
manner, which we cannot control on IPFire.
(c) Especially static Referer headers make users stick out like a sore
thumb, as nobody else in the world is likely to have the same
Referer set _all the time_.
Modern browsers attempt to strip sensitive information from Referer
headers, or ditch them completely, particularly to 3rd party sites.
Given the state of the web ecosystem as we know it today, enforcing
privacy in a centralised manner does not even come close to being
sufficient. Without gaining control over users' browsers, their
settings, and their infrastructure (such as setting up terminal
environments for accessing the web, preventing hardware
fingerprinting), a centralised attempt will at best fail, if not making
things worse, as highlighted in (c).
Therefore, removing these features from the Squid GUI is the least worse
option we have. We should not give our users a false sense of privacy.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This time without bold. ;-)
Altered the info text for restore to make clear that only the addon configs
are restored, not the addons themselves.
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
While preparing the Core153 update, I found by chance that a language string had been added from
Core152 to Core153 which I couldn't find in any CGI-file.
The translation suggested that this string ('Available Updates') could belong to 'pakfire.cgi'.
And I thought that on the pakfire GUI something was actually missing: the heading above the
box listing the 'Available Updates'. Don't know why I didn't saw this before.
So tried to add these missing heading. I hope I made it right...
Some cosmetic fixes:
I also added some space around the text for 'Available Addons' and 'Installed Addons'
because the text lines weren't separated. There is no seen wordwrapping. This required deleting
some unwanted '<br />' in the affected translation strings.
I tried this about 4 years ago, but somehow this patch got lost.
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This adds in the option to have "deny known clients" in dhcpd.conf
This is applied to the range command so applies to the dynamic addresses
given.
If you have just a range statement say in blue then if you are not using
vlans you could have the situation where a known host in green might end
up getting a lease from the blue range. Here a deny known-clients makes
sense. Your range in this case would be limited to only unknown clients if
deny known-clients was selected.
dhcp WUI has been modified to add in this command. Error message has been
added to check that a range has been specified if the deny unknown clients
checkbox has been selected.
Language files updated with additional items (English, German & Dutch).
For more information on the history of this please see the bugzilla entry
Signed-off-by: Adolf Belka <ahb.ipfire@gmail.com>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
I did the following:
- Rearranged the fields on 'guardian.cgi' a bit - in a (hopefully) logical manner,
so that they don't need so much room.
- Added some translation-strings and explanations to (revised) 'guardian.cgi'.
- Added missing language string(s), deleted obsolete.
- Deleted all guardian entries from standard language files in
'/var/ipfire/langs'-directory.
- Added (upgraded) addon-specific language files to '/var/ipfire/addon-lang'-directory.
I hope, I didn't forget something...
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
The correct case for "kilobit" is "kilobit", not "kiloBit".
And the same applies for Mbit, Gbit etc.
Reference is https://en.wikipedia.org/wiki/Kilobit
This commit changes the texts used in the web UI, so
that it correctly displays as "bit", "kbit", "Mbit" etc.
This fixes bugzilla item 10918.
Signed-off-by: Alf Høgemark <alf@i100.no>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Mark required input fields with a star as nowadays this is
the de-facto default. Before, it was the other way around and
optional fields were marked.
Signed-off-by: Lars Schumacher <larsen007@web.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>