Fachschaft/nixConfig
5
2
Fork 2
Code Issues 7 Pull requests Projects 1 Wiki Activity

lobon (Mailman-VM) #30

Merged
Gonne merged 5 commits from Gonne/nixConfig:lobon into main 2024-10-12 14:10:02 +00:00
Conversation 3 Commits 5 Files changed 7 +82 -6
4 changed files with 82 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit c5f641cabf - Show all commits

39
nixos/machines/lobon/backupKey.yaml Normal file
View file

@ -0,0 +1,39 @@
backupKey: ENC[AES256_GCM,data:/PErHUVZDTyqK+GKI2inDoEBQpSmezeBTgXWnrthc8IPtUFn4Ur2CkDo+MqfiAlSn9vT2ksHmyS5qmoGANG01e1Cm50qpt/BdoC2hh15jOVuc0uUBNOq7f5YBVeYtbemwjPcmbF7dgUeRlEAvxhqtX3/ntzxSB1inew/SsEgPrU4Yl0FF+CHhqgbeB/NJOhQY29/3hBGwMksfTUDymUmX6pUgIN1M26crIKFCn5IyqAXl10F+zL4PThZPnhmks7Y8BsGUbKkiE6ghdaUjEjBjGOGgbaGAjolG+nJ17xyM1Pc2speT4E/3VgAC34dpaByveGcf2SfsXir0KavcI86mUkjzaNF9u7GjGO0Szn742/aqbdUoOkJl41unb0Enf2/D4Up3fy6LrUqVqrHIM4Dea9WLQd0poD0FWSN12IKh+ylkouMkmhwLXUXFzIHOePS92/MsPM+9fLhH4cU64qxr9UzmfYRnNBpAHrjlxdkK9WZ1Oj4mdtu6R20vYkYcMIQgU38FvSN6uWGvPxJj+Ij,iv:ghvgkC6qFO/0tvsc7igCoZy7am8eNsd21WYCSAKiZDs=,tag:MFnk/Nnw+cloN+x7sd4LLg==,type:str]
nerf marked this conversation as resolved Outdated
nerf commented 2024-04-03 14:05:59 +00:00
Outdated
Review
Copy link

Hmm, I didn't have thought about the following:

Which secrets get different sops files and which go into the same file?
can we put both of this secrets into the same yaml, is this desirable?

Hmm, I didn't have thought about the following: Which secrets get different sops files and which go into the same file? can we put both of this secrets into the same yaml, is this desirable?
Gonne commented 2024-04-04 14:22:20 +00:00
Outdated
Review
Copy link

I think splitting per desired system user is useful (might even be necessary). Apart from that it feels more about conventions which I don't know.

Currently the secrets are used by root and mailman but giving the backup service root-access in itself feels like a mistake.

I think splitting per desired system user is useful (might even be necessary). Apart from that it feels more about conventions which I don't know. Currently the secrets are used by `root` and `mailman` but giving the backup service `root`-access in itself feels like a mistake.
nerf commented 2024-04-04 14:44:36 +00:00
Outdated
Review
Copy link

refactoring the backup process sounds like something, that we should do uniform across all VM. So I think we should do that
in a dedicated pull request. I will open an issue for that. Finding a solution for this is probably out of scope here.

refactoring the backup process sounds like something, that we should do uniform across all VM. So I think we should do that in a dedicated pull request. I will open an issue for that. Finding a solution for this is probably out of scope here.
sops:
kms: []
gcp_kms: []
azure_kv: []
hc_vault: []
age:
- recipient: age1rasjnr2tlv9y70sj0z0hwpgpxdc974wzg5umtx2pnc6z0p05u3js6r8sln
enc: |
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBaNVExTHQrY2h1M3RZOEdU
Wm5kdDBHZ1NmZGpQU0VOYWtjOTdBVURQZkJnCmZzWTEvSWxvMFk4NlFOVnBDbm9q
Tncva0VyMGVDL29ZZ0YxeGE3RFBUS3cKLS0tIDluK05NMUNNM3pEUmlCNE9BV3lT
L0dPYTBwbjJzUmJnYktiM2JBME5LM3cKvPwth4DxQgFYhvr9vJLfeaiNc+UfAo4c
RdXPLkwtq3vksrU1IR54tHcUJ0yZiZ1HxxGp3PCPaXXJiUykllnJPw==
-----END AGE ENCRYPTED FILE-----
- recipient: age1epz92k2rkp43hkrg3u0jgkzhnkwx8y43kag7rvfzwl9wcddelvusyetxl7
enc: |
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBRdFV0OVA5VTBuOVhsL3lp
MFpDN2RHVDExck5vcWpDNDNPM2k3S1FqQUFFCjNreXdSbDFXOHJ4b21mNGlZb0xQ
YUh0WVNGN2o1aFVaaGpxbmk4aUQ4ZTAKLS0tIHhtci84Zk1zZlBOOHk4a3VKUlM1
MXNZbWdpVEJiTTlIRERLYzBlNWxBMlUK4Z8JLlN5FOegfdg5njhHjbCwAm/f+kJS
buOHGWzWirW0ZibOP+fikzJwdIzIsX8v8tGaV89nQwf0hrxK0748Hg==
-----END AGE ENCRYPTED FILE-----
- recipient: age12nz7dtc0m5wasxm4r9crtkgwnzvauyfp0xh0n8z8jld0arn9ea9qe0agvn
enc: |
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBZa2pUZlZsVmhPU242d0Nj
bi9BSlJBU1Q1cFU4ZjA4NnlJNmdwaVFBc2xNCjJlSG5UaDFnSzFHZ01RVVNjOHY5
L1JVUit6SThvbGRIU0loNmtZanllNXcKLS0tIFhMR1pxRmlGQWFEQURiRFJoMWJZ
dlExV2xTVWR6bWI3VCtSdU81SmtqYncKLFQczlIj89vzlfgE33w6ktotYFdxaWr9
YyewbY8qZmOUGQ4xKlZmhojeMh/FEH8dGNEf1AxnKbuQdnW6lqGR/w==
-----END AGE ENCRYPTED FILE-----
lastmodified: "2024-03-31T16:01:00Z"
mac: ENC[AES256_GCM,data:AawTzIXyX+3FyFpw8pXFeVJJtXN7ZpTFnUqhedC2vcbbNUzMMt1X0SaxtNNJ5chZI/tYHn59FT6zznl1eO4Xn29Zc2Up4dkT1BE4yqkEG0hiCFXrXMz/PaHfROzBhIWCVyF4fYj6MZKg1iBBxhWRqhJlQ1q4UVkoaITRUKpFJgs=,iv:3lTPOQ8VjmP3WNGbFK2yLU4Ks1KviNS/l7TH4SnvSUs=,tag:KUbAU6+76/Uxj2Wn9EnqnA==,type:str]
pgp: []
unencrypted_suffix: _unencrypted
version: 3.8.1

15
nixos/machines/lobon/configuration.nix
View file

@ -18,4 +18,19 @@
networking.hostName = "lobon";
vmNetwork.ipv4 = "192.168.0.22";
system.stateVersion = "23.11";
sops.secrets = {
allowlistPass = {
sopsFile = ./allowlistPass.yaml;
owner = "mailman";
group = "mailman";
mode = "0400";
};
backupKey = {
sopsFile = ./backupKey.yaml;
owner = "root";
group = "root";
mode = "0400";
};
};
}

7
nixos/modules/borgbackup.nix
View file

@ -83,6 +83,13 @@ in {
path = "/var/lib/backups/ithaqua";
allowSubRepos = true;
};
lobon = {
authorizedKeysAppendOnly = [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICEptjf1UWRlo6DG9alAIRwkSDUAVHwDKkHC6/DeYKzi Lobon Backup"
];
path = "/var/lib/backups/lobon";
allowSubRepos = true;
};
sanctamariamaterdei = {
authorizedKeysAppendOnly = [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9Le5OI4ympQ0mQKYHmxgxGF598rzpD5VVpWK1mGfd8 Sanctamariamaterdei Backupsystem"

27
nixos/modules/mailman.nix
View file

@ -37,7 +37,7 @@ in {
proxy_interfaces = "130.83.2.184";
smtputf8_enable = "no"; # HRZ does not know SMTPUTF8
Gonne marked this conversation as resolved Outdated
nerf commented 2024-08-18 16:28:44 +00:00
Outdated
Review
Copy link

m(

m(
};
relayHost = "mailout.hrz.tu-darmstadt.de"; # Relay to HRZ (see https://www.hrz.tu-darmstadt.de/services/it_services/email_infrastruktur/index.de.jsp)
relayHost = "192.168.0.24"; # Relay to eihort which relays to HRZ (see https://www.hrz.tu-darmstadt.de/services/it_services/email_infrastruktur/index.de.jsp)
};
mailman = {
enable = true;
@ -60,6 +60,7 @@ in {
"/var/lib/mailman"
"/var/lib/mailman-web"
];
files = ["/root/.ssh/known_hosts"]; # for the backup server bragi
nerf commented 2024-08-18 16:35:34 +00:00
Outdated
Review
Copy link

we could move this to the general vm role, right? Every vm makes backups this way, (or am i missing something?)

we could move this to the general vm role, right? Every vm makes backups this way, (or am i missing something?)
Gonne commented 2024-08-18 20:09:46 +00:00
Outdated
Review
Copy link

Maybe. This is in scope for the backup refactoring.

Maybe. This is in scope for the backup refactoring.
};
security.acme.defaults.email = cfg.siteOwner;
@ -95,11 +96,25 @@ in {
PrivateTmp = true;
nerf commented 2024-04-04 14:01:17 +00:00
Outdated
Review
Copy link

can we set NoNewPrivileges = true;? or does it break the service?

And one could read the Sandboxing part of systemd.exec(5)

can we set `NoNewPrivileges = true;`? or does it break the service? And one could read the Sandboxing part of `systemd.exec(5)`
Gonne commented 2024-04-04 15:19:15 +00:00
Outdated
Review
Copy link

Yes, I added a bunch of them in f334e00d01 that seemed reasonable and don't break the updater. Notably, I left out ExecPaths= and NoExecPaths= because the correct values are unclear to me.

Yes, I added a bunch of them in f334e00d01 that seemed reasonable and don't break the updater. Notably, I left out `ExecPaths=` and `NoExecPaths=` because the correct values are unclear to me.
};
};
sops.secrets.allowlistPass = {
sopsFile = ../machines/lobon/allowlistPass.yaml;
owner = "mailman";
group = "mailman";
mode = "0400";
# Backups
services.borgbackup.jobs.mailman = {
paths = [
"/var/lib/mailman/data"
"/var/lib/mailman-web"
];
encryption.mode = "none"; # Otherwise the key is next to the backup or we have human interaction.
environment = {
BORG_RSH = "ssh -i /run/secrets/backupKey";
# “Borg ensures that backups are not created on random drives that ‘just happen’ to contain a Borg repository.”
# https://borgbackup.readthedocs.io/en/stable/deployment/automated-local.html
# We don't want this in order to not need to persist borg cache and simplify new deployments.
BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK = "yes";
};
repo = "borg@192.168.1.11:lobon"; # TODO for https://gitea.mathebau.de/Fachschaft/nixConfig/issues/33
startAt = "daily";
user = "root";
nerf marked this conversation as resolved Outdated
nerf commented 2024-04-04 14:42:26 +00:00
Outdated
Review
Copy link

This is probably a bigger refactoring pull request and outside the scope of this one.
We could think making it easier configurable that backups are made by a user that can
basically read everything but not write.

This is probably a bigger refactoring pull request and outside the scope of this one. We could think making it easier configurable that backups are made by a user that can basically read everything but not write.
👍 1
group = "root";
};
};
}