[xen-tools] Various potential modifications

[Jeff Forcier]

Hi all, hi Steve, thanks as always :)

Got a handful of comments/questions and didn't feel it would be
prudent to make a separate mail for each - let me know if I should
split any of these off into its own thread for some reason. I'll
number them to make it easier to reference - please don't take this as
some sort of demands list :D

Apologies for the length - I've tried to include enough backstory so
that it's clear where these queries are coming from, and that I tried
to do at least a little homework before posting.


1. domU user accounts: an issue I mentioned to Steve a few weeks ago,
which sparked the multiple-roles change (which is working fine,
incidentally - thanks again for that) is the desire to specify system
users at image create time. E.g. when creating a new domU, I might
want to create N user accounts - using --accounts won't work as these
accounts are unique per domU, and I'm not using xen-shell so I don't
think --admins is applicable.

I tried a 'users' role script, only to realize that it doesn't work
because role scripts are executed via runCommand() which eats/logs
stdout, thus causing problems during the password-entry phase.

The only obvious solutions I can think of are to add some sort of
option for controlling the stdout-eating behavior of runCommand()
per-role  (unwieldy and hackish, especially on top of the --role-args
for multiple roles stuff) or to make this users stuff part and parcel
of the script itself (which aside from being a core modification would
also mean there are now at least 3 user-related options - potentially
confusing).

I'm willing to get my hands dirty with Perl and work on a patch, but
wanted to post this topic to the list in case anyone had other
suggestions/concerns.


2. IP address (re)allocation: unless I'm missing something, there is
currently an auto-allocation mechanism for increasing subsequent IP
addresses from a starting number. This is useful, but I find myself
trashing and recreating domUs fairly often, and while that's partly
due to lots of testing, I'd still like to have a mechanism that was
able to reallocate unused IPs, for fear of "running out" - from the
script's point of view - despite still having extra numbers available
in my allocated block.

As with #1, I would probably write a patch that replaces the current
last-number-allocated file with one that holds a list of domU IDs and
IP addresses, which would be modified when xen-delete-image is run,
and checked for the lowest unallocated address when it's referenced
for new numbers.


3. Extended .deb caching: This may be more of a general Debian
question as opposed to something xen-tools specific, but is there a
way to cache more of the Debian packages than just those used by
debootstrap? As far as I can tell, the current way of doing things
doesn't cache commonly installed packages from role or dist scripts,
and while I think I understand why that is, it'd be nice if there were
some way to improve upon it. Having the additional .deb files present
in dom0's /var/cache/apt/archives (which seemed the most obvious
approach) doesn't appear to count for these later-on installs.

I don't have an obvious solution or patch for this one - mostly just
looking for ideas or a better understanding of the underlying
mechanisms. domU network performance is less than ideal, and it seems
that a nontrivial portion of the runtime of the scripts, for me, is
the fetch portions of package installations.


4. Fine-grained 'skel' behavior: Kind of an out-there thing, but I was
curious if there are any decent solutions for wanting to tweak just
one or two specific options in config files instead of wholesale
replacements as is currently done with the /etc/xen-tools/skel/ stuff.

E.g., right now, in order to change SSH's PermitRootLogin to 'no' I
have to include a full sshd_config file. Since most of my domUs are
Debian or Ubuntu that's not a big problem, but I fear that in the
future when I'm using CentOS or other non-Debian distros, I'll run
into some problems with file paths and other things that might differ
in config files between distros.

I originally started out writing additional role scripts that ran some
sed replacements on the domU stock config files, but ended up just
using the skel framework as it was quicker. Being an idealist I was
curious if there's a better way to approach this. Or I could just be
thinking about this too much :)


Sorry again for the length! Looking forward to any replies.

Regards,
Jeff