This repository has been archived by the owner on Jan 30, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 11
/
FAQ
5297 lines (3792 loc) · 214 KB
/
FAQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_ _ _
| \ | | |_ ___ _ __
| \| | __/ _ \| '_ \
| |\ | || (_) | |_) |
|_| \_|\__\___/| .__/
|_|
Network Top
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Fully revised for ntop 3.0
Updated for ntop 3.1 and 3.2
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Compiled by Burton M. Strauss III <Burton@ntopsupport.com> - comments to him!
In this document, that's whom "I" or "My" refers to.
|\ _,,,---,,_ "If I purr, you must have fed me.
/,`.-'`' -. ;-;;,_ If the network purrs, it must
<|,4- ) )-,_..;\ ( `'-' be ntop!" -----Pixel
'---''(_/--' `-'\_)
As usual, entries are in no particular sequence. However, there is an
overall flow, starting with very general questions, then questions about
specific features, then questions about specific platforms.
What structure there is in this FAQ is that of a dialog with a bright 7 year
old. The response to every answer is "Why". Keep reading until you get
too detailed for your needs.
If you actually read through this FAQ and don't find yourself saying "Oh,
Bother", at least twice, and then go read Winnie the Pooh.
At the very end are "HowTo Ask For Help" and a "GDB ultraMini-tutorial".
Read them. Before posting to the mailing list.
Note that some of this FAQ is based on the entries people contributed
to the community FAQ formerly at http://snapshot.ntop.org. Lots more are
based on messages to the ntop and ntop-dev mailing lists.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
TOP 10 - the questions everyone asks...
Q0. I downloaded the source and ./configure doesn't work.
A. Yup.
There is a long history of warfare between the versions of the GNU
autotools we use to build the distribution files and the ones installed
on your host. So during the 3.3 development cycle, Luca finally gave in
and stopped distributing a generated configure file.
Instead there is a script, autogen.sh, which uses the version(s) of the
tools installed on your system to create configure and then run it.
Yes, this means you MUST have the following tools installed:
libtool
automake
m4
autoconf
We are talking only about people who are compiling from source. Those
tools are pretty much required for ANY source. Live with it.
Q1(a). Can I store data in a SQL database?
Q1(b). When ntop stops I lose all my data. Why?
Q1(c). Why doesn't the -S option work?
A. ntop used to optionally store some data in a SQL database. The code was
broken, difficult to maintain, etc. and was removed. A LONG TIME AGO.
If you are reading about this in 'some' documentation - update.
Current ntop is 3.1, which is the only version we support.
There are scripts that various users have offered to take the data dump
and insert it into a SQL database. Search the back traffic on the mailing
list for them.
Yes, ntop uses memory based structures to hold usage data and they are lost
when you reset or restart ntop.
Persistent storage is in the RRD databases - there's a paper @ SourceForge
that explains them.
There was another option for some persistence - it was -S - look in FAQarchive
for an article about it, "What was the -S option?".
Q2. The archive isn't indexed, so I can't search it.
A. Yes, but it's easy to search using search engines or mail archives.
Google: You need to restrict the search to the U of Pisa mail list
gateway, i.e.:
site:listgateway.unipi.it ntop freebsd
Two 'mail archive' sites that I know of (as of March 2005) are:
gmane: http://search.gmane.org (our lists are renamed as gmane.linux.ntop.general
and gmane.linux.ntop.devel).
The Mail Archive:
http://www.mail-archive.com/ntop-dev@unipi.it/
http://www.mail-archive.com/ntop@unipi.it/
Q3. ntop crashed and the last log message is "xxxxx".
A. Sorry, that's useless. ntop is multi-threaded and processes 100s or 1000s of
packets per second. The last log message is probably from the wrong thread
and many seconds out of date.
To capture the true 'failure point information', you need to run under the
debugger (gdb) and send us the various outputs. Instructions are at the bottom
of this document. Look for "GDB ultraMini-tutorial".
Yes, you will need the source and a compiler.
Q3(a). What about the backtrace?
A. Again, probably useless. Use gdb and capture the full failure point info. If you
want to see more, look for "Q. What about the backtrace?" below.
Q4. I'm running out of memory.
A. Basically ntop uses a lot of memory - it stores a chunk of information about each
and every host it's monitoring. See "Q. Why does ntop use so much memory ?" and
the following articles below.
Q5. Dropped packets?
A. There are lots of reasons - look for "Q. Why does ntop drop packets?" below.
Short version, is that as long as it's random, the information you glean from ntop
(32% of our usage is P2P Music) is still valid. But you are probably understating
any problems.
Q6. The docs at ntop.org say ...
A. Stop right there. They're out of date (notice, for example, the man page is
July 2002?).
The only current stuff is this FAQ (which gets out of date quickly) the other files
in the distribution and the mailing lists.
You can access the updated FAQ from docs/FAQ in the cvs or from your ntop instance
(click on the (?) icon in the "About" menu and read down 1/2 a page or so.
Q7. How do I report a problem?
A. Best way is to use the PR (Problem Report) form - it automatically includes a lot of
the important information about your ntop instance. In the "About" menu, click on the
"Bug" icon. This generates a text form you can copy into your email program, update
and send.
Q8. HACK ALERT HACK ALERT - ntop is sending information to some machine called "jake".
A. Chill. Take a deep breath.
Jake is the cannonical name for version.ntop.org. All you are seeing is the version
check. See "Q. What's with the version check?" below.
Q9. The program asks for password for "ntop HTTP server". When I started NTOP for the first
time, it asked me to set admin password, and i put "xxxxxxxx". The user is "xxxxxxxxxx"
but I get "Unauthorized to access the document". Why?
A. The correct user to specify for the ntop web server is admin.
The -u value in the command line or parameter file is the account ntop runs under.
Q10. I'm not getting any rrd output.
A. First, make sure that the plugin is installed (you should see it in the web interface
under plugins). Make sure it is configured and active.
The default configuration does NOT include per-host .rrd files, because these can take
up a lot of space. But you probably want them and at the medium or high level of detail.
Q11. Single Threaded ntop?
A. Gone. Poof. We're in a multi-threaded world, so live with it.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Q. Where can I find ntop?
A. The official website can be found at http://www.ntop.org/.
Q. Where do I get the source?
A. SourceForge -- http://sourceforge.net/projects/ntop/
There is also a cvs (current development) maintained at cvs.ntop.org.
(instructions are on the download page of www.ntop.org)
Q. What is ntop?
A. ntop is an open source network top - it monitors a network and collects
information about the protocols and hosts for display.
Q. Um, so it's like mrtg (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/)?
A. Yes and no...
Yes in that both are analyzers of network packets.
Yes in that both display information about your network.
No in that they take very different approaches to collecting information.
No in that they display different types of information.
Q. So mrtg...
A. mrtg creates a picture of the network centered on the device on the link
between devices (and aggregations of devices and links).
Tobias (Tobi) Oetiker describe mrtg as:
"The Multi Router Traffic Grapher (MRTG) is a tool to monitor
the traffic load on network-links. MRTG generates HTML pages
containing graphical images which provide a LIVE visual
representation of this traffic."
Q. And mrtg works how?
A. mrtg reads the counters maintained by various devices such as routers, using
a protocol called 'snmp' (Simple Network Monitoring Protocol). The
management information bases (MIBs) read using snmp, contain incredibly
detailed information about the packets the device has seen and what it has
done with them.
Again, quoting Tobi:
"MRTG ... uses SNMP to read the traffic counters of your routers and
... which logs the traffic data and creates beautiful graphs representing
the traffic on the monitored network connection."
mrtg is focused on 'layer 2' (the tcp/ip and other low level protocol).
Q. And ntop?
A. ntop doesn't use snmp for it's main analysis - it's not a device centric
view of the network. Instead ntop actually processes the network packets
directly.
Q. What's wrong with snmp?
A. Nothing. As of 3.1, ntop has some sort of snmp plugin.
It's just different.
snmp is a pull protocol, that is a monitoring tool has to pull the
information from the device. snmp has 'traps' that is alert messages which
can be sent out, but the MIB data has to be read by the monitoring tool from
the device.
snmp is an older protocol, from the dawn of the network era and it has some
minor issues of security and complexity and verbosity. But it's a critical
network protocol, used successfully by 1000s of ISPs to monitor AND CONTROL
vast networks.
From our perspective, the problems with snmp are minor -
It can use a lot of bandwidth - especially if you're reading from devices
on the far side of slow links.
Pulling data out of MIBs is a complex process. MIBs can be specified in
an RFC, or be unique to a vendor/device.
An snmp-based tool either has to restrict itself to the common MIBs,
or (most often for vendor tools) it be updated whenever a new device
must be supported or a MIB changes.
This makes snmp-based tools complex, because data may be unavailable
in certain versions of seemingly similar devices, etc. For example,
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
is a page which links to the specific MIBs supported by various
Cisco devices.
Q. So why hasn't ntop 'won'?
A. mrtg excels at monitoring 100s or 1000s of network devices (routers,
switches, etc.) and presenting that information over long periods of time.
ntop doesn't do a good job of showing multiple 'networks' - it's really
focused on aggregating a picture of a single network. And for drilling down
into that picture or presenting it over long periods of time.
The processing of packets requires a lot more computer resources than just
reading counters from devices. On the plus side, this gives much more
detailed information - for example ntop sees the actual web server request
instead of just that there was traffic on port 80. On the minus side, it's
pretty easy to exceed the processing power of the low end machine typically
available for ntop. An ISP using ntop to monitor a couple of T3s needs a
FAST computer and A LOT of memory.
ntop also requires access to the physical network (either directly via a
network card or indirectly via a netFlow/sFlow probe). This limits ntop's
(usefullness|ability) to work across sites.
Once you learn what they do (mrtg and ntop), you'll probably discover that
You need both.
Q. What's this 'layer' crud?
A. Network layers come from a widely cited but never implemented model, the OSI
(Open System Interconnect ) networking model from the ISO (International
Standards Organization).
Google for it - for example
http://www.ussg.iu.edu/usail/network/nfs/network_layers.html
Q. So ntop is like netFlow (Cisco), sFlow (RFC 3176, http://www.sflow.org) or
RMON (HP)?
A. Not really, actually those are all protocols for sending and receiving
information about the network.
ntop has lots in common with the tools that USE those protocols.
And there are lots of tools - some proprietary, many open source.
The devices/programs that collect the information and send it out in netFlow,
sFlow or RMON format are usually called (by me) 'probes'. The devices and/or
programs that receive the netFlow, sFlow or RMON formatted information and do
things with it are called 'collectors' (if they process it and forward it on)
or called 'displays'.
In fact, ntop can receive netFlow packets and both send and receive sFlow
packets. It can be a 'probe' or a 'display'. (ntop used to be able to send
netFlow packets - that was removed 2004-03 by Luca).
Q. So ntop is like Nagios or Ipswitch's - WhatsUp Gold?.
A. Nope - those are layer 4 and higher (application) monitoring programs.
Q. So it's like ...
A. Enough already - if you search Freshmeat.net,
http://freshmeat.net/search/?q=network+monitor§ion=projects
you will find (as of 18Aug2003):
Topic :: System :: Networking :: Monitoring (654 projects)
We'll be here all day. ntop is ntop.
Q. Ok, so ntop is a unique TCP/IP analyzer.
A. Not exactly.
First off, ntop pretty much doesn't care about the lowest (layer 1 or wire)
layer. It leaves dealing with that to a library, libpcap, which hides most
of that.
ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer
(layer 2) nor a pure TCP/IP analyzer (layer 3).
ntop gets the data at the layer 2 (frame) level, which could be Ethernet
or another protocol. Beyond Ethernet, ntop has minimal smarts about FDDI,
PPP, RAW and TOKEN-RING frames. That is, at least enough for some basic
counts or to extract the (layer 3) TCP/IP data in side.
ntop 3.0 adds TWO (three?) HUGE areas of new protocol support.
ntop 3.0 supports IPv6, thanks to code contributed by Olivier Festor
<Olivier.Festor@loria.fr> and Abdelkader Lahmadi <Abdelkader.Lahmadi@loria.fr>
of the MADYNES Research Time (Managing DYnamic NEtworks and Services), see
http://madynes.loria.fr/.
ntop 3.0 has more than a fair amount of smarts about FibreChannel and SCSI
thanks to code contributed by Dinesh G Dutt <ddutt@cisco.com> of Cisco.
However, since most of ntop's displayed counts are at the TCP/IP level, it
confuses people into thinking ntop is purely a TCP/IP analyzer.
ntop is a traffic monitor with it's own network interfaces, which monitors
what it sees (or is told about through netFlow or sFlow probes).
Q. ntop runs under?
A. ntop is known to work under Linux, Mac OS X, FreeBSD, Solaris and Win32.
ntop development is done primarily on Fedora Linux.
Luca also does a port to Win32 (MS Visual C .Net) and used to work in the Sun
Solaris environment. He also seems to work with FreeBSD 5.4.
I (Burton) usually work under Fedora Linux, but use Microsoft's VPC 2004 and
VMware Workstation 5 to test under other Linux distros and OSes.
Our users run under many other platforms - Here's data from the version.xml log
records showing what people were running while testing 3.2:
(This data covered approximately the first two weeks of July 2005)
count version
------- -------
16684 3.1
10960 3.0
345 3.1rc1
259 3.1.1
etc.
count OS Version
------- ------- --------------
20509 Linux
3566 Windows WinNT/2K/XP
1752 Unknown Windowsv3.1
1018 Unknown Windowsv3.0
266 FreeBSD 5.3
234 FreeBSD 5.4
219 Darwin 7.7.0
Of course, this is self-selected - people can turn off the logging.
Linux covers lots of Different Linuxes... of the ones we recognize:
count Distro Release
------- --------- --------
3148 suse
2637 redhat 9
2625 fedora 3
2014 fedora 2
1541 debian 3.1
1373 gentoo 1.4.16
613 redhat 3
603 fedora 1
523 mandrakel 10.2
505 gentoo 1.6.12
473 redhat 7.3
448 mandrakel 10.1
428 debian
399 redhat 4
367 redhat 8.0
301 slackware 10.1.0
282 slackware 10.0.0
The jump in 'SuSE' may represent nothing more than improved detection
in the 3.2/3.1 scripts vs. 3.0. We used to have a huge 'unknown' count.
Running under pretty much any *nix is at least theoretically possible.
But it takes interested party/parties and access to resources - some of the
things that ntop does such as libpcap and loading plugins are tied tighter
to the OS than you might like.
There are sections below about each specific OS.
--------------------------------------------------------------------------------
-----Features-------------------------------------------------------------------
--------------------------------------------------------------------------------
Q. What determines the features of ntop?
A. <laugh>Whatever Luca wants</laugh>
Q. Why did you do this "x" instead of feature "y"?
A. Don't know. I could guess...
Imagine you are the network manager for a large University network and have
to crack down on users who are illegally exchanging copyrighted files or
using University resources to run a business without paying for the resources
being consumed.
or
You are a major vendor of infrastructure, whose customers are using networks
for new features such as storage area networks and you want to give them
the ability to monitor these.
or
You have a really cool technology that you've just donated to the community
via an RFC and wish to jump-start adoption of it.
or
You are moving heavily into IPv6 and need to be able to monitor your 'new'
network just like you monitored the IPv4 one.
or (my favorite)
You really, really, really hate that ntop generates such lousy html code
and you decide to scratch that itch.
or (what should happen)
A major corporation, with out resources, time, skills and/or inclination
to do it themselves sponsors the development of a feature that's critical
to him/her.
or
Then again, it could just be because it's cool...
Q. Could ntop do "x"
A. Probably - as long as it doesn't move the tool away from it's purpose and
it's strengths, almost anything is possible - especially as a plugin.
Q. Will you do "x"
A. Maybe - if it's of interest to a developer, or you provide the code such
that it can be merged in, or if you're willing to sponsor the development
effort (contact us through http://www.ntop.org/consultancy.html).
--------------------------------------------------------------------------------
-----Documentation--------------------------------------------------------------
--------------------------------------------------------------------------------
Q. Why isn't there (any)(more)(better) documentation.
A. (A personal peeve from Burton...)
I get real tired of people complaining that there isn't any documentation
and then being unwilling to contribute even the simplest stuff. I've said
I'll edit and assemble whatever people send me... and since I started working
with ntop in November 2001, I've received maybe six pages of stuff.
I'm trying to get people - who aren't coders - to contribute to ntop the
project. The contribution that ANYONE can make is "documentation". A task-
specific HOWTO... some sample screen shots... An FAQ entry...
I've tried being nice.
I've tried asking.
I've tried shaming people into it.
What have I gotten? Zip.
Nasty is all that's left... This is your fair warning. If you show up on
the ntop mailing lists and complain about documentation, you will get
blasted.
-----Burton
Q. Ok, where can I find what does exist.
A. http://www.ntop.org has pointers and some (very out-dated) documents.
The documentation in the docs/ directory, the Documentation files at SourceForge
and some at http://www.ntopsupport.com are basically all that there is.
Search the ntop mailing lists at gmane, http://search.gmane.org. The lists
are called gmane.linux.ntop.general and gmane.linux.ntop.devel.
Please contribute to the ntop community by writing things up for inclusion
in this FAQ or other documents!
Q. I can't find a file at SourceForge!
A. You can reach the archives through any SourceForge mirror, or the main site:
http://prdownloads.sourceforge.net/n/nt/ntop
It has ALL the files unless we explicitly delete them...
--------------------------------------------------------------------------------
-----Problems-------------------------------------------------------------------
--------------------------------------------------------------------------------
Q. I have a problem...
A. Make sure it's a supported release!
We support only the current versions of ntop. This is either:
* the last release, e.g. v3.1.
* the current cvs (cvs.ntop.org)
* the latest development version posted at SourceForge (if one)
If you use a port/package and the latest version available for your
OS is some release candidate from a year ago, sorry. Contact the
packager and ask them to get current.
Luca usually asks people to try the latest cvs (development) version
because problems are frequently already fixed in there.
Q. I'm running something supported and I've tried the latest & greatest.
Still, I have a problem.
A. Read the ntop mailing lists.
The ntop mailing lists are at
http://listgateway.unipi.it/mailman/listinfo/ntop
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
and
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
If you're having non-user problems OR you are using the cvs, you should be
reading and posting ntop-dev (for example, the cvs commit messages are posted
there). Stuff unrelated to baseline ntop (PF_RING) belongs in ntop-misc.
You can read the lists through gmane (or other gateways) if you don't
want to subscribe, but only subscribers can post.
You can download the older messages in large chunks from the mailing list
subscription pages. Look for "To see the collection of prior postings to
the list".
Q. I looked and I didn't find my problem.
A. Join the mailing list(s) and ask for help.
Before you post, check the "HowTo Ask for Help" at the end of this FAQ.
Please, if at all possible, use the built in PR_ form (the little 'bug' icon
on the 'About' tab).
Guidelines for asking questions:
ONE and only ONE problem / issue / question per message.
With a meaningful subject.
The goal is that if you're asking a common question, the
subject would have allowed you to find it in the back
traffic for the mailing list.
Post the information about your environment we ask for.
We STRONGLY suggest you use the automatically generated "Problem
Report" form that since it contains much of the necessary information.
Make sure you're in a supported environment (./configure --showoses).
If it's an unsupported environment, we're interested in your efforts to
make ntop work, but we don't have the time, resources, knowledge and/or
interest to do it ourselves.
For software 'crashes', please run ntop under the gdb debugger and capture
the full failure information.
Brief instructions on using gdb are at the end of this file (docs/FAQ).
Q. I posted to the list and nobody answered me.
A. ntop is open source, and the lists are a community resource. If nobody
answered your question, then nobody knew the answers off-hand and nobody
wanted to spend THEIR time solving YOUR problem.
Q. Do you offer paid support?
A. Yes - contact us through http://www.ntop.org/consultancy.html
--------------------------------------------------------------------------------
-----Configuring ntop-----------------------------------------------------------
--------------------------------------------------------------------------------
Q. What does ./configure do?
A. ./configure checks for the tools installed on your system - configuring
ntop to compile with the ones you have and skip the ones you don't (or
to tell you if you're missing something critical).
Q. Why bother - just compile the code.
A. Then you would have to have a machine configured EXACTLY like Luca's.
Nothing else would work. Various OSes and Linux distributions package
the files in different ways and put them in different places. Plus some
packages put files into directories with release information in them, etc.
Q. OK, so ./configure
A. Is how you tell ntop where to find things. A lot of stuff it can figure
out on it's own, but if things get put in 'strange' places, ntop's
./configure has switches you use to tell where to find things.
Q. And the list is?
A. ./configure --help shows the whole list. It's a bit confusing because
there are standard options and ntop options mixed in there.
A. So, first let's look at the 'where are things' options. There are two
types of files ntop is looking for, '.h' files and libxxxx files.
.h files are also called 'includes' and libxxxx files are called libraries
or lib files.
.h files are the C source for functions provided by the OS or by libraries.
They are typically in a directory named /usr/include, but they can be
placed ANYWHERE.
lib files are compiled libraries of these functions (the .h tells ntop
how to call something, the lib file is the actual code). Their names
usually begin libxxxx (so the library gd is named libgd).
By convention, libraries end in .so or .a. A .so library is a shared
library (Windows DLL), where one copy of the library is used by all
programs that want it's functions. A .a library is a non-shared or
static library, which must be merged (the technical term is linked)
with the code.
ntop uses both - the myrrd library is a static, .a library. When it
comes to things like libpcap or libgd, we use shared (.so) libraries.
Library files are typically placed in /usr/lib, where the gnu linker
(ld), 'knows' automatically how to find them. However, from OS to
OS and distribution to distribution, there are many other common places.
Some OSes even have a file telling ld all the places to look.
Q. So ntop looks for these .h and library thingies in a couple of places.
What if it doesn't find them?
A. If a basic ./configure can't find something, you'll have to tell ntop
where to look.
It's complex and OS/distro dependent. For example, if you install libgd
from the Sun Freeware site on to a Solaris machine, the files get put
into /usr/local/include and /usr/local/lib, which are not on the lists
of 'standard' places for Solaris' versions of gcc (the Gnu c compiler)
or ld. So to compile ntop, you have to tell gcc to look in these
additional locations.
The things ntop might be looking for are in this part of the
./configure --help output:
+-External-source-locations:-------------------------------------------------+
--with-pcap-root=DIR LBNL pcap located in DIR
--with-pcap-lib=DIR or libpcap located in DIR
--with-pcap-include=DIR or pcap.h located in DIR
--with-gdbm-root=DIR gdbm located in DIR
--with-gdbm-lib=DIR or libgdbm located in DIR
--with-gdbm-include=DIR or gdbm.h located in DIR
--with-zlib-root=DIR zlib located in DIR
--with-zlib-lib=DIR or libz located in DIR
--with-zlib-include=DIR or zlib.h located in DIR
--with-gd-root=DIR gd located in DIR
--with-gd-lib=DIR or libgd located in DIR
--with-gd-include=DIR or gd.h located in DIR
--with-libpng-root=DIR libpng located in DIR
--with-libpng-lib=DIR or libpng located in DIR
--with-libpng-include=DIR or png.h located in DIR
--with-ossl-root=DIR openSSL located in DIR
--with-ossl-lib=DIR or libssl located in DIR
--with-ossl-include=DIR or ssl.h located in DIR
--with-localedir=DIR LOCALE files located in DIR (i18n)
+-----------------------------------------------------------------------+
You can see that there is a pattern, pretty much every --with-xxxxx-root
has a --with-xxxxx-include and --with-xxxxx-lib option.
So, if ntop tells you it can't find something, do this - first look for the
File on your system:
$ locate pcap.h
/usr/include/pcap/pcap.h
(If you don't have locate, this works too:
$ find / -type f -name "pcap.h"
)
And then tell ./configure via --with-pcap-include=/usr/include/pcap
(Some OSes are smart enough to look in a subdirectory of the standard
location, but others aren't).
Q. Ok, but why three options?
A. You use either the --with-xxxxx-root option OR either/both of the others
at a time. But ntop really only looks at the --with-xxxxx-include and
--with-xxxxx-lib options.
Internally, --with-xxxxx-root=/a/b/c is translated into
--with-xxxxx-lib=/a/b/c/lib and --with-xxxxx-include=/a/b/c/include
(that's the usual pattern).
Now sometimes libraries are installed logically - if the pcap.h file is in
/usr/local/pcap/include, the library (libpcap.so) is probably in
/usr/local/pcap/lib. Sometimes they are not logical and you will have
to use the split options.
The --with-pcap-root=/usr/local/pcap is shorthand for the two options,
--with-pcap-include=/usr/local/pcap/include and
--with-pcap-lib=/usr/local/pcap/lib.
Q. Oh Ghu - aren't there any short cuts.
A. For the first time you try ./configure, there's a script on SourceForge in
The user contributed area that will try to build the ./configure line for
you.
Q. And the OTHER options
A. There is a set that tells ntop where to install stuff. For simplicity,
the two you might want to change are:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--datadir=DIR read-only architecture-independent data
[PREFIX/share]
--prefix tells ntop where to install the various files. The default value
is /usr/local, which is where most non-OS software normal goes.
A common choice for libraries (such as pcap) is --prefix=/usr, which puts
things like .h files in places easier to automatically find (/usr/include).
--prefix=/usr certainly works for ntop. --prefix=/opt is another choice.
The 'proper' choice turns on which model of file organization the OS and
sysadmin prefer. That's a fight I'm staying out of.
--datadir tells ntop where to put its databases and output files. The
default is /usr/share/ntop, but that will give some sysadmin's agita.
Another popular choice is --datadir=/var, which puts all the files in
/var/ntop. That may be attractive especially if you make /var/ntop
a separate partition, so the rrd files don't eat all your disk space.
Q. What's --enable-iknowbetter Override WILLFAIL
A. There are some error messages where it's possible that thing work (now)
that didn't used to, or you're doing development and don't want ntop
to stop you from doing something, or there's an error message that you
have skipped before without getting bitten.
--enable-iknowbetter will print the message but not stop ntop from
finishing ./configure.
Use it at your own risk.
Q. What are the --enable and --disable options?
A. These (and the with/without options) pretty much do what you think - they
enable or disable large chunks of ntop functionality:
+--ntop-specific:------------------------------------------------------------+
--enable-sslv3 enable ssl v3 support [default=disabled]
--enable-sslwatchdog enable Watchdog for ssl hangups [default=disabled]
--disable-plugins disable compilation of plugins [default=enabled]
--enable-static-plugins Enable static linked plugins sntop, default=dynamic]
--enable-ignoresigpipe Ignore SIGPIPE errors [default=do not ignore]
--disable-snmp Disable SNMP support [default=disable]
--enable-i18n Enable (limited) internationalization [default=disabled]
--enable-jumbo-frames Enable Jumbo (9K) Ethernet frames [default=disabled]
--disable-ipv6 use IPv6 [default=enabled]
+-----------------------------------------------------------------------+
+--external-packages:---------------------------------------------------+
--without-ssl disable HTPPS support [default=enabled]
--without-zlib disable zlib [default=enabled]
--with-tcpwrap enable use of TCP Wrapper [default=disabled]
+-----------------------------------------------------------------------+
Q. What ELSE?
A. There are some so called 'environment variables' you can set that change
things too. The common ones are:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CPP C preprocessor
You would use these variables to override the choices made by ./configure
or to help it to find libraries and programs with truly nonstandard
names/locations.
The best place to look for examples of these environment variables are in
the OS/distribution files in the configureextra directory. For example,
(again picking on Solaris), we use LDFLAGS to tell ld to look in some
common Solaris locations for libraries via this:
LDFLAGS="-L/usr/local/lib -R/usr/local/lib ${LDFLAGS}"
What that does is add /usr/local/lib to the locations that ld will check.
Q. ./configure dies in some strange horrible way complaining about version
conflicts, lunar phase or whatever.
A. The process of creating portable cross-platform scripts for building
software is ugly and hard and prone to failure. There are tools
(released by gnu) to help, named automake, autoconf and libtool.
(Collectively the auto* tools).
These tools take basic files and generate more complex files based
on a series of rules, conventions and macros (much of which is poorly
or undocumented). Other processes (e.g. ./configure) take these files
and generate more complex files based on a different series of rules,
conventions and macros. This ultimately produces the 'Makefile', which
a program called make uses - based on (...wait for it...) yet another
series of rules, conventions and macros - to actually compile the ntop
source.
There are interdependencies among the tools, partial support for older
versions in some releases, but not in other releases and many more
problems.
Different OSes and different Linux distros ship with wildly different
versions. Some even have scripts that attempt to analyze the file and
pick the correct version (which just means that trying to code a file
with multiple version support confuses the tool).
So if you have a basic, total failure of ./configure, it's usually
the auto* tools.
ntop used to ship with a manual script that rebuilt the generated files
according to the version(s) of the tools installed on the system you were
using to build ntop. Thus the standard answer was 'run ./autogen.sh -1'.
But, this meant that you had to have these 'developer' tools installed
and caused much problems and gnashing of teeth.
So we spent 100s of hours rebuilding the scripts to be totally independent
of having the tools installed on your system - only to run into problems
because the xyz 1.6.1 tool installed by default on OS A isn't quite
compatible with the 1.6.3 version on OS B.
So we put technology in place to automatically detect tool versions and
rebuild the generated files if necessary. That meant you had to have
these 'developer' tools installed and caused much problems.
So we rebuilt the scripts AGAIN and AGAIN, dropped support for old versions
of the tools and finally reached a point where it works for most reasonably
current platforms. This is a compromise:
Systems that don't have the tools installed usually work.
Systems that have bleeding edge versions of these tools may break.
Systems with very old versions also may break.
The technology to detect versions and rebuild the script files if
appropriate is still in there, but it's disabled from normal use.
If you have the auto* tools installed and have ./configure problems, you
can activate the automatic rebuild feature via:
$ export NTOPAUTOREBUILD=yes
$ ./configure ...
If the rebuild fixes it, that's great. Regardless, please report the
problem to the ntop mailing list. Please don't paraphrase the messages
cut & paste the ACTUAL MESSAGES into your report. Also, please let us
know the version(s) of the tools installed on your system:
$ aclocal --version
$ autoheader --version
$ autoconf --version
$ automake --version
$ libtool --version
Q. I can't build ntop... (auto* tools)
A. ntop has been tested with and developed for various versions of
the "GNU auto* tools" (automake, autoconf and libtool).
The basic requirements are
automake 1.6.1 or higher (automake 1.4 and 1.5 may or may not work)
autoconf 2.51 or higher (autoconf 2.13 will NOT work)
libtool 1.4 or higher
But that simple statement hides a lot of complexity and many potential
problems. Surprisingly, this isn't solely ntop's fault, it's the
combination of GNU auto* tools version to version compatiblity and
because we're trying to distribute configure and make files that work
on all versions. If ntop were less complex or less clever about
trying to build a working program even with many components missing,
things would work a lot better.
The big change between autoconf 2.13 and 2.5x generated scripts is that
the ./configure and make steps are supposed to run the auto* commands
automatically if they're required. As we've seen, this doesn't always
work!
If you run into problems, you can ALWAYS recreate the generated files
via this procedure:
rm -f acinclude.m4 aclocal.m4 Makefile.in config.h.in configure Makefile
find current versions of libtool, config.guess and config.sub and cp
them into your working directory.
cat acinclude.m4.ntop libtool.m4.in > acinclude.m4
aclocal
autoheader
autoconf
automake --gnu --copy --add-missing
and then:
./configure ...
make
make install
as usual.
Q. But how does it all hang together?
A. There's a vsd (Visio)/pdf in the docs directory - ntop-autotools.pdf.