Age | Commit message (Collapse) | Author |
|
The PCEngines APU2 systems with mSATA disks tend to be very slow. This results
in a service startup error:
$ systemctl status vyos-grub-update
× vyos-grub-update.service - Update GRUB loader configuration structure
Loaded: loaded (/lib/systemd/system/vyos-grub-update.service; enabled; preset: enabled)
Active: failed (Result: timeout) since Sun 2024-03-24 08:48:10 UTC; 14min ago
Main PID: 779 (code=killed, signal=TERM)
CPU: 869ms
Mar 24 08:48:05 LR4.wue3 systemd[1]: Starting vyos-grub-update.service - Update GRUB loader configuration structure...
Mar 24 08:48:10 LR4.wue3 systemd[1]: vyos-grub-update.service: start operation timed out. Terminating.
Mar 24 08:48:10 LR4.wue3 systemd[1]: vyos-grub-update.service: Main process exited, code=killed, status=15/TERM
Mar 24 08:48:10 LR4.wue3 systemd[1]: vyos-grub-update.service: Failed with result 'timeout'.
Mar 24 08:48:10 LR4.wue3 systemd[1]: Failed to start vyos-grub-update.service - Update GRUB loader configuration structure.
Measunring on an APU2 system after boot and memory is "hot", it still needs
almost 17 seconds to complete the job
cpo@LR4.wue3:~$ time sudo /usr/libexec/vyos/system/grub_update.py
real 0m16.803s
user 0m0.018s
sys 0m0.028s
|
|
|
|
This commit adds the whole set of system image tools written from the scratch in
Python that allows performing all the operations on images:
* check information
* perform installation and deletion
* versions management
Also, it contains a new service that will update the GRUB menu and keep tracking
its version in the future.
WARNING: The commit contains non-reversible changes. Because of boot menu
changes, it will not be possible to manage images from older VyOS versions after
an update.
|
|
T5261: Add AWS load-balancing tunnel handler
|
|
|
|
Render isc-dhcp-server systemd unit from configuration
|
|
Add AWS load-balancing tunnel handler
https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-integrate-linux-instances-with-aws-gateway-load-balancer/
set service aws glb script on-create '/config/scripts/tmp.sh'
set service aws glb script on-destroy '/config/scripts/tmp.sh'
set service aws glb status format 'simple'
set service aws glb status port '8282'
set service aws glb threads tunnel '4'
set service aws glb threads tunnel-affinity '1-2'
set service aws glb threads udp '4'
set service aws glb threads udp-affinity '0-3'
|
|
Otherwise packet can be received in a VRF that was already deleted.
Image of the following CLI commands:
del interface ethernet eth0 address dhcp
del interface ethernet eth0 vrf red
del vrf name red
VRF could be deleted even if dhclient release was not yet completely
processed.
|
|
|
|
vyos@vyos# run show vrf MGMT processes
2282 sshd
There is no dhclient process running in given VRF. dhclient complains it can
not send out packets via the given interface (as it's not bound to that VRF)
Aug 02 20:29:54 dhclient[1686]: send_packet: Network is unreachable
Aug 02 20:29:54 dhclient[1686]: send_packet: please consult README file regarding broadcast address.
Aug 02 20:29:54 dhclient[1686]: dhclient.c:3001: Failed to send 300 byte long packet over fallback interface.
|
|
|
|
When booting a system with DHCP clients running inside a VRF we require multiple
restarts - prevent systemd from putting the service into a "failed" state.
|
|
When no-release is specified, dhcp6c client will not release allocated address or prefix on client exit.
vyos.ifconfig: dhcpv6: T5387: re-use options_file for no release flag [WIP]
* Todo: render Jinja2 template and fill it
vyos.ifconfig: dhcpv6: T5387: finish options_file and no release flag in cli
vyos.ifconfig: dhcpv6: T5387: fix missing/wrong end tag
vyos.ifconfig: dhcpv6: T5387: fix options, no var for -n
dhcpv6-client: T5387: fix missing / from filepaths
|
|
|
|
|
|
cloud-init: T5190: Added Cloud-init pre-configurator
|
|
Add 'vyos-wan-load-balance.service' systemd unit for
'loadbalancing wan' instead of old vyatta-wanloadbalance.init script
|
|
Added a new service that starts before Cloud-init, waits for all network
interfaces initialization, and if requested by config, checks which interfaces
can get configuration via DHCP server and creates a corresponding Cloud-init
network configuration.
This protects from two situations:
* when Cloud-init tries to get meta-data via eth0 (default and fallback variant
for any data source which depends on network), but the real network is connected
to another interface
* when Cloud-init starts simultaneously with udev and initializes the first
interface to get meta-data before it is renamed to eth0 by udev
|
|
|
|
`fqdn` node
|
|
Ability to autocheck available new images
Parse remote URL JSON image-version.json file and compare version
VyOS with a local current version, if find diff sent wall
message that the new image is available
Also, add op-mode command to check images "show system image"
With option "auto-check" check will be once per 12 hours
set system update-check auto-check
set system update-check url 'http://example.com/image-version.json'
If new version is available shows it per login (MOTD)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Commit 19789463 ("dhclient: T2393: introduce 20 seconds stop timeout - required
for smoketesting on Qemu") assigned a string to a boolean field. This has been
fixed.
|
|
smoketesting on Qemu
|
|
firewall: T970: Add firewall group domain-group
|
|
* Removed dynamic generating for systemd unit
* Optimized configuration file deleting process
* Added exceptions handlers to event-handler script to protect service
from most obvious potential troubles
* Improved logging
* Moved pattern compilation outside a messages loop to avoid extra operations
* Added signal handlers for proper systemd integration
|
|
Domain group allows to filter addresses by domain main
Resolved addresses as elements are stored to named "nft set"
that used in the nftables rules
Also added a dynamic "resolver" systemd daemon
vyos-domain-group-resolve.service which starts python script
for the domain-group addresses resolving by timeout 300 sec
set firewall group domain-group DOMAINS address 'example.com'
set firewall group domain-group DOMAINS address 'example.org'
set firewall name FOO rule 10 action 'drop'
set firewall name FOO rule 10 source group domain-group 'DOMAINS'
set interfaces ethernet eth0 firewall local name 'FOO'
nft list table ip filter
table ip filter {
set DOMAINS {
type ipv4_addr
flags interval
elements = { 192.0.2.1, 192.0.2.85,
203.0.113.55, 203.0.113.58 }
}
chain NAME_FOO {
ip saddr @DOMAINS counter packets 0 bytes 0 drop comment "FOO-10"
counter packets 0 bytes 0 return comment "FOO default-action accept"
}
}
|
|
upnpd: T3420: Support UPNP protocol
|
|
|
|
In case if a CLI configuration is not available, dhclient cannot add
nameservers to a `resolv.conf` file, because `vyos-hostsd` requires that
an interface be listed in the `set system name-server` option.
This commit introduces two changes:
* `vyos-hostsd` service will not be started before Cloud-Init fetch all
remote data. This is required because all meta-data should be available
for Cloud-Init before any of VyOS-related services start since it is
used for configuration generation.
* the `vyos-hostsd-client` in the `dhclient-script` will be used only if
the `vyos-hostsd` is running. In other words - if VyOS services already
started, dhclient changes `resolv.conf` using `vyos-hostsd`; in other
cases - does this directly.
These changes should protect us from problems with DHCP during system
boot if DHCP is required by third-party utils.
|
|
|
|
|
|
tftp: T4012: Add TFTP VRF support
|
|
|
|
|
|
|
|
This reverts commit 6b48900358ce9b01eaa78e3a086e95a26064f0df.
|
|
|
|
|
|
|
|
Debian Bullseye ships an upstream version of lcdproc.service which infact will
start LCDd instead of the lcdproc client.
Divert the Debian Upstream service file and use the ones provided by vyos-1x.
|
|
This reverts commit a4bb1b77ff415700e00df3768915fdc176f779d1.
|
|
|
|
|
|
Replace the Flask micro-framework with FastAPI, in order to support
extensions to the API and OpenAPI 3.* generation. This change will
remain backwards compatible with previous versions. Notably, the
multipart forms version of requests remain supported; in addition
application/json requests are now natively supported.
|