KR20040046619A - Apply embody method snmp and other applications in linux - Google Patents

Abstract

PURPOSE: A method for applying an SNMP(Simple Network Management Protocol) and other application program on the Linux is provided to apply a current value and a new value in a module on the Linux basis without rebooting, and apply a result applied to one module to other module equally. CONSTITUTION: A factor in a configuration file to apply an application function to the Linux based module is allotted/recorded to a flash memory(101). As allotting a space for a structure to store a flash memory value while initializing a system, the factor and a community are read/stored(103). As each module is executed, the stored factor value is stored in the structure or an array in each module(105,107,109).

Description

Apply embody method snmp and other applications in linux}

The present invention relates to an application implementation method between modules in order to solve the problem that communication between snmp (simple network management protocol) and other applications (agent, server, console, etc.) is not free on Linux.

Linux is a Unix-like operating system commonly used in workstations and personal computers, and various variants have emerged because the source can be changed according to various peripherals or the characteristics of the system used.

Since communication between modules (here referred to as protocols) is not free on Linux, it remains a challenge to implement the necessary apply functions for system execution. This, apply, is when snmp changes a particular magnetic variable, tells other application protocols that protocol will change the value of that variable.

There is a problem to be solved in the internal module itself instead of communication between other modules in order to implement the application function on Linux. That is, even inside the module, communication between the existing value and the new value to be applied should be possible.

On Linux, each module makes a lot of configuration file references. Snmp, for example, refers to the configuration file (snmpd.conf file) for important configurations. In this case, each module can read the value from its configuration file and refer to it, but cannot write a new one.

If you want to change to a new value, you have to go through the cumbersome process of modifying the configuration file on the source code, compiling it, and downloading the image back to the system.

The prior art having such a problem will be described below.

Referring to FIG. 1, the process of authenticating snmp's agent community on Linux is as follows. For the relevance of explanation, the main purpose is to apply http and console related to system operation and management.

The community of snmp agent 10 on Linux is defined in the configuration file snmpd.conf. Here, in snmp, the community must be authenticated to access the agent running the external manager, which is the argument used.

This configuration file (snmpd.conf) is created on the snmp directory of source code (compiled) and compiled to move to a folder / file (/etc/snmpd.conf) of Linux (10).

As the system initializes, the snmp agent (snmpd) 10 is executed, and the snmp agent 10 reads the community by referring to the configuration file (snmpd.conf) under the folder (etc) created above. Store in Here, the stored community has the first value as long as the system operates.

In addition, the authentication of the packet from the outside is determined according to whether or not the community of the structure.

And, if you want to change the community for security reasons, you need to change the community-related values in the configuration file (snmpd.conf file) in the source code, compile it, download the generated image to the system and reinitialize it.

If you want to know the changed community from other applications, such as the server (http server: httpd) or console (setup: setupd), you can refer to it other than reading the Linux folder / file (etc / snmpd.conf). There is no way. This is because snmp's community is defined internally in a configuration file called snmpd.conf and has difficulty in communicating between snmp and other modules on existing Linux.

The following describes the community- (snmp's agent community) authentication process on Linux.

Main ()

{

read_config ---- (1)

create_community ----- (2)

agent_read ---- (3)

snmp_auth_parse ----- (4)

}

(1) The function is the process by which the server reads the arguments from the reference file snmpd.conf during initialization. As a detailed procedure (2), the snmp agent reads the community and stores it in the community structure (structure 1).

(3) is a function that receives and receives an external snmp packet sequentially and parses it and processes it. As a detailed process, (4) the function compares the community of the incoming packet with the community of the stored structure (structure1). Decide whether to accept.

However, the following problems exist conventionally.

First of all, if you want to change the community for security reasons, you need to compile the source code, download the image, and reboot the system to apply the changed community.

Second, as with snmp, only reads are made with respect to the community in other modules, such as server (httpd) and setup. That is, there is a problem that you can lead a community and not record and apply a new community in another module.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned problem, and it is possible to apply an existing value and a new value to be applied in a specific module on a Linux-based system without rebooting the system. The goal is to provide a way to implement snmp with other applications on Linux so that the results of one module can be applied to the other.

One feature allows a new community to be applied inside snmp without a system reboot, and another feature allows concurrent changes in other modules to be applied at the same time. The purpose is to provide a method of implementing application functions with other applications.

1 is a diagram illustrating an agent community authentication process of snmp on a conventional Linux.

2 is a view for explaining a method of implementing the application function of snmp and other applications on Linux according to an embodiment of the present invention.

3 is a view showing a community change process according to an embodiment of the present invention.

4 is a diagram illustrating an example of applying a community value changed in a console to another application using a kill function, according to an embodiment of the present invention.

Application implementation method of snmp and other applications on Linux according to the present invention for achieving the above object,

Allocating and writing, in flash memory, parameters in a configuration file to which an application function is to be applied in a particular Linux-based module;

Allocating space for a structure to store a flash memory value while the system initializes, reading and storing the argument and the community;

As each module is executed, storing the stored argument values in a corresponding structure or array in each module.

Preferably, in the module, when you want to change the community in a particular module, changing the value of a specific variable in the module; And applying the changed value to the specific variable in the entire system structure and writing the value applied to the specific variable in the entire system structure to the flash memory.

Preferably, in order to apply the changed specific variable value to another module, sending a signal to other modules using a kill function in a specific module; And causing the other modules to read the signal from the specific module back into the flash memory.

Preferably, the module is a Linux-based snmp agent, characterized in that implemented by assigning the relevant parameters to be applied in the snmp agent and the parameters in the configuration file on the flash memory.

Preferably, the module is a Linux-based http server, characterized in that implemented by assigning the arguments in the configuration file and the relevant parameters to be applied in the http server.

Preferably, the module is a Linux-based console, it characterized in that the implementation by assigning the relevant parameters to be applied in the console and the arguments in the configuration file on the flash memory.

Preferably, the module is a snmp agent, http server, console, characterized in that the specific module uses a kill function for communication with other modules.

Referring to the accompanying drawings, a method for implementing an application function between snmp and another application program on Linux according to the present invention as described above is as follows. For convenience of explanation, the following describes how to apply community in snmp to solve the above problem.

First, the following describes how to apply a new community inside snmp without system reboot.

First, referring to FIG. 2, the community reference of the snmp agent is read directly from the flash memory (flash memory or other memory) instead of from the configuration file snmpd.conf. This means that the community must be stored in flash memory.

For this purpose, the community storage space is allocated on the flash memory 101 to record the total sysconf structure value.

Now, the system initializes and allocates space for the entire system structure (sysconf structure) to store the flash memory 101 value, and reads the flash memory value and stores it in the structure (S101). In the process, the community is also read and saved.

Thereafter, each module, that is, the snmp agent (snmpd) 105, the server (httpd) 107, the console (setupd) 109, and the like, is executed to store the entire system structure (sysconf) value stored in the corresponding module. Stored in a structure or an array (S103).

And, if you want to change the community in the above state is as follows.

Referring to FIG. 3, when a community wants to change a community in one module (eg, change the read community from public to read in the console), the read community is changed to read in a community array inside the console 109 ( Read community = read), and this value is again applied to the read community (Read commuinty = read) of the community part of the whole sysconf structure 103 (S111), and finally the applied structure value is stored in the flash memory 101. ) To write (S113). This eliminates the need to reboot the system as before to apply the new values.

Meanwhile, referring to FIG. 4, it is necessary to communicate with each other to apply the community value changed in the console 109 in another module so that the changed community value may be applied in other modules snmp and http.

To this end, the present invention uses a kill function. The console 109 sends a signal (e.g., USR1) to another module (ie, a processor identifier (pid) to be executed) using a kill function (S121), and the receiving side (httpd, snmpd) receives the flash memory ( 101 may be read again (S123). This is because kill (pid, signal) of the purpose of the kill function sends the specified signal to the specified processor (pid).

In order to enable the above process, the corresponding module (console) must first send a signal to the application module (http, snmp) through a kill function. You need to execute a function that reads flash memory.

It will be described in detail below.

The first snmp agent (snmpd) describes the process of reading the flash memory without referring to snmpd.conf.

Main ()

{

read_config --------- (1)

FlashParmRead () ---- (2)

Read_community ----- (3)

Agent_read

Snmp_auth_parse-(4)

}

The above function (1) is a part that reads the community from snmpd.conf before, so the block is processed.

Then, (2) reads system parameters from flash memory into sysconf, and (3) stores the community values of the sysconf contents in community structure 2 of the snmp agent. (4) Process by comparing the community of packets actually coming from the function and the values stored in community structure 2.

Secondly, the process of applying a new value to another module through communication with another module will be described. First of all, change the community in snmp and apply it to other modules (http, console).

If you change the community value through the Snmp Manager and apply the application, the snmp agent handles it as follows.

Apply_process_func ()

{

proc_sysconf --------- (5)

Write_sysconf_to_flash ---- (6)

If ((fp = fopen (/tmp/2/setup.pid,r)) == NULL) {------ (7)

fprintf (stderr, "Can't open file /tmp/2/setup.pid");

} else {

fscanf (fp, "% d", &setup_pid); -------------------(8)

fclose (fp);

kill (setup_pid, SIGUSR1); ------------------- (9)

}

}

if ((fp = fopen ("/ tmp / 2 / ghttpd.pid", "r")) == NULL) {------ (10)

fprintf (stderr, "Can't open file /tmp/2/ghttpd.pid");

} else {

fscanf (fp, "% d", &ghttpd_pid); ----------------- (11)

fclose (fp);

kill (ghttpd_pid, SIGUSR1); ----------- (12)

}

}

In the above algorithm, function (5) applies the contents of community structure 2 of the snmp agent containing the newly applied values to sysconf. (6) The function stores the community value of sysconf in flash memory.

Here, the function (6) is as follows.

void Write_sysconf_to_flash (void)

{

flash_control (flash_jmp_sectorerase, 0x1ff, 0, 0, NO_DIP_MODE); ---(end)

FlashParamWrite ((unsigned short *) & sysconf, sizeof (sysconf)); ---- (me)

}

The function (a) is to allocate flash memory to use, and (b) to write the sysconf structure value to the allocated area. This is the process of allocating fresh when applying apply, and also assigning flash as a function during system initialization and writing the value of the sysconf structure saved in the memory before rebooting with (B).

Then, the current processor identifier (pid) of the console is read in the functions (7) and (8), and the SIGUSR1 signal is transmitted to the corresponding processor identifier (pid) in the function (9).

The function (10) (11) reads the current pid (process id) of http and sends a SIGUSR1 signal to that pid.

In the above, the processor identifiers (pid) of the server and the console are stored in the / tmp / 2 / directory as the currently executing process identifiers. Additional points on this are as follows.

In the above, the snmp was applied to another module. Now, when the community is changed in another module, the snmp agent describes how to handle it.

Next is Snmp agent.

Main ()

{

signal (SIGUSR1, Read_sysconf_from_flash) ----- (13)

fp = fopen ("/ tmp / 2 / snmpd.pid", "w"); --------- (14)

fprintf (fp, "% d", getpid ()); ------------------ (15)

fclose (fp);

}

Read_sysconf_from_flash ()

{

FlashParamRead () ------------------------ (16)

for (cp = kang_communities; cp; prev = cp, cp = cp-> next) {

free (cp); ------------------ (17)

}

read_community () ------------------- (18)

}

In the above algorithm, the function (13) is defined when the snmp agent is initialized to execute a function (Read_sysconf_from_flash) that reads a structure from flash memory when SIGURE1 is received from the outside. This function is the apply apply function.

(14) (15) writes the currently running snmp processor identifier (process id) under "/ tmp / 2 /. This will read this value when another module applies it and send a SIGUSR1 signal to the snmp agent. .

Finally, the operation of the function (Read_sysconf_from_flash) that reads a structure from flash memory is described. When SIGURE1 is signaled from the outside, the Read_sysconf_from_flash function is called, which reads the new value from flash memory and stores it in the sysconf structure (function 16).

Then, before reading the snmp agent from the sysconf, the existing value defined in the snmp agent (community structure 2) is deleted (function 17). Now finally, the value of the stored structure (sysconf) is stored in community structure 2 of the snmp agent. In this way, the community values changed in other modules are applied to the snmp agent.

In the present invention, the description is mainly given by snmp, but the application of the present invention is equally applicable to an http server or a console (console, menu). In other words, the newly applied values in the http server or in the console module itself can be applied to other modules.

In this way, kill functions can be used to solve the difficulty of communicating between modules (or applications) running on Linux. This is a common problem for all systems using Linux as an operating system. And as communication between each module becomes easy, apply function that can apply the value applied in one module to other module at the same time becomes possible.

Also, in Linux when various applications refer to a configuration file, the arguments defined in the file are fixed, which makes it inconvenient to change them. The flexiable argument can be defined in flash memory to refer to the inconvenience of having to reboot.

As described above, the present invention solves the difficulty of communication between each module or application program executed on the existing Linux using a kill function, thereby enabling faster and more accurate processing. This makes it easy to communicate between all systems using Linux as an operating system, so the apply function can apply the values applied in one module to other modules at the same time.

Another effect is that if several applications refer to a configuration file on Linux, the file can be fixed according to the characteristics of the configuration file, and the flexible argument is defined in flash memory. This will solve the inconvenience of having to boot.

Claims (7)

Allocating and writing, in flash memory, parameters in a configuration file to which an application function is to be applied in a particular Linux-based module; Allocating space for a structure to store a flash memory value while the system initializes, reading and storing the argument and the community; And executing the respective snmp and other application programs in Linux, wherein the stored parameter values are stored in a corresponding structure or array in each module as each module is executed. The method of claim 1, Changing a value of a specific variable within a module when changing a community in a specific module among the modules; Applying the changed value to the particular variable in the overall system structure and writing the value applied to the particular variable in the overall system structure to flash memory, wherein snmp and other applications are applied on Linux. How to implement. The method of claim 2, In order to apply the changed specific variable value to another module, Signaling to other modules using a kill function in a particular module; And causing the other modules to read the signal sent from the specific module back into the flash memory. The method of claim 1, The module is a Linux-based snmp agent, and the implementation of the application of snmp and other applications on Linux, characterized in that by implementing the relevant parameters to be applied in the snmp agent and the parameters in the configuration file on the flash memory. The method of claim 1, The module is a Linux-based http server, and the implementation of snmp and other applications on Linux, characterized in that by implementing the relevant parameters to be applied in the http server and the parameters in the configuration file in the flash memory. The method of claim 1, The module is a Linux-based console, and the implementation of snmp and other applications on Linux, which is implemented by allocating the relevant parameters to be applied in the console and the parameters in the configuration file on the flash memory. The method of claim 3, wherein The module is a snmp agent, an http server, a console, and a method for implementing snmp and other applications on Linux, wherein a specific module uses a kill function for communicating with other modules.