CVS log for loncom/Attic/lonManage

Up to [LON-CAPA] / loncom

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

- remove manager idea

remove debugging output

Actually read the edit config file and apply it

Add an additional line to the fakey edit script.

Add stubs and base logic for --edit switch.

re-factored the LondConnection state machine sequencing into a separate
sub:   SequenceStateMachine

Complete the process of peeling it away from lonc... debugged the transaction
logic

- Really debug use of foreign config files.
- Set debug level on LondConnection for now to assist in debugging efforts.
- Debug the connection negotiation logic.

Add code to create initial connection to lond.  Tests out ok.

Block out top level logic for standalone operation.. NOTE:  lonManage
will not work until further notice (the logic is all stubs for now).

Get my host from either command lin parameter or from config file
depending on our startup mode.

Add/debug code to support reading alternat hosts.tab for use in standalone environment.

Add switch processing and usage for standalone mode; To invoke standalone mode
>both< of the following switches will need to be present with values:

--myname=hostname - hostname is the name lonManage will use to negotiate the
   host key.  This must match the hostname given to this system in
   the manager table read by the associated lond.

--hosts=filename - filename will be read as the hosts.tab for this invocation
   of lonc.

This will allow the program to run standalone as well as to manage nodes in a
cluster other than the one it is a member of (assuming the remote management
table allows that).

- use lib . in order to access LondConnection.pm in the cwd.
  At this point we're requiring that lonMangae and LondConnection.pm
  be in the cwd of the user invocing lonManage.
- Read the configuration files using the configuration I/O functions
  in LondConnection.pm for now... later we need switches that tell
  us:
  - Our lonCAPA hostname.
  - Where our 'hosts.tab' is.
  so that we can use the LondConnection::ReadForeignConfig member.

Add ability to manage entire cluster in hosts table.

Adjust the usage message to reflect what actually will happen on
--reinit={lond|lonc}

Remove BUGBUG about comment about authentication as we'll be doing
host based authentication initially (no need for lonManage to do anything),
and certificate based later (need at that time).

Initial working version... tested against an unmodified lond this
produces an unknown_cmd response which is about what I'd expect.

Debug request building in Transact.

Felt strongly enough about hoisting ReadConfiguration into a separate sub
that I did it now before I forgot.

Code/test ValidHost.  The hosts.tab and the perl variables are read in as
global hashes as a side effect.  May later want to clean this up by making
a separate getconfig function and hoisting the config reads into that.

Write ReinitProcess function in terms of ValidHost and Transact.

Completed PushFile function in terms of
- ValidHost - Determines if target host is valid.
- Transact  - Performs one of the valid transactions with the
              appropriate lonc<-->lond client/server pairs.

1. Require to be run as root.
2. Catch case where no operation switch is supplied and put out usage.
3. skeleton/comments for PushFile function.

Implement command switch dispatching.

Complete command line parsing (tested)

Get switch parsing right.

Put in parameter parsing infrastructure

Add usage and skeleton documentation.

New file:  lonManage will be the user side of the lonCAPA remote management
interface.  It is a command line utility that will initially be capable of:

   lonManage  -push   <tablename>  newfile  host
        Push <tablename> to the lonTabs directory.  Note that
        <tablename> must be one of:
           hosts  (hosts.tab)
           domain (domain.tab)

    lonManage  -reinit lonc host
           Sends a HUP signal to the remote systems's lond.

    lonmanage  -reinit lond host
          Requests the remote system's lond perform the same action as if
          it had received a HUP signal.

    In the above syntax, the host above is the hosts.tab name of a host,
    not the IP address of the host.