[Openvpn-devel] Openvpn for RH62 - eek!
James, Folks, I noticed a minor problem as my RH62 box started up: $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator expected That's two distinct, common errors: - $localization stuff that doesn't work on bash1 - an == in a [] in the script. These are both directly related to the fact that the standard bash on RH62 is bash1. We can fix compatibility in a few ways: - ignore the odd $localization $artefact and make the one change to the init script (as if we did perl -pi -e 's:==:=:' to is) in one place. OR - this patch: --- /etc/rc.d/init.d/openvpn~ Sun Apr 27 03:51:51 2003 +++ /etc/rc.d/init.d/openvpnThu May 1 12:07:50 2003 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash2 # # openvpn This shell script takes care of starting and stopping # openvpn. Super-trivial, but I'm wondering about any possible complications with either approach. As it is now, we do have a valid bug in that, on RH62, openVPN will not start. (I also noticed I can start it multiple times. This may be another problem - service openvpn start ; service openvpn start ; service openvpn start ; service openvpn start - because it should normally generate a minor gripe message) Anyway, whatever the consensus, I can submit a patch. - bish -- "Every well-bred petty crook knows -- the small concealable weapons always go to the far left of the place setting." -- Inara (Morena Baccarin), "Firefly" (unaired - into production AFTER fox crushed it)
Re: [Openvpn-devel] Openvpn for RH62 - eek!
How do most other initialization scripts handle the differences between bash 1 and 2? Do they just restrict themselves to the least common denominator (a)? Or do they try to explicitly instantiate bash2 (b)? -#!/bin/sh +#!/bin/bash2 (b) could be risky if there are distros where where /bin/bash2 is not present. I would lean towards (a) if trivial changes in the script can make it both bash1 and bash2 compliant. If that is not the case, and we think that we have a reliable, distro-independent method to instantiate bash2, then I would favor (b). What does the patch look like for (a)? James bishop said: > James, Folks, > > I noticed a minor problem as my RH62 box started up: > > > $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator expected > > That's two distinct, common errors: > - $localization stuff that doesn't work on bash1 > - an == in a [] in the script. > > These are both directly related to the fact that the standard bash on > RH62 is bash1. We can fix compatibility in a few ways: > - ignore the odd $localization $artefact and make the one change to > the init script (as if we did perl -pi -e 's:==:=:' to is) in one place. > > OR > - this patch: > > > --- /etc/rc.d/init.d/openvpn~ Sun Apr 27 03:51:51 2003 > > +++ /etc/rc.d/init.d/openvpnThu May 1 12:07:50 2003 > > @@ -1,4 +1,4 @@ > > -#!/bin/sh > > +#!/bin/bash2 > > # > > # openvpn This shell script takes care of starting and stopping > > # openvpn. > > Super-trivial, but I'm wondering about any possible complications with > either approach. As it is now, we do have a valid bug in that, on RH62, > openVPN will not start. > > (I also noticed I can start it multiple times. This may be another > problem - service openvpn start ; service openvpn start ; service > openvpn start ; service openvpn start - because it should normally > generate a minor gripe message) > > Anyway, whatever the consensus, I can submit a patch. > > - bish > > -- > "Every well-bred petty crook knows -- the small concealable > weapons always go to the far left of the place setting." > -- Inara (Morena Baccarin), "Firefly" > (unaired - into production AFTER fox crushed it) > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > --
Re: [Openvpn-devel] Openvpn for RH62 - eek!
IMHO init scripts must be POSIX (Bourne?) compliant. They should work in bash, ksh, whateversh, and don't depend on the administrator's will to install one or another. i.e. I'll say this: if [ $errors == 1 ]; then is better this way: if [ $errors -eq 1 ]; then And this: # can't detect error... #if [ $? != 0 ]; then # errors=1 #fi is better this way: # can't detect error... #if [ $? -ne 0 ]; then # errors=1 #fi Anyway, I'm attaching Debian's init.d script in case you want to take a look at it. Regards, Alberto On Fri, May 02, 2003 at 04:32:23AM -, James Yonan wrote: > How do most other initialization scripts handle the differences between bash 1 > and 2? Do they just restrict themselves to the least common denominator (a)? > > Or do they try to explicitly instantiate bash2 (b)? > > -#!/bin/sh > +#!/bin/bash2 > > (b) could be risky if there are distros where where /bin/bash2 is not present. > > I would lean towards (a) if trivial changes in the script can make it both > bash1 and bash2 compliant. If that is not the case, and we think that we have > a reliable, distro-independent method to instantiate bash2, then I would favor > (b). > > What does the patch look like for (a)? > > James > > bishop said: > > > James, Folks, > > > > I noticed a minor problem as my RH62 box started up: > > > > > $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator > > > expected > > > > That's two distinct, common errors: > > - $localization stuff that doesn't work on bash1 > > - an == in a [] in the script. > > -- Alberto Gonzalez Iniesta | They that give up essential liberty agi@(agi.as|debian.org)| to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Openvpn for RH62 - eek!
On Fri, May 02, 2003 at 11:25:46AM +0200, Alberto Gonzalez Iniesta wrote:
> Anyway, I'm attaching Debian's init.d script in case you want to take a
> look at it.
>
Doh! I ALWAYS forget to attach files! Sorry :)
--
Alberto Gonzalez Iniesta | They that give up essential liberty
agi@(agi.as|debian.org)| to obtain a little temporary safety
Encrypted mail preferred | deserve neither liberty nor safety.
Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
#!/bin/sh -e
#
# Original version by Robert Leslie
# , edited by iwj and cs
# Modified for openvpn by Alberto Gonzalez Iniesta
test $DEBIAN_SCRIPT_DEBUG && set -v -x
DAEMON=/usr/sbin/openvpn
CONFIG_DIR=/etc/openvpn
test -x $DAEMON || exit 0
test -d $CONFIG_DIR || exit 0
start_vpn () {
$DAEMON --daemon --writepid /var/run/openvpn.$NAME.pid \
--config $CONFIG_DIR/$NAME.conf --cd $CONFIG_DIR || echo -n "
FAILED->"
echo -n " $NAME"
}
stop_vpn () {
kill `cat $PIDFILE` || true
rm $PIDFILE
}
case "$1" in
start)
echo -n "Starting openvpn:"
for CONFIG in `cd $CONFIG_DIR; ls *.conf 2> /dev/null`; do
NAME=${CONFIG%%.conf}
start_vpn
done
echo "."
;;
stop)
echo -n "Stopping openvpn:"
for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
NAME=`echo $PIDFILE | cut -c18-`
NAME=${NAME%%.pid}
stop_vpn
echo -n " $NAME"
done
echo "."
;;
# We only 'reload' for running VPNs. New ones will only start with 'start' or
'restart'.
reload|force-reload)
echo -n "Reloading openvpn:"
for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
NAME=`echo $PIDFILE | cut -c18-`
NAME=${NAME%%.pid}
# If openvpn if running under a different user than root we'll need to restart
if egrep '^( |\t)*user' $CONFIG_DIR/$NAME.conf > /dev/null 2>&1 ; then
stop_vpn
sleep 1
start_vpn
echo -n "(restarted)"
else
kill -HUP `cat $PIDFILE` || true
#start-stop-daemon --stop --signal HUP --quiet --oknodo \
# --exec $DAEMON --pidfile $PIDFILE
echo -n " $NAME"
fi
done
echo "."
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "Usage: $0 {start|stop|reload|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
# vim:set ai et sts=2 sw=2 tw=0:
Re: [Openvpn-devel] Openvpn for RH62 - eek!
On Fri, 02 May 2003, James Yonan wrote: > How do most other initialization scripts handle the differences between bash 1 > and 2? Do they just restrict themselves to the least common denominator (a)? Yes. /bin/sh is standardized; Solaris for some strange reason ship b0rked year-old stuff though (they may need /usr/xpg4/bin/sh -- but that's a different matter). OTOH, init scripts don't need real processing work, so getting them to fly with the rotten Solaris /bin/sh is feasible and should be done. If it works there, it'll most likely work anywhere else as well :-) > Or do they try to explicitly instantiate bash2 (b)? > > -#!/bin/sh > +#!/bin/bash2 > (b) could be risky if there are distros where where /bin/bash2 is not present. It is indeed harmful, it will actually break SuSE and FreeBSD. I know systems that don't have bash at all, but just pdksh...
