- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Jul 28 2026
Jul 27 2026
The real cause is in the PKI/ACME pipeline. When an ACME cert is issued, pki.py imports the intermediate as pki ca AUTOCHAIN_<cert> and triggers dependent services (HAProxy included) to regenerate within the same commit. But that regeneration reuses an in-memory config object whose cache was already populated before the import happened, so it never sees the new CA. HAProxy's chain logic then has nothing to find.
On Stream 2026.03 (runned virtualized in Proxmox, the virtual drive is configured with discard and ssd in VM-guest settings i Proxmox and the host drive is using ZFS) it do seem to be working when running with sudo but not without sudo:
Bug reproduced on image 2026.07.21-1151-rolling and proposed patch tested.
Forgot to mention that lacking proper FS trimming has a very negative impact when running VyOS virtualised and having the filesystem sitting on a thin provisioned volume, like for instance LVM thin. The absence of discard commands coming from the virtual node does not allow the cleaning of unused blocks.
A PR was submitted:
https://github.com/vyos/vyos-1x/pull/5353/changes
@RubenNL thanks for looking into this
I believe the module is misused, that is why the result is not as expected.
Jul 26 2026
Hi @syncer @sever and @dmbaturin !
Can we discuss the need in this feature.
JunOS has never implemented it (despite the PR above), yet vyos.vyos seems to use ActonNetworkModule from netcommon Galaxy collection - it is maintained, patched and works well.
Having own action plugin will mean we will need to build it separately and maintain to meet Ansible version.
Jul 25 2026
Jul 24 2026
@doctorpangloss any news?
Do you have steps to reproduce? If yes, provide the minimal set of commands and version.
Yes, I can confirm that it works the same with multiple users in the system:
vyos@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history 600 vyos:users vyos@vyos1:~$ su - testuser testuser@vyos1:~$ pwd /home/testuser testuser@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history 600 testuser:users
Jul 23 2026
Is this also true for multiple users so they not all end up with vyos:users?
New PRs:
I checked it manually and it looks like the metadata was transferred after upgrade:
vyos@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history 600 vyos:users vyos@vyos1:~$ sudo stat -c '%a %U:%G' .ssh/known_hosts 644 vyos:users vyos@vyos1:~$ add system image vyos-999.202607231048-generic-amd64.iso Validating image compatibility Validating image checksums ... Would you like to copy SSH host keys? [Y/n] Copying SSH host keys Would you like to save the SSH known hosts (fingerprints) from your current configuration? [Y/n] Copying SSH known_hosts files Would you like to copy bash history? [y/N] y Copying bash history ... vyos@vyos1:~$ sudo reboot now ... vyos@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history 600 vyos:users vyos@vyos1:~$ sudo stat -c '%a %U:%G' .ssh/known_hosts 644 vyos:users
Jul 22 2026
A PR has been opened with these changes.
Will chmod and chown be preserved on the directories and files being copied?
@mrpops2ko Could you please test whether the fix works for you?
This issue remains in july 2026 using VyOS Stream 2026.03.
A workaround for NTP and DNS-server is to use containers and allow-host-networks in case the container itself have support for VRF (aka SO_BINDTODEVICE seen through "ss -atulpn" that the process listens to for example 192.0.2.1%PROD:123 instead of just 192.0.2.1:123).