mirror of
https://git.proxmox.com/git/pve-docs
synced 2025-08-02 11:19:26 +00:00
cluster: restructure ssh role section
Move the example into the bulletin points, makes it clearer that they are connected and avoids interrupting the flow when reading. Make the whole "important" part a admontion, as such notes should be self-contained (not split between note and non-note), it also gives it more visibility. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This commit is contained in:
parent
39aa8892b4
commit
9d999d1bf6
38
pvecm.adoc
38
pvecm.adoc
@ -869,28 +869,31 @@ pvecm status
|
||||
If you see a healthy cluster state, it means that your new link is being used.
|
||||
|
||||
|
||||
Role of SSH in {PVE} Clustering
|
||||
-------------------------------
|
||||
Role of SSH in {PVE} Clusters
|
||||
-----------------------------
|
||||
|
||||
{PVE} utilizes SSH tunnels for various operations:
|
||||
{PVE} utilizes SSH tunnels for various operations.
|
||||
|
||||
* Proxying terminal sessions on the GUI
|
||||
|
||||
* VM/CT Migrations (if not configured 'insecure' mode)
|
||||
|
||||
* Storage replications
|
||||
|
||||
For example when you connect another nodes shell through the interface, a
|
||||
* Proxying terminal sessions of node and containers between nodes
|
||||
+
|
||||
When you connect another nodes shell through the web interface, for example, a
|
||||
non-interactive SSH tunnel is started in order to forward the necessary ports
|
||||
for the VNC connection.
|
||||
|
||||
Similarly during a VM migration an SSH tunnel is established between the target
|
||||
and source nodes. This way the local `qemu` socket can be used for the migration.
|
||||
* VM and CT memory and local-storage migration, if the cluster wide migration
|
||||
settings are not configured 'insecure' mode. During a VM migration an SSH
|
||||
tunnel is established between the target and source nodes.
|
||||
|
||||
IMPORTANT: In case you have a custom `.bashrc` or similar file that gets
|
||||
executed on login, `ssh` will automatically run it once the session is
|
||||
established. This can cause some unexpected behavior (as commands may be
|
||||
executed as a side-effect).
|
||||
* Storage replication
|
||||
|
||||
.Pitfalls due to automatic execution of `.bashrc` and siblings
|
||||
[IMPORTANT]
|
||||
====
|
||||
In case you have a custom `.bashrc`, or similar files that get executed on
|
||||
login by the configured shell, `ssh` will automatically run it once the session
|
||||
is established successfully. This can cause some unexpected behavior, as those
|
||||
commands may be executed with root permissions on any above described
|
||||
operation. That can cause possible problematic side-effects!
|
||||
|
||||
In order to avoid such complications, it's recommended to add a check in
|
||||
`/root/.bashrc` to make sure the session is interactive, and only then run
|
||||
@ -899,12 +902,13 @@ In order to avoid such complications, it's recommended to add a check in
|
||||
You can add this snippet at the beginning of your `.bashrc` file:
|
||||
|
||||
----
|
||||
# If not running interactively, don't do anything
|
||||
# Early exit if not running interactively to avoid side-effects!
|
||||
case $- in
|
||||
*i*) ;;
|
||||
*) return;;
|
||||
esac
|
||||
----
|
||||
====
|
||||
|
||||
|
||||
Corosync External Vote Support
|
||||
|
Loading…
Reference in New Issue
Block a user