Ok, found the issue. The 4.0 script in the system vm that adds DHCP
entries parses args like this:
# edithosts.sh -- edit the dhcphosts file on the routing domain
# $mac : the mac address
# $ip : the associated ip address
# $host : the hostname
# $4 : default router
# $5 : nameserver on default nic
# $6 : comma separated static routes
mac=$1
ip=$2
host=$3
dflt=$4
dns=$5
routes=$6
And the script in 4.1 parses args like this:
while getopts 'm:4:h:d:n:s:6:u:N' OPTION
do
case $OPTION in
m) mac="$OPTARG"
;;
4) ipv4="$OPTARG"
;;
6) ipv6="$OPTARG"
;;
u) duid="$OPTARG"
;;
h) host="$OPTARG"
;;
d) dflt="$OPTARG"
;;
n) dns="$OPTARG"
;;
s) routes="$OPTARG"
;;
N) nondefault=1
;;
?) usage
exit 2
;;
esac
done
So in 4.0 it's looking at flags as though they're arguments, which is
why we get garbage in the dhcp file. In the router log we see the
results (first line is a working one, second line isn't)
Mar 28 04:41:54 r-5-VM cloud: edithosts: update 02:00:2b:58:00:01
10.1.1.6 ff9b5970-d095-4602-aa7d-671e3a7535da to hosts
Mar 28 04:48:01 r-5-VM cloud: edithosts: update -4 10.1.1.245 -m to hosts
I don't see an easy way around this. We could perhaps detect if the
router has upgraded its scripts, and then adjust how we call
edithosts.sh accordingly. Anyone want to take that on? Is this the
only issue? I'm assuming people will need to reboot their system vms
anyway for other features.
On Wed, Mar 27, 2013 at 9:27 PM, Marcus Sorensen <shadow...@gmail.com> wrote:
> We can look into it, my guess is that an existing script now has new and/or
> different parameters. Perhaps it could be adjusted to be backward compatible
> so people can reboot at their leisure. All just guesswork.
>
> On Mar 27, 2013 9:21 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
>>
>> Hard to say. Sometimes functionality/implementation changes even though
>> the feature is the same.
>>
>> On Mar 27, 2013 9:20 PM, "David Nalley" <da...@gnsa.us> wrote:
>>>
>>> On Wed, Mar 27, 2013 at 11:13 PM, Marcus Sorensen <shadow...@gmail.com>
>>> wrote:
>>> > Just to clarify a step further, this should have been the case with 3.x
>>> > to
>>> > 4.0 as well. We had all of these new vpc scripts that added brand new
>>> > functionality that needed to go on the virtual routers. The system VM
>>> > template stayed the same, even though new scripts were added via
>>> > systemvm.iso.
>>>
>>>
>>> That said, why would new functionality make existing functionality
>>> stop working in a system VM.
>>>
>>> --David
