Compare commits
No commits in common. "fyp_procedures" and "main" have entirely different histories.
fyp_proced
...
main
23 changed files with 26 additions and 809 deletions
3
.githooks/post-checkout
Executable file
3
.githooks/post-checkout
Executable file
|
|
@ -0,0 +1,3 @@
|
||||||
|
#!/bin/sh
|
||||||
|
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-checkout' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks').\n"; exit 2; }
|
||||||
|
git lfs post-checkout "$@"
|
||||||
3
.githooks/post-commit
Executable file
3
.githooks/post-commit
Executable file
|
|
@ -0,0 +1,3 @@
|
||||||
|
#!/bin/sh
|
||||||
|
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-commit' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks').\n"; exit 2; }
|
||||||
|
git lfs post-commit "$@"
|
||||||
3
.githooks/post-merge
Executable file
3
.githooks/post-merge
Executable file
|
|
@ -0,0 +1,3 @@
|
||||||
|
#!/bin/sh
|
||||||
|
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-merge' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks').\n"; exit 2; }
|
||||||
|
git lfs post-merge "$@"
|
||||||
4
.githooks/pre-commit
Executable file
4
.githooks/pre-commit
Executable file
|
|
@ -0,0 +1,4 @@
|
||||||
|
#!/usr/bin/env bash
|
||||||
|
|
||||||
|
tar czf _git.tar.gz --exclude .git/lfs .git
|
||||||
|
git add _git.tar.gz
|
||||||
3
.githooks/pre-push
Executable file
3
.githooks/pre-push
Executable file
|
|
@ -0,0 +1,3 @@
|
||||||
|
#!/bin/sh
|
||||||
|
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'pre-push' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks').\n"; exit 2; }
|
||||||
|
git lfs pre-push "$@"
|
||||||
BIN
_git.tar.gz
(Stored with Git LFS)
Normal file
BIN
_git.tar.gz
(Stored with Git LFS)
Normal file
Binary file not shown.
|
|
@ -19,6 +19,8 @@
|
||||||
packages = with pkgs.python3Packages; [
|
packages = with pkgs.python3Packages; [
|
||||||
mkdocs
|
mkdocs
|
||||||
mkdocs-material
|
mkdocs-material
|
||||||
|
mkdocs-git-authors-plugin
|
||||||
|
mkdocs-git-revision-date-localized-plugin
|
||||||
];
|
];
|
||||||
in {
|
in {
|
||||||
formatter = alejandra.defaultPackage.${system};
|
formatter = alejandra.defaultPackage.${system};
|
||||||
|
|
@ -26,7 +28,7 @@
|
||||||
name = "skynet-wiki";
|
name = "skynet-wiki";
|
||||||
src = self;
|
src = self;
|
||||||
buildInputs = packages;
|
buildInputs = packages;
|
||||||
buildPhase = "mkdocs build";
|
buildPhase = "tar -zxf _git.tar.gz && mkdocs build";
|
||||||
installPhase = "mkdir -p $out; cp -R site/* $out;";
|
installPhase = "mkdir -p $out; cp -R site/* $out;";
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -25,10 +25,10 @@ theme:
|
||||||
view: material/eye
|
view: material/eye
|
||||||
plugins:
|
plugins:
|
||||||
- search
|
- search
|
||||||
# - git-authors:
|
- git-authors:
|
||||||
# show_email_address: false
|
show_email_address: false
|
||||||
# - git-revision-date-localized:
|
- git-revision-date-localized:
|
||||||
# enable_creation_date: true
|
enable_creation_date: true
|
||||||
markdown_extensions:
|
markdown_extensions:
|
||||||
- tables
|
- tables
|
||||||
- pymdownx.caret
|
- pymdownx.caret
|
||||||
|
|
|
||||||
|
|
@ -1,78 +0,0 @@
|
||||||
# Change Admins
|
|
||||||
A Skynet Admin is a user with teh highest level of access to the cluster, having been trained up over a year.
|
|
||||||
This guide will cover adding and removing an Admin.
|
|
||||||
|
|
||||||
The normal Committee Member process applies to them as well, so check [here](committee_modify.md#adding) for teh specific details.
|
|
||||||
|
|
||||||
A user cannot add or remove themselves from being an admin, an existing admin must do so (one who will still be admin after the procedure).
|
|
||||||
|
|
||||||
## Add
|
|
||||||
Steps to add a new Admin
|
|
||||||
|
|
||||||
### NixOS
|
|
||||||
There are several steps related to the NixOS repo on Forgejo.
|
|
||||||
|
|
||||||
#### Username Added
|
|
||||||
Like a normal committee member the users username must be added to the [``config/users.nix``][users.nix], specifically the admin section.
|
|
||||||
This gives teh user teh correct Skynet roles on our services.
|
|
||||||
This also enables them to use their personal account to login to all the servers.
|
|
||||||
|
|
||||||
#### SSH Key
|
|
||||||
##### Root Account
|
|
||||||
There is a ``root`` account that admins can use.
|
|
||||||
To be able to login as root you have to add you key to the keys for ``root``
|
|
||||||
|
|
||||||
You can add it in the [``machines/_base.nix``][base.nix].
|
|
||||||
|
|
||||||
##### Secrets Management
|
|
||||||
We store our secrets encrypted in the repo using a tool called ``agenix``, a nix implementation of [age][age].
|
|
||||||
In order to create/edit any secret your key has to be added to [``secrets/secrets.nix``][secrets.nix].
|
|
||||||
|
|
||||||
Add the key mimicking the format for the other admins.
|
|
||||||
Then add it to the users list/array.
|
|
||||||
Finally re-key the secrets
|
|
||||||
|
|
||||||
|
|
||||||
###### Re-key Secrets
|
|
||||||
In order to re-key the secrets your key must have been previously added (this just not work if you have just added your key, an existing admin must do this).
|
|
||||||
|
|
||||||
|
|
||||||
```shell
|
|
||||||
# enter the devshell
|
|
||||||
nix develop
|
|
||||||
|
|
||||||
# Move into teh secrets folder
|
|
||||||
cd secrets
|
|
||||||
|
|
||||||
# Re-key the secrets
|
|
||||||
agenix -R
|
|
||||||
```
|
|
||||||
|
|
||||||
Then commit the changes.
|
|
||||||
|
|
||||||
### VPN
|
|
||||||
The VPN is what allows admins to get access to the internal parts of teh cluster when not on campus.
|
|
||||||
It is provided by ITD.
|
|
||||||
|
|
||||||
1. Add an entry to the bottom of [``ITD/VPN_Admins.csv``][VPN_Admins.csv]
|
|
||||||
2. Add an entry to [``ITD/VPN_Admins_changes.csv``][VPN_Admins_changes.csv] with ``Pending`` for teh Action.
|
|
||||||
3. Open up a [TopDesk request with ITD](./topdesk.md) to add the new Admin.
|
|
||||||
4. Add the ticket reference to [``ITD/VPN_Admins_changes.csv``][VPN_Admins_changes.csv]
|
|
||||||
5. When complete mark the entry ``Added`` on [``ITD/VPN_Admins_changes.csv``][VPN_Admins_changes.csv].
|
|
||||||
|
|
||||||
## Remove
|
|
||||||
For teh most part the removal/retirement of an admin is just the opposite of the adding.
|
|
||||||
The main difference is contacting ITD to remove them from the VPN.
|
|
||||||
|
|
||||||
### VPN
|
|
||||||
1. Open up a TopDesk request with ITD to remove the old Admin.
|
|
||||||
2. Add the ticket reference to [``ITD/VPN_Admins_changes.csv``][VPN_Admins_changes.csv]
|
|
||||||
3. When complete mark the entry ``Removed`` on [``ITD/VPN_Admins_changes.csv``][VPN_Admins_changes.csv].
|
|
||||||
|
|
||||||
|
|
||||||
[users.nix]: https://forgejo.skynet.ie/Skynet/nixos/src/commit/b46eca16b0b207d14e173d4e40286160749c5c07/config/users.nix#L76
|
|
||||||
[base.nix]: https://forgejo.skynet.ie/Skynet/nixos/src/commit/b46eca16b0b207d14e173d4e40286160749c5c07/machines/_base.nix#L75
|
|
||||||
[secrets.nix]: https://forgejo.skynet.ie/Skynet/nixos/src/commit/b46eca16b0b207d14e173d4e40286160749c5c07/secrets/secrets.nix#L3-L18
|
|
||||||
[VPN_Admins.csv]: https://forgejo.skynet.ie/Skynet/nixos/src/commit/b46eca16b0b207d14e173d4e40286160749c5c07/ITD/VPN_Admins.csv
|
|
||||||
[VPN_Admins_changes.csv]: https://forgejo.skynet.ie/Skynet/nixos/src/commit/b46eca16b0b207d14e173d4e40286160749c5c07/ITD/VPN_Admins_changes.csv
|
|
||||||
[age]: https://github.com/FiloSottile/age
|
|
||||||
|
|
@ -1,95 +0,0 @@
|
||||||
# Alumni Verification
|
|
||||||
We are an old Society (1992-<span id="year">now</span>) with a long history of members staying members long after they leave UL.
|
|
||||||
In 2023 we had an outage ([see here for more information][outage_2023]) which lead to us loosing contact with many of these since their contact details were their Skynet email.
|
|
||||||
We are also required to ensure that all active Skynet accounts are linked to a UL Computer Society membership.
|
|
||||||
This put us in the catch22, where folks needed their Skynet account in order to gain access to their Skynet account.
|
|
||||||
|
|
||||||
Many of these people want to regain access to their accounts and will make a request for help.
|
|
||||||
|
|
||||||
## How to process Requests
|
|
||||||
These requests to gain access to an old Skynet account may come in through one of our Email addresses (``contact@skynet.ie``) or from our [Discord][discord]
|
|
||||||
|
|
||||||
### Email
|
|
||||||
Keep an eye on the inboxes ye have access to.
|
|
||||||
Ensure that you have set up the aliases correctly (TODO: Email Aliases).
|
|
||||||
Aside from that be polite.
|
|
||||||
|
|
||||||
### Discord
|
|
||||||
Generally users will bring up their query in ``help-and-support``.
|
|
||||||
It is recommended that you create a Private thread and ping them to bring them into it.
|
|
||||||
This ensures that no private information will leak out.
|
|
||||||
|
|
||||||
#### How to create a Private Thread
|
|
||||||
|
|
||||||
1. Bottom left there is a Plus icon, click on that and select the ``Thread`` option.
|
|
||||||
|
|
||||||
2. In teh segment that popped up tick the Private Thread checkbox.
|
|
||||||
|
|
||||||
|
|
||||||
## The user recovers their own account.
|
|
||||||
The easiest way is that the user can recover their own account.
|
|
||||||
This works if they know their own username/password.
|
|
||||||
See [Account Recovery here][account_recovery] for more details.
|
|
||||||
|
|
||||||
If the user's account is old enough that the password is hashed with CRYPT then tehy will be unable to reset it themselves (even if they know teh password).
|
|
||||||
This is due to CRYPT being specific to the *machine* it is on, and the LDAP server has moved several times since in the last two decades.
|
|
||||||
In which case check out the following methods.
|
|
||||||
|
|
||||||
## Check if there is ``.forward``
|
|
||||||
A ``.forward`` file was placed in a users home directory to forward all incoming mail to that address.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
USER="username"
|
|
||||||
|
|
||||||
# Output a list of paths if one exists for this user
|
|
||||||
find /skynet_old/{mailconfig,home}/$USER-name '.forward'
|
|
||||||
|
|
||||||
# use cat to output the contents to teh terminal
|
|
||||||
cat /skynet_old/mailconfig/$USER/.forward
|
|
||||||
```
|
|
||||||
|
|
||||||
### Usernames
|
|
||||||
One possible contents of the file is one or more Skynet usernames.
|
|
||||||
|
|
||||||
These are not too useful for our use case.
|
|
||||||
```
|
|
||||||
usera
|
|
||||||
userb
|
|
||||||
```
|
|
||||||
|
|
||||||
### Email(s)
|
|
||||||
What we are looking for is an email (identity) to tie the Skynet account to.
|
|
||||||
In which case you can check with the user that they still have access to teh email.
|
|
||||||
Get them to send you a mail from that account and verify the headers (TODO: Email headers)
|
|
||||||
```
|
|
||||||
username@example.com
|
|
||||||
```
|
|
||||||
|
|
||||||
## Find a link to Personal Email
|
|
||||||
Nothing in the ``.forwards`` or they no longer have access to the email its time to see if you can tie their current identity to skynet.
|
|
||||||
This is mostly possible since many members used to send mail between their Skynet account and their private account.
|
|
||||||
|
|
||||||
SSH into ``skynet.skynet.ie`` and run:
|
|
||||||
```shell
|
|
||||||
EMAIL="email@example.ie"
|
|
||||||
USER="username"
|
|
||||||
grep -r "$EMAIL" /skynet_old/{home,mail,mailconfig}/$USER
|
|
||||||
```
|
|
||||||
It may take a while to run depending on the contents of these folders.
|
|
||||||
in some cases they may have proof of their ID, in which case you can search for that.
|
|
||||||
|
|
||||||
Honestly the output of this is vibes based.
|
|
||||||
If there are forwarded email headers its a strong indication.
|
|
||||||
If a file in their ``public_html`` shows up that is also a strong indication.
|
|
||||||
The easiest one is if nothing pops up.
|
|
||||||
|
|
||||||
Remember you are the guardian of data on Skynet, if a user cannot prove a connection you are not obligated to grant them access.
|
|
||||||
|
|
||||||
[outage_2023]: ../support/recovery.md
|
|
||||||
[discord]: https://discord.skynet.ie
|
|
||||||
[account_recovery]: ../../support/recovery#account-recovery
|
|
||||||
|
|
||||||
<script>
|
|
||||||
/* I am a lazy fucker */
|
|
||||||
document.getElementById('year').textContent = new Date().getFullYear().toString()
|
|
||||||
</script>
|
|
||||||
BIN
src/procedures/alumni_verify/plus_icon.png
(Stored with Git LFS)
BIN
src/procedures/alumni_verify/plus_icon.png
(Stored with Git LFS)
Binary file not shown.
BIN
src/procedures/alumni_verify/private_thread.png
(Stored with Git LFS)
BIN
src/procedures/alumni_verify/private_thread.png
(Stored with Git LFS)
Binary file not shown.
|
|
@ -1,48 +0,0 @@
|
||||||
# Change Committee Members
|
|
||||||
This page covers the adding and removing of UL Computer Society committee members.
|
|
||||||
|
|
||||||
## Adding
|
|
||||||
Before starting the committee member in question *must* have a Skynet Account.
|
|
||||||
This is because we have several services that require authentication to access.
|
|
||||||
Details on how to create one can be found [here][skynet_account_creation].
|
|
||||||
|
|
||||||
Once they have an account add their username to [``config/users.nix``][users.nix].
|
|
||||||
Then commit and push.
|
|
||||||
|
|
||||||
Once everything is deployed they should have access to all resources within 15 min.
|
|
||||||
If you require it sooner than that see the [Force Update](#force-update) section below.
|
|
||||||
|
|
||||||
Next checkout the page on [VaultWarden](vaultwarden.md) to add the user to the password manager.
|
|
||||||
|
|
||||||
## Removing
|
|
||||||
Removing is essentially the same as adding.
|
|
||||||
|
|
||||||
Remove their username to [``config/users.nix``][users.nix].
|
|
||||||
Then commit and push.
|
|
||||||
|
|
||||||
## Force Update
|
|
||||||
If you need to hasten an update you can log into teh server to give it a (virtual) kick.
|
|
||||||
|
|
||||||
### SSH into Kitt
|
|
||||||
Kit is teh home of the user accounts.
|
|
||||||
```shell
|
|
||||||
ssh root@kitt.skynet.ie
|
|
||||||
```
|
|
||||||
### Once attached run these commands
|
|
||||||
```shell
|
|
||||||
# reboot the main process
|
|
||||||
systemctl restart skynet_ldap_backend.service
|
|
||||||
|
|
||||||
# Update the data (this ensures that folks are current members)
|
|
||||||
systemctl restart skynet_ldap_backend-update_data.service
|
|
||||||
|
|
||||||
# Apply the new group roles
|
|
||||||
systemctl restart skynet_ldap_backend-update_groups.service
|
|
||||||
```
|
|
||||||
### Exit the terminal.
|
|
||||||
```shell
|
|
||||||
quit
|
|
||||||
```
|
|
||||||
|
|
||||||
[skynet_account_creation]: ../tutorials/skynet/create_account.md
|
|
||||||
[users.nix]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/config/users.nix#L52
|
|
||||||
|
|
@ -1,19 +0,0 @@
|
||||||
# Renewing Domains
|
|
||||||
|
|
||||||
While ``skynet.ie`` is sponsored by Blacknight (and we have one more from UL) we still have ``ulcompsoc.ie`` as a backup.
|
|
||||||
It needs renewing every two years and costs roughly €40/year for this.
|
|
||||||
Renewing every two years gives us some breathing space.
|
|
||||||
|
|
||||||
1. [Login][login] to Blacknight
|
|
||||||
* ``username`` and ``password`` are on [Vaultwarden](./vaultwarden.md)
|
|
||||||
2. ``Domains`` > ``My Domains`` > ``ulcompsoc.ie``
|
|
||||||
3. Under ``Actions`` select ``Renew Domain``
|
|
||||||
4. ``Add to Cart`` > ``Checkout``
|
|
||||||
5. In the ``Review & Checkout`` page there are several options to pay.
|
|
||||||
* Card - probably the fastest, you will have to submit an invoice to the Treasurer though. (TODO: Section on how to submit invoices)
|
|
||||||
* Paypal - Same as Card.
|
|
||||||
* Bank Transfer - Possibly the best, talk to Treasurer about this.
|
|
||||||
6. Done
|
|
||||||
|
|
||||||
|
|
||||||
[login]: https://cp.blacknighthosting.com/index.php/login
|
|
||||||
|
|
@ -1,186 +0,0 @@
|
||||||
# Minecraft Server
|
|
||||||
Skynet can host many game servers, however one of the most popular (going back through teh years) is Minecraft.
|
|
||||||
|
|
||||||
## Base Templates
|
|
||||||
The base templates for the servers are called [eggs][eggs].
|
|
||||||
These are basically scripts to setup and run the servers in question.
|
|
||||||
|
|
||||||
These are created by laying other eggs on top of each otehr to create a single config.
|
|
||||||
Bit of a PITA to make.
|
|
||||||
|
|
||||||
### mcsleepingserverstarter-Packwiz-Purpur-Geyser-Floodgate
|
|
||||||
This is the core Minecraft egg and can be found [here][eggs_main].
|
|
||||||
It comprises of several components bodged together
|
|
||||||
|
|
||||||
#### Sleeping Server Starter
|
|
||||||
This is a core component of being able to host multiple servers for multiple Clubs/Socs as it allows us to reduce the footprint of the server when nto so many folks are using it.
|
|
||||||
It listens on Java and Bedrock ports as a low power process and when someone tries to connect it spins up the full server.
|
|
||||||
Coupled with a plugin which shuts down teh server after the last person leaves it is pretty good for keeping resourse useage low.
|
|
||||||
|
|
||||||
#### Packwiz
|
|
||||||
Packwiz is a package/plugin/mod manager for minecraft which is compatible with source control.
|
|
||||||
The main repo for the plugins can be found [here][config_repo], with branches for each server configured with it
|
|
||||||
|
|
||||||
It allows us to have several plugins as a base that can be used by all servers.
|
|
||||||
|
|
||||||
##### Geyser and Floodgate
|
|
||||||
These pair together to allow bedrock players to connect and play with a Java server.
|
|
||||||
Quite useful as this encompasses console players.
|
|
||||||
|
|
||||||
##### ViaVersion
|
|
||||||
This and its partner plugins allow people who dont have the exact right version to match the server to connect.
|
|
||||||
Not perfect but it works pretty well.
|
|
||||||
|
|
||||||
#### Purpur
|
|
||||||
Purpur is a minecraft server which supports plugins.
|
|
||||||
It is a descendant of Paper and Bukkit and can use plugins built for those.
|
|
||||||
|
|
||||||
## Server - New
|
|
||||||
### Create user account
|
|
||||||
On the [admin page][panel_users] create an account for the Club/Soc which is getting the server.
|
|
||||||
Use their UL Wolves email for the email, username can be whatever as long as its descriptive of the Club/Soc.
|
|
||||||
Their role should be ``Server Admin``.
|
|
||||||
|
|
||||||
For password use a random string (I use 42 characters) and then email it to their Wolves address.
|
|
||||||
We are able to reset it in the future if required.
|
|
||||||
|
|
||||||
### Server setup
|
|
||||||
#### Config
|
|
||||||
1. On the [config repo][config_repo] fork off of main and name it after the Club/Soc and push.
|
|
||||||
2. Then on the web version of teh repo find that branch and teh ``pack.toml`` and click into it.
|
|
||||||
3. In the top right hand corner of the file you will see a button called ``raw``, select that.
|
|
||||||
|
|
||||||
4. Copy the link of the page, will be used shortly.
|
|
||||||
|
|
||||||
#### Pelican Setup
|
|
||||||
On Pelican, on the [servers page][panel_servers] create a new server.
|
|
||||||
|
|
||||||
##### Information
|
|
||||||
###### Name
|
|
||||||
Enter teh Club/Soc who is getting it.
|
|
||||||
|
|
||||||
###### Owner
|
|
||||||
Select teh account you created earlier.
|
|
||||||
|
|
||||||
###### Primary Allocation
|
|
||||||
You will need to select the ``+``.
|
|
||||||
For ``IP Address`` select teh ``193.1.99.xyz`` address.
|
|
||||||
For ``Ports`` enter the minecraft port you have chosen, you can see the existing ports on [NixOS][nixos_minecraft]
|
|
||||||
Java ports take the form of ``255XY`` while Bedrock takes ``244XY``, with teh ``XY`` being teh same for both (makes it easier to keep track).
|
|
||||||
|
|
||||||
Once ye have that chosen click on teh ``Next Step``.
|
|
||||||
|
|
||||||
##### Egg Configuration
|
|
||||||
###### Egg
|
|
||||||
Select the ``mcsleepingserverstarter-Packwiz-Purpur-Geyser-Floodgate`` egg.
|
|
||||||
|
|
||||||
###### Packwiz URL
|
|
||||||
Then enter teh URL you copied previously into the input.
|
|
||||||
|
|
||||||
Once ye have that chosen click on teh ``Next Step``.
|
|
||||||
|
|
||||||
##### Environment Configuration
|
|
||||||
###### Memory
|
|
||||||
Set this to be ``Limited`` and between ``8000`` and ``12000``
|
|
||||||
|
|
||||||
Once ye have that chosen click on teh ``Create Server``.
|
|
||||||
|
|
||||||
#### NixOS
|
|
||||||
In NixOS you have to create DNS entries so folks can easily connect to teh server.
|
|
||||||
Location is in [``minecraft.nix``][nixos_minecraft], copy the existing format.
|
|
||||||
|
|
||||||
This will allow players to connect to ``minecraft.$CLUBSOC.games.skynet.ie``, although bedrock players will still need to use the port.
|
|
||||||
|
|
||||||
|
|
||||||
### Server Configuration
|
|
||||||
#### Discord
|
|
||||||
TODO: https://essentialsx.net/wiki/Discord-Tutorial.html
|
|
||||||
|
|
||||||
#### ``plugins/voicechat/voicechat-server.properties``
|
|
||||||
(TODO: add more about teh voice port)
|
|
||||||
|
|
||||||
Set teh port for use in teh voice chat.
|
|
||||||
```
|
|
||||||
port=24424
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
#### ``server.properties``
|
|
||||||
|
|
||||||
This is to allow bedrock users to text chat
|
|
||||||
````
|
|
||||||
enforce-secure-profile: false
|
|
||||||
````
|
|
||||||
|
|
||||||
#### ``plugins/Geyser-Spigot/config.yml``
|
|
||||||
Set the bedrock port
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
bedrock:
|
|
||||||
port: 24423
|
|
||||||
```
|
|
||||||
|
|
||||||
Also set the authtype to be ``floodgate``
|
|
||||||
```yaml
|
|
||||||
remote:
|
|
||||||
auth-type: floodgate
|
|
||||||
```
|
|
||||||
|
|
||||||
#### ``sleepingSettings.yml``
|
|
||||||
Bedrock port needs to be added to this file:
|
|
||||||
```yaml
|
|
||||||
bedrockPort: 24423
|
|
||||||
```
|
|
||||||
|
|
||||||
## Server - Update
|
|
||||||
|
|
||||||
### Plugins Modification
|
|
||||||
#### DevShell
|
|
||||||
In the [config repo][config_repo] run this command to enter teh devshell which gives you access to ``packwiz``:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
nix develop
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Add
|
|
||||||
Once in the devshell use the add command to add a plugin.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
packwiz modrinth add $LinkToModrinthPlugin
|
|
||||||
```
|
|
||||||
|
|
||||||
Commit and push.
|
|
||||||
|
|
||||||
#### Update
|
|
||||||
To update all plugins you can use this command
|
|
||||||
```shell
|
|
||||||
packwiz update --all
|
|
||||||
```
|
|
||||||
Commit and push.
|
|
||||||
|
|
||||||
#### Remove
|
|
||||||
To remove a plugin just delete the ``*.pw.toml``.
|
|
||||||
Then run the refresh command to update teh pack
|
|
||||||
```shell
|
|
||||||
packwiz refresh
|
|
||||||
```
|
|
||||||
Commit and push.
|
|
||||||
|
|
||||||
### Server Update
|
|
||||||
Now that teh pack has been updated you need to restart teh server to pull it in.
|
|
||||||
|
|
||||||
1. ``Stop`` the server
|
|
||||||
* This stops the java server, does not start teh ``sleepingserverstarter`` server.
|
|
||||||
2. ``Kill`` the server
|
|
||||||
* This stops the ``sleepingserverstarter`` server.
|
|
||||||
3. ``Start`` the server
|
|
||||||
* This restarts everything and pulls in teh updates.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
[eggs]: https://panel.games.skynet.ie/admin/eggs
|
|
||||||
[eggs_main]: https://panel.games.skynet.ie/admin/eggs/22/edit?tab=-configuration-tab
|
|
||||||
[config_repo]: https://forgejo.skynet.ie/silver/Testing_packwiz
|
|
||||||
[panel_users]: https://panel.games.skynet.ie/admin/users
|
|
||||||
[panel_servers]: https://panel.games.skynet.ie/admin/servers
|
|
||||||
[nixos_minecraft]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/applications/games/minecraft.nix#L27
|
|
||||||
BIN
src/procedures/minecraft/raw_file.png
(Stored with Git LFS)
BIN
src/procedures/minecraft/raw_file.png
(Stored with Git LFS)
Binary file not shown.
|
|
@ -1,37 +0,0 @@
|
||||||
# Proxmox
|
|
||||||
A collection of all things proxmox related.
|
|
||||||
|
|
||||||
## Access
|
|
||||||
Proxmox can be found at [``193.1.99.73:8006``][webgui] when either on UL network or connected to the [VPN][vpn].
|
|
||||||
Login with your Skynet account.
|
|
||||||
The ``root`` account can be found on [Vaultwarden][vaultwarden].
|
|
||||||
|
|
||||||
If you are on Firefox you may need to refresh teh page if the ``No Valid Subscription`` popup fails to disappear after clicking ``ok``.
|
|
||||||
|
|
||||||
## Rebooting
|
|
||||||
### LCX's
|
|
||||||
For some LXC's (haven't tracked down teh root cause) their MAC address has issues when they reboot.
|
|
||||||
If you are trying to ssh into a LXC which has rebooted it can display ``No route to host``.
|
|
||||||
To fix:
|
|
||||||
|
|
||||||
1. [Login to Proxmox](#access)
|
|
||||||
2. Navigate to the LXC
|
|
||||||
3. Network tab, then double click on the network row.
|
|
||||||
* Clicking the row then the ``Edit`` button has teh same function.
|
|
||||||
4. Clear the MAC (so it reads ``auto``) then ``Save``
|
|
||||||
|
|
||||||
You will be able to ssh into that server now.
|
|
||||||
|
|
||||||
### Proxmox
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
[webgui]: https://193.1.99.73:8006/
|
|
||||||
[vpn]: ./admin_modify.md#vpn
|
|
||||||
[vaultwarden]: ./vaultwarden.md
|
|
||||||
|
|
||||||
|
|
@ -1,178 +0,0 @@
|
||||||
# New Server (LXC)
|
|
||||||
|
|
||||||
This is the instruction guide for setting up a new LXC server.
|
|
||||||
|
|
||||||
Rough steps are as follows:
|
|
||||||
1. Plan the servers config
|
|
||||||
2. Login to Proxmox
|
|
||||||
3. Create Container using the base LXC image
|
|
||||||
4. Login to Server
|
|
||||||
5. Push new configuration
|
|
||||||
|
|
||||||
## Plan server Configuration
|
|
||||||
To allocate he correct resources there are a few questions that need to be asked and answered.
|
|
||||||
|
|
||||||
1. What will this server be **For**?
|
|
||||||
2. What will its **Name** be?
|
|
||||||
3. What will its **IP** be?
|
|
||||||
4. Fill the details into the tracking sheet.
|
|
||||||
|
|
||||||
### What is it **For**?
|
|
||||||
What a server is for dictates what hardware resources need to be allocated.
|
|
||||||
Is there one already existing that you can copy the configuration of?
|
|
||||||
Do you have prior experience with what will be hosted on it?
|
|
||||||
Is there documentation that you can use as a foundation?
|
|
||||||
|
|
||||||
When you know these, write it down and save for later.
|
|
||||||
|
|
||||||
### What is its **Name**?
|
|
||||||
In our cluster we have a very definite naming scheme for the servers we have.
|
|
||||||
There are two rules:
|
|
||||||
|
|
||||||
1. The login server (where folks have their home dirs and websites) is called Skynet.
|
|
||||||
* [This can be traced back to 2007][server_name_skynet]
|
|
||||||
* > By popular demand, the skynet name was retained for the login server
|
|
||||||
2. All other servers are also named after AI's
|
|
||||||
|
|
||||||
|
|
||||||
In the current cluster we tend to use groups of AI names for particular functions.
|
|
||||||
For example:
|
|
||||||
|
|
||||||
* Vigil/Vendetta were AI's in the Mass effect series, pointing Shepherd forward, so they are our DNS servers
|
|
||||||
* Glados/Wheatly from Portal, that game runs on the Source Engine, so they are our Source control servers
|
|
||||||
* Optimus/Bumblebee from Transformers, their origin is a line of toys, so fittingly our games servers.
|
|
||||||
* Neuromancer/Wintermute, from Neuromancer, each with multiple minds, thus became our backup (redundancy) servers.
|
|
||||||
|
|
||||||
If at all possible try to get the name to match its task.
|
|
||||||
Some past names and ideas for others can be found on [the nixos wiki][server_names]
|
|
||||||
|
|
||||||
|
|
||||||
### What is its **IP** address?
|
|
||||||
We have a ``/26`` allocation, so about 60 IP's we can make use of.
|
|
||||||
Like with the names above several servers are grouped together IP wise.
|
|
||||||
Check the [Server Inventory][server_inventory] to see what addresses are available.
|
|
||||||
|
|
||||||
### Tracking sheet
|
|
||||||
Now that ye have all the details about the build it is time to add them to the [Server Inventory][server_inventory].
|
|
||||||
Add a new one, incrementing the index, and fill in the rest of the information.
|
|
||||||
|
|
||||||
For the IP address if the last segment (ABC in this: 193.1.99.ABC) is less than 100 then add a leading ``0`` to it.
|
|
||||||
This is so that it can be easily sorted.
|
|
||||||
|
|
||||||
## Login to Proxmox
|
|
||||||
|
|
||||||
[Login to Proxmox](./proxmox.md#access)
|
|
||||||
|
|
||||||
## Create Container Using the Base LXC Image
|
|
||||||
The Proxmox documentation for LXC's is available [here][proxmox_lxc].
|
|
||||||
|
|
||||||
Top right there is a button [Create CT], that brings up a window.
|
|
||||||
Each section below is one of the tabs in the window.
|
|
||||||
|
|
||||||
### General
|
|
||||||
#### Hostname
|
|
||||||
This is the **Name** of the server, lowercase.
|
|
||||||
#### Unprivileged
|
|
||||||
Ensure this is ticked.
|
|
||||||
#### Nesting
|
|
||||||
Ensure this is ticked.
|
|
||||||
#### SSH Public Keys
|
|
||||||
Enter the ``root`` pub ssh key.
|
|
||||||
This is used to login to teh container later.
|
|
||||||
|
|
||||||
### Template
|
|
||||||
Select the container image, most likely ``nixos-system-x86_64-linux.tar.xz``.
|
|
||||||
|
|
||||||
### Disks
|
|
||||||
#### Storage
|
|
||||||
Most likely it is ``main_pool``, it should have a significant amount of storage available.
|
|
||||||
**DO NOT** use ``local-zfs``, this is on Proxmox's own drive and not suited for container data.
|
|
||||||
|
|
||||||
#### Disk Size
|
|
||||||
Self-explanatory, how much space you want to give teh container.
|
|
||||||
A minimum of 30Gb is suggested.
|
|
||||||
|
|
||||||
### CPU
|
|
||||||
One core minimum, larger servers will require up to 6 or so.
|
|
||||||
|
|
||||||
### Memory
|
|
||||||
Nixos will happily run on 512Mb if its load is not too intensive
|
|
||||||
|
|
||||||
### Network
|
|
||||||
#### Bridge
|
|
||||||
The main bridge we use is ``vmbr0`` which is for most servers as it connects to the normal Skynet DMZ.
|
|
||||||
|
|
||||||
We also have ``vmbr1`` which is for ``skynet.skynet.ie`` and connects to Skynet-EXT DMZ.
|
|
||||||
This is due to our users needing ssh access.
|
|
||||||
|
|
||||||
#### IPv4
|
|
||||||
##### IPv5/CIDR
|
|
||||||
This is the **IP** followed by ``/26``.
|
|
||||||
For example ``193.1.99.75/26``
|
|
||||||
|
|
||||||
##### Gateway
|
|
||||||
The main gateway we use is ``193.1.99.65``.
|
|
||||||
There is a secondary one for ``skynet.skynet.ie`` which is ``193.1.96.161``.
|
|
||||||
|
|
||||||
### DNS
|
|
||||||
You can either use ``use host settings`` or fill in ``193.1.99.120`` and ``193.1.99.109``.
|
|
||||||
|
|
||||||
### Confirm
|
|
||||||
Use this as a chance to review all the options.
|
|
||||||
There are a few gotcha's outlined above that ye do have to look over.
|
|
||||||
|
|
||||||
#### Start after created
|
|
||||||
Tick this box if you want it to boot up immediately after being installed.
|
|
||||||
|
|
||||||
## Login to Server
|
|
||||||
Now that the server is up and running it is time to login to it.
|
|
||||||
Assuming you have your SSH configured like (TODO: admin ssh config).
|
|
||||||
You just have to use ``ssh root@IP`` (for example ``ssh root@192.99.1.111``)
|
|
||||||
|
|
||||||
### Getting the server ssh key
|
|
||||||
We are logging in because we need to get the servers own ssh key.
|
|
||||||
You can find it in ``/etc/ssh``.
|
|
||||||
You have a choice between ``ssh_host_ed25519_key.pub`` and ``ssh_host_rsa_key.pub``.
|
|
||||||
``ssh_host_ed25519_key.pub`` is the recommended one.
|
|
||||||
|
|
||||||
### Using the server ssh key
|
|
||||||
This key is used to decrypt secrets stored in our Nixos repo and as such needs to be added there.
|
|
||||||
1. Add the key with the other system keys [here][nixos_secrets].
|
|
||||||
2. Add it to the systems array underneath that.
|
|
||||||
3. In the ``secrets`` folder run ``cd secrets && agenix -r`` to rekey the secrets.
|
|
||||||
* This is to give the new server access.
|
|
||||||
4. Commit all the changed files
|
|
||||||
|
|
||||||
|
|
||||||
## Push new configuration
|
|
||||||
### Create config
|
|
||||||
An example server config for nixos is [available here][nixos_template].
|
|
||||||
Copy it to a new file and name it ``name.nix``.
|
|
||||||
Fill in all relevant details (name/ip/name details/its purpose/...).
|
|
||||||
|
|
||||||
Finally add it to the bottom of the [``flake.nix``][nixos_flake].
|
|
||||||
Save and commit the files.
|
|
||||||
|
|
||||||
### Push Config
|
|
||||||
There are two ways to test out the config, manual and pipeline.
|
|
||||||
Each has pros and cons.
|
|
||||||
|
|
||||||
#### Manually
|
|
||||||
This requires your key to be added the the keys for the [root account][nixos_root] and your ``~/.ssh/config`` to be set up properly (TODO: SSH tutorial)
|
|
||||||
|
|
||||||
1. Build it with ``colmena build --on name``
|
|
||||||
2. If it builds ye can test deployment
|
|
||||||
3. Deploy it using ``colmena apply --on name``
|
|
||||||
|
|
||||||
#### Pipeline
|
|
||||||
Just push it to the repo and the pipeline will handle building and deployment.
|
|
||||||
The disadvantage of this is you cannot fix any mistakes before they are pushed.
|
|
||||||
|
|
||||||
[server_name_skynet]: https://2009.skynet.ie/history.html
|
|
||||||
[server_names]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/Possible_Server_Names.md
|
|
||||||
[server_inventory]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/ITD/Server_Inventory.csv
|
|
||||||
[proxmox_lxc]: https://pve.proxmox.com/wiki/Linux_Container
|
|
||||||
[nixos_secrets]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/secrets/secrets.nix#L35
|
|
||||||
[nixos_template]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/machines/_template.nix
|
|
||||||
[nixos_flake]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/flake.nix#L156
|
|
||||||
[nixos_root]: https://forgejo.skynet.ie/Skynet/nixos/src/branch/main/machines/_base.nix#L75
|
|
||||||
|
|
@ -1,84 +0,0 @@
|
||||||
# Updating Servers (NixOS)
|
|
||||||
A short guide on how to update NixOS servers.
|
|
||||||
This is required at least once a semester in order to keep the systems up to date.
|
|
||||||
|
|
||||||
These are some of the easiest servers we have to update.
|
|
||||||
This is how you update it locally, and then deploy.
|
|
||||||
|
|
||||||
## Update
|
|
||||||
Invoke the devshell for the NixOS repo locally on your computer (TODO: Setup nix and into to devshell).
|
|
||||||
This will give you all the tools you need to update the NixOS servers.
|
|
||||||
|
|
||||||
In that shell you can run these commands.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
# this will update every input, sometimes that is not desired
|
|
||||||
nix flake update
|
|
||||||
|
|
||||||
# This will update a single input, nixpkgs which will update the OS's
|
|
||||||
nix flake update nixpkgs colmena
|
|
||||||
|
|
||||||
# Update multiple at once, these are the core tools and utilities
|
|
||||||
# Recommended command
|
|
||||||
nix flake update nixpkgs flake-utils agenix arion alejandra colmena
|
|
||||||
```
|
|
||||||
|
|
||||||
## Build
|
|
||||||
Now that the inputs have been updated it is time to build it locally to ensure no errors pop up.
|
|
||||||
For any errors that pop up you can use ``--key-result`` in order to explore the system output.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
# This will build all the servers locally
|
|
||||||
colmena build
|
|
||||||
|
|
||||||
# Build a single one
|
|
||||||
colmena build --on glados
|
|
||||||
|
|
||||||
# Build a logical group of them
|
|
||||||
colmena build --on @active-dns
|
|
||||||
|
|
||||||
# Build all but keep the outputs in ``.gcroots``
|
|
||||||
# This is useful if you need to explore the config locally
|
|
||||||
colmena build --keep-result
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
## Deploy
|
|
||||||
It is now time to commit and deploy the updates.
|
|
||||||
|
|
||||||
|
|
||||||
### Manually
|
|
||||||
Most of the flags from the build step above apply for teh deploy step.
|
|
||||||
You dont need to have the files committed to do this, so it cna be useful for testing.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
# This will build all the servers locally
|
|
||||||
colmena deploy
|
|
||||||
|
|
||||||
# Build a single one
|
|
||||||
colmena deploy --on glados
|
|
||||||
|
|
||||||
# Build a logical group of them
|
|
||||||
colmena deploy --on @active-dns
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
### Pipeline
|
|
||||||
To deploy via the pipeline simply commit and push to Forgejo.
|
|
||||||
The pipeline will build and deploy to almost all the servers.
|
|
||||||
Downside of this is slow iteration for testing, but it is useful if you are pretty sure of teh changes.
|
|
||||||
|
|
||||||
#### Git Server/Runner
|
|
||||||
The CI/CD pipelines we have run on Glados and Wheatly, as such the pipelines are not able to update these two servers on their own.
|
|
||||||
These need to be updated manually using any of these commands:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
# This will deploy all the servers
|
|
||||||
colmena deploy
|
|
||||||
|
|
||||||
# Deploy a single one
|
|
||||||
colmena deploy --on glados wheatly
|
|
||||||
|
|
||||||
# Deploy a logical group of them
|
|
||||||
colmena deploy --on @active-git
|
|
||||||
```
|
|
||||||
|
|
@ -1,16 +0,0 @@
|
||||||
# Updating Servers (Proxmox)
|
|
||||||
A short guide on how to update servers running Proxmox VM Host
|
|
||||||
|
|
||||||
There is documentation for Proxmox available on teh [web][docs_web] and locally on teh server [itself][docs_inbuilt].
|
|
||||||
The inbuilt ones are preferred since they match teh version of Proxmox we are using.
|
|
||||||
In both there is a chapter called [``System Software Updates``][docs_inbuilt_update] which tells you how to update.
|
|
||||||
|
|
||||||
When there is a major version released there will be a new link on [this page][docs_wiki] in teh format of:
|
|
||||||
``Upgrade from $VersionCurrent to $VersionNext``
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
[docs_inbuilt]: https://193.1.99.73:8006/pve-docs/pve-admin-guide.html
|
|
||||||
[docs_inbuilt_update]: https://193.1.99.73:8006/pve-docs/pve-admin-guide.html#system_software_updates
|
|
||||||
[docs_web]: https://pve.proxmox.com/pve-docs/pve-admin-guide.html
|
|
||||||
[docs_wiki]: https://pve.proxmox.com/wiki/Category:Upgrade
|
|
||||||
|
|
@ -1,18 +0,0 @@
|
||||||
# Topdesk Tickets
|
|
||||||
UL and ITD uses TopDesk to allow students to submit support tickets to ITD.
|
|
||||||
In our case we mostly use it to open and close ports.
|
|
||||||
ITD also uses it to contact us about any security issues.
|
|
||||||
|
|
||||||
Because we have to keep records, and because Skynet is not a student we cannot use TopDesk teh normal way.
|
|
||||||
|
|
||||||
1. Ensure that you have set up your email aliasing for ``skynet_topdesk[at symbol]skynet.ie``. (TODO: email aliasing)
|
|
||||||
2. Login to your Skynet email account and enable the ``skynet_topdesk[at symbol]skynet.ie`` profile.
|
|
||||||
3. Set ``[Skynet]`` to be the first part of the Subject, the remainder can be about teh contents of teh ticket.
|
|
||||||
4. Set the to address to be``ITD.ServiceDesk[at symbol]ul.ie``.
|
|
||||||
|
|
||||||
Check yer inbox often enough after that, they normally respond within 24hrs and may have some questions.
|
|
||||||
Sometimes they also use it in case their security software captures any issues.
|
|
||||||
|
|
||||||
Additionally if they attach any images/files to the ticket also request that they send it to ``skynet_topdesk[at symbol]skynet.ie``.
|
|
||||||
Because we cannot view the ticket on TopDesk these dont get loaded for us.
|
|
||||||
|
|
||||||
|
|
@ -1,36 +0,0 @@
|
||||||
# Vaultwarden
|
|
||||||
[Vaultwarden][vaultwarden_github] is rust based server implmentation of [Bitwarden][bitwarden_github].
|
|
||||||
One of the core reasons why we went with Vaultwarden over the original Bitwarden is that it gives us access to Org Mode.
|
|
||||||
This allows us to have an organisation with multiple members with access to passwords, as well as controlling their access.
|
|
||||||
|
|
||||||
Additionally we are using [Bitwarden Directory Connector][bitwarden-dc_github] to sync our ldap groups to vaultwarden.
|
|
||||||
This is how Admins and Committee can access the password manager.
|
|
||||||
it also removes folks access once they no longer meet the requirements (be committee or admin).
|
|
||||||
|
|
||||||
Vaultwarden is not available for regular Skynet users since we do not want teh responsibility of managing their passwords, since the cost of failing is so high (for us)
|
|
||||||
|
|
||||||
The instance is available at [``pw.skynet.ie``][pw].
|
|
||||||
|
|
||||||
## Adding Users
|
|
||||||
When a committee member gets [added](committee_modify.mddding) they will become of teh committee LDAP group.
|
|
||||||
When this group is synced with Vaultwarden then that member will get an email to their Skynet account to ``Join UL Computer Society``.
|
|
||||||
|
|
||||||
The member should then click on teh link in that email.
|
|
||||||
They will then have to choose a password to access the password manager, the password tied to their Skynet account does nto sync for security reasons.
|
|
||||||
|
|
||||||
The user will then need to be confirmed in the [organisation panel][pw_org].
|
|
||||||
Once that is complete they will have access to Computer Societies AND/OR Skynet's passwords, depending if they are committee or a Skynet admin.'
|
|
||||||
|
|
||||||
|
|
||||||
## Resending Invites
|
|
||||||
If the user does not accept the invite within a day or so the invite will expire.
|
|
||||||
|
|
||||||
In the [organisation panel][pw_org], to the far right of teh user there is a ``⋮``.
|
|
||||||
Selecting it will give an option to resend the invite.
|
|
||||||
|
|
||||||
|
|
||||||
[vaultwarden_github]: https://github.com/dani-garcia/vaultwarden
|
|
||||||
[bitwarden_github]: https://github.com/bitwarden/server
|
|
||||||
[bitwarden-dc_github]: https://github.com/bitwarden/directory-connector
|
|
||||||
[pw]: https://pw.skynet.ie/
|
|
||||||
[pw_org]: https://pw.skynet.ie/#/organizations/ca0eacc2-988f-4368-b85f-40061eefd453/members
|
|
||||||
Loading…
Reference in a new issue