Re: amandas group membership in FC6?
On Sat, Nov 25, 2006 at 11:22:38PM -0500, Gene Heskett wrote: See what that number maps to in /etc/group. I'm betting it goes to an 'amanda' group and not the 'disk' group. There was not, and still is not, a group named amanda, just the amanda entry in the disk line. Is there any chance you're using ldap/nis/winbind/etc for groups in nsswitch.conf? The amanda group must be coming from somewhere. If it's not listed in /etc/group, I'm wondering if there's another source of groups on your system. -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Re: amandas group membership in FC6?
On Sunday 26 November 2006 10:09, Ross Vandegrift wrote: On Sat, Nov 25, 2006 at 11:22:38PM -0500, Gene Heskett wrote: See what that number maps to in /etc/group. I'm betting it goes to an 'amanda' group and not the 'disk' group. There was not, and still is not, a group named amanda, just the amanda entry in the disk line. Is there any chance you're using ldap/nis/winbind/etc for groups in nsswitch.conf? The amanda group must be coming from somewhere. If it's not listed in /etc/group, I'm wondering if there's another source of groups on your system. Pretty close to zero on the above. [EMAIL PROTECTED] etc]# grep -R amanda * aliases:amanda: root amandates:/amanda 0 1155793225 amandates:/amanda 1 1155879121 amandates:/amanda 2 1155966111 amandates:/amanda 3 1156050701 amandates:/amanda 4 1144996628 group:disk:x:6:amanda,root group:amanda:x:501: group-:disk:x:6:root,amanda group-:amanda:x:501: group.bak:disk:x:6:root,amanda group.bak:amanda:x:501: gshadow:disk:!::amanda,root gshadow:amanda:!:: gshadow-:amanda:!:: gshadow.bak:disk:!::root,amanda gshadow.bak:amanda:!:: kde/kdm/kdmrc:HiddenUsers=adm,alias,amanda,apache,bin,bind,daemon,exim,falken,ftp,games,gdm,gopher,halt,httpd,ident,ingres,kmem,lp,mail,mailnull,man,mta,mysql,named,news,nfsnobody,nobody,nscd,ntp,operator,pcap,pop,postfix,postgres,qmaild,qmaill,qmailp,qmailq,qmailr,qmails,radvd,reboot,rpc,rpcuser,rpm,sendmail,shutdown,squid,sympa,sync,tty,uucp,xfs,xten mtab:/dev/hdd3 /amandatapes ext3 rw 0 0 passwd:amanda:x:501:6::/home/amanda:/bin/bash passwd-:amanda:x:501:501::/home/amanda:/bin/bash services:amanda 10080/tcp # amanda backup services services:amanda 10080/udp # amanda backup services services:kamanda10081/tcp # amanda backup services (Kerberos) services:kamanda10081/udp # amanda backup services (Kerberos) services:amandaidx 10082/tcp # amanda backup services services:amidxtape 10083/tcp # amanda backup services shadow:amanda::13477:0:0 shadow-:amanda:!!:13461:0:9:7::: shadow.bak:amanda:!!:13461:0:9:7::: X11/xdm/kdmrc:HiddenUsers=adm,alias,amanda,apache,bin,bind,daemon,exim,falken,ftp,games,gdm,gopher,halt,httpd,ident,ingres,kmem,lp,mail,mailnull,man,mta,mysql,named,news,nfsnobody,nobody,nscd,ntp,operator,pcap,pop,postfix,postgres,qmaild,qmaill,qmailp,qmailq,qmailr,qmails,radvd,reboot,rpc,rpcuser,rpm,sendmail,shutdown,squid,sympa,sync,tty,uucp,xfs,xten xinetd.d/amanda:service amanda xinetd.d/amanda:user= amanda xinetd.d/amanda:server = /usr/local/libexec/amandad xinetd.d/amanda:service amandaidx xinetd.d/amanda:user= amanda xinetd.d/amanda:user= amanda [EMAIL PROTECTED] etc]# === I removed the obvious errors and several kilobytes of selinux related stuff from the above as its set permissive. I expect some of the above, like the group entries for a group 501, could just as well be deleted. But are they a factor? I don't know. I will get rid of the group 501 entries though, just to make me feel better. FWIW, amanda ran just fine this morning. Thanks Ross. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 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: amandas group membership in FC6?
Gene Heskett wrote: Greetings; Despite the fact that the user 'amanda' is a member of the group 'disk', all compilations and new files generated by the user amanda seem to be owned by amanda:amanda instead of the expected amanda:disk. The end result is that many of my backup operations are failing because the amanda utility doesn't have perms to delete or write to files actually owned by amanda:disk. I just went thru all the directory trees amanda needs to access and chowned everything back the way its supposed to be, but then I built the 20061124 tarball just now, and everything is still owned by amanda:amanda. From my /etc/group file: disk:x:6:root,amanda So I blew it away, called up KUsr and verified that amanda was indeed a member of the group disk. Even deleted the user and re-added it and made sure this new copy of amanda was a member of the group disk. Then as amanda, I unpacked it again and rebuilt it, but I still have the same problem. Because none of the files are owned by amanda:disk, the end result is several megs of dead, can't do a thing code that I'd just as well not bother with the 'make install'. Anything that amanda has touched over the last 4 days since I started running it again has been converted to being owned by amanda:amanda, and if the file existed, and was to be deleted as part of the housekeeping, was not because the old file was owned by amanda:disk. So my backups are being slowly trashed because the indice files are not updatable. Whats the deal with FC6 and its owner:group handling? Am I setting up the user wrong or what? Perhaps something changed the amanda user's primary group in /etc/passwd? When new files are created, the user/group set are the ones in passwd, and /etc/group is only consulted by the system if the user is not the owner of the directory, then it checks if it is in the same group (assuming you have group write perms). Another possibility is that you are forcing the group amanda runs as in xinetd to be 'amanda' and not 'disk'. Frank -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: amandas group membership in FC6?
On Saturday 25 November 2006 20:42, Frank Smith wrote:
Gene Heskett wrote:
Greetings;
Despite the fact that the user 'amanda' is a member of the group
'disk', all compilations and new files generated by the user amanda
seem to be owned by amanda:amanda instead of the expected amanda:disk.
The end result is that many of my backup operations are failing
because the amanda utility doesn't have perms to delete or write to
files actually owned by amanda:disk.
I just went thru all the directory trees amanda needs to access and
chowned everything back the way its supposed to be, but then I built
the 20061124 tarball just now, and everything is still owned by
amanda:amanda.
From my /etc/group file:
disk:x:6:root,amanda
So I blew it away, called up KUsr and verified that amanda was indeed
a member of the group disk. Even deleted the user and re-added it and
made sure this new copy of amanda was a member of the group disk.
Then as amanda, I unpacked it again and rebuilt it, but I still have
the same problem. Because none of the files are owned by amanda:disk,
the end result is several megs of dead, can't do a thing code that I'd
just as well not bother with the 'make install'.
Anything that amanda has touched over the last 4 days since I started
running it again has been converted to being owned by amanda:amanda,
and if the file existed, and was to be deleted as part of the
housekeeping, was not because the old file was owned by amanda:disk.
So my backups are being slowly trashed because the indice files are
not updatable.
Whats the deal with FC6 and its owner:group handling? Am I setting up
the user wrong or what?
Perhaps something changed the amanda user's primary group in
/etc/passwd? When new files are created, the user/group set are
the ones in passwd, and /etc/group is only consulted by the system
if the user is not the owner of the directory, then it checks if it
is in the same group (assuming you have group write perms).
Another possibility is that you are forcing the group amanda runs as
in xinetd to be 'amanda' and not 'disk'.
I hadn't thought of that, but the amanda file in the xinetd.d dir is the
same one I used for FC2:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons such it needs
service amanda
{
only_from = coyote.coyote.den # gene.coyote.den
disable = no
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}
service amandaidx
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
According to the amanda coders, this is correct usage. Is it not now?
Thanks Frank.
--
Cheers, Gene
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
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: amandas group membership in FC6?
Gene Heskett wrote:
On Saturday 25 November 2006 20:42, Frank Smith wrote:
Gene Heskett wrote:
Greetings;
Despite the fact that the user 'amanda' is a member of the group
'disk', all compilations and new files generated by the user amanda
seem to be owned by amanda:amanda instead of the expected amanda:disk.
The end result is that many of my backup operations are failing
because the amanda utility doesn't have perms to delete or write to
files actually owned by amanda:disk.
I just went thru all the directory trees amanda needs to access and
chowned everything back the way its supposed to be, but then I built
the 20061124 tarball just now, and everything is still owned by
amanda:amanda.
From my /etc/group file:
disk:x:6:root,amanda
So I blew it away, called up KUsr and verified that amanda was indeed
a member of the group disk. Even deleted the user and re-added it and
made sure this new copy of amanda was a member of the group disk.
Then as amanda, I unpacked it again and rebuilt it, but I still have
the same problem. Because none of the files are owned by amanda:disk,
the end result is several megs of dead, can't do a thing code that I'd
just as well not bother with the 'make install'.
Anything that amanda has touched over the last 4 days since I started
running it again has been converted to being owned by amanda:amanda,
and if the file existed, and was to be deleted as part of the
housekeeping, was not because the old file was owned by amanda:disk.
So my backups are being slowly trashed because the indice files are
not updatable.
Whats the deal with FC6 and its owner:group handling? Am I setting up
the user wrong or what?
Perhaps something changed the amanda user's primary group in
/etc/passwd? When new files are created, the user/group set are
the ones in passwd, and /etc/group is only consulted by the system
if the user is not the owner of the directory, then it checks if it
is in the same group (assuming you have group write perms).
So what group does amanda have in /etc/passwd (the number in the fourth
field)? See what that number maps to in /etc/group. I'm betting it
goes to an 'amanda' group and not the 'disk' group. It's also possible
that you have two amanda lines in your passwd file, or two groups in
/etc/group that map to the same number (or the same group name in twice
with two different numbers). In those cases the first match is what
the system uses, but it can certainly be confusing to debug if you
don't notice the other one.
Your system is finding an amanda group for the amanda user somewhere,
it's just a mater of finding out where it is getting it from. I would
suggest looking into whether you might have compiled it in, but I know
you always use your same build script, so I'll just mention it as a
possibility for future readers of the archives.
Another possibility is that you are forcing the group amanda runs as
in xinetd to be 'amanda' and not 'disk'.
I hadn't thought of that, but the amanda file in the xinetd.d dir is the
same one I used for FC2:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons such it needs
service amanda
{
only_from = coyote.coyote.den # gene.coyote.den
disable = no
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}
service amandaidx
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
According to the amanda coders, this is correct usage. Is it not now?
That looks correct to me, so I'd look more into the passwd/group
files mentioned above.
Frank
--
Frank Smith [EMAIL PROTECTED]
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
Re: amandas group membership in FC6?
On Saturday 25 November 2006 22:29, Frank Smith wrote:
Gene Heskett wrote:
On Saturday 25 November 2006 20:42, Frank Smith wrote:
Gene Heskett wrote:
Greetings;
Despite the fact that the user 'amanda' is a member of the group
'disk', all compilations and new files generated by the user amanda
seem to be owned by amanda:amanda instead of the expected
amanda:disk.
The end result is that many of my backup operations are failing
because the amanda utility doesn't have perms to delete or write to
files actually owned by amanda:disk.
I just went thru all the directory trees amanda needs to access and
chowned everything back the way its supposed to be, but then I built
the 20061124 tarball just now, and everything is still owned by
amanda:amanda.
From my /etc/group file:
disk:x:6:root,amanda
So I blew it away, called up KUsr and verified that amanda was
indeed a member of the group disk. Even deleted the user and
re-added it and made sure this new copy of amanda was a member of
the group disk.
Then as amanda, I unpacked it again and rebuilt it, but I still
have the same problem. Because none of the files are owned by
amanda:disk, the end result is several megs of dead, can't do a
thing code that I'd just as well not bother with the 'make install'.
Anything that amanda has touched over the last 4 days since I
started running it again has been converted to being owned by
amanda:amanda, and if the file existed, and was to be deleted as
part of the housekeeping, was not because the old file was owned by
amanda:disk. So my backups are being slowly trashed because the
indice files are not updatable.
Whats the deal with FC6 and its owner:group handling? Am I setting
up the user wrong or what?
Perhaps something changed the amanda user's primary group in
/etc/passwd? When new files are created, the user/group set are
the ones in passwd, and /etc/group is only consulted by the system
if the user is not the owner of the directory, then it checks if it
is in the same group (assuming you have group write perms).
So what group does amanda have in /etc/passwd (the number in the fourth
field)?
It was originally the same as amanda, 501::501 but I've edited that to
501::6 now. I've also SGID'd the amanda home dir. It ran alright this
morning I believe. But the real answer will be when Jean-Louis releases
the next snapshot.
See what that number maps to in /etc/group. I'm betting it
goes to an 'amanda' group and not the 'disk' group.
There was not, and still is not, a group named amanda, just the amanda
entry in the disk line.
It's also possible
that you have two amanda lines in your passwd file, or two groups in
/etc/group that map to the same number (or the same group name in twice
with two different numbers). In those cases the first match is what
the system uses, but it can certainly be confusing to debug if you
don't notice the other one.
Nope, just one.
Your system is finding an amanda group for the amanda user somewhere,
it's just a mater of finding out where it is getting it from. I would
suggest looking into whether you might have compiled it in, but I know
you always use your same build script, so I'll just mention it as a
possibility for future readers of the archives.
Another possibility is that you are forcing the group amanda runs as
in xinetd to be 'amanda' and not 'disk'.
I hadn't thought of that, but the amanda file in the xinetd.d dir is
the same one I used for FC2:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons such it needs
service amanda
{
only_from = coyote.coyote.den # gene.coyote.den
disable = no
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}
service amandaidx
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
According to the amanda coders, this is correct usage. Is it not now?
That looks correct to me, so I'd look more into the passwd/group
files mentioned above.
Frank
Thanks Frank. We'll see if its fixed in due time I guess.
--
Cheers, Gene
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Yahoo.com and
