Re: [lmi] Creating an lmi schroot from scratch

[Greg Chicares]

On 2020-06-09 22:36, Vadim Zeitlin wrote:
> On Tue, 9 Jun 2020 20:29:25 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> I think this will work for you:
> 
>  I'll try this a.s.a.p., but I'll probably do it inside a VM to begin with
> because I'm really afraid of running shell script with su

Absolutely reasonable. It might be okay to be less cautious if I were
sharing a docker (e.g.) container and you trust their infrastructure,
but this is more like emulating docker on bare metal, and I know less
about containers than they do.

Would it be worthwhile to run the script as root, and prefix commands
with 'sudo' only where unavoidable? (I think not: root is dangerous
no matter how you gain it, and 'sudo' requires typing a password so
often that it creates a temptation to add NOPASSWD to /etc/sudoers,
making the system less secure.)

>  I indeed wouldn't run wget as root neither

Hmmm...I never thought of that.

> GC> I assume you won't mind that this suite of scripts installs 'rinse'.
> GC> or that it creates:
> GC>   /var/cache/centos_lmi/
> GC>   /etc/schroot/chroot.d/centos7lmi.conf
> GC>   /srv/chroot/
> GC>   /srv/cache_for_lmi
> 
>  Well... This is less easily defensible than my unwillingness to run
> big and complicated scripts as root, but I'd rather use my own directories,
> e.g. I'd prefer to create the caches on a non-RAID-1 disk which has more
> space and my other chroots live in /usr/local/chroot (they shouldn't, and
> /srv/chroot is a better path which I also use on other machines, but I'd
> rather not change this right now). As for /etc, it's under Git control here
> and I'd also rather create the config file there manually.

It might be worth setting all those directories into a global
configuration file if you foresee running these scripts often.
But I don't imagine you will.

I could be wrong, but I thought schroot insisted on using
  /etc/schroot/chroot.d
because without a fixed, known location, it wouldn't be able to list
available chroots.

>  All in all this just shows that I really shouldn't be running this on my
> main Linux system and should use a dedicated VM for this, where the script
> can do "rm -rf /etc" if it wants to without any real consequences.

It's that 1970s "do I feel lucky?" meme again.

> GC> These scripts can create a debian-testing chroot directly on a debian
> GC> or redhat system, but I'm suggesting you create a debian-within-centos
> GC> chroot ("flavor=centos").
> 
>  OTOH if I'm already running this in a VM, I don't even really care about
> doing the rest of things in a chroot. Can I somehow short-circuit
> everything and jump directly to after the chroot creation in this case?

Sure: just run 'gwc/redhat_rebuild.sh'. Despite its name, I think it'll
DTRT in a debian VM, because the script it runs does this:
  case "$(cat /proc/version)" in
    (*Debian*)    flavor_guess=debian ;;
    (*"Red Hat"*) flavor_guess=redhat ;;

>  Sorry for all these complications, I know that it's me and not you(r
> scripts), but maybe this helps to explain why I prefer running "configure
> && make" which definitely don't modify anything outside of the build
> directory on my main system...

But you still need root in the VM. Otherwise, you can't mount /dev/pts etc.

Oh, wait...you want to skip all that, even the chroot creation...then
edit 'lmi_setup_01.sh' and skip as much as you want. Maybe you don't need
any 'lmi_setup_NN' script with a number lower than 30 or even 40, which
means you don't need to run anything as root. If there are some steps in
the 20-29 range that you do need, you can apply those manually. You'll
probably still need these harmless files
  lmi_setup_inc.sh
  tmp/schroot_env
that are created in 'lmi_setup_0*.sh', but those don't require root.

And if you devise a way to use these scripts without root privileges,
maybe we can write an 'lmi_setup_00_rootless.sh' that would be quite
safe to run. I could even potentially use that on my debian-stable
system, now that 'stable' has a reasonable MinGW-w64 version.