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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of pc Sent: Thursday, August 28, 2003 5:25 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > Sent: Wednesday, August 27, 2003 10:16 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > Sent: Tuesday, August 26, 2003 9:07 PM > To: [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
