Ubuntu templates

[unman]

For any one who wants to try out Xenial or Bionic, I've put some updated
templates for 4.0 online, including a bionic+desktop version.
They are pretty vanilla, except I have stopped the automatic search for
updates. The templates are signed with my key.

If you use Ubuntu in Qubes I provide package repositories at
https://qubes.3isec.org for convenience. Full details on that page.

As you may know Qubes doesn't provide official pre-built Templates for
Ubuntu, because of licensing concerns - details at
www.qubes-os.org/doc/templates/ubuntu

To use my templates or packages, you will, of course, have to trust me
(and my key). If you're not happy doing this, then build the templates
and packages yourself using Qubes Builder.
It is simple to build templates using Qubes Builder, but some
people find it daunting, or don't have time.
If you want to do it, follow the instructions for building but select
"builder-debian" plugin and the Ubuntu distribution you want. If you
need help just ask.

unman

[Achim Patzner]

On 20181226 at 10:39 +0000 unman wrote:
> For any one who wants to try out Xenial or Bionic, I've put some
> updated templates for 4.0 online, including a bionic+desktop version.

Building the templates if the stars are aligned just right and nothing
in the build process breaks is not that big of a problem (although
someone might take a look at the builder script and the makefiles to
make them a bit more fault tolerant (e. g. in case the downloading of
additional packages fails)) if the process is not done in steps by the
user. The more interesting problem would be keeping the included qubes-
specific packages updated and offering the necessary server
infrastructure to deliver updates (providing the servers would be a
minor problem...). Do you feel up to doing that for the foreseeable
future?


Achim

[unman]

There's an open issue relating to making build more fault tolerant, but
since I never see that problem, it's not a priority. (I use
apt-cacher-ng as a caching proxy which might help. Certainly does on the
template updating.)

On your second point did you read https://qubes.3isec.org ? I've been
running those for about two years.

[Achim Patzner]

On 20181227 at 10:58 +0000 unman wrote:

There's an open issue relating to making build more fault tolerant, but

since I never see that problem, it's not a priority.

Not starting redoing everything to the point where the build process stopped would be a good first step.

(I use

apt-cacher-ng as a caching proxy which might help. Certainly does on the

template updating.)

Probably. Sitting in jakarta and trying to do a make qubes-vm followed by make template was tiring with every second package failing to download. Maybe a "download all required additional data" make target would be a good idea, too. Or did I miss that?

On your second point did you read 

https://qubes.3isec.org? I've been

running those for about two years.

Sadly not but I will take a look at it now; I gave up using other people's templates when the Arch template was running out of updates... And to be honest: Using the Builder environment is a good exercise.

Achim

[unman]

On Sun, Dec 30, 2018 at 04:35:07PM +0100, Achim Patzner wrote:
> On 20181227 at 10:58 +0000 unman wrote:
> > There's an open issue relating to making build more fault tolerant, but
> > since I never see that problem, it's not a priority.
>
> Not starting redoing everything to the point where the build process
> stopped would be a good first step.

Yes, it's very aggravating. I would work around this by commenting out the
packages that *have* been built, so the build can start again from where
it failed.
I'm not surehow this oculd be done otherwise, except having a build
target (start-from) which skipped pachkage in the build list before that
one.

>
> > (I use
> > apt-cacher-ng as a caching proxy which might help. Certainly does on the
> > template updating.)
>
> Probably. Sitting in jakarta and trying to do a make qubes-vm followed
> by make template was tiring with every second package failing to
> download. Maybe a "download all required additional data" make target
> would be a good idea, too. Or did I miss that?

There's make get-sources, of course, but I dont think that is what you
mean.
I strongly recommend a caching proxy. apt-cacher-ng works pretty much out
the box. The only change required is to make it listen on port 8082 and
some minor config for Fedora.
Also, since the move to https , you have to make some changes to keep
caching. The simplest way is to use http://HTTPS/// in the sources.list
and then the proxy will will be able to cache packages but will still
fetch them under https.

>
> > On your second point did you read
> > https://qubes.3isec.org? I've been
> > running those for about two years.
>
> Sadly not but I will take a look at it now; I gave up using other
> people's templates when the Arch template was running out of updates...
> And to be honest: Using the Builder environment is a good exercise.
>

Agreed.
>
> Achim

[Achim Patzner]

On 20181230 at 16:34 +0000 unman wrote:
> > Not starting redoing everything to the point where the build
> > process stopped would be a good first step.
>
> Yes, it's very aggravating. I would work around this by commenting
> out the packages that *have* been built, so the build can start again
> from where it failed.

I (having started using Unix with 4.2BSD on a VAX where things tended
to take really long) wrote a csh script around make doing every single
component one-by-one and checking the exit state of the make jobs I'm
starting. Looks ridiculous but works unattended.

> I'm not surehow this could be done otherwise

By formulating further dependencies that check whether the goals are
already existing. If something that has been done flawlessly is remade
the thing has been missing in the dependencies.

Another good indicator that something is wrong with the makefile is
getting into a mess if using -j is causing any kind of race condition
or premature target being done. And no, "make -j4 qubes-vm" does not
work which means that rules fire before all prerequisites have been
done.


> download. Maybe a "download all required additional data" makeMaybe a
> "download all required additional data" maktarget

> >
> > would be a good idea, too. Or did I miss that?
>
> There's make get-sources, of course, but I dont think that is what
> you mean.

No, rather a target get-packages that will download all
.deb/.rpm/.whatever that will later be used to create the root
environments for VM templates. This step is coming REALLY late (after
building all qubes-packages) and I definitely do not see any reason to
rebuild all the qubes-* components because a package download fails.
Wrong order.

> I strongly recommend a caching proxy. apt-cacher-ng works pretty much
> out the box.

If you downloaded it once it stays in qubes-builder. (Which is another
target that is missing -- old packages are kept in there if later
builds are getting more recent versions.) So unless you are using a
tool with high tolerance to interrupted downloads this will not help
that much. And places with unstable network connections are easy to
find.

Btw: If I understood the license clauses of Ubuntu correctly you can do
with it whatever you want as long as you do not call it (genuine or
derived) (U)buntu. So if you provide a minimal template with
sufficiently free space (and calling it Pronto instead of Ubuntu) that
pulls down the "trade dress and feel" on a first run should be well
within the limits. Maybe that's a way to do it. Although I would
consider having supported Arch and a CentOS template much more
important. Debian is a glacier and Fedora... I'd better not start
thinking about that. But it will take considerable resources to keep
all necessary components working.


Achim

[seshu]

Hi, I'm new to Qubes and am interested in trying the ubuntu template. But, I"m confused on how to use the template you created? I went to 3isec.org site and the instructions are confusing. I see the key you have there, but the pgp.mit.edu server doesn't seem to be responding when I request keys. And then I'm not sure what to do with the rpm file for the template?

Sorry to ask dumb questions, but thanks also for putting this together. thanks!

[unman]

No need to apologise. Everyone starts from somewhere.

If you are connecting via Tor then pgp.mit.edu will often be
unresponsive. You should be able to find the key elsewhere, on other
keyservers (like keys.gnupg.net), and be able to check fingerprint
against github, or postings to this list.
Download the package in a qube. Use a Fedora based qube and you can
verify the package is signed by me, using 'rpm -K' or 'rpm -qpi'

Once you are happy, (and have decided to trust me), you need to transfer
the package in to dom0.
Have a look at www.qubes-os.org/doc/copy-from-dom0/ for help with this.

Once you have the package in dom0 you can install it with 'dnf install'
That will create a template, and you should be able to create qubes as
you will.

unman

[seshu]

Thanks! that worked really well!

[list...@gmail.com]

On Tuesday, 1 January 2019 02:11:21 UTC, unman wrote:

> Once you have the package in dom0 you can install it with 'dnf install'
> That will create a template, and you should be able to create qubes as
> you will.
>
> unman

Awesome!
It worked but I can't sudo without knowing the built-in user's password.