script failed: could not execute external program

Bug #277447 reported by Ralf Hildebrandt on 2008-10-03
Affects Status Importance Assigned to Milestone
openvpn (Debian)
Fix Released
openvpn (Ubuntu)

Bug Description

I invoke openvpn with an up & down script, which used to work undter hardy, with intrepid I get:
Fri Oct 3 09:35:32 2008 OPTIONS IMPORT: timers and/or timeouts modified
Fri Oct 3 09:35:32 2008 OPTIONS IMPORT: --ifconfig/up options modified
Fri Oct 3 09:35:32 2008 OPTIONS IMPORT: route options modified
Fri Oct 3 09:35:32 2008 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Oct 3 09:35:32 2008 TUN/TAP device tun0 opened
Fri Oct 3 09:35:32 2008 TUN/TAP TX queue length set to 100
Fri Oct 3 09:35:32 2008 /sbin/ifconfig tun0 pointopoint mtu 1500
Fri Oct 3 09:35:32 2008 ./ up tun0 1500 1542 init
Fri Oct 3 09:35:32 2008 script failed: could not execute external program
Fri Oct 3 09:35:32 2008 Exiting

Upstream bug seems to be:

since the version in intrepid is
ii openvpn 2.1~rc9-3ubuntu2 virtual private network daemon

Related branches

Thierry Carrez (ttx) wrote :

Thanks for reporting this bug. Could you post an extract of your configuration that shows the exact value of the "up" and "down" parameters, as well as the value of the "script-security" parameter (if any) ?

Changed in openvpn:
status: New → Incomplete

openvpn is started like this:

cd `dirname $0`
/usr/sbin/openvpn --up "./ up" --down "./ down" --config client.conf

Using absolute pathnames didn't change anything.


dev tun
proto udp
remote 1194
resolv-retry infinite
pkcs12 client.p12
ns-cert-type server
verb 3
reneg-sec 0

setting the script-security parameter didn't have any effect, I tried values 0-3, no change, just like the upstream bugreport indicates.

Thierry Carrez (ttx) wrote :

This is a rc9 bug, fixed upstream in rc10. Commands with parameters don't get executed.

Changed in openvpn:
status: Incomplete → Confirmed
importance: Undecided → Medium
Thierry Carrez (ttx) wrote :

RC10 introduces lots of new options so it might not be suitable at that point in the release.
See for details.

> RC10 introduces lots of new options so it might not be suitable at that point in the release.

One might argue that including ANY RC version into a supposedly stable release is a bad move...
(if rc at all, why not go for the latest?)

Thierry Carrez (ttx) wrote :

Well, it's been 2 years since OpenVPN 2.1_rc1 so you should probably not consider them as "release candidates", but rather as "development releases". They are at rc12 today without any sign that a "real release" is near. It's been changing rapidly in the recent months because there was some invasive security fix in rc9 that resulted in a lot of breakdown (including this one). However I agree that merging with Debian's rc11-1 (which is functionally equivalent to rc12) is probably a good idea given the number of bugs fixed in the recent releases.

Changed in openvpn:
status: Unknown → Fix Released
Thierry Carrez (ttx) wrote :
Download full text (3.3 KiB)

Detailed Changelog from our rc9 to rc11-1 in Debian:

[regressionfix] Fixed --lladdr bug introduced in 2.1-rc9 where input validation code was incorrectly expecting the lladdr parameter to be an IP address when it is actually a MAC address (HoverHell).
[bugfix] Fixed a bug that can cause SSL/TLS negotiations in UDP mode to fail if UDP packets are dropped.
[feature] Added "--server-bridge" (without parameters) to enable DHCP proxy mode: Configure server mode for ethernet bridging using a DHCP-proxy, where clients talk to the OpenVPN server-side DHCP server to receive their IP address allocation and DNS server addresses.
[feature] Added "--route-gateway dhcp", to enable the extraction of the gateway address from a DHCP negotiation with the OpenVPN server-side LAN.
[feature] Warn when ethernet bridging that the IP address of the bridge adapter is probably not the same address that the LAN adapter was set to previously.
[feature] When running as a server, warn if the LAN network address is the all-popular 192.168.[0|1].x, since this condition commonly leads to subnet conflicts down the road.
[bugfix] Primarily on the client, check for subnet conflicts between the local LAN and the VPN subnet.
[buildfix] Minor fix to cryptoapi.c to not compile itself unless USE_CRYPTO and USE_SSL flags are enabled (Alon Bar-Lev).
[buildfix] Updated openvpn/ (used by "make check") to conform to new --script-security rules. Also adds retrying if the addresses are in use (Matthias Andree).
[buildfix] Fixed build issue with ./configure --disable-socks --disable-http.
[buildfix] Fixed separate compile errors in options.c and ntlm.c that occur on strict C compilers (such as old versions of gcc) that require that C variable declarations occur at the start of a {} block, not in the middle.
[bugfix] Workaround bug in OpenSSL 0.9.6b ASN1_STRING_to_UTF8, which the new implementation of extract_x509_field_ssl depends on.
[bugfix] LZO compression buffer overflow errors will now invalidate the packet rather than trigger a fatal assertion.
[buildfix] Fixed minor compile issue in ntlm.c (mid-block declaration).
[regressionfix] Added --allow-pull-fqdn option which allows client to pull DNS names from server (rather than only IP address) for --ifconfig, --route, and --route-gateway. OpenVPN versions 2.1_rc7 and earlier allowed DNS names for these options to be pulled and translated to IP addresses by default. Now --allow-pull-fqdn will be explicitly required on the client to enable DNS-name-to-IP-address translation of pulled options.
[regressionfix] 2.1_rc8 and earlier did implicit shell expansion on script arguments since all scripts were called by system(). The security hardening changes made to 2.1_rc9 no longer use system(), but rather use the safer execve or CreateProcess system calls. The security hardening also introduced a backward incompatibility with 2.1_rc8 and earlier in that script parameters were no longer shell-expanded
[rfc-conformancefix] Modified ip_or_dns_addr_safe, which validates pulled DNS names to more closely conform to RFC 3696
[regressionfix] Fixed bug in intra-session TLS key rollover that was introduced with deferred authentication featur...


Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openvpn - 2.1~rc11-1ubuntu1

openvpn (2.1~rc11-1ubuntu1) intrepid; urgency=low

  * Merge with Debian (LP: #279655), remaining diffs:
    - debian/openvpn.init.d: Added 'status' action to init script, show
      per-VPN result messages and add "--script-security 2" by default for
      backwards compatibility
    - debian/control: Added lsb-base>=3.2-14 depend to allow status_of_proc()
  * Fixes regression when calling commands with arguments (LP: #277447)

 -- Thierry Carrez <email address hidden> Tue, 07 Oct 2008 16:30:44 +0200

Changed in openvpn:
status: Confirmed → Fix Released
Angelo Pantano (ghilteras) wrote :

am I the only one still afflicted by this bug?

I have a box with karmic:

Setting up openvpn (2.1~rc19-1ubuntu2) ...
invoke-rc.d: initscript openvpn, action "cond-restart" failed.
invoke-rc.d: initscript openvpn, action "restart" failed.
dpkg: error processing openvpn (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

uname -a:
Linux XXXXX 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i586 GNU/Linux

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.