Re: [Config4gnu-developer] Re: a new approach to "parsers"

[Justin Y. <ju...@di...>]

On Thu, 2002-11-07 at 17:46, Jason Long wrote:

<snip>

> Which makes me think of how remote administration is going to happen. I
> think of two alternatives now; I'm sure there are others:
> 
> 1. Config4GNU is installed on one computer, the computer that manages
> configuration for all other computers. It is configured to use remote shell
> or (preferably) secure shell to read/write remote configuration files and
> run commands on these remote computers.
> 
>     Pros:
>      - only one system has to meet Config4GNU dependencies
>      - ssh/rsh are pretty universally available for all sorts of unixes
>      - simple to upgrade Config4GNU
> 
> 2. A Config4GNU daemon is installed on all computers that can be configured,
> and the client talks to the daemon on the computer that you want to
> configure.
> 
>     Pros:
>      - configuration is not dependent on a certain host being up

If the host isn't up, there are bigger problems than configuration. 
Perhaps CFG could be told to check a remote CFG server every X hours for
possible updates.  This would be similar to the commercial pcr-dist
program, which checks upon boot whether changes to the computer should
be made and makes them as necessary.

>      - Config4GNU installation is limited to files/parsers applicable to a
> particular distribution of Linux/Unix

There's a third possibility which could be used in place of #1 if CFG is
on both machines, otherwise #1 could be the fall-back method, although
there should be a warning before #1 is falled-back upon b/c things could
easily break:

- A user runs CFG on their machine and wants to edit a remote machine's
configuration

- They enter the username/password of an account w/ appropriate
permissions on the remote machine (root, for example)

- The local CFG connects to the remote machine via SSH

- The local CFG attempts to read the remote machine's config by running
the appropriate parser(s) on the appropriate file(s) (which would be
determined by XML data on the remote machine)  Even better, once a
command line version of CFG is finished, there should be an "just output
the raw XML" option so that the local CFG can tell the remote CFG "Send
the XML config for Samba" and get the XML on stdout.

- XML is read back via SSH/SCP (either way, doesn't matter much)

- Local CFG is used to modify data

- Local CFG reconnects or resuses connection to remote computer

- Local CFG sends modified XML to parser on remote machine, which writes
the config file, or sends modified XML to command line CFG on remote
machine, which handles the details.

If the remote machine doesn't have CFG, then although dangerous, it
could fall back to your #1 using nearly the same process but telling ssh
to execute a slightly different command.

Example of command local CFG uses to connect *if* CFG is installed on
remote machine, which I'd argue is strongly recommended:

To get XML:

ssh us...@my... -c 'cfg --fetchraw --path=/Daemons/Samba' > tmpfile

To read XML:

ssh us...@my... -c 'cfg --saveraw --path=/Daemons/Samba' < tmpfile


Admittedly, a CFG server/daemon would be cool, but would also be a lot
of work and added complexity (I think), and like all other remote
configuration programs, is a potential security issue.  To get remote
config working to a point where it is useful, I *think* what I described
would be sufficient, at least at first.  

I could see how a more robust remote administration "module" could be
combined with an authentication module, since they're very similar, and
could be a later optional component.

Well, I guess what I'm saying is that the command line client *should*
have an option to read/write raw XML config data anyway, as that would
be a very slick and powerful option.  If such an option existed, then
99% of remote administration can be done w/ a simple bash script which
handed some XML to CFG on a set of remote machines.

It would also be cool to be able to be able to do small changes via
something like:

for host in "host1.com" "host2.com" "host3.com"
do
  echo 'cd /Daemons/Samba/; set "wins server" = "10.13.1.1"; commit;' \
    | ssh root@$host.com -c 'cfg'
done 


It seems like the sticky point is how to make it easy to ensure that the
configuration changes are successful.  Maybe a better bash script would
be:


for host in "host1.com" "host2.com" "host3.com"
do
  echo 'cd /Daemons/Samba/; set "wins server" = "10.13.1.1"; commit;' \
    > cfg -H $host
done 

Where here, CFG takes responsibility for running SSH to connect, and
handles any error checking.  Perhaps it could even say "Oops, 1 of the
servers is down, do you want me to retry in the background and send you
an email when I'm successful, or give up and send an error email after
24 hours?"


Justin