Thanks for confirming. With 2 users, you may encounter always the issue that a cronjob locks up your ability to change the config afterwards. For now the manual workaround should help you, I'm going to revert my changes from yesterday and return to the drawing board.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 22 2019
Thx for testing.
Fixed via T1181
I wouldn't execute a scheduled script. Thats all. Do you recreate then a different user? Since all users have admin privs, the probem with the change permissions will persist. Actually makes it works, one user can block the other. So, I have to find something else out.
@cpo it would just exit 1. I gotta look into the possibility to see the commit user, I was under the assumption that the vyos user always exists. If there are multiple (at least 2 different) and the cron runs a root or the user (the one which did not setup the job), it will disable any config for all other users, since the filesystem permissions change. ACL's would be something which can solve it, but I have to verify it. I'll keep this task open to track it. Do you just replace the vyos user, or are you using root only in your config?
Jan 21 2019
@yun can you please test with the latest rolling?
@kroy install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-10_all.deb and try again, I have the changes in that package and tonights rolling will have it too. I couldn't find anywhere a requirement that the cronjobs need root, so I switched it to always run as vyos which keeps the file system permissions intact. Test it on a test machine first, but it should now do what you want, I used your script code from above, but didn't have any real ospf adjacency with any other route, but that shouldn't matter at all. Let me know the results please.
OK, I think I found it, however so far I can only give you a quick workaround rather than solving it.
Short explanation, if you setup cron, your script is executed as root which changes the permissions for the configs on union-fs and the directories, that's why already a set fails, it can't simply write as user vyos to the directory.
To get your stuff working, try the following (preferably on a test box, I used the rolling from tonight but any 1.2 image should work if it's not older than 3 months or so)
The 'commit' causes the issue, but right now I'm not sure why.
In T1178#30992, @kroy wrote:@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.
I'm going to implement it into the configuration, which will assure that is it going to be the last step executed after a reboot.
Jan 18 2019
wireguard identifies peers on their key, improve the command for sh int wireguard wg01 peers etc. so that the peer name from the config is visible as well.
@ekim https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address the dhcp issue, can you please test? I only tested on VMs yet.
@yun https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address that issue, can you please test? I only tested on VMs yet.
Jan 17 2019
pending ci netplugd integration, local tests were quite successful, I think it can be release into rolling in the next few days.
Jan 16 2019
T1181 will fix that issue.
All right @ekim I have that feature working in an experimental package. If you want to test it you can build it from here:
https://github.com/hagbard-01/vyos-netplug via dpkg-buildpackage -b -tc -uc -us and install it on any rolling iso. I used the latest for my tests, but it should work on older ones too. It will still take a little time to have that pushed into the normal build process, since it requires some integration work.
@ekim Yeah, that is a known issue I was looking into a while ago already. disable/enable in eth interfaces should now work in the latest rolling, the plug-in and unplug will still need a little. I'll keep this task here open for it.
I think I know what you mean now, it also starts translating the global address on the external interface. Can you send a PR for the changes you've made please?
Jan 15 2019
At the first quick review it works:
@Merijn I haven't added anything. I just tested nptv6 and it was working as expected. I used your setup you have initially posted, I just used a different interface for the outgoing traffic. I confirmed via tcpdump that NAT did work.
@ekim I think I found it. When I put the interface into disabled mode and then delete disabled, the dhcp client isn't started anymore if the address is supposed to be received via dhcp, correct?
Have you checked on the server DHCP server side for issues?
I've tested it without doing anything on the code and everything is working properly.
Jan 11 2019
That's all to test. I did test it based on the config you provide above, I just want to see if there are any corner case I did not consider.
Jan 10 2019
I got a bit further. uacctd seems to have an issue, I started manually pmacctd on pppoe0 and everything is working well. Uacctd shows that it gets hit with something when I check via strace, but it doesn't show anything.
Jan 8 2019
merged and closed on @kroy 's behalf. (https://phabricator.vyos.net/R5:749d923ee9704624a476bef17d66d752aff6bf0d)
thx @kroy
The latest rolling has now 'net.ipv4.conf.all.send_redirects = 0', can you please test if that would solve that issue?
But wouldn't that be a n SA issue in strongswan?
Found their bugreports, I think the best and safest way is to turn redirects entirely off and set an option in interfaces to turn it on. That way we can assure that a warning messages is also read and understood. agree?
Hmm, I don't like the leaking part :D (I doubt that it will be unecrypted, but haven't tested it yet) . Per default redirects are enabled on every interface, which is the default.
@zsdc if I understand you correctly, you want that /proc/sys/net/ipv4/conf/all/send_redirects is always 0 unless configured on purpose, correct?
Per default router should do that.
Jan 7 2019
Sorry for the delay @Barrysdca , please test the rolling release January 8th. or alternativly you can install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-system/vyatta-cfg-system_0.20.44+vyos2+current17_amd64.deb as well, which should fix the issue.
Please provide feedback as soon as you can, I tested the config you have posted above and everything appears to be working well now with the new package.
@syncer I was thinking to add a cli menu for vmwaretoolsd mitgation like these things. It seems that not many were affected by that but if there is anything in the cli available, it can configure the toolsd to prevent things like that plus the toolsd has tons of options. So, I'm not really sure how I should go forward with this one.
Next rolling will have the fix applied:
https://github.com/vyos/vyos-1x/commit/76fe726e3530158ee175d34b9cb74209ccca2345
Jan 6 2019
@c-po I have access to it, let me know if you need a pdf out of it.
Jan 5 2019
Jan 3 2019
I stumbled over the same issue and since then I contribute to @UnicronNL and @c-po documentation. I think the old wiki will go away at one point, have a look at the github link @c-po posted above, it's also way easier to maintain the new documentation.
Hi @rherold , these messages are verbose debug messages, change to virtio-net or to a different emulated driver to have them disappear. In general I recommend to use the virtio one which has a better performance too compared to emulated ones, plus less complex code. (https://github.com/MorteNoir1/virtualbox_e1000_0day)
Dec 31 2018
Dec 29 2018
Thanks for testing that guys.
Dec 28 2018
@MrXermon , yes that sounds reasonable. I found in the code that they limit it to 100 routes, can you please try the following:
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/conf.h#L138)
Hi @Barrysdca did you have a chance to test again?
Hi @danhusan, did you ever try another poll value, like 3 secs or 5 or anything like that? If set to 0, the host system won't show you any updated meta data, like if you change the ip address etc.
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L1662)
I'm therefore not entirely sure if that should be treated as a special case scenario (we could publish a kb if you run into that condition), or if it is a general issue since you 2 were the only ones experience that issue as far as I know.
I'm also not sure it only is triggered by your situation (full bgp table) or if it can happen on other occasions as well, if you came across more issues regarding that value, please let me know.
Dec 27 2018
I have a look into it but I doubt that this will be an issue. Charon is usually taking care of the routes if an IPSec tunnel has been established and you have a valid SA. The redirects from the settings above shouldn't interferer with it at all. If a mode tunnel is being used with public IPs, the packets will leave the system unencrypted anyway as long as no valid SA exists, so they will go the default route. I'll check if the perl script is actually changing these settings, that would be not so nice since you will face a race condition which would explain why I can't reproduce your issue, since I never tested with a working IPSec tunnel :). I'm having the flu right now, so please give me a few days to have a look.
Dec 26 2018
Can you check ig you have any postscripts running or any manual sysctl variable set? Or do you experience that on new insatllations?
Dec 25 2018
Yes, that's correct. When I enable redirects, it automatically disables receive redirects, which I didn't know but makes sense.
I have only set the redirect and dhcp on eth0, commit && save and rebooted, all looks good.
I still have no luck reproducing it, I loaded your config on a vm, runni9ng the smae version as you do but if I enable and disable redirects it switches between 1 and 0, as expected.
Dec 24 2018
@zsdc I can't reproduce it, can you please share your config? I have only enable send redirects set, nothing else in the config and everything works like expected. I suspect that something is overwriting your variables. We'll find out.
Dec 18 2018
Next rolling release tonight will have the bugfix in place. Thanks for reporting.
@Barrysdca Can you please test with the latest rolling release, please?
@Unicron Can you please integrate the package below into ci?
https://github.com/vyos/vyos-vmwaretools-scripts