Re: barcode scanners (or, chg-zd-mtx problem)
On Fri, 2005-07-08 at 10:34 -0600, Cam wrote: > havereader 1 > firstslot 1 > lastslot 17 > cleanslot -1 > offline_before_unload 0 > > but when i run the "/usr/lib/amanda/chg-zd-mtx -info'" it reports "4 30 1 " Where are you running it from? It'll read the config in the local directory (IIRC), so you should run it from your config directory. > These values are good (the 30 is what i want, but i changed it to 17 > for testing purposes), but they are clearly not what is in my > changer.conf. I've noticed that on our Exabyte unit, it *always* reports the number of slots that actually have tapes in them, as opposed to the number of slots I've specified to use, or the total number of slots. > I'm not sure if it's guessing the information on it's > own or pulling it from some other file... i read through some of the > /tmp/amanda/chg-zd-mtx stuff, but unfortunately they do not tell me > what config file it's reading from. Any help would be greatly > appreciated. What do you have in relation to the changer in your amanda.conf? -- Graeme Humphries ([EMAIL PROTECTED]) Linux Administrator VCom Inc. (306) 955-7075 ext 485 My views and comments do not necessarily reflect the views of my employer.
Re: barcode scanners (or, chg-zd-mtx problem)
On July 8 2005, Cam wrote:
> havereader 1
> firstslot 1
> lastslot 17
> cleanslot -1
> offline_before_unload 0
>
> but when i run the "/usr/lib/amanda/chg-zd-mtx -info'" it reports "4 30 1 "
You need equals signs ("=") between the keywords and values in the
changer.conf file. Like this:
havereader=1
firstslot=1
lastslot=17
cleanslot=-1
offline_before_unload=0
If chg-zd-mtx doesn't find good values for those keywords, it uses mtx
to figure them out itself.
-Ben
--
Benjamin Lewis <[EMAIL PROTECTED]>
Security Analyst, Identity and Access Management
IT Security and Privacy
Purdue University
barcode scanners (or, chg-zd-mtx problem)
Hi, My amanda configuration is working nicely, but i have a problem w/ the barcode scanning stuff. MTX reports all the :VolumeTag=blahblah stuff indicating that my barcode scanner should be working. the tape-changer i'm using is chg-zd-mtx. i a line in my /etc/amana/DailySet1/amanda.conf that says "changerfile=/etc/amanda/DailySet1/changer". the changer.conf in that directory is like this: havereader 1 firstslot 1 lastslot 17 cleanslot -1 offline_before_unload 0 but when i run the "/usr/lib/amanda/chg-zd-mtx -info'" it reports "4 30 1 " These values are good (the 30 is what i want, but i changed it to 17 for testing purposes), but they are clearly not what is in my changer.conf. I'm not sure if it's guessing the information on it's own or pulling it from some other file... i read through some of the /tmp/amanda/chg-zd-mtx stuff, but unfortunately they do not tell me what config file it's reading from. Any help would be greatly appreciated. Thanks, Cameron Matheson
Re: another chg-zd-mtx problem
All of my issues have been solved and Amanda is running like a champ. I
wanted to thank all of you that worked with me off list to solve the
problem and apologize for posting so many emails at first.
The final solution:
You know how hard it is to RTFM at times.. In the chg-zd-mtx
script itself there is one small section that solves all my issues:
# * Figure out the drive slot number. By default, the script takes
# any digits in the tape drive device name and assumes they match
# the robot slot number for the drive. In the example above, the
# tape drive ("Data Transfer Element") is in slot 0. If the tape
# drive device name happens to be (e.g.) /dev/rmt/0mn, the numbers
# match and you do not have to do anything else. If they do not
match
# (e.g. the robot number was 128, or the drive was /dev/nst3) you
# need to set the drive slot number with the "driveslot" variable.
My robot is in slot 0 on my tape drive and the device is /dev/sg2. So
as you can see as defined above the script will never ID the robot
unless "driveslot" is defined in the mtx-changer script. Simply adding:
driveslot=0
to my script was all that was needed and she took off like a charm.
Hopefully this will help some one else who was in too much of a hurry to
read..
Thanks again!
--
signature.asc
Description: This is a digitally signed message part
Re: another chg-zd-mtx problem
On Thursday 13 February 2003 09:54, Pete Poggione wrote: >Jon - >Perhaps I'm have a blonde moment over this whole configuration > issue. Please excuse my ignorance... and I do appreciate your > help. Below see my comments embedded in your last email.. > >On Wed, 2003-02-12 at 15:16, Jon LaBadie wrote: >> Is there a "groups" command on your system. >> Or maybe the "id" command will show it. > >Both 'groups' and ID work on my system (Mandrake 9) > >>It might be useful to check what are the groups amanda belongs to >> when logged in and when running from cron. >>A little script like this could be make (I'm calling it "ckit") >> >>exec 1> /tmp/ckit-$$ 2>&1 >> >>groups# or id or what ever >>mtx -f status # or info or inquiry or >> what ever > >'amanda' does not belong to any secondary groups. I now have set > the changer device group to 'disk' (the amanda group) and > verified that group has rw permissions. > >lr-xr-xr-x1 root root 36 Feb 10 13:45 /dev/sg2 > -> scsi/host0/bus0/target5/lun1/generic > >crw-rw1 root disk 21, 2 Dec 31 1969 >/dev/scsi/host0/bus0/target5/lun1/generic > >I created the script and ran at the command line as 'amanda' as > well as from amanda's cron. The output looks like this: (I called > both groups and id in the script) The output was identical from > either a shell or cron. > >script output: > >disk >uid=502(amanda) gid=6(disk) groups=6(disk) > Storage Changer /dev/sg2:1 Drives, 6 Slots ( 0 Import/Export ) >Data Transfer Element 0:Full (Storage Element 2 Loaded) > Storage Element 1:Full > Storage Element 2:Empty > Storage Element 3:Full > Storage Element 4:Full > Storage Element 5:Full > Storage Element 6:Full > >> If that works, try a "cd amanda_config_dir ; chg-zd-mtx > command>" in the cron script. > >OK - I tried this manually.. my configs are in >/usr/local/etc/amanda/daily-net. So I went there and ran: > >/usr/local/libexec/chg-zd-mtx -info. The result was not good. It > returns > >" could not determine current slot" > >The contents of the debug file for the above test is: >== >chg-zd-mtx: debug 1 pid 3361 ruid 0 euid 0: start at Thu Feb 13 > 09:34:17 2003 >09:34:17 Arg info: > $# = 1 > $0 = "/usr/local/libexec/chg-zd-mtx" > $1 = "-info" >09:34:17 Running: /sbin/mtx status >09:34:17 Exit code: 0 > Stdout: > Storage Changer /dev/sg2:1 Drives, 6 Slots ( 0 Import/Export ) >Data Transfer Element 0:Full (Storage Element 2 Loaded) > Storage Element 1:Full > Storage Element 2:Empty > Storage Element 3:Full > Storage Element 4:Full > Storage Element 5:Full > Storage Element 6:Full >09:34:17 Config info: > firstslot = "1" > lastslot = "6" > cleanslot = "6" Here is the only place I see that might be a problem, but it doesn't appear to be germain to your problem. IF you have a cleaning tape in slot 6, then one would normally set lastslot to "5" which would prevent the inadvertant clean cycle during a "looking for the right tape" scan. IF you don't keep a cleaning tape in slot 6 then I'd not even define cleanslot. I don't know enough about your drive to be much help other than this. My experience is with a Seagate/Campaq 4 slotter. > cleancycle = "120" > offline_before_unload = "0" > unloadpause = "0" > autoclean = "0" > autocleancount = "99" > havereader = "0" > driveslot = "1" > poll_drive_ready = "3" > max_drive_wait = "120" >09:34:17 Exit (2) -> could not determine current slot >chg-zd-mtx: pid 3484 finish time Thu Feb 13 09:34:17 2003 >== > >I don't know if this helps in determining where my stuff is SB > (Sh**'s broke) > >The user config portion of ../daily-net/mtx-changer: > >### USER CONFIGURATION ># Name of the tape drive (takes place of "tapedev" option in >amanda.conf) ># and default driver number in library (usu 0) that DRIVE_NAME > points to >DRIVE_NAME="/dev/nst1" >DRIVE_NUM=0 > ># Location of "STC" command and control device >MTX_CMD="/sbin/mtx"; >MTX_CONTROL="/dev/sg2"; > ># Whether tape drive must eject tape before changer retrieves ># (ie, EXB-2x0). Usually okay if set while not necessary, bad if ># required but not set. >DRIVE_MUST_EJECT=1 > ># How long to check drive readiness (in seconds) after mounting > (or # ejecting) a volume (on some libraries, the motion or eject > command may ># complete before the drive has the volume fully mounted and > online, # or ready for retrieval, resulting in "Drive not > ready"/"Media not # ready" errors). Do an "mt status" command > every 5 seconds upto this # time. >DRIVE_READY_TIME_MAX=120 > ># tape "mt" command location... >MT_CMD="/bin/mt" # called via "MT_CMD -f DRIVE_NAME rewind" & > # "MT_CMD -f DRIVE_NAME offline" to > eject
Re: another chg-zd-mtx problem
Jon - Perhaps I'm have a blonde moment over this whole configuration issue. Please excuse my ignorance... and I do appreciate your help. Below see my comments embedded in your last email.. On Wed, 2003-02-12 at 15:16, Jon LaBadie wrote: > Is there a "groups" command on your system. > Or maybe the "id" command will show it. Both 'groups' and ID work on my system (Mandrake 9) >It might be useful to check what are the groups amanda belongs to when logged in and >when running from cron. >A little script like this could be make (I'm calling it "ckit") > >exec 1> /tmp/ckit-$$ 2>&1 > >groups # or id or what ever >mtx -f status # or info or inquiry or what ever > 'amanda' does not belong to any secondary groups. I now have set the changer device group to 'disk' (the amanda group) and verified that group has rw permissions. lr-xr-xr-x1 root root 36 Feb 10 13:45 /dev/sg2 -> scsi/host0/bus0/target5/lun1/generic crw-rw1 root disk 21, 2 Dec 31 1969 /dev/scsi/host0/bus0/target5/lun1/generic I created the script and ran at the command line as 'amanda' as well as from amanda's cron. The output looks like this: (I called both groups and id in the script) The output was identical from either a shell or cron. script output: disk uid=502(amanda) gid=6(disk) groups=6(disk) Storage Changer /dev/sg2:1 Drives, 6 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 2 Loaded) Storage Element 1:Full Storage Element 2:Empty Storage Element 3:Full Storage Element 4:Full Storage Element 5:Full Storage Element 6:Full > If that works, try a "cd amanda_config_dir ; chg-zd-mtx " > in the cron script. OK - I tried this manually.. my configs are in /usr/local/etc/amanda/daily-net. So I went there and ran: /usr/local/libexec/chg-zd-mtx -info. The result was not good. It returns " could not determine current slot" The contents of the debug file for the above test is: == chg-zd-mtx: debug 1 pid 3361 ruid 0 euid 0: start at Thu Feb 13 09:34:17 2003 09:34:17 Arg info: $# = 1 $0 = "/usr/local/libexec/chg-zd-mtx" $1 = "-info" 09:34:17 Running: /sbin/mtx status 09:34:17 Exit code: 0 Stdout: Storage Changer /dev/sg2:1 Drives, 6 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 2 Loaded) Storage Element 1:Full Storage Element 2:Empty Storage Element 3:Full Storage Element 4:Full Storage Element 5:Full Storage Element 6:Full 09:34:17 Config info: firstslot = "1" lastslot = "6" cleanslot = "6" cleancycle = "120" offline_before_unload = "0" unloadpause = "0" autoclean = "0" autocleancount = "99" havereader = "0" driveslot = "1" poll_drive_ready = "3" max_drive_wait = "120" 09:34:17 Exit (2) -> could not determine current slot chg-zd-mtx: pid 3484 finish time Thu Feb 13 09:34:17 2003 == I don't know if this helps in determining where my stuff is SB (Sh**'s broke) The user config portion of ../daily-net/mtx-changer: ### USER CONFIGURATION # Name of the tape drive (takes place of "tapedev" option in amanda.conf) # and default driver number in library (usu 0) that DRIVE_NAME points to DRIVE_NAME="/dev/nst1" DRIVE_NUM=0 # Location of "STC" command and control device MTX_CMD="/sbin/mtx"; MTX_CONTROL="/dev/sg2"; # Whether tape drive must eject tape before changer retrieves # (ie, EXB-2x0). Usually okay if set while not necessary, bad if # required but not set. DRIVE_MUST_EJECT=1 # How long to check drive readiness (in seconds) after mounting (or # ejecting) a volume (on some libraries, the motion or eject command may # complete before the drive has the volume fully mounted and online, # or ready for retrieval, resulting in "Drive not ready"/"Media not # ready" errors). Do an "mt status" command every 5 seconds upto this # time. DRIVE_READY_TIME_MAX=120 # tape "mt" command location... MT_CMD="/bin/mt" # called via "MT_CMD -f DRIVE_NAME rewind" & # "MT_CMD -f DRIVE_NAME offline" to eject # and "MT_CMD -f DRIVE_NAME status" to get ready info and one again my mtx-changer.conf is: firstslot=1 1st tape slot lastslot=6 Last tape slot cleanslot=6 Slot with cleaner tape # Do you want to clean the drive after a certain number of accesses? # NOTE - This is unreliable, since 'accesses' aren't 'uses', and we # have no reliable way to count this. A single amcheck could # generate as many accesses as slots you have, plus 1. # ALSO NOTE - many modern tape loaders handle this automatically. AUTOCLEAN=0 Set to '1' or greater to enable autocleancount=99 Number of access before a clean. havereader=0
Re: another chg-zd-mtx problem
On Wed, Feb 12, 2003 at 12:25:40PM -0500, Pete Poggione wrote: > amcheck now gives me: > > Amanda Tape Server Host Check > - > Holding disk /var/tmp: 7048472 KB disk space available, that's plenty > amcheck-server: could not get changer info: could not determine current > slot Have you set the changer device to the same group ?disk? as amanda. Your last report still had it as group root. > > > [root@ruby lun1]# ls -l > > > total 0 > > > crw-rw1 root root 21, 2 Dec 31 1969 generic -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: another chg-zd-mtx problem
Hi Pete, Could you try this patch. Jean-Louis On Wed, Feb 12, 2003 at 12:25:40PM -0500, Pete Poggione wrote: > amcheck now gives me: > > Amanda Tape Server Host Check > - > Holding disk /var/tmp: 7048472 KB disk space available, that's plenty > amcheck-server: could not get changer info: could not determine current > slot > > Amanda Backup Client Hosts Check > > Client check: 1 host checked in 0.556 seconds, 0 problems found > > (brought to you by Amanda 2.4.3) > > same if I try amtape. I get the 'could not determine current slot' > error. > > Incidentally there has been some questions as to the version of Amanda I > am running. It's 2.4.3 now. I upgraded from 2.4.2 in hopes that it would > fix the chg-zd-mtx problem. > > The system is Mandrake 9.0 > > ~P > > > On Wed, 2003-02-12 at 11:09, Eric Sproul wrote: > > On Wed, 2003-02-12 at 10:49, Pete Poggione wrote: > > > You and I are thinking the same. As I looked further it seems for some > > > reason the target was not owned by root but rather by me.(?) changing > > > the ownership to root eliminated all permission issues. It is now like > > > this: > > > > > > [root@ruby dev]# ls -l sg2 > > > lr-xr-xr-x1 root root 36 Feb 10 13:45 /dev/sg2 -> > > > scsi/host0/bus0/target5/lun1/generic > > > > > > [root@ruby lun1]# ls -l > > > total 0 > > > crw-rw1 root root 21, 2 Dec 31 1969 generic > > > > Well, the mod date seems weird, in that it is set to the UNIX epoch, but > > I guess that doesn't really matter. It still doesn't appear that > > amanda's group 'disk' would have access to this file, but that may be an > > affect of your particular system (what OS is this?). Your success with > > mtx below means that for whatever reason, the permissions seem to be OK. > > > > > mtx now responds correctly for user 'amanda' > > > > > > [root@ruby amanda-2.4.3]# su amanda -c "mtx status" > > > Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) > > > Data Transfer Element 0:Full (Storage Element 1 Loaded) > > > Storage Element 1:Empty > > > Storage Element 2:Full > > > Storage Element 3:Full > > > Storage Element 4:Full > > > Storage Element 5:Full > > > Storage Element 6:Full > > > > > > Do you see anything weird about this or am I correct in assuming this > > > should be ok? > > > > This does indeed look like mtx succeeded. The next step would be to > > ensure that amanda can execute the changer functions via her generic > > commands, like 'eject' or 'slot X'. Something like > > > > # su amanda -c amtape slot 1 > > > > If that works, then you're all set. > > > > Cheers, > > Eric > -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834 --- changer-src/chg-zd-mtx.sh.in.orig 2002-11-04 20:37:52.0 -0500 +++ changer-src/chg-zd-mtx.sh.in2003-02-12 13:56:28.0 -0500 @@ -472,7 +472,7 @@ loadedbarcode=$2 if [ -z "$loadedslot" ]; then - Exit 2 "" "could not determine current slot" + Exit 2 "" "could not determine current slot, are you sure your +drive slot is $driveslot" return $? # in case we are internal fi if IsNumeric "$loadedslot" ; then
Re: another chg-zd-mtx problem
amcheck now gives me: Amanda Tape Server Host Check - Holding disk /var/tmp: 7048472 KB disk space available, that's plenty amcheck-server: could not get changer info: could not determine current slot Amanda Backup Client Hosts Check Client check: 1 host checked in 0.556 seconds, 0 problems found (brought to you by Amanda 2.4.3) same if I try amtape. I get the 'could not determine current slot' error. Incidentally there has been some questions as to the version of Amanda I am running. It's 2.4.3 now. I upgraded from 2.4.2 in hopes that it would fix the chg-zd-mtx problem. The system is Mandrake 9.0 ~P On Wed, 2003-02-12 at 11:09, Eric Sproul wrote: > On Wed, 2003-02-12 at 10:49, Pete Poggione wrote: > > You and I are thinking the same. As I looked further it seems for some > > reason the target was not owned by root but rather by me.(?) changing > > the ownership to root eliminated all permission issues. It is now like > > this: > > > > [root@ruby dev]# ls -l sg2 > > lr-xr-xr-x1 root root 36 Feb 10 13:45 /dev/sg2 -> > > scsi/host0/bus0/target5/lun1/generic > > > > [root@ruby lun1]# ls -l > > total 0 > > crw-rw1 root root 21, 2 Dec 31 1969 generic > > Well, the mod date seems weird, in that it is set to the UNIX epoch, but > I guess that doesn't really matter. It still doesn't appear that > amanda's group 'disk' would have access to this file, but that may be an > affect of your particular system (what OS is this?). Your success with > mtx below means that for whatever reason, the permissions seem to be OK. > > > mtx now responds correctly for user 'amanda' > > > > [root@ruby amanda-2.4.3]# su amanda -c "mtx status" > > Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) > > Data Transfer Element 0:Full (Storage Element 1 Loaded) > > Storage Element 1:Empty > > Storage Element 2:Full > > Storage Element 3:Full > > Storage Element 4:Full > > Storage Element 5:Full > > Storage Element 6:Full > > > > Do you see anything weird about this or am I correct in assuming this > > should be ok? > > This does indeed look like mtx succeeded. The next step would be to > ensure that amanda can execute the changer functions via her generic > commands, like 'eject' or 'slot X'. Something like > > # su amanda -c amtape slot 1 > > If that works, then you're all set. > > Cheers, > Eric
Re: another chg-zd-mtx problem
On Wed, 2003-02-12 at 10:49, Pete Poggione wrote: > You and I are thinking the same. As I looked further it seems for some > reason the target was not owned by root but rather by me.(?) changing > the ownership to root eliminated all permission issues. It is now like > this: > > [root@ruby dev]# ls -l sg2 > lr-xr-xr-x1 root root 36 Feb 10 13:45 /dev/sg2 -> > scsi/host0/bus0/target5/lun1/generic > > [root@ruby lun1]# ls -l > total 0 > crw-rw1 root root 21, 2 Dec 31 1969 generic Well, the mod date seems weird, in that it is set to the UNIX epoch, but I guess that doesn't really matter. It still doesn't appear that amanda's group 'disk' would have access to this file, but that may be an affect of your particular system (what OS is this?). Your success with mtx below means that for whatever reason, the permissions seem to be OK. > mtx now responds correctly for user 'amanda' > > [root@ruby amanda-2.4.3]# su amanda -c "mtx status" > Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) > Data Transfer Element 0:Full (Storage Element 1 Loaded) > Storage Element 1:Empty > Storage Element 2:Full > Storage Element 3:Full > Storage Element 4:Full > Storage Element 5:Full > Storage Element 6:Full > > Do you see anything weird about this or am I correct in assuming this > should be ok? This does indeed look like mtx succeeded. The next step would be to ensure that amanda can execute the changer functions via her generic commands, like 'eject' or 'slot X'. Something like # su amanda -c amtape slot 1 If that works, then you're all set. Cheers, Eric
Re: another chg-zd-mtx problem
You and I are thinking the same. As I looked further it seems for some reason the target was not owned by root but rather by me.(?) changing the ownership to root eliminated all permission issues. It is now like this: [root@ruby dev]# ls -l sg2 lr-xr-xr-x1 root root 36 Feb 10 13:45 /dev/sg2 -> scsi/host0/bus0/target5/lun1/generic [root@ruby lun1]# ls -l total 0 crw-rw1 root root 21, 2 Dec 31 1969 generic I set mtx back to where it should be as well (as originally defaulted after install) [root@ruby lun1]# ls -la /sbin/mtx -rwxr-xr-x1 root root20140 May 16 2002 /sbin/mtx* mtx now responds correctly for user 'amanda' [root@ruby amanda-2.4.3]# su amanda -c "mtx status" Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 1 Loaded) Storage Element 1:Empty Storage Element 2:Full Storage Element 3:Full Storage Element 4:Full Storage Element 5:Full Storage Element 6:Full Do you see anything weird about this or am I correct in assuming this should be ok? > > Pete, > Could you list the entry for the target of this link? I'm not sure the > link's permissions matter, as they would only affect who could reference > the link itself, with final access granted by the permissions of the > target. > > AFAIK, the target will need rw by group 'disk' in order for AMANDA to > control the changer. > > Cheers, > Eric
Re: another chg-zd-mtx problem
On Wed, 2003-02-12 at 09:58, Pete Poggione wrote: > If I change the group of /dev/sg2 to disk (the amanda group on my box is > 'disk') I still get the same problem: > > [root@ruby daily-net]# ls -la /dev/sg2 > lr-xr-xr-x1 root disk 36 Feb 10 13:45 /dev/sg2 -> > scsi/host0/ Pete, Could you list the entry for the target of this link? I'm not sure the link's permissions matter, as they would only affect who could reference the link itself, with final access granted by the permissions of the target. AFAIK, the target will need rw by group 'disk' in order for AMANDA to control the changer. Cheers, Eric
Re: another chg-zd-mtx problem
Eric - Yeah my brain must have been up my proverbial a**. I actually tried that first and it didn't work. What I didn't pay attention to was that /dev/sg2 actually was a sym link to /dev/scsi/host0/ (I'm running Mandrake 9 and using devfs) So once I changed the group recursively of /dev/scsi/host0/ I was fine for this part of my problems anyway. Thanks for making me take a second look at that. If I change the group of /dev/sg2 to disk (the amanda group on my box is 'disk') I still get the same problem: [root@ruby daily-net]# ls -la /dev/sg2 lr-xr-xr-x1 root disk 36 Feb 10 13:45 /dev/sg2 -> scsi/host0/ On Tue, 2003-02-11 at 16:21, Eric Sproul wrote: > On Tue, 2003-02-11 at 14:41, Pete Poggione wrote: > > I get an error trying to access /dev/sg2 as the Amanda user so I had to > > set /sbin/mtx to run as suid root. That seemed to take care of that > > issue (if anyone has a better idea let me know) > > Pete, > This is not wise-- with suid root, any non-privileged user on the system > would be able to execute mtx. This is probably not what you want. It > would be better to make the device read/writable by the group that the > amanda user belongs to, such as "operator" or "backup". > > For example, on my Debian box, I have an HP changer as well, and the > robot is on /dev/sg2 like yours. On Debian, amanda runs as user > "backup" and group "backup" so I did: > > # chmod g+rw backup /dev/sg2 > > Now amanda has access to the robot without making mtx suid root. Normal > users have no access to the device. > > HTH, > Eric
Re: another chg-zd-mtx problem
>amcheck-server: could not get changer info: badly formed result from >changer: "/usr/lib/amanda/chg-zd-mtx: line 151: [: : integer expression >expected" You neglected to mention what version of Amanda you're using, but this was a known problem with chg-zd-mtx a while back. I don't think it was every specifically fixed, but the entire script was overhauled to clean up a lot of things and this was taken care of in the process. My suggestion would be to get 2.4.3 from www.amanda.org and uncrate it, then copy chg-zd-mtx.sh.in over the one you built from (I'd also make a copy of the old one first, just in case). Then re-configure, re-build and re-install, at least in the changer-src directory. You don't have to install all of 2.4.3 (in fact, I don't think I'd recommend it due to some memory bugs and the nearness of 2.4.4). As I recall, chg-zd-mtx should be fully backward compatible with whatever you're running. >Pete John R. Jackson, Technical Software Specialist, ITaP/RCS, [EMAIL PROTECTED]
Re: another chg-zd-mtx problem
On Tue, 2003-02-11 at 14:41, Pete Poggione wrote: > I get an error trying to access /dev/sg2 as the Amanda user so I had to > set /sbin/mtx to run as suid root. That seemed to take care of that > issue (if anyone has a better idea let me know) Pete, This is not wise-- with suid root, any non-privileged user on the system would be able to execute mtx. This is probably not what you want. It would be better to make the device read/writable by the group that the amanda user belongs to, such as "operator" or "backup". For example, on my Debian box, I have an HP changer as well, and the robot is on /dev/sg2 like yours. On Debian, amanda runs as user "backup" and group "backup" so I did: # chmod g+rw backup /dev/sg2 Now amanda has access to the robot without making mtx suid root. Normal users have no access to the device. HTH, Eric
another chg-zd-mtx problem
If this problem is addressed somewhere else in the mail list archives I
apologize in advance. I have not been able to find anything that helps
me solve this problem after 3 days of searching and fiddling...
THE HISTORY:
I have had Amanda configured and running on this server with a single
internal tape drive with no issues. The internal drive is /dev/nst0.
I have installed a HP SureStore 24x6 to handle the backups now as the
internal drive is just too small and requires too much manual
intervention. The SureStore tape device is /dev/nst1 and the changer is
/dev/sg2. Since the HP does not use a separate SCSI ID for the changer
using the tape device's no-rewind device is what needs to be done.
The changer responds on both /dev/sg1 and /dev/sg2 but only /dev/sg2
will respond to the mtx eject command so I figured that is the proper
one to use.
The SCSI info on the box:
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
(scsi0:A:5): 10.000MB/s transfers (10.000MHz, offset 15)
scsi1 : SCSI host adapter emulation for IDE ATAPI devices
Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0
Attached scsi tape st1 at scsi0, channel 0, id 5, lun 0
Vendor: WangDAT Model: Model 3200Rev: 02.5
Vendor: HPModel: C1557ARev: U812
Vendor: HPModel: C1557ARev: U812
I get an error trying to access /dev/sg2 as the Amanda user so I had to
set /sbin/mtx to run as suid root. That seemed to take care of that
issue (if anyone has a better idea let me know)
The changer responds to mtx fine: (example)
[root@ruby daily-net]# su amanda -c "mtx -f /dev/sg2 status"
Storage Changer /dev/sg2:1 Drives, 6 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
Storage Element 1:Full
Storage Element 2:Full
Storage Element 3:Full
Storage Element 4:Full
Storage Element 5:Full
Storage Element 6:Full
as well as mt:
su amanda -c "mt -f /dev/nst1 status"
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (5):
DR_OPEN IM_REP_EN
THE PROBLEM:
I can't seem to get the configuration to work right with the SureStore.
Running amcheck yields:
[root@ruby daily-net]# su amanda -c "amcheck daily-net"
Amanda Tape Server Host Check
-
Holding disk /var/tmp: 7068972 KB disk space available, that's plenty
amcheck-server: could not get changer info: badly formed result from
changer: "/usr/lib/amanda/chg-zd-mtx: line 151: [: : integer expression
expected"
Amanda Backup Client Hosts Check
Client check: 1 host checked in 0.900 seconds, 0 problems found
I had a suggestion that /usr/lib/amanda/chg-zd-mtx had some issues out
of the box and needed to be edited. An Amanda user that uses the same
tape drive provided me with both an amanda.conf and mtx-changer.conf
files from his working installation to compare against mine. They were
identical except for device locations. Here is the pertinent info from
my files:
chg-zd-mtx looks like that at line 151:
if [ "$usedslot" -eq "-1" ]; then
echo '-1' > $slotfile
fi
amanda.conf:
runtapes 2 # number of tapes to be used in a single run of
amdump
tpchanger "chg-zd-mtx" # the tape-changer glue script
tapedev "/dev/nst1" # the no-rewind tape device to be used
rawtapedev "/dev/nst1" # the raw device to be used (ftape only)
#changerfile "/var/lib/amanda/daily-net/changer"
#changerfile "/var/lib/amanda/daily-net/changer-status"
changerfile "/etc/amanda/daily-net/mtx-changer"
changerdev "/dev/sg2"
tapetype HP1557A
define tapetype HP1557A {
comment "HP SureStore DAT 24x6 tape drive"
# data provided by Ivo Clarysse
length 12000 mbytes
filemark 111 kbytes
speed 3000 kbytes
}
and mtx-changer.conf
firstslot=1 1st tape slot
lastslot=6 Last tape slot
cleanslot=6 Slot with cleaner tape
AUTOCLEAN=0 Set to '1' or greater to enable
autocleancount=99 Number of access before a clean.
havereader=0 If you have a barcode reader, set to 1.
offlinestatus=1 Set to 0 if 'mt status' gives an
"offline" when drive is offline.
Set to 1 or greater if 'mt status'
doesn't give and offline, rather an
"ONLINE" when drive is online.
OFFLINE_BEFORE_UNLOAD=0
If anyone has any idea where I've gone wrong or what the problem is I
would greatly appreciate your comments.
Many thanks in advance.
Pete
signature.asc
Description: This is a digitally signed message part
Re: chg-zd-mtx problem
Get the newest chg.zd.mtx.sh.in from CVS, as it's fixed there.
On Wed, 14 Mar 2001, Mark L. Chang wrote:
> in loadslot() we have code that picks the slot source/destination:
>
> [${firstslot}-${lastslot}])
> loadslot=$1
> ;;
> clean)
> loadslot=$cleanslot
> ;;
> *)
> echo "0 illegal request"
> exit 1
> ;;
>
> works great if you have _single digit_ $firstslot and $lastslot. Well, I
> don't. $lastslot=21 and $firstslot=1 ... any /bin/sh gurus fix this for
> me? or, am I just not using the latest and greatest chg-zd-mtx?
>
> Mark
>
> --
> http://www.mchang.org/
> http://decss.zoy.org/
>
--
Jason Hollinden
SMG Systems Admin
chg-zd-mtx problem
in loadslot() we have code that picks the slot source/destination:
[${firstslot}-${lastslot}])
loadslot=$1
;;
clean)
loadslot=$cleanslot
;;
*)
echo "0 illegal request"
exit 1
;;
works great if you have _single digit_ $firstslot and $lastslot. Well, I
don't. $lastslot=21 and $firstslot=1 ... any /bin/sh gurus fix this for
me? or, am I just not using the latest and greatest chg-zd-mtx?
Mark
--
http://www.mchang.org/
http://decss.zoy.org/
