[prev in list] [next in list] [prev in thread] [next in thread]
List: ntop-dev
Subject: RE: [Ntop-dev] --use-syslog (was: Issues w/ ntop 2.2.93)
From: "Burton M. Strauss III" <Burton () ntopsupport ! com>
Date: 2003-08-31 13:35:23
Message-ID: JIEPJGFPFMFIGBNCPKGGKEJJEEAA.Burton () ntopsupport ! com
[Download RAW message or body]
You know, there was an option that was disabled when Luca chainsawed one too
many lines out of main.c in his cleanup. I thought it was before 2.2.93 and
I don't remember which option - wait one - nope, that was p3p...
When I added --log-extra, I did a bit more than the usual ntop option does
(set the flag and damn the torpedos), because I wanted to cleanup an ugly
bit --trace-level was overloaded so that --trace-level 5 did more than just
be --trace-level 4 + more messages. And because Luca and I are interested
in different things at that noisiest level - he wants file:line, while I
want something that logwatch can chew upon. So --log-level was born.
In order not to break existing scripts, I set --trace-level 5
== --trace-level 5 --log-extra 1 ... then on 2003/08/22 (BMS340), I fixed
the nit so that --log-extra 2 --trace-level 5 wasn't stepped on.
The -L vs. --use-syslog, if it's not clear from the /usr/bin/ntop --help
output, sure that can be an FAQ entry.
But - for me - --use-syslog has NEVER stopped working. My scripts, across
most platforms, have --use-syslog=local3 so I can keep the mess of ntop
debugging and noisy messages from swamping my normal logs. If ntop.log gets
too big, I just grep out the junk or delete it. Tigger - my main
development platform - runs RH8 with reasonably current patches (I have a RH
Network Demo account and run up2date). There's nothing in the RH updates
that should affect the code.
The only think that has happened between 2.2c and 2.2.9x is that ntop sheds
root privileges sooner. It could be that you are getting bit by some sort
of logging privilege issue. As I said, I run a pretty default setup, but if
you've got some security patches that lock down syslog()??? Ring any
bells???
You can usually test things by su to the ntop user id and trying the command
line tool logger - if it gets through, e.g.
$ logger -p local3.info "this is a test"
$ tail -n 1 /var/log/ntop.log
Aug 31 08:27:06 tigger ntop: this is a test
then ntop's logging should work too.
-----Burton
-----Original Message-----
From: ntop-dev-admin@unipi.it [mailto:ntop-dev-admin@unipi.it]On Behalf
Of pc
Sent: Thursday, August 28, 2003 5:25 PM
To: ntop-dev@Unipi.IT
Subject: RE: [Ntop-dev] --use-syslog (was: Issues w/ ntop 2.2.93)
Well, I see we are in agreement that -L can't be hard coded in the init.d
script if you want to use --use-syslog in the config.
Back in the beginning of August I rebuilt this machine from scratch and then
migrated a boatload of data. I also installed all the RH upgrades available
at that time prior to compiling and installing the cvs version of ntop
v2.2c. --use-syslog=local1 was working reliably in this environment. Since
that time I have continued to install the RH upgrades, added a variety of
database engines, added some perl modules that I needed and some other odds
and ends. The only thing that I installed after ntop that I has anything to
do with it is rrdtool (that I know of), but I'm not using it yet. Just
prior to installing 2.2.93 the --use-syslog=local1 was still running fine.
So I rebuild and installed 2.2.93 and the option dies. Previously I had all
the options hard coded into an init script that I had developed locally and
migrated them to new ntop.config file. My inclination is to do a
'reasonable' level of investigation at my end prior to calling in the
troops. I found the init.d script interference and corrected it. I also
attempted to hard code the --use-syslog=local1 into the init.d script to see
if that had any impact (none). Where you are working with beta testing
prior to a new release, I thought I would report the issue and anything else
I could find.
I don't have the output from the v2.2c install, so I can't do any comparison
without reinstalling it. I'm a firm believer in installation/patching tools
like rpm. They certainly have their drawbacks and rpm could use some work
as well; particularly with timestamping. But overall they are certainly
better than trying to research every dependency with every package that
comes along.
At this point it appears my best shot would be to download the latest cvs
again and go from there. If the situation corrects, there must be something
wrong between my environment and the source rpm for 2.2.93. If not, then I
guess a reinstall of 2.2c is in order so that I can make sure that a more
recent compile still works (and validate my environment) and provide some
output for comparison. I don't have the expertise with c code to get in
there and see what may or may not be creating the issue. It's not my flavor
and the potential dynamic library impacts are a reason that I've never had a
real interest with developing in c.
I'll keep you informed but it wont be quick where there are a number of
other priority issues on my plate (not associated with ntop).
Tim
-----Original Message-----
From: ntop-dev-admin@unipi.it [mailto:ntop-dev-admin@unipi.it]On Behalf
Of Burton M. Strauss III
Sent: Thursday, August 28, 2003 9:05 AM
To: Ntop-Dev
Subject: [Ntop-dev] --use-syslog (was: Issues w/ ntop 2.2.93)
It works for me on RH7.3, 8 and 9 -- plus six other Linuxes and FreeBSD. It
has to be something in your configuration. I think, based on your various
comments, that you don't understand - -L and --use-syslog=xxxxxx are the
same (in that they're the short and long version of the 'same' option, yet
they're independent because of the need to process the parameter.
If you give more than one, only the right most in the option string will
matter.
So "--use-syslog=local3 -L" is really just -L
>From main.c:
case 'L':
myGlobals.useSyslog = DEFAULT_SYSLOG_FACILITY;
break;
and
case 131:
if (optarg) {
int i;
stringSanityCheck(optarg);
for (i=0; myFacilityNames[i].c_name != NULL; i++) {
if (strcmp(optarg, myFacilityNames[i].c_name) == 0) {
break;
}
}
if (myFacilityNames[i].c_name == NULL) {
printf("WARNING: --use-syslog=unknown log facility('%s'), using
default value\n",
optarg);
myGlobals.useSyslog = DEFAULT_SYSLOG_FACILITY;
} else {
myGlobals.useSyslog = myFacilityNames[i].c_val;
}
} else {
printf("NOTE: --use-syslog, no facility specified, using default
value. Did you forget the =?\n");
myGlobals.useSyslog = DEFAULT_SYSLOG_FACILITY;
}
break;
If the facility name you gave is missing, you should see - printed to the
console - an error message. Otherwise, it should set to the value you gave.
If you forget the =s, --use-syslog is equivalent to -L.
> -----Original Message-----
> From: pc [mailto:tgm@cshore.com]
> Sent: Wednesday, August 27, 2003 10:16 PM
> To: deri@ntop.org; bstrauss3@users.sourceforge.net
> Subject: Issues w/ ntop 2.2.93
>
> I'm resending this message directly where the ntop-devel mailing list
quarantined it for the moderator due to its size. Nothing happened with the
previous for more then 24hrs. I also did a little more editing and added
another attachment, so you can have the moderator delete the first message.
>
> -----Original Message-----
> From: pc [mailto:tgm@cshore.com]
> Sent: Tuesday, August 26, 2003 9:07 PM
> To: ntop-dev@unipi.it
> Subject: Issues w/ ntop 2.2.93
>
> The other day I loaded 2.2.93 on my machine and there are a variety of
issues that I have found. I'm a newbie around here, so please be a little
patient. With the call for comments ASAP, I thought I would pass this along
quickly instead of getting better acquainted with the group first. I'm not
a networking expert and I'm not a c coder either, but I thought that my
experience as a unix/NT SA could be of some use.
>
> First, my environment: The RedHat source> rpm was downloaded and rebuilt
on an RedHat 9 system. The system has all the latest RedHat updates
installed including the latest kernel. The only thing that I changed in the
ntop.spec was the release number so I don't screw up down the street
(changed to local1 - a convention I use for locally compiled rpms). This
means that NPTL is active. I've attached a copy of the output du> ring the
rebuild (see ntop.build.redhat9.rpm.txt). There were no problems
encountered with the rebuild process and the install via rpm was also fine.
There were a few issues with new vs. old file locations where the previous
release was 2.2c from a cvs download.
>
> This box is somewhat of a toy I use for keeping up with what's happening
in the linux world but I also use it for some valid development at times. I
have a few services running (secondary DNS, NTP, backup DHCP, etc) for my
relatively tiny home network (10 nodes). But I do have a couple of routers
on the network and a Cabletron ELS100 switch, so I can do some advanced
playing around. Linux firewall features are currently not running on this
machine. rrdtool is installed but I'm not currently using it. A PR form is
attached for further info (see: myconfig_20030826.txt)
>
> So here are some things that I've come up with:
>
> --use-syslog option not working
>
> The --use-syslog option no longer works on a separate facility. This
option was configured and working fine using facility 'local1' on my machine
with ntop 2.2c. Initially I had a problem with the -L option that was hard
coded in the init.d script, but this has been repaired (see separate init.d
issues below). If using -L it processes normally to the daemon facility.
With --use-syslog=local1 only the following is being inserted in
/var/log/messages: "Processing file /etc/ntop.conf for parameters...",
followed by this message AGAIN (strange), followed by "ntop startup
succeeded". When ntop is shutdown "ntop shutdown succeeded" is logged.
Facility local1.* is configured in /etc/syslog.conf to go to file
/var/log/ntop. The file is not being created when ntop is started.
Touching the file manually and changing ownership to ntop does not help
either (was not required for 2.2c). Looking at the ntop web configuration
screen shows that the option is in fact being parsed and the option line
shows that facility local1 should be in use. A very interesting aspect is
the fact that the ntop web interface sees the log activity. My guess is
that the log data is being held in memory. lsof of the ntop process shows
an open write only pipe. Further testing by hard coding --use-syslog=local1
in the init script and removing it from /etc/ntop.conf does not help either.
<snip/>
_______________________________________________
Ntop-dev mailing list
Ntop-dev@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
Ntop-dev@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic