You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gui-dev@apache.org by Randy Terbush <ra...@zyzzyva.com> on 1997/08/20 15:41:29 UTC
Re: GUI-Dev
Can we please make sure these make it to gui-dev? Other people need
to see this discussion.
> > > But I maybe you didn't got my concern here. I will explain.
> > > As I understand it you have the configuration variables in memory,
> > > but how do they go into Apache for configuration??
> > > As you know, Apache is written in the C-language. Or do you want to
> > > go for the option where your configuration tool write in a file
> > > and then gives Apache a 'SIGHUP'??
> > >
> >
> Bingo- as a start we'd just "communicate" with apache via it's config
> files. In future, once this whole system is up and operational and
> there is perhaps a mod_monitor or mod_snmp then we can gradually fold
> this functionality into the server. To my thinking the server would
> have to be threaded before something like this could come to pass so
> first things first. But using SNMP as a configuration language from the
> start would make this this integration much easier and keep the number
> of protocols required down to a minimum of one.
But..But...
Harrie has already written a mod_snmp. This is where I don't agree.
The SNMP functionality needs to go in the server. As he pointed
out, we will need to write the config MIB, but I'm excited to have
a look at his tool to generate the C code from the MIB.
> > > This part is what I not completely get, maybe you can explain this??
> > > An SNMP solution should be that the SNMP agent inside Apache
> > > completely configures it. Something as the configuration tool
> > > speak SNMP with the Apache agent and the SNMP-SET changes
> > > directly the appriopriate variables in Apache (runtime).
> > >
> > > HH
> >
> Right now the configuration server would be a separate process on the
> machine hosting the web server. The configuration server would read and
> then write changes to the configuration files and then HUP the web
> server. We can have the configuration server find out about the modules
> installed in the web server by parsing the result of apache -h (I think
> this is the flag- there's a flag which causes apache to spit out info on
> which modules/options are compiled in similar to the information
> displayed by mod_config.)
In my opinion, the config server is just an added exercise that
really isn't needed. You probably weren't aware that Harrie has
given us a start with mod_snmp.
> All the authorization can be handled by sockets or SNMP (built in
> there). Hopefully we won't have to deal with CGI... We can do things
> without encryption, etc. at first and then fold that in- we just have to
> keep security in mind during the build. If the broker (glue between the
> application code and classes doing the actual communication) is built
> correctly, we can plug in authorization with minimal changes to the
> application source.
>
> > p.s. Randy: Don't forget will use RSA keys in the password auth. part,
> > does CGI supports them?
I think that you would be better off writing a key authentication
module for Apache.
A possible APACHE-MIB for the configuration
Posted by Harrie Hazewinkel <ha...@jrc.it>.
Hi,
Oops... I forgot to attach the MIB itself. :-((
Hereby the MIB.
--
HA HA
0- Harrie Hazewinkel --------------------------------------0
mailto:harrie.hazewinkel@jrc.it phone:+39+332+789384
http://porto.jrc.it/~harrie/ fax:+39+332+785500
postal: JRC of the E.C. - CEO unit
Ispra 21020 (VA) Italy
0----------------------------------------------------------0
Ik ben Harrie en ik ben 28 jaar en doe SNMP na. MIB, MIB
A possible APACHE-MIB for the configuration
Posted by Harrie Hazewinkel <ha...@jrc.it>.
HI,
A long time ago we psoke about the possibility of using
SNMP and MIbs for the possible configuration of
the Apache server.
Hereby I sent some preliminary ideas about this MIB.
It is mainly consisting of tables which are indexed by
the 'sysApplRunIndex' of the SYStem APPLication - MIB.
This doesn't mean that this SYSAPPL-MIB has to be
implemented to, but it is used only in case someone
does and then multiple invocations of Apache on the
same system are possible.
I believe especialy the first table is quite useful.
I hope you can understand my ideas so far. I plan to provide
a more complete desription in the future. These are my
first ideas.
HA HA
0- Harrie Hazewinkel --------------------------------------0
mailto:harrie.hazewinkel@jrc.it phone:+39+332+789384
http://porto.jrc.it/~harrie/ fax:+39+332+785500
postal: JRC of the E.C. - CEO unit
Ispra 21020 (VA) Italy
0----------------------------------------------------------0
Ik ben Harrie en ik ben 28 jaar en doe SNMP na. MIB, MIB
SNMP MIB Structure
Posted by Calvin Justin Seiferth <se...@www.disa.mil>.
Harrie,
I had thought about dividing the MIB into tables for "core", "modules"
and "contributed" sections. Why?
Accounting for all the directives in one big MIB seems like a tough task
to me but breaking it up into variables associated with the major parts
seems workable- allowing the MIB to stay fairly stable across Apache
versions and various combinations of modules/functionality.
Each SNMP variable would be a string whose value would need to be parsed
to strip out the relevant info. For instance we could pass:
www.disa.mil:specialized.domain.mil:documentdirectory/subdirectory:directive:directive_value
as the value for the "core" variable.
I couldn't find a MIB which used this approach or addressed this issue
in an alternative way; any suggestions or does this seem like a workable
approach?
If the approach does seem workable here are some areas that are
confusing to me:
I don't understand how tables are constructed and queried very well.
Could you help me out in this area?
What object type would you recommend using? It can't have any arbitrary
upper limit on length since my context idea could extend to very long
strings as it moves down a complex directory structure for instance
although perhaps 512 - 1024 characters would allow for this instance.
What are the particulars of the calling sequence which allows the
managed entity (aka the configuration server), snmpd and the agent to
interact. I understand the snmpd <-> agent communication but how is the
snmpd<->configuration server communcation handled? From the code I have
read it seems as if the configuration server "registers" itself with
snmpd and then snmpd in turn then just queries the managed object when a
get request is received or sends in a new value when a set directive is
issued. Is this correct and are then intracacies here? I was planning
on implementing this by just snagging what seemed to be the relevant
bits of mod_snmp.
Thanks...
Justin
Re: GUI-Dev
Posted by Harrie Hazewinkel <ha...@jrc.it>.
Maj Justin Seiferth wrote:
>
> Harrie, et al:
>
> I've integrated the Advent SNMP java-based toolkit into the GUI I've
> been working on- I can establish contact with snmpd and retrieve system
> information (from the OS obviously, not Apache) so I now is the time to
> start worrying about a configuration mib and how to integrate this into
> the server end.
I work on an upgrade of the SNMP-module for Apache in order to get
it in line with the IETF defined WWW-MIB.
>
> How would you fashion the configuration MIB and is the separate server
> idea still the best one for doing something which can read/write config
> files? With the dynamic nature of the config directives I'm not sure
> what the best structure for a configuration MIB might be.
I have tried to think of something for a configuration MIB.
I believe this is quit difficult, since a lot of different
directives have to be grouped. Once this is done.
We have to write the tables in which the values can be set.
We also have to decided if we go for a more general option
or specific.
We have somehow to choose between:
a) a table in which 1 entry for 1 installed Apache has
lots of columns (in which each a seperate managed objects
(configuration directive) is defined.
or
b)
every configuration directive has a seperate entry.
For the choice of putting the configuration inside apache or
outside. The choice is do we want to "sighup" Apache after each
change in configuration. I believe the most easiest way is via
config-files, but this is actually not prefered, because
before responding an SNMP-set it must be sure that
the SNMP-set operation is possible. IMHO, this
is directly required if config files are used and
there can become inconsistencies between the running
configuration and the SNMP-setted configuration.
--
HA HA
0- Harrie Hazewinkel --------------------------------------0
mailto:harrie.hazewinkel@jrc.it phone:+39+332+789384
http://porto.jrc.it/~harrie/ fax:+39+332+785500
postal: JRC of the E.C. - CEO unit
Ispra 21020 (VA) Italy
0----------------------------------------------------------0
Re: GUI-Dev
Posted by Maj Justin Seiferth <se...@www.disa.mil>.
Harrie, et al:
I've integrated the Advent SNMP java-based toolkit into the GUI I've
been working on- I can establish contact with snmpd and retrieve system
information (from the OS obviously, not Apache) so I now is the time to
start worrying about a configuration mib and how to integrate this into
the server end.
How would you fashion the configuration MIB and is the separate server
idea still the best one for doing something which can read/write config
files? With the dynamic nature of the config directives I'm not sure
what the best structure for a configuration MIB might be.
Justin
seiferth@erols.com
Re: GUI-Dev
Posted by Harrie Hazewinkel <ha...@jrc.it>.
Randy Terbush wrote:
[snip]
> > >
> > Bingo- as a start we'd just "communicate" with apache via it's config
> > files. In future, once this whole system is up and operational and
> > there is perhaps a mod_monitor or mod_snmp then we can gradually fold
> > this functionality into the server. To my thinking the server would
> > have to be threaded before something like this could come to pass so
> > first things first. But using SNMP as a configuration language from the
> > start would make this this integration much easier and keep the number
> > of protocols required down to a minimum of one.
>
> But..But...
>
> Harrie has already written a mod_snmp. This is where I don't agree.
> The SNMP functionality needs to go in the server. As he pointed
> out, we will need to write the config MIB, but I'm excited to have
> a look at his tool to generate the C code from the MIB.
Depending on the mod_snmp integeration the current protocol engine is
not able to do writes and so. I deliberatly took them first out,
because this functionality wasn't needed. Also the tool to generate
C code from a MIB is a bit changed, since my first relaese of mod_snmp.
So if we ship in the protocol engine of my tool it is directly able to
do writes as well. The tool still need an extension in order to
generate also all SNMP-set funtions. But that can be done quit quickly.
URL' for the
mod_snmp -> http://www-musiq.jrc.it/software/snmp0b1_apache1_2b8.tar
(This is also placed by Randy at Apache-site)
SNMP-toolkit -> http://www-musiq.jrc.it/~harrie/smut/smut_2b1.tar.gz
Writing such a config MIB is not that difficult aspecially if
I get a view on what the configuration toolkit does at the front
and how Apache needed to write this internally. This could be
based on some earlier given object class example.
About mod_monitor and mod_snmp.
What should mod_monitor do in this case?? Provide already exisiting
statistics as the status module or the mod_snmp.
For the monitor part you can build the GUI on some PD SNMP-java classes,
I guess.
>
> > > > This part is what I not completely get, maybe you can explain this??
> > > > An SNMP solution should be that the SNMP agent inside Apache
> > > > completely configures it. Something as the configuration tool
> > > > speak SNMP with the Apache agent and the SNMP-SET changes
> > > > directly the appriopriate variables in Apache (runtime).
> > > >
> > > > HH
> > >
> > Right now the configuration server would be a separate process on the
> > machine hosting the web server. The configuration server would read and
> > then write changes to the configuration files and then HUP the web
> > server. We can have the configuration server find out about the modules
> > installed in the web server by parsing the result of apache -h (I think
> > this is the flag- there's a flag which causes apache to spit out info on
> > which modules/options are compiled in similar to the information
> > displayed by mod_config.)
>
> In my opinion, the config server is just an added exercise that
> really isn't needed. You probably weren't aware that Harrie has
> given us a start with mod_snmp.
Correct me if I am wrong, but is the concept of the configuration server
bnot based on the fact that the Apache-server and the configuration
server
run at the same box?? So remote-shells, remote-login are also required.
An SNMP soulution is not requiring these last ones. 1 manager
application
communicates with all the SNMP-agent out in the filed and thus with the
Apache-server.
>
> > All the authorization can be handled by sockets or SNMP (built in
> > there). Hopefully we won't have to deal with CGI... We can do things
> > without encryption, etc. at first and then fold that in- we just have to
> > keep security in mind during the build. If the broker (glue between the
> > application code and classes doing the actual communication) is built
> > correctly, we can plug in authorization with minimal changes to the
> > application source.
> >
> > > p.s. Randy: Don't forget will use RSA keys in the password auth. part,
> > > does CGI supports them?
>
> I think that you would be better off writing a key authentication
> module for Apache.
The new SNMPv3 WG of the IETF is creating security for the SNMP
protocol.
So in the future the SNMP-agent could go speaking SNMPv3.
Although my comments look like I plea guilty for the SNMP-solution,
I am certainly not against any other solution. But I agree with Randy
that we should keep the required protocols to the minimum (maybe one).
HH
--
0- Harrie Hazewinkel --------------------------------------0
email:harrie.hazewinkel@jrc.it phone:+39+332+789384
http://porto.jrc.it/~harrie/ fax:+39+332+785500
postal: JRC of the E.C. - CEO Programme
Ispra 21020 (VA) Italy
0----------------------------------------------------------0
Ik ben Harrie en ben 28 jaar en doe SNMP na. MIB, MIB.