- User Since
- Sep 10 2018, 3:30 PM (162 w, 6 d)
Tue, Sep 28
The issue solved in the https://github.com/vyos/vyos-1x/pull/1017
However, the question if netplug script is necessary at all is still opened.
Mon, Sep 27
Sep 15 2021
Aug 27 2021
This is a typo in the documentation. In the real system, the facility is called security, but it is deprecated at least from the 2004 year.
The problem that I see in names is that it seems that different systems and software may use slightly different names for facilities. So, could be a good idea to do the two things:
- check existing and add missing facility names in CLI
- in the actual configuration transparently convert facilities to numeric representation to avoid software issues (like deprecated security facility in rsyslog).
Aug 24 2021
Aug 16 2021
Thank you for testing! The change was backported to 1.3 and 1.2.
Aug 11 2021
Really appreciated for such a detailed problem analysis! The regex is fixed in the 1.4 version now.
Could you test it, so we can backport changes safely to 1.2 and 1.3?
Jul 29 2021
They should be disabled by default, but there must be the ability to re-enable OIDs back from CLI.
Jul 26 2021
Jun 29 2021
Jun 11 2021
It also works with the current VTI interfaces (sudo ip l set vti1 vrf VRF1).
May 28 2021
@UnicronNL I would like to put default values in the config.boot file, and overwrite them from Cloud-init if a customer provides custom values.
Apr 28 2021
Apr 22 2021
Apr 13 2021
The issue exists because the ifupdown package that is required for the eni renderer was removed by the https://github.com/vyos/vyatta-cfg-system/commit/3dd837f2d3518b7ddcf8e1ab68d8ab9f3eff0968
To not take back it again for all the platforms, the problem was resolved by the https://github.com/vyos/vyos-vm-images/commit/090e5367dc6df9b49c037e0b60f7adfafdf54a53 , so all the images created with the vyos-vm-images should not contain the problem with the renderer.
This task must be obsoleted by the https://phabricator.vyos.net/T2116
Just a small update on this.
PXE boot service for all 1.2 / 1.3 / 1.4 versions is up and running in private testing.
Mar 23 2021
Mar 22 2021
The root of the problem here is changed place for custom options and the ability to configure options that should be applied differently, depending on the place. In other words, "Additional OpenVPN options" becomes "Additional OpenVPN options. You must use the syntax of openvpn.conf in this text-field", but actually these variants are not fully equal and cannot be converted directly.
Mar 15 2021
Mar 11 2021
Still does not work in 1.4-rolling-202102060218
Moving tunnels between bridges works well in:
Both UEFI and MBR boot modes are supported currently.
As a replacement for keys from Microsoft, it is possible to use our keys and ask users to install CA into a MOK database.
Most likely this should be done (after firewall rewrite) as jump statements.
Kernel related part is located here: https://github.com/vyos/vyos-build/tree/current/packages/linux-kernel
The rest is here: https://docs.vyos.io/en/latest/contributing/build-vyos.html
The idea stays actual, but unfortunately, it needs now to be rewritten according to the new config implementation.
Feb 19 2021
I would like to solve this in the next way. I will:
- Add verification to our config module to avoid impossible configurations.
- Add IPv6 gateway processing (how could I miss this? Cannot imagine...).
I saw multiple times configs with a firewall section that contains about a thousand lines, so I do not think that DNS records are something size-critical that deserves additional config files.
I believe that keeping config parts outside the config.boot is a bad idea in general that against our main benefit - single config for everything.
Feb 18 2021
Can you share details about your hypervisor and datasource? Also as the full Cloud-init log (/var/log/cloud-init.log)?
Either datasource generates a wrong config, either the format is not well described in the Cloud-init documentation - there noted that: "gateway: IPv4 address of the default gateway for this subnet". I more believe in the wrong documentation, but would be better to check.
Independently of this all, the situation is not good, because we need to verify values that put into config. So, this will be fixed in one or another way (proper adding or drop), when we figure out details.
Feb 15 2021
Feb 13 2021
I am suggesting switching to https://github.com/vyos/vyos-vm-images for everything, except ISO images. This will solve the problem automatically. It is already able to create images for QEMU, VMware, Hyper-V, GCE, AWS, OpenStack, Oracle, Packet, and more not mentioned in the https://github.com/vyos/vyos-build. The only what I have not tried yet is Azure.
Setting Ethernet interfaces addresses, routes, and name servers are supported in both versions now. Advanced features like bonding, bridges, VLANs could be added later on-demand.
This was resolved via dhclient hooks - there is a protection mechanism now, which allows deleting only routes with tag 210 that set by hooks to all DHCP routes.
The config module without this problem is available in the crux, should be released in the 1.2.7 version.
The config module backported to the crux, should be available with 1.2.7 release.
Backported to the crux branch, should be released with 1.2.7.
Feb 10 2021
Jan 29 2021
Dec 25 2020
After the testing with a standalone User-Data handler, this feature was ported to the main cloud-init package in https://github.com/vyos/vyos-cloud-init/pull/27.
Currently, supported only set and delete commands processing. They must be provided as a list in the vyos_config_commands option.