XPipe Vault (Keep this repository private!)

This repository contains all connection information that is designated to be shared.

You can sync with this repository in all XPipe application instances the same way, every change you make in one instance will be reflected in the repository.

Category list

• Connections
  • Proxmox Kladow
    • VM
    • Hosts
    • Container
  • Proxmox Hetzner
    • VM
    • Hosts
    • Container
  • local
  • Default
  • Boot
• Scripts
  • Custom
• Identities
  • Synced
• Macros

Connection list

All connections / Proxmox Kladow

empty

All connections / Proxmox Kladow / VM

• Univention fileserver archiv
• Univention fileserver laufend
• Univention PDC02

All connections / Proxmox Kladow / Hosts

• Proxmox Kladow Backup
  • Proxmox systems
    • 3CX-SBC
    • docker-main
    • Ecockpit
    • fileserver-archiv
    • fileserver-laufend
    • PDC02
    • pihole
    • Services
      • PVE dashboard
    • wireguard
    • workstationneuerMaster
    • XP
• Proxmox Kladow main
• Proxmox Kladow PBS02

All connections / Proxmox Kladow / Container

• pihole
• wireguard

All connections / Proxmox Hetzner

empty

All connections / Proxmox Hetzner / VM

• Terminalserver 174
• Unvention fileserver Archiv
  • Docker containers
    • default
  • Shell environments
    • sudo
• Unvention fileserver ausgelagert
  • Docker containers
    • default
  • Shell environments
    • sudo
• Unvention fileserver laufend
  • Docker containers
    • default
  • Shell environments
    • sudo
• Unvention Mail
  • Docker containers
    • default
  • Shell environments
    • sudo
• Unvention nextcloud Guacamole
  • Docker containers
    • default
  • Shell environments
    • sudo
• Unvention PDC
  • Docker containers
    • default
  • Shell environments
    • bash
    • dash
    • sudo

All connections / Proxmox Hetzner / Hosts

• Proxmox Hetzner
  • Proxmox systems
• Proxmox Hetzner PBS

All connections / Proxmox Hetzner / Container

• docker immich
  • Docker containers
    • default
• docker rustdesk
  • Docker containers
    • default
• docker-baikal
  • Docker containers
    • default
  • Shell environments
    • bash
    • dash
• docker-ip-symcon
  • Docker containers
    • default
  • Shell environments
    • ash
• docker-vaultwarden
  • Docker containers
    • default
  • Shell environments
    • bash
    • dash
• dolibarr
  • Shell environments
    • bash
    • dash
• ecomailz
  • Shell environments
    • bash
    • dash
• gitea
  • Shell environments
    • bash
    • dash
• Influxdb
  • Shell environments
    • bash
    • dash
• Lizenzserver
• mysql
• pihole
• proxmox mailgateway
  • Shell environments
    • bash
    • dash
• vdirsyncer
• wireguard

All connections / local

empty

All connections / Default

• nextcloud guacamole
  • Docker containers
    • default
  • Shell environments
    • bash
    • dash
    • sudo

All connections / Boot

empty

All scripts / Custom

• My scripts

All identities / Synced

• Administrator AD

Secret encryption

You have the option to fetch any sensitive information like passwords from outside sources like password managers or enter them at connection time through a prompt window. In that case, XPipe doesn't have to store any secrets itself.

In case you choose to store passwords and other secrets within XPipe, all sensitive information is encrypted when it is saved using AES with either:

• A dynamically generated key file vaultkey (The data can then only be decrypted with that file present)
• A custom passphrase that can be set for your user in the vault settings menu (This option can only as secure as the password you choose)

By default, general connection data is not encrypted, only secrets are. So things like hostnames and usernames are stored without encryption, which is in line with many other tools. There is an available setting in the vault settings menu to encrypt all connection data if you want to do that.

Cloning the repository on other systems

Nowadays, most providers require a personal access token (PAT) to authenticate from the command-line instead of traditional passwords. You can find common (PAT) pages here:

• GitHub: Personal access tokens (classic)
• GitLab: Personal access token
• BitBucket: Personal access token
• Gitea: Settings -> Applications -> Manage Access Tokens section Set the token permission for repository to Read and Write. The rest of the token permissions can be set as Read.

Even if your git client prompts you for a password, you should enter your token unless your provider still uses passwords.

If you don't want to enter your credentials every time, you can use any git credentials manager for that. For more information, see for example:

• https://git-scm.com/doc/credential-helpers
• https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git

Some modern git clients also take care of storing credentials automatically.

Troubleshooting

Adding connections to the repository

By default, no connection categories are set to sync so that you have explicit control on what connections to commit.

To have your connections of a category put inside your git repository, you first need to change its sync configuration. In your Connections tab under the category overview on the left side, you can open the category configuration menu either by right-clicking the category or click on the ⚙️ icon when hovering over the category, and then clicking on the 🔧 configure button.

Then, set the Sync with git repository value to Yes to sync the category and connections to your git repository. This will add all syncable connections in that category to the git repository. The sync settings for a category are inherited by default from its parent if not explicitly set.

Local connections are not synced

Any connection located under the local machine can not be shared as it refers to connections and data that are only available on the local system.