Browse Source

Adds some history and other tidbits

pull/1/head
Jared Dunbar 2 years ago
parent
commit
d7c5a9e5d2
  1. 13
      docs/compute/granddad.md
  2. 8
      docs/compute/hydra.md
  3. 5
      docs/compute/norm.md
  4. 3
      docs/compute/tiamat.md
  5. 2
      docs/index.md
  6. 14
      docs/network/atlas.md
  7. 14
      docs/network/talos.md
  8. 10
      docs/network/unifi.md
  9. 22
      docs/network/voip.md
  10. 24
      docs/network/ziltoid.md
  11. 10
      docs/storage/bacon.md
  12. 14
      docs/storage/elephant.md
  13. 10
      docs/storage/uncle-deadly.md
  14. 8
      docs/web/docs.md
  15. 8
      docs/web/dubsdot.md
  16. 5
      docs/web/gitea.md

13
docs/compute/granddad.md

@ -1,6 +1,19 @@
# Grand-Dad
It's a VM Host.
## Basic Info
8 cores and not much disk space. A good compute server. 10G NIC and dual PSU. It's in the COLO currently.
## History
Grand Dad was aquired from some other department at Clarkson in March 2017 as part of a failed Green Data Center (GDC) project. Not to be confused with [OIT's GDC](https://photos.app.goo.gl/AsuJhjN7r3jGoE3BA).
## Installation
Standard VM Host
## Services
Currently, not many. Comm and GMx?

8
docs/compute/hydra.md

@ -20,8 +20,16 @@ Hydra is our primary VM host. It is currently running 18.04.03 LTS
## History
Hyrda was purchased in Fall 2016 since most of our VM infrastructure at the time was failing. We bought an AMD Opteron with 16 (slow) cores over an Intel Xeon with 8 (fast) cores because we wanted to have more VMs and speed didn't matter as much as running our vast infrastructure.
Until sometime around September 2017, we did not understand why using GDB would occasionally crash the server (used often in 141). This would cause a kernel panic, and we installed Arch Linux in January 2017 because it was the only OS that didn't seem to have the problem.
Later, we determined that it was because we forgot to do BIOS updates that fixed the CPU microcode.
## Installation:
It's Ubuntu?
### Additional packages:
htop iotop iftop lm_sensors vim sudo qemu libvirtd screen rsync tmux p7zip

5
docs/compute/norm.md

@ -1,5 +1,10 @@
# Norm
A compute server
## Basic Info
## History
Alan Beadle used this server from roughly 2015 through 2018 as a compute server. [Tiamat](tiamat.md) is the sister server, likely purchased at the same time and has nearly identical hardware.
## Installation

3
docs/compute/tiamat.md

@ -19,6 +19,9 @@ Tiamat is the name of our secondary VM host, taking the name of a hydra from DnD
* ac:16:2d:a4:6f:93 [Unused]
## History
This server was named Distance for a while (was going to host a Blue Button distance learning solution) but the server was re-allocated for a short period in 2018 as an IDS (a 10G NIC was installed at that time, since it was just after the fiber network upgrade was completed) and then got repurposed as a VM host for compute-heavy tasks after the IDS was shot down at the forum.
## Installation
## Services:

2
docs/index.md

@ -16,4 +16,4 @@ To contribute to info/, make sure you have an LDAP account on the COSI network.
In addition, you will need to install `mkdocs` on your system. Refer to [https://www.mkdocs.org/#installation](https://www.mkdocs.org/#installation) for installation instructions.
Once you have an LDAP account, clone down the [info-slash repository](https://gitea.cslabs.clarkson.edu/COSI_Sysadmins/info-slash) and make modifications to your local copy. You can preview your changes by running `mkdocs serve` and then viewing [`localhost:8000`](localhost:8000) in your browser. Commit and push your changes to have them be saved to the repository. To deploy your changes, run `mkdocs gh-deploy` and your changes will appear on info/ within 10 minutes.
Once you have an LDAP account, clone down the [info-slash repository](https://gitea.cslabs.clarkson.edu/COSI_Sysadmins/info-slash) and make modifications to your local copy. You can preview your changes by running `mkdocs serve` and then viewing [`localhost:8000`](http://localhost:8000) in your browser. Commit and push your changes to have them be saved to the repository. To deploy your changes, run `mkdocs gh-deploy` and your changes will appear on info/ within 10 minutes.

14
docs/network/atlas.md

@ -1,5 +1,19 @@
# Atlas
Atlas is the secondary DHCP and DNS server ([Talos](talos.md) is the primary).
## Basic Info
This server is `dns2.cslabs.clarkson.edu` and has a NS record from `ns1.clarkson.edu` so that we can have our delegation. (Talos is `dns1`).
## History
This server was created shortly after Summer 2017, when [Talos's](talos.md) hardware failed, causing a 6 week long outage of DHCP, DNS, and LDAP over the summer.
## Installation
I can't recall the os. Probably Arch or Ubuntu.
Install `dhcpd4` and `bind` 9 and then copy the configs over. Eventually, Talos will communicate with it and do the failover that it should do with DHCP. DNS will fail over to this server if Talos is unreachable.
That's it.

14
docs/network/talos.md

@ -1,5 +1,19 @@
# Talos
Talos is the COSI central authentication (LDAP) server, the primary DNS server, and the primary DHCP server.
## Basic Info
It is on VLAN 2 and can only be logged into from the 144/23 network.
## History
Talos was created by Alan Beadle in Summer 2015 as a replacement for the old system that we had which was not working very well. The hardware failed in Summer 2017 and was replaced with new hardware that fall. The failure prompted the creation of [Atlas](atlas.md) as a failover server for DHCP and DNS.
## Installation
Too complicated to say here, it has a lot of shit.
TL;DR, read the "[Talos Book](http://docs.cslabs.clarkson.edu/wiki/Talos)".
**TODO: Move.**

10
docs/network/unifi.md

@ -1,9 +1,19 @@
# Unifi
It controls the Unifi WiFi dish in the labs.
## Basic Info
Arch. Needs to be on VLAN 2 and connected to the dish over L2 for provisioning (so no routers in the way).
## History
Created by Jared when we needed "The Final Solution" to the COSI WiFi woes in 2016 or 2017. Up until this point, we had used various WiFi solutions (mostly home WiFi routers in bridge mode) and it was terrible. The Unifi dishes were purchased as a replacement and have done their job very well.
## Installation
It's arch. Good luck. Even worse, it requires mongodb which uses the SSPL.
# Unifi Controller
## Basic Info

22
docs/network/voip.md

@ -1,5 +1,27 @@
# VOIP
It's a VoIP server; it exists on VLAN 2 (private network) and VLAN 5 (phone network).
## Basic Info
VoIP provides an interface on VLAN 2 and is the DHCP server and gateway for VLAN 5.
## History
Created in Fall 2018 the first week we got back by Jared and Graham, it was used at the Fall 2018 career fair. Notably, Tony Collins dialed 804 ("You're an All Star") on a Grandstream GXP 1625 and enjoyed the system we had set up.
The system was later upgraded with many audio snippets and also the ability to do conference bridges (70x numbers) without authentication to the server.
## Installation
It's arch. Good luck.
```
pacman -Syu asterisk
```
Copy config files from Asterisk config folder.
Be sure to configure the interface for VLAN 5 as a DHCP server (use the dhcpd4 package for this) as well as using iptables to provide NAT to that interface.
Proposed change: This system uses it's own host based firewall, and would be suitable to put on VLAN 3 as it has a passthrough in the Ziltoid rules. It also uses UDP and does UDP blocks which are inefficient on Ziltoid.

24
docs/network/ziltoid.md

@ -1,5 +1,29 @@
# Ziltoid
Ziltoid is a blanket firewall and a gateway server.
## Basic Info
Ziltoid takes traffic from the VLAN 3 (public vlan) and sends data over to VLAN 2 (private vlan) while applying a set of firewall rules.
The configuration files are [version controlled on the COSI Git Server](https://gitea.cslabs.clarkson.edu/COSI_Sysadmins/firewall) using a private repository (so that outside actors can't find the rules).
There are instructions contained in the repo, but basically there is a special shell script that takes the rules from the Git server and applies them.
There are also some proposed upgrades on the Git repo to make the service more foolproof, as administration of the firewall can be complicated.
## History
COSI's network (as late as Summer 2015, there was a VLAN tagged network with a gateway box before 2014 IIRC) up until 2016 was a flat VLAN that had all the servers on it, and no firewall except a few host firewalls using `/etc/hosts.allow` and `/etc/hosts.deny` (which is pretty abysmal security practice and caused multiple security incursions, such as the "Stack-Stack" incident).
On March 25, 2016, Ziltoid was completed and brought online. It used a 4 port NIC card - one port was the uplink, one port was to the COSI private network (now VLAN 2), and another one had a 10.x.x.x network to the Tor Exit Node (which has since been removed after the service was deprecated).
In 2017 at some point, Ziltoid's hardware was upgraded as part of the 10G upgrade project, the NIC was changed from the 4 port PCIe NIC to a 2 port 10G SPF+ Intel PCIe NIC. This allows full line-speed 10G network traffic through the firewall.
## Installation
It's running Ubuntu 18.04 LTS. Not too complex a system, it just bridges the two networks together and has `iptables-presistent` installed, plus some special configuration files and shell scripts to aid in system administration and system security.
!!! Warning
Ziltoid's performance will be greatly reduced if you do UDP filtering on it. Only do TCP firewall rules and firewall UDP on each VM if you need firewalls on UDP (typically not used for most services).

10
docs/storage/bacon.md

@ -1,5 +1,15 @@
# Bacon
It's a storage and Kerberos server. It also hosts [cslabs.clarkson.edu](https://cslabs.clarkson.edu) and is our main "email" server.
## Basic Info
Bacon is used for homedirs and Kerberos. It has all of the PXE images on it, provides the COSI website, and also has been used as a general purpose box, IRC bouncer, and jump host.
## History
Originally named Metapod (aka Meatpod), it was the only server not re-installed in Summer 2015 as part of the infrastructure overhauls, due to the system complexity and using BSD as an OS. In September 2016, it was reinstalled with a debian based distro by Bobby and others, making the system more accessible to use.
## Installation
Oh boy.

14
docs/storage/elephant.md

@ -1,5 +1,19 @@
# Elephant
Warm Backup server
## Basic Info
Elephant has a bunch of storage space for backing up important COSI stuff. It is the warm backup server ([Uncle Deadly](uncle-deadly.md) is the cold backup server).
## History
Created in Fall 2016 as a project by Baha. Barely finished and scrapped soon after, but still occasionally has hand-copied backups put on it.
## Installation
It's OpenSUSE with some shell scripts.
Consider replacing with AWS Glacier Deep Storage for the most treasured COSI stuff? It's cheap and would preserve COSI history relatively cheaply on tape while costing us the least investment over time.
This has been proposed before when Elephant was implemented.

10
docs/storage/uncle-deadly.md

@ -1,5 +1,15 @@
# Uncle-Deadly
Cold Backup server
## Basic Info
Uncle Deadly has a bunch of storage space for backing up important COSI stuff. It is the cold backup server ([Elephant](elephant.md) is the warm backup server).
## History
Created a bit after Elephant by Bobby.
## Installation
It's OpenSUSE with some shell scripts.

8
docs/web/docs.md

@ -1,5 +1,13 @@
# Docs
Old documentation server.
## Basic Info
It runs Mediawiki, probably a super outdated version. Crashes all the time, just need a reboot here and there.
## History
This is the fourth incarnation of "web" servers (this is called `web4`) which have hosted the COSI documentation. The database goes back as far as 2007 and is quite a mess. Many proposals have been made to convert it to Git, and perhaps this time it will actually happen.
## Installation

8
docs/web/dubsdot.md

@ -1,5 +1,13 @@
# Dubsdot
Web server.
## Basic Info
It's a web server. It uses Apache. It's often a dumpster fire of webdev in various stages.
## History
Commissioned in 2016 by Ben Lannon.
## Installation

5
docs/web/gitea.md

@ -1,5 +1,10 @@
# Gitea
It's a Git server.
## Basic Info
## History
Created by Jared after moving away from a Gogs server, and before that, a GitLab server (which was quite a pain).
## Installation
Loading…
Cancel
Save