| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The current CLI did not support multiple prefix-delegations per interface. Some
ISPs only send one /64 to a client per prefix-delegation request, but they
allow the customer to request multiple prefixes.
The 'dhcpv6-options prefix-delegation' node has been renamed and converted to a
tag node named 'dhcpv6-options pd'. The tag node specifies a PD request (>=0).
In the past the user needed to know what prefix will be assigned and required
to calculate the sla-len by himself. The 'sla-len' node was dropped and is now
calculated in the background from the 'dhcpv6-options pd 0 length' node.
It is no longer mandatory to supply the 'sla-id' node, if sla-id is not
specified it is 'guessed' by counting upwards.
Example configuration:
----------------------
ethernet eth1 {
address dhcpv6
dhcpv6-options {
pd 0 {
length 56
interface eth2 {
address 1
}
}
}
}
This will request a /56 assignment from the ISP and will delegate a /64 network
to interface eth2. VyOS will use the interface address ::1 on the delegate
interface (eth2) as its local address.
|
|
|
|
|
|
anyconnect: T2811: Return None if anyconnect not configured
|
|
|
|
|
|
|
|
|
|
* 't2564-lcd' of github.com:c-po/vyos-1x:
lcd: T2564: flatten CLI interface
system display: T2564: Added test model
system display: T2564: Dictionary code update
system display: T2564: Conf files to /run
system display: T2564: Changed "duration" to "time"
system display: T2564: py code cleanup
system display: T2564: Replace "config (enabled|disabled)" with "display disabled"
system display: T2564: Lowercase model names
system display: T2564 Extend VyOS to support appliance LCDs
|
|
|
|
Add missing verify() check that at least one interface must be defined to
listen to PPPoE data.
|
|
* set system lcd device <device>
* set system lcd model <modeml>
Both device and model have completion helpers for supported interfaces and LCD
displays.
|
|
|
|
t2564-lcd
* 'system-display' of https://github.com/fmertz/vyos-1x:
system display: T2564: Added test model
system display: T2564: Dictionary code update
system display: T2564: Conf files to /run
system display: T2564: Changed "duration" to "time"
system display: T2564: py code cleanup
system display: T2564: Replace "config (enabled|disabled)" with "display disabled"
system display: T2564: Lowercase model names
system display: T2564 Extend VyOS to support appliance LCDs
|
|
|
|
|
|
When running SSH from the VyOS system the source IP address can be set by:
set system options ssh-client source-address x.x.x.x
|
|
Problem was introduced in commit 740ace13 ("router-advert: T2609: add missing
verify() for prefix lifetime"). The 'infinity' literal was not converted to its
corresponding integer 0xffffffff (4294967295) for the check.
|
|
Move sshd_config file to /run so it must be generated on every boot and is
not stored accidently.
|
|
This removes additional code paths as we can instatly work with the input dict
the same was as it was done for PPPoE. This fixes the entire DHCPv6-PD support
on non PPPoE interfaces as this was lost in translation while processing T2653.
|
|
Make the port used for RADIUS accounting user configurable. This is now
valid for the following services which are based on Accel-PPP:
* ipoe-server
* pppoe-server
* l2tp
* pptp
* sstp
|
|
|
|
|
|
Migration files on the storage should be done one time by a migration script
instead of every time the configuration changes. Moving this to an older
migration script is fine as this is around for a long time and all rolling
releases are already up2date. It only affects updates from VyOS 1.2 series.
|
|
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
Further reduce the boiler-plate code to determine interface tag node or not.
It can be passed into get_interface_dict() if explicitly required - else it
is taken from the environment.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
This can be used to see if a tagNode has been changed. It will return a list
of changed nodes.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
After switching from raw parsing of the interface options to get_config_dict()
this utilizes another utility function which wraps get_config_dict() and adds
other common and reused parameters (like deleted or bridge member).
Overall this drops redundant code (again) and makes the rest more maintainable
as we only utilize a single function.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
While providing a new update() method in vyos.ifconfig.interfaces() this is
extended for pdeudo-ethernet interfaces in the derived class.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
While providing a new update() method in vyos.ifconfig.interfaces() this is
extended for bridge interfaces in the derived bridge class.
Signed-off-by: Christian Poessinger <christian@poessinger.com>
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
While providing a new update() method in vyos.ifconfig.interfaces() this is
extended for ethernet based interfaces which also supports 802.1q, 802.1ad
VLANs. This commit migrates the existing codebase for an ethernet based
interfaces and implements the missing parts for VLANs. Adding or migrating other
interfaces (e.g. bridge or bond) will become much easier as they must reuse
the entire functionality - we now walk towards a single codepath.
Thanks for all who made this combined effort possible!
Signed-off-by: Christian Poessinger <christian@poessinger.com>
|
|
l2tpv3, wireguard, wirelessmodem, nat all require additional Kernel modules
to be present on the system. Each and every interface implemented their own
way of loading a module - by copying code.
Use a generic function, vyos.util.check_kmod() to load any arbitrary kernel
module passed as string or list.
|
|
Fix for https://phabricator.vyos.net/T2725
T2492 / a07e22377ab83104ac925e13d1824f241f0f8d4a
introduced a change which broke the initialization of
the user dict. In case the config contained an user
without an encrypted-password set, the property would
be missing and the commit would crash with
`KeyError: 'password_encrypted'`
|
|
Rules without a translation address are also valid, they'll modify just
the port and leave the address intact.
This also used to be a valid syntax and it caused an error on upgrade.
|
|
Add additional verify() stage to check that the relaying interface actually
exists on the system.
|
|
Since it is not impossible to change MACVLAN interface mode on the fly, this fix adds a new one trigger to recreate it from scratch if the mode changed in system config
|
|
Please note that either interface or address can be configured.
system {
options {
http-client {
source-interface eth0
source-address 1.1.1.1
}
}
}
|
|
The 3rd party library used for calculating the SNMP hashes in advance only
worked for SHA and nod for MD5 as SHA was hardcoded [1]. The code has been
replaced by a class-less implementation providing only the required
functionality.
[1]: https://github.com/TheMysteriousX/SNMPv3-Hash-Generator/issues/2
|
|
|
|
As of now when adding new credentials for any SNMPv3 user we submit the
credential either plaintext or encrypted. A plaintext credential will be hashed
by SNMPd in the background and then passed back into the CLI so it's not stored
in cleartext. This feels like the wrong way in changing the CLI content with
data produced by a 3rd party daemon which implements the service.
It feels like the tail wiggles the entire dog.
This should be changed in the following way:
- After retrieving the plaintext password from CLI, use Python to hash the key
in advance
- Re-populate the encrypted key into the CLI and drop the plaintext one
- Generate service configuration and continue startup of SNMPd
This also fixes a race condition when SNMPd started up but not properly
provided the hasehd keys in the configuration resulting in a ConfigurationError.
Now as we also support binding SNMPd to a VRF this fixes a deadlock situation
on bootup as we can only bind late to the VRF and require up to 5 restarts of
the service - but the service will never start.
|
|
* src/conf_mode/system-display.py added get_first_key to dictionary call
|
|
* src/conf_mode/system-display.py conf files to /run
+ src/systemd/LCDd@.service lo
- src/systemd/lcdproc.service
+ src/systemd/lcdproc@.service lo
|
|
* src/conf_mode/system-display.py cleanup use of dictionary
* data/templates/system-display/lcdproc.conf.tmpl cleanup, removed extra DateTime
|
