the service `user@0.service` fails in system vms and virtual routers
This PR removes a change to fix memory leak of SSH connections in the systemvm templates with old linux kernel.
* 4.18:
server: remove registered userdata when cleanup an account (#7777)
server: Use max secondary storage defined on the account during upload (#7441)
test: upgrade kubernetes versions to 1.25.0/1.26.0 (#7685)
kvm: Added VNI Devices as normal bridge slave devs (#7836)
noVNC: fix JP keyboard on vmware7+ which uses websocket URL (#7694)
* 4.18:
SSVM: 'allow from' private IP in other SSVMs if the public IP is in allowed internal sites cidrs (#7288)
eof added to StorPoolStatsCollector (#7754)
This PR fixes#6702
The service conntrackd will be started by the script /opt/cloud/bin/cs/CsRedundant.py, therefore add it to disabled_svcs so it is not started automatically when VR is started.
This PR slows down the console paste text function in the console ever so slightly, adding 25ms between each character. It was found that when large text is pasted, say an SSH key or something over 100 characters, it would stop somewhere in the 100-200 character range, and if the last character was capitalized it would be stuck with left shift held down.
In debugging, I ran noVNC locally with websockify against a Qemu VNC and took the whole console proxy out of the equation and was still able to reproduce it. I traced the websocket packets and we were clearly firing off all of the keypresses just fine, but the ones on the end were getting dropped VNC server side. It seems we are overloading a keyboard buffer, or something along those lines when we send all of the keypress messages at once. It was also observed that we were able to send off all of the messages via websocket in just a few ms but the typing on the guest side took a few seconds, so there is some buffering and processing going on and I think we are just hitting some limit in this.
This sendText function doesn't seem to exist in upstream noVNC, so just patching it here seems reasonable. I suspect we added this for feature parity with whatever noVNC replaced.
In testing it is now much more reliable in sending a few paragraphs of text, and not visibly slower than before, but obviously still too slow to do anything really big with it. It isn't really the goal to be able to paste full documents.
Co-authored-by: Marcus Sorensen <mls@apple.com>
This PR allows securing the console access through CloudStack to the virtual machines running on KVM. The secure access is achieved through the generated certificates for the CA Framework in CloudStack, that provides mutual TLS connections between agents. These certificates are used to also secure the connection between the console proxies and the VNC ports for VM console access.
This feature is only supported on the KVM hypervisor
Design Document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+KVM+VNC+connection+using+the+CA+framework
Fixes#6873
When the management server is in a different subnet than the pod in which a VPC VR is deployed, an ip route must be added just after creation of eth0 to allow the connectivity between the VR and the management server.
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Co-authored-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This PR fixes that the /etc/network/interfaces is misconfigured in VPC VR startup, which causes VPC VR to be stuck for 1 minute and continue working.
The issue is because ifup eth0 and ifdown eth0 do not work when /etc/network/interfaces is not correct in VPC VR.
PR #5375, introduced in version 4.15.2.0, removed parameter %any of VPNs client-to-site (C2S) IPSec secrets:
structure before PR vr: ipsec/l2tp vpn secret with no ID selectors #5375:
<IP> %any : PSK "<PSK>"
structure after PR vr: ipsec/l2tp vpn secret with no ID selectors #5375:
<IP> : PSK "<PSK>"
Because of that, when a VPN site-so-site (S2S) is created in parallel to a VPN C2S in the same network, the C2S will not handle any IP (%any) anymore and, as the network is being tunneled to the other VPN, the connection will be handled by the final peer. This way, when a VPN S2S is created in parallel to a VPN C2S in the same network, it is only possible to connect to the C2S with the S2S PSK.
As ACS is only able to implement a single C2S per network (ACS allows setting more than one IP of the network as VPN, however, only the first will be implemented) and every S2S has its own secret file, the secrets structure of C2S was changed to contain only the PSK:
: PSK "<PSK>"
By doing that, StrongSwan will handle correctly C2S connections from any IP and still will use the correct PSK for S2S.
Co-authored-by: GutoVeronezi <daniel@scclouds.com.br>
