m (Update re. GRUB2 timeout) |
|||
(6 intermediate revisions by 2 users not shown) | |||
Line 53: | Line 53: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1308537 1308537] | ||
== Detailed Description == | == Detailed Description == | ||
Line 69: | Line 69: | ||
More information and discussion can be found on the [https://lists.fedoraproject.org/archives/list/cloud%40lists.fedoraproject.org/thread/M75UQFVNUPNC6ES3RZMT5PXRHIH3FMP5/ Cloud SIG mailing list]. | More information and discussion can be found on the [https://lists.fedoraproject.org/archives/list/cloud%40lists.fedoraproject.org/thread/M75UQFVNUPNC6ES3RZMT5PXRHIH3FMP5/ Cloud SIG mailing list]. | ||
=== How It Works === | |||
Atomic Developer Mode uses the same ostree deployment as the | |||
top-most entry (i.e. the default boot entry). Whenever a new | |||
grub.cfg is generated (e.g. by doing an rpm-ostree | |||
upgrade/rollback/rebase), the Developer Mode entry is also | |||
updated to point to the new default deployment. | |||
In the kernel command-line, a cloud-init argument is | |||
provided so that during the boot process, it does not try to | |||
contact e.g. the OpenStack metaserver (and eventually hang), | |||
but instead uses local metadata installed by the | |||
atomic-devmode package. It is this cloud-init metadata that | |||
bootstraps the Developer Mode experience. | |||
A core requirement of the Developer Mode feature is | |||
statelessness. This means that even if one has booted into | |||
Developer Mode, later boots should show no remnants or | |||
artifacts of that effect (no auto-login, no auto-generated | |||
root password, etc...). | |||
=== Security Considerations === | |||
It may be seen as a security issue to be able to boot | |||
directly into an autologged in root shell. However, this | |||
would require access to the GRUB 2 menu. If you are planning | |||
to run Atomic Host in an environment in which a malicious | |||
user may have access to the boot menu (e.g. in a kiosk | |||
setup), then you should lock it regardless of the presence | |||
of a Developer Mode installed or not. | |||
Otherwise, the malicious user will be able to edit the | |||
kernel command-line for any boot entry and point cloud-init | |||
to a datasource which will e.g. set the root password to a | |||
predefined string. | |||
As a POC, you should be able to boot the current Fedora | |||
Atomic Host image, and at boot time, press 'e' to edit the | |||
menuentry and appending the following to the boot option: | |||
ds=nocloud-net\;s=http://jlebon.fedorapeople.org/bad-cloud-init/ | |||
Once booted, you should be auto-logged in as root. | |||
Even if network access is blocked, one simply has to append | |||
`rw init=/bin/bash` to the kernel cmdline, write the | |||
meta-data locally, reboot, and then point cloud-init to | |||
the local datasource (or just skip all that and disable | |||
cloud-init and set a root password). | |||
Thus, the Developer Mode feature does not introduce a new | |||
security vulnerability in that space, although it can make | |||
it more convenient. It is always possible to delete the | |||
Developer Mode menu entry by doing: | |||
/usr/libexec/atomic-devmode/bootentry remove | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Line 80: | Line 137: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
** Create an atomic-devmode package to hold the helper files needed for this feature -- '''DONE''' | ** Create an atomic-devmode package to hold the helper files needed for this feature -- '''DONE''' | ||
** Add the atomic-devmode package to the Fedora repos | ** Add the atomic-devmode package to the Fedora repos -- '''DONE''' | ||
** Submit the necessary changes to repos related with tree and image creation: | ** Submit the necessary changes to repos related with tree and image creation: | ||
*** 1. Submit a patch to [https://git.fedorahosted.org/cgit/fedora-atomic.git fedora-atomic] to have the atomic-devmode package part of the default tree compose | *** 1. Submit a patch to [https://git.fedorahosted.org/cgit/fedora-atomic.git fedora-atomic] to have the atomic-devmode package part of the default tree compose -- '''DONE''' | ||
*** 2. Submit a patch to [https://git.fedorahosted.org/cgit/spin-kickstarts.git spin-kickstarts] to have the boot menu item added in the kickstart %post | *** 2. Submit a patch to [https://git.fedorahosted.org/cgit/spin-kickstarts.git spin-kickstarts] to have the boot menu item added in the kickstart %post -- '''DONE''' | ||
** Work with projectatomic.io maintainers to properly present Atomic Developer Mode (including updating the Quick Start Guide) | ** Work with projectatomic.io maintainers to properly present Atomic Developer Mode (including updating the Quick Start Guide) | ||
Line 127: | Line 184: | ||
* GRUB 2 menu | * GRUB 2 menu | ||
** Make sure Developer Mode is not the default entry | ** Make sure Developer Mode is not the default entry | ||
** Make sure the GRUB 2 timeout is | ** Make sure that the GRUB 2 timeout is still 1 second | ||
** Make sure that atomic upgrade/rollback/rebase preserves the Developer Mode boot menu item | ** Make sure that atomic upgrade/rollback/rebase preserves the Developer Mode boot menu item | ||
* Statelessness | * Statelessness | ||
Line 174: | Line 230: | ||
TBD | TBD | ||
[[Category: | [[Category:ChangeAcceptedF24]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> |
Latest revision as of 15:16, 26 April 2016
Atomic Developer Mode
Summary
Add a "Developer Mode" boot menu entry in the Atomic image to allow users to boot without setting up cloud-init.
Owner
- Name: Jonathan Lebon
- Email: jlebon@redhat.com
- Release notes owner:
- Product: Atomic Image
- Responsible WG: Cloud SIG
Current status
Detailed Description
The high-level goal of Atomic Developer Mode is to make the Fedora Atomic Host image more accessible by providing a new GRUB 2 menu item labeled e.g. "Fedora 24 (Twenty Four) Developer Mode". This mode is an attempt to provide a painless experience for folks who want to try out Atomic but (1) do not want to bother setting up a cloud-init datasource, or (2) do not know anything about cloud-init, or even (3) do not have much experience with Linux overall. They just want to try out e.g. /usr/bin/atomic, /usr/bin/docker, or play with the Cockpit console.
Since the functionality is completely integrated into the image, there are no requirements on the host system, other than its ability to boot VMs. When booted in Developer Mode, the following happens:
- cloud-init uses a local built-in datasource
- a new root password is generated
- the root user is automatically logged in on tty1
- the cockpit/ws image is downloaded and started
- a tmux session is started on tty1 to provide all the relevant information (root password, IP address, Cockpit console address)
More information and discussion can be found on the Cloud SIG mailing list.
How It Works
Atomic Developer Mode uses the same ostree deployment as the top-most entry (i.e. the default boot entry). Whenever a new grub.cfg is generated (e.g. by doing an rpm-ostree upgrade/rollback/rebase), the Developer Mode entry is also updated to point to the new default deployment.
In the kernel command-line, a cloud-init argument is provided so that during the boot process, it does not try to contact e.g. the OpenStack metaserver (and eventually hang), but instead uses local metadata installed by the atomic-devmode package. It is this cloud-init metadata that bootstraps the Developer Mode experience.
A core requirement of the Developer Mode feature is statelessness. This means that even if one has booted into Developer Mode, later boots should show no remnants or artifacts of that effect (no auto-login, no auto-generated root password, etc...).
Security Considerations
It may be seen as a security issue to be able to boot directly into an autologged in root shell. However, this would require access to the GRUB 2 menu. If you are planning to run Atomic Host in an environment in which a malicious user may have access to the boot menu (e.g. in a kiosk setup), then you should lock it regardless of the presence of a Developer Mode installed or not.
Otherwise, the malicious user will be able to edit the kernel command-line for any boot entry and point cloud-init to a datasource which will e.g. set the root password to a predefined string.
As a POC, you should be able to boot the current Fedora Atomic Host image, and at boot time, press 'e' to edit the menuentry and appending the following to the boot option:
ds=nocloud-net\;s=http://jlebon.fedorapeople.org/bad-cloud-init/
Once booted, you should be auto-logged in as root.
Even if network access is blocked, one simply has to append
rw init=/bin/bash
to the kernel cmdline, write the
meta-data locally, reboot, and then point cloud-init to
the local datasource (or just skip all that and disable
cloud-init and set a root password).
Thus, the Developer Mode feature does not introduce a new security vulnerability in that space, although it can make it more convenient. It is always possible to delete the Developer Mode menu entry by doing:
/usr/libexec/atomic-devmode/bootentry remove
Benefit to Fedora
The major benefit is to make Fedora Atomic Host more approachable to folks of all skill levels. This includes simplifying and reworking the Project Atomic Quick Start Guide to omit the whole section on cloud-init setup.
Scope
- Proposal owners:
- Create an atomic-devmode package to hold the helper files needed for this feature -- DONE
- Add the atomic-devmode package to the Fedora repos -- DONE
- Submit the necessary changes to repos related with tree and image creation:
- 1. Submit a patch to fedora-atomic to have the atomic-devmode package part of the default tree compose -- DONE
- 2. Submit a patch to spin-kickstarts to have the boot menu item added in the kickstart %post -- DONE
- Work with projectatomic.io maintainers to properly present Atomic Developer Mode (including updating the Quick Start Guide)
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The big win for Atomic Developer Mode is the ability to easily boot without setting up cloud-init. If a user is able to upgrade their Atomic Host, it means that cloud-init has already been set up. That said, after upgrading to (and rebooting into) a tree which has the atomic-devmode package, if users desire to have the Developer Mode boot menu item, they will have to manually run:
# /usr/libexec/atomic-devmode/bootentry add
How To Test
Atomic Developer Mode can be tested by anyone with access to a virtualization platform, either locally or in the cloud.
Test aspects:
- GRUB 2 menu
- Make sure Developer Mode is not the default entry
- Make sure that the GRUB 2 timeout is still 1 second
- Make sure that atomic upgrade/rollback/rebase preserves the Developer Mode boot menu item
- Statelessness
- Make sure that even if Developer Mode was booted once, it leaves no undesirable artifacts when booting using a regular cloud-init source (e.g. no auto-login, no auto-root pw generation, etc...)
- Error handling
- Make sure that Developer Mode errors out gracefully when the machine has no Internet access
- Make sure that Developer Mode errors out gracefully when the Cockpit image fails to be downloaded or run
- User experience
- [Subjective] Make sure that the system is approachable enough by folks who may not have much experience with Fedora, cloud, or Linux, but are tech-savvy enough to follow instructions and use the command-line.
User Experience
Users of the Fedora Atomic Host image will see a new boot menu item.
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?)
- Revert the patch to spin-kickstarts so that the new boot menu item does not appear.
- Revert the patch to fedora-atomic so that the atomic-devmode package is no longer part of the default tree compose.
- Contingency deadline: Beta
- Blocks release? No
- Blocks product? No
Documentation
Documentation includes this very page and the upstream source for atomic-devmode.
Release Notes
TBD