Handling apt sources with ltsp-build-client

"Adam J. Lincoln" <alincoln-eGqb5pYUX368SA5af/[email protected]> Thu, 21 Jan 2010 16:59:19 -0500
Newsgroups gmane.linux.terminal-server.devel
Message-ID <[email protected]>
Hi folks,
    After wanting stgraber's PPA on my test client, I noticed that
--copy-sourceslist doesn't bring over entries in /etc/apt/sources.list.d.
Since folks often put entries for PPAs and other repos in this directory,
I wrote up a patch to fix this and pasted it to sbalneav on IRC.

    But this brought up another point: these PPAs are signed, and the
client need to know about this via apt-key.  There is --apt-keys, but
afaict this requires that the key be in a file, and that filename is
given as the parameter.  This doesn't seem right to me - it ought to at
least take the output of 'apt-key export', or even better, a key id.

    As I was asking about the intent of this on IRC, there was a
discussion on whether --copy-sourceslist is good at all, or how much
control it should allow.  Here it is in full glory:

14:01 < alkisg> So the real question is, "in which use cases would one
want to run tsp-build-client --copy-sourceslistbut not copy
sources.list.d, and/or not copy the server's apt keys?"
14:06 < johnny> if there is a ppa that say.. contains a newer version of
some that you want on the server, but not on the client?
14:07  * vagrantc thinks copy-sourceslist is a bad idea
14:07 < johnny> vagrantc, why?
14:08 < vagrantc> johnny: there are so many possible configurations where
it would do the wrong thing, even though in default scenarios it will
probably do the right thing.
14:09 < vagrantc> johnny: largely permutations on the example you gave
14:09 < johnny> i'd be happy with --copy-repos=universe,main,multiverse
14:09 < johnny> or whatever
14:09 < vagrantc> ppa's, backports... someone who pulls a known set of
packages from the newer version...
14:09 < alincoln> so without it, you make the admin go into the chroot
and edit it manually?  or you leave it in, and let the admin edit the
sources manually in the strange cases.
14:09 < vagrantc> you'd almost have to copy /etc/apt/preferences* too, to
make it sane... and even then, it's all kinds of guesswork.
14:10 < johnny> vagrantc, i think it is important to be able to copy
stgraber's ppa
14:10 < johnny> as early as posssible
14:10 < johnny> so we should be able to inject repos in some fashion
14:10 < vagrantc> johnny: sure, but there's numerous other ways to
accomplish that.
14:10 < vagrantc> copy-sourceslist is a shotgun approach.
14:10 < johnny> yeah... as long as i can copy a specific list, i'm OK
without it
14:11 < vagrantc> it might solve the problem in many cases, but it has
high potential for unintended consequences.
14:11  * alkisg is right now writing a private plugin that adds his own
repositories... vagrantc, what are the alternatives?
14:11 < vagrantc> but that's why i don't include it in debian :)
14:11 < vagrantc> y'all are free to do whatever you want with ubuntu
14:11 < alkisg> Heh
14:11 < vagrantc> alkisg: --extra-mirror ?
14:12 < vagrantc> --early-mirror
14:12 < alkisg> But what about the keys/
14:12 < alkisg> ?
14:12 < vagrantc> --apt-keys ?
14:12 < alkisg> How would I find those files?
14:12 < alkisg> I'd tell the sysadmin to download them? Or make a deb
with them?
14:12 < vagrantc> whatever you think is easier
14:13  * alkisg thinks a private plugin is easier :)
14:13 < vagrantc> could even include a plugin by default like:
--use-ppa's
14:13 < vagrantc> if it's a stable location
14:13 < alkisg> Ubuntu has an "add-apt-repository" command, is that in
recent Debian versions too?
14:13 < vagrantc> :q
14:13 < vagrantc> heh
14:13 < alkisg> It's supposed to handle more than just PPAs... :D
14:14 < vagrantc> don't see add-apt-repository in ltsp-trunk...
14:14 < vagrantc> but there's extra-mirror and early-mirror in both
debian and ubuntu
14:14 < alkisg> No, I meant it's a normal command, unrelated to ltsp
14:14 < vagrantc> alkisg: sure, but that's an example for a common thing
people will add
14:14 < johnny>  vagrantc, i like being able to do it by the name of the
repo.. and copy the keys for me too... for those i specified
14:14 < vagrantc> alkisg: ah, no idea.
14:15 < vagrantc> --include-bonus-mirrors ppa,backports,foo
14:15 < vagrantc> with some predefined settings...
14:15 < vagrantc> maybe none of it is stable enough, though.
14:15 < alkisg> vagrantc:
http://packages.debian.org/sid/python-software-properties
14:16 < alkisg> add-apt-repository is there...
14:16 < alkisg> It adds a repo to sources.list.d/ and also fetches the key
14:17 < alkisg> Hmm or maybe it's an Ubuntu addition :D
14:17 < alkisg> nm
14:18 < vagrantc> don't know about it in either case :)

    Whatever it does, though, should have --apt-keys behavior that
correponds well.

    It seems to me that both fine control and all-included approaches
should be allowed.  It could allow individual repos (with the apt-key
properly along for the ride) to be selectable when the client is built,
and it could allow the current approach, with sources.list.d/* all moved
over plus all needed keys.

    I think you'd want to do this with optional parameters to
--copy-sourceslist and --apt-keys, but perhaps people don't like the
space-or-no-space stuff that comes with that.  Plus, you can imagine
having the fine grained control be like

ltsp-build-client ... --copy-sourceslist=ltsp,foo \
--apt-keys=abcdef12,12345678

    where ltsp.list and foo.list are in sources.list.d.  But this
doesn't allow for controlling additions made inside the servers's
sources.list.

    If I were to write something today, this is what I'd try.  Any
further input from those in the IRC conversation or comments from
others?

-- 
Adam Lincoln
DisklessWorkstations.com


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net