Add an initial mkosi config #105
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jeremycline
force-pushed
the
mkosi-conf
branch
3 times, most recently
from
e33a26b to
d848ef6
Compare
This is still a work-in-progress. It still needs: - A stubbed out Wireserver and IMDS instance To try it out as-is, you can build and then boot the image with: $ mkosi -d fedora $ sudo mkosi boot The version of azure-init in target/debug/ will be run as part of the image startup. You can inspect the result with "systemctl status azure-init". Run "systemctl poweroff" to leave the environment. This needs to be done in an Azure VM since it relies on talking to a real Wireserver and IMDS. Refer to mkosi docs[0] for installation options [0] https://github.com/systemd/mkosi?tab=readme-ov-file#installation
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
jeremycline
added a commit
to jeremycline/azure-init
that referenced
this pull request
Jul 19, 2024
Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing Azure#105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this.
dongsupark
pushed a commit
that referenced
this pull request
Jul 23, 2024
* azure-init: Accept providing user groups via the CLI Debian uses "sudo" as the group for having do-anything sudo permissions, where-as Fedora uses "wheel". Otherwise the same binary works fine for both. I don't see an advantage to baking the groups into the binary, so this is a take on runtime configuration. Accept a list of supplementary groups to use when provisioning the user so the same binary can be used for both. Values can be provided using the "-g" or "--groups" argument, or by setting the "AZURE_INIT_USER_GROUPS" environment variable. If no groups are provided, the default remains "wheel". I found this helpful when testing #105. We could expand this to allow more runtime tweaks to, for example, the backend in use if folks like this. * Clarify priority of environment variables vs CLI args Arguments provided as CLI arguments (`azure-init --groups=wheel,deal`) override any arguments provided by environment variables. They are not merged.
dongsupark
reviewed
Jul 25, 2024
| # Perform an incremental rebuild of the image | ||
| Incremental=true | ||
| # Make the source available at runtime | ||
| RuntimeBuildSources=yes |
There was a problem hiding this comment.
How about adding ToolsTree=default here?
On my Debian stable system with systemd 252, mkosi boot does not run because systemd-nspawn version is too low.
See also NEWS:
ToolsTree=default can be used to make sure a recent version of systemd is used to do the image build.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is still a work-in-progress.
It still needs:
To try it out as-is, you can build and then boot the image with:
$ mkosi -d fedora
$ sudo mkosi boot
The version of azure-init in target/debug/ will be run as part of the
image startup. You can inspect the result with "systemctl status
azure-init". Run "systemctl poweroff" to leave the environment.
This needs to be done in an Azure VM since it relies on talking to a
real Wireserver and IMDS.
Refer to mkosi docs[0] for installation options
[0] https://github.com/systemd/mkosi?tab=readme-ov-file#installation