Re: can only run amanda tests as root
On Friday 04 August 2006 10:21, Matt Hyclak wrote: >On Fri, Aug 04, 2006 at 07:03:39AM -0400, Gene Heskett enlightened us: >> This is a frequent problem when using a 'packaged' version of amanda. >> The rpm packagers in particular have demonstrated many times that they >> do not understand how amanda treats security issues. Amanda's build >> gives it enough perms to do the instant job each piece needs to do, and >> no more. This is why, when potential users run into these sort of >> problems, that we universally recommend that it be built from the >> tarball, following amanda's instructions so that the amanda build and >> install can be done correctly. > >Not to get off topic, and no offense Gene, but that second sentence is >entirely inaccurate. Only if you are looking at it from the redhat/fedora side of the fence, Matt. >There are several problems with Amanda RPMs which >require compromises be made, but not understanding security and how > amanda works is definitely *not* one of them. What some of the problems > are include: > >- Inability to know the hostname of the amanda server (or any server for > that matter) on the clients network. Since amanda requires these at > build time, the only logical compromise is to use localhost With all due respect Matt, that puts a bullet through the heart of any chance to do a recovery with the recovery tools as they specifically reject the localhost as a valid name because it could be any machine anywhere. Thats one of the security things amanda enforces. Without that, recovery is a mt, dd, gzip and tar exersize. Doable, but a pita. Either that, or you have to patch that back out of amanda before the object package is built. >- Inability to know what user the software will be built as (if > rebuilding a source RPM). There are RPM mechanisms in place that fix > that, though not pretty, which set ownership to the appropriate user and > permissions. I would argue that the fact these are in there (at least in > the > RedHat-produced RPMs) counter your point about not understanding the > security needs. Then the only way to do amanda as an rpm is in the form of a source rpm isn't it? >As always, I consider http://www.math.ohiou.edu/~hyclak/casit/amanda/ a >worthwhile read for anyone using an RPM-based system, and recommend that >users of Amanda rebuild SRPMs for their environment. Jay has made it > easier with the latest Fedora Development RPMs to do that in the future. Whats needed is that this src rpm be self building as it installs, after installing its own user, makeing that user a member of the group disk or backup as appropriate and detecting via uname responses the host servers name during the configure stage, and the install process switching users as appropriate during the build and install phases. However rpm does not that I know of, and I'm certainly not a real card carrying expert about rpm, support the continuous build and install of a src rpm in one command line execution. AFAIK it just builds the package, leaving the user to then install it in a seperate step. Maybe its time for rpm-5.0? And we were, in the present case, talking about SuSe rpms, not redhat/fedora. Redhat/fedora rpms haven't recently been enough of a problem to generate noticable traffic on the list. They were, in spades, 2-3 years ago, as I'm sure you are aware, with no little traffic defending rpms coming from the redhat camp's packager, whose name escapes me at this late date but it wasn't you. And I don't recall that it was Jay at the time either, but I could be wrong about that. But after he (whomever) had lurked and listened on the list for a while, it seemed that the problems with redhat/fedora rpms went away. So in that regard, redhat/fedora seems to have adjusted their packageing enough fix it. I guess that because amanda is so easily built and installed, I'm naturally going to do it that way. And I haven't been reticent about posting my script to do that, along with suitable caveats about what needs to be changed. I haven't changed that script but once in 6 years since I wrote it, and that was when I switched to vtapes nearly 2 years ago. Its not a very long script, but it guarantees that option compatibility is maintained from snapshot to snapshot. In any event, it turned out to not be an amanda problem, but a SuSe furnished 50-udev.rules problem and I believe the OP has now posted that he has fixed it. >Respectfully, >Matt -- Cheers Matt, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: can only run amanda tests as root
On Fri, Aug 04, 2006 at 07:03:39AM -0400, Gene Heskett enlightened us: > This is a frequent problem when using a 'packaged' version of amanda. The > rpm packagers in particular have demonstrated many times that they do not > understand how amanda treats security issues. Amanda's build gives it > enough perms to do the instant job each piece needs to do, and no more. > This is why, when potential users run into these sort of problems, that we > universally recommend that it be built from the tarball, following > amanda's instructions so that the amanda build and install can be done > correctly. > Not to get off topic, and no offense Gene, but that second sentence is entirely inaccurate. There are several problems with Amanda RPMs which require compromises be made, but not understanding security and how amanda works is definitely *not* one of them. What some of the problems are include: - Inability to know the hostname of the amanda server (or any server for that matter) on the clients network. Since amanda requires these at build time, the only logical compromise is to use localhost - Inability to know what user the software will be built as (if rebuilding a source RPM). There are RPM mechanisms in place that fix that, though not pretty, which set ownership to the appropriate user and permissions. I would argue that the fact these are in there (at least in the RedHat-produced RPMs) counter your point about not understanding the security needs. As always, I consider http://www.math.ohiou.edu/~hyclak/casit/amanda/ a worthwhile read for anyone using an RPM-based system, and recommend that users of Amanda rebuild SRPMs for their environment. Jay has made it easier with the latest Fedora Development RPMs to do that in the future. Respectfully, Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
Re: can only run amanda tests as root
On Friday 04 August 2006 08:19, Stephen Carter wrote: Gene Heskett <[EMAIL PROTECTED]> 08/04/06 12:03 PM >>> >> >>This is why, when potential users run into these sort of problems, that >> we universally recommend that it be built from the tarball, following >> amanda's instructions so that the amanda build and install can be done >> correctly. >> >>Cheers, Gene > >In this instance, installing from source made no difference to the > outcome of the perms that are applied to the autochanger devices by > udev. > >I also thought along the same lines initially so when I installed from > source and came across the same problem (but I didn't realise why at the > time) I knew it was not an amanda issue at all. > >SteveC Ahh, so I was carrying coals to Newcastle. :( But was the snippet of 50-udev.rules I posted from my FC5 lappy of any assistance? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: can only run amanda tests as root
>>> Gene Heskett <[EMAIL PROTECTED]> 08/04/06 12:03 PM >>> >This is why, when potential users run into these sort of problems, that we >universally recommend that it be built from the tarball, following >amanda's instructions so that the amanda build and install can be done >correctly. > >Cheers, Gene In this instance, installing from source made no difference to the outcome of the perms that are applied to the autochanger devices by udev. I also thought along the same lines initially so when I installed from source and came across the same problem (but I didn't realise why at the time) I knew it was not an amanda issue at all. SteveC
Re: can only run amanda tests as root
On Friday 04 August 2006 05:24, Paul Bijnens wrote:
>On 2006-08-04 10:31, Stephen Carter wrote:
>> I installed Amanda via rpm and it's been around in SuSE for a long
>> time, so I would expect someone to have picked up this 'basic'
>> problem and fixed it since SuSE 9.3 up to SLES 10 if it were an
>> amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1,
>> SLES9 & 10). The permissions are correct for the amanda user, and
>> amanda's default group is the disk group.
>>
>> The problem is that the disk group has, by default, only read access
>> to changer devices (/dev/sg*) in SuSE that are created dynamically
>> during boot. The perms assigned are governed by rules in udev, which
>> I pointed out.
>>
>> For what it's worth, all no changer tape devices (e.g. /dev/nst*) do
>> give the disk group read and write perms by default so no problem
>> there... it's only an issue if you are using a changer with SuSE (or
>> CentOS apparently)
>
>CentOS???
>
>I run CentOS 4.3, and in my /etc/udev/permissions.d/50-udev.permissions
>I find:
>
> [...]
> # disk devices
> hd*:root:disk:0660
> sd*:root:disk:0660
> [...]
> # tape devices
> [...]
> st*:root:disk:0660
> nst*:root:disk:0660
> [...]
> # scsi devices
> sg*:root:disk:0660
>
>
>So, all seems fine here.
This is not the same format as is contained in this file on my FC5 lappy,
but in all cases of a changer or a scanner assigned to a /dev/sg#, the
perms assigned appear to be root:disk and 0660. From that file:
===
# sd: 0 TYPE_DISK, 7 TYPE_MOD, 14 TYPE_RBC
# sr: 4 TYPE_WORM, 5 TYPE_ROM
# st/osst: 1 TYPE_TAPE
# sg: 8 changer, [36] scanner
ACTION=="add", SUBSYSTEM="scsi" , SYSFS{type}=="0|7|14", \
RUN+="/bin/sh -c 'echo 60 > /sys$$DEVPATH/timeout'"
ACTION=="add", SUBSYSTEM="scsi" , SYSFS{type}=="1", \
RUN+="/bin/sh -c 'echo 900 > /sys$$DEVPATH/timeout'"
ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg"
ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="0|7|14", \
RUN+="/sbin/modprobe sd_mod"
ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="[45]", \
RUN+="/sbin/modprobe sr_mod"
ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]", \
SYMLINK+="scanner scanner-%k", MODE="0660"
ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="8", \
SYMLINK+="changer changer-%k", MODE="0660", GROUP="disk"
ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="1",
SYSFS{device/vendor}=="On[sS]tream", \
SYSFS{model}!="ADR*", RUN+="/sbin/modprobe osst"
ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="1",
SYSFS{device/vendor}=="On[sS]tream", \
SYSFS{model}=="ADR*", RUN+="/sbin/modprobe st"
ACTION=="add", SUBSYSTEM=="scsi_device", SYSFS{type}=="1",
SYSFS{device/vendor}!="On[sS]tream", \
RUN+="/sbin/modprobe st"
=
I have no idea if this is correct as there's no changer, not even any scsi
stuff on this lappy, but you can compare and fix the obvious stuff at
least. And file a bugzilla entry if you get it fixed, giving details.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: can only run amanda tests as root
On Friday 04 August 2006 04:31, Stephen Carter wrote: Gene Heskett <[EMAIL PROTECTED]> 08/02/06 12:09 PM >>> >> >>Then you don't have your amanda user in the correct group, amanda should >> be a member of the group disk in your case. >> >>This walks and quacks like the incorrect installation duck, amanda >> should be configured and built by the user amanda (or whoever is >> actually going to run amanda, and NOT root) and this user should be a >> member of the group that includes disk and backup. >> >>However, after amanda has been built by this user, then amanda must be >>installed by root, thereby setting up all these permissions and setuids >>automaticly. >> >I installed Amanda via rpm and it's been around in SuSE for a long time, > so I would expect someone to have picked up this 'basic' problem and > fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile / > install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 & 10). The > permissions are correct for the amanda user, and amanda's default group > is the disk group. > >The problem is that the disk group has, by default, only read access to > changer devices (/dev/sg*) in SuSE that are created dynamically during > boot. The perms assigned are governed by rules in udev, which I pointed > out. > >For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give > the disk group read and write perms by default so no problem there... > it's only an issue if you are using a changer with SuSE (or CentOS > apparently) > This is a frequent problem when using a 'packaged' version of amanda. The rpm packagers in particular have demonstrated many times that they do not understand how amanda treats security issues. Amanda's build gives it enough perms to do the instant job each piece needs to do, and no more. This is why, when potential users run into these sort of problems, that we universally recommend that it be built from the tarball, following amanda's instructions so that the amanda build and install can be done correctly. As for the udev permissions problem, I haven't used it yet (FC2 and RH7.3 boxes here) so I cannot advise on the exact fix, but I'm told there is a .conf file that controls this, and that it can be edited to fix the changer perms. If the local build is not an option, then one should file a bugzilla entry against the specific package(s) at Suse. I would include udev as the root of the problem in this case. >Stephen Carter >Retrac Networking Limited >www: http://www.retnet.co.uk >Ph: +44 (0)7870 218 693 >Fax: +44 (0)870 7060 056 >CNA, CNE 6, CNS, CCNA, MCSE 2003 -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: can only run amanda tests as root
>>> Paul Bijnens <[EMAIL PROTECTED]> 08/04/06 10:24 AM >>> >CentOS??? > >So, all seems fine here. >-- >Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 >Technologielaan 21 bus 2, B- 3001 Leuven, BELGIUMFax +32 16 397.512 >http://www.xplanation.com/ email: [EMAIL PROTECTED] There was an earlier reply to this thread that suggested another user had this problem running CentOS, but maybe he has another issue instead. Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003
Re: can only run amanda tests as root
On 2006-08-04 10:31, Stephen Carter wrote: I installed Amanda via rpm and it's been around in SuSE for a long time, so I would expect someone to have picked up this 'basic' problem and fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 & 10). The permissions are correct for the amanda user, and amanda's default group is the disk group. The problem is that the disk group has, by default, only read access to changer devices (/dev/sg*) in SuSE that are created dynamically during boot. The perms assigned are governed by rules in udev, which I pointed out. For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give the disk group read and write perms by default so no problem there... it's only an issue if you are using a changer with SuSE (or CentOS apparently) CentOS??? I run CentOS 4.3, and in my /etc/udev/permissions.d/50-udev.permissions I find: [...] # disk devices hd*:root:disk:0660 sd*:root:disk:0660 [...] # tape devices [...] st*:root:disk:0660 nst*:root:disk:0660 [...] # scsi devices sg*:root:disk:0660 So, all seems fine here. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: can only run amanda tests as root
>>> Gene Heskett <[EMAIL PROTECTED]> 08/02/06 12:09 PM >>> >Then you don't have your amanda user in the correct group, amanda should be >a member of the group disk in your case. > >This walks and quacks like the incorrect installation duck, amanda should >be configured and built by the user amanda (or whoever is actually going >to run amanda, and NOT root) and this user should be a member of the group >that includes disk and backup. > >However, after amanda has been built by this user, then amanda must be >installed by root, thereby setting up all these permissions and setuids >automaticly. > >-- >Cheers, Gene >People having trouble with vz bouncing email to me should add the word >'online' between the 'verizon', and the dot which bypasses vz's >stupid bounce rules. I do use spamassassin too. :- ) >Yahoo.com and AOL/TW attorneys please note, additions to the above >message by Gene Heskett are: >Copyright 2006 by Maurice Eugene Heskett, all rights reserved. I installed Amanda via rpm and it's been around in SuSE for a long time, so I would expect someone to have picked up this 'basic' problem and fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 & 10). The permissions are correct for the amanda user, and amanda's default group is the disk group. The problem is that the disk group has, by default, only read access to changer devices (/dev/sg*) in SuSE that are created dynamically during boot. The perms assigned are governed by rules in udev, which I pointed out. For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give the disk group read and write perms by default so no problem there... it's only an issue if you are using a changer with SuSE (or CentOS apparently) Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003
Re: can only run amanda tests as root
Stephen, Sorry, not amanda files but system /dev files, I lost track of your OS but I have a robot on a linux system and have the following in my amanda.conf file. you need proper protections on both /dev/nst0 and /dev/sg1 or whatever your OS calls your devices. runtapes 3 # number of tapes to be used in a single run of amdump tpchanger "chg-zd-mtx" # the tape-changer glue script tapedev "/dev/nst0" # the no-rewind tape device to be used rawtapedev "/dev/null" # the raw device to be used (ftape only) #changerfile "/usr/adm/amanda/solarisbackup/changer" #changerfile "/usr/adm/amanda/solarisbackup/changer-status" changerfile "/etc/amanda/agnetha/chg-zd-mtx" changerdev "/dev/sg1" On Wed, Aug 02, 2006 at 09:33:23AM +0100, Stephen Carter wrote: > I figured that part out, and running mtx -f /dev/sg0 inquiry then again for > sg1 showed that my drive was on sg0 and the autoloader was on sg1. > > All the mtx and amtape commands work when being run as the root user, so I > don't think this is a configuration file issue. I think it's more of a setup > issue with users / perms but I just can't see it... > > > Stephen Carter > Retrac Networking Limited > www: http://www.retnet.co.uk > Ph: +44 (0)7870 218 693 > Fax: +44 (0)870 7060 056 > CNA, CNE 6, CNS, CCNA, MCSE 2003 > > > >>> Brian Cuttler <[EMAIL PROTECTED]> 08/01/06 9:16 PM >>> > > The robot/picker/whatever is a different device on most systems > from the tape drive, I've seen it as a different device/SCSI ID > and as the same SCSI ID/different LUN, depending on the implementation. > > You have to check the devices for the robot in this case. > > On Tue, Aug 01, 2006 at 09:10:57PM +0100, Stephen Carter wrote: > > I've got my user amanda who is a member of the disk group, and although > > permissions on all amanda files seem fine, when I try to run > > su amanda - c "/usr/sbin/amtape DailySet1 show" > > > > I get the error > > amtape: could not get changer info: no slots available > > > > I can however run this successfully as root. > > > > My tape device is /dev/sg0 and the changer is /dev/sg1. Both have > > permissions root:disk (along with everything else in /dev it appears) > > > > My amanda config files are in /etc/amanda/DailySet1 and amanda is the owner > > of /etc/amanda and all files beneath that. > > > > I'm running SLES 10 and installed Amanda through YaST which is v2.4.5 > > > > I also uninstalled that and tried doing it directly from source, with > > exactly the same problem... > > > > Any help would be great. > > > > Thanks! > > > > > > Stephen Carter > > Retrac Networking Limited > > www: http://www.retnet.co.uk > > Ph: +44 (0)7870 218 693 > > Fax: +44 (0)870 7060 056 > > CNA, CNE 6, CNS, CCNA, MCSE 2003 > > > > > > > --- >Brian R Cuttler [EMAIL PROTECTED] >Computer Systems Support(v) 518 486- 1697 >Wadsworth Center(f) 518 473- 6384 >NYS Department of HealthHelp Desk 518 473- 0773 > > > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: can only run amanda tests as root
Hi I have the same issue but I am running centos instead of SuSE Jose Ruiz http://www.conectapeople.com - Original Message - From: "Stephen Carter" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 02, 2006 11:15 AM Subject: Re: can only run amanda tests as root I found it. It was udev causing the problems, which I can only thing must be a problem for many SuSE users running amanda with tape changers out there. In /etc/udev/rules.d/50-udev-default.rules there is a line to create sg* devices like: KERNEL=="sg*" NAME="%k", GROUP="disk", MODE="640" This was from a clean install of SLES 10, and will only give members of the disk group read access to /dev/sg* devices, which is why I couldn't run it as amanda. Removing the MODE comment (defaults to rw for both user & group) and a reboot fixed it. Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 "Stephen Carter" <[EMAIL PROTECTED]> 08/02/06 9:33 AM >>> I figured that part out, and running mtx - f /dev/sg0 inquiry then again for sg1 showed that my drive was on sg0 and the autoloader was on sg1. All the mtx and amtape commands work when being run as the root user, so I don't think this is a configuration file issue. I think it's more of a setup issue with users / perms but I just can't see it... Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 Brian Cuttler <[EMAIL PROTECTED]> 08/01/06 9:16 PM >>> The robot/picker/whatever is a different device on most systems from the tape drive, I've seen it as a different device/SCSI ID and as the same SCSI ID/different LUN, depending on the implementation. You have to check the devices for the robot in this case. On Tue, Aug 01, 2006 at 09:10:57PM +0100, Stephen Carter wrote: I've got my user amanda who is a member of the disk group, and although permissions on all amanda files seem fine, when I try to run su amanda - c "/usr/sbin/amtape DailySet1 show" I get the error amtape: could not get changer info: no slots available I can however run this successfully as root. My tape device is /dev/sg0 and the changer is /dev/sg1. Both have permissions root:disk (along with everything else in /dev it appears) My amanda config files are in /etc/amanda/DailySet1 and amanda is the owner of /etc/amanda and all files beneath that. I'm running SLES 10 and installed Amanda through YaST which is v2.4.5 I also uninstalled that and tried doing it directly from source, with exactly the same problem... Any help would be great. Thanks! Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486- 1697 Wadsworth Center(f) 518 473- 6384 NYS Department of HealthHelp Desk 518 473- 0773
Re: can only run amanda tests as root
On Wednesday 02 August 2006 05:15, Stephen Carter wrote: >I found it. > >It was udev causing the problems, which I can only thing must be a > problem for many SuSE users running amanda with tape changers out there. > >In /etc/udev/rules.d/50-udev-default.rules there is a line to create sg* > devices like: KERNEL=="sg*" NAME="%k", GROUP="disk", MODE="640" > >This was from a clean install of SLES 10, and will only give members of > the disk group read access to /dev/sg* devices, which is why I couldn't > run it as amanda. Removing the MODE comment (defaults to rw for both > user & group) and a reboot fixed it. > Then you don't have your amanda user in the correct group, amanda should be a member of the group disk in your case. This walks and quacks like the incorrect installation duck, amanda should be configured and built by the user amanda (or whoever is actually going to run amanda, and NOT root) and this user should be a member of the group that includes disk and backup. However, after amanda has been built by this user, then amanda must be installed by root, thereby setting up all these permissions and setuids automaticly. > >Stephen Carter >Retrac Networking Limited >www: http://www.retnet.co.uk >Ph: +44 (0)7870 218 693 >Fax: +44 (0)870 7060 056 >CNA, CNE 6, CNS, CCNA, MCSE 2003 > "Stephen Carter" <[EMAIL PROTECTED]> 08/02/06 9:33 AM >>> > >I figured that part out, and running mtx - f /dev/sg0 inquiry then again > for sg1 showed that my drive was on sg0 and the autoloader was on sg1. > >All the mtx and amtape commands work when being run as the root user, so > I don't think this is a configuration file issue. I think it's more of a > setup issue with users / perms but I just can't see it... > > >Stephen Carter >Retrac Networking Limited >www: http://www.retnet.co.uk >Ph: +44 (0)7870 218 693 >Fax: +44 (0)870 7060 056 >CNA, CNE 6, CNS, CCNA, MCSE 2003 > Brian Cuttler <[EMAIL PROTECTED]> 08/01/06 9:16 PM >>> > >The robot/picker/whatever is a different device on most systems >from the tape drive, I've seen it as a different device/SCSI ID >and as the same SCSI ID/different LUN, depending on the implementation. > >You have to check the devices for the robot in this case. > >On Tue, Aug 01, 2006 at 09:10:57PM +0100, Stephen Carter wrote: >> I've got my user amanda who is a member of the disk group, and although >> permissions on all amanda files seem fine, when I try to run su amanda >> - c "/usr/sbin/amtape DailySet1 show" >> >> I get the error >> amtape: could not get changer info: no slots available >> >> I can however run this successfully as root. >> >> My tape device is /dev/sg0 and the changer is /dev/sg1. Both have >> permissions root:disk (along with everything else in /dev it appears) >> >> My amanda config files are in /etc/amanda/DailySet1 and amanda is the >> owner of /etc/amanda and all files beneath that. >> >> I'm running SLES 10 and installed Amanda through YaST which is v2.4.5 >> >> I also uninstalled that and tried doing it directly from source, with >> exactly the same problem... >> >> Any help would be great. >> >> Thanks! >> >> >> Stephen Carter >> Retrac Networking Limited >> www: http://www.retnet.co.uk >> Ph: +44 (0)7870 218 693 >> Fax: +44 (0)870 7060 056 >> CNA, CNE 6, CNS, CCNA, MCSE 2003 > >--- > Brian R Cuttler [EMAIL PROTECTED] > Computer Systems Support(v) 518 486- 1697 > Wadsworth Center(f) 518 473- 6384 > NYS Department of HealthHelp Desk 518 473- 0773 -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: can only run amanda tests as root
I found it. It was udev causing the problems, which I can only thing must be a problem for many SuSE users running amanda with tape changers out there. In /etc/udev/rules.d/50-udev-default.rules there is a line to create sg* devices like: KERNEL=="sg*" NAME="%k", GROUP="disk", MODE="640" This was from a clean install of SLES 10, and will only give members of the disk group read access to /dev/sg* devices, which is why I couldn't run it as amanda. Removing the MODE comment (defaults to rw for both user & group) and a reboot fixed it. Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 >>> "Stephen Carter" <[EMAIL PROTECTED]> 08/02/06 9:33 AM >>> I figured that part out, and running mtx - f /dev/sg0 inquiry then again for sg1 showed that my drive was on sg0 and the autoloader was on sg1. All the mtx and amtape commands work when being run as the root user, so I don't think this is a configuration file issue. I think it's more of a setup issue with users / perms but I just can't see it... Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 >>> Brian Cuttler <[EMAIL PROTECTED]> 08/01/06 9:16 PM >>> The robot/picker/whatever is a different device on most systems from the tape drive, I've seen it as a different device/SCSI ID and as the same SCSI ID/different LUN, depending on the implementation. You have to check the devices for the robot in this case. On Tue, Aug 01, 2006 at 09:10:57PM +0100, Stephen Carter wrote: > I've got my user amanda who is a member of the disk group, and although > permissions on all amanda files seem fine, when I try to run > su amanda - c "/usr/sbin/amtape DailySet1 show" > > I get the error > amtape: could not get changer info: no slots available > > I can however run this successfully as root. > > My tape device is /dev/sg0 and the changer is /dev/sg1. Both have permissions > root:disk (along with everything else in /dev it appears) > > My amanda config files are in /etc/amanda/DailySet1 and amanda is the owner > of /etc/amanda and all files beneath that. > > I'm running SLES 10 and installed Amanda through YaST which is v2.4.5 > > I also uninstalled that and tried doing it directly from source, with exactly > the same problem... > > Any help would be great. > > Thanks! > > > Stephen Carter > Retrac Networking Limited > www: http://www.retnet.co.uk > Ph: +44 (0)7870 218 693 > Fax: +44 (0)870 7060 056 > CNA, CNE 6, CNS, CCNA, MCSE 2003 > > > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486- 1697 Wadsworth Center(f) 518 473- 6384 NYS Department of HealthHelp Desk 518 473- 0773
Re: can only run amanda tests as root
I'm getting closer and it's a SuSE specific problem. Using SuSE the devices in /dev have only +r rights for group. If I manually add +w for group access I can run amtape tests successfully, so maybe it's a problem with udev that is used to create the devices during boot. I will go to the SuSE forums and ask around there. Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 >>> "Stephen Carter" <[EMAIL PROTECTED]> 08/02/06 9:33 AM >>> I figured that part out, and running mtx - f /dev/sg0 inquiry then again for sg1 showed that my drive was on sg0 and the autoloader was on sg1. All the mtx and amtape commands work when being run as the root user, so I don't think this is a configuration file issue. I think it's more of a setup issue with users / perms but I just can't see it... Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 >>> Brian Cuttler <[EMAIL PROTECTED]> 08/01/06 9:16 PM >>> The robot/picker/whatever is a different device on most systems from the tape drive, I've seen it as a different device/SCSI ID and as the same SCSI ID/different LUN, depending on the implementation. You have to check the devices for the robot in this case. On Tue, Aug 01, 2006 at 09:10:57PM +0100, Stephen Carter wrote: > I've got my user amanda who is a member of the disk group, and although > permissions on all amanda files seem fine, when I try to run > su amanda - c "/usr/sbin/amtape DailySet1 show" > > I get the error > amtape: could not get changer info: no slots available > > I can however run this successfully as root. > > My tape device is /dev/sg0 and the changer is /dev/sg1. Both have permissions > root:disk (along with everything else in /dev it appears) > > My amanda config files are in /etc/amanda/DailySet1 and amanda is the owner > of /etc/amanda and all files beneath that. > > I'm running SLES 10 and installed Amanda through YaST which is v2.4.5 > > I also uninstalled that and tried doing it directly from source, with exactly > the same problem... > > Any help would be great. > > Thanks! > > > Stephen Carter > Retrac Networking Limited > www: http://www.retnet.co.uk > Ph: +44 (0)7870 218 693 > Fax: +44 (0)870 7060 056 > CNA, CNE 6, CNS, CCNA, MCSE 2003 > > > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486- 1697 Wadsworth Center(f) 518 473- 6384 NYS Department of HealthHelp Desk 518 473- 0773
Re: can only run amanda tests as root
I figured that part out, and running mtx -f /dev/sg0 inquiry then again for sg1 showed that my drive was on sg0 and the autoloader was on sg1. All the mtx and amtape commands work when being run as the root user, so I don't think this is a configuration file issue. I think it's more of a setup issue with users / perms but I just can't see it... Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 >>> Brian Cuttler <[EMAIL PROTECTED]> 08/01/06 9:16 PM >>> The robot/picker/whatever is a different device on most systems from the tape drive, I've seen it as a different device/SCSI ID and as the same SCSI ID/different LUN, depending on the implementation. You have to check the devices for the robot in this case. On Tue, Aug 01, 2006 at 09:10:57PM +0100, Stephen Carter wrote: > I've got my user amanda who is a member of the disk group, and although > permissions on all amanda files seem fine, when I try to run > su amanda - c "/usr/sbin/amtape DailySet1 show" > > I get the error > amtape: could not get changer info: no slots available > > I can however run this successfully as root. > > My tape device is /dev/sg0 and the changer is /dev/sg1. Both have permissions > root:disk (along with everything else in /dev it appears) > > My amanda config files are in /etc/amanda/DailySet1 and amanda is the owner > of /etc/amanda and all files beneath that. > > I'm running SLES 10 and installed Amanda through YaST which is v2.4.5 > > I also uninstalled that and tried doing it directly from source, with exactly > the same problem... > > Any help would be great. > > Thanks! > > > Stephen Carter > Retrac Networking Limited > www: http://www.retnet.co.uk > Ph: +44 (0)7870 218 693 > Fax: +44 (0)870 7060 056 > CNA, CNE 6, CNS, CCNA, MCSE 2003 > > > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486- 1697 Wadsworth Center(f) 518 473- 6384 NYS Department of HealthHelp Desk 518 473- 0773
