allow accessing test vms from fedi201, closes #286 #297
No reviewers
fricklerhandwerk
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fediversity/fediversity!297
Loading…
Reference in a new issue
No description provided.
Delete branch "kiara/fediversity:panel-vm-access-test-vms"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
todo:
b8391591303c0d1478cc3c0d1478cc94420f112fWIP: allow accessing test vms from fedi201's machine ssh key, closes #286to allow accessing test vms from fedi201's machine ssh key, closes #286allow accessing test vms from fedi201's machine ssh key, closes #286to allow accessing test vms from fedi201, closes #2860759d7d8c7aeb4f0cc8b@ -29,0 +33,4 @@{nixos.module.users.users.root.openssh.authorizedKeys.keys = [# allow our panel vm access to the test machines(import ../keys).panelIsn't this duplicate of your change in
infra/common/resource.nix?good catch, lemme see if i can ditch this one
@ -18,0 +19,4 @@owner = name;group = name;mode = "400";};I guess technically we don't care much about
group = nameif when then give a mode that only touches the user. - future proofness, I suppose.thanks, i removed it now
@ -35,3 +35,4 @@contributors = collectKeys ./contributors;systems = collectKeys ./systems;panel = removeTrailingWhitespace (readFile ./panel-ssh-key.pub);}I'm thinking if we enforce the
.pubsuffix, we could actually rather easily compute this nested record structure from the filesystem directly. But OK, that's really not a priority, and definitely not the topic of this PR.i consider keys to be deployment-specific state which should have no place in a code-base that should be as useful to someone from outside our team as to us - so down the line i do wanna get rid of the hard-coded cruft, yeah.
@ -159,3 +159,3 @@users.users.${name} = {isSystemUser = true;isNormalUser = true;What exactly are the impacts that we are looking for here? I suppose:
Is that true? Can we not SSH into a system user?
we ssh (and execute orchestration) from that user, not to it.
making
panela normal user grants it its own home folder, with a.cacheit can write to, and.sshstuff.home-manager i'm using just to grant user
panelan ssh config - which tbf does feel overkill, tho i hadn't looked into alternatives as of yet.It does feel like overkill indeed, but that's really fine. That you for the details about system vs. normal user!
LGTM. If this has been tested successfully, feel free to merge!