Snappy on RPi 2 Certificate Bug -- and other thoughts...

Alexander Sack asac at canonical.com
Mon Feb 16 11:53:50 UTC 2015


On Sun, Feb 15, 2015 at 8:48 PM, Louis St-Amour <louisstamour at gmail.com> wrote:
> Hi all,
>
> Not sure what the correct channel is to report this, but if you Google
> around you'll notice on Reddit and RPi forums that folks like myself are
> picking Ubuntu Core in part because it seems easy to install Docker.
>
> But you'll encounter two issues. The first is that default Snappy images for
> the Raspberry Pi do not have NTP enabled and well, the Raspberry Pi doesn't
> seem to have a default system clock set out of the box. ;-)
>
> So once you get past not knowing that the default username is ubuntu/ubuntu
> you then encounter a mysterious certificate error to which the fix is to use
> "sudo date MMDDhhmmYYYY" to set the time to the current time. And you have
> to do this each time you start the dang thing, which does not make this
> easy!
>
> I only discovered "webdm" when I googled 'ubuntu "webdm"' and Google
> initially thought I was searching for webmd ;-) From there, visiting
> http://webdm.local:4200/ was cool.
>
> I see this is build number 2, and there's not even a dozen apps in the
> store, so this is just getting started on ARM. But I really like this
> approach. It's just NTP that's missing from making this a usable system. If
> NTP is seen as "too much bloat" ;-) well, perhaps there could be an NTP ARM
> package added to the store, and like webmd, this could be included by
> default in the image?

We agreed to include ntpdate in the core image, but then it was raised
that we rather should include the systemd equivalent. Just talked to
pitti and mvo and they are on it. Expect this to be in our
devel-proposed image pretty soon.


>
>
> Okay, here ends the consise feedback. What follows is more of a "stream of
> consciousness" on the project as an outsider:
>
>
> Just doing an ls /usr/bin reveals that this install of ubuntu core, at
> least, seems far from small. It appears to include dpkg, perl and two copies
> of python, which I guess are dependencies for other commands, like
> ubuntu-core-config? I've no idea what that does, it just prints something
> like timezone: UTC if I give it the -d command. Seems far more overkill to
> bundle two copies of python and a perl interpreter unless it's needed by
> drivers and things. I see by the logs left in /var/log that this was once a
> more full-featured install, then packages were removed via apt-get, etc.
>
> It also surprised me that the download was over 700MB given it was a minimal
> install, but I suppose that was the nature of packaging it as a 3GB disk
> image. The total in use is 768M, 8.5M, 27M, 4K and 60M, so excluding all the
> zeros, somewhere around 82% compression. Of this, 575MB is the /lib folder
> and 128M is /usr. Most of /lib judging by folder names is just kernel
> drivers and features. (It can speak Appletalk!) So I guess it really is
> quite minimal for a stock system, but I could see a future where, as an
> embedded systems author, I might want to make my own distribution of Core
> with unnecessary files removed and maybe some other drivers pre-installed?

You are right, some clean up still has to happen before release in
april. And you are also right that the kernel modules are HUGE.

The idea of having something for system builders to "strip" modules
that they dont need has been discussed, but we didn't have the time to
look at it. If you want to help speccing that out just touch base with
me on #snappy channel on IRC.

The idea would be to provide a feature in our oem.snap (which is a
special snaps where we allow system builders to do their appliance
customizations). I assume it would be about defining a language how to
express this nicely in our oem.yaml. Obvioulsy, simply listing
include/exclude patterns comes to mind, but that doesn't feel clean
and very hackish. Maybe we could limit ourselves to listing subsystems
and concrete drivers for exclude/include rather than wildcard
patterns? Maybe we could find a language that talks about "features to
include/exlcude" rather than very technical tems such as subsystems
and drivers.


>
> I really like the read-only approach, but I'd almost want to build my own
> Ubuntu image with my app pre-installed on the read-only partition, such that
> deploying new apps then becomes installing a new OS and rebooting. As it

note that this is exactluy what snappy is made for: to build your very
own custom appliance. The oem snap mentioned above allows you to
define which snaps should come preinstalled and how they are
configured. udf will take that info and just do it (TM) so you can
produce prebuilt images that are exactly that you want to put on
system.

> stands now, I can see that this project will make /apps read-only, but it's
> concerning to read that currently, apps make the folder on installation:
> https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ ... it
> seems like another answer would be to use a Packer-style tool to make a
> read-only OS image that includes just the apps you'd want. Or deploy a new
> apps partition, a/b style, the advantage being that to switch partitions
> you'd only need to have the OS restart the apps instead of restarting the
> entire OS? Actually, now that I think about it, you could do a graceful
> restart from one app partition to the next, rather than today's "stop the
> universe, update, then start it again..." It'd have to be the app's job to
> fully support such a scenario, since ideally the old and new versions of the
> app could run and briefly co-exist during the handover. Alternatively, move
> it down the stack and deploy apps using a framework that supports such
> behavior, I suppose.

I think the above oem snap feature will do what you want. Happy to
have you as a tester of those features that are either still in work
or pretty hot in our code base. At best pop in on #snappy and chat
with sergiusens about oem snap and me (asac)

>
> Well, thanks for reading this far! ;-)

Thanks for great input!
>
>
> Louis.
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>



More information about the snappy-devel mailing list