[xen-tools] Re: Various potential modifications

[Jeff Forcier]

On 10/1/07, Steve Kemp <steve at steve.org.uk> wrote:

>   Probably ok this once, but generally it is easier to keep track
>  with one mail per subject..

Noted, thanks and apologies :)

>   My initial inclination would be to have a role script to add
>  the accounts, but not in the way that you're currently doing
>  (with 'passwd').  Instead have a script which takes an
>  input file of:
>
>  username:password
>
>   (Ideally a salted + crypted password which the role script
>  could update directly via 'pwconv' / 'usermod'?)

The same rough idea (noninteractive input via file) occurred to me as
well; it's not as braindead-easy as interactive prompting, but at the
same time it also allows for reuse of the requested user/pass
combinations (theoretically such a script could still take additional
args narrowing down which entries in the file it executes). Which
would be nice and, at least for me, more effective in the long run
anyways.

Wasn't aware of 'pwconv' so that will give me more manpages to read, thanks.

>  192.168.1.3:used
>
>   Or similar would suffice there?  Then on creation we'd scan for
>  an IP which wasn't marked as used?  (And similarly remove the
>  :used upon deletion.)
>
>   That should be a simple change, the downside is that you would
>  have to enumarate a range rather than just the starting number.
>
>   (Altnertively I'd be happy with IP[ :]xen name. But that feels
>  a little like duplication /etc/hosts ;)

Originally I was thinking of the latter option to make it easier to
identify which IP to release upon xen-delete-image run - but now that
I think about it, it's just as easy to discern the IP itself. So I
don't have much of a preference either way and would probably
implement the former option - DRY is king after all :)

Regarding the downside, I agree - not sure if the burden should be on
the end-user to generate the full range, or if some xen-generate-ips
helper would be going too far (e.g. xen-generate-ips
192.168.1.200-254).

Theoretically the user could be met halfway - allow them to create the
starting ips.txt, but allow it to be a range instead (again
192.168.1.200-254; just doing 200-254 and then expecting the first 3
octets from stdin or conf file feels kind of strange [no offense],
because even if the user does want to hand out 2 different sets of
addresses they'd be sharing the same final octet, which isn't
necessarily a good thing). The first run of xen-create-image would
transform the range into the full list of IPs. Feels kind of icky due
to that one-time transform; maybe have two files, a 'seed' with the
range, and the full list. Then the user could theoretically alter the
seed later on to extend the range (shrinking obviously presents
problems).

>   I believe this should actually be handled already.   Certainly
>  the intention is there.
>
> [...]
>
>   If you can demonstrate that failing it is a bug and I'll fix it.

Huh, I wasn't aware it went that far. Has that behavior been altered
or beefed up since 3.5 (I'm using 3.5 + some manual patching)? If yes,
I'll check CVS and apply those changes to my local version; if no, I
will investigate to see if it's doing what you describe above.

>    I can't think of a neat solution should have having per-host
>   skel stuff, or per-role skel.  eg /etc/xen-tools/skel.$role.d/
>   and a role to copy over the contents.  But I think that'd get
>   messy fast.

Sorry, I might not have been clear - my concern wasn't necessarily
different behaviors per distro but simply allowing the user to specify
*only* the distro-*agnostic* stuff. I.e. every sshd_config, regardless
of paths or other system alterations, will accept the same
"PermitRootLogin no" option. Similarly, simple alias additions to a
bashrc or commands in a vimrc; an altered REMOVE_HOME option in
deluser.conf; and so on.

In that vein, I was thinking of basically tiny 'transformation' files
that describe what options to add or change in the otherwise
domU-dist-specific config file. I could accomplish this with sed, etc
in a role script, as mentioned below; I was just thinking it would be
more elegant to have a mechanism for this in the skel section of
things. Given your below comment, though, I think you still prefer
role scripts, and I'm definitely being overly idealistic here :)

>   I have an 'install cfengine' role which allows me to do this
>  post-install .. ;)

I'll take a look at that one and see what you did :)


Thanks again,
Jeff