Bug 213898

What permissions did the file have before the update? 
 
I have confirmed that .amandahosts has a mode of 0600 on a new fc6 
installation, so any bug here is likely to be in rpm.  Was the .amandahosts 
file unchanged from the fc5 installation default? 

(In reply to comment #1)
> What permissions did the file have before the update? 
>  
> I have confirmed that .amandahosts has a mode of 0600 on a new fc6 
> installation, so any bug here is likely to be in rpm.  Was the .amandahosts 
> file unchanged from the fc5 installation default? 

600.

I had edited the file for access control per the amanda documentation, but never
altered the permissions manually.

Are you *sure* it was 0600?  In my change log I see 
* Fri Apr 7 2006 Jay Fenlason <fenlason> 2.5.0-2 
... 
- Change the mode of ~amanda/.amandahosts to 600, since 2.5.0 requires 
  it. 
and the most recent Amanda for FC-5 is 
* Fri Feb 10 2006 Jesse Keating <jkeating> - 2.4.5p1-3.2     
- bump again for double-long bug on ppc(64) 
which is before 2.5.0.  Before 2.5.0 the default mode on .amandahosts was 660, 
owned by amanda, group disk. 

Yes.  It was the default of 660 for the 2.4.* version, which the 2.5 complained
about.

(In reply to comment #3)
> Are you *sure* it was 0600?  In my change log I see 
> * Fri Apr 7 2006 Jay Fenlason <fenlason> 2.5.0-2 
> ... 
> - Change the mode of ~amanda/.amandahosts to 600, since 2.5.0 requires 
>   it. 
> and the most recent Amanda for FC-5 is 
> * Fri Feb 10 2006 Jesse Keating <jkeating> - 2.4.5p1-3.2     
> - bump again for double-long bug on ppc(64) 
> which is before 2.5.0.  Before 2.5.0 the default mode on .amandahosts was 660, 
> owned by amanda, group disk. 

Ok, so the real bug is "When upgrading a rpm, when processing a 
%config(noreplace) file that the user has modified, rpm doesn't change the 
mode of the file when the old rpm specified one mode and the new rpm specifies 
a different one"?  If that's an accurate assessment, I'll reassign this bug to 
rpm. 

I've not tested this hypothesis on other rpms, but it sounds accurate to me.  I
wouldn't think it would come up that often, but it's a good thing for rpm to
look out for.   Should make upgrades, either via yum or CD, more robust.  Which
is always good. :)

What does "rpm -V amanda" say about the package?

NEEDINFO

Here's at least one flaw in current FC[67] amanda:

Running Transaction
warning: user amanda does not exist - using root
  Installing: amanda                                                 [1/1]warning: user amanda does not exist - using 
root
  Installing: amanda                       #######################   [1/1]warning: user amanda does not 
exist - using root
  Installing: amanda                       ########################  [1/1]warning: user amanda does not 
exist - using root
  Installing: amanda                       ########################  [1/1]warning: user amanda does not 
exist - using root
  Installing: amanda                       ########################  [1/1]warning: user amanda does not 
exist - using root
  Installing: amanda                       ######################### [1/1] 

Installed: amanda.i386 0:2.5.0p2-4


i.e. any user/group within a package must be either added or pre-existing. The test is whether
the user or group can be looked up through getpwnam(3)/getgrnam(3).

With final result:
[root@wellfleet amanda]# rpm -qf .amandahosts 
amanda-2.5.0p2-4.i386.rpm
[root@wellfleet amanda]# ls -al
total 16
drwxr-xr-x  2 root disk 4096 Nov  6 14:30 .
drwxr-xr-x 40 root root 4096 Nov  6 14:30 ..
-rw-------  1 root disk   48 Oct  2 15:58 .amandahosts
[root@wellfleet amanda]# 

(In reply to comment #7)
> What does "rpm -V amanda" say about the package?
> 
> NEEDINFO

S.5....T c /etc/amandates
S.?....T c /var/lib/amanda/.amandahosts

FYI, this sequence "fixes"

[root@wellfleet amanda]# rpm --setperms amanda
[root@wellfleet amanda]# pwd
/var/lib/amanda
[root@wellfleet amanda]# ls -al .amandahosts 
-rw------- 1 root disk 48 Oct  2 15:58 .amandahosts
[root@wellfleet amanda]# rpm --setugids amanda
[root@wellfleet amanda]# ls -al .amandahosts 
-rw------- 1 amanda disk 48 Oct  2 15:58 .amandahosts
[root@wellfleet amanda]# rpm -qlv amanda | grep amandahosts
-rw-------    1 amanda  disk               48 Oct  2 15:58 /var/lib/amanda/.amandahosts
[root@wellfleet amanda]# rpm -V amanda
[root@wellfleet amanda]# 

FWIW, I corrected manually with chmod.

So would this be considered a bug in amanda.*.rpm's spec, or rpm's handling of a
%config(noreplace) directive in amanda.*.rpm's spec?  It would seem that at
least the proper perm info exists in the rpm, since rpm may be used to correct it.

(In reply to comment #11)
> FYI, this sequence "fixes"
> 
> [root@wellfleet amanda]# rpm --setperms amanda
> [root@wellfleet amanda]# pwd
> /var/lib/amanda
> [root@wellfleet amanda]# ls -al .amandahosts 
> -rw------- 1 root disk 48 Oct  2 15:58 .amandahosts
> [root@wellfleet amanda]# rpm --setugids amanda
> [root@wellfleet amanda]# ls -al .amandahosts 
> -rw------- 1 amanda disk 48 Oct  2 15:58 .amandahosts
> [root@wellfleet amanda]# rpm -qlv amanda | grep amandahosts
> -rw-------    1 amanda  disk               48 Oct  2 15:58
/var/lib/amanda/.amandahosts
> [root@wellfleet amanda]# rpm -V amanda
> [root@wellfleet amanda]# 

This bug should be reassigned to amanda to fix the %pre script that tries (unsuccessfully)
to add the "amanda" user (verified by snipping the line from "rpm -q --scripts amanda",
running in a shell, and verifying through "grep amanda /etc/passwd" that the command
does not operate as expected).

REASSIGN to amanda

Here's the problem:

[root@wellfleet ~]# useradd -M -n -g disk -o -r -d /var/lib/amanda -s /bin/bash         -c "Amanda user" 
-u 33 amanda 
useradd: invalid numeric argument 'disk'

useradd does not comply with its doco.

Doesn't seem to be an rpm problem, reassigning to amanda.

I cannot reproduce problem from Comment #8 nor Comment #14, and original problem
seems to have nothing to do with Amanda (user rights in .spec are correct). Can
I consider the bug solved and close it?

Since further upgrades have not reintroduced the problem, I'd say that's fine
with me.

Okay, thank you.

I tested the upgrade once more and it works like this (in F7):

1. before:
-rw-rw----  1 amanda disk   88 2007-07-12 16:40 .amandahosts

2. when upgrading, rpm warns that .amandahosts is created as .amandahosts.rpmnew

3. after:
-rw-rw----  1 amanda disk   88 2007-07-12 16:40 .amandahosts
-rw-------  1 amanda disk   48 2007-07-12 16:25 .amandahosts.rpmnew

User must manualy set rights for .amandahosts or owerwrite it with
.amandahosts.rpmnew. It's probably expected behaviour, but that should be
decided by rpm maintainer --> transfering to rpm.

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

Well, rpm is told not to mess with the config file so it doesn't, so yes it's
expected behavior, but there's just more than a couple of different issues
tangled here.

Anyway, since everybody seems to agree the it's no longer an issue lets close
this ping-pong bug... WORKFORME in the sense that rpm is doing what's expected here.