| Age | Commit message (Collapse) | Author |
|---|
|
vyos@vmware:~$ show environment sensors
VyOS running under hypervisor, no sensors available
vyos@apu4:~$ show environment sensors
ath10k_hwmon-pci-0500
temp1: N/A
k10temp-pci-00c3
temp1: +54.6°C (high = +70.0°C)
(crit = +105.0°C, hyst = +104.0°C)
fam15h_power-pci-00c4
power1: 3.28 W (interval = 0.01 s, crit = 6.00 W)
|
|
This reverts commit 44355e6525daec62120601073065f63c9f9a7993.
|
|
Wake up host
vyos@vyos:~$ wake-on-lan interface eth0.201 host a:b:c:d:e:f
Wake up invalid host
vyos@vyos:~$ wake-on-lan interface eth0.201 host a:b:c:d:e:f:f
etherwake: The Magic Packet host address must be specified as
- a station address, 00:11:22:33:44:55, or
- a hostname with a known 'ethers' entry.
|
|
|
|
|
|
|
|
|
|
ISC does not support running the client on PPP(oE) interfaces which makes it
unusable for DHCPv6 Prefix Delegation tasks.
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Unsupported device type 512 for "pppoe0"
|
|
|
|
- "show nat source|destination statistics" is now implemented in Python
- "show nat source|destination rules" needs a new implementation, see T2459
- "show nat source|destination translations" has been copied over from the old
repo and is here until it is rewritten, this was not possible for "rules"
as there would have been too much dependencies. This one only requires
libxml-simple-perl
|
|
|
|
When instantiating NAT it is required to isntall some nftable jump targets.
The targets need to be added after a specific other target thus we need to
dynamically query the handler number. This is done by get_handler() which could
be moved to vyos.util at a later point in time so it can be reused for a
firewall rewrite.
|
|
|
|
|
|
This commit will update the version field of the generated deb package from the git repo version tag.
the tag needs to be in the format "vyos/<version>" eg. "vyos/1.2.5" 1.2.5 is then used as the version
The version field will be one of the following syntaxes:
on a commit:
- <version>-<commits from tag>-g<commit id>
eg. 1.2.5-4-g23232343
on a commit with unstaged changes:
- <version>-<commits from tag>-g<commit id>+dirty
eg. 1.2.5-4-g23232343+dirty
This will make it clear what state the repo was in when the package was generated.
It is possible to remove the number and commit id on the tagged commit, but i've decided to use the same
format for all commits tagged or not. as for now the tagged commit will be sufixed with -0-g<commit id>
if no valid tag is recieved from `git describe`, the script uses a 0.0 version number.
The changelog is also updated to reflext that we dont use it and refers to the Git Changelog and vyos release-notes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
easy-rsa is used by e.g. OpenVPN installation and was dropped when enabling
"--apt-recommends false" in VyOS build system. Dependency has been
explicitly added.
|
|
|
|
|
|
|
|
According to http://wiki.stocksy.co.uk/wiki/Multiple_SSIDs_with_hostapd every
SSID served by access-point should run on its own, locally administered MAC
address. Take the phy's interface MAC address as base and calculate a per
interface locally administered MAC address.
|
|
|
|
|
|
ppp already supports ip-pre-up script but none was being supplied. Need
ip-pre-up to handle renames and firewall properly.
Script imported from old VyOS PPP fork repository at
https://github.com/vyos/ppp-debian
|
|
|
|
vyos@vyos# show interfaces pppoe
pppoe pppoe0 {
default-route force
link eth2.7
mtu 400
name-server auto
password 12345678
user-id vyos@vyos.io
}
|
|
Commit e39f2ea ("dhclient-script: T1987: Multiple fixes in dhclient-script")
added the dhclient script but it missed the dependency.
|
|
This changeset contains multiple changes in structure, logic, and bugfixes for dhclient-script. It should provide better compatibility with new Debian versions and flexibility in controlling and changing VyOS-related functions.
1. Structure change:
* All VyOS-related functionality was moved from dhclient-script itself to separated hook files.
* Old vyatta-dhclient-hook was moved from vyatta-cfg to vyos-1x.
* This change allows discard dhclient-script replacing and use the original one from Debian without any changes. So, we do not need to track all changes in upstream so carefully.
* To provide compatibility between original dhclient-script and VyOS, two internal commands/functions are repaced in hooks: ip and make_resolv_conf. So, in all places where used ${ip} or make_resolv_conf, actually using VyOS-tuned functions instead original.
* `ip` function is a wrapper, which automatically chooses what to use: transparently pass a command to /usr/sbin/ip, change a route in kernel table or FRRouting config via vtysh.
* `make_resolv_conf` function main logic was copied from current VyOS implementation and use vyos-hostsd-client for making changes
2. Added:
* Logging. Now is possible to log all changes, what is doing by dhclient-script. Logs can be saved to the journal and displayed in stderr (for debugging purposes). By default, logging to the journal is enabled (at least for some time) to provide a way to collect enough information in case if some bug in this new implementation will be found. This can be changed in the 01-vyos-logging file.
3. Fixed/Changed:
* If DHCP lease was expired, released or dhclient was stopped, dhclient-script will try to delete default route from this lease.
* Instead of blindly killing all dhclients in case if FRRouting daemon is not running, now used more intelligent logic:
* dhclients are stopping natively (with all triggers processing), instead of killing;
* dhclient-script will not kill parent dhclient process. This allows to fix the problem when systemd inform about failing to rise up interfaces at early boot stages (used in Cloud-init images);
* dhclient-script will not touch dhclients, which are not related to the current interface or IP protocol version.
* For getting FRRouting daemon status used native way via watchfrr.sh, instead of the previous trick with vtysh accessibility.
* before adding a new route to FRRouting configuration, this route will be deleted from the kernel (if it is presented there). This allows to properly replace routes, added at early boot stages, when FRR not available.
* Routes in FRRouting are adding with "tag 210". This allows protecting static routes, added via CLI, from deletion when old routes are deleting by DHCP.
* DNS servers will be reconfigured only when $new_domain_name_servers are not the same as $old_domain_name_servers. Previously, this was done during each RENEW procedure.
* Replacing MTU for preconfigured one was changed to Python (via vyos.config). The previous version with vyatta-interfaces.pl was obsoleted and seems to be broken.
|
|
|
|
Commit a9eb356 ("user: add test for adding/deleting system users") added
python3-paramiko to the list of build dependencies, but its a runtime
dependency.
|
|
|
|
* 't1948-system-login' of github.com:c-po/vyos-1x:
radius: T1948: add libnss-mapname support
radius: T1948: rename server dictionary
radius: T1948: supply PAM configuration template
user: T1948: fix system user creation
ogin: user: radius: T1948: use discrete configuration for each system
login: T1948: remove obsolete config nodes "group" and "level"
login: T1948: SSH keys can only be added after user has been created
login: T1948: initial support for RADIUS configuration
login: T1948: support for SSH keys
login: T1948: add/remove local users
login: T1948: initial rewrite in XML/Python
options: T1919: remove broken comment
|
|
|
|
|
|
|
|
|
|
We have a CLI wrapper so we must also have it in our list of dependencies.
|
|
Without dbus the vyos-load-config.py will fail and nothing will work.
|
|
|
|
This is actually an "upstream" bug, see [1] but it can be fixed via our own
scripts.
[1]: https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1384122
|
|
|
|
Commit 7e00ffa ("Debian: add vyos-1x-vmware package") added a new subpackage,
but by adding this package it was forgotton to create the appropriate
vyos-1x.install file.
|
|
|
|
Split out files required only by VMware systems.
|
