I have that issue for a while here too and just helped myself locally. I'll can take care of that.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 17 2019
Oct 16 2019
PR #37
PR #31
The system where I'm seeing this is a VM which use a BNX2 dual port network card via PCI pass-thru. Both ports (eth0 and eth1) are configured in a LACP bond (bond0) with several VIF running on top of it (bond0.10, bond0.20, etc). All VIF are showing this problem.
I have generated a PR for this fix https://github.com/vyos/vyatta-op-vpn/pull/24.
Please take a look at it.
Hi @albeu the fix is very bad in most of our cases and not really good to address a single issue. Can you give some hints to reproduce the "DHCP won't start on some interfaces"? problem?
When we say building is only supported in our Docker environment - is it even an issue? Just patch it during preparation of the container and we‘re all set.
One might need to differentiate between transparent bump-in-the-wire type squid deployments, and running it as a known proxy (delivered via DHCP and an onboard PAC file). Plus any kind of speedbump captive portal. I know one place specifically uses it to force clients to expose connecting hostname due to the use of the CONNECT command for TLS connections, for passive logging on the wire. Which will get interesting with the emergence of DoH and DoT in mainstream browsers, and enterprise efforts to kill that off.
Oct 15 2019
Myself I'm in favor of maintaining a fork and asking people to install it. We can add a version check to the ./configure script to make sure it stops and tells the user what to do if the version is not patched.
Most enterprises use it still as a cheap authentication method, I'm totally in favor to drop it, not only in vyos. Breaking it off (they generate fitting ssl certs on the fly signed with a private PKI), is questionable as well, since I think https should be end to end encryption, everyone who messes with that idea, well I wouldn't trust them on other items as well.
works with:
Version: VyOS 1.2-rolling-201910110117 Built by: [email protected] Built on: Fri 11 Oct 2019 01:17 UTC Build UUID: 48a11fa6-8c59-4dbb-94a3-215376c09a02 Build Commit ID: 46f9b2ab60e4fa
Can't create an iso right now to test it.
Also, as we are implementing this into the vyos cli, we can only omplement a small subset of the squid functionallity without doing lare efforts on implementing everything.. thats also why i favor to removing this functionallity..
+1
+1
Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).
I will ask on customer survey but i know proxies used in enterprise environments not for caching or blocking but for securing access to public segments
Oct 14 2019
To be fair, that’s what prompted this. The logs go to a different file already.
Because the amount of logs from this system could be enormous, Is it possible to move these logs to another syslog file to not overcroud the main syslog file?
This PR should address those concerns
@c-po can you provide a way to reproduce your issue?
I would rather prefer it to send messages to local syslog and then distribute it to remote hosts. Otherwise we have an async syslog interface.
https://github.com/vyos/vyatta-cfg/pull/19
This fixes the conf mode completion, at least in the bash cli shell.
@hagbard This is still an issue in conf-mode. to replicate:
Any update when this can be used live? This prevents me fro using vyos😟
Oct 13 2019
Okay - just installed the latest rolling and it does not even boot up anymore. Its trapped in a snmp restart loop somehow. Going to revert this commit.
The change now leads to not starting SNMP when I do not use BGP