-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd/system: add [email protected] #103
Conversation
systemd/system/[email protected]
Outdated
|
||
[Install] | ||
WantedBy=multi-user.target | ||
DefaultInstance=core |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need the @
parameterization? I think that users would directly enable [email protected]
for any other users they want to have instead of enabling sshykeys@USER
to have this start the other one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, would just sshkeys.service
be enough with [email protected]
hardcoded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question but even in the current state it's good
this service allows to conditionnally start the `[email protected]` on DO, EM, EC2 and GGE with the default `core` instance in order to control the `[email protected]` from the generic image and not from the OEM. Signed-off-by: Mathieu Tortuyaux <[email protected]>
68a21a0
to
9bebd6c
Compare
It still has the |
ah 🤦 |
this service allows to conditionnally start the
[email protected]
on DO, EM, EC2 and GGE with the defaultcore
instance in order to control the[email protected]
from the generic image and not from the OEM.See: flatcar/scripts#1083 for context, CI and cie.