I'm usually on #vyos:chat.freenode.net.
User Details
- User Since
- Nov 6 2018, 10:08 PM (320 w, 5 d)
Nov 16 2021
Jun 15 2021
Can you try any 1.3 rolling version before 2020-10-30 commit c8b7e5c ?
Jan 15 2021
Do I need to test the image before closing the task? I'm on a older image version and I manually applied the patch which works. Otherwise I'd need to upgrade the image which I won't have time for in the near future.
Jan 14 2021
Sep 30 2020
Sep 10 2020
Aug 6 2020
Aug 4 2020
I wasn't trying to solve any specific issue. I was working on some other project, trying to use GCC as a preprocessor, the same way as it's used here, and ran into those obstacles I listed in the original description, which are present here too. I was made aware m4 is much more suitable to template processing than GCC as it was actually designed and made for it.
As for using any self-made code to do this, I have no problem with that as long as it's well known this is what is now used, is documented, and then an effort made to port all preprocessing to it. I see no sense using two or three different preprocessors.
Jul 31 2020
Jul 30 2020
No I didn't, sorry. I'll test it and see :)
This is not enough, bridge and bond members also didn't get IPv6 link-locals in the previous implementation. To have them is incorrect and a security risk.
Jul 23 2020
This is expected as disabling an ethernet interface is different than any other interface, they're still present but just put admin down. All other interfaces get deleted and thus throw this error.
Jul 21 2020
I assume this will break 'system static-host-mapping host-name' and other places where tagnodes are used to carry string values as well
Jul 20 2020
I could file a PR if you like, already prepared it.
Jul 19 2020
Jul 17 2020
Jul 8 2020
Jul 5 2020
The most likely culprit is /opt/vyatta/sbin/vyatta_interface_rescan. I'm not sure if this should be fixed or migrated to Python.
The rewrite would need to be done together with all other vyatta interface renaming and detection scripts.
Upgrading a different test VM with different config that starts at eth0: on 2nd reboot the hw-id lines are duplicated too, but they are the same on a single interface, and there are no new interfaces created, so the config loads and works fine. The duplicated hw-id lines stay in the config for all subsequent reboots.
Example:
ethernet eth0 { address "192.0.2.1" hw-id "52:54:00:2d:29:19" ipv6 { address { } } smp-affinity "auto" speed "auto" hw-id 52:54:00:2d:29:19 }
What I'm noticing is that the migration scripts save all nodes with quotes, but saving in config mode (through vyatta-cfg) results in most nodes not having quotes (mostly just those with spaces have it). Maybe there is a vyatta script that adds any new interfaces to config.boot that runs on each boot that doesn't like these quoted hw-id lines that the migration scripts produce.
I tried reupgrading from 1.3-rolling-202006110117 to 1.3-rolling-202007050117 and the exact same error occurred - on first reboot everything was fine (config.boot was migrated, looked correct, and loaded fine). On 2nd reboot, the exact same thing happened.
Jul 4 2020
Duplicate of T2627
Jun 30 2020
Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.
This is already fixed in 1.3
Jun 27 2020
Will you be doing this change or can I claim it? I'm ready to work on it right now if you prefer.
To clarify, I'm not actually sure the formatting is the reason for the bug - I just observed that it happened. It may have no impact on functionality. The real problem is that something is messing with the hw-id entries, and I don't think it's the migrator scripts, as those weren't executed when it happened. Maybe some legacy Vyatta code.
Looking at the code, there is a missing error check for when an alias is the same as a static-host-mapping or already existing alias (either of this mapping or any other one). It will require some additional iteration.
Or maybe these should be converted to warnings and not errors, as they don't cause anything to break, just not work as expected?
I agree, we can make the error message point the user towards using an alias instead. But I don't think doing so is common practice, such things are usually written in docs.
Maybe the problem was that it exposed a configuration only understood by pdns-recursor, so replacing it with something else would be impossible if we ever considered so? That was the reason for not allowing certain patches in the past.
The reason I do it this way is to comply with the 80-column limit. Any strings separated by whitespace will be transparently concatenated by Python to one string, it requires adding extra braces around the multi-line string.
No, the string concatenation is done by Python (these are not multiple arguments but one argument) so there's nothing ConfigError can do. It's simply a mistake (typo) on my part.
Yeah, only the first line will be used, the subsequent lines for an already existing IP or hostname will be ignored. pdns-recursor also behaves the same, it logs "not replacing entry" (or something similar, I can't recall) when encountering a entry with a different IP for a hostname already defined, so it behaves the same as getent. You can't add multiple entries for round-robin resolution, hosts has no support for that, if we want that we need to use zone files instead (but those only work for pdns-recursor and not the system, so are not a suitable replacement here, they could be added under the dns forwarding node)
Have you tested that this actually works as intended? The reason I added that check is that each static-host-mapping "inet" address translates to a line in /etc/hosts. The hosts manpage says there should be only one line for each host:
Jun 26 2020
Migration scripts use vyos.configtree which uses libvyosconfig so it's probably a bug there.
Attached are config.boot post-upgrade(migration) and config.boot pre-migration.
Notice:
- doubled hw-id lines
- missing opening and closing curly braces on lines 45, 75-77 (tag nodes)
- lines 8, 33, 35 are leaf nodes, those shouldn't have opening/closing curly braces after them
- some things are quoted, some are not
Not doing anything regarding the failed load and just rebooting has now hard-baked the eth0-eth2 names into config.boot without me doing anything. So something effectively decided to rename eth1-eth3 to eth0-eth2 and save it to config.boot.
Jun 25 2020
To be fair, I'm getting frustrated by the layers-upon-layers of new abstractions getting added on old code that doesn't work properly in the first place. I'd much prefer if we just started with a clean slate. I liked @thomas-mangin 's idea of replacing vyatta-cfg completely with our own code, either vyconf or his python daemon. I wouldn't waste time patching up the old backend, just make a decision in one place to replace it completely.
I think I ran into this today after upgrading from 1.3-rolling-202006110117 to 1.3-rolling-202006241940. My config had eth1-eth3 (as those were the default names created by a previous install of 1.3 somewhere around May) and those worked fine for numerous reboots before this upgrade. The first reboot after adding the new image, everything was fine. The 2nd reboot (actually a power outage) the interfaces were eth0-eth2 on the system, but eth1-eth3 in the config, so the config load failed.
Keep in mind that the preferred way to implement scripts is, in my mind, the one used by interfaces-tunnel.py: it takes both session and effective configs and compares them, only applying the changes for the differences that are required. get_config_dict just takes the session config and so it requires a complete teardown and re-initialization of any system component that is configured from it (restarting instead of reloading services, deleting interfaces instead of modifying just 1 setting, ...)
I don't consider just get_config_dict as the preferred future way to implement features for that reason, rather it is the interfaces-tunnel that could be made the reference.
get_config_dict could be ran 2 times (once with effective=True) in each script, then the script could compare/make a diff of the 2 dicts, but that's what interfaces-tunnel ConfigurationState does.
Take for example a minor change in the current openvpn code - changing the description of the interface - currently results in a complete service outage (restart). AFAIK all scripts are like this. It didn't use to be that way in Vyatta, most perl scripts compared session and effective configs and just applied the necessary changes.
Possibly related to T2205, it might have been fixed since this was reported.
Jun 23 2020
It would be possible to make the scripts check if IPv6 is enabled on the interface (or system?) and make the minimal MTU 1280 in that case. If IPv6 on the interface is disabled or not supported, have it go as low as it can.
This was discussed already in T2404. The problem is that NICs that expose their min/max MTU are rare. None of the NICs I have expose it, neither through sysfs nor through 'ip -d link show'. If I recap the discussion from T2404, there are 2 main ways to solve this:
a) not have any limitations regarding MTU at all and then detect an error when trying to apply the new MTU. This means no way to verify if the new mtu is correct beforehand so it doesn't comply with the verify/apply separation that's prescribed in the developer docs. I described a possible workaround using revert code in T2404.
b) have a mtu detection script that would be ran by udev on every new NIC detection (to support hotplugging NICs) that would determine the min/max mtu with a bruteforce binary search algorythm (try to set a mtu and see if it errors), then record the results in some temporary file that would get read by the config script. The idea was proposed by @thomas-mangin.
Jun 22 2020
This would have been fixed for isc-dhcp-client if T2590 hadn't happened in the process of me working on it, now it requires writing a new dhclient script for the WIDE client.
Fixed as part of T2486
Fixed as part of T2486
The above PR419 did not fix the issue as a wrong pdns-recursor process name was used (its real name is 'pdns-rec/worker'). It was fixed as part of T2486.
That's great, I like the config syntax. What does the interface alias do regarding the display? Maybe it could be read from the interface description? Then again the display name needs to be short as the displays are small and the interface description can be longer. Maybe default to reading the alias from the interface description and override it with the display alias.
For starting services in 1.3 we use systemd, it's simple to create new service files in src/systemd that will be put in /lib/systemd/system. Just make sure they're started manually by the config script and not as part of a target (just creating a service file without the Install section should ensure that).
Jun 19 2020
Fair point. In that case I agree with not including a raw config option.
As for the errors when installing vyos-1x, c-po already pointed out why this occurs.For this reason I don't rebase on upstream while working on a set of changes locally, I always try to keep the installed iso and local git state as much together as possible. I also run docker from the vyos-build repo and have the vyos-1x repo dir in vyos-build/packages/vyos-1x (where the included scripts/build-packages would put it) so I can just docker run and build without having to copy any files anywhere, just scp the built deb into the VM.
@c-po I tend to agree to have as much predefined templates, but I'd leave the option to have a custom config if the user wants to, I don't like imposing artificial limitations. We already allow custom options with dhcp-server, openvpn..., why not allow specifying your own conf file for the driver section to include? Some things are impossible without either this or going with approach 2 by exposing absolutely all configurable driver options through the config. I'd prefer that, but if it results in too much options/config size, the alternative is as I described. But in the long term I think approach 2 would be the best.
Jun 18 2020
I'd go with approach 3, if 2 is too complex. Have a predefined set of appliances that can be configured by a single option. For all other scenarios, one of:
a) have the user supply the path to a file in /config that the script will include in lcdd.conf as-is (as including a multi-line string in the config directly is very awkward and unreadable).
b ) we could for example make a /config/lcdproc directory, containing a template conf file that would be used if the user selected that option in config, still starting the daemon via the config.
c) or split out the individual driver sections with defaults (as in lcdd.conf) into many files in /config/lcdproc/$drivername.conf that can be edited by the user, and have a config option that selects which driver to use, and have the user edit the file to configure it.
Jun 17 2020
There is another use of is_tag/is_leaf in python/vyos/validate.py is_member, as it can work on both bridge and bond members, and they have different syntax for member interfaces. It would only be possible to hardcode each case and remove the use of is_*
Jun 14 2020
This is the users dmesg with failed firmware load
[ 21.951100] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 21.951932] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-6.ucode failed with error -2 [ 21.951961] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-5.ucode failed with error -2 [ 21.951982] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-4.ucode failed with error -2 [ 21.951985] iwlwifi 0000:03:00.0: no suitable firmware found! [ 21.958303] iwlwifi 0000:03:00.0: minimum version required: iwlwifi-6000-4 [ 21.967817] iwlwifi 0000:03:00.0: maximum version supported: iwlwifi-6000-6 [ 21.975992] iwlwifi 0000:03:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
I suggested to install the firmware-iwlwifi package from the debian repos as part of the debugging process. Of course this isn't a supported way for end users, this is known for a long time, and you must take care to not run apt-get upgrade, dist-upgrade or install a package that conflicts or overrides a vyos package. It is safe to install packages that don't conflict.
Non-free firmware was added by default in crux: T15
Jun 12 2020
I have no need for PD for now, so this isn't an important issue for me. I just noticed that WIDE didn't run any scripts, so right now it can't set any nameservers obtained from DHCP. If anyone needs that, I guess it would be simplest to write a script (by using the existing dhclient-script hooks as a guide) just for vyos-hostsd, since PD is already done with WIDE. Switching to ISC would mean we'd need to improve that PD script I linked to, since it only supports a single interface, and we need multiple.
@jack9603301 you're not the one that made the choice so you can't know why it was made.
ISC-DHCP can do prefix delegation too (not by itself, but with a helper script that others already made: https://wiki.debian.org/IPv6PrefixDelegation ) so that's not why WIDE was chosen.
What was the reason for choosing WIDE dhcp6c and not keeping isc-dhcp? This has now caused T2590 which will require making a new set of dhclient scripts just for WIDE, so we'll be maintaining 2 separate scripts. If it was due to the support for prefix length hint, isc-dhcp has added that too, as I mentioned in this task before https://phabricator.vyos.net/T421#49842
Jun 11 2020
Jun 10 2020
+1 for this, it would be very useful for a lot of use cases, we wouldn't need to add everything to vyos-1x and the config syntax, but users could add "missing" services on their own. For example T2195