Closed GoogleCodeExporter closed 9 years ago
--enable-static-modules was used in an effort to eliminate the need to set the
LD_LIBRARY_PATH variable when using pdsh 2.25. Unless LD_LIBRARY_PATH is set
pdsh cannot load genders.so, evidently because it is linked with
-nodefaultrpath.
Is there a way we can change/override -nodefaultrpath for the genders module so
it is linked with an rpath so we don't need to set LD_LIBRARY_PATH?
Original comment by bwir...@gmail.com
on 25 Apr 2011 at 3:01
Sorry about --enable-static-modules, static modules probably have not been
testing
in awhile. I'll work on getting that basically working again.
I'm not sure how to override -nodefaultrpath. It appears that libtool is setting
this, but I don't see a way to override it, see:
http://www.mail-archive.com/libtool-patches@gnu.org/msg01946.html
for what appears to be the original reason this is done on HP-UX.
Reading about the HP-UX linker, it seems that you can embed search paths
into binaries with the +b linker option. See
http://docs.hp.com/en/B2355-90968/linkertasks.htm#MOVINGLIBRARIES-B
maybe you could try adding
"-Wl,+b /path/to/libgenders"
to CFLAGS or just
"+b /path/to/libgenders"
to LDFLAGS?
Original comment by mark.gro...@gmail.com
on 25 Apr 2011 at 4:18
For the build with --enable-static-modules, can you verify that the attached
patch fixes the build time issue? There are some other fixes needed in the
testuite, but
since the testsuite doesn't work on hp-ux either...
Original comment by mark.gro...@gmail.com
on 25 Apr 2011 at 5:18
Attachments:
This issue was updated by revision r1323.
Move prototypes in mod.c so they are not ifdef'd out when building
with --enable-static-modules. This should fix the static module
build.
Original comment by mark.gro...@gmail.com
on 25 Apr 2011 at 10:38
This issue was updated by revision r1324.
Fixes for testsuite and --enable-static-modules
Original comment by mark.gro...@gmail.com
on 25 Apr 2011 at 10:38
I built svn rev 1325 with static modules and everything looks good except for
pdsh not having any embedded paths to load libraries from so it still needs to
have LD_LIBRARY_PATH set. I'm going to play with compiler/linker options to
try to fix that.
I attached the "make check" output - there are a few errors you may want to
check.
We really appreciate your fast response and patches to all of our issues! We
use pdsh about a million times/day and the genders support is going to be great
to use. Looking forward to replacing our old 2.7 soon.
Original comment by bwir...@gmail.com
on 26 Apr 2011 at 2:15
Original comment by bwir...@gmail.com
on 26 Apr 2011 at 2:15
Attachments:
I attached the make check output to issue 22, in which I'm tracking testsuite
failures on HP-UX. It looks like HP-UX doesn't have seq(1). Will have to
encode one in a shell function I guess -- or is it perhaps in another path?
Original comment by mark.gro...@gmail.com
on 26 Apr 2011 at 2:36
I also noticed you are not building the rcmd/exec module. This is going to
allow a lot of the tests to work, and is actually a very useful module to have
built (It allows you to run any command in parallel with pdsh, e.g. grep)
Original comment by mark.gro...@gmail.com
on 26 Apr 2011 at 2:40
Right - HP-UX does not appear to have a seq command and a rudimentary search
doesn't turn one up.
We use only ssh transport with pdsh - all other remote shells (e.g., remsh,
rexec, rlogin) are disabled on all our systems due to security requirements.
So we run any command we want in parallel on up to 300+ hosts using pdsh with
ssh.
wilma:/home/root/genders-1.17# pdsh -V
pdsh-2.25 (+static-modules+readline)
rcmd modules: ssh
misc modules: genders
pdsh 2.25+1325 is in production use now. Among other things we use pdsh in
scripts to manage user accounts across 300+ Linux and hpux systems. Here's a
pdsh command from one of our scripts:
<snip>
pdsh -f $FANOUT -w $HOSTS '
if (('$DEBUG')) ; then
set -x
fi
LOCALDATE=$(date -u +%Y%j)
if [[ $(uname) = Linux ]] ; then
grep -q "^'$USER':" /etc/shadow || exit 0
grep -q "^'$USER':!" /etc/shadow && LOCKS="ADMIN"
# convert seconds to days for linux password date
LDATE=$(('$DATE'/86400))
# update the password and date
/usr/sbin/usermod -p '\'$PWD\'' '$USER'
[[ '$SYSTEMDATE' = $LOCALDATE ]] \
&& /usr/bin/chage -d $LDATE '$USER'
# remove lock
/usr/bin/passwd -u '$USER' >/dev/null
# reset failed login count
DENY=$(grep -Eo "deny=[0-9]" '$SYSTEMAUTH' |awk -F= '\'{print \$NF}\'')
TALLY=$(/sbin/pam_tally --user '$USER' --reset |awk '\'{print \$NF}\'')
[[ ! -z $DENY ]] \
&& (($TALLY >= $DENY)) \
&& LOCKS="${LOCKS}${LOCKS:+, }MAXTRIES"
else
# format the lockout flags for display
lockout=$(/usr/lbin/getprpw -m lockout '$USER' 2>/dev/null)
[[ ($? > 0) ]] && exit 0
# NOTE: bash requires the parentheses in a test statement be escaped.
lockout=$(echo $lockout |cut -f2 -d=)
[[ $lockout = @\(1??????\) ]] && LOCKS="PWDEXPIRED"
[[ $lockout = @\(?1?????\) ]] && LOCKS="${LOCKS}${LOCKS:+, }INACTIVE"
[[ $lockout = @\(??1????\) ]] && LOCKS="${LOCKS}${LOCKS:+, }EXPIRED"
[[ $lockout = @\(???1???\) ]] && LOCKS="${LOCKS}${LOCKS:+, }MAXTRIES"
[[ $lockout = @\(????1??\) ]] && LOCKS="${LOCKS}${LOCKS:+, }NULLPWD"
[[ $lockout = @\(?????1?\) ]] && LOCKS="${LOCKS}${LOCKS:+, }ADMIN"
[[ $lockout = @\(??????1\) ]] && LOCKS="${LOCKS}${LOCKS:+, }PWDISA*"
# remove all locks
/usr/lbin/modprpw -k '$USER'
# ensure the password date field exists
[[ $(grep -c u_succhg '$UTCB') = 0 ]] \
&& { UTCBVAR=$(< '$UTCB')
echo "$UTCBVAR" \
|sed -e "5s/:/:u_succhg#0:/" \
>'$UTCB'
}
# update the password and (if the local and remote
# system dates match) date
[[ '$SYSTEMDATE' = $LOCALDATE ]] \
&& EDTDATE='\'-e "s/u_succhg#[^:]*:/u_succhg#$DATE:/"\''
UTCBVAR=$(< '$UTCB')
echo "$UTCBVAR" \
|sed $EDTDATE \
-e "s#u_pwd=[^:]*:#u_pwd='$PWD':#" \
>'$UTCB'
fi
LOCKS=${LOCKS:-NONE}
echo "'$USER' password updated, locks reset=$LOCKS"
'
</snip>
Original comment by bwir...@gmail.com
on 26 Apr 2011 at 7:36
Nice, were you able then to get around the LD_LIBRARY_PATH issue?
Original comment by mark.gro...@gmail.com
on 26 Apr 2011 at 7:38
Yes, using
LDFLAGS="-L/usr/local/lib/hpux32 -L/usr/lib/hpux32 \
+b/usr/lib/hpux32:/usr/local/lib/hpux32" \
fixed the LD_LIBRARY_PATH issue for pdsh.
But unfortunately that doesn't work for nodeattr in the genders package;
LD_LIBRARY_PATH still needs to be set to use it. I've recompiled it about 18
times today trying different options but it always gets linked with NO embedded
path. Of course we don't use nodeattr with pdsh but we are testing it for use
in some other things.
So, pdsh with the genders module is working great and I'll be modifying some of
our pdsh scripts to take advantage of genders. genders is just what we needed
and is even better that the proposed "include" enhancement to dshgroups that
Sean (my coworker) submitted last week.
Original comment by bwir...@gmail.com
on 26 Apr 2011 at 8:40
Original comment by mark.gro...@gmail.com
on 27 Apr 2011 at 6:15
Original issue reported on code.google.com by
bwir...@gmail.com
on 25 Apr 2011 at 2:24