Alex A. Naanou e404ea7d77 ...
Signed-off-by: Alex A. Naanou <alex.nanou@gmail.com>
2024-10-22 03:39:05 +03:00
2024-10-21 15:58:03 +03:00
2024-02-02 02:04:35 +03:00
2024-02-05 23:16:36 +03:00
2024-10-22 02:55:50 +03:00
2024-10-20 02:22:39 +03:00
...
2024-10-20 10:23:49 +03:00
2024-03-31 15:17:09 +03:00
2024-10-21 17:43:01 +03:00
2024-10-19 13:59:43 +03:00
...
2023-07-17 21:51:57 +03:00
2024-10-20 00:50:53 +03:00
2023-06-28 14:25:43 +03:00
2024-03-26 14:12:34 +03:00
fix
2024-01-02 04:07:36 +03:00
2024-10-21 15:58:03 +03:00
2024-01-25 03:35:49 +03:00
2024-02-02 01:50:22 +03:00
...
2024-10-22 03:36:04 +03:00
2023-12-30 16:05:41 +00:00
2023-12-30 16:05:41 +00:00
...
2024-10-22 03:39:05 +03:00
2023-12-30 16:05:41 +00:00

proxmox-utils (EXPERIMENTAL)

A set of scripts for automating setup and tasks in proxmox.

TODO

  • CT updates / upgrades
    Right now the simplest way to update the infrastructure CT's if the sources changed is to simply rebuild them -- add rebuild command.
    • backup
    • build (new reserve)
    • destroy
    • clone
    • cleanup
  • backup/restore
  • config manager -- save/use/..
  • mail server
  • which is better?
    • Makefile (a-la ./wireguard/templates/root/Makefile)
    • shell (a-la ./shadow/templates/root/update-shadowsocks.sh)
  • separate templates/assets into distribution and user directories ...this is needed to allow the user to change the configs without the fear of them being overwritten by git (similar to how config is handlerd)

Motivation

This was simply faster to implement than learning and writing the same functionality in Ansible.

NOTE: for a fair assessment of viability of further development an Ansible version will be implemented next as a direct comparison.

Fun.

Architecture

Goals

  • Separate concerns
    Preferably one service/role per CT
  • Keep things as light as possible
    This for the most part rules out Docker as a nested virtualization layer under Proxmox, and preferring light distributions like Alpine Linux
  • Pragmatic simplicity
    This goal yields some compromises to previous goals, for example TKL is used as a base for Nextcloud effectively simplifying the setup and administration of all the related components at the cost of a heavier CT, transparently integrating multiple related services

Network

    Internet                                              Admin 
       v                                                    v
  +----|----------------------------------------------------|-----+  
  |    |                                                    |     |  
  |  (wan)                                (lan)          (admin)  |  
  |    |                                    |               |     |  
  |    |                                    |         pve --+     |  
  |    |                                    |               |     |  
  |    |                   +--------------------------------+     |  
  |    |                  /                 |               |     |  
  |    +--($WAN_SSH_IP)- ssh ---------------+               |     |  
  |    |                  ^                 |               |     |  
  |    |              (ssh:23)              |               |     |  
  |    |                  .                 |               |     |  
  |    |                  . +------------------------(nat)--+     |  
  |    |                  ./                |               |     |  
  |    +------($WAN_IP)- gate ------(nat)---+               |     |  
  |                       .                 |               |     |  
  |                       .                 +-- ns ---------+     |  
  |                       .                 |               |     |  
  |                       + - (udp:51820)-> +-- wireguard --+     |  
  | System                .                 |               |     |  
  | - - - - - - - - - - - . - - - - - - - - | - - - - - - - | - - |  
  | Application           .                 +-- syncthing --+     |  
  |                       .                 |                     |  
  |                       + - - - (https)-> +-- nextcloud         |  
  |                       .                 |                     |  
  |                       + - (ssh/https)-> +-- gitea             |  
  |                                                               |  
  +---------------------------------------------------------------+  

The system defines two networks:

  • LAN
    Hosts all the service CT's (*.srv)
  • ADMIN
    Used for administration (*.adm)

The ADMIN network is connected to the admin port.

Both networks are provided DNS and DHCP services by the ns CT.

Services on both networks are connected to the outside world (WAN) via a NAT router implemented by the gate CT (iptables).

The gate CT also implements a reverse proxy (traefik), routing requests from the WAN ($WAN_IP) to appropriate service CT's on the LAN.

Services expose their administration interfaces only on the ADMIN network when possible.

The host Proxmox (pve.adm) is only accessible through the ADMIN network.

The gate and ns CT's are only accessible for administration from the host (i.e. via lxc-attach ..).

Three ways of access to the ADMIN network are provided:

  • wireguard VPN (CT) via gate reverse proxy,
  • ssh service (CT) via the gate reverse proxy,
  • ssh service (CT) via the direct $WAN_SSH_IP (fail-safe).

Getting started

Prerequisites

Install Proxmox and connect it to your device/network.

Proxmox will need to have access to the internet to download assets and updates.

Notes

This setup will use three IP addresses:

  1. The static (usually) IP initially assigned to Proxmox on install. This will not be used after setup is done,
  2. WAN IP address to be used for the main set of applications, this is the address that all the requests will be routed from to various services on the LAN network,
  3. Fail-safe ssh IP address, this is the connection used for recovery in case the internal routing fails.

Setup

Open a terminal on the host, either ssh (recommended) or via the UI.

Optionally, set a desired default editor (default: nano) via:

export EDITOR=nano

Download the bootstrap.sh script and execute it:

curl 'https://raw.githubusercontent.com/flynx/proxmox-utils/refs/heads/master/scripts/bootstrap.sh' | sudo bash

It is recommended to review the script/code before starting.

This will:

  • Install basic dependencies,
  • Clone this repo,
  • Run make bootstrap on the repo.

At this point WAN interface exposes two IPs:

  • Main server (config: $DFL_WAN_IP / $WAN_IP)
    • ssh:23
    • wireguard:51820
  • Fail-safe ssh (config: $DFL_WAN_SSH_IP / $WAN_SSH_IP)
    • ssh:22

The Proxmox administrative interface is available behind the Wireguard proxy or on the ADMIN port, both on https://10.0.0.254:8006.

To finalize the setup run:

make finalize

This will

  • Setup firewall rules.
    Note that the firewall will not be enabled, this should be done manually after rule review.
  • Detach the host from any external ports and make it accessible only from the internal network.
    See: Architecture and Bootstrapping

This will break the ssh connection when done, reconnect via the WAN port to continue (see: Accessing the host), or connect directly to the ADMIN port (DHCP) and ssh into $HOST_ADMIN_IP (default: 10.0.0.254).

Note that the ADMIN port is configured for direct connections only, connecting it to a configured network can lead to unexpected behavior -- DHCP races, IP clashes... etc.

Accessing the host

The simplest way is to connect to wireguard VPN and open http://pve.adm:8006 in a browser (a profile was created during the setup process and stored in the /root/clients/ directory on the wireguard CT).

The second approach is to ssh to either:

ssh -p 23 <user>@<WAN_IP>

or:

ssh <user>@<WAN_SSH_IP>

The later will also work if the gate CT is down or not accessible.

And from the ssh CT:

ssh root@pve

WARNING: NEVER store any ssh keys on the ssh CT, use ssh-agent instead!

Configuration

XXX

The following CT's interfaces can not be configured in the Proxmox UI:

  • gate
  • ns
  • nextcloud
  • wireguard

This is done mostly to keep Proxmox from touching the hostname $(hostname) directive (used by the DNS server to assigned predefined IP's) and in the case of gate and wireguard to keep it from touching the additional bridges or interfaces defined.
(XXX this restriction may be lifted in the future)

Services

XXX

make all
make dev

Syncthing

make syncthing

XXX

Nextcloud

make nextcloud

XXX

Gitea

make gitea

XXX

Custom services

XXX traefik rules

Extending

Directory structure

proxmox-utils/
+- <ct-type>/
|   +- templates/
|   |   +- ...
|   +- assets/
|   |   +- ...
|   +- staging/
|   |   +- ...
|   +- make.sh
|   +- config
|   +- config.last-run
+- ...
+- Makefile
+- config.global
+- config.global.example
Description
No description provided
Readme BSD-3-Clause 499 KiB
Languages
Shell 89.4%
Makefile 8.9%
Smarty 1.7%