headers
FreeBSD bugmaster | 1 Aug 2011 13:07
Picon
Favicon

freebsd-jail@...

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/156111  jail       [jail] procstat -b not supported in jail
o misc/155765  jail       [patch] `buildworld' does not honors WITHOUT_JAIL
o conf/154246  jail       [jail] [patch] Bad symlink created if devfs mount poin
o conf/149050  jail       [jail] rcorder ``nojail'' too coarse for Jail+VNET
s conf/142972  jail       [jail] [patch] Support JAILv2 and vnet in rc.d/jail
o conf/141317  jail       [patch] uncorrect jail stop in /etc/rc.d/jail
o kern/133265  jail       [jail] is there a solution how to run nfs client in ja
o kern/119842  jail       [smbfs] [jail] "Bad address" with smbfs inside a jail
o bin/99566    jail       [jail] [patch] fstat(1) according to specified jid
o bin/32828    jail       [jail] w(1) incorrectly handles stale utmp slots with 

10 problems total.
Permalink | Reply | 0 comments |
headers
joris dedieu | 7 Aug 2011 20:42
Picon
Gravatar

Re: New jail(8) with configuration files, not yet in head

2011/8/7 Simon L. B. Nielsen <simon@...>:
>
> On 19 Jul 2011, at 19:14, Jamie Gritton wrote:
>
>> On 07/18/11 13:08, Paul Schenkeveld wrote:
>>
>>> Although I really like this new functionality, there is one issue that
>>> I am concerned about.  Should all this functionality be integrated into
>>> the jail(8) command?
>>
>> This project came from a desire to improve the jail startup procedure in rc.d/jail, which remains stuck
handling the old fixed-parameter jails. Rather that continue to extend an already unwieldy number of
rc.conf shell variables, I opted to add a configuration file like other subsystems use (e.g. apmd, devd).
 The new jail pseudo-parameters added to the config file exist mostly to match the existing rc.d/jail
functionality - the mount.* and exec.* parameters are direct analogs to rc.conf shell variables.  Some
other parameters match the command-line options of the existing jail(8).
>
> [This is less a mail to Jamie and more me getting around to publicly supporting they way it's done]

>
> A thing to note is also that when starting a jail you have to be really careful to do all of the related
operations in the right order and in a safe manner. E.g. mounting file systems are only safe in some
circumstances (ref: symlink attacks) so that's one reason I think the new approach is the right one. Also
try reading the current rc.d/jail code for checking for those symlinks etc... not pretty.
>
> There are also some other quirks which means a slightly more comprehensive program is better.  E.g.
current rc.d jails have a bug where they can actually fill /tmp if they produce a lot of console output due to
redirection to temp file (this is rarely a real problem so I never gotten around to trying to fix it).
>
> Bloat is of course a concern, but I don't think that risk outweigh the benefits of Jamie's new work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
FreeBSD bugmaster | 8 Aug 2011 13:07
Picon
Favicon

freebsd-jail@...

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/156111  jail       [jail] procstat -b not supported in jail
o misc/155765  jail       [patch] `buildworld' does not honors WITHOUT_JAIL
o conf/154246  jail       [jail] [patch] Bad symlink created if devfs mount poin
o conf/149050  jail       [jail] rcorder ``nojail'' too coarse for Jail+VNET
s conf/142972  jail       [jail] [patch] Support JAILv2 and vnet in rc.d/jail
o conf/141317  jail       [patch] uncorrect jail stop in /etc/rc.d/jail
o kern/133265  jail       [jail] is there a solution how to run nfs client in ja
o kern/119842  jail       [smbfs] [jail] "Bad address" with smbfs inside a jail
o bin/99566    jail       [jail] [patch] fstat(1) according to specified jid
o bin/32828    jail       [jail] w(1) incorrectly handles stale utmp slots with 

10 problems total.
Permalink | Reply | 0 comments |
headers
Paul Schenkeveld | 9 Aug 2011 14:45
Picon

Jexec and access to tty

Hi,

There have been several threads about this issue, some people have come
up with work arounds but I think that the issue is more fundamental,
that's why I wanted to start this new thread.

When using jexec to do interactive work inside an existing jail, people
find out that they no longer have access to their tty device.  As a
result, programs requiring input of passwords or passphrases behave
unexpectedly in one of several ways.

Ssh says "Host key verification failed." and refuses to log in to
another system (unless pubkey authentication is user in combination with
an agent of course).  Some programs fall back to using stdin/stdout
and echo the password as it is typed (the mysql clients are popular
examples).

Work-arounds that have been suggested are
 1. Run a sshd inside the jail and log in using ssh
 2. Start tmux inside the jail so you get a new pseudo tty slave inside
    the jail.  People trying screen find that it won't work unlike tmux.
 3. I tried using 'script -q /dev/null' inside the jail because it is
    part op the base system and it doesn't change your terminal type
    and interpret keyboard input and screen output.  I found out that I
    failed when I resized my window :-(

I don't like 1 on a machine with many jails, especially if some of them
share the same IP address (e.g. sometimes I have to run a mail server on
the same IP adress as a webserver but in a distinct jail).
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ian Downes | 10 Aug 2011 04:17
Gravatar

umounting md backed jail filesystems - busy

Hi everyone,

I'm trying to cleanup after shutting down some jails but I'm getting device
busy errors when trying to umount some of the filesystems.

More specifically, I've got an ephemeral zfs filesystem that serves as the root
of the jail. On '/etc/rc.d/jail stop' the jail stops cleanly but when I try to
destroy the zfs filesystem the initial umount fails, claiming it's busy. This
happens everytime.

I can't for the life of me work out who's tying it up. I've tried fstat, lsof
and fuser but nothing is reported as active! No processes, no active files.

Details:

$ uname -a
FreeBSD XXX.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Tue May 31 19:05:32 UTC 2011    
root@...:/usr/obj/usr/src/sys/XENHVM  amd64

'data' is a md backed zpool

$ mount | grep
data/path/to/jail/root on /path/to/jail/root (zfs, local)

$ fstat -f /path/to/jail/root
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W

$ unmount /path/to/jail/root
cannot unmount '/path/to/jail/root': Device busy
(Continue reading)

Permalink | Reply | 5 comments |
headers
joris dedieu | 10 Aug 2011 14:49
Picon
Gravatar

Re: Jexec and access to tty

2011/8/9 Paul Schenkeveld <freebsd@...>:
> Hi,
>
> There have been several threads about this issue, some people have come
> up with work arounds but I think that the issue is more fundamental,
> that's why I wanted to start this new thread.
>
> When using jexec to do interactive work inside an existing jail, people
> find out that they no longer have access to their tty device.  As a
> result, programs requiring input of passwords or passphrases behave
> unexpectedly in one of several ways.
>
> Ssh says "Host key verification failed." and refuses to log in to
> another system (unless pubkey authentication is user in combination with
> an agent of course).  Some programs fall back to using stdin/stdout
> and echo the password as it is typed (the mysql clients are popular
> examples).
>
> Work-arounds that have been suggested are
>  1. Run a sshd inside the jail and log in using ssh
>  2. Start tmux inside the jail so you get a new pseudo tty slave inside
>    the jail.  People trying screen find that it won't work unlike tmux.
>  3. I tried using 'script -q /dev/null' inside the jail because it is
>    part op the base system and it doesn't change your terminal type
>    and interpret keyboard input and screen output.  I found out that I
>    failed when I resized my window :-(

An other way is to use chroot(5) to enter the jail.
Maybe chroot /jail/root login -f $USER should be acceptable in some situations.
(Continue reading)

Permalink | Reply | 3 comments |
headers
joris dedieu | 10 Aug 2011 15:16
Picon
Gravatar

Re: umounting md backed jail filesystems - busy

2011/8/10 Ian Downes <ian@...>:
> Hi everyone,
>
> I'm trying to cleanup after shutting down some jails but I'm getting device
> busy errors when trying to umount some of the filesystems.
>
> More specifically, I've got an ephemeral zfs filesystem that serves as the root
> of the jail. On '/etc/rc.d/jail stop' the jail stops cleanly but when I try to
> destroy the zfs filesystem the initial umount fails, claiming it's busy. This
> happens everytime.
>
> I can't for the life of me work out who's tying it up. I've tried fstat, lsof
> and fuser but nothing is reported as active! No processes, no active files.

What gives top -S -n 10000  |grep -i zfs  while system is not
unmountable (could you see some processes in zfs state) ?
What gives jls during this time (does it report anythink still alive) ?

Regards
Joris
>
> Details:
>
> $ uname -a
> FreeBSD XXX.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Tue May 31 19:05:32 UTC 2011    
root@...:/usr/obj/usr/src/sys/XENHVM  amd64
>
> 'data' is a md backed zpool
>
> $ mount | grep
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ian Downes | 10 Aug 2011 18:00
Gravatar

Re: umounting md backed jail filesystems - busy

Joris,

thanks for the suggestions but they don't appear to indicate anything unusual.

> > I'm trying to cleanup after shutting down some jails but I'm getting device
> > busy errors when trying to umount some of the filesystems.
> >
> > More specifically, I've got an ephemeral zfs filesystem that serves as the root
> > of the jail. On '/etc/rc.d/jail stop' the jail stops cleanly but when I try to
> > destroy the zfs filesystem the initial umount fails, claiming it's busy. This
> > happens everytime.
> >
> > I can't for the life of me work out who's tying it up. I've tried fstat, lsof
> > and fuser but nothing is reported as active! No processes, no active files.
> 
> What gives top -S -n 10000  |grep -i zfs  while system is not
> unmountable (could you see some processes in zfs state) ?
> What gives jls during this time (does it report anythink still alive) ?

$  jls
JID  IP Address      Hostname                      Path

$ top -S -n 10000  |grep -i zfs
5 root         6  -8    -     0K    88K tx->tx  2   0:01  0.00% zfskern

It's entirely possible that this isn't due to a process related to the jail but
it is zfs tying things up for a while. I'd like to understand what's going on though
as I'd rather not just hack something together to schedule purges at some later
time.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ian Downes | 10 Aug 2011 18:36
Gravatar

Re: umounting md backed jail filesystems - busy

> > $  jls
> > JID  IP Address      Hostname                      Path
> 
> What does jls -d say? i.e. is the jail really shutdown or is it still dieing?

Thanks, indeed jls -d does show the jail as in the process of dying. I
watched jls -d and (unscientifically) as soon as jls -d reported the jail was
completely dead I was able to umount and destroy the filesystem. 

I hadn't expected it to take a minute or more for a jail to die. Is this usual?
Can anyone suggest what may be causing this? Perhaps a network related timeout?

thanks,

Ian
Permalink | Reply | 1 comment |
headers
Steven Hartland | 10 Aug 2011 18:28
Picon
Favicon

Re: umounting md backed jail filesystems - busy

----- Original Message ----- 
From: "Ian Downes" <ian@...>
> $  jls
> JID  IP Address      Hostname                      Path

What does jls -d say? i.e. is the jail really shutdown or is it still dieing?

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is
addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or
otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@...
Permalink | Reply | 2 comments |

Gmane