lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Creating an lmi schroot from scratch


From: Vadim Zeitlin
Subject: Re: [lmi] Creating an lmi schroot from scratch
Date: Wed, 10 Jun 2020 00:36:36 +0200

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 (it's not that I
suspect you of trying to install an NSA backdoor on my server, but my
machines are set up strangely enough that even scripts working perfectly
well in standard environments may malfunction here and I strongly prefer to
not let them malfunction with superuser permissions).

GC> su
GC> cd /tmp
GC> wget -N -nv 
https://git.savannah.nongnu.org/cgit/lmi.git/plain/lmi_setup_00.sh
GC> chmod +x lmi_setup_00.sh
GC> time flavor=centos ./lmi_setup_00.sh 
>/srv/cache_for_lmi/logs/chroot_log_$(date -u +"%Y%m%dT%H%MZ") 2>&1
GC> 
GC> It's been my habit to do that as root, but I believe you could just as
GC> well do it as a normal user, adding "sudo" on the last line, e.g.:
GC>   sudo flavor=centos ./lmi_setup_00.sh

 I indeed wouldn't run wget as root neither (it's not a paranoia if half of
the entire Internet is out to get you!), but my real holy grail would be to
run the setup script itself without superuser rights too.

GC> The script that's downloaded manually with wget, uses wget to download
GC> other scripts with similar names. If you have files in /tmp that you
GC> want to preserve, with names matching
GC>   lmi_setup_*.sh
GC>   install_msw.sh
GC>   schroot_env
GC>   .zshrc
GC>   .vimrc
GC>   en.utf-8.add
GC> then this script will overwrite them; I think it's reasonable to assume
GC> that's not a problem.

 It shouldn't be, but why not use "mktemp -d /tmp/lmi_XXXXXX" and create
these files there?

GC> In 'lmi_setup_02c.sh', I wasn't sure how to avoid accidental harm when
GC> obliterating any previously-created centos chroot, so for safety it
GC> just halts for you. Here's the dangerous code:
GC> 
GC> grep centos /proc/mounts | cut -f2 -d" " | xargs --no-run-if-empty umount
GC> rm -rf /srv/chroot/centos7lmi
GC> rm /etc/schroot/chroot.d/centos7lmi.conf
GC> 
GC> especially the first line, which destroys any mount containing the
GC> string 'centos'.

 Yes, this definitely makes me apprehensive:

        % grep -c centos /proc/mounts
        9

GC> I'm assuming you're using a debian-based system.

 Yes, and even my VMs are mostly Ubuntus (although I have a couple of
CentOSs too).

GC> Probably the script
GC> should check for that before invoking 'apt-get install rinse', but
GC> that should fail safely on a non-debian system (and all these scripts
GC> use 'set -e', so they halt on failure...but for 'lmi_setup_inc.sh'
GC> (see below), I assume without testing that
GC>   set -evx
GC>   ... "e" is enabled here
GC>   set +vx
GC>   ... "e" is still enabled here
GC> right?).

 Yes. And testing it is simple enough:

        % bash -c 'set -evx; echo Here; set +vx; false; echo There'
        + echo Here
        Here
        + set +vx

(and my prompt shows that the command exited with 1).

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.

 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.

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?

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

VZ

Attachment: pgpoAw1j5iAQQ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]