[gentoo-amd64] Wine with no-multilib on AMD64

[gentoo-amd64] Wine with no-multilib on AMD64

[Mansour Al Akeel]

Hello all,

I have been looking into installing wine and a cross dev tool chain. I
didn't get much luck, since I have amd64 and I use no-multilib. I found
this http://bugs.gentoo.org/269439 and I am wondering if any one can
provide an advice. Is it be possible to run wine on amd64 with
no-multilib ? 

Re: [gentoo-amd64] Wine with no-multilib on AMD64

[Volker Armin Hemmann]

On Samstag 13 März 2010, Mansour Al Akeel wrote:
> Hello all,
> 
> I have been looking into installing wine and a cross dev tool chain. I
> didn't get much luck, since I have amd64 and I use no-multilib. I found
> this http://bugs.gentoo.org/269439 and I am wondering if any one can
> provide an advice. Is it be possible to run wine on amd64 with
> no-multilib ?

you won't be able to run any 32bit windows app. Which makes wine pretty 
useless.

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Duncan]

Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
excerpted:

> On Samstag 13 März 2010, Mansour Al Akeel wrote:
>> Hello all,
>> 
>> I have been looking into installing wine and a cross dev tool chain. I
>> didn't get much luck, since I have amd64 and I use no-multilib. I found
>> this http://bugs.gentoo.org/269439 and I am wondering if any one can
>> provide an advice. Is it be possible to run wine on amd64 with
>> no-multilib ?
> 
> you won't be able to run any 32bit windows app. Which makes wine pretty
> useless.

FWIW, I have no-multilib, but with the 32-bit compatibility turned on in 
the kernel, I'm able to do the 32-bit chroot thing as in the gentoo/amd64 
documentation.

In my case, I'm doing a full 32-bit chroot image, which then gets 
transferred to my AA1 netbook.  (The big machine has far more memory and 
power to do the compiles, so it makes more sense to do that and not even 
have the gentoo tree on the netbook, just transfer over the prebuilt, 
preconfigured image, and rsync it again after every update.  I've never 
booted the 32-bit image on the big machine, tho, and indeed, couldn't, as 
the kernel drivers, etc, are all built-in and configured for the netbook.)

For just running 32-bit stuff on the same machine, tho, you'd not need the 
full system image, as you'd be able to skip stuff like syslog and the 
kernel, as they'd be 64-bit hosted.

That'd give you the 32-bit stuff including wine in its own little chroot, 
fully built from source as any Gentooer should appreciate, without 
dirtying up your 64-bit-clean no-mulilib main install as the 32-bit stuff 
would be in its own chroot, and without the compromise of the prebuilt 32-
bit libraries the typical multilib installation uses.  It's a bit more 
work to keep updated than a multilib install, but because the main install 
is 64-bit clean no-multilib, you don't have the broken 32-bit toolchain 
issues that seem to strike many multilib users after awhile.  (...that I 
got tired of after a few times, and that I was VERY glad to be rid of, 
when I dumped multilib myself.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Volker Armin Hemmann]

On Samstag 13 März 2010, Duncan wrote:
> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
> 
> excerpted:
> > On Samstag 13 März 2010, Mansour Al Akeel wrote:
> >> Hello all,
> >> 
> >> I have been looking into installing wine and a cross dev tool chain. I
> >> didn't get much luck, since I have amd64 and I use no-multilib. I found
> >> this http://bugs.gentoo.org/269439 and I am wondering if any one can
> >> provide an advice. Is it be possible to run wine on amd64 with
> >> no-multilib ?
> > 
> > you won't be able to run any 32bit windows app. Which makes wine pretty
> > useless.
> 
> FWIW, I have no-multilib, but with the 32-bit compatibility turned on in
> the kernel, I'm able to do the 32-bit chroot thing as in the gentoo/amd64
> documentation.
> 

so you wasted a lot of space. For what benefit again?

And - because you seem to lack some understanding. There is no 'dirtying up'. 
So please, keep your dubios advise down. Chrooting just to be able to run an 
app is not a good choice, if a few mb of 32bit libs, residing in /usr/lib32 
would be all that is needed.

> It's a bit more work to keep updated than a multilib install,

yeah, that too. So lets keep honest, ok? no-multilib+chroot means more work on 
maintenance, more work to set up. More compiling, more disk space wasted 
for... zero benefits.

Hm, yeah, sounds really great.

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Duncan]

Volker Armin Hemmann posted on Sun, 14 Mar 2010 00:27:20 +0100 as
excerpted:

> so you wasted a lot of space. For what benefit again?

What, you can't even read?  In the same message you quoted part of, I 
explained why -- I build my (32-bit only) netbook image in that chroot, on 
my main machine.  I then rsync the completely build and configured image 
to my netbook, thus allowing me to run Gentoo on the netbook without 
having to actually /build/ Gentoo on the netbook.

> And - because you seem to lack some understanding. There is no 'dirtying
> up'. So please, keep your dubios advise down. Chrooting just to be able
> to run an app is not a good choice, if a few mb of 32bit libs, residing
> in /usr/lib32 would be all that is needed.

Well, depending on what you consider dirtying it up.  If you consider 
unnecessarily installing a somewhat brittle dual-bitness toolchain that 
has an annoying tendency to have the 32-bit side break at times "dirtying 
up", if you consider it installing only generically optimized 32-bit 
binary-only emul-linux libraries "dirtying up", then yes, it's definitely 
"dirtying up".  Certainly so as opposed to a separate full 32-bit chroot, 
thus allowing the 64-bit side to stay clean 64-bit (no brittle dual-
bitness toolchain), and no compromise only generic optimizations binary 
emul-linux libraries.

Now a 32-bit chroot is definitely more work than standard multilib, but 
it's also definitely cleaner, and from personal experience, less brittle.  
It's also far more flexible.  Whether it's worth the tradeoff is for an 
individual to decide.

I was simply posting that the 32-bit chroot thing is possible with
no-multilib, something that's poorly documented, so some people might not 
realize it's even possible.  (They may think that multilib is required for 
it.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Nikos Chantziaras]

On 03/14/2010 02:34 AM, Duncan wrote:
> Volker Armin Hemmann posted on Sun, 14 Mar 2010 00:27:20 +0100 as
> excerpted:
>
>> so you wasted a lot of space. For what benefit again?
>
> What, you can't even read?  In the same message you quoted part of, I
> explained why -- I build my (32-bit only) netbook image in that chroot, on
> my main machine.  I then rsync the completely build and configured image
> to my netbook, thus allowing me to run Gentoo on the netbook without
> having to actually /build/ Gentoo on the netbook.

This thread is about running Wine though, not about building a 32bit 
Gentoo image on AMD64 :P

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Mansour Al Akeel]

Hello Duncan:
Pleae read my comments.

On Sat Mar 13,2010 10:20 pm, Duncan wrote:
> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
> excerpted:
> 
> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
> >> Hello all,
> >> 
> >> I have been looking into installing wine and a cross dev tool chain. I
> >> didn't get much luck, since I have amd64 and I use no-multilib. I found
> >> this http://bugs.gentoo.org/269439 and I am wondering if any one can
> >> provide an advice. Is it be possible to run wine on amd64 with
> >> no-multilib ?
> > 
> > you won't be able to run any 32bit windows app. Which makes wine pretty
> > useless.
> 
> FWIW, I have no-multilib, but with the 32-bit compatibility turned on in 
> the kernel, I'm able to do the 32-bit chroot thing as in the gentoo/amd64 
> documentation.
> 
> In my case, I'm doing a full 32-bit chroot image, which then gets 
> transferred to my AA1 netbook.  (The big machine has far more memory and 
> power to do the compiles, so it makes more sense to do that and not even 
> have the gentoo tree on the netbook, just transfer over the prebuilt, 
> preconfigured image, and rsync it again after every update.  I've never 
> booted the 32-bit image on the big machine, tho, and indeed, couldn't, as 
> the kernel drivers, etc, are all built-in and configured for the netbook.)

Are you saying that you have another 32bit gentoo image, and you mount it
somewhere and chroot to it? If so, what does the memory has to do with this ?
Can you please elaborate on this ? The space is not a concern to me, but
I'd rather not mix 32 and 64 libs.

> 
> For just running 32-bit stuff on the same machine, tho, you'd not need the 
> full system image, as you'd be able to skip stuff like syslog and the 
> kernel, as they'd be 64-bit hosted.
> 
> That'd give you the 32-bit stuff including wine in its own little chroot, 
> fully built from source as any Gentooer should appreciate, without 
> dirtying up your 64-bit-clean no-mulilib main install as the 32-bit stuff 
> would be in its own chroot, and without the compromise of the prebuilt 32-
> bit libraries the typical multilib installation uses.  It's a bit more 
> work to keep updated than a multilib install, but because the main install 
> is 64-bit clean no-multilib, you don't have the broken 32-bit toolchain 
> issues that seem to strike many multilib users after awhile.  (...that I 
> got tired of after a few times, and that I was VERY glad to be rid of, 
> when I dumped multilib myself.)
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 
> 

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Duncan]

Mansour Al Akeel posted on Mon, 15 Mar 2010 15:04:49 -0300 as excerpted:

> Hello Duncan:
> Pleae read my comments.
> 
> On Sat Mar 13,2010 10:20 pm, Duncan wrote:
>> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
>> excerpted:
>> 
>> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
>> >> Hello all,
>> >> 
>> >> I have been looking into installing wine and a cross dev tool chain.
>> >> I didn't get much luck, since I have amd64 and I use no-multilib. I
>> >> found this http://bugs.gentoo.org/269439 and I am wondering if any
>> >> one can provide an advice. Is it be possible to run wine on amd64
>> >> with no-multilib ?
>> > 
>> > you won't be able to run any 32bit windows app. Which makes wine
>> > pretty useless.
>> 
>> FWIW, I have no-multilib, but with the 32-bit compatibility turned on
>> in the kernel, I'm able to do the 32-bit chroot thing as in the
>> gentoo/amd64 documentation.
>> 
>> In my case, I'm doing a full 32-bit chroot image, which then gets
>> transferred to my AA1 netbook.  (The big machine has far more memory
>> and power to do the compiles, so it makes more sense to do that and not
>> even have the gentoo tree on the netbook, just transfer over the
>> prebuilt, preconfigured image, and rsync it again after every update. 
>> I've never booted the 32-bit image on the big machine, tho, and indeed,
>> couldn't, as the kernel drivers, etc, are all built-in and configured
>> for the netbook.)
> 
> Are you saying that you have another 32bit gentoo image, and you mount
> it somewhere and chroot to it? If so, what does the memory has to do
> with this ? Can you please elaborate on this ? The space is not a
> concern to me, but I'd rather not mix 32 and 64 libs.

Yes.  I have a 32-bit chroot image that gets mounted and chrooted into 
(using linux32 chroot ...) as per the gentoo/amd64 32-bit chroot guide.  
That works just fine with no-multilib, and indeed, multilib would 
duplicate functionality to some degree.  Just make sure your kernel has
32-bit "emulation" turned on (tho it's not really emulation, in the same 
way that wine is not an emulator, amd64/x86_64 is true dual-bitness 
hardware).

I posted the link to the guide in the doomsday thread pretty much 
concurrently to the discussion here, but for convenience, here's the link:

http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2

That explains the process and covers the step-by-step quite nicely.  I 
discuss it in more depth in the doomsday thread, so I'd suggest you read 
it if you're seriously interested in this.  Meanwhile...

As mentioned, I use the 32-bit chroot for a somewhat different purpose, 
building a separate 32-bit image to run on my 32-bit-only netbook.  As 
such, I have a fully configured and bootable build-out of the 32-bit as if 
it were an entirely separate machine, even if I never boot to it on this 
machine, because it is intended to run on a separate machine.  However, 
while that's a reasonably trivial extension from the 32-bit chroot guide, 
it's not why it was written, nor what it directly addresses.  But as you 
specify, it's definitely entirely separate, no mixed 32/64-bit as multilib 
does, or it'd be unsuitable for the 32-bit-only machine usage to which I 
put it.  So rest assured on that point.  The only mixing between the two 
systems are mount-binds setup to expose stuff like a common tempdir 
between the two systems (and of course that you happen to be running on a 
64-bit host kernel in the first place), and it's relatively trivial to 
simply not mount-bind what you specifically don't need.  If you're 
familiar with chroots, mount-binds for access within the chroot are pretty 
standard stuff, and it /is/ a chroot, so it's as entirely separate as a 
chroot normally would be.

As to your specific question "what does the memory have to do with this?", 
I don't quite understand the question, so pardon my not answering it 
specifically.

Unless of course you're referring to the fact that you can't normally 
combine 32-bit apps with 64-bit libs, or the reverse, a typical source of 
newbie confusion (and quite some emerge bugs when the build happens across 
the wrong bitness lib before it sees the correct one) on multilib setups.

That, IMO, is one of the advantages of the separate 32-bit chroot concept, 
particularly with no-multilib.  The main 64-bit system basically doesn't 
know it's there, it's just data to it, and the 32-bit chroot of course 
only knows about the parts of the 64-bit system that you've exposed to it 
thru bind-mounts, so there's very little chance of getting things mixed 
up, unless you deliberately mount a 64-bit libdir into the chroot or 
something, and as Gentooers should know by now, Gentoo does specifically 
allow you to (metaphorically) point a loaded gun at yourself and pull the 
trigger if you want, which is about what deliberately mounting a 64-bit 
libdir into the chroot would be doing.

So... read my detailed response in the doomsday thread and the chroot 
guide, and that should give you a far better idea of whether what we're 
talking about is useful for you or not.

Personally, I don't know.  Honestly, it's definitely a lot of work, 
perhaps more than you're willing to put into it.

You might be able to do what you want, and would arguably be better off, 
switching to a multilib profile and starting with a standard 64-bit 
stage-3 tarball again, to rebuild your Linux-side toolchain as multilib.  
That'll be some work now, but will definitely be less work maintaining 
than a 32-bit chroot.  Unfortunately I don't know enough about the wine 
and MS platform cross-dev toolchain bit to evaluate what problems you 
might or might not have with that.  I'm simply assuming it'll "just work" 
with a multilib profile, but that's a best-case assumption.

OTOH, the 32-bit chroot concept, while definitely more work maintaining 
(it's roughly comparable work immediately to switching back to multilib, 
starting again from a standard multilib-compatible amd64 stage-3 tarball, 
but the 32-bit chroot will be more work maintaining over time as you'll be 
having to update stuff both on the main machine and in the chroot), *IS* a 
cleaner, more logically separate, solution.  And, installing a 32-bit wine/
MS-platform cross-dev is much more likely a known quantity with any bug 
you might happen across much more common, than the dual bitness multilib 
concept.

The thought occurs to me that it may hinge on 64-bit MS cross-dev status 
and whether you anticipate doing both 32-bit and 64-bit development, or 
only 32-bit.  It's possible multilib would enable both, while you'd very 
likely have to have separate 32-bit and 64-bit cross-dev arrangements too, 
if your Linux host is separate 32-bit and 64-bit, as with the chroot 
solution.  If you're not interested in the 64-bit MS side at all, that's 
not an issue.  Likewise if your cross-dev solution doesn't include a
64-bit MS side at all.  But if you are and it does, then going the 
separate 32-bit chroot route on the Linux side probably necessitates a 
separate cross-dev for each as well, thus an even higher continuing 
maintenance burden choosing the separate chroot route.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Sebastian Beßler]

Am 16.03.2010 02:56, schrieb Duncan:

> I posted the link to the guide in the doomsday thread pretty much 
> concurrently to the discussion here, but for convenience, here's the link:
> 
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2

What I don't like with this guide is that you have to be root to chroot
into and run the applications as root inside of the chroot.

schroot could be a way to get around this, but I can't test because
schroot fails to build here. So atm I try something with a sshd running
inside the chroot.

I think the guide should be extended to cover one way or more. Maybe
when done with it I write something with my experiences, problems and
solutions.

Greetings

Sebastian

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Nikos Chantziaras]

On 03/16/2010 11:23 AM, Sebastian Beßler wrote:
> Am 16.03.2010 02:56, schrieb Duncan:
>
>> I posted the link to the guide in the doomsday thread pretty much
>> concurrently to the discussion here, but for convenience, here's the link:
>>
>> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>
> What I don't like with this guide is that you have to be root to chroot
> into and run the applications as root inside of the chroot.

Wait a minute.  You're telling me that all the people who posted that 
they use chroot in order to have a "clean 64bit" system are actually 
running all their 32bit application as root and still consider the 
chroot a viable alternative to multilib?

I have only one word to describe this:

PHAIL.

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Sebastian Beßler]

Am Dienstag, 16. März 2010 12:01:38 schrieb Nikos Chantziaras:
> On 03/16/2010 11:23 AM, Sebastian Beßler wrote:
> > Am 16.03.2010 02:56, schrieb Duncan:
> >> I posted the link to the guide in the doomsday thread pretty much
> >> concurrently to the discussion here, but for convenience, here's the
> >> link:
> >> 
> >> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> > 
> > What I don't like with this guide is that you have to be root to chroot
> > into and run the applications as root inside of the chroot.
> 
> Wait a minute.  You're telling me that all the people who posted that
> they use chroot in order to have a "clean 64bit" system are actually
> running all their 32bit application as root and still consider the
> chroot a viable alternative to multilib?

If you follow the guide word by word and do nothing more then:
Yes, as far as I understand the guide. But it is "only" root in a chroot.. I 
know that is not better at all.
 
> I have only one word to describe this:
> 
> PHAIL.

Exactly that is why I work something out to use my user account inside the 
chroot. I need the 32bit chroot because I have still some programms that I 
can't get to work with multilib on Gentoo. I tried already the multilib-
overlay but that was a total failure for me. 

Oh and I do it because I really like to try new (new for me at last) stuff all 
the time, if it is complicated then it is only better.. ;-) Thats why I love 
Gentoo, you can break so much so easy :-D

Greetings

Sebastian

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Duncan]

Nikos Chantziaras posted on Tue, 16 Mar 2010 13:01:38 +0200 as excerpted:

> On 03/16/2010 11:23 AM, Sebastian Beßler wrote:
>> Am 16.03.2010 02:56, schrieb Duncan:
>>
>>> I posted the link to the guide in the doomsday thread pretty much
>>> concurrently to the discussion here, but for convenience, here's the
>>> link:
>>>
>>> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>>
>> What I don't like with this guide is that you have to be root to chroot
>> into and run the applications as root inside of the chroot.
> 
> Wait a minute.  You're telling me that all the people who posted that
> they use chroot in order to have a "clean 64bit" system are actually
> running all their 32bit application as root and still consider the
> chroot a viable alternative to multilib?
> 
> I have only one word to describe this:
> 
> PHAIL.

Actually, neither the invoking nor the invoked side are root here.  Here's 
how I handle it.

1)  I use chroot's --userspec=UID:GID option so I end up as the specified 
user -- not root -- in the chroot.  The guide doesn't mention this, 
unfortunately, but the chroot manpage does, and when I got tired of su-ing 
back to a normal user, it was easy enough to lookup, and then to change my 
invoking scripts, accordingly. =:^)

2)  On the invoking side, I have sudo setup to authorize the specific 
linux32 chroot command used, so while it's executed as root, the user 
never sees it, and sudo can be set to only allow that specific command 
with those specific parameters (including the --userspec bit), so that 
bit's reasonably locked down.

3)  Since the allowed command is a fixed string of some length, it makes 
sense to setup either a scriptlet or an alias, invoked with a much shorter 
command.  Since in my case, the chroot is the image for my Acer Aspire One 
netbook, I use the scriptlet name "aastart".

4)  I also scripted the chroot setup, called "aamount", that handles all 
the bind-mounts, etc, and have that invokable using sudo as well.  I 
separated the setup from the actual chroot entry command as it can be 
useful to run multiple sessions, all in the same chroot.  So I run the 
setup script once, and can then run aastart multiple times as desired.  
There's a similar "aaumount" script that tears down the setup, umounting 
all the mount-binds, etc.

But you're right that the --userspec bit should really be documented in 
the guide.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Tue, Mar 16, 2010 at 10:23:06AM +0100, Sebastian Beßler wrote:
> Am 16.03.2010 02:56, schrieb Duncan:
> 
> > I posted the link to the guide in the doomsday thread pretty much 
> > concurrently to the discussion here, but for convenience, here's the link:
> > 
> > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> 
> What I don't like with this guide is that you have to be root to chroot
> into and run the applications as root inside of the chroot.

You don't need to be root in the chroot to run applications. Just create
a user in the chroot and switch:

su - youruser

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-amd64] Secure chroot (was: Re: Wine with no-multilib on AMD64)

[Sebastian Beßler]

Am Dienstag, 16. März 2010 12:22:56 schrieb Alex Alexander:
> On Tue, Mar 16, 2010 at 10:23:06AM +0100, Sebastian Beßler wrote:
> > Am 16.03.2010 02:56, schrieb Duncan:
> > > I posted the link to the guide in the doomsday thread pretty much
> > > concurrently to the discussion here, but for convenience, here's the
> > > link:
> > > 
> > > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> > 
> > What I don't like with this guide is that you have to be root to chroot
> > into and run the applications as root inside of the chroot.
> 
> You don't need to be root in the chroot to run applications. Just create
> a user in the chroot and switch:
> 
> su - youruser

That is not really a solution, because all it need to be root again is a 
simple exit.  And chroot-root can break out of the chroot without problem. 

And you still need to be root to enter the chroot so you must always type in 
your root password to start a simple app, even if you drop root inside the 
chroot. So this is nothing more then a really fragile hack, to me at last.

Greetings

Sebastian

[gentoo-amd64] Re: Secure chroot (was: Re: Wine with no-multilib on AMD64)

[Duncan]

Sebastian Beßler posted on Tue, 16 Mar 2010 13:27:46 +0100 as excerpted:

> That is not really a solution, because all it need to be root again is a
> simple exit.  And chroot-root can break out of the chroot without
> problem.

See the chroot --userspec option in its manpage...

> And you still need to be root to enter the chroot so you must always
> type in your root password to start a simple app, even if you drop root
> inside the chroot.

Not if you have sudo configured properly.  Then the user uses their normal 
password, or none, if sudo is set for no password verification for that 
command.  And since sudo is configurable per command including the passed 
parameters, it's possible to specifically allow only the single command

"sudo linux32 chroot --userspec=xxx:yyy /mnt/point /bin/bash"

... and to configure it to require, or not require, entering the user 
password, as desired.  (FWIW, sudo can also be configured to require the 
changed /to/ user's password, instead of the changed /from/ user's 
password, so to require root's password here since it's root we're 
changing to, to do the chroot, but that's a global setting that would 
apply to all sudo usage on the system, while the require a password or not 
setting is per configured allowed command or group of commands.)

> So this is nothing more then a really fragile hack, to me at last.

I won't argue that it's not a hack, but it isn't really more so, or more 
fragile, IMO, than the whole multilib thing.  And it does keep the 32-bit 
and 64-bit sides better separated.  So pick your hack. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Secure chroot (was: Re: Wine with no-multilib on AMD64)

[Sebastian Beßler]

Am Dienstag, 16. März 2010 14:25:46 schrieb Duncan:

> I won't argue that it's not a hack, but it isn't really more so, or more
> fragile, IMO, than the whole multilib thing.  And it does keep the 32-bit
> and 64-bit sides better separated.  So pick your hack. =:^)

With hack I had "su - youruser" in mind. 

Your way looks quite nice, I will look into it when I am back home. 
Btw. the ubuntu manpage of chroot (at work I use ubuntu) does not mention 
--userspec (or maybe I am still to dumb to use man ;-) 

Alex tipp is interessting too, thx for that.

Greetings

Sebastian

[gentoo-amd64] Re: Secure chroot (was: Re: Wine with no-multilib on AMD64)

[Duncan]

Sebastian Beßler posted on Tue, 16 Mar 2010 17:24:55 +0100 as excerpted:

> Your way looks quite nice, I will look into it when I am back home. Btw.
> the ubuntu manpage of chroot (at work I use ubuntu) does not mention
> --userspec (or maybe I am still to dumb to use man ;-)

It's possible the --userspec option is relatively new to chroot, tho I'd 
not expect so.  FWIW I'm using ~amd64, so have never versions of a lot of 
packages than stable will.

It's also possible that ubuntu is using an old (or possibly POSIX-only) 
manpage.  What does chroot --help list?  Here, --userspec is the first 
option listed (the other one besides help and version being --groups, 
which takes a list of supplementary groups that the user will appear in, 
while in the chroot).

One thing that's unclear to me is whether the userspec and groups 
parameters use the IDs from the running system or the chroot, tho I 
suspect it's the running system (I started with the same passwd, etc files 
in both, here, because as I said I need a full config for my usage and 
that was most convenient).

I did notice that I had to use the actual UID:GID numbers, altho the 
manpage said names should work too.  I figured that was due to some 
vagaries of configuration, but finding and using the numbers was no big 
deal, so I didn't worry about it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Secure chroot (was: Re: Wine with no-multilib on AMD64)

[David Fellows]

On Tue, 16 Mar 2010 23:38:49 +0000 (UTC) 
Duncan wrote -
> 
> It's possible the --userspec option is relatively new to chroot, tho I'd=20
> not expect so.  FWIW I'm using ~amd64, so have never versions of a lot of=
> =20
> packages than stable will.

Ubuntu Karmic Koala provides coreutiils-7.4 which does not have --userspec
Gentoo stable provides -7.5 which does have it
Gentoo unstable provides -8.4

Dave F

Re: [gentoo-amd64] Secure chroot (was: Re: Wine with no-multilib on AMD64)

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Tue, Mar 16, 2010 at 01:27:46PM +0100, Sebastian Beßler wrote:
> Am Dienstag, 16. März 2010 12:22:56 schrieb Alex Alexander:
> > On Tue, Mar 16, 2010 at 10:23:06AM +0100, Sebastian Beßler wrote:
> > > Am 16.03.2010 02:56, schrieb Duncan:
> > > > I posted the link to the guide in the doomsday thread pretty much
> > > > concurrently to the discussion here, but for convenience, here's the
> > > > link:
> > > > 
> > > > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> > > 
> > > What I don't like with this guide is that you have to be root to chroot
> > > into and run the applications as root inside of the chroot.
> > 
> > You don't need to be root in the chroot to run applications. Just create
> > a user in the chroot and switch:
> > 
> > su - youruser
> 
> That is not really a solution, because all it need to be root again is a 
> simple exit.  And chroot-root can break out of the chroot without problem. 
> 
> And you still need to be root to enter the chroot so you must always type in 
> your root password to start a simple app, even if you drop root inside the 
> chroot. So this is nothing more then a really fragile hack, to me at last.
> 
> Greetings
> 
> Sebastian

I have a script that runs su - wired and I run that instead of /bin/bash
(in my chroot script after all the necessary mounting, ofcourse)

	sudo chroot my_chroot /usr/local/bin/init_chroot_wired

that script ends with an "exit"

	### /usr/local/bin/init_chroot_wired in my chroot ###

	#!/bin/bash
	env-update
	source /etc/profile
	su - wired
	exit

so when I exit the chroot it dies instead of dropping me to the root
chroot shell.

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Mansour Al Akeel]

When you change root, just swith to the user you want. For example, 

su mansour.




On Tue Mar 16,2010 10:23 am, Sebastian Be??ler wrote:
> Am 16.03.2010 02:56, schrieb Duncan:
> 
> > I posted the link to the guide in the doomsday thread pretty much 
> > concurrently to the discussion here, but for convenience, here's the link:
> > 
> > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> 
> What I don't like with this guide is that you have to be root to chroot
> into and run the applications as root inside of the chroot.
> 
> schroot could be a way to get around this, but I can't test because
> schroot fails to build here. So atm I try something with a sshd running
> inside the chroot.
> 
> I think the guide should be extended to cover one way or more. Maybe
> when done with it I write something with my experiences, problems and
> solutions.
> 
> Greetings
> 
> Sebastian
> 

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Mansour Al Akeel]

Thank you Duncan,
I checked this yesterday. In fact I was considering the idea of a
chroot last. And I didn't know there's a guide for it. The guide served
as a refrence in case I forgot something. 

In my case, having a separate 32 bit is a better option, since I have a
huge external hard disk, and use it mostely as a bootable server for
development and testing. In case I run low on resources on my laptop, I
just plug this usb drive in any PC and I have a fully running server to
deploy and test. After all, I don't that the chroot, is taking a lot of
room on my disk, and I'd rather not to use multilib for bad experience I
had with it, few years ago.

Things are working great for now. 


On Tue Mar 16,2010 01:56 am, Duncan wrote:
> Mansour Al Akeel posted on Mon, 15 Mar 2010 15:04:49 -0300 as excerpted:
> 
> > Hello Duncan:
> > Pleae read my comments.
> > 
> > On Sat Mar 13,2010 10:20 pm, Duncan wrote:
> >> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
> >> excerpted:
> >> 
> >> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
> >> >> Hello all,
> >> >> 
> >> >> I have been looking into installing wine and a cross dev tool chain.
> >> >> I didn't get much luck, since I have amd64 and I use no-multilib. I
> >> >> found this http://bugs.gentoo.org/269439 and I am wondering if any
> >> >> one can provide an advice. Is it be possible to run wine on amd64
> >> >> with no-multilib ?
> >> > 
> >> > you won't be able to run any 32bit windows app. Which makes wine
> >> > pretty useless.
> >> 
> >> FWIW, I have no-multilib, but with the 32-bit compatibility turned on
> >> in the kernel, I'm able to do the 32-bit chroot thing as in the
> >> gentoo/amd64 documentation.
> >> 
> >> In my case, I'm doing a full 32-bit chroot image, which then gets
> >> transferred to my AA1 netbook.  (The big machine has far more memory
> >> and power to do the compiles, so it makes more sense to do that and not
> >> even have the gentoo tree on the netbook, just transfer over the
> >> prebuilt, preconfigured image, and rsync it again after every update. 
> >> I've never booted the 32-bit image on the big machine, tho, and indeed,
> >> couldn't, as the kernel drivers, etc, are all built-in and configured
> >> for the netbook.)
> > 
> > Are you saying that you have another 32bit gentoo image, and you mount
> > it somewhere and chroot to it? If so, what does the memory has to do
> > with this ? Can you please elaborate on this ? The space is not a
> > concern to me, but I'd rather not mix 32 and 64 libs.
> 
> Yes.  I have a 32-bit chroot image that gets mounted and chrooted into 
> (using linux32 chroot ...) as per the gentoo/amd64 32-bit chroot guide.  
> That works just fine with no-multilib, and indeed, multilib would 
> duplicate functionality to some degree.  Just make sure your kernel has
> 32-bit "emulation" turned on (tho it's not really emulation, in the same 
> way that wine is not an emulator, amd64/x86_64 is true dual-bitness 
> hardware).
> 
> I posted the link to the guide in the doomsday thread pretty much 
> concurrently to the discussion here, but for convenience, here's the link:
> 
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> 
> That explains the process and covers the step-by-step quite nicely.  I 
> discuss it in more depth in the doomsday thread, so I'd suggest you read 
> it if you're seriously interested in this.  Meanwhile...
> 
> As mentioned, I use the 32-bit chroot for a somewhat different purpose, 
> building a separate 32-bit image to run on my 32-bit-only netbook.  As 
> such, I have a fully configured and bootable build-out of the 32-bit as if 
> it were an entirely separate machine, even if I never boot to it on this 
> machine, because it is intended to run on a separate machine.  However, 
> while that's a reasonably trivial extension from the 32-bit chroot guide, 
> it's not why it was written, nor what it directly addresses.  But as you 
> specify, it's definitely entirely separate, no mixed 32/64-bit as multilib 
> does, or it'd be unsuitable for the 32-bit-only machine usage to which I 
> put it.  So rest assured on that point.  The only mixing between the two 
> systems are mount-binds setup to expose stuff like a common tempdir 
> between the two systems (and of course that you happen to be running on a 
> 64-bit host kernel in the first place), and it's relatively trivial to 
> simply not mount-bind what you specifically don't need.  If you're 
> familiar with chroots, mount-binds for access within the chroot are pretty 
> standard stuff, and it /is/ a chroot, so it's as entirely separate as a 
> chroot normally would be.
> 
> As to your specific question "what does the memory have to do with this?", 
> I don't quite understand the question, so pardon my not answering it 
> specifically.
> 
> Unless of course you're referring to the fact that you can't normally 
> combine 32-bit apps with 64-bit libs, or the reverse, a typical source of 
> newbie confusion (and quite some emerge bugs when the build happens across 
> the wrong bitness lib before it sees the correct one) on multilib setups.
> 
> That, IMO, is one of the advantages of the separate 32-bit chroot concept, 
> particularly with no-multilib.  The main 64-bit system basically doesn't 
> know it's there, it's just data to it, and the 32-bit chroot of course 
> only knows about the parts of the 64-bit system that you've exposed to it 
> thru bind-mounts, so there's very little chance of getting things mixed 
> up, unless you deliberately mount a 64-bit libdir into the chroot or 
> something, and as Gentooers should know by now, Gentoo does specifically 
> allow you to (metaphorically) point a loaded gun at yourself and pull the 
> trigger if you want, which is about what deliberately mounting a 64-bit 
> libdir into the chroot would be doing.
> 
> So... read my detailed response in the doomsday thread and the chroot 
> guide, and that should give you a far better idea of whether what we're 
> talking about is useful for you or not.
> 
> Personally, I don't know.  Honestly, it's definitely a lot of work, 
> perhaps more than you're willing to put into it.
> 
> You might be able to do what you want, and would arguably be better off, 
> switching to a multilib profile and starting with a standard 64-bit 
> stage-3 tarball again, to rebuild your Linux-side toolchain as multilib.  
> That'll be some work now, but will definitely be less work maintaining 
> than a 32-bit chroot.  Unfortunately I don't know enough about the wine 
> and MS platform cross-dev toolchain bit to evaluate what problems you 
> might or might not have with that.  I'm simply assuming it'll "just work" 
> with a multilib profile, but that's a best-case assumption.
> 
> OTOH, the 32-bit chroot concept, while definitely more work maintaining 
> (it's roughly comparable work immediately to switching back to multilib, 
> starting again from a standard multilib-compatible amd64 stage-3 tarball, 
> but the 32-bit chroot will be more work maintaining over time as you'll be 
> having to update stuff both on the main machine and in the chroot), *IS* a 
> cleaner, more logically separate, solution.  And, installing a 32-bit wine/
> MS-platform cross-dev is much more likely a known quantity with any bug 
> you might happen across much more common, than the dual bitness multilib 
> concept.
> 
> The thought occurs to me that it may hinge on 64-bit MS cross-dev status 
> and whether you anticipate doing both 32-bit and 64-bit development, or 
> only 32-bit.  It's possible multilib would enable both, while you'd very 
> likely have to have separate 32-bit and 64-bit cross-dev arrangements too, 
> if your Linux host is separate 32-bit and 64-bit, as with the chroot 
> solution.  If you're not interested in the 64-bit MS side at all, that's 
> not an issue.  Likewise if your cross-dev solution doesn't include a
> 64-bit MS side at all.  But if you are and it does, then going the 
> separate 32-bit chroot route on the Linux side probably necessitates a 
> separate cross-dev for each as well, thus an even higher continuing 
> maintenance burden choosing the separate chroot route.
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 
> 

Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Mansour Al Akeel]

One last quesiton related to the cross compiler. I find the documentaion
for this are incomplete, and not very clear, and in many cases links are
broken. I have followed this page to get mingw ready:
http://www.gentoo-wiki.info/MinGW

I am not using any overlay. So things should be simple. I am using the
xmerge script and "export SYSROOT=/usr/i686-mingw32/"

$ cat /etc/make.conf
CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
CHOST="i686-pc-linux-gnu"
MAKEOPTS="-j2"
PORTDIR_OVERLAY="/usr/local/portage"




$ cat /usr/i686-mingw32/etc/make.conf
ARCH="i686"
CFLAGS="-Os -pipe"
CXXFLAGS="${CFLAGS}"
CHOST="i686-mingw32"
INPUT_DEVICES="keyboard"
MAKEOPTS="-j2"
USE="symlink"


When I try to install dbus, I get this: 
$ xmerge dbus

!!! /usr/i686-mingw32/etc/make.profile is not a symlink and will probably prevent most merges.
!!! It should point into a profile within /usr/portage/profiles/
!!! (You can safely ignore this message when syncing. It's harmless.)


!!! If you have just changed your profile configuration, you should revert
!!! back to the previous configuration. Due to your current profile being
!!! invalid, allowed actions are limited to --help, --info, --sync, and
!!! --version.


What does this mean, and what should be the profile to use. 
Again, I am running under amd64 (intel i5), and chroot to 32bit
enviroment. I want to compile for windows. 

Thank you.

[gentoo-amd64] Re: Wine with no-multilib on AMD64

[Duncan]

Mansour Al Akeel posted on Tue, 16 Mar 2010 18:18:02 -0300 as excerpted:

> One last quesiton related to the cross compiler.

That one's out of my domain.  If no one answers it, consider posting as a 
new thread, as it's no longer no-multilib related, and for philosophical 
reasons I stay as far away from proprietaryware including MS as I can get.

Also note that within the chroot, you're effectively running 32-bit only, 
so if necessary you can post to the general user list and/or to the 
forums, and x86 user answers will normally apply to you as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman