[Ovirt-devel] [PATCH node] The node now passes in the mac address and iface names during identify.

[Daniel P. Berrange]

On Tue, Sep 23, 2008 at 01:18:30PM +0100, Daniel P. Berrange wrote:
> On Fri, Sep 19, 2008 at 04:35:37PM -0400, Darryl L. Pierce wrote:
> > @@ -31,12 +36,19 @@ configure_from_network() {
> >                  if [ -n "$SRV_HOST" -a -n "$SRV_PORT" ]; then
> >                      printf .
> >                      cfgdb=$(mktemp)
> > +                    get_mac_addresses
> >                      wget -q -O $cfgdb \
> > -                      "http://$SRV_HOST:$SRV_PORT/ovirt/cfgdb/$(hostname)"
> > +                      "http://$SRV_HOST:$SRV_PORT/ovirt/managed_node/config?host=$(hostname)&macs=$macs"
> >                      if [ $? -eq 0 ]; then
> >                          printf .
> > -                        echo "save" >> $cfgdb
> > -                        augtool < $cfgdb > /dev/null 2>&1
> > +                        bash $cfgdb
> 
> NACK.  We cannot download & execute arbitrary shell scripts. It blows a 
> hole in the security of the node host OS. If there are shell scripts 
> needed they must be built into the node image, and merely the configuration
> data to be fed to them should be downloaded.
> 
> That said, even the original code was kinda suspect - downloading an 
> entire augtool control file basically allows any change whatsoever
> to be made.  
> 
> Really we should download data such as the interface name, and config
> options, and then use a local pre-existing script to make the changes
> and/or call augtool - ie the augtool rules should already be on the
> managed node, with placeholders where you fit in the validated config
> parameters.

Downloading augtool or bash scripts also makes for a horrible data
upgrade path, and complicates life if we want to run the node standalone
without the WUI server present. 

We need to avoid tight coupling between the node & the server. All the
functional logic the node needs must be kept in the node image, and it
only goes off-node to fetch well-defined configuration parameters. This
gives us a fighting chance of providing a sane data upgrade path - if we
know the config params for each version, we can  be carefult to keep
back-compatability, and more easily run standalone by just storing config
params in a local datastore.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|