On 6/30/2011 1:28 PM, Victor Hugo dos Santos wrote:
> On Tue, May 3, 2011 at 11:05 AM, Josh Fisher<jfisher AT pvct DOT com> wrote:
>> So, bacula:bacula cannot write, but bacula:disk can, yet all accessed
>> directories appear to be owned by bacula:bacula? What group does the
>> bacula-sd daemon run as? On Fedora, it is typical for bacula-dir to run
>> as bacula:bacula, while bacula-sd runs as bacula:disk. Perhaps this is
>> an selinux thing? Maybe the simple solution is to change everything to
>> be owned by bacula:disk and run bacula-sd as bacula:disk.
> Hi...
>
> I had the same error today in ubuntu server:
>
> ================
> $ sudo vchanger -u bacula -g bacula /etc/bacula/disco_usb.conf initmag 1
> magazine bay 1 has no magazine mounted
>
> $ sudo vchanger -u bacula -g tape /etc/bacula/disco_usb.conf initmag 1
> magazine bay 1 has no magazine mounted
>
> $ sudo vchanger -u bacula -g disk /etc/bacula/disco_usb.conf initmag 1
> magazine in bay 1 (/mnt/vchanger/29d9d497-62dd-4903-9054-a3fb9777b79d)
> already initialized as magazine 1
> ================
>
> bacula-dir and bacula-sd are working in "bacula" and "tape" groups
> respectively and all folders and files have this groups.
>
> =================
> $ find /var/lib/bacula/ /var/log/bacula/ /var/bacula -not -group
> bacula -and -not -group tape
> /var/log/bacula/
> =================
>
> and after check the output of strace
>
> =================
> $ sudo strace -s 100 vchanger -u bacula -g bacula
> /etc/bacula/disco_usb.conf initmag 1
>
> stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0
> time(NULL) = 1309454624
> stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0
> open("/dev/sdc1", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
> read(4, "", 1024) = 0
> close(4)
> =================
>
> I found that the problem is that vchanger try to access the device
> (/dev/sd*) directly and not the directory/mountpoint configured..
Could be. If magazines are specified by UUID, then libblkid functions
are used to discover the device node with that UUID, followed by a
getmntent() call to query the mountpoint path. Either libblkid or
getmntent() is very likely making the stat64() call on the device node.
> and how the script are running with a group (bacula/tape) that don't
> have access do /dev/sd*, the script don't work...
>
> ===========
> $ ls -ltr /dev/sd*
> brw-rw---- 1 root disk 8, 16 2011-06-28 11:16 /dev/sdb
> brw-rw---- 1 root disk 8, 0 2011-06-28 11:16 /dev/sda
> brw-rw---- 1 root disk 8, 1 2011-06-28 11:16 /dev/sda1
> brw-rw---- 1 root disk 8, 17 2011-06-28 11:16 /dev/sdb1
> brw-rw---- 1 root disk 8, 21 2011-06-28 11:16 /dev/sdb5
> brw-rw---- 1 root disk 8, 18 2011-06-28 11:16 /dev/sdb2
> brw-rw---- 1 root disk 8, 32 2011-06-30 12:10 /dev/sdc
> brw-rw---- 1 root disk 8, 33 2011-06-30 12:10 /dev/sdc1
> ===========
>
> solution... mmm .. include bacula in disk group ??
That, or run bacula-sd as bacula:disk, rather than bacula:tape, if that
is possible. The user bacula-sd runs as needs read-only access in order
to look up the mountpoint using a getmntent() call.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
