Thu, Sep 28
Tue, Sep 26
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2310
Mon, Sep 25
Sat, Sep 23
Fri, Sep 22
Thu, Sep 21
Wed, Sep 20
Tue, Sep 19
Mon, Sep 18
Ok, I was thinking if that then waited for some password or such.
I haven't tried anything else since I rebooted back into 1.4, but I did try sudo su - which gave the same error.
How does a simple "sudo bash" work?
I think this broke a whole lot of things for RADIUS users (these work fine in 1.4-rolling-202308040317, but are broken in 1.5-rolling-202309170024):
Fri, Sep 15
How does FRR/vrrpd work regarding SNMP compatability?
Thu, Sep 14
PR created: https://github.com/vyos/vyos-1x/pull/2264
Should probably add "-M rpki" permanently to FRR/bgp.
Could the error from latest nightly be due to that rpki module isnt loaded for FRR/bgp?
Could https://vyos.dev/T2044 be related to the failed nightly build from last night?
Wed, Sep 13
PR for 1.3.x https://github.com/vyos/vyatta-cfg-quagga/pull/102
Tue, Sep 12
Mon, Sep 11
Sat, Sep 9
PR for 1.3.x https://github.com/vyos/vyos-1x/pull/2225
Fri, Sep 8
Thu, Sep 7
For 1.4 add session [default=ignore success=2] pam_succeed_if.so service = sudo to /etc/pam.d/common-session-noninteractive fixes the issue
# here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session required pam_permit.so # and here are more per-package modules (the "Additional" block) session required pam_mkhomedir.so umask=0022 skel=/etc/skel session [default=ignore success=2] pam_succeed_if.so service = sudo session [default=ignore success=ignore] pam_succeed_if.so user ingroup aaa quiet session [authinfo_unavail=ignore success=ok default=ignore] pam_radius_auth.so session required pam_unix.so # end of pam-auth-update config