[xen-tools] Re: Various potential modifications

[C.J. Adams-Collier]

Hey there Jeff.

Following is some perl code I use to hide sensitive input.

Cheers,

C.J.


# Turn off echo, read password, ssn, turn echo back on
use Term::ReadKey;
ReadMode('noecho');
print("Enter Password: ");
my $password = ReadLine(0);
chomp $password;
print("\n");

print("Enter SSN: ");
my $ssn = ReadLine(0);
ReadMode(0);
chomp $ssn;
print("\n");

On 10/1/07, Jeff Forcier <jeff at bitprophet.org> wrote:
> 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
>
>
>


-- 
moo.