#754 /opt/pvm3 directory ownership on image
When PVM rpm is installed in the image, the ownership
is wrong. This may be caused by the fact that
systeminstaller strips out the %post script and execute
it "out of context" (without certain variables set).
This is what my /opt directory looks like on a
resulting node:
[root@rhel4u2-x86 opt]# ls -l
total 44
drwxr-xr-x 4 root root 4096 Nov 24 21:08 c3-4
drwxr-xr-x 6 root root 4096 Nov 24 21:07 env-switcher
drwxr-xr-x 8 root root 4096 Nov 24 21:08 lam-7.0.6
drwxr-xr-x 3 root root 4096 Nov 24 21:08
lam-switcher-modulefile-7.0.6
drwxr-xr-x 6 root root 4096 Nov 24 21:07 modules
drwxr-xr-x 12 root root 4096 Nov 24 21:07
mpich-ch_p4-gcc-1.2.7
drwxr-xr-x 23 pegasus 101 4096 Nov 24 21:07 pvm3
drwxr-xr-x 16 root root 4096 Nov 24 21:07 sge
It should be owned by pvm.pvm.
Tested on RHEL4u2 x86.
Discussion
Logged In: YES
user_id=288102
Ok, it may be that the RPM's useradd is not being fired,
since it happens in the %post section, when installed in the
chroot'd env.
However, it appears that the permissions are correct (from
what I can tell)
UID = pegasus --> no clue but possibly uid=100
GID = 101 --> same as what I have on my system.
But I think the catch is that 'pvm' is
(1) installed on the server, then
(2) this adds user 'pvm' to the server, ie. /etc/passwd
(3) then when the image is built, the server's /etc/passwd
is copied over, thus effectively creating the user
I checked on my system and the md5sum's are identical
between my image's /etc/passwd and my server's (host)
/etc/passwd.
Questions:
1) What's the UID of user 'pegasus'?
2) Is PVM installed on the server (image host system)?
3) Does user 'pvm' appear in /etc/passwd on server?
4) Does user 'pvm' appear in /etc/passwd in image?
(probaly not)
So, I don't think this is a mod to the RPM or necessarily a
SIS change...probably just an issue we've never discovered
b/c we create the PVM user and copy that down to the image
so it doesn't matter if the RPM's %post section ran. Sort
of evil/bad but we'll confirm this is indeed the case before
we got any further.
Thanks,
--tjn
Logged In: YES
user_id=288102
I tested this again using the following settings to try to
reproduce the problem:
Test#1:
- FC4/x86
- oscar-4.2.1b2r3996 (build/install directly from SVN)
- pvm-3.4.5+4-1
- systemimager 3.5.3-3oscar
This worked just fine?
Test#2:
- FC4/x86
- oscar-4.2.1b2r3996 (build/install directly from SVN)
- pvm-3.4.5+4-2 (rebuild by hand on FC2/x86 system)
- systemimager 3.5.3-3oscar
- Used PackageInUn to remove old pvm-3.4.5+4-1, and
replace with pvm-3.4.5+4-2.
This worked too, but the PackageInUn doesn't use exactly the
same method to install as SIS does, so I'm going to retest.
Other than that, it appears the SIS version was slightly
different so that could be another
variable...hopefully/probably not but adding to notes.
NOTE: I did realized that the PVM rpms use the '-r' option
to useradd(8) which appers to be a RedHat specific
option...who knew? :)
Excerpt from useradd(8) on FC4 system:
(notice that last sentence, DOH! :)
-r This flag is used to create a system
account. That is, a user with a UID lower
than the value of UID_MIN defined in
/etc/login.defs and whose password does not
expire. Note that useradd will not create a
home directory for such an user, regardless
of the default setting in /etc/login.defs.
You have to specify -m option if you want a
home directory for a system account to be
created. This is an option added by Red Hat.
Logged In: YES
user_id=288102
# Further tests on FC4 with same version of oscar,
# using pvm-3.4.5+4-2 (rebuilt on FC2/x86).
I just tested again and it appears that the %post section
for PVM fired during the SIS install (build image).
I checked the images/oscarimage/opt/passwd file as the RPMS
were being installed and saw that after pvm was installed,
there was an entry for user 'pvm' in the file.
pvm:!!💯101::/opt/pvm3:/bin/bash
And the dir has proper ownership
root# ls -ld oscarimage/opt/pvm3/
drwxr-xr-x 23 pvm pvm 4096 Nov 29 16:26 oscarimage/opt/pvm3/
Note, somewhere at the end of the build image phase, we copy
over the server's /etc/passwd to the new image.
So I'm not sure if this is an error or problem with newer
SIS version or RHEL4u2. Bernard said he'll test again
tonight and I'll see if he can reproduce the problem with a
4.2.1beta tarball.
Logged In: YES
user_id=879102
I tested both 4.2.1 and 5.0 nightly tarballs and both have
issues on RHEL4u2 x86.
(Note 5.0 nightly has systemimager 3.5.3-3oscar and not
3.5.4 which I have in my local repository)
On 5.0, I got:
drwxr-xr-x 23 pegasus 101 4096 Nov 29 16:07 pvm3
On 4.2.1, I got:
drwxr-xr-x 23 pegasus pvm 4096 Nov 29 17:37 pvm3
Can you please test on a similar system (eg. CentOS)?
I am starting to think that the tog-pegasus RPM is the
culprit (CentOS provides this as well), here's the %post
script of tog-pegasus:
postinstall scriptlet (using /bin/sh):
if [ $1 -eq 1 ]; then
echo `date` >/var/log/Pegasus/install.log 2>&1
/sbin/ldconfig
# By default, ONLY the "pegasus" user will be allowed to
connect to cimserver
/usr/sbin/groupadd pegasus >/dev/null 2>&1 || :;
/usr/sbin/useradd -c "tog-pegasus OpenPegasus WBEM/CIM
services" -g pegasus \
-s /sbin/nologin -r -d /var/lib/Pegasus pegasus
>/dev/null 2>&1 || :;
Logged In: YES
user_id=879102
Okay I found the problem. Here's the scenario:
- headnode has tog-pegasus and pvm RPMs installed
- compute nodes have pvm RPM installed, the uid and gid of
the pvm user/group on the compute nodes are _different_ from
the headnode (because this not hardcoded in the useradd
command and the uid.gid created for pvm user / pvm group
depends on the id's available on the system at that time)
- headnode's /etc/passwd gets pushed to compute nodes
- compute nodes' directory ownership gets skewed (ownership
is by uid.gid, but not the "name")
I think I have unravelled a bigger problem within OSCAR.
The fix is either:
1) Docfix this, have user un-install tog-pegasus before
image creation (on systems which have this)
2) Add code to uninstall tog-pegasus
3) Figure out a "better" solution
I think there needs to be some fundamental change within
OSCAR to fix the underlying problem, as this is not just a
problem with pvm - it's a problem with EVERY package which
creates user and assign ownership to directories.
Logged In: YES
user_id=879102
Does the pvm user need to have a shell?
Logged In: YES
user_id=879102
Discussed on IRC today (Thomas, John and Bernard) that we
will docfix this for 4.2.1 - moving this bug to 5.0.
Logged In: YES
user_id=288102
So, I don't recall how we decided to fix this for 5.0. :)
This isn't a PVM specific issue, but should indeed be fixed.
Logged In: YES
user_id=288102
This is not really a PVM bug. We agreed to fix this issue in
a more accurately named bug.