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

Re: chroot: java fails



On Sat, Jan 05, 2008 at 03:59:40PM +0100, Heikki Levanto wrote:
> On Fri, Jan 04, 2008 at 12:11:01PM -0500, Douglas A. Tutty wrote:
> > Under what conditions would you need to boot the 32-bit chroot natively?
> 
> Hopefully none - but until it works perfectly, I need a way to get back
> there, so I can use my netbank (firefox, java, etc), and other things.
> Well, perhaps to run some performance tests, to show that my go program
> really is faster on a real 64-bit system. (well, I have to write that program
> first...)
> 
> > I access the chroot with 
> > $ schroot -pc etch-ia32
> > which means that I have the schroot package installed on the amd64
> > system.
> 
> 
> Thanks. The basic setup was surprisingly easy. I used the old root partition,
> so I did not have to install anything at all!  
> 
> I still had to (re?)mount my disks manually, haven't found where to tell
> schroot which disks I need mounted, or how to get them all right. 
> 
> I run into problems with X display not coming out. xeyes times out after some
> seconds with "Could not connect to :0". I fixed that by enabling tcp
> listening (in  vi /etc/kde3/kdm/kdmrc), and setting DISPLAY="127.0.0.1"
> inside the chroot. And a "xhost +" on the amd-64 side. Xeyes works, xine
> works! Firefox works - except when I try to go to my netbank (www.nordea.dk).
> I get the login screen, but the process dies in a few seconds, often in the
> middle of me typing in my password.
> 
> I am using a 'plain' schroot, since I already have the old root system
> mounted. Perhaps I should try with a block device type thing?

Here's my /etc/schroot/schroot.conf:

8>--
# schroot chroot definitions.
# See schroot.conf(5) for complete documentation of the file format.
#
# Please take note that you should not add untrusted users to
# root-groups, because they will essentially have full root access
# to your system.  They will only have root access inside the chroot,
# but that's enough to cause malicious damage.
#
#
#
#
[etch-ia32]
type=directory
description=Debian Etch ia32
groups=ssh
run-setup-scripts=true
run-exec-scripts=true
personality=linux32
location=/srv/chroot/etch-ia32

[snip commented out example lines]

8>--

Since /srv is its own LVM, it is its own block device, but it is always
mouted in the base amd64 system's fstab.  Therefore, this is a directory
type, which give auto-mounting and set up of networking, directories,
passwords, whatever.

The groups=ssh I put in.  On my box, as a bit of security, I only allow
members of the ssh group to run ssh.  Those same users are the ones I
would allow to run apps in the chroot.  There's a general rule that, for
security, you should never trust anyone in a chroot that you wouldn't
trust with root access on the main box.  This is probably overkill with
schroot but I didn't want just any random UID to run apps either.

I found that schroot ends up leaving schroot sessions active and then
restoring them on reboot.  Since I didn't want or need persistant
sessions and I shutdown every night, I removed the symlinks from
/etc/rc*.d to /etc/init.d/schroot.

Doug.


Reply to: