Bug 219025

Summary: Review Request: ntop - A network traffic probe similar to the UNIX top command
Product: [Fedora] Fedora Reporter: Bernard Johnson <bjohnson>
Component: Package ReviewAssignee: Mamoru TASAKA <mtasaka>
Status: CLOSED DUPLICATE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mathguthrie, mgarski, mtasaka, nhruby, nphilipp, pertusus, roozbeh, tim, tjb, tuju, yaneti
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-13 04:24:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 389631    
Bug Blocks: 201449    
Attachments:
Description Flags
Mock build log of ntop 3.2-1.20061208cvs.fc6.
none
backtrace from the segfault
none
mock build log of 3.3-0.2.20060218cvs.fc7
none
Proposed patch to remove Apache 2 licensed material - if needed
none
fix mysql detection
none
don't use the output of net-snmp-config --cflags
none
fix enable-mysql handling
none
cleanup RRD variables and remove AM_LDFLAGS= @LDFLAGS@
none
use pkgconfig to find modules. add libs to LIBS and not LDFLAGS
none
ntop log
none
link libns against libraries none

Description Bernard Johnson 2006-12-09 14:24:38 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL: http://www.symetrix.com/~bj/projects/Fedora-Extras/ntop-3.2-1.20061208cvs.fc6.src.rpm
Description:
ntop is a network traffic probe that shows the network usage, similar to what
the popular top Unix command does. ntop is based on libpcap and it has been
written in a portable way in order to virtually run on every Unix platform and
on Win32 as well.

ntop users can use a a web browser (e.g. netscape) to navigate through ntop
(that acts as a web server) traffic information and get a dump of the network
status. In the latter case, ntop can be seen as a simple RMON-like agent with
an embedded web interface. The use of:

    * a web interface
    * limited configuration and administration via the web interface
    * reduced CPU and memory usage (they vary according to network size and
      traffic)

make ntop easy to use and suitable for monitoring various kind of networks.

Comment 1 Bernard Johnson 2006-12-09 14:32:44 UTC
If someone could mark bug #197198 a duplicate of this bug, that would be great.

The package currently has many problems.  I need some advice on how to correct
them.  The most annoying is:
E: ntop shared-lib-without-dependency-information
/usr/lib/debug/usr/lib/ntop/plugins/icmpPlugin.so.debug

What is triggering debug files to be packaged in the arch rpm?


Comment 2 Kevin Fenzi 2006-12-09 17:37:21 UTC
*** Bug 197198 has been marked as a duplicate of this bug. ***

Comment 3 Mamoru TASAKA 2006-12-10 02:38:54 UTC
Created attachment 143230 [details]
Mock build log of ntop 3.2-1.20061208cvs.fc6.

I cannot rebuild this by mockbuild
on FC-devel rawhide.

Note:
[tasaka1@localhost SRPMS]$ rpm -q automake autoconf
automake-1.10-2
autoconf-2.61-2

Comment 4 Bernard Johnson 2006-12-10 08:33:25 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-2.fc7.src.rpm

Mamoru, try these.  They mock-build on FC6/rawhide for me.  I'm no autotools
expert, and I think I botched something the first time around.

I reverted the cvs version back to 3.2 on this build.  Also, I integrated a
great deal of the differences from the previous submission.

Still some work to do, but I thought I'd throw this out for you to take a look at.

Comment 5 Mamoru TASAKA 2006-12-10 12:05:37 UTC
Well, I have not looked into this package.
For now I comment only for this issue:

(In reply to comment #1)
>  The most annoying is:
> E: ntop shared-lib-without-dependency-information
> /usr/lib/debug/usr/lib/ntop/plugins/icmpPlugin.so.debug
> 
> What is triggering debug files to be packaged in the arch rpm?

This is because of %files entry of spec file:
--------------------------------------------
%{_libdir}/*
--------------------------------------------
This tries to package all files under /usr/lib (in i386) in
main package, which includes /usr/lib/debug.

Please specify more explicitly the file lists under %{_libdir}.




Comment 6 Mamoru TASAKA 2006-12-10 12:28:15 UTC
Well, a quick glance at this package:
* some files  should not be in main package, like:
--------------------------------------------------
W: ntop devel-file-in-non-devel-package /usr/lib/libntop.so
--------------------------------------------------

* permissions of some files in -debug package is wrong.
----------------------------------------------------
E: ntop-debuginfo script-without-shebang /usr/src/debug/ntop-3.2/fcUtils.c
E: ntop-debuginfo script-without-shebang
/usr/src/debug/ntop-3.2/plugins/xmldumpPlugin.c
E: ntop-debuginfo script-without-shebang
/usr/src/debug/ntop-3.2/globals-structtypes.h
------------------------------------------------------

* By the way, what is fedora-groupadd? Is there any reason
  that this cannot be replaced with groupadd?
* Usually calling userdel or groupdel is not recommended.
  Usually it is left as it is and deleting user or group should
  be manually done by administrator.

* For Requires:
  Please don't write the explicit dependency which is required
  automatically by dependencies of libraries.
  For example, libgd.so.2 dependency pulls gd, so adding "gd"
  explicitly to Requires is not needed.

* For BuildRequires:
  Please don't write redundant dependencies. For example, zlib-devel
  is required by openssl-devel, so adding "zlib-devel" to BuildRequires
  is not necessary.

Comment 7 Mamoru TASAKA 2006-12-10 14:06:13 UTC
Well, another:
* Timestamps:
  For cp or install, please use "cp -p" or "install -p" to keep 
  timestamps
  http://fedoraproject.org/wiki/Packaging/Guidelines
* Source0
  Please specify URL.
* # strip off version number from plugin .so files
  Why is this needed?
* applying patch
  I prefer adding some suffix to original files. i.e. for example:
------------------------------------
%patch0 -p1 -b .plugins
%patch1 -p1 -b .conf
-------------------------------------
* %config(noreplace) %{_sysconfdir}/logrotate.d/ntop
  I think Requires: %{_sysconfdir}/logrotate.d or 
  Requires: logrotate should be added.

* Requires:       fedora-usermgmt
  This is for scriplets?  If so, please write:
  Requires(pre): /usr/sbin/fedora-groupadd
  and so on and not write "Requires:  fedora-usermgmt", however,
  please consider to use normal %{_sbindir}/groupadd and so on.
  ref: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

Comment 8 Bernard Johnson 2006-12-10 22:55:09 UTC
> * %config(noreplace) %{_sysconfdir}/logrotate.d/ntop
>   I think Requires: %{_sysconfdir}/logrotate.d or 
>   Requires: logrotate should be added.

Please read this thread:
http://article.gmane.org/gmane.linux.redhat.fedora.devel/46042

Comment 9 Bernard Johnson 2006-12-11 08:12:34 UTC
> Well, a quick glance at this package:
> * some files  should not be in main package, like:
> --------------------------------------------------
> W: ntop devel-file-in-non-devel-package /usr/lib/libntop.so
> --------------------------------------------------

Fixing that in the next release.

* permissions of some files in -debug package is wrong.
> ----------------------------------------------------
> E: ntop-debuginfo script-without-shebang /usr/src/debug/ntop-3.2/fcUtils.c
> E: ntop-debuginfo script-without-shebang
> /usr/src/debug/ntop-3.2/plugins/xmldumpPlugin.c
> E: ntop-debuginfo script-without-shebang
> /usr/src/debug/ntop-3.2/globals-structtypes.h
> ------------------------------------------------------

Fixing that in the next release. 

> * By the way, what is fedora-groupadd? Is there any reason
>   that this cannot be replaced with groupadd?

fedora-usermgmt provides wrappers around useradd, userdel, groupadd and groupdel
to allow predictable but configurable uids/gids.  I took these from the old package.

If the consensus is that we should not use the fedora tools, then I can replace
them with normal user*/group* tools.


> * Usually calling userdel or groupdel is not recommended.
>   Usually it is left as it is and deleting user or group should
>  be manually done by administrator.

I've been looking for any packaging guidelines regarding this.  It seems sloppy
to me to leave (program) users hanging around.

> * For Requires:
>   Please don't write the explicit dependency which is required
>   automatically by dependencies of libraries.
>   For example, libgd.so.2 dependency pulls gd, so adding "gd"
>   explicitly to Requires is not needed.

I will work on this. How good is RPM?  How far can it be trusted to find the
right dependencies?

> * For BuildRequires:
>   Please don't write redundant dependencies. For example, zlib-devel
>   is required by openssl-devel, so adding "zlib-devel" to BuildRequires
>   is not necessary.

I will work on this as well.

Comment 10 Bernard Johnson 2006-12-11 08:36:20 UTC
> Well, another:
> * Timestamps:
>   For cp or install, please use "cp -p" or "install -p" to keep 
>   timestamps
>   http://fedoraproject.org/wiki/Packaging/Guidelines

Fixed.

> * Source0
>   Please specify URL.

Fixed.

> * # strip off version number from plugin .so files
>   Why is this needed?

This was suggested by Patrice here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197198#c37.  This makes
sense to me as dl'opened modules aren't versioned.


> * applying patch
>   I prefer adding some suffix to original files. i.e. for example:
> ------------------------------------
> %patch0 -p1 -b .plugins
> %patch1 -p1 -b .conf
> -------------------------------------

Fixed.

> * Requires:       fedora-usermgmt
>   This is for scriplets?  If so, please write:
>   Requires(pre): /usr/sbin/fedora-groupadd
>   and so on and not write "Requires:  fedora-usermgmt", however,
>   please consider to use normal %{_sbindir}/groupadd and so on.
>   ref: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

Looking into this.

Comment 11 Bernard Johnson 2006-12-11 13:09:09 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-3.fc6.src.rpm

* Mon Dec 11 2006 Bernard Johnson <bjohnson> - 3.2-3
- fix: do not package debug files in arch package
- fix: remove x bit from /usr/src debug files
- fix: direct source download link
- fix: don't package devel libraries in /usr/lib
- integrate previous package ntop.sysv to ntop.init
- remove sysconfig file
- clean up usage of fedora-usermgt
- remove ldconfig calls
- create a ntop-passwd wrapper to set the passwd
- fix: directory permission in directory, init, and passwd wrapper

Comment 12 Mamoru TASAKA 2006-12-11 16:42:24 UTC
Well, before checking 3.2-3 :

>> * %config(noreplace) %{_sysconfdir}/logrotate.d/ntop
>>   I think Requires: %{_sysconfdir}/logrotate.d or 
>>   Requires: logrotate should be added.

> Please read this thread:
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/46042

Actually I have already known these long discussion because
I always receive mails from fedora-extras-list.

Anyway leaving /etc/logrotate.d unowned by any pacakge is
wrong. You should either
- require logrotate as Requires
- require /etc/logrotate.d
- have this package (ntop) own /etc/logrotate.d (easiest)
*for now* and my thought is this package (ntop)
should require logroate.

>> * Usually calling userdel or groupdel is not recommended.
>>   Usually it is left as it is and deleting user or group should
>>  be manually done by administrator.

> I've been looking for any packaging guidelines regarding this.  It seems sloppy
> to me to leave (program) users hanging around.

I checked http://fedoraproject.org/wiki/PackageUserCreation and
your usermgmt usage seems okay.

>> * For Requires:
>>   Please don't write the explicit dependency which is required
>>   automatically by dependencies of libraries.
>>   For example, libgd.so.2 dependency pulls gd, so adding "gd"
>>   explicitly to Requires is not needed.

> I will work on this. How good is RPM?  How far can it be trusted to find the
> right dependencies?

rpm uses ldd and objdump to check libraries' dependency and this
_should_ work ( _should_ means that if this does not work,
it means that some rpms installed together should be fixed because
they conflict functionally anyway).
Details are on: /usr/lib/rpm/redhat/find-requires

And, writing like "Requires: openssl" does not make sense
because requirement of openssl or so is "version specific".
This is correctly treated by libraries' dependencies, where 
"explicit" requirement of rpm name does not care about these.

Note: If this package needs another "version specific" issue,
this should be written to Requires. A example is xscreensaver-base
(which I maintain), which has a explicit requirement

"pam > 0.80-7" 

because /etc/pam.d/xscreensaver says:
-----------------------------------------------------
auth       include      system-auth
-----------------------------------------------------
this content can be interpreted only by pam >= 0.80


>> * # strip off version number from plugin .so files
>>   Why is this needed?

> This was suggested by Patrice here:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197198#c37.  This makes
> sense to me as dl'opened modules aren't versioned.

Leaving symlinks as they are is sufficient. Please check:
-------------------------------------------------------------------------
[tasaka1@localhost ~]$ for f in /usr/lib/*/*.so ; do  if [ -L $f ] ; then echo
$f ; fi ; done
-------------------------------------------------------------------------
I don't think removing version info is a good idea.

* Another issue:
-----------------------------------
%post
/sbin/chkconfig --add %{name} 2>&1 > /dev/null
-----------------------------------
  scriptlets like these need corresponding requirement as
  Requires(post) or so. Please check the section "Services" of
  http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

By the way, is this okay?
---------------------------------------------------------
 gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../myrrd -DLINUX -I/usr/include/libgdome
-I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -I/usr/local/include -Wshadow -Wpointer-arith
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fPIC -DPIC -MT
libxmldumpPlugin_la-xmldumpPlugin.lo -MD -MP -MF
.deps/libxmldumpPlugin_la-xmldumpPlugin.Tpo -c xmldumpPlugin.c  -fPIC -DPIC -o
.libs/libxmldumpPlugin_la-xmldumpPlugin.o
xmldumpPlugin.c:50:2: warning: #warning 
xmldumpPlugin.c:51:2: warning: #warning
===========================================================
xmldumpPlugin.c:52:2: warning: #warning 
xmldumpPlugin.c:53:2: warning: #warning Missing header files, disabling xmldump
plugin
xmldumpPlugin.c:54:2: warning: #warning 
xmldumpPlugin.c:55:2: warning: #warning FOR MOST USERS THIS IS NOT A PROBLEM
xmldumpPlugin.c:56:2: warning: #warning ntop will build and run just fine...
xmldumpPlugin.c:57:2: warning: #warning 
xmldumpPlugin.c:58:2: warning: #warning Why?
xmldumpPlugin.c:59:2: warning: #warning 
xmldumpPlugin.c:61:2: warning: #warning glibconfig.h unavailable
xmldumpPlugin.c:64:2: warning: #warning glib.h unavailable
xmldumpPlugin.c:67:2: warning: #warning gdome.h unavailable
xmldumpPlugin.c:72:2: warning: #warning 
xmldumpPlugin.c:73:2: warning: #warning
===========================================================
xmldumpPlugin.c:74:2: warning: #warning 
xmldumpPlugin.c:1076:1: warning: multi-line comment
xmldumpPlugin.c:28: warning: 'dumpXML' used but never defined
xmldumpPlugin.c:107: warning: 'traceEvent_forked' declared 'static' but never
defined
xmldumpPlugin.c:242: warning: 'xmlDebug' defined but not used
xmldumpPlugin.c:470: warning: 'handleXmldumpHTTPrequest' defined but not used
---------------------------------------------------------

I have not checked this package 'functionally' yet.

Comment 13 Bernard Johnson 2006-12-12 00:03:49 UTC
(In reply to comment #12)
> Anyway leaving /etc/logrotate.d unowned by any pacakge is
> wrong. You should either

I don't disagree with you on that point. I was just pointing out that a
discussion of how to to resolve this issue has not been finalized.

> *for now* and my thought is this package (ntop)
> should require logroate.

Agreed.  For now, this is the answer, but it may change in the future.

> Leaving symlinks as they are is sufficient. Please check:
> -------------------------------------------------------------------------
> [tasaka1@localhost ~]$ for f in /usr/lib/*/*.so ; do  if [ -L $f ] ; then echo
> $f ; fi ; done
> -------------------------------------------------------------------------
> I don't think removing version info is a good idea.

Because of the way the software works (it loads all files/links in the
.../plugins directory), we can have either a versioned file
(libnetflowPlugin-3.2.so) or unversioned (libnetflowPlugin.so).  We can not have
a symbolic link, because that would cause the plugin to load twice. 

Why do you think it's so important to keep the versioning?  There are no
dependencies on these files - they are dlopened by the application.

>   scriptlets like these need corresponding requirement as
>   Requires(post) or so. Please check the section "Services" of
>   http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

Fixed.
 
> By the way, is this okay?
> xmldumpPlugin.c:53:2: warning: #warning Missing header files, disabling xmldump
> plugin

No, it just took me awhile to figure out the problem.  Fixed now.

Still the pid file is being written to /var/ntop although the config seems to
indicate it should go elsewhere.  Not sure why.  Looking into that.

Also, the syslog should be logged at facility=daemon.



Comment 14 Bernard Johnson 2006-12-12 00:37:17 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-4.fc6.src.rpm

* Mon Dec 11 2006 Bernard Johnson <bjohnson> - 3.2-4
- fix detection of glib-2.0 and gdome2
- remove Requires: entries to let rpm figure them out
- remove BR libxml2, zlib-devel as they are pulled by other packages
- added scriplet requires for /sbin/chkconfig
- add logrotate to requires
- add BR dependency on pkgconfig since patch to fix missing files depends on it


Comment 15 Bernard Johnson 2006-12-12 05:23:37 UTC
Once we resolve the .so naming for plugins, I think this resolves all blockers.

One particular thing to consider is whether ntop should be running in /var/ntop
or some other directory (/var/lib/ntop?)


Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-5.fc6.src.rpm

* Mon Dec 11 2006 Bernard Johnson <bjohnson> - 3.2-5
- use ntop.conf.sample with some modifications
- change default syslog facilty to daemon in init file
- add repo tag for those who want to use it
- install as-data by default, at least for now
- fix package detection of gdome library
- remove extraneous ldconfig call


E: ntop non-standard-gid /var/ntop/dnsCache.db ntop
E: ntop non-standard-gid /var/ntop/rrd/interfaces ntop
E: ntop non-standard-dir-perm /var/ntop/rrd/interfaces 0775
E: ntop non-standard-gid /var/ntop/ntop_pw.db ntop
E: ntop non-standard-gid /var/ntop/macPrefix.db ntop
E: ntop non-standard-gid /var/ntop ntop
E: ntop non-standard-dir-perm /var/ntop 0775
E: ntop non-standard-gid /var/ntop/rrd/graphics ntop
E: ntop non-standard-dir-perm /var/ntop/rrd/graphics 0775
E: ntop non-standard-gid /var/ntop/prefsCache.db ntop
E: ntop non-standard-gid /var/ntop/fingerprint.db ntop
E: ntop non-standard-gid /var/ntop/rrd ntop
E: ntop non-standard-dir-perm /var/ntop/rrd 0775
E: ntop non-standard-gid /var/ntop/addressQueue.db ntop
E: ntop non-standard-gid /var/ntop/rrd/flows ntop
E: ntop non-standard-dir-perm /var/ntop/rrd/flows 0775
E: ntop non-standard-gid /var/ntop/LsWatch.db ntop
W: ntop non-standard-dir-in-var ntop

Comment 16 Patrice Dumas 2006-12-12 10:41:49 UTC
* the autotools related patches should be made upstream (after removal
  of fedora specific stuff). Did you contact them?

* tcp_wrappers-devel is out in devel

* rpmlint warnings seems to be ignorable.

* I reiterate that dlopened objects are better without version, I
  think the current spec is right.

* ntop is still uninterruptible by Ctrl-C when the password is 
  entered, but I guess it is because Ctrl-C is interpreted as a 
  character of the password.

* I still get, after ctrl-C for the first run:
mar 12 déc 2006 12:07:28 CET  THREADMGMT[t3029126032]: RRD: Data collection
thread terminated [p11257]
*** glibc detected *** ntop: malloc(): memory corruption: 0x096121f0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2ff54b]
/lib/libc.so.6(__libc_malloc+0x7e)[0x300c6e]
/usr/lib/libntop-3.2.so(ntop_safestrdup+0x39)[0xb585c9]
/usr/lib/libntop-3.2.so(traceEvent+0x312)[0xb7c472]
/usr/lib/libntop-3.2.so(pcapDispatch+0x1d2)[0xb5ba02]
/lib/libpthread.so.0[0x1532db]
/lib/libc.so.6(clone+0x5e)[0x365eee]
======= Memory map: ========
Abandon

* Kevin made this relevant comment:
8. Instead of removing the .a files you could just pass '--disable-static'
to configure. Possibly also enable: --enable-snmp ?

* I dislike the following in the init file:
chown -f root.ntop /var/ntop/*db  > /dev/null 2>&1
chmod -f 664 /var/ntop/*db  > /dev/null 2>&1

Is it really needed?

* when starting ntop with /etc/init.d/ntop start 
  the [ OK ] doesn't appear.

* the mechanism described in the "PRIVACY NOTICE" of the man
  page should be disabled, at least when started from init file.
  (the option may be in the ntp.conf file, for example).

* ntop web server listens on all interfaces. In the default case 
  it should only listen to localhost, with
-w 127.0.0.1:3000

Comment 17 Bernard Johnson 2006-12-12 11:59:27 UTC
(In reply to comment #16)
> * the autotools related patches should be made upstream (after removal
>   of fedora specific stuff). Did you contact them?

No, I want to make sure everything is working first.

> * tcp_wrappers-devel is out in devel

I will fix that in the next update.
 
> * rpmlint warnings seems to be ignorable.

I agree.
 
> * I reiterate that dlopened objects are better without version, I
>   think the current spec is right.

I agree.
 
> * ntop is still uninterruptible by Ctrl-C when the password is 
>   entered, but I guess it is because Ctrl-C is interpreted as a 
>   character of the password.

I believe that is true, but I'll look into it.

> * I still get, after ctrl-C for the first run:
> mar 12 déc 2006 12:07:28 CET  THREADMGMT[t3029126032]: RRD: Data collection
> thread terminated [p11257]
> *** glibc detected *** ntop: malloc(): memory corruption: 0x096121f0 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2ff54b]
> /lib/libc.so.6(__libc_malloc+0x7e)[0x300c6e]
> /usr/lib/libntop-3.2.so(ntop_safestrdup+0x39)[0xb585c9]
> /usr/lib/libntop-3.2.so(traceEvent+0x312)[0xb7c472]
> /usr/lib/libntop-3.2.so(pcapDispatch+0x1d2)[0xb5ba02]
> /lib/libpthread.so.0[0x1532db]
> /lib/libc.so.6(clone+0x5e)[0x365eee]
> ======= Memory map: ========
> Abandon

I'm unable to reproduce this.  Try loading the debug symbols and getting a
backtrace under gdb.
 
> * Kevin made this relevant comment:
> 8. Instead of removing the .a files you could just pass '--disable-static'
> to configure. Possibly also enable: --enable-snmp ?

I'll include both of those in the next release.
 
> * I dislike the following in the init file:
> chown -f root.ntop /var/ntop/*db  > /dev/null 2>&1
> chmod -f 664 /var/ntop/*db  > /dev/null 2>&1
> 
> Is it really needed?

I dislike it too.  There are some non-trivial permission problems that we must
overcome.  I think another patch is in order because I just found a security
hole (the admin password file is created world readable).

> * when starting ntop with /etc/init.d/ntop start 
>   the [ OK ] doesn't appear.

Fixed for the next release.
 
> * the mechanism described in the "PRIVACY NOTICE" of the man
>   page should be disabled, at least when started from init file.
>   (the option may be in the ntp.conf file, for example).

I forgot about this, so I'll fix it in the next release.
 
> * ntop web server listens on all interfaces. In the default case 
>   it should only listen to localhost, with
> -w 127.0.0.1:3000

You're right, I'll change that in the init script and config file as well.



Comment 18 Bernard Johnson 2006-12-14 09:48:05 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-6.fc6.src.rpm

* Thu Dec 14 2006 Bernard Johnson <bjohnson> - 3.2-6
- configure --disable-static
- configure --enable-snmp
- patch to fix permissions of created gdbm databases
- no more ntop-passwd
- fix OK printing in init file, redirect stdout of ntop command to null
- fix permissions on LsWatch.db database creation
- only listen on 127.0.0.1:3000 by default


(In reply to comment #17)
> > * tcp_wrappers-devel is out in devel
> 
> I will fix that in the next update.

I'm building for FC6, so I can't do it at this time.
 
> > * ntop is still uninterruptible by Ctrl-C when the password is 
> >   entered, but I guess it is because Ctrl-C is interpreted as a 
> >   character of the password.
> I believe that is true, but I'll look into it.

ntop calls the GETPASS(3) routine.  From the man page:
While reading the password, signal generation (SIGINT, SIGQUIT, SIGSTOP,
SIGTSTOP) is disabled  and the  corresponding  characters (usually control-C,
control-\, control-Z and control-Y) are transmitted as part of  the  password.

So "as designed".


Comment 19 Patrice Dumas 2006-12-14 14:59:06 UTC
There is a missing BR on net-snmp-devel. After net-snmp-devel is 
installed, build fails with:

gcc -shared  .libs/libsnmpPlugin_la-snmpPlugin.o  -L/lib -lgdome -lglib-2.0
-lxml2 -L/usr/local/lib -L/usr/lib -lne
tsnmpmibs -lnetsnmpagent -lnetsnmphelpers -lnetsnmp -lsensors -L/usr/lib/lib
/usr/lib/perl5/5.8.8/i386-linux-thread
-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -lperl -lresolv -lnsl -ldl 
-lm -lutil -lpthread -lcrypt -lc -lssl -lcrypto -lpcap -lgdbm -lgd -lpng -lz
-lwrap  -m32 -march=i386 -mtune=generi
c -Wl,-E -Wl,-rpath -Wl,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE
-Wl,-soname -Wl,libsnmpPlugin-3.2.so -o .
libs/libsnmpPlugin-3.2.so
/usr/bin/ld: cannot find -lsensors
collect2: ld returned 1 exit status
make[3]: *** [libsnmpPlugin.la] Error 1

Before it fails, there is a big warning:
*** Warning: Linking the shared library libsnmpPlugin.la against the
*** static library
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a is not
portable!




Some warnings that may be worrisome:

address.c: In function 'ipaddr2str':
address.c:516: warning: 'key_data.dptr' may be used uninitialized in this function
address.c:516: warning: 'key_data.dsize' may be used uninitialized in this function

fcUtils.c: In function 'processFcNSCacheFile':
fcUtils.c:565: warning: format '%02hx' expects type 'short unsigned int *', but
argument 3 has type 'u_int32_t *'
fcUtils.c:565: warning: format '%02hx' expects type 'short unsigned int *', but
argument 4 has type 'u_int32_t *'
fcUtils.c:565: warning: format '%02hx' expects type 'short unsigned int *', but
argument 5 has type 'u_int32_t *'

plugin.c: In function 'loadPlugins':
plugin.c:54: warning: 'prev' may be used uninitialized in this function

pbuf.c: In function 'processPacket':
pbuf.c:3153: warning: pointer targets in passing argument 2 of
'__builtin___strncpy_chk' differ in signedness
pbuf.c:3153: warning: pointer targets in passing argument 2 of '__strncpy_ichk'
differ in signedness

pbuf.c: In function 'processIpPkt':
pbuf.c:951: warning: 'off' may be used uninitialized in this function
pbuf.c:943: warning: 'snapend' may be used uninitialized in this function
pbuf.c:942: warning: 'cp' may be used uninitialized in this function
pbuf.c:944: warning: 'icmp6len' may be used uninitialized in this function

sessions.c: In function 'handleSession':
sessions.c:2550: warning: suggest parentheses around && within ||
sessions.c:2552: warning: suggest parentheses around && within ||

util.c: In function 'createThread':
util.c:1670: warning: format '%lu' expects type 'long unsigned int', but
argument 5 has type 'pthread_t *'
util.c: In function '_killThread':
util.c:1688: warning: format '%lu' expects type 'long unsigned int', but
argument 5 has type 'pthread_t *'
util.c: In function '_joinThread':
util.c:1708: warning: format '%lu' expects type 'long unsigned int', but
argument 5 has type 'pthread_t *'
util.c: In function '_accessMutex':
util.c:1796: warning: format '%s' expects type 'char *', but argument 7 has type
'void *'
util.c:1796: warning: format '%d' expects type 'int', but argument 8 has type
'char *'
util.c:1796: warning: too many arguments for format
util.c: In function '_tryLockMutex':
util.c:1870: warning: format '%s' expects type 'char *', but argument 7 has type
'void *'
util.c:1870: warning: format '%d' expects type 'int', but argument 8 has type
'char *'
util.c:1870: warning: too many arguments for format
util.c: In function '_releaseMutex':
util.c:1957: warning: format '%p' expects type 'void *', but argument 10 has
type 'pid_t'

util.c: In function 'pathSanityCheck':
util.c:3020: warning: array subscript has type 'char'
util.c: In function 'fileSanityCheck':
util.c:3093: warning: array subscript has type 'char'
util.c: In function 'ipSanityCheck':
util.c:3149: warning: array subscript has type 'char'

util.c: In function '_ntopSleepMSWhileSameState':
util.c:3950: warning: format '%u' expects type 'unsigned int', but argument 5
has type 'long unsigned int'
util.c:3968: warning: format '%d' expects type 'int', but argument 5 has type
'__time_t'
util.c:3968: warning: format '%d' expects type 'int', but argument 6 has type
'long int'
util.c: In function 'i18n_xvert_locale2common':
util.c:4252: warning: passing argument 1 of 'ntop_safestrdup' discards
qualifiers from pointer target type
util.c: In function 'i18n_xvert_acceptlanguage2common':
util.c:4277: warning: passing argument 1 of 'ntop_safestrdup' discards
qualifiers from pointer target type

util.c: In function 'convertNtopVersionToNumber':
util.c:5050: warning: format '%1[a-z' expects type 'char *', but argument 5 has
type 'unsigned char (*)[4]'

util.c: In function 'computeIdx':
util.c:266: warning: 'idx' may be used uninitialized in this function
util.c: In function 'computeTransId':
util.c:296: warning: 'transactionId' may be used uninitialized in this function
util.c: In function 'mkdir_p':
util.c:6544: warning: 'rc' may be used uninitialized in this function

traffic.c: In function 'matrixHostHash':
traffic.c:567: warning: 'hash' is used uninitialized in this function

graph.c: In function 'drawVsanStatsBytesDistribution':
graph.c:2393: warning: value computed is not used
graph.c: In function 'drawVsanStatsPktsDistribution':
graph.c:2476: warning: value computed is not used

http.c: In function '_sendStringLen':
http.c:1035: warning: type defaults to 'int' in declaration of 'econnresetcount'
http.c:1047: warning: too few arguments for format

fcReport.c: In function 'drawVsanStatsGraph':
fcReport.c:4639: warning: value computed is not used
fcReport.c: In function 'printFcTrafficSummary':
fcReport.c:4706: warning: value computed is not used
fcReport.c: In function 'makeFcHostLink':
fcReport.c:39: warning: 'linkStr' may be used uninitialized in this function

webInterface.c: In function 'initSocket':
webInterface.c:8180: warning: 'ai' may be used uninitialized in this function
webInterface.c: In function 'printNtopConfigInfoData':
webInterface.c:7089: warning: 'pT' may be used uninitialized in this function
webInterface.c:7089: warning: 'pM' may be used uninitialized in this function
webInterface.c:7087: warning: 'qT' may be used uninitialized in this function
webInterface.c:7087: warning: 'qM' may be used uninitialized in this function

ssl.c: In function 'term_ssl_connection':
ssl.c:307: warning: 'return' with no value, in function returning non-void
ssl.c:305: warning: 'rc' may be used uninitialized in this function

rrdPlugin.c: In function 'graphCounter':
rrdPlugin.c:567: warning: statement with no effect
rrdPlugin.c: In function 'netflowSummary':
rrdPlugin.c:707: warning: statement with no effect
rrdPlugin.c: In function 'graphSummary':
rrdPlugin.c:971: warning: statement with no effect

rrdPlugin.c: In function 'updateRRD':
rrdPlugin.c:1242: warning: statement with no effect
rrdPlugin.c:1298: warning: statement with no effect
rrdPlugin.c:1322: warning: format '%d' expects type 'int', but argument 5 has
type 'time_t'
rrdPlugin.c:1322: warning: format '%d' expects type 'int', but argument 7 has
type 'time_t'
rrdPlugin.c:1322: warning: format '%d' expects type 'int', but argument 9 has
type 'time_t'
rrdPlugin.c:1329: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:1329: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:1329: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:1329: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:1329: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:1329: warning: statement with no effect
rrdPlugin.c: In function 'rrdUpdateIPHostStats':
rrdPlugin.c:2835: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:2835: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:2835: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:2835: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:2835: warning: statement with no effect
rrdPlugin.c:2920: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:2920: warning: left-hand operand of comma expression has no effect
rrdPlugin.c:2920: warning: statement with no effect
.... many other similar

rrdPlugin.c: In function 'rrdTrafficThreadLoop':
rrdPlugin.c:3081: warning: control reaches end of non-void function
rrdPlugin.c: In function 'handleRRDHTTPrequest':
rrdPlugin.c:384: warning: 'total' may be used uninitialized in this function

snmpPlugin.c: In function 'createAnswer':
snmpPlugin.c:739: warning: format '%d' expects type 'int', but argument 5 has
type 'oid'

snmpPlugin.c: In function 'processRequest':
snmpPlugin.c:833: warning: pointer targets in assignment differ in signedness

snmpPlugin.c: In function 'processRequest':
snmpPlugin.c:788: warning: 'size' may be used uninitialized in this function
snmpPlugin.c:787: warning: 'cp' may be used uninitialized in this function 



Comment 20 Patrice Dumas 2006-12-14 16:19:33 UTC
(In reply to comment #17)

> I'm unable to reproduce this.  Try loading the debug symbols and getting a
> backtrace under gdb.

I don't know how to do that. I start with gdb, enters the pasword,
and then hit ctrl-C, but then gdb catch the signal:

jeu 14 déc 2006 17:17:06 CET  THREADMGMT[t3018537872]: NPS(1,eth0): pcapDispatch
thread running [p12392]

Program received signal SIGINT, Interrupt.
[Switching to Thread -1209092416 (LWP 12392)]
0x001d6402 in __kernel_vsyscall ()
(gdb)

What should I do now?


Comment 21 Mamoru TASAKA 2006-12-14 16:29:40 UTC
(In reply to comment #20)
> (In reply to comment #17)
> 
> > I'm unable to reproduce this.  Try loading the debug symbols and getting a
> > backtrace under gdb.
> 
> I don't know how to do that. I start with gdb, enters the pasword,
> and then hit ctrl-C, but then gdb catch the signal:
> 
> jeu 14 déc 2006 17:17:06 CET  THREADMGMT[t3018537872]: NPS(1,eth0): pcapDispatch
> thread running [p12392]
> 
> Program received signal SIGINT, Interrupt.
> [Switching to Thread -1209092416 (LWP 12392)]
> 0x001d6402 in __kernel_vsyscall ()
> (gdb)
> 
> What should I do now?
> 

I don't checked 3.2-6, however, what happens if you try
(gdb) handle SIGINT nonstop print pass
?



Comment 22 Mamoru TASAKA 2006-12-14 16:31:16 UTC
Sorry: the correct one is:

(gdb) handle SIGINT nostop print pass
not "nonstop".


Comment 23 Patrice Dumas 2006-12-14 17:09:00 UTC
Thanks, I got a backtrace. It isn't very reproducible. Sometimes
it segfaults, and sometimes it shutdowns gracefully. It is not only
during the first run but anytime.

Comment 24 Patrice Dumas 2006-12-14 17:10:47 UTC
Created attachment 143662 [details]
backtrace from the segfault

Comment 25 Bernard Johnson 2006-12-14 21:51:33 UTC
(In reply to comment #19)
> There is a missing BR on net-snmp-devel. After net-snmp-devel is 
> installed, build fails with:
> /usr/bin/ld: cannot find -lsensors

You'll need to put lm_sensors-devel in your BR as well.  I'll fix this in the
next version.

> Before it fails, there is a big warning:
> *** Warning: Linking the shared library libsnmpPlugin.la against the
> *** static library
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a is not
> portable!

I don't believe that this is relevent as we nuke libtool archives anyway.

> Some warnings that may be worrisome:
I'll try to look into some of these, but don't have time for a full code review.

Comment 26 Ralf Corsepius 2006-12-15 07:21:51 UTC
(In reply to comment #25)

> > Before it fails, there is a big warning:
> > *** Warning: Linking the shared library libsnmpPlugin.la against the
> > *** static library
> > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a is not
> > portable!
> 
> I don't believe that this is relevent as we nuke libtool archives anyway.
Only partially correct. 

This is libtool warning you about this package doing something non-portable:
Linking a shared library against a static.

This warning is largely irrelevant when building on Linux, because linking a
shared against a static library basically (i.e. in most cases) is possible on Linux.

Whether this warning is related to the breakdown is a different question, and
should be analyzed. It's rather unlikely, but it could be an indication of ntop
not being ready for dynamic linkage.

All removing the *.la would do, is to silence the warning, it would not change
anything about ntop potentially doing something "naughty".



Comment 27 Bernard Johnson 2006-12-15 07:39:38 UTC
(In reply to comment #26)
> (In reply to comment #25)
> 
> > > Before it fails, there is a big warning:
> > > *** Warning: Linking the shared library libsnmpPlugin.la against the
> > > *** static library
> > > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a
is not
> > > portable!
> > 
> > I don't believe that this is relevent as we nuke libtool archives anyway.
> Only partially correct. 

Understood, but I'd like to point out that if you google search this error,
you'll find that this is not the only package that suffers from this.  As one
site puts it - it's a result of perl's crappy dynamic linking/loading facilities.

In fact, FE's own xchat suffers from it.  Here is a recent build log of xchat in
the build system:
http://buildsys.fedoraproject.org/logs/fedora-development-extras/23222-xchat-gnome-0.15-2.fc7/i386/build.log
You can find an almost identical warning there.

I'm not saying it's ok, just probably not the end of the world.

Comment 28 Bernard Johnson 2006-12-15 12:02:50 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-7.fc6.src.rpm

%changelog
* Thu Dec 14 2006 Bernard Johnson <bjohnson> - 3.2-7
- add missing net-snmp-devel, and lm_sensors-devel BR


There are no other fixes in this package.  I won't be able to update it again
until around the first of the year, but please post any relevent comments
regarding your experience or recommendations.

Comment 29 Mamoru TASAKA 2007-01-09 16:23:17 UTC
Well, time to review this again as a new year came.

Assuming that the newest srpm is 3.2-7, I will check
this package again.

Comment 30 Mamoru TASAKA 2007-01-10 16:43:08 UTC
Well, let's start again.

Well, for 3.2-7:

* Conditional dependencies:

  - Mockbuild log (on FC-devel i386) says:
----------------------------------------
checking security/pam_appl.h usability... no
checking security/pam_appl.h presence... no
----------------------------------------
    These are included in pam-devel.

*******************************************************************
*
* WARNING:  One or more items required for the xmldump plugin are 
*           missing:
*
*                  libxml2.so or libxml2.a...yes
*                  gdome.h...yes
*                  libgdome.so or libgdome.a...yes
*                  glib.h...yes
*                  libglib.so or libglib.a...no
*                  glibconfig.h...yes
*
*           (yes means it was found, no means it was not found)
*
*       ntop will run just fine without this plugin.
*
*>>>    If you want to use the xmldump plugin,
*
*???     1. Install the necessary headers and libraries.
*???    and rerun ./configure
*
*******************************************************************
     libglib.so is included in glib-devel.

* BuildRequires:
--------------------------------------------------------
redundant package <= package which requires it
tcp_wrappers         net-snmp-devel
autoconf             automake
automake             libtool 
     (However, I don't mind if you want to write "automake"
      explicitly)
pkgconfig            glib2-devel
glib2-devel          gdome2-devel
--------------------------------------------------------

* Encoding:
---------------------------------------------------------
/usr/share/doc/ntop-3.2/ChangeLog:  ISO-8859 English text
---------------------------------------------------------
  - Please change the encoding to UTF-8.

* For SEGV issue Patrice saw:
  Oh, I got SEGV, too! However, not completely reproducible,
  however, for me this happens at the same point at last.

  One example:
----------------------------------------------------------
Program received signal SIGABRT, Aborted.
[Switching to Thread -1273857136 (LWP 20547)]
0x00f58402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00f58402 in __kernel_vsyscall ()
#1  0x00bd8c70 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x00bda4c1 in *__GI_abort () at abort.c:88
#3  0x00c0e29b in __libc_message (do_abort=2, 
    fmt=0xcd21c4 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#4  0x00c15e29 in _int_free (av=0xcfc120, mem=0x82e67a0) at malloc.c:5774
#5  0x00c19650 in *__GI___libc_free (mem=0x82e67a0) at malloc.c:3552
#6  0x00f726cc in ntop_safefree (ptr=0x81d6154, file=0xfaa9fc "util.c",
line=2601) at leaks.c:188
#7  0x00f964b9 in traceEvent (eventTraceLevel=3, file=0xfa73fd "ntop.c", line=136, 
    format=0xfa7d40 "THREADMGMT[t%lu]: NPS(%d,%s): pcapDispatch thread
terminated [p%d]")
    at util.c:2601
#8  0x00f75a62 in pcapDispatch (_i=0x0) at ntop.c:136
#9  0x00d382db in start_thread (arg=0xb4127b90) at pthread_create.c:296
#10 0x00c7d24e in clone () from /lib/libc.so.6
----------------------------------------------------------

    And.. in util.c:
----------------------------------------------------------
  2598        }
  2599  
  2600        if (myGlobals.logView[myGlobals.logViewNext] != NULL)
  2601          free(myGlobals.logView[myGlobals.logViewNext]); <- PROBLEM
HAPPENED HERE!!
  2602  
  2603        myGlobals.logView[myGlobals.logViewNext] = strdup(buf);
  2604  
  2605        myGlobals.logViewNext = (myGlobals.logViewNext + 1) %
CONST_LOG_VIEW_BUFFER_SIZE;
  2606  
  2607        if(myGlobals.logViewMutex.isInitialized) {
----------------------------------------------------------
    It seems that myGlobals.logView is not initialized correctly
    by NULL.

Comment 31 Bernard Johnson 2007-01-12 18:52:38 UTC
(In reply to comment #30)
> * For SEGV issue Patrice saw:
>   Oh, I got SEGV, too! However, not completely reproducible,
>   however, for me this happens at the same point at last.
>

On Dec 4, the author stated that he would soon be working towards a 3.3 release.
 Perhaps we should pull the CVS-current and start working with that as some of
these problems may be resolved.  Thoughts?

Comment 33 Mamoru TASAKA 2007-01-13 18:14:41 UTC
Well, I want to check CVS accroding to your comment 32
and as I can see many changes between 3.2 -> cvs 071111.
Would you package cvs version?

However, I am afraid that as long as I check the diff
of util.c, the bug I pointed out on comment 30 doesn't seem
to be fixed......

Comment 34 Mamoru TASAKA 2007-01-14 15:46:51 UTC
NOTIFICATION:

Currently gdome2 is orphaned, which means that no one
maintains gdome2, and if ntop requires gdome2 a new 
maintainer is needed.

Comment 35 Bernard Johnson 2007-01-26 21:28:32 UTC
(In reply to comment #33)
> Well, I want to check CVS accroding to your comment 32
> and as I can see many changes between 3.2 -> cvs 071111.
> Would you package cvs version?
> 
> However, I am afraid that as long as I check the diff
> of util.c, the bug I pointed out on comment 30 doesn't seem
> to be fixed......

It took awhile to figure out that gmane is just broken and can't post to the
ntop mailing list - so I subscribed and sent a message to follow up with this bug.

http://permalink.gmane.org/gmane.linux.ntop.devel/6445

Comment 36 Bernard Johnson 2007-01-26 21:29:52 UTC
(In reply to comment #34)
> NOTIFICATION:
> 
> Currently gdome2 is orphaned, which means that no one
> maintains gdome2, and if ntop requires gdome2 a new 
> maintainer is needed.

If ntop is worked into acceptable shape, I can pick up ownership of gdome2 as well.

Comment 37 Mamoru TASAKA 2007-01-29 18:13:19 UTC
(removing NEEDSPONSOR as bug 216723)

Comment 38 Bernard Johnson 2007-02-05 18:23:46 UTC
The author replied to me privately and offered to help this process along.  He
also said that he expects to release 3.3 in a few weeks.  Since this is the
case, I'll bump the rpm to the CVS version.

Comment 39 Bernard Johnson 2007-02-06 08:45:26 UTC
Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.2-8.1.20060206cvs.fc6.src.rpm

* Mon Feb 05 2007 Bernard Johnson <bjohnson> - 3.2-8.1.20060206cvs
- update to cvs 20060206
- update ntop-am.patch for cvs version
- get rid of plugins patch and just remove cruft in spec file


Already noted problems to fix:
- lots of "linker input file unused because linking not done" messages during
build - need to be tracked down
- snmp plugin won't load because of undefined symbol: netsnmp_extract_table_info


Mamoru/Patrice -

Please see if this version gives you a SEGV as well.  If it does please post a
backtrace here.

Comment 40 Mamoru TASAKA 2007-02-07 13:20:39 UTC
(In reply to comment #36)
> (In reply to comment #34)
> > NOTIFICATION:
> > 
> > Currently gdome2 is orphaned, which means that no one
> > maintains gdome2, and if ntop requires gdome2 a new 
> > maintainer is needed.
> 
> If ntop is worked into acceptable shape, 
> I can pick up ownership of gdome2 as well.

Well, currently gdome2 is orphaned and removed from FC/E-devel
tree and I cannot rebuild your srpm because I am using FC-devel.

So:
* If you want to use gdome2, please take over gdome ownership
  first. You are already in cvsextras (as I am sponsoring you)
  and you can do this.
  For this, you should post to fedora-extras list as "I want to
  take over gdome2". Please check:
  http://fedoraproject.org/wiki/Extras/OrphanedPackages
* Or, if this package works without gdome2, you may disable
  gdome2 support for a moment (in this case please upload a
  new srpm/spec).



Comment 41 Mamoru TASAKA 2007-02-15 09:17:24 UTC
Well, it seems that no one disagrees your taking over
gdome2 maintainership, so please do so.

* You have to fill up
  http://fedoraproject.org/wiki/Extras/CVSSyncNeeded
  to have owners.list fixed by cvsadmin.
* After cvsadmin changes owners.list, rebuild gdome2 on
  FE-devel again (with release number incremented)
* And you have to remove gdome from
  http://fedoraproject.org/wiki/Extras/OrphanedPackages

After that I will restart to review ntop again.

Comment 42 Mamoru TASAKA 2007-02-19 13:28:53 UTC
Bernard, now gdome2 maintainer is you.

Would you rebuild gdome2 with release number incremented
and with adding some fixes if you want and rebuild gdome2
for FE-devel?

Comment 43 Bernard Johnson 2007-02-19 16:43:49 UTC
(In reply to comment #42)
> Bernard, now gdome2 maintainer is you.

I just submitted a build of gdome2 for devel, so it will probably appear
tomorrow, unless you are using the buildsys repo.

Also, here is later build of ntop.  Starting with the rc0 of ntop, it would not
build for me.  There were big updates to the autotools configurations.  I didn't
understand why it wasn't building so I did a bi-section of the changes.  Now I
have a patch that will make it build, but honestly, I'm not sure why it works. 
If you wouldn't mind, take a look at shrext.patch.  If I don't apply this small
patch on my system to reverse part of the changes, the build will fail on my system.


Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.1.20060218cvs.fc6.src.rpm

* Wed Feb 18 2007 Bernard Johnson <bjohnson> - 3.3-0.1.20060218cvs
- update to ntop cvs 20060208

* Wed Feb 07 2007 Bernard Johnson <bjohnson> - 3.3-0.1.20060207cvs
- update to ntop cvs 20060207
- remove gdbm, pidfile, and FEDORAextra patches
- ntopdump.dtd has fixed eol markers now
- update nolibs patch so there is no complaint about xmldump libraries/headers



Comment 44 Mamoru TASAKA 2007-02-19 17:46:25 UTC
Created attachment 148350 [details]
mock build log of 3.3-0.2.20060218cvs.fc7

mockbuild succeeded on FC7 i386, install succeeded,
however I have not checked this at all and I will go to
sleep for now...

Comment 45 Mamoru TASAKA 2007-02-20 13:08:48 UTC
Well, for 0.2.20060218cvs:

* cvs custom
  - Well, it is a custom when using CVS source to do
    in %prep stage:
----------------------------------------------------
find . -name CVS | sort -r | xargs rm -rf
----------------------------------------------------
    to avoid cvs stuff accidentally installed.

* BuildRequires:
  - On FC-devel, tcp_wrapper-devel is already out
    (anyway tcp_wrapper-devel is required by net-snmp-devel
     so this is redundant. However, it is not bad to write
     explicitly "tcp_wrapper-devel" BuildRequires because
     configure explicitly requires this for one of the
     options). You may write
----------------------------------------------------
%if 0%{?fedora} >= 7
Requires: tcp_wrappers-devel
%else
Requires: tcp_wrappers
%endif
----------------------------------------------------
   - BR: glib2-devel is redundant. gdome2-devel requires it.

* Documentation-seeming files
  - By the way, are the files under /usr/share/ntop/html always
    required by this package?

Well, I tested Ctrl-C interrupt for about 30 times, and this
time segv didn't occur.

I want to approve this package after the issues above are
resolved and after I check some other issues (which takes some
time to be checked).

Comment 46 Mamoru TASAKA 2007-02-20 13:25:47 UTC
Well,
* License
  - A issue is found.
    * html/domLib.js
      html/domTT.js 
      - Apache License, Version 2.0, incompatible with GPL
        (according to http://www.gnu.org/philosophy/license-list.html)

Comment 47 Bernard Johnson 2007-02-20 15:34:27 UTC
(In reply to comment #45)
> find . -name CVS | sort -r | xargs rm -rf

Forgot to put this back in when I switched back to CVS version.  next rel.

> * BuildRequires:
>   - On FC-devel, tcp_wrapper-devel is already out

fixed next rel.

>    - BR: glib2-devel is redundant. gdome2-devel requires it.

fixed next rel.
 
> * Documentation-seeming files
>   - By the way, are the files under /usr/share/ntop/html always
>     required by this package?

yes, they are used by the web server
 
> Well, I tested Ctrl-C interrupt for about 30 times, and this
> time segv didn't occur.

good!

> I want to approve this package after the issues above are
> resolved and after I check some other issues (which takes some
> time to be checked).

I need to go back through it again as well and make sure some of the odd things
I was seeing are no longer happending.

Comment 48 Bernard Johnson 2007-02-20 15:37:38 UTC
(In reply to comment #46)
> Well,
> * License
>   - A issue is found.
>     * html/domLib.js
>       html/domTT.js 
>       - Apache License, Version 2.0, incompatible with GPL
>         (according to http://www.gnu.org/philosophy/license-list.html)

I'm looking into this.  I was just about to contact the author, but it appears
that these files are not actively used (ie. they are loaded into the html pages,
but no functionality is used).  If that is true, I'll see if I can patch them out.


Comment 49 Bernard Johnson 2007-02-21 00:39:45 UTC
So here is the response regarding Legal issues that I got from someone on the
mailing list:

>
> Another data point:
> 
> http://www.apache.org/licenses/GPL-compatibility.html
> 
> I'm not sure that we really have a problem here.
>

I'm setting the blocker for FE-Legal until this is resolved.

Comment 50 Bernard Johnson 2007-02-21 21:13:53 UTC
Created attachment 148534 [details]
Proposed patch to remove Apache 2 licensed material - if needed

Comment 51 Jason Tibbitts 2007-02-26 15:12:02 UTC
This is nuts; the presense of files with different licenses in a single packages
is perfectly fine as long as all of those files are used in accordance with
their licenses.  Sure, you can't derive a GPL work from one with the Apache
License v2; you can't take a piece of a GPL program and use it in an ASL2
program, nor can you do the reverse, but that's not what's being done here.  The
files are merely being aggregated, and the GPL is clear about "mere aggregation".


Comment 52 Mamoru TASAKA 2007-02-26 17:09:20 UTC
Thanks, Jason.

Removing FE-legal, so would you fix the package according
to my comment 45?

Comment 53 Patrice Dumas 2007-02-26 19:17:25 UTC
(In reply to comment #51)
> This is nuts; the presense of files with different licenses in a single packages
> is perfectly fine as long as all of those files are used in accordance with
> their licenses.  Sure, you can't derive a GPL work from one with the Apache
> License v2; you can't take a piece of a GPL program and use it in an ASL2
> program, nor can you do the reverse, but that's not what's being done here.  The
> files are merely being aggregated, and the GPL is clear about "mere aggregation".

I have seen interpretations of what is mere aggregation and derived 
work that don't follow that one. I have seen somewhere that being 
in the same tarball was not mere aggregation but derived work. 
In fact, still if I recall well it is the court that would settle 
that. Considering that files in the same tarball should have 
compatible license would put us on the safe side. However if 
the authors of the 2 pieces of software are the same people then 
it is not that problematic, since the
author would have to attack himself. The issue in that case is 
that a court may rule that both license cannot apply to the 
package. 

As a disclaimer, I have to add that I am not a lawyer and I may 
be completely wrong.

Comment 54 Jason Tibbitts 2007-02-26 20:14:13 UTC
I fail to comprehend how aggregating within a tarball would be bad, while
aggregating within an ISO file (as Fedora does today) would be acceptable.

I think that if we actually keep a package out of Fedora because of crazy
interpretations such as this then we truly have lost the plot.

Comment 55 Patrice Dumas 2007-02-26 21:14:48 UTC
(In reply to comment #54)
> I fail to comprehend how aggregating within a tarball would be bad, while
> aggregating within an ISO file (as Fedora does today) would be acceptable.

Because the tarball is what demarcate what is a given software.

> I think that if we actually keep a package out of Fedora because of crazy
> interpretations such as this then we truly have lost the plot.

I am not saying that we should do that, the 2 programs here are
clearly distinct (I mean, js code and ntop are distinct programs) 
so mere aggregation may be the right interpretation.

If I recall well, debian people consider that files in the same
tarball or package should have compatible licenses, but we are not
forced to do the same.

Comment 56 Bernard Johnson 2007-02-28 08:05:45 UTC
Here is an update, but note:
1) Ntop is terminating on my system after 5-20 minutes.
2) javascript generated graphics are not displaying on my system (I don't know
if this is a code problem or something with my browser at the moment).


Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.3.20060227cvs.fc6.src.rpm

* Tue Feb 27 2007 Bernard Johnson <bjohnson> - 3.3-0.3.20060227cvs
- update to ntop cvs 20060227
- kill all the CVS files/directories
- remove glib2-devel BR because gdome2-devel requires it
- tcp_wrappers vs. tcp_wrappers-devel no dependent on os release
- add initscripts to requires since init file uses daemon function
- patch .so files to just version 3.3 not 3.3rc0; otherwise rpmlint complains
- fix typo in init file

Comment 57 Mamoru TASAKA 2007-02-28 15:43:29 UTC
Well, now I am trying to update my rawhide system and
I think this may take long because around 300 (or more?)
update packages are released.... 

Comment 58 Mamoru TASAKA 2007-03-02 15:54:34 UTC
(In reply to comment #56)
> Here is an update, but note:
> 1) Ntop is terminating on my system after 5-20 minutes.
I ran for about 11 hours but no problem occurred...

> 2) javascript generated graphics are not displaying on my system
I am not familiar with javascript...
I will review this later. Please wait...

Comment 59 Mamoru TASAKA 2007-03-02 17:27:37 UTC
Well, for 3.3-0.3.20060227cvs.fc7:

* conditional dependency (check again...)
----------------------------------------------
checking for pcre_refcount in -lpcre... no
----------------------------------------------
  - Perhaps adding "BuildRequires: pcre-devel" will
    change this to yes.

----------------------------------------------
checking security/pam_appl.h usability... no
checking security/pam_appl.h presence... no
----------------------------------------------
   - Perhaps pam-devel

----------------------------------------------
checking for i686-redhat-linux-gnu-mysql_config... no
checking for mysql_config... no
----------------------------------------------
   - mysql-devel or so?

* Unused source?
  - What is Source4?

Comment 60 Bernard Johnson 2007-03-02 23:04:24 UTC
(In reply to comment #59)
> Well, for 3.3-0.3.20060227cvs.fc7:
> 
> * conditional dependency (check again...)
> ----------------------------------------------
> checking for pcre_refcount in -lpcre... no
> ----------------------------------------------
>   - Perhaps adding "BuildRequires: pcre-devel" will
>     change this to yes.
>

This can be used for pattern matching of incoming payloads, so I have enabled it.

> ----------------------------------------------
> checking security/pam_appl.h usability... no
> checking security/pam_appl.h presence... no
> ----------------------------------------------
>    - Perhaps pam-devel
> 
> ----------------------------------------------

I looked at the code and all this would give is the ability of the web interface
to display that you have pam_appl.h available.  It doesn't use it anywhere else
that I can find.  

> checking for i686-redhat-linux-gnu-mysql_config... no
> checking for mysql_config... no
> ----------------------------------------------
>    - mysql-devel or so?

This can be used for longer term storage of net flow data, so I've enabled it,
and added mysql-server as a requires.


> * Unused source?
>   - What is Source4?

Not currently used.  I was looking for a better way to set the ntop password,
but I didn't finish this.  I removed it.


Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.4.20060227cvs.fc6.src.rpm

* Fri Mar 02 2007 Bernard Johnson <bjohnson> - 3.3-0.4.20060227cvs
- add pcre-devel to BR so payloads can be matched
- remove unused Source4 line
- enabled mysql storage of net flow data



Comment 61 Mamoru TASAKA 2007-03-03 05:06:02 UTC
Okay.

---------------------------------------------
  This package (ntop) is APPROVED by me.
---------------------------------------------

Comment 62 Bernard Johnson 2007-03-03 09:55:32 UTC
(In reply to comment #58)
> > 2) javascript generated graphics are not displaying on my system
> I am not familiar with javascript...
> I will review this later. Please wait...

Are the javascript graphs working for you?

Comment 63 Patrice Dumas 2007-03-03 10:01:06 UTC
I think that this package cannot be approved as-is since there
is no way to check the source. At least a comment is missing
giving the command line that allows to recreate the tarball
such that it is easy to recreate it and make a diff.


Suggestion: prefix then new patches with ntop, like
ntop-shrext.patch
ntop-remove-rc0.patch

Comment 64 Mamoru TASAKA 2007-03-03 10:41:03 UTC
(In reply to comment #62)
> Are the javascript graphs working for you?
I don't know. I am less familiar with ntop than you and
I don't know well about javascript.

(In reply to comment #63)
> I think that this package cannot be approved as-is since there
> is no way to check the source. At least a comment is missing
> giving the command line that allows to recreate the tarball
> such that it is easy to recreate it and make a diff.
Simply, "To get source by cvs, check http://www.ntop.org/download.html"
is okay for _minimal_ explanation. 

> Suggestion: prefix then new patches with ntop,
I leave this to packager.

Anyway I won't get this review back to cvs-review?.

Comment 65 Patrice Dumas 2007-03-03 11:11:11 UTC
(In reply to comment #64)
> (In reply to comment #63)
> > I think that this package cannot be approved as-is since there
> > is no way to check the source. At least a comment is missing
> > giving the command line that allows to recreate the tarball
> > such that it is easy to recreate it and make a diff.
> Simply, "To get source by cvs, check http://www.ntop.org/download.html"
> is okay for _minimal_ explanation. 

Of course it is still possible to find out how to get the 
source tarball oneself, but it is far easier if the submitter
helps. It is in the guidelines now:

http://fedoraproject.org/wiki/Packaging/SourceURL#head-615f6271efb394ab340a93a6cf030f2d08cf0d49

No problem for me if you find that acceptable, though.
 
> > Suggestion: prefix then new patches with ntop,
> I leave this to packager.

That's a suggestion, it means that I think it is to be left
to the packager.

Comment 66 Patrice Dumas 2007-03-03 11:17:32 UTC
* rpmlint on installed package gives a lot of warnings, showing 
unneeded linking and missing linking. It is certainly more an upstream
issue, though.

* there is a rpmlint warning:
W: ntop non-standard-dir-in-var ntop
I think it would be better if ntop wasn't directly under /var, but
maybe under /var/lib/. Still may be more an upstream issue.

* are
/usr/lib/libicmpPlugin-3.3.so
/usr/lib/liblastSeenPlugin-3.3.so
/usr/lib/libnetflowPlugin-3.3.so
/usr/lib/libpdaPlugin-3.3.so
/usr/lib/libremotePlugin-3.3.so
/usr/lib/librrdPlugin-3.3.so
/usr/lib/libsflowPlugin-3.3.so
/usr/lib/libsnmpPlugin-3.3.so
/usr/lib/libxmldumpPlugin-3.3.so
useful?


Comment 67 Patrice Dumas 2007-03-03 13:23:03 UTC
Also is the 
Requires: mysql-server
really needed? I have tested without having mysql-server and it 
seems to work right.

Comment 68 Patrice Dumas 2007-03-03 13:45:47 UTC
When running ntop, I get in logs:

Database support not compiled into ntop

That's strange. Maybe a configure flag missing?

During run, there are many error messages like these ones:
**WARNING** RRD: rrd_create(/var/ntop/rrd/interfaces/eth0/throughput.rrd) error:
Invalid alpha: must be between 0 and 1
**WARNING** RRD: rrd_update(/var/ntop/rrd/interfaces/eth0/throughput.rrd) error:
opening '/var/ntop/rrd/interfaces/eth0/throughput.rrd': (null)

with the file name changing

I also get
 **WARNING** Unable to open file /var/ntop/rrd/graphics/1172875647-4.png -
graphic not sent
EPIPE during sending of page to web client

I guess all this stems from the same issue. Maybe a directory
with wrong permissions (ie root and not ntop?) Looking at
/var/ntop/rrd I don't see anything wrong, though:

# ls -lR /var/ntop/rrd
/var/ntop/rrd:
total 12
drwxrwx--- 2 root ntop 4096 mar  3 11:13 flows
drwxrwx--- 2 root ntop 4096 mar  3 11:13 graphics
drwxrwx--- 3 root ntop 4096 mar  3 11:56 interfaces

/var/ntop/rrd/flows:
total 0

/var/ntop/rrd/graphics:
total 0

/var/ntop/rrd/interfaces:
total 4
drwx------ 3 ntop ntop 4096 mar  3 12:01 eth0

/var/ntop/rrd/interfaces/eth0:
total 4
drwx------ 7 ntop ntop 4096 mar  3 12:11 AS

/var/ntop/rrd/interfaces/eth0/AS:
total 20
drwx------ 2 ntop ntop 4096 mar  3 12:01 12322
drwx------ 2 ntop ntop 4096 mar  3 12:06 137
drwx------ 2 ntop ntop 4096 mar  3 12:01 2200
drwx------ 2 ntop ntop 4096 mar  3 12:11 22753
drwx------ 2 ntop ntop 4096 mar  3 12:01 2422

/var/ntop/rrd/interfaces/eth0/AS/12322:
total 0

/var/ntop/rrd/interfaces/eth0/AS/137:
total 0

/var/ntop/rrd/interfaces/eth0/AS/2200:
total 0

/var/ntop/rrd/interfaces/eth0/AS/22753:
total 0

/var/ntop/rrd/interfaces/eth0/AS/2422:
total 0

That may be linked with the fact that I don't graphs on the interface
where the rrd graphs should be.

Comment 69 Bernard Johnson 2007-03-03 14:09:23 UTC
Until I can confirm that the javascript is working correctly (this broke between
3.2 and cvs best I can tell), I'm not going to put this in fedora cvs.  Since
I'm traveling next week, it might be awhile.

This release resolves the comments from Patrice, except regarding /var/ntop. 
I'll look into that when I get a chance, it does seem logical that it should be
/var/lib/ntop.

(I see you also posted comment #68, which this doesn't account for)


Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.5.20060227cvs.fc6.src.rpm

* Sat Mar 03 2007 Bernard Johnson <bjohnson> - 3.3-0.5.20060207cvs
- prefix patches with ntop-
- explanation on how to retrieve cvs source
- fix removal of %%{_libdir}/.so plugin files no matter the version
- reduce dependency on mysql-server to just mysql


Comment 70 Bernard Johnson 2007-03-03 14:21:58 UTC
(In reply to comment #68)
> Database support not compiled into ntop
> That's strange. Maybe a configure flag missing?

I thought it picked it up with configure, but I have to give it --enable-mysql,
so I'll add that.



> During run, there are many error messages like these ones:
> **WARNING** RRD: rrd_create(/var/ntop/rrd/interfaces/eth0/throughput.rrd) error:
> Invalid alpha: must be between 0 and 1
> **WARNING** RRD: rrd_update(/var/ntop/rrd/interfaces/eth0/throughput.rrd) error:
> opening '/var/ntop/rrd/interfaces/eth0/throughput.rrd': (null)
> 
> with the file name changing
> 
> I also get
>  **WARNING** Unable to open file /var/ntop/rrd/graphics/1172875647-4.png -
> graphic not sent
> EPIPE during sending of page to web client
> 
> I guess all this stems from the same issue. Maybe a directory
> with wrong permissions (ie root and not ntop?) Looking at
> /var/ntop/rrd I don't see anything wrong, though:
> 
> # ls -lR /var/ntop/rrd
> /var/ntop/rrd:
> total 12
> drwxrwx--- 2 root ntop 4096 mar  3 11:13 flows
> drwxrwx--- 2 root ntop 4096 mar  3 11:13 graphics
> drwxrwx--- 3 root ntop 4096 mar  3 11:56 interfaces
> 
> /var/ntop/rrd/flows:
> total 0
> 
> /var/ntop/rrd/graphics:
> total 0
> 
> /var/ntop/rrd/interfaces:
> total 4
> drwx------ 3 ntop ntop 4096 mar  3 12:01 eth0
> 
> /var/ntop/rrd/interfaces/eth0:
> total 4
> drwx------ 7 ntop ntop 4096 mar  3 12:11 AS
> 
> /var/ntop/rrd/interfaces/eth0/AS:
> total 20
> drwx------ 2 ntop ntop 4096 mar  3 12:01 12322
> drwx------ 2 ntop ntop 4096 mar  3 12:06 137
> drwx------ 2 ntop ntop 4096 mar  3 12:01 2200
> drwx------ 2 ntop ntop 4096 mar  3 12:11 22753
> drwx------ 2 ntop ntop 4096 mar  3 12:01 2422
> 
> /var/ntop/rrd/interfaces/eth0/AS/12322:
> total 0
> 
> /var/ntop/rrd/interfaces/eth0/AS/137:
> total 0
> 
> /var/ntop/rrd/interfaces/eth0/AS/2200:
> total 0
> 
> /var/ntop/rrd/interfaces/eth0/AS/22753:
> total 0
> 
> /var/ntop/rrd/interfaces/eth0/AS/2422:
> total 0
> 
> That may be linked with the fact that I don't graphs on the interface
> where the rrd graphs should be.

I'm not having these errors on my system.  Are you sure ntop is running as
"ntop" and not another id?

Comment 71 Mamoru TASAKA 2007-03-03 15:57:19 UTC
(In reply to comment #69)
> Since
> I'm traveling next week, it might be awhile.

Well, I don't like a approved request left open without any activity,
so I pull back to "currently reviewing"

Comment 72 Patrice Dumas 2007-03-03 16:43:15 UTC
(In reply to comment #70)
> (In reply to comment #68)
> > Database support not compiled into ntop
> > That's strange. Maybe a configure flag missing?
> 
> I thought it picked it up with configure, but I have to give it --enable-mysql,
> so I'll add that.

It won't be that simple. In fact upon reading configure.in, I have found 
that:

* --enable/disable-mysql setting is ignored.

* mysql support isn't compiled in because mysql.h isn't found. And 
  it isn't found for 2 reasons. First it isn't searched for because
  if the mysql lib is found mysql support isn't used.
  The second reason is that it uses INCS to store the include flags 
  but this variable isn't used when compiling autoconf tests. it 
  should be CPPFLAGS instead.

* instead of mysql_config --cflags, mysql_config --include should be used.

I'll attach a patch that solves all those issues.

I also have remarked another things that is very broken: for
snmp net-snmp-config --cflags gives a lot of junk, although 
nothing at all is needed on fedora. For that I suggest just 
patching the configure.

> I'm not having these errors on my system.  Are you sure ntop is running as
> "ntop" and not another id?

It is what is said in the log. And I start it with the init
script. It only happens when I click on the interface.


Comment 73 Patrice Dumas 2007-03-03 16:44:53 UTC
Created attachment 149182 [details]
fix mysql detection

Comment 74 Patrice Dumas 2007-03-03 16:47:37 UTC
Created attachment 149183 [details]
don't use the output of  net-snmp-config --cflags

I haven't tested that patch.

If not using cvs version I suggest patching configure 
instead.

Comment 75 Patrice Dumas 2007-03-03 16:50:43 UTC
I think that once ntop is linked against mysql, mysql
will be put automatically as a dependency since ntop 
should depend on libmysqlclient_r.so.15.

Comment 76 Bernard Johnson 2007-03-08 05:22:07 UTC
(In reply to comment #75)
> I think that once ntop is linked against mysql, mysql
> will be put automatically as a dependency since ntop 
> should depend on libmysqlclient_r.so.15.

Patrice, the author snagged your patches and included them in current cvs.  I
just updated the rpm to the latest cvs and fixed the javascript display problems.

I still don't see rpm pulling in libsqlclient as a dependency.

IMPORTANT:  I also moved the ntop data directory from /var/ntop to
/var/lib/ntop, so be aware of this changing.

Next updates will be in approximately a week.

Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.8.20070307cvs.fc6.src.rpm

* Mon Mar 07 2007 Bernard Johnson <bjohnson> - 3.3-0.8.20070307cvs
- update to 20070307cvs
- move database files to %%{_localstatedir}/lib/ntop
- fix javascript files not being installed
- remove x bit from additional javascript files

Comment 77 Patrice Dumas 2007-03-11 00:03:12 UTC
The patches look sane except that 
ntop-config.patch
and
ntop-conf.patch
seems to patch the same file one after another. And moreover
those patches seems to be unuseful since you overwrite the file?

I suggest using the 'official scriptlets' found here:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
Yours don't seem wrong, it is for consistency. Using
/sbin/service may be more robust over time, however.
It adds a 
Requires(preun): /sbin/service

Build log looks saner, but there is still a duplication of the 
CFLAGS. In my opinion it comes from Makefile.am, the following
line should be removed (at least @CFLAGS@ should be removed):

AM_CFLAGS = @CFLAGS@


In the init file, maybe add the LSB bits? (within BEGIN INIT INFO)

still in the init file the summary is a bit terse.



Comment 78 Patrice Dumas 2007-03-11 00:05:25 UTC
Created attachment 149782 [details]
fix enable-mysql handling

The handling of --enable-mysql is broken, should be
fixed with that patch (for upstream).

Comment 79 Patrice Dumas 2007-03-11 00:24:27 UTC
I still see the same errors than above. As a side note, i 
have noticed that the perms for /var/lib/ntop itself is:

# ls -l /var/lib/ntop/
total 1328
-rw-r----- 1 root root   12357 mar 11 01:17 addressQueue.db
-rw-r----- 1 root root   12786 mar 11 01:17 dnsCache.db
-rw-r----- 1 root root  237568 mar 11 01:16 fingerprint.db
-rw-r----- 1 root root   12288 mar 11 01:16 LsWatch.db
-rw-r----- 1 root root 1110238 mar 11 01:16 macPrefix.db
-rw-r----- 1 root root   12546 mar 11 01:16 ntop_pw.db
-rw-r----- 1 root root   12967 mar 11 01:16 prefsCache.db
drwxrwx--- 5 root ntop    4096 mar 11 01:16 rrd


Comment 80 Patrice Dumas 2007-03-11 00:28:34 UTC
Also there are no logs in the file specified in the logrotate
config file. The logs go through syslog for me. Is it normal,
or is there something wrong? 

Comment 81 Bernard Johnson 2007-03-16 17:21:08 UTC
(In reply to comment #77)
> seems to patch the same file one after another. And moreover
> those patches seems to be unuseful since you overwrite the file?

I've integrated this into one sane patch now :)

> I suggest using the 'official scriptlets' found here:
> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
> Yours don't seem wrong, it is for consistency. Using
> /sbin/service may be more robust over time, however.
> It adds a 
> Requires(preun): /sbin/service

My original intent was to avoid the dependency, although I later found that my
init file uses the daemon function that requires initscripts package anyway, so
now there is no reason to not use /sbin/service.  Fixed.

I also updated the scriptlents to make them look more like the ScriptlnetSnippets.

> Build log looks saner, but there is still a duplication of the 
> CFLAGS. In my opinion it comes from Makefile.am, the following
> line should be removed (at least @CFLAGS@ should be removed):
> 
> AM_CFLAGS = @CFLAGS@

I added this fix, but can you explain to me more what the intention is?  I would
like to document why this has to be changed.
 
> In the init file, maybe add the LSB bits? (within BEGIN INIT INFO)

Added.

> still in the init file the summary is a bit terse.

Updated this to match the summary from the spec file.

(In reply to comment #78)
> Created an attachment (id=149782) [edit]
> fix enable-mysql handling
> 
> The handling of --enable-mysql is broken, should be
> fixed with that patch (for upstream).

Integrated and forwarded to upstream.  This does now correctly generate a
dependency for me.

(In reply to comment #80)
> Also there are no logs in the file specified in the logrotate
> config file. The logs go through syslog for me. Is it normal,
> or is there something wrong? 

Remnants of times passed when I was having it lot to a regular log file.  I
removed all remnants of the logrotate pieces.


Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.9.20070314cvs.fc6.src.rpm

* Fri Mar 16 2007 Bernard Johnson <bjohnson> - 3.3-0.9.20070314cvs
- update to 20070314cvs
- add additional mysql patch from Patrice
- remove all of unused logrotate pieces
- use /sbin/service to start/stop services
- update scriptlets to be easier to read
- Better description to initfile summary
- add LSB bits to initfile


Comment 82 Bernard Johnson 2007-03-16 17:23:30 UTC
(In reply to comment #79)
> I still see the same errors than above. As a side note, i 
> have noticed that the perms for /var/lib/ntop itself is:
> 
> # ls -l /var/lib/ntop/
> total 1328
> -rw-r----- 1 root root   12357 mar 11 01:17 addressQueue.db
> -rw-r----- 1 root root   12786 mar 11 01:17 dnsCache.db
> -rw-r----- 1 root root  237568 mar 11 01:16 fingerprint.db
> -rw-r----- 1 root root   12288 mar 11 01:16 LsWatch.db
> -rw-r----- 1 root root 1110238 mar 11 01:16 macPrefix.db
> -rw-r----- 1 root root   12546 mar 11 01:16 ntop_pw.db
> -rw-r----- 1 root root   12967 mar 11 01:16 prefsCache.db
> drwxrwx--- 5 root ntop    4096 mar 11 01:16 rrd
> 


Can you verify what id your ntop is running as?

Those permissions are correct.  ntop opens those database files before it drops
privileges.

Comment 83 Patrice Dumas 2007-03-16 22:38:18 UTC
rpmlint interesting errors:
E: ntop unknow-lsb-tag # Requird-Start:     $local_fs $network $syslog
E: ntop wrong-line-in-lsb-tag #                    top command

For the second one, the previous end of line has to be escaped by a \

Comment 84 Patrice Dumas 2007-03-16 22:40:39 UTC
Created attachment 150284 [details]
cleanup RRD variables and remove AM_LDFLAGS= @LDFLAGS@

A patch for upstream

Comment 85 Patrice Dumas 2007-03-16 22:43:18 UTC
Created attachment 150285 [details]
use pkgconfig to find modules. add libs to LIBS and not LDFLAGS

Also for upstream

Comment 86 Patrice Dumas 2007-03-16 22:45:33 UTC
(In reply to comment #81)

> > Build log looks saner, but there is still a duplication of the 
> > CFLAGS. In my opinion it comes from Makefile.am, the following
> > line should be removed (at least @CFLAGS@ should be removed):
> > 
> > AM_CFLAGS = @CFLAGS@
> 
> I added this fix, but can you explain to me more what the intention is?  I would
> like to document why this has to be changed.

CFLAGS is already added to the command line and there is 
CFLAGS = @CFLAGS@
automatically added by Makefile.am in Makefile.in




Comment 87 Bernard Johnson 2007-03-16 23:29:59 UTC
(In reply to comment #83)
> rpmlint interesting errors:
> E: ntop unknow-lsb-tag # Requird-Start:     $local_fs $network $syslog
> E: ntop wrong-line-in-lsb-tag #                    top command
> 
> For the second one, the previous end of line has to be escaped by a \

First one was a typo I thought I had previously fixed.

Here is another spin cleaned up with your recent patches applied:

Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.10.20070314cvs.fc6.src.rpm

* Fri Mar 16 2007 Bernard Johnson <bjohnson> - 3.3-0.10.20070314cvs
- fix rpmlint warning for initfile
- include 2 of Patrice's patches to cleanup builds
- remove repotag


Comment 88 Patrice Dumas 2007-03-17 10:41:08 UTC
ntop run as ntop user. I attach the logs.

Comment 89 Patrice Dumas 2007-03-17 10:44:19 UTC
Created attachment 150302 [details]
ntop log

Comment 90 Bernard Johnson 2007-03-17 16:07:59 UTC
(In reply to comment #88)
> ntop run as ntop user. I attach the logs.

Try uninstalling ntop then recursively deleting /var/lib/ntop/rrd.  Install ntop
and then run it again.

Also, let me know what version of rrdtool you have.

I looked through the rrdtool source and it seems to think that it's getting 2
for alpha channel when it should be 0 or 1 when opening the file.  Since I
switched from ntop 3.2 with included rrdtool to 3.3 that uses the system
rrdtool, it might be possible that the rrd databases are not compatible.

Comment 91 Patrice Dumas 2007-03-17 16:14:50 UTC
(In reply to comment #90)

> Try uninstalling ntop then recursively deleting /var/lib/ntop/rrd.  Install ntop
> and then run it again.

That's already what I did last time.
 
> Also, let me know what version of rrdtool you have.

rrdtool-1.2.18-1.fc7

> I looked through the rrdtool source and it seems to think that it's getting 2
> for alpha channel when it should be 0 or 1 when opening the file.  Since I
> switched from ntop 3.2 with included rrdtool to 3.3 that uses the system
> rrdtool, it might be possible that the rrd databases are not compatible.

I removed all the files from previous installs before 
regenerating password and running ntop.

Comment 92 Bernard Johnson 2007-03-17 16:24:59 UTC
Patrice:

What arch are you running on?

Are the files created?  What filesize?  If > 0 bytes, is there data in them?

Can you run 'rrdtool dump rrdfile.rrd' or 'rrdtool info rrdfile.rrd' on one of
the rrd files that it's complaining about?

Also, please attach one of the rrd files here.

Comment 93 Patrice Dumas 2007-03-17 16:30:25 UTC
There are no rrd files created.

ls -lR is still similar with what I reported in Comment #68.

Comment 94 Patrice Dumas 2007-03-17 16:32:18 UTC
my arch is i386.

Comment 95 Bernard Johnson 2007-03-17 16:53:39 UTC
(In reply to comment #93)
> There are no rrd files created.
> 
> ls -lR is still similar with what I reported in Comment #68.

Ok.

One line 5105 of rrdPlugin.c the is a '#if DEBUG' conditional that prints the
information for the rrd database creation.  Can you compile your rpm with
-DDEBUG, and log at CONST_TRACE_INFO level (3)?

Comment 96 Bernard Johnson 2007-03-20 02:28:25 UTC
* Mon Mar 19 2007 Bernard Johnson <bjohnson> - 3.3-0.11.20070319cvs
- update to 20070319cvs
- remove patches that have been added upstream

Spec URL: http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop.spec
SRPM URL:
http://www.symetrix.com/~bjohnson/projects/Fedora-Extras/ntop-3.3-0.11.20070319cvs.fc6.src.rpm

Comment 97 Patrice Dumas 2007-03-25 01:59:35 UTC
* ntop daemon is started by default, this is not right, 
Default-Start: should certainly be empty, instead of:
# Default-Start:     3 4 5

* when I do
export CFLAGS="%{optflags} -DDEBUG"
just before %configure in %build, there is a compile error
in util.c, so I cannot test a build with -DDEBUG.

* the libraries aren't linked against any libraries, 
so there are a lot of undefined non weak symbols with 
rpmlint run on the installed rpm. I'll attach a patch.

After applying the patch I get
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
/usr/lib/librrd_th.so.2
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
/usr/lib/libgdome.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /lib/libglib-2.0.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /usr/lib/libxml2.so.2
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /usr/lib/libgd.so.2
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
/usr/lib/libpng12.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /lib/libssl.so.6
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
/usr/lib/libnetsnmpmibs.so.15
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
/usr/lib/libnetsnmphelpers.so.15
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
/usr/lib/libsensors.so.3
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /lib/libresolv.so.2
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /lib/libnsl.so.1
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /lib/libcrypt.so.1
W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so /lib/libutil.so.1
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/lib/libpcre.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libgdome.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/lib/libglib-2.0.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libxml2.so.2
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libpng12.so.0
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/mysql/libmysqlclient_r.so.15
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libnetsnmpmibs.so.15
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libnetsnmphelpers.so.15
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libnetsnmp.so.15
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/libsensors.so.3
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/lib/libresolv.so.2
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/lib/libnsl.so.1
W: ntop unused-direct-shlib-dependency /usr/lib/libntopreport-3.3.so
/lib/libutil.so.1

It means that there should be more fine grained linking flags
added in *_LIBADD, *_LDADD.

There are still some non-weak symbols:
W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so welcome
W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so static_ntop
W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so welcome
W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so setAdminPassword
W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so usage
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so welcome
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so static_ntop
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so welcome
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so setAdminPassword
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so usage
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so addUser
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so changeFilter
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so doAddUser
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so doChangeFilter
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so showUsers
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so addURL
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so deleteUser
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so doAddURL
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so addDefaultAdminUser
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so handleNtopConfig
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so showURLs
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so deleteURL

I checked some of those symbols, they were in admin.c,
or main.c and admin.c and main.c are only in ntop. This 
should really be reported upstream, this is weird....


Comment 98 Patrice Dumas 2007-03-25 02:01:16 UTC
Created attachment 150840 [details]
link libns against libraries

Comment 99 Bernard Johnson 2007-04-07 01:33:16 UTC
(In reply to comment #97)
> * when I do
> export CFLAGS="%{optflags} -DDEBUG"
> just before %configure in %build, there is a compile error
> in util.c, so I cannot test a build with -DDEBUG.

This is now fixed in the upstream, and I've included the -DDEBUG in the src.rpm
for now until we get this worked out.
 
> * the libraries aren't linked against any libraries, 
> so there are a lot of undefined non weak symbols with 
> rpmlint run on the installed rpm. I'll attach a patch.
> 
> After applying the patch I get
> W: ntop unused-direct-shlib-dependency /usr/lib/libntop-3.3.so
>
> ...
> 
> I checked some of those symbols, they were in admin.c,
> or main.c and admin.c and main.c are only in ntop. This 
> should really be reported upstream, this is weird....

Upstream claims to have fixed this.

My rpmlint does now show any problems, but it never did on the other builds
either.  Can you check and see if this clears it up for you?


* Fri Apr 06 2007 Bernard Johnson <bjohnson> - 3.3-0.12.20070407cvs
- update to 20070407cvs
- compile with -DDEBUG for now to check for problems
- rework ntop-am.patch with recent changes
- patch to remove gdVersionGuessValue from plugin
- repatch with shrext patch

Spec URL: http://symetrix.com/~bjohnson/projects/fedora/ntop.spec
SRPM URL:
http://symetrix.com/~bjohnson/projects/fedora/ntop-3.3-0.12.20070407cvs.fc6.src.rpm


Comment 100 Patrice Dumas 2007-04-07 22:29:35 UTC
I have a segfault. In the backtrace I remove personal information and
replace it with xx.xx... or xx:xx...

Added a new hash_hostTraffic entry [00:07:CB:0B:30:E6///4][idx=3019]
DEBUG: free(85b86f0) @ util.c:2755

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1314272368 (LWP 29298)]
0x01007f4b in strlen () from /lib/libc.so.6
(gdb) bt
#0  0x01007f4b in strlen () from /lib/libc.so.6
#1  0x00fd9732 in _IO_vfprintf_internal (s=0xb1a984cc, format=0x27117c
"(%s/%s/%s) -> (%s/%s/%s) routed by [idx=%d/%s/%s/%s]", ap=<value optimized out>)
    at vfprintf.c:1560
#2  0x0107df01 in ___vsnprintf_chk (
    s=0xb1a99648 "(00:0F:1F:xx:xx:96/82.67.xx.xx/xxxxxxxxxxxxxxxxxxx) ->
(/82.67.xx.xx/82.67.xx.xx) routed by [idx=149712984//freebox sa:xx:xx:xx/", 
    maxlen=1024, flags=1, slen=1024, format=0x27117c "(%s/%s/%s) -> (%s/%s/%s)
routed by [idx=%d/%s/%s/%s]", 
    args=0xb1a99ba0 "��\b��\b��b��\b��b��bXp�bjp�b�p�b\001") at vsnprintf_chk.c:65
#3  0x0025c40c in traceEvent (eventTraceLevel=3, file=0x271862 "pbuf.c",
line=611, format=0x27117c "(%s/%s/%s) -> (%s/%s/%s) routed by [idx=%d/%s/%s/%s]")
    at util.c:2722
#4  0x0023d49f in processIpPkt (bp=0xb1a9a2ae "E�, h=0xb1a9c320, length=106,
ether_src=0xb1a9a224 "", ether_dst=0xb1a9a21e "", actualDeviceId=0, vlanId=65535)
    at pbuf.c:611
#5  0x0024344e in processPacket (_deviceId=0x0, h=0xb1a9c320, p=0xb1a9a2a0 "")
at pbuf.c:3665
#6  0x00247083 in queuePacket (_deviceId=0x0, h=0xb1a9c320, p=0x85191ea "") at
pbuf.c:2446
#7  0x009ee4e7 in ?? () from /usr/lib/libpcap.so.0.9
#8  0x009ee957 in pcap_dispatch () from /usr/lib/libpcap.so.0.9
#9  0x002392de in pcapDispatch (_i=0x0) at ntop.c:106
#10 0x002032db in start_thread (arg=0xb1a9cb90) at pthread_create.c:296
#11 0x0106a0fe in clone () from /lib/libc.so.6


Comment 101 Patrice Dumas 2007-04-07 22:34:21 UTC
(In reply to comment #99)

> > I checked some of those symbols, they were in admin.c,
> > or main.c and admin.c and main.c are only in ntop. This 
> > should really be reported upstream, this is weird....
> 
> Upstream claims to have fixed this.
>
> My rpmlint does now show any problems, but it never did on the other builds
> either.  Can you check and see if this clears it up for you?

It clears many of the undefined-non-weak-symbol, but not all. There
are still symbols from admin.c and main.c needed in the shared libs.

To get those warnings, you must run rpmlint against an installed package,
like 
rpmlint ntop

And it is similar than running
ldd -r  /usr/lib/libntopreport-3.3.so
(for undefined symbols)
and
ldd -r -u /usr/lib/libntopreport-3.3.so
(for Unused direct dependencies, and undefined symbols)


Comment 102 Mamoru TASAKA 2007-05-04 08:05:48 UTC
What is the status of this bug?

Comment 103 Bernard Johnson 2007-05-04 14:46:09 UTC
Waiting for upstream to make some bug fixes.  I've reported at least three
issues upstream that I consider show stoppers:

1) configure with --disable-static will not build
2) compile with -DDEBUG will not build.
3) A segfault reported by Patrice that can not be adequately evaluated because of #2

I've been updating to cvs version (locally) whenever I see movement upstream,
but so far none of these issues have been fixed.

Comment 104 Bernard Johnson 2007-06-08 18:06:29 UTC
ntop finally compiles again.  However, all three issues above are still not
fixed.  I posted a message for upstream again regarding these.

Spec URL: http://symetrix.com/~bjohnson/projects/fedora/ntop.spec
SRPM URL:
http://symetrix.com/~bjohnson/projects/fedora/ntop-3.3-0.13.20070608cvs.fc7.src.rpm

* Wed Jun 08 2007 Bernard Johnson <bjohnson> - 3.3-0.13.20070608cvs
- update to 20070608cvs
- update patch to remove rc version
- remove remove-gd-version-guess.patch (not needed anymore)
- remove xmldump plugin dependencies since it has been disabled (broken) in
  default ntop installation

Comment 105 Bernard Johnson 2007-06-12 06:03:29 UTC
Upstream has released 3.3.  This is updated for the 3.3 release.  The problem
with --disable-static is not fixed.  The other reported problems should be.  If
there are any segfaults with this version reported, please try to collect a
stacktrace.  Compiling with -DDEBUG works now (but you must then run ntop in the
foreground rather than as a daemon).

Spec URL: http://symetrix.com/~bjohnson/projects/fedora/ntop.spec
SRPM URL:
http://symetrix.com/~bjohnson/projects/fedora/ntop-3.3-1.fc7.src.rpm

* Mon Jun 11 2007 Bernard Johnson <bjohnson> - 3.3-1
- update to ntop 3.3 release
- remove patch to change release version (no longer needed)
- fix initfile to use correct parameters to --skip-version-check


Comment 106 Bernard Johnson 2007-06-12 18:06:09 UTC
Luca updated the autotools to fix the --disable-static issue that I was having.
 I  pulled out the bits that seemed important (autotools generated almost 17,000
lines to patch).  It looks like the bits I was previously patching seem to still
be the important bits.

If no one is having problems with this version, I'd like to move forward at this
point.

Spec URL: http://symetrix.com/~bjohnson/projects/fedora/ntop.spec
SRPM URL:
http://symetrix.com/~bjohnson/projects/fedora/ntop-3.3-2.fc7.src.rpm

* Tue Jun 12 2007 Bernard Johnson <bjohnson> - 3.3-2
- autotools patch to fix broken --disable-static switch - updated
- remove find the removes CVS directories (no longer needed)


Comment 107 Mamoru TASAKA 2007-06-20 15:54:16 UTC
Patrice, is the newest ntop good for you?

Comment 108 Patrice Dumas 2007-06-20 21:35:03 UTC
This is for upstream, but there are still the undefined-non-weak-symbol
certainly those I found above.
W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so static_ntop
....
W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so static_ntop

The timestamps are not kept. Maybe adding 
INSTALL='install -p' to the make install command line would
do the trick.

I see a blocker:
W: ntop service-default-enabled /etc/rc.d/init.d/ntop

When starting ntop I get an error:
# /etc/init.d/ntop start
Démarrage de ntop :/usr/sbin/ntop: option `--skip-version-check' requires an
argument
/usr/sbin/ntop: option `--skip-version-check' requires an argument
                                                           [ÉCHOUÉ]
When I modify /etc/ntop.conf to have
--skip-version-check yes
it starts.

I have in logs:
Jun 20 23:16:03 localhost ntop[30182]:   **WARNING** RRD:
[path=/var/lib/ntop/interfaces][error=13/Permission non accordée]
Jun 20 23:16:03 localhost ntop[30182]:   **WARNING** RRD:
[path=/var/lib/ntop/interfaces/eth0][error=2/Aucun fichier ou répertoire de ce type]
Jun 20 23:16:03 localhost ntop[30182]:   **WARNING** RRD:
mkdir(/var/lib/ntop/interfaces/eth0/), error 2 Aucun fichier ou répertoire de ce
type

So it seems to me that the directory 
/var/lib/ntop/interfaces/
should preexist.

I don't have the error message i quote above when I create this
directory by hand.

However I still get
Jun 20 23:31:09 localhost ntop[30533]:   **WARNING** RRD:
rrd_create(/var/lib/ntop/interfaces/eth0/throughput.rrd) error: Invalid alpha:
must be between 0 and 1
Jun 20 23:31:09 localhost ntop[30533]:   **WARNING** RRD:
rrd_update(/var/lib/ntop/interfaces/eth0/throughput.rrd) error: opening
'/var/lib/ntop/interfaces/eth0/throughput.rrd': strerror_r failed. sorry!


Comment 109 Patrice Dumas 2007-06-20 21:53:16 UTC
After recompilation with -DDEBUG, I get in the log:


Jun 20 23:48:59 localhost ntop[22568]:   RRD: rrdtool create --start now-1 file
--step 300 DS:counter:COUNTER:600:0:125000000 RRA:AVERAGE:0,5:1:864
RRA:MIN:0,5:1:72 RRA:MAX:0,5:1:72 RRA:AVERAGE:0,5:12:2160
RRA:AVERAGE:0,5:288:1080 RRA:HWPREDICT:1440:0.1:0.0035:20

before:

Jun 20 23:48:59 localhost ntop[22568]:   **WARNING** RRD:
rrd_create(/var/lib/ntop/rrd/interfaces/eth0/ethernetPkts.rrd) error: Invalid
alpha: must be between 0 and 1
Jun 20 23:48:59 localhost ntop[22568]:   **WARNING** RRD:
rrd_update(/var/lib/ntop/rrd/interfaces/eth0/ethernetPkts.rrd) error: opening
'/var/lib/ntop/rrd/interfaces/eth0/ethernetPkts.rrd': strerror_r failed. sorry!

Maybe this is what is needed to debug the **WARNING** RRD issue?

Comment 110 Bernard Johnson 2007-06-27 23:26:36 UTC
(In reply to comment #108)
> This is for upstream, but there are still the undefined-non-weak-symbol
> certainly those I found above.
> W: ntop undefined-non-weak-symbol /usr/lib/libntop-3.3.so static_ntop
> ....
> W: ntop undefined-non-weak-symbol /usr/lib/libntopreport-3.3.so static_ntop

Yeah, I'd already reported this and a bunch more previous to upstream, but they
didn't fix this.  Not sure if they will.

> The timestamps are not kept. Maybe adding 
> INSTALL='install -p' to the make install command line would
> do the trick.

Will do.

> I see a blocker:
> W: ntop service-default-enabled /etc/rc.d/init.d/ntop

Appears that rpmlint now checks the LSB entries as well! Fixed.

> --skip-version-check yes

I fixed this in the init file when upstream changed it but forgot the config
file :)  Fixed.

> So it seems to me that the directory /var/lib/ntop/interfaces/
> should preexist.

It looks like upstream has changed something here.  The correct location should
be /var/lib/ntop/rrd/interfaces/throughput.rrd, but looking through the code, it
appears that when throughput.rrd is created, the variable that hold rrd
directory may be uninitialized.  I'll be checking this with upstream.

I'll be out of town until next week.

Comment 111 Mamoru TASAKA 2007-09-27 12:45:42 UTC
Any news on this bug?

Comment 112 Bernard Johnson 2007-10-18 21:11:32 UTC
I just moved, and all my computer -devel equipment is still packed away.  I'll
also be out of the country in two days.  I expect to either resume work on this
package or drop it completely when I get back and get unpacked (approx 3 weeks).

Comment 113 Pierre-Marie Le Biot 2007-11-07 13:50:40 UTC
(in reply to comment #109)
I had the same warnings :

Jun 20 23:48:59 localhost ntop[22568]:   **WARNING** RRD:
rrd_create(/var/lib/ntop/rrd/interfaces/eth0/ethernetPkts.rrd) error: Invalid
alpha: must be between 0 and 1

this was the result of a localized system (LANG=fr_FR.UTF-8)
using LANG=C solved this problem.

Comment 114 Bernard Johnson 2007-11-16 07:24:34 UTC
I don't think I'm going to be able to finish this review because I don't have
time  to debug the last few issues.  I think the package is in /pretty good/
shape, if the last few issues can be sorted out.



(In reply to comment #113)
> this was the result of a localized system (LANG=fr_FR.UTF-8)
> using LANG=C solved this problem.

Patrice, can you see if this has any effect on the strerror_r warnings you're
receiving?


Comment 115 Patrice Dumas 2007-11-17 10:44:15 UTC
When starting with LANG=C, I indeed don't see the previous warnings.
And I can see some graphs I believe I couldn't before. I believe this
should be set in ntop.init.

One time I got the following error, which should be corrected
(and Requires /usr/bin/dot or graphviz added):

Missing dot tool (expected /usr/local/bin/dot). Please set its path (key
dot.path) here.

Also rpmlint says (among ignorable warnings):

ntop.i386: W: service-default-enabled /etc/rc.d/init.d/ntop

As always the non-weak symbols should be reported upstream such that
they correct their link commands.


So it is basically ok for me, with the service-default-enabled
corrected, dot path correctly setup and LANG=C set before starting
ntop.

Comment 116 Bernard Johnson 2007-11-18 18:54:39 UTC
Here is a new SRPM.  This build fine on F-7, but I'm running F-8 now, so I can't
install it.  The build for F-8 terminates in the build system.  I'll attach that
bug to this one in just a moment.

I see rpmlint is complaining about the license, so I need to update to the new
format.  I'll do that next rev.

Spec URL: http://bjohnson.fedorapeople.org/ntop.spec
SRPM URL:
http://bjohnson.fedorapeople.org/ntop-3.3-3.fc8.src.rpm

* Sun Nov 18 2007 Bernard Johnson <bjohnson> - 3.3-3
- add 'yes' as argument to skip-version-check in /etc/ntop.conf
- fix LSB section of init file to agree on default start runlevels
- make install preserve timestamps
- patch for location of throughput.rrd
- force LANG to "C" to prevent errors in string handling
- clean up init file
- add Requires: on graphviz


Comment 117 Patrice Dumas 2007-11-19 10:34:31 UTC
It doesn't build for me in devel. Certainly because of a
change in compiler which has become stricter. Here is the error:

/usr/include/net-snmp/library/container.h: In function 'CONTAINER_FREE':
/usr/include/net-snmp/library/container.h:440: error: invalid lvalue in assignment


Comment 118 Jason Tibbitts 2008-01-20 01:23:57 UTC
Any progress?

Comment 119 Bernard Johnson 2008-01-24 01:42:26 UTC
(In reply to comment #118)
> Any progress?

Waiting for a response from upstream. https://svn.ntop.org/trac/ticket/24

Comment 120 Bernard Johnson 2008-03-13 04:24:47 UTC
I no longer have time to pursue this package.

If someone wishes to pick it up, feel free to start with the src.rpm in comment
#116.  

Comment 121 Mamoru TASAKA 2008-05-26 14:31:19 UTC

*** This bug has been marked as a duplicate of 448397 ***