Re: [lmi] dpkg error on redhat server

[Greg Chicares]

On 2019-10-09 20:36, Vadim Zeitlin wrote:
> On Wed, 9 Oct 2019 15:52:03 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-10-08 21:56, Vadim Zeitlin wrote:
> GC> > On Tue, 8 Oct 2019 21:51:07 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> [server]$ls -ld /srv/chroot/lmi_bullseye_1/opt/lmi
> GC> > GC> drwxr-xr-x 2 1007 su-secdesign 40 Oct  8 11:33 
> /srv/chroot/lmi_bullseye_1/opt/lmi
> GC> > GC>                   ^^^^^^^^^^^^ who ordered that?
> GC> 
> GC> That turns out to be the name of a group.
> 
>  Oh, yes, sure, this much was clear enough, I just didn't know if it was a
> standard group or one existing only on this server.

Only on this server, I think. My ID's primary group is 'unxdflt'.
Whoever chose that name must consider unix not to be the default
operating system for a unix server. I don't think redhat would
have picked such a group name.

> GC> But that was just the tip of the iceberg. I had never realized
> GC> how much these UIDs and GIDs matter, because every GNU/Linux
> GC> system I've ever worked with has greg:greg == 1000:1000 but
> GC> this server just wasn't set up that way. And I'd always thought
> GC> that UIDs and GIDs inside a chroot don't matter, because they've
> GC> always had the One True Value in my prior experience, so I never
> GC> needed to make sure they matched the host system's values--I just
> GC> figured they had their own namespace.
> 
>  No, this is the main difference between simple chroot and containers.

Well, live and learn, as they say. I'm also realizing that all that
stuff after the first three letters in rwx------ is actually important,
which it never was on a machine where either I own all the files I
normally use, or I'm root.

> Inside a container, all namespaces can be virtualized, including UIDs, but
> inside chroot, only the filesystem is virtualized and all the rest is
> shared with the main system. For my use it's actually more convenient
> precisely because it means I can reuse the same directories in both places,
> but containers definitely have an important advantage here (and I think you
> can avoid virtualizing UIDs with containers if you don't want to, while
> with chroot you don't have any choice).

The convenience of bind-mounting /home would introduce peril for me:
I would have erased everything several times by now.

>  I'm saying all this just because I start wondering if this low
> technological chroot approach is not costing us/you too much time, after
> all, and if maybe it would be better to invest a bit more time to create a
> Docker container for building lmi instead, that you could run on any system
> with Docker installed on it. But maybe it's too late to propose it now,
> when you've already spent so much time on this...

The chroot approach was best for now. I've had to learn many things
that I wish I'd learned long ago. And now I've managed to get this
server working up to the point where it has already built wx with
MinGW-w64 gcc-8.3.0 (debian 6.0.0-4); now all I need is to bind-mount
the correct directory for downloaded library tarballs, but I've at
last learned how to do that.

Maybe in the future we should use 'docker'. But learning how to do
this with chroots has been time well spent for me.