Infrastructure

From MTU LUG Wiki
(Redirected from LUGDocs)
Jump to navigation Jump to search

This page is intended as a 'hub' for all of LUGs internal documentation.

All of our documentation is intentionally public so that other student organizations or individuals can replicate aspects of our infrastructure if they so desire.


If a topic requires a significant amount of content, you may want to break it out into a new article and link it on this page.

Servers & Services

Proxmox Cluster

The majority of our infrastructure are VMs in the Proxmox cluster, so everything can be highly-available (meaning VMs can jump to another Proxmox node if one goes down).

In the panel for each VM in the webUI, make sure to enable the guest agent; Debian will auto install the QEMU guest agent on first install when it detects being run inside a VM.

Proxmox Nodes

The nodes in the cluster include:

  • [10.10.1.20] Kurisu
  • [10.10.1.21] Okabe (currently offline; running Windows 10 LTSC temporarily to poke around with HGST Drives)
  • [10.10.1.22] Daru
  • [10.10.1.23] Luka
  • [10.10.1.24] Mayuri
  • [10.10.1.25] MrBraun (HP Server)

Note that all these addresses are static, and must be changed manually on each host (Proxmox doesn't currently support DHCP). The process is loosely outlined by the comments here.

These are also listed in Servers since they're all physical servers in the GLRC rack.

Virtual Machines

The VMs in the cluster include:

  • [10.10.1.2] PXEBoot server (inactive)
  • [10.10.1.8] Huskybot IRC<->Matrix<->Discord bridge
  • [10.10.1.9] LUG IRC Server (running ergo)
  • [10.10.1.12] Invidious (private youtube frontend, currently inactive)
  • [10.10.1.14] BookStack (alternative knowledgebase for documentation. Inactive, we're using this Wiki instead)
  • [10.10.1.15] webserver running NGINX, hosts the lug.mtu.edu homepage and servers as a reverse-proxy for all other webservers behind our NAT.
  • [10.10.1.16] This mediawiki instance
  • [10.10.1.17] Netbox (network/rack-related documentation. Currently inactive, overly complicated for our needs)
  • [10.10.1.70] Socksproxy (so members using the split-tunneled LUG VPN have an easy way to route traffic through LUG)
  • [10.10.1.71] VM for accessvillage.net (contact Noah if any issues)
  • [10.10.1.76] debian (noah courseproject; will eventually delete)
  • [10.10.1.99] Noah's personal VM for random stuff
  • [10.10.1.170] hashtopolis (RedTeam Hashtopolis server for CTFs)
  • [10.10.1.172] badapple (parrot.live-like badapple service)
  • [10.10.1.202] "Main-MC" (idk; ask Allen)
  • [10.10.1.212] Velocity reverse-proxy for Minecraft servers (so we can offer unlimited servers to clubs/halls on campus without running out of public IPs)
  • [10.10.1.224] Allen's Gaming VM (runs Windows)
  • [10.10.1.229] "Kube-Minecraft" (idk; ask Allen)

You can see all VMs listed in the Proxmox WebUI.

Updating Nodes

Proxmox runs on top of Debian, so the updating process is the mostly same.

  1. apt update && apt upgrade
  2. (Optional) Remove the annoying unlicensed popup from web dashboard: sed -Ezi.bak "s/(Ext.Msg.show\(\{\s+title: gettext\('No valid sub)/void\(\{ \/\/\1/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service
  3. (Optional) Manually migrate all VMs to other Proxmox nodes first; Proxmox doesn't do this automatically and all the VMs running on the host when it reboots will go offline until the host comes back up
  4. (Optional but recommended) reboot the node

For the yearly major version bumps, you may need to run apt update && apt upgrade, followed by apt dist-upgrade; This is the process on Debian, but I haven't tested it on Proxmox.

Check the Proxmox wiki's 'Upgrade' category for specific instructions when the time comes.

Updating VMs

All VMs run Debian to keep things homogenous and easy to upgrade/automate, except a few Windows VMs like Allen's scuffed Win10 LTSC gaming VM; Those are presumed self-managed.

The update process is the same as any Debian system:

  1. apt update && apt upgrade
    1. If the kernel or systemd get updated, it's a good idea to reboot
  2. For major version bumps (I think there's one each year?), you need to run the aforementioned apt update && apt upgrade, followed by apt dist-upgrade

Updates need to be automated with Ansible at some point.

Mirrors

Mirrors is a standalone Dell R730xd server (3.5" drive bay variant) running FreeBSD, and all services are managed by salt.

We're in the process of rebuilding it, but in the meantime this is what we've been doing to manage it thus far:


Certificate maintenance:

put it in /usr/share/salt/<somewhere> where salt will copy it to /etc/nginx/<somewhere>

Continued in the Mirrors subpage:

Infrastructure/Mirrors

Shell

Firewall/Router/Network

Our firewall/router runs pfSense, soon to be OPNsense.

All IP addressing of servers and virtual machines happens through DHCP, and can be viewed in the pfSense 'DHCP Leases' tab. (except Proxmox nodes, which don't support DHCP and require static addressing)

Otherwise, most configuration can be viewed by poking around the web interface.

Firewall rules

View the WebUI for the specific firewall rules, but some of the more basic/essential ones are:

  1. Management cannot communicate with LAN/WAN (the internet), and LAN cannot communicate with Management.
    1. Generally, Management should be restricted from everything else. (maybe even other iDrac servers?)
    2. OOB services tend to be super vulnerable, there are dozens of premade scripts that instapwn iDRACs and give you a root shell by just pointing them at the IP address.
    3. Because of this, the iDRAC web login interface should only be accessible to anyone you're okay having root on the server.
  2. Wireguard
    1. The admin/user split is so all members can be given a wireguard config to the internal network without having to worry about them being able to trivially get root on all servers running premade-exploits like these on the iDracs.
    2. If someone shows up to a couple meetings they're probably fine to get an admin config; this is more for peace-of-mind to not need to worry about the configs given to people who went to one meeting once at the beginning of the semester and have never been seen again.
    3. Neither config should have access to WAN, just to prevent someone getting LUG in hot water if they attempt to torrent or something similarly dumb through the VPN.

Main networks

We have two main networks:

  • 10.10.0.0/24 - Management (OOB Management services like Dell iDRAC / HP iLO)
  • 10.10.1.0/24 - LAN (servers/VMs)

We may also be getting a /27 of Tech's 141.219.0.0/16 block through IT (~28-30 usable public IP addresses).

The plan is to use reverse-NAT to map the public IPs to select internal IPs, since we won't have enough IPs for every VM (so we can't do it like IT and exclusively use publicly routable addresses).

VPN Networks

In addition, there are two main VPN networks:

  • 10.10.10.0/24 - OpenVPN
  • 10.10.11.0/24 - Wireguard
    • 10.10.11.0/25 - Wireguard admin range (access to Management+LAN, no WAN)
    • 10.10.11.128/25 - Wireguard user range (access to only LAN, no WAN)

Fileserver

Coming Soon, currently unprovisioned (waiting on new PSU; and fixing HGST drives)

Management

Time-sensitive

Email IT for new certs (example template to use, make sure to keep SubjectAltName, etc)

Install-a-thons

shirt printing

Budget

USG meetings

making presentable diagrams and representations of data