exactly , i'll give an example of what is the improving (or new cli) , we have a policy where we can mach different DSCPs associate with REAL TIME or VIOCE . Current in our cli , it would be something like this :
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Oct 24 2023
Using VyOS 1.5-rolling-202310220123.
Checked in VyOS 1.4-rolling-202310030309
LEFT router configuration
So, do you want to add a new syntax to archive the same behavior that we have for qos policy ?
The global state-policy was dropped from CLI.
Close it for now.
Oct 23 2023
this case was resolved lasted configuration done .
this task is a re-definition from a traffic class , I think it could be more clear if we separate tc-filter in a class-map , so we can define different profiles in our cli based on services :
1.5 should not have such issues.
1.4: op-mode should be working as expected. Backport for https://github.com/vyos/vyos-1x/pull/2344 failed. I'll submit PR for 1.4 for such feature.
Oct 22 2023
In T5673#162681, @Apachez wrote:Should debug code really be part of production releases?
Wouldnt it be sufficient that you can enable this on your own if you want a debug build being made?
Should debug code really be part of production releases?
Oct 21 2023
@rayzilt Could you re-check and close it if solved?
@Apachez I suppose it is.
- biosdevname is called by scripts in the initrd, so we can't remove it just yet.
- it's not completely abandoned and had quite a few releases since the point when Vyatta forked it.
- I sent a PR to allow biosdevname to run in VMs (that's the only thing that vyatta-biosdevname has and that's used in scripts): https://github.com/dell/biosdevname/pull/12
I could not find any uses of "slave" in current VyOS versions. If anyone finds any, feel free to start a discussion. VRRP "master" terminology cannot be changed because it's a part of the protocol spec itself, and, as said above, its counterpart is "backup".
The new-style op mode is well-established now, it's time to close the task.
The problem was resolved in the forum. Whether the underlying cause in FRR was resolves is another question...
Oct 20 2023
PR for Saggita: https://github.com/vyos/vyos-1x/pull/2388
PR for 1.5 https://github.com/vyos/vyos-1x/pull/2386
Oct 19 2023
PR for 1.4 https://github.com/vyos/vyos-1x/pull/2383
PR for 1.5 current https://github.com/vyos/vyos-1x/pull/2378
File gets generated but could be not extracted nor transferred as it tries to resolve it as hostname
Interestingly enough, I just found this error as well, but showed lines 173, 130, and 66.
Oct 18 2023
This has been verified to be a driver issue as the Intel's out-of-tree module for ixgbe does indeed work when I compilied my own version of the ISO with the Intel's out-of-tree-module installed.
Implementation; this may be slightly revised before PR, to provide extra data ...
https://github.com/vyos/vyos-1x/compare/current...jestabro:commit-schedule
vyos logs
Oct 18 14:16:41 sshd[24197]: pam_succeed_if(sshd:auth): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 sshd[24197]: pam_succeed_if(sshd:account): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 sshd[24197]: Accepted password for olofl from 10.6.10.89 port 47110 ssh2 Oct 18 14:16:41 sshd[24197]: pam_succeed_if(sshd:session): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 sshd[24197]: pam_unix(sshd:session): session opened for user olofl(uid=1001) by (uid=0) Oct 18 14:16:41 systemd[1]: Created slice user-1001.slice - User Slice of UID 1001. Oct 18 14:16:41 systemd[1]: Starting [email protected] - User Runtime Directory /run/user/1001... Oct 18 14:16:41 systemd-logind[1259]: New session 129 of user olofl. Oct 18 14:16:41 systemd[1]: Finished [email protected] - User Runtime Directory /run/user/1001. Oct 18 14:16:41 systemd[1]: Starting [email protected] - User Manager for UID 1001... Oct 18 14:16:41 (systemd)[24203]: pam_succeed_if(systemd-user:account): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 (systemd)[24203]: pam_succeed_if(systemd-user:session): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 (systemd)[24203]: pam_unix(systemd-user:session): session opened for user olofl(uid=1001) by (uid=0) Oct 18 14:16:41 rsyslogd[11051]: message repeated 69 times: [-- MARK --] Oct 18 14:16:41 rsyslogd[11051]: child process (pid 24200) exited with status 1 [v8.2302.0] Oct 18 14:16:41 systemd[24203]: Queued start job for default target default.target. Oct 18 14:16:41 systemd[24203]: Reached target paths.target - Paths. Oct 18 14:16:41 systemd[24203]: Reached target sockets.target - Sockets. Oct 18 14:16:41 systemd[24203]: Reached target timers.target - Timers. Oct 18 14:16:41 systemd[24203]: Reached target basic.target - Basic System. Oct 18 14:16:41 systemd[24203]: Reached target default.target - Main User Target. Oct 18 14:16:41 systemd[24203]: Startup finished in 64ms. Oct 18 14:16:41 systemd[1]: Started [email protected] - User Manager for UID 1001. Oct 18 14:16:41 systemd[1]: Started session-129.scope - Session 129 of User olofl. Oct 18 14:16:41 systemd[1]: opt-vyatta-config-tmp-new_config_24226.mount: Deactivated successfully. Oct 18 14:16:41 sshd[24197]: pam_env(sshd:session): deprecated reading of user environment enabled
testing another radius user
Oct 18 14:19:32 sshd[24610]: pam_succeed_if(sshd:auth): requirement "service = sudo" not met by user "oxidized" Oct 18 14:19:32 sshd[24610]: pam_succeed_if(sshd:account): requirement "service = sudo" not met by user "oxidized" Oct 18 14:19:32 sshd[24610]: Accepted password for oxidized from 10.6.10.89 port 58054 ssh2 Oct 18 14:19:32 sshd[24610]: pam_succeed_if(sshd:session): requirement "service = sudo" not met by user "oxidized" Oct 18 14:19:32 sshd[24610]: pam_unix(sshd:session): session opened for user oxidized(uid=1001) by (uid=0) Oct 18 14:19:32 systemd-logind[1259]: New session 132 of user olofl. Oct 18 14:19:32 systemd[1]: Started session-132.scope - Session 132 of User olofl. Oct 18 14:19:32 systemd[1]: opt-vyatta-config-tmp-new_config_24614.mount: Deactivated successfully. Oct 18 14:19:32 sshd[24610]: pam_env(sshd:session): deprecated reading of user environment enabled
What if you install the same version again but as a new boot name?
My radius user was not called admin, but local user called admin was configured before I tried.
I removed local admin user, and tried once again, and I get the same reults.