VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=1.4.0-epa3 2024-03-28T11:44:19+00:00 2024-03-28T11:44:19+00:00 Christian Breunig christian@breunig.cc 2024-03-28T06:36:22+00:00 urn:sha1:e37f58be928b5f86f1c599ab4386747bf45e900e The current op-mode script simply calls sudo systemctl restart "dhclient@$4.service" with no additional information about a client interface at all. This results in useless dhclient processes root 47812 4.7 0.0 5848 3584 ? Ss 00:30 0:00 /sbin/dhclient -4 -d root 48121 0.0 0.0 4188 3072 ? S 00:30 0:00 \_ /bin/sh /sbin/dhclient-script root 48148 50.0 0.2 18776 11264 ? R 00:30 0:00 \_ python3 - Which also assign client leases to all local interfaces, if we receive one valid DHCPOFFER vyos@vyos:~$ show interfaces Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down Interface IP Address MAC VRF MTU S/L Description ----------- ----------------- ----------------- ------- ----- ----- ------------- eth0 - 00:50:56:bf:c5:6d default 1500 u/u eth0.10 172.16.33.102/24 00:50:56:bf:c5:6d default 1500 u/u eth1 172.16.33.131/24 00:50:56:b3:38:c5 default 1500 u/u 172.16.33.102/24 and 172.16.33.131/24 are stray DHCP addresses. This commit moved the renew command to the DHCP op-mode script to properly validate if the interface we request a renew for, has actually a dhcp address configured. In additional this exposes the renew feature to the API. (cherry picked from commit 7dbaa25a199a781aaa9f269741547e576410cb11) 2024-03-24T13:38:31+00:00 Christian Breunig christian@breunig.cc 2024-03-24T09:07:01+00:00 urn:sha1:875ac6980b1d99f7ba00fca082ea393ec7de61c8 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 (cherry picked from commit 5a12645cb25fb23f2195db1e2e977a69d0788d01) 2023-12-17T02:37:10+00:00 zsdc taras@vyos.io 2023-01-19T18:18:42+00:00 urn:sha1:c1d02ab5a2594d945e3f7aed18a1c18f296d65e2 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. (cherry picked from commit 8f94262e8fa2477700c50303ea6e2c6ddad72adb) 2023-09-11T12:14:47+00:00 Christian Breunig christian@breunig.cc 2023-09-11T12:14:24+00:00 urn:sha1:d2e7eafe84c1739fc5252c0f841e97a604ceefea (cherry picked from commit af398c51f7d06cdf582b347a35b1e5c867aaea58) 2023-09-05T19:09:54+00:00 Viacheslav Hletenko v.gletenko@vyos.io 2023-09-05T19:09:54+00:00 urn:sha1:24d65014bbdb2de0bde5ca9e5664baa9f7ac7121 Render isc-dhcp-server systemd unit from configuration 2023-08-07T21:05:12+00:00 Christian Breunig christian@breunig.cc 2023-08-07T20:53:49+00:00 urn:sha1:9afcea251bdc895ffd49cb11f455fd636fdf817b 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. 2023-08-05T07:28:35+00:00 Christian Breunig christian@breunig.cc 2023-08-05T07:02:59+00:00 urn:sha1:8a15595e1ac3d9e3e15f40f8b2256768f8d71f0c 2023-08-04T18:13:29+00:00 Christian Breunig christian@breunig.cc 2023-08-04T18:13:29+00:00 urn:sha1:782e400d6f276a8a4ee51c92f02e01e7695f55fb 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. 2023-08-02T20:05:58+00:00 Christian Breunig christian@breunig.cc 2023-08-02T20:05:58+00:00 urn:sha1:1dba4d088eba86854d8db8536eba36a5830e62c4 2023-08-02T20:03:49+00:00 Christian Breunig christian@breunig.cc 2023-08-02T20:03:07+00:00 urn:sha1:6a100233536f357ab3d45e55b9c0ecb52bd69c47 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.