This PR will be reintroduced following completion of T5500.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 23 2023
Aug 22 2023
I did start writing support for this but didn't have time to build and test it at the time. If anyone wants to test it out: https://github.com/sarthurdev/vyos-1x/commit/9199b75d75ceea3b7d49f0e3d71a19175b7b1326
There's request for fib matcher: https://vyos.dev/T5119
It would be useful if you could propose cli design for this feature in that task, so we can discuss about it and then work on adding it
Aug 21 2023
Until the other maintainers share their ideas and thoughts I would like to add some context about FreeIPA and Active Directory, as I have the impression, that the difference between FreeIPA and Active Dirctory is not completely clear.
Comparing with other vendors thats what you use the ACL for.
The short story:
I disagree with that. Cause only why bgp is running, we don't need the port to be reachable on all interfaces or for all source IP's.
Aug 20 2023
A dirty workaround would be to include a "hidden" (as in it exists in nft but not displayed in the vyos-config itself) CoPP table which includes the port(s) needed for:
It's me. I'm User! Happy to provide before (1.4-rolling-202308060317) and after (1.4-rolling-202308180646) VyOS configs and nft dumps for analysis. I can reliable reproduce/correct the issue by switching between those two images.
As seen on slack and I think on the forum.
Perhaps same workaround as firewalld is implementing through option "IPv6_rpfilter=yes" could be implemented in VyOS (both uses nft)?
Possibly the fib statement can be used through nft:
today I want test how fast firewall rules loading and changing in vyos performed. I took an vyos-1.4-rolling-202308180646-amd64.iso boot it as kvm guest.
Then I added some rules with:
Looks like the Problem still exist in 1.4. Are there any plans?
Nope, scrap the above. (Even though it would not surprise me if systemd would be able to perform such tasks in initramfs or else where.)
My guess is that a whole bunch of systemd-things are missing inside initramfs.
For example systemd-fsck-root.service has Before=local-fs.target shutdown.target & ConditionPathIsReadWrite=!/ which (to me) suggests it should be ran from inside initramfs, before your root partition is mounted.
I ran what you suggested, but it still shows wrong block/inode count right after boot.
Looks like you would need some more extensive checking of that partition.
As I understabd FreeIPA is an alternative to ActiveDirectory? And SSSD should support authentication via LDAP only if the backend is AD.
I managed to enter initramfs on the machine running in a VM by appending break to grub. From there I manually ran a fs check, which didn't show any issues.
Aug 19 2023
I have created this task regarding the fsck issues (fsck does not run during boot): https://vyos.dev/T5498
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2158
Both attached files seem to be downloadable (but now viewable in browser) from the download-link in the upper right corner after clicking a file.
Thank you for taking a look on the PR.
In PR 2152:
Adding Kerberos to a router is overkill in my opinion. I'd agree on adding LDAP(s) auth support via sssd of course, but Kerberos is simply a bit beyond the scope.
Works for me without errors but I currently only have an empty ruleset:
Aug 18 2023
I couldn't open those files, but it can be related our firewall refactor :
I confirm this warning message , although, on Linux doesn't affect or at least with our server/client work as expected :
The similar task https://vyos.dev/T4797
Pull request #2156 opened
https://github.com/vyos/vyos-1x/pull/2156
Aug 17 2023
This error not only occurs for new settings in global-options but also for older:
Priority must be less than -200 https://github.com/vyos/vyos-1x/blob/08cb4f350b335d5af401f30850d410b4be38530d/data/vyos-firewall-init.conf#L23-L32
https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation#notrack_-_Bypass_connection_tracking
chain PREROUTING { type filter hook prerouting priority -200; policy accept; counter packets 6405 bytes 444828 jump VYOS_CT_IGNORE counter packets 6405 bytes 444828 jump VYOS_CT_TIMEOUT counter packets 6405 bytes 444828 jump VYOS_CT_PREROUTING_HOOK counter packets 6405 bytes 444828 jump FW_CONNTRACK notrack }
Tested after merging T5476 and now we see a proper DHCP release message
It could be incorrect process name name='ddclient - sleeping for 10 seconds' expectedd ddclient, possible bug after commit https://github.com/vyos/vyos-1x/commit/58a20e42087cbb7a1b3b4725fa40fd15a31bb4ed
psutil.Process(pid=2282, name='sshd', started='12:29:23') psutil.Process(pid=2283, name='vbash', started='12:29:23') psutil.Process(pid=2625, name='rsyslogd', started='12:30:31') psutil.Process(pid=9841, name='vbash', started='13:02:24') psutil.Process(pid=10249, name='kworker/u2:1-events_unbound', started='13:03:58') psutil.Process(pid=10735, name='kworker/0:1-mm_percpu_wq', started='13:10:42') psutil.Process(pid=10737, name='kworker/u2:2-events_unbound', started='13:10:42') psutil.Process(pid=10987, name='ddclient - sleeping for 10 seconds', started='13:12:47')
PR for 1.3.4 https://github.com/vyos/vyos-1x/pull/2153
Thanks @Apachez - closing