The main reason it’s not in EPEL is that right now, it functionally doesn’t work. I have an idea of what EPEL-specific patching I’ll need to do, though.
Recovery mode for core devices
- Use cases:
- Reset to original factory state for whatever reason (lost password, etc)
- Reset device while retaining essential data (might be delegated to application level)
- Soft-reset: remove the data, but keep the data? Sounds similar to prior case.
- Primary goal is having back a working device
- It should be extremely robust, since this is already the “get out of jail” card
- Given the nature of snaps, we might be able to do it without duplicating the data already in the image today
- We might make the seed directory immutable using attributes, but that’s not safe enough
- How would the reset procedure actually work:
- Tell grub to boot from the seed kernel and seed core, plus magic command line
- We might get away without using the initramfs for the procedure
- Either initramfs or very early systemd unit formats the partition and puts it back in a working state
- There might be code duplication between ubuntu-image and snapd, but we already need to understand the description in gadget.yaml for performing updates, so probably unavoidable
- It goes without saying that we are always assuming that the device can at least boot, so has a good partition table, etc. Otherwise there isn’t much we can do from inside out.
- That said, we may support being able to have independent devices for recovery and for the writable space. In those cases, we might support repartitioning the writable space from the outside.
- Proposed first phase: get a mechanism in place that once the reset “button” is pressed, it gets back into the exact same state of first boot (so no serial, no extra hooks executed, or anything else). This is a good stepping ground towards anything more advanced.
- We might do a soft-reset system where we have a hook that allows the snap to decide what to preserve (export and import) on a reset situation, for cases where things are broken but not much. That would allow keeping a hard-to-reach device online, for example.
Snapd staging snap
- Build a staging snapd deb in a PPA.
- Have a spread-cron job building snapd snap with staging keys, and push to the staging store.
- Regularly copy core18, the pc gadget to the staging store (probably on beta or candidate releases).
- Use cases for store team to test snapd in a LXD.
Snapcraft extensions progress review
- Only allow “extensions” in the app level or top-level for now, so it may be decided later what it would mean to declare both
- Error if extensions are defined in conflicting order across different applications ([a, b] and then [b, a])
- Extensions need to be able to chain/compose, so that in [ext-a, ext-b] the output of ext-a becomes the input to ext-b
- Output human-built documentation to describe what an extension does, with snapcraft extension foo
- Improve internal implementation so extensions can also declare plugs and slots
- Break down the individual scripts that were originally concatenated into a single wrapper, so that they can now become independent commands in the chain
- Extensions support specific bases, explicitly, so that people can trust their behavior; anyone that reviews the behavior of an extension on a new base can report and the list will be expanded
- The internal implementation might be improved eventually to support a richer implementation of the snapcraft.yaml content, but that’s not critical since changes in extensions won’t break any public APIs
Snapcraft snap directory
- Problem is that some projects (e.g. snapd
) use the snap/ directory for content that is not related to snapcraft building process (reported as #1772584) - There’s currently no way to avoid that clash
- Proposed solution is to allow .snap/ to be used instead of snap
- That will only be used if a .snap/snapcraft.yaml file exists ($HOME/.snap exists)
- New VM-based snapcraft will enforce use of either snap/snapcraft.yaml or .snap/snapcraft.yaml, and error clearly if snapcraft.yaml or .snapcraft.yaml are in the current path
- build.snapcraft.io needs to be updated to support .snap/snapcraft.yaml as well
CUPS snap is working now (tested printing from LibreOffice snap through CUPS snap):
- CUPS snap now checks whether port 631 is busy. If it is not busy it starts CUPS on port 631, otherwise on 10631.
- cups-browsed startup waits for CUPS startup having selected the port, to assure correct connection of the snap’s CUPS and cups-browsed
- It is not recommended to run both the system’s (Debian-package-based) and the snapped CUPS on production systems, but for development setups this is possible.
- If a system is only running the snap’s CUPS, this CUPS is available through port 631 and both Debian-package-based and snapped applications can print on it.
- The snap still needs manual connection to Avahi and USB interfaces (on core also to home dir intrerface).
- Connected to Avahi interface the snapped CUPS finds and sets up IPP (driverless) printers automatically, using its cups-browsed.
- Users in “adm” group can do administrative tasks using the command line utilities of the snap (they use the snap’s domain socket by default), admin via localhost:631 (system’s utilities) does not work.
- The snap uses now the up-to-date upstream versions: CUPS 2.2.8, cups-filters 1.21.2, and to fulfill the dependencies of cups-filters QPDF (8.2.1) is nowalso included.
- Cleaned up warnings in snap build process
- Updated README.md
Next steps:
- Automatic connection of all interfaces (Request)
- Addition of ippusbxd for auto-setup of driverless USB printers (Needs support for systemd templates).
- If possible/needed: Have “lpadmin” group for administrative tasks (Thread: Multiple users and groups in snaps)
- Get admin via localhost:631 to work (Thread: User authentication in snapd)
What will next cycle look like?
- Probably will be completed next month:
- Ubuntu Core 18!
- Warnings
- Snapshots working
- Epochs
- Parallel installs
- Documentation outline polished
- Documentation published on snapcraft.io
- Dynamic snap-update-ns for user mounts
- Health checks
- Probably won’t be completed next month:
- Hotplug
- Snapshots at remove and refresh
- Candidates for next cycle:
- First boot improvements
- Prevent refreshes while applications are in use
- Support for man page
- Configuration schemas
- Health checks
- Support for more RPM distributions
- Device reset and recovery
- Bootloader/gadget updates
- Repairs phase 2
- Multi-user support
- CLI support for holding refreshes
- Interface for accessing hidden files
- Remodeling
- USN/CVE metadata association
- More interfaces, as usual
- Christmas gifts
- Renames of snaps
- CLI support for holding refreshes
- Cohort support
- Improve license support
- Interfaces and layouts in classic snaps
- “Semi-classic” interface
- Resource quotas
- Snap “parts” for debug symbols and translations
- Consider integration of libc localization support in base
- Entitlements
Metered connections
- Existing configuration enables usage of metered network setting to hold refreshes for up to 3 months
- Ideally that should become the default
- For compatibility, the refresh.metered setting will accept more clear string values, in addition to current boolean setting
- Current boolean settings preserve the current meaning for compatibility
- Before the default is changed we need to make sure no unattended devices will be bricked due to their only connections being marked as metered
- Field team confirmed they will check whether there are devices being marked as metered, and then whether those can be reconfigured so they won’t be affected
1 Like
Kernel driver development experience
- Pain points
- Third-party maintains a wifi driver, but they cannot test their patches
- Kernel snaps cannot be locally installed without signatures
- Pushing to the store is a long roundtrip and impractical
- Kernel snaps are always constantly being flagged for manual reviews
- We cannot accept arbitrary kernels to simply replace actual device kernels
- The proper solution must involve a signed document (assertion) saying that for a specific case, it’s okay to replace that kernel by that other kernel
- The snap-declaration assertion may have data on it that is important for the kernel setup to happen properly. The system cannot simply reuse that assertion, which was reviewed and signed, in a third-party local snap that was never seen by the system.
Ordering across snaps and system
- There’s a project trying to support dependencies with dynamic systemd device units
- Another project would like to depend on daemons across snaps
- Sensitive cases… we need to consider carefully how to support something equivalent to that without introducing brittle logic that is hard to understand, hard to debug, and easy to break
1 Like