[xen-tools] Re: Various potential modifications

[Steve Kemp]

On Mon Oct 01, 2007 at 22:15:55 -0400, Jeff Forcier wrote:

> at least for me, more effective in the long run anyways.

  Great :)

> 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 :)

  Fine by me :)

> 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).

  I don't see why not.  After all I regard the auto-generation as
 a neat thing for people who create a *lot* of machines, rather than
 the average user.

  Besides a simple look like this will do the job:

  for i in $(seq 100 200) ; do echo "192.168.1.$i" >> ip.list; done

> 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],

  I'd be happy if there were two files, like this:

    available ->  Having a range
    used      ->  Recording the ones used.

  (Probably need better names than that though!)

> 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 honestly can't recall, and looking at the code it looks like I
 was mistaken.  Sorry!  I'll restore the previous behaviour ASAP.

> 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.

  Ahh that does make more sense.  I think the general case would be
 hard.  But a roles script is probably the way forward there ..

  Something like /etc/xen-tools/skell-trans containing *.sed and
 running each one if the specified file exists.

   eg:

    /etc/xen-tools/trans.d/etc/sshd_config.sed

  That should only be run if the file /etc/sshd_config exists in the
 guest.  I could add a role script to do that if you like?

  I like the idea of allowing people to make changes like this, but
 at the same time I don't want to add lots of special cases just to
 please one person at the expense of making things overly complicated
 for other users, if that makes sense?

Steve
-- 
http://www.steve.org.uk/