...to add a few suggestions, me and my colleagues have used a simple way to distinguish different SEC instances from each other - we have created different rule file directories for each functional area (e.g., /etc/sec/linux, /etc/sec/solaris, etc.), and we have specified rules with a wildcard as the very first option, e.g. sec.pl -conf=/etc/sec/linux/*.rule ... With that way, it is immediately evident what kind of area each process is watching, even if you see only the first part of the command line. As an additional benefit, your rule files are better organized and the command line is much shorter. BR, risto
2010/12/12 Risto Vaarandi <risto.vaara...@gmail.com>: > Tim, > although I can see some rationale for the secrc flag, the -title > option looks somewhat weird to me. Actually, in the UNIX world it is > common to create a hard link to a program if there is a need to run > the same program under different names. There are also other > opportunities to distinguish processes from each other and learn their > command line options. Firstly, if you set up pid files with different > names for production processes, you have a nice mapping from name to > pid. Also, the SEC dump file lists all options it has read from > command line and resource file, plus the location of the resource > file. > Just out of curiosity, how many SEC processes are you running at the > same node? I have had a number of boxes with more than one process up > and running, and it has never been an issue for me to make a > distinction. > regards, > risto > > 2010/12/11 Tim Peiffer <peif...@umn.edu>: >> Risto, >> >> I have a Feature request. I would like options to pass SECRC and create a >> title via the shell command line. >> >> For a while now I have been uncomfortable with the SEC's use of the process >> table. You can see what is going on in the process table, but if there are >> a number of files being monitored, the line is difficult to read creating >> some confusion. Add to that the explicit use of path names, and the process >> table line gets even longer, exacerbating the confusion. System5 unix >> (solaris) only exposes a limited number of the commandline, and the salient >> details of SEC may become invisible. I would like something to simplify the >> process table to make it easier to read. >> >> Example: >> sec 11693 0.0 0.5 11808 5556 ? S 09:28 0:00 >> /usr/local/bin/perl -w /usr/local/bin/sec.pl -detach -conf=/sec/sec.cfg >> -input=/remote/machine-a/log/messages -input=/var/log/messages >> -input=/sec/backups.current -pid=/sec/sec.pid -log=/sec/sec.log >> -dump=/sec/sec.dump -debug=4 -intevents >> >> From the man pages, I see that you can improve things somewhat by pushing >> command line info into a file and creating a SECRC environment variable. >> SEC is then fired off with no arguments. As an additional benefit, you can >> use the file as a pseudo include mechanism, or a master configuration. >> Similar to monitoring multiple input files, if you wish to break the >> config into multiple files, you can. Just create multiple -conf= lines. >> >> However, within my group, there is a dislike of the cleaning out the process >> table, because that by setting a SECRC environment variable, the process >> becomes more difficult to grasp what is going on. At least with something >> explicit on the command line, the environment is accessible to a larger >> group, instead of encouraging spelunking. >> >> I am also interested in 'naming' or providing 'titles' to the sec processes. >> I may have a number of them running, some associated with a given service, >> or modularized to a view or instance of a service, or I may have a SEC >> process running for debugging or testing new code. >> >> Example: >> sec 3013 0.0 0.2 2439688 7260 s006 S+ 12:04PM 0:00.15 >> /usr/local/bin/perl -w /usr/local/bin/sec.pl >> -secrc=/usr/local/myproject/secrc -title=testing >> >> Attached is a unified diff that should be suitable as a patch to sec-2.5.3. >> The patch should provide for the 'title' in the commandline, as well as >> passing in the SECRC via the shell command line. >> >> Regards, >> Tim Peiffer >> >> -- >> Tim Peiffer >> Network Support Engineer >> Office of Information Technology >> University of Minnesota/NorthernLights GigaPOP >> >> +1 612 626-7884 (desk) >> >> >> ------------------------------------------------------------------------------ >> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, >> new data types, scalar functions, improved concurrency, built-in packages, >> OCI, SQL*Plus, data movement tools, best practices and more. >> http://p.sf.net/sfu/oracle-sfdev2dev >> _______________________________________________ >> Simple-evcorr-users mailing list >> Simple-evcorr-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >> >> > ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
