@krassle backported to crux branch

waiting for a decision on T2485 before doing this work

https://github.com/vyos/vyos-1x/pull/418

I have worked and provided a patch for T2485 .. It may be the right place to move it in.

https://docs.google.com/document/d/1pKkxwq5eBm9eSTmyrSluDU1cx8NYqQRkQNdTB1tCSdk/edit?usp=sharing

No worries. I think I've got a simple fix for this. Just needed to step away for a bit

I think this should be fixed by the one that broke this, or no? I don't have the time to do any real work right now. Maybe in a week or 2.

Every call to /bin/cli-shell-api --show-working-only --show-show-defaults --show-ignore-edit showConfig takes multiples seconds (6?)
/usr/libexec/vyos/conf_mode/system-timezone.py call it twice.
/usr/libexec/vyos/conf_mode/nat.py call it twice
/usr/libexec/vyos/conf_mode/interfaces-loopback.py call it twice ... etc.

Not really, the change to nobody:nogroup was by c-po in https://github.com/vyos/vyos-1x/commit/f371946044696737d1649d9119665b96430d2328
The commit by me you referenced just fixed a bug that resulted from that change.

Fixed in https://github.com/vyos/vyos-1x/commit/bc06027 - task id missed in commit

This is related to this change:

For get_bridge_member_config, ifname_from_config and maceui64 to be able
to be moved into ifconfig.interfaces T2366 needs to be done first,
otherwise functionality will break.

Note: When we migrate NAT to nftables, we need to use nftables sets instead of ipset

in full agreement

Definitely, I'm not saying NPT should be removed, just discouraged in favour of using routed public prefixes where available. If the user chooses tho use NPT, the option should definitely still be there.

In T421#64197, @jjakob wrote:

That's a case where having the ability to assign addreses from the received prefix via DHCPv6 on the internal interface would allow internal hosts to get managed addresses from the prefix automatically without the use of NPT or SLAAC. But that isn't implemented yet AFAIK.

That's a case where having the ability to assign addreses from the received prefix via DHCPv6 on the internal interface would allow internal hosts to get managed addresses from the prefix automatically without the use of NPT or SLAAC. But that isn't implemented yet AFAIK.

Please see attached the full log of the boot process. I try to supply a PNG later on but I guess it will be really huge.

Even if dhcpv6-pd is now supported, nptv6 may still be needed, and as a user's choice, the application user may need to use the ula address. In particular, if you do not use ula addresses, in some environments, users may not be able to obtain fixed address prefixes, and when users need internal IPv6 address prefixes that can only be assigned by themselves, NPT may be necessary.Like myself.

I agree. NPTv6 was acceptable as a stopgap measure as VyOS didn't support DHCPv6-PD. Now that we have that (even though it's still young and needs testing), NPTv6 should be actively discouraged in the docs except for unavoidable cases, e.g. where the ISP wants to only give the client a single /64 but the client wants multiple L2 segments with IPv6, each needing its own /64 segment - unless there is a better alternative way to solve that I don't know of, other than demanding a /56 from the ISP or switching ISPs.

We definitely shouldn't be setting permissions on the socket to 777 or 666 - whoever has write access to it can modify the DNS configuration (pdns-recursor) and can thus inject malicious DNS records or add himself as a DNS forwarder and do MITM attacks.

Hehe... naming is difficult, I have that problem too :)

0-18 kernel boot
18-41 system starting inc FRR
70-120 the python most of the time is spend/wasted in cli-shell-api - so I would think reading the configuration file. If we can optimise / reduce this number of calls it would be very good.
140-220 is more or less firewall setup with vyatta-firewall / vyatta-upset.pl / ip6tables

PR416 should be the real fix here and PR413 should be reverted.

I need to double-check (and may not get to it) but if you use a vyos-build to build current and then try to build crux, make iso is not happy. I am now building crux using the command in my post above, the only difference: clean vyos-build install before the git checkout crux.

Yep. Confirmed, and that's the root issue here.

I tested the PR mentioned above and don't believe this will work. Reason is, is that https://github.com/vyos/vyos-1x/blob/current/src/systemd/isc-dhcp-server.service runs dhcpd as user: nobody and nobody is not in the sudo group, as far as i can tell. This is the error message im seeing.

May 19 21:37:45 vyos sudo[6141]:   nobody : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/vyos-hostsd-client

Based on a bond interface

This PR should hopefully correct this.

Now the protocol is not stable.
Simple XML for the future
https://github.com/sever-sever/vyos-1x/blob/eigrp-conf-mode/interface-definitions/protocols-eigrp.xml.in

In T2474#64078, @c-po wrote:

@fetzerms thanks for getting back to us - I also successfully tested it.

I guess there is always room for improvement in the documentation. Maybe you want to contribute a fix for the missleading parts?

OPNSense does maintain a version of wide-dhcpv6-client, but as far as I know, neither Debian or any other linux distribution use this repository as their upstream repository.

@fetzerms thanks for getting back to us - I also successfully tested it.

I was able to build 1.2.5 iso (but there is no git tag for it?) with the docker container. I just misunderstood the documentation and thought that the vyos-build-repo is only the repo for the docker image. But it seems the docker image is just from the docker file and the repository needs to be cloned anyways.

No one to follow up? I know this problem may be strange, but it does happen to me!

@runar, thanks for clarification! I will change the initial description accordingly.

@MrLenin What makes you say that dhclient is better maintained? The OPNSense people are actively maintaining the project... but that said, I also do not have any preference. It needs to work, and I guess that's the most important part :) The only thing I see missing in dhclient is that you cannot control the IAID etc (or maybe you can and I didn't see it).

Yes it is, we auto publish it if there is a change.

Here is an expanded concept covering a few more areas of the config. It's not as pretty as I'd like, but doing it this way allows for an early translation pass and the result would be a config more or less with everything how it would be if it had been hand entered in VyOS as-is. Tying things to the sla-id also makes consistency checking simpler, can't add a prefix-sla-id block unless a delegation defining it exists, and can't delete the delegation until nothing references its sla-id any longer. I feel this can probably be improved upon, suggestions and criticisms welcome.

I don't have much preference configuration-wise between the isc and wide clients, but wide-dhcp6-client is not actively developed and is less rfc compliant than dhclient. Not deal breakers for my needs, but the existing vyos scripts already assumed dhclient so I figured it would be a little less work to get things properly integrated once I learned my way around the scripts and even if my changes were not adopted, it would have at least made it easier to keep things synced as time went on.

The dockerhub image is just an environment capable of generating the vyos image, it does not include any of the files needed to generate the image itself. These files are inside the vyos-build repository.

ediing vyos make iso -r crux -d
https://github.com/thomas-mangin/vyos-hacker-toolkit

To clarify the hw-id tag. This is the only way VyOS scripts know what interface to give what name on bootup, as the boot-order of nics could be different on every reboot (potentially) vyos needs a way to identify the "correct" order of the nics when it boots. if you remove the hw-id tag from the interface the configuration script don't know what interface to give the configuration to, so you could potentially get nic-reordering on every single reboot.

In T421#63999, @Azayaka wrote:

In T421#63962, @jack9603301 wrote:

@c-po What did you want? Configuration of DHCPv6 PD in vyos?? Didn't you update the document? How do you configure it?? I don't quite understand!

Please...This is just embarrassing. This comment might be off-topic, but it looks like our fellow Chinese user @jack9603301 need suggestions on how to use English in a proper manner. (Your current wording style can easily offend people.)
Here are my wording suggestions.

• Avoid double or tripple question marks.
• Avoid rhetorical questions.
• Use "Sorry", "Please", "Could you...", etc. for questions and requests.
• Avoid representing others if you are not entitled. For example, when *you* want some features, do not say "VyOS fans in China" want those features.

I can translated my points to Chinese if it can be better understood.

雖然你可能沒有意識到，但是你的英語行文很不禮貌，容易冒犯他人。以下是我的幾點建議：

• 避免使用多個問號。
• 避免反問他人。在中文語境下，反問也可以被認為是想吵架。
• 多用 "Sorry", "Please", "Could you..." 這種緩和語氣、表示禮貌的詞彙，特別是在提問或請求他人的時候。
• 不要輕易“代表”他人。

In T2474#63995, @jestabro wrote:

You want to fetch the repo before building; cf. the 'Generating the container section':

git clone -b crux --single-branch https://github.com/vyos/vyos-build

@MrLenin Your approach is interesting. I also prefer using wide-dhcpv6-client because it has better control over the id's and allows cleaner configuration (my opinion).

Last time I generate crux I used the docker current to do it ...
(but I could not this time...)

@jestabro I installed new rolling images today and will verify tomorrow.