From root@minerva.uucp.kew.com  Wed Jun 20 08:18:15 2001
Return-Path: <root@minerva.uucp.kew.com>
Received: from minerva.uucp.kew.com (kendra.ne.mediaone.net [24.218.227.234])
	by hub.freebsd.org (Postfix) with ESMTP id 74D6737B403
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Jun 2001 08:18:15 -0700 (PDT)
	(envelope-from root@minerva.uucp.kew.com)
Received: by minerva.uucp.kew.com (Postfix, from userid 0)
	id 80F49BA20; Wed, 20 Jun 2001 11:18:14 -0400 (EDT)
Message-Id: <20010620151814.80F49BA20@minerva.uucp.kew.com>
Date: Wed, 20 Jun 2001 11:18:14 -0400 (EDT)
From: ahd@kew.com
Reply-To: ahd@kew.com
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: dump of vinum based file systems by device name fails 
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         28294
>Category:       bin
>Synopsis:       dump of vinum based file systems by device name fails
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    joerg
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 20 08:20:06 PDT 2001
>Closed-Date:    Fri Jan 17 00:51:20 MET 2003
>Last-Modified:  Fri Jan 17 00:51:20 MET 2003
>Originator:     Drew Derbyshire
>Release:        FreeBSD 4.3-RELEASE i386
>Organization:
Kendra Electronic Wonderworks
>Environment:
System: FreeBSD minerva.hh.kew.com 4.3-RELEASE FreeBSD 4.3-RELEASE #3: Sun Jun 17 14:05:19 EDT 2001 ahd@minerva.hh.kew.com:/usr/src/sys/compile/MINERVA i386

System has amanda24-client-2.4.2p1_2 installed.

Applicable part of /etc/fstab

   /dev/da1s2a	/		ufs	rw		1	1
   /dev/da1s2b	/tmp		mfs	rw		0	0
   /dev/vinum/var	/var	ufs	rw			2	2
   /dev/vinum/usr	/usr	ufs	rw			2	2
   /dev/vinum/export /usr/export ufs	rw		2	2
   /dev/vinum/scratch /usr/scratch ufs	rw		0	3

vinunm configuration summary:

   2 drives:
   D d0                    State: up	Device /dev/da0s2g	Avail: 0/16739 MB (0%)
   D d1                    State: up	Device /dev/da1s2g	Avail: 0/16739 MB (0%)

   4 volumes:
   V var                   State: up	Plexes:       2	Size:        512 MB
   V usr                   State: up	Plexes:       2	Size:       2227 MB
   V export                State: up	Plexes:       2	Size:       5000 MB
   V scratch               State: up	Plexes:       2	Size:       9000 MB

   8 plexes:
   P var.p0              C State: up	Subdisks:     1	Size:        512 MB
   P usr.p0              C State: up	Subdisks:     1	Size:       2227 MB
   P export.p0           C State: up	Subdisks:     1	Size:       5000 MB
   P scratch.p0          C State: up	Subdisks:     1	Size:       9000 MB
   P var.p1              C State: up	Subdisks:     1	Size:        512 MB
   P usr.p1              C State: up	Subdisks:     1	Size:       2227 MB
   P export.p1           C State: up	Subdisks:     1	Size:       5000 MB
   P scratch.p1          C State: up	Subdisks:     1	Size:       9000 MB

   8 subdisks:
   S var.p0.s0             State: up	PO:        0  B Size:        512 MB
   S usr.p0.s0             State: up	PO:        0  B Size:       2227 MB
   S export.p0.s0          State: up	PO:        0  B Size:       5000 MB
   S scratch.p0.s0         State: up	PO:        0  B Size:       9000 MB
   S var.p1.s0             State: up	PO:        0  B Size:        512 MB
   S usr.p1.s0             State: up	PO:        0  B Size:       2227 MB
   S export.p1.s0          State: up	PO:        0  B Size:       5000 MB
   S scratch.p1.s0         State: up	PO:        0  B Size:       9000 MB

>Description:

I'm not sure this is a bug in vinum (kern), dump (bin), or amanda
(ports).

minerva has a number of vinum mirrored volumes (see above) and
amanda24-client-2.4.2p1_2.  Attempts to dump the vinum resident
file systems via amanda fail because amanda attempts to invoke dump
with the device name, not the mount point, and dump fails.

amanda debug log sample:

   sendsize: debug 1 pid 2242 ruid 2 euid 2 start time Wed Jun 20 10:49:31 2001
   /usr/local/libexec/amanda/sendsize: version 2.4.2p1
   calculating for amname '/usr', dirname '/usr'
   sendsize: getting size via dump for /usr level 0
   sendsize: running "/sbin/dump 0hsf 0 1048576 - /dev/vinum/usr"
   running /usr/local/libexec/amanda/killpgrp
     DUMP: Date of this level 0 dump: Wed Jun 20 10:49:31 2001
     DUMP: Date of last level 0 dump: the epoch
     DUMP: Dumping /dev/vinum/usr (/usr) to standard output
     DUMP: Cannot open /dev/vinum/usr
   .....
   (no size line match in above dump output)
   .....
   asking killpgrp to terminate

>How-To-Repeat:
	
	Request amanda dump (via dump) a vinum based file system.

>Fix:
	
	Workaround is specify use of GNU TAR for the dump program.
>Release-Note:
>Audit-Trail:

From: "Drew Derbyshire" <ahd@kew.com>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Derbyshire, Drew" <ahd@kew.com>
Cc:  
Subject: Re: bin/28294: dump of vinum based file systems by device name fails
Date: Thu, 21 Jun 2001 18:36:42 -0400

 The problem is in vinum itself -- it builds the volume device nodes wrong,
 with an owner group of wheel instead of operator.   This prevents non-root
 members of operator from accessing the drives.
 
 Compare these device nodes for regular disk slices:
 
 crw-r-----  2 root  operator   13, 0x0003000a Jun 16 23:47 /dev/da1s2
 crw-r-----  2 root  operator   13, 0x00030008 Jun 16 23:47 /dev/da1s2a
 crw-r-----  2 root  operator   13, 0x00030009 Jun 16 23:47 /dev/da1s2b
 crw-r-----  2 root  operator   13, 0x0003000a Jun 16 23:47 /dev/da1s2c
 crw-r-----  2 root  operator   13, 0x0003000b Jun 16 23:47 /dev/da1s2d
 crw-r-----  2 root  operator   13, 0x0003000c Jun 16 23:47 /dev/da1s2e
 crw-r-----  2 root  operator   13, 0x0003000d Jun 16 23:47 /dev/da1s2f
 crw-r-----  2 root  operator   13, 0x0003000e Jun 16 23:47 /dev/da1s2g
 crw-r-----  2 root  operator   13, 0x0003000f Jun 16 23:47 /dev/da1s2h
 
 to the vinum subdirectory:
 
 crw-------  1 root  wheel   91, 0x40000001 Jun 18 13:44 Control
 crw-------  1 root  wheel   91, 0x40000002 Jun 18 13:44 control
 crw-------  1 root  wheel   91, 0x40000000 Jun 18 13:44 controld
 drwxr-xr-x  2 root  wheel       512 Jun 18 13:44 drive
 crw-r-----  1 root  wheel   91,   2 Jun 18 13:44 export
 drwxr-xr-x  2 root  wheel       512 Jun 18 13:44 plex
 crw-r-----  1 root  wheel   91,   3 Jun 18 13:44 scratch
 drwxr-xr-x  2 root  wheel       512 Jun 18 13:44 sd
 crw-r-----  1 root  wheel   91,   1 Jun 18 13:44 usr
 crw-r-----  1 root  wheel   91,   0 Jun 18 13:44 var
 drwxr-xr-x  6 root  wheel       512 Jun 18 13:44 vol
 
 The scratch, usr, export, and var devices should all be owned by group
 operator.
 
 Note that because vinum attempts remake to the device nodes in /dev/vinum at
 every reboot, it's unclear if a simple chmod command would solve the issue
 for existing vinum volumes across reboots.
 
 -ahd-
 
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: schweikh 
Responsible-Changed-When: Thu Oct 3 05:19:48 PDT 2002 
Responsible-Changed-Why:  
Over to vinum maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28294 
Responsible-Changed-From-To: grog->	 joerg 
Responsible-Changed-By: grog 
Responsible-Changed-When: Thu Oct 17 18:39:21 PDT 2002 
Responsible-Changed-Why:  
joerg has offered to fix this problem. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28294 
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Fri Jan 17 00:50:37 MET 2003 
State-Changed-Why:  
Fixed in both, the kernel part (for DEVFS under -current), 
and the vinum(8) utility (for non-DEVFS cases, due for MFC 
into 4.x). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28294 
>Unformatted:
