allow accessing test vms from fedi201, closes #286 #297
No reviewers
fricklerhandwerk
Labels
No labels
ambition
application-offering
ambition
configure-applications
ambition
front-end
ambition/install-applications
ambition
security
ambition
switch-host
ambition
update-applications
ambition
user-management
blocked
component
api-service
component
fediversity-panel
component
nixops4
documentation
points
0
points
0.5
points
1
points
13
points
2
points
21
points
3
points
34
points
5
points
55
points
8
points
infinite
productisation
project-management
question
role
application-developer
role
application-operator
role
hosting-provider
role
maintainer
security
technical debt
testing
type
bug
type
deliverable
type
key-result
type
objective
type
task
type
unclear
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!