SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
exabyte autochanger
Author Message
Post exabyte autochanger 
Hi Maria,

On Wednesday 13 June 2007 writes Maria McKinley:
I recently updated to version 1.38.11-8, and I am having a hard time
getting my autochanger to work. I changed my bacula-sd.conf file so that
there is now an Autochanger:

Autochanger {
Name = Exabyte
Device = Drive-1
Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/sg0
}

Device {
Name = Drive-1
Drive Index = 0
Media Type = VXA-2
Archive Device = /dev/st0
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = yes;
AlwaysOpen = yes;
Autochanger = yes;
Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
}

This seems to work fine with btape auto command, but if I try to label
from bconsole, I get the following:

*label barcodes
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...
3306 Issuing autochanger "slots" command.
Device "Exabyte" has 0 slots.
No slots in changer to scan.

Any idea why I'm getting this?

please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.

regards
Falk

Post exabyte autochanger 
Maria McKinley schrieb:
Falk Sauer wrote:
please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.

My permissions are:

crw------- 1 root root 21, 0 2005-02-25 22:38 sg0

so, maybe that is my problem. Can I just change this, like any file,
with chown (assuming that the disk part is important) and chmod?

udev might override the permissions again. I would create an udev rule
to set the right permissions (check if your system uses udev).

You could try something like that:

/etc/udev/rules.d/010-local.rules

KERNEL=="st*", GROUP="tape", MODE="0660"
KERNEL=="nst*", GROUP="tape", MODE="0660"

/etc/init.d/udev restart (or reload...)

The bacula user has to be member of group tape.

Ralf

Post exabyte autochanger 
Maria McKinley wrote:
Falk Sauer wrote:
Hi Maria,


please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.

regards
Falk


Thanks Falk,

My permissions are:

crw------- 1 root root 21, 0 2005-02-25 22:38 sg0

so, maybe that is my problem. Can I just change this, like any file,
with chown (assuming that the disk part is important) and chmod?

As far as the /dev/nst0, I had this working with the old version of
bacula (1.36), and I found then that only nst0 worked, I would get
errors if I tried to change it to st0.

I am using Debian.

cheers,
maria

hi there,

have u tried to use mtx itself from shell?
and see what results will give simple
mtx -f /dev/sg0 status
or whatever your autochanger device node is

i dont know debian but i guess
/dev/nst0 is tape drive itself not autochanger device so to move; load;
unload tapes u have to use for example sg0 (if it works)
like for example
mtx -f /dev/sg0 load 3 /dev/nst0 0
should load tape from slot 3 to tape drive

of course u can load tape from bconsole as well

permissions are one thing and next thing is if mtx-changer is doing a
job and u have proper device in SD conf

good luck
--
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
TD840-RIPE |

Post exabyte autochanger 
An autochanger node should be /dev/sgX

tomasz a écrit :
Maria McKinley wrote:

Falk Sauer wrote:

Hi Maria,


please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.

regards
Falk


Thanks Falk,

My permissions are:

crw------- 1 root root 21, 0 2005-02-25 22:38 sg0

so, maybe that is my problem. Can I just change this, like any file,
with chown (assuming that the disk part is important) and chmod?

As far as the /dev/nst0, I had this working with the old version of
bacula (1.36), and I found then that only nst0 worked, I would get
errors if I tried to change it to st0.

I am using Debian.

cheers,
maria


hi there,

have u tried to use mtx itself from shell?
and see what results will give simple
mtx -f /dev/sg0 status
or whatever your autochanger device node is

i dont know debian but i guess
/dev/nst0 is tape drive itself not autochanger device so to move; load;
unload tapes u have to use for example sg0 (if it works)
like for example
mtx -f /dev/sg0 load 3 /dev/nst0 0
should load tape from slot 3 to tape drive

of course u can load tape from bconsole as well

permissions are one thing and next thing is if mtx-changer is doing a
job and u have proper device in SD conf

good luck


--
Adam CECILE Linbox / Free&ALter Soft
152 rue de Grigy tél: +33 3 87 50 87 95
Technopôle Metz 2000 fax: +33 3 87 75 19 26
57070 METZ - France http://www.linbox.com

Post exabyte autochanger 
Hi,

On 6/13/2007 8:58 PM, Maria McKinley wrote:
Ralf Gross wrote:
Maria McKinley schrieb:
Falk Sauer wrote:
please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.
My permissions are:

crw------- 1 root root 21, 0 2005-02-25 22:38 sg0

so, maybe that is my problem. Can I just change this, like any file,
with chown (assuming that the disk part is important) and chmod?
udev might override the permissions again. I would create an udev rule
to set the right permissions (check if your system uses udev).

You could try something like that:

/etc/udev/rules.d/010-local.rules

KERNEL=="st*", GROUP="tape", MODE="0660"
KERNEL=="nst*", GROUP="tape", MODE="0660"

/etc/init.d/udev restart (or reload...)

The bacula user has to be member of group tape.

Ralf


Hmm, udev does not seem to be installed, although curiously, the config
files are there. On the machine I had working previously with this tape
drive and an earlier version of bacula (1.36), udev was also not
installed, but again the config files were there, so it seems some other
package is using and installing these config files.
...
I'm still not entirely sure what to do about it. Since udev isn't
actually installed, I'm not sure what to restart to read my script.
Seems like something should be reading the udev config files, since I
didn't put the default ones there, so some package must have. I'd rather
not reboot this machine, but I will if no one knows, and then I can see
if the permissions were updated. But how on earth did this get set in my
previous installation without a script in udev?

Which OS do you use?

Usually, there a commands available to tell you which package a file
belongs to. For example, running an rpm-based distribution:
elf:~ # rpm -qf /etc/udev/udev.conf
udev-030-9.2

Starting with that information, or knowing which OS you run, someone
might have an idea...

Oh, and of course you could always add a simple line like 'chown
bacula.tape /dev/sg0' into the Bacula start script.

Arno

--
IT-Service Lehmann al < at > it...
Arno Lehmann http://www.its-lehmann.de

Post exabyte autochanger 
Are you sure that /dev/sg0 is in fact the autochanger device and not the
tape drive?

For instance on my server (from dmesg output):

(scsi3:A:4): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Vendor: CERTANCE Model: ULTRIUM 3 Rev: 1856
Type: Sequential-Access ANSI SCSI revision: 04
Attached scsi generic sg2 at scsi3, channel 0, id 4, lun 0, type 1

st: Version 20040403, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi3, channel 0, id 4, lun 0
st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA
134217727
Vendor: QUANTUM Model: UHDL Rev: 0031
Type: Medium Changer ANSI SCSI revision: 02
Attached scsi generic sg3 at scsi3, channel 0, id 4, lun 1, type 8

So the generic device for my tape drive is /dev/sg2 (but the tape drive
is normally addressed as /dev/nst0) and the changer for it is /dev/sg3.

It would be interesting to see the output of "cat /proc/scsi/scsi" on
your machine.

[root < at > nts ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: LSILOGIC Model: 1030 IM Rev: 1000
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 08 Lun: 00
Vendor: IBM Model: 25P3495a S320 1 Rev: 1
Type: Processor ANSI SCSI revision: 02
Host: scsi3 Channel: 00 Id: 04 Lun: 00
Vendor: CERTANCE Model: ULTRIUM 3 Rev: 1856
Type: Sequential-Access ANSI SCSI revision: 04
Host: scsi3 Channel: 00 Id: 04 Lun: 01
Vendor: QUANTUM Model: UHDL Rev: 0031
Type: Medium Changer ANSI SCSI revision: 02

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Post exabyte autochanger 
I would also do a quick check to make sure you have LUN support enabled.

On Wed, 13 Jun 2007 14:24:09 -0700
Michael Nelson <mnelson < at > in...> wrote:

Are you sure that /dev/sg0 is in fact the autochanger device and not the
tape drive?

For instance on my server (from dmesg output):


(scsi3:A:4): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Vendor: CERTANCE Model: ULTRIUM 3 Rev: 1856
Type: Sequential-Access ANSI SCSI revision: 04
Attached scsi generic sg2 at scsi3, channel 0, id 4, lun 0, type 1

st: Version 20040403, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi3, channel 0, id 4, lun 0
st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA
134217727
Vendor: QUANTUM Model: UHDL Rev: 0031
Type: Medium Changer ANSI SCSI revision: 02
Attached scsi generic sg3 at scsi3, channel 0, id 4, lun 1, type 8

So the generic device for my tape drive is /dev/sg2 (but the tape drive
is normally addressed as /dev/nst0) and the changer for it is /dev/sg3.

It would be interesting to see the output of "cat /proc/scsi/scsi" on
your machine.

[root < at > nts ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: LSILOGIC Model: 1030 IM Rev: 1000
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 08 Lun: 00
Vendor: IBM Model: 25P3495a S320 1 Rev: 1
Type: Processor ANSI SCSI revision: 02
Host: scsi3 Channel: 00 Id: 04 Lun: 00
Vendor: CERTANCE Model: ULTRIUM 3 Rev: 1856
Type: Sequential-Access ANSI SCSI revision: 04
Host: scsi3 Channel: 00 Id: 04 Lun: 01
Vendor: QUANTUM Model: UHDL Rev: 0031
Type: Medium Changer ANSI SCSI revision: 02




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users


--

----------

Broderick Wood
Seconded to AICT for the Summer
General Services Building #144
University of Alberta

(780) 492-6875



Re: [Bacula-users] exabyte autochanger From: Maria McKinley

- 2007-06-13 21:39

Arno Lehmann wrote:
Hi,

On 6/13/2007 8:58 PM, Maria McKinley wrote:
Ralf Gross wrote:
Maria McKinley schrieb:
Falk Sauer wrote:
please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.
My permissions are:

crw------- 1 root root 21, 0 2005-02-25 22:38 sg0

so, maybe that is my problem. Can I just change this, like any file,
with chown (assuming that the disk part is important) and chmod?
udev might override the permissions again. I would create an udev rule
to set the right permissions (check if your system uses udev).

You could try something like that:

/etc/udev/rules.d/010-local.rules

KERNEL=="st*", GROUP="tape", MODE="0660"
KERNEL=="nst*", GROUP="tape", MODE="0660"

/etc/init.d/udev restart (or reload...)

The bacula user has to be member of group tape.

Ralf

Hmm, udev does not seem to be installed, although curiously, the config
files are there. On the machine I had working previously with this tape
drive and an earlier version of bacula (1.36), udev was also not
installed, but again the config files were there, so it seems some other
package is using and installing these config files.
...
I'm still not entirely sure what to do about it. Since udev isn't
actually installed, I'm not sure what to restart to read my script.
Seems like something should be reading the udev config files, since I
didn't put the default ones there, so some package must have. I'd rather
not reboot this machine, but I will if no one knows, and then I can see
if the permissions were updated. But how on earth did this get set in my
previous installation without a script in udev?

Which OS do you use?

Usually, there a commands available to tell you which package a file
belongs to. For example, running an rpm-based distribution:
elf:~ # rpm -qf /etc/udev/udev.conf
udev-030-9.2

Starting with that information, or knowing which OS you run, someone
might have an idea...


Oh, and of course you could always add a simple line like 'chown
bacula.tape /dev/sg0' into the Bacula start script.

Arno


Ah, thanks for that jolt. Forgot about figuring out what package a file
belongs to. Looks like both hdparm and mt-st have files in the
/etc/udev, so I tried reloading hdparm, and that updated permissions in
/dev. I am now trying to label the tapes, but it appears that bacula is
hung trying, this is where I've been for over 10 minutes:

*label barcodes
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...

In answer to other questions, mtx and mt-st both work from the command
line, and the tape changer is definitely /dev/sg0, and the tape drive is
definitely /dev/st0

thanks again,
Maria

Post exabyte autochanger 
I see in another post you say that MTX is working properly from the command line. This makes me believe that LUN support is enabled.

You should be getting communication problems with MTX if it wasn't. :-)

BTW What Operating System and version are you running?

On Wed, 13 Jun 2007 14:48:05 -0700
Maria McKinley <parody < at > u.washington.edu> wrote:



Broderick Wood wrote:
I would also do a quick check to make sure you have LUN support enabled.



What is LUN support, and how do I check to make sure it is enabled?

~maria


On Wed, 13 Jun 2007 14:24:09 -0700
Michael Nelson <mnelson < at > in...> wrote:

Are you sure that /dev/sg0 is in fact the autochanger device and not the
tape drive?

For instance on my server (from dmesg output):


(scsi3:A:4): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Vendor: CERTANCE Model: ULTRIUM 3 Rev: 1856
Type: Sequential-Access ANSI SCSI revision: 04
Attached scsi generic sg2 at scsi3, channel 0, id 4, lun 0, type 1

st: Version 20040403, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi3, channel 0, id 4, lun 0
st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA
134217727
Vendor: QUANTUM Model: UHDL Rev: 0031
Type: Medium Changer ANSI SCSI revision: 02
Attached scsi generic sg3 at scsi3, channel 0, id 4, lun 1, type 8

So the generic device for my tape drive is /dev/sg2 (but the tape drive
is normally addressed as /dev/nst0) and the changer for it is /dev/sg3.

It would be interesting to see the output of "cat /proc/scsi/scsi" on
your machine.

[root < at > nts ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: LSILOGIC Model: 1030 IM Rev: 1000
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 08 Lun: 00
Vendor: IBM Model: 25P3495a S320 1 Rev: 1
Type: Processor ANSI SCSI revision: 02
Host: scsi3 Channel: 00 Id: 04 Lun: 00
Vendor: CERTANCE Model: ULTRIUM 3 Rev: 1856
Type: Sequential-Access ANSI SCSI revision: 04
Host: scsi3 Channel: 00 Id: 04 Lun: 01
Vendor: QUANTUM Model: UHDL Rev: 0031
Type: Medium Changer ANSI SCSI revision: 02




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users


--

----------

Broderick Wood
Seconded to AICT for the Summer
General Services Building #144
University of Alberta

(780) 492-6875

Post exabyte autochanger 
Maria McKinley wrote:
Arno Lehmann wrote:
Hi,

On 6/13/2007 8:58 PM, Maria McKinley wrote:
Ralf Gross wrote:
Maria McKinley schrieb:
Falk Sauer wrote:
please make shure that your changer device has the correct permissions eg.:

crw-rw---- root disk /dev/sg0

and for the potentially next problem ...
by your tapedrive device i'm unshure, i think this should /dev/nst0, i don't
know how its correct on exabyte tapes.

Normally the /dev/st* device makes a automatic rewind after write,
the /dev/nst* make no auto rewind. Bacula needs imho a non auto rewinding
device. You dosn't write wich OS you use, here are little differences between
the OSes.
My permissions are:

crw------- 1 root root 21, 0 2005-02-25 22:38 sg0

so, maybe that is my problem. Can I just change this, like any file,
with chown (assuming that the disk part is important) and chmod?
udev might override the permissions again. I would create an udev rule
to set the right permissions (check if your system uses udev).

You could try something like that:

/etc/udev/rules.d/010-local.rules

KERNEL=="st*", GROUP="tape", MODE="0660"
KERNEL=="nst*", GROUP="tape", MODE="0660"

/etc/init.d/udev restart (or reload...)

The bacula user has to be member of group tape.

Ralf

Hmm, udev does not seem to be installed, although curiously, the config
files are there. On the machine I had working previously with this tape
drive and an earlier version of bacula (1.36), udev was also not
installed, but again the config files were there, so it seems some other
package is using and installing these config files.
...
I'm still not entirely sure what to do about it. Since udev isn't
actually installed, I'm not sure what to restart to read my script.
Seems like something should be reading the udev config files, since I
didn't put the default ones there, so some package must have. I'd rather
not reboot this machine, but I will if no one knows, and then I can see
if the permissions were updated. But how on earth did this get set in my
previous installation without a script in udev?
Which OS do you use?

Usually, there a commands available to tell you which package a file
belongs to. For example, running an rpm-based distribution:
elf:~ # rpm -qf /etc/udev/udev.conf
udev-030-9.2

Starting with that information, or knowing which OS you run, someone
might have an idea...


Oh, and of course you could always add a simple line like 'chown
bacula.tape /dev/sg0' into the Bacula start script.

Arno


Ah, thanks for that jolt. Forgot about figuring out what package a file
belongs to. Looks like both hdparm and mt-st have files in the
/etc/udev, so I tried reloading hdparm, and that updated permissions in
/dev. I am now trying to label the tapes, but it appears that bacula is
hung trying, this is where I've been for over 10 minutes:

*label barcodes
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...


In answer to other questions, mtx and mt-st both work from the command
line, and the tape changer is definitely /dev/sg0, and the tape drive is
definitely /dev/st0

thanks again,
Maria


try use mtx-changer instead of mtx and see whats happened
i think u should enable debug mode in mtx-changer too and look into log
file.

are you sure bacula have right permissions to this devices?

--
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
TD840-RIPE |

Post exabyte autochanger 
Maria McKinley wrote:

Broderick Wood wrote:
I see in another post you say that MTX is working properly from the command line. This makes me believe that LUN support is enabled.

You should be getting communication problems with MTX if it wasn't. :-)

BTW What Operating System and version are you running?



I am running Debian, Linux version 2.4.27-3-386.

In another post, I had explained how I got the permissions fixed (at
least I think, they aren't the same as they use to be, but they are what
someone else had reccommeded), but bacula was hanging. It did quit
hanging, and turns out I had forgotten to restart the storage daemon.
But there still seems to be a problem, as this is what I get now:

*update slots
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...
3306 Issuing autochanger "slots" command.
Device "Exabyte" has 0 slots.
No slots in changer to scan.

Could this still be a permission problem? Here are my permissions now:

crw-rw---- 1 root tape 9, 0 2005-02-25 22:38 /dev/st0
crw------- 1 root root 21, 0 2005-02-25 22:38 /dev/sg0

I assumed /dev/sg0 should have the same permissions as /dev/st0, so I
added this to my script:

KERNEL=="sg*", GROUP="tape", MODE="0660"

but this didn't change the permissions for /dev/sg0. Is this likely to
be the problem the changer didn't see any slots, and any idea why didn't
changing the permissions work like it did for /dev/st0?

thanks again,
maria


have been bacula running earlier as root? and right now is running as
bacula user? check starting script

cos if so as simple test change devices owner to bacula like
chown bacula:bacula /dev/st0
chown bacula:bacula /dev/sg0
and check if it works from bconsole
cos as i pointed it earlier when u run mtx in console u are doing it as
root - dont u? not bacula
when u r doing it from bconsole u r doing it as bacula group bacula - i
guess thats how it is running.
correct me if i am wrong

--
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
TD840-RIPE |



Re: [Bacula-users] exabyte autochanger From: Maria McKinley

- 2007-06-13 22:11

Broderick Wood wrote:
I see in another post you say that MTX is working properly from the command line. This makes me believe that LUN support is enabled.

You should be getting communication problems with MTX if it wasn't. :-)

BTW What Operating System and version are you running?



I am running Debian, Linux version 2.4.27-3-386.

In another post, I had explained how I got the permissions fixed (at
least I think, they aren't the same as they use to be, but they are what
someone else had reccommeded), but bacula was hanging. It did quit
hanging, and turns out I had forgotten to restart the storage daemon.
But there still seems to be a problem, as this is what I get now:

*update slots
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...
3306 Issuing autochanger "slots" command.
Device "Exabyte" has 0 slots.
No slots in changer to scan.

Could this still be a permission problem? Here are my permissions now:

crw-rw---- 1 root tape 9, 0 2005-02-25 22:38 /dev/st0
crw------- 1 root root 21, 0 2005-02-25 22:38 /dev/sg0

I assumed /dev/sg0 should have the same permissions as /dev/st0, so I
added this to my script:

KERNEL=="sg*", GROUP="tape", MODE="0660"

but this didn't change the permissions for /dev/sg0. Is this likely to
be the problem the changer didn't see any slots, and any idea why didn't
changing the permissions work like it did for /dev/st0?

thanks again,
maria

Post exabyte autochanger 
Maria McKinley wrote:
tomasz wrote:
Maria McKinley wrote:
Broderick Wood wrote:
I see in another post you say that MTX is working properly from the
command line. This makes me believe that LUN support is enabled.

You should be getting communication problems with MTX if it wasn't.
:-)

BTW What Operating System and version are you running?


I am running Debian, Linux version 2.4.27-3-386.

In another post, I had explained how I got the permissions fixed (at
least I think, they aren't the same as they use to be, but they are
what someone else had reccommeded), but bacula was hanging. It did
quit hanging, and turns out I had forgotten to restart the storage
daemon. But there still seems to be a problem, as this is what I get
now:

*update slots
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...
3306 Issuing autochanger "slots" command.
Device "Exabyte" has 0 slots.
No slots in changer to scan.

Could this still be a permission problem? Here are my permissions now:

crw-rw---- 1 root tape 9, 0 2005-02-25 22:38 /dev/st0
crw------- 1 root root 21, 0 2005-02-25 22:38 /dev/sg0

I assumed /dev/sg0 should have the same permissions as /dev/st0, so I
added this to my script:

KERNEL=="sg*", GROUP="tape", MODE="0660"

but this didn't change the permissions for /dev/sg0. Is this likely
to be the problem the changer didn't see any slots, and any idea why
didn't changing the permissions work like it did for /dev/st0?

thanks again,
maria


have been bacula running earlier as root? and right now is running as
bacula user? check starting script

cos if so as simple test change devices owner to bacula like
chown bacula:bacula /dev/st0
chown bacula:bacula /dev/sg0
and check if it works from bconsole
cos as i pointed it earlier when u run mtx in console u are doing it as
root - dont u? not bacula
when u r doing it from bconsole u r doing it as bacula group bacula - i
guess thats how it is running.
correct me if i am wrong



Ok, that did it. Changing them both to be owned by bacula fixed it. Now
I just have figure out how to make sure they stay that way. Thanks a bunch!


i think u wont do it
try the same as u done with 'st0' and 'chgrp' for 'sg0' to 'tape' then
add perm for group
then stick bacula user into 'tape' group

--
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
TD840-RIPE |

Post exabyte autochanger 
Attachments: novosirj.vcf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maria McKinley wrote:
On 6/14/07, tomasz <tomaszd < at > pa...> wrote:
Maria McKinley wrote:
tomasz wrote:
Maria McKinley wrote:
Broderick Wood wrote:
I see in another post you say that MTX is working properly from the
command line. This makes me believe that LUN support is enabled.

You should be getting communication problems with MTX if it wasn't.
:-)

BTW What Operating System and version are you running?


I am running Debian, Linux version 2.4.27-3-386.

In another post, I had explained how I got the permissions fixed (at
least I think, they aren't the same as they use to be, but they are
what someone else had reccommeded), but bacula was hanging. It did
quit hanging, and turns out I had forgotten to restart the storage
daemon. But there still seems to be a problem, as this is what I get
now:

*update slots
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: Exabyte
Connecting to Storage daemon Exabyte at dinah:9103 ...
3306 Issuing autochanger "slots" command.
Device "Exabyte" has 0 slots.
No slots in changer to scan.

Could this still be a permission problem? Here are my permissions now:

crw-rw---- 1 root tape 9, 0 2005-02-25 22:38 /dev/st0
crw------- 1 root root 21, 0 2005-02-25 22:38 /dev/sg0

I assumed /dev/sg0 should have the same permissions as /dev/st0, so I
added this to my script:

KERNEL=="sg*", GROUP="tape", MODE="0660"

but this didn't change the permissions for /dev/sg0. Is this likely
to be the problem the changer didn't see any slots, and any idea why
didn't changing the permissions work like it did for /dev/st0?

thanks again,
maria

have been bacula running earlier as root? and right now is running as
bacula user? check starting script

cos if so as simple test change devices owner to bacula like
chown bacula:bacula /dev/st0
chown bacula:bacula /dev/sg0
and check if it works from bconsole
cos as i pointed it earlier when u run mtx in console u are doing it as
root - dont u? not bacula
when u r doing it from bconsole u r doing it as bacula group bacula - i
guess thats how it is running.
correct me if i am wrong


Ok, that did it. Changing them both to be owned by bacula fixed it. Now
I just have figure out how to make sure they stay that way. Thanks a bunch!

i think u wont do it
try the same as u done with 'st0' and 'chgrp' for 'sg0' to 'tape' then
add perm for group
then stick bacula user into 'tape' group


--
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
TD840-RIPE |


Thanks Tomasz, but I can't get the script to change the group for
/dev/sg0 for some reason. Here is my script:

KERNEL=="st*", GROUP="tape", MODE="0660"
KERNEL=="nst*", GROUP="tape", MODE="0660"
KERNEL=="sg*", GROUP="tape", MODE="0660"

When I run it, the group and permissions for st* and nst* change, but
not sg*. Sticking bacula in group tape makes sense to me, but what
does it mean "add perm for group"?

He just means what you have above, that the group has write permission
(660 does that just fine, 600 would not). IMO, this is the right way to
do it too.

I seem to remember you finding two things that worked with udev.
Personally, I think the other one (st-whatever) is a lot more closely
related to tape functions than hdparm. Perhaps reloading that one
instead will help?

- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGckFumb+gadEcsb4RAgzQAKDQbbMa9ikhC7WtdRvI713BLHLPbQCghT8n
5TLHPfAVHbNfUxp8qudcn14=
=QG1Q
-----END PGP SIGNATURE-----

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB