[Trunk] vnstat (& Makefile-"SUBOPTS")

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
C

cuma

Aktives Mitglied
Mitglied seit
16 Dez 2006
Beiträge
2,756
Punkte für Reaktionen
7
Punkte
38
Noch ein Tool zum Loggen & Anzeigen des Traffics und der genutzen Bandbreite

Das Pakete ist nun im Trunk mit Webinterface, am besten den Thread von hinten lesen...

Nur mit Binary kann man sich "live" anzeigen lassen:
Code: 
# vnstat -l -i wan
Monitoring wan...    (press CTRL-C to stop)

 wan  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------------
  bytes                    63.27 MiB  |       17.00 MiB
--------------------------------------+------------------------
          max           33.59 Mbit/s  |     2.31 Mbit/s
      average            9.85 Mbit/s  |   635.76 kbit/s
          min               4 kbit/s  |        0 kbit/s
--------------------------------------+------------------------

Mit Daemon kann man im Hintergrund loggen lassen. Ich hab dies in einer autorun.sh
Code: 
ln -s /ANPASSEN/vnstat /var/lib/vnstat
vnstatd -s -d

Jedes Interface muss einmalig initialisiert werden, oder für alle Interfaces:
Code: 
for x in `vnstat -u|tail -n1`; do vnstat -u -i $x; done

Anzeige dann mit
Code: 
 # vnstat -d  -i wan

 wan  /  daily

         day         rx      |     tx      
     ------------------------+-------------
      12/08/09      1.59 GiB |  180.27 MiB 
      12/09/09      3.30 GiB |   61.68 MiB 
      12/10/09      1.03 GiB |  256.85 MiB 
      12/11/09    218.69 MiB |   38.59 MiB


Vielleicht folgt noch ein Webinterface, dies evtl mit vnstati (Beispiel)
 
Zuletzt bearbeitet:
Ich habe mein vnstat auch externalisiert:
Code: 
config EXTERNAL_FREETZ_PACKAGE_VNSTAT
	depends on EXTERNAL_ENABLED && FREETZ_PACKAGE_VNSTAT
	bool "vnstat"
	default n
	help
		externals these file(s):
			/usr/bin/vnstat
 
Danke! Changeset #4040

Hier noch ein Patch für vnstati und libgd. Ein Problem ist aber noch, dass libgd beim -precompiled immer was macht. Hab nur leider keine Ahnung wie ich das wegbekomme...
Die .mk hat auch noch einen Bug. Es landen immer aller 2 bzw 3 Binarys im Image.
 
Zuletzt bearbeitet:
Code: 
$(PKG)_BINARIES_ALL := vnstat vnstatd vnstati
$(PKG)_BINARIES := $(filter-out $(if $(FREETZ_PACKAGE_VNSTAT_DAEMON),,vnstatd),$($(PKG)_BINARIES_ALL))
$(PKG)_BINARIES := $(filter-out $(if $(FREETZ_PACKAGE_VNSTAT_IMAGE),,vnstati),$($(PKG)_BINARIES_ALL))
Wenn du immer alle Binaries auswählst, dann landen natürlich auch alle im Image...
Code: 
--- make/libs/gd.mk.orig        2009-12-16 17:36:43.000000000 +0000
+++ make/libs/gd.mk     2009-12-16 17:33:05.000000000 +0000
@@ -2,7 +2,7 @@
 $(PKG)_LIB_VERSION:=2.0.0
 $(PKG)_SOURCE:=gd-$($(PKG)_VERSION).tar.bz2
 $(PKG)_SITE:=http://www.libgd.org/releases
-$(PKG)_BINARY:=$($(PKG)_DIR)/src/.libs/libgd.so.$($(PKG)_LIB_VERSION)
+$(PKG)_BINARY:=$($(PKG)_DIR)/.libs/libgd.so.$($(PKG)_LIB_VERSION)
 $(PKG)_STAGING_BINARY:=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/libgd.so.$($(PKG)_LIB_VERSION)
 $(PKG)_TARGET_BINARY:=$($(PKG)_TARGET_DIR)/libgd.so.$($(PKG)_LIB_VERSION)
 $(PKG)_SOURCE_MD5:=6c6c3dbb7bf079e0bb5fbbfd3bb8a71c
Pfad zur Lib stimmt nicht.

MfG Oliver
 
habe cuma in PN schon geschrieben, es sollte
Code: 
$(PKG)_BINARIES := $(filter-out $(if $(FREETZ_PACKAGE_VNSTAT_DAEMON),,vnstatd) $(if $(FREETZ_PACKAGE_VNSTAT_IMAGE),,vnstati),$($(PKG)_BINARIES_ALL))
heißen.

Die Link-Option lautet -lgd und nicht -llibgd.

Weiterhin fehlen in der .mk
Code: 
$(PKG)_CONFIG_SUBOPTS += FREETZ_PACKAGE_VNSTAT_DAEMON
$(PKG)_CONFIG_SUBOPTS += FREETZ_PACKAGE_VNSTAT_IMAGE
 
Danke euch beiden, funktioniert jetzt soweit. Man darf halt nur nicht mehr als 1 Datei bauen und danach weniger, da dann trotzdem alle ins Image kopiert werden.
Man kommt wohl um zusätzlich clean-Targets wie hier nicht herum?
 
Hab es ausprobiert, funktioniert nicht
 
cuma, Du findest aber Bugs :)

Wenn ich die Ursache richtig verstehe, besteht dieses Problem generell bei allen Paketen, die mehrere Binaries zur Verfügung stellen. Der angehängte Patch stellt eine mögliche Lösung dar, wurde aber mangels Zeit kaum getestet (im Grunde genommen nur mit vnstat)...

Wenn jemandem was besseres einfällt, bin ich ganz Ohr, explizite clean-targets halte ich aber für Unsinn.
 

Anhänge

  • clean_pkg_target_dir_on_suboption_change.patch.txt
    1.6 KB · Aufrufe: 7
Wie wäre es denn analog wie beim openssh.mk?

Code: 
# SSH keyutil binaries
$(OPENSSH_KEYUTILS_SSHKEYGEN_TARGET_BINARY): $(OPENSSH_KEYUTILS_SSHKEYGEN_BINARY)
ifeq ($(strip $(FREETZ_PACKAGE_OPENSSH_KEYUTILS)),y)
	$(INSTALL_BINARY_STRIP)
else
	$(RM) $(OPENSSH_KEYUTILS_SSHKEYGEN_TARGET_BINARY)
endif

Jörg
 
Wie gesagt, explizite clean-targets mag ich nicht, denn sie müssten bei jedem Paket implementiert werden, die im Patch angebotene Lösung ist dagegen allgemein
 
... die Idee, erstmal alles zu Löschen, um das benötigte zurückzukopieren finde ich nicht so toll.
Das Optimum aus meiner Sicht wäre eine Art "COND_INST_RM_BINARY_STRIP" ;-) was in Abhängigkeit vom entsprechenden Schalter für das Binary das nicht vorhandene Binary kopiert (und stripped) oder das überflüssige löscht...

Jörg
 
@MaxMuster: Die nicht benötigten Binaries sind gar nicht in der $(PKG)_BINARIES-VARIABLE enthalten. D.h. dieses COND*-Macro eignet sich nur für Pakete, die für jedes BINARY eine explizite Regel definieren (was ich auch nicht toll finde, da es meistens nichts anderes als Code-Clones sind). Für Pakete, die static-pattern-rules verwenden, müsste eine zweite Variable definiert werden, die die nicht benötigten Binaries enthält und eine Regel, die diese löscht. Ich finde meine Lösung gar nicht so schlecht, denn wie oft kommt es schon vor, dass man Paket-Teile abwählt, einmal, höchstens zwei, da kann man schon alles löschen, um sicherzustellen, dass es keine Überreste von den vorigen Builds gibt.

@cuma: libgd lässt sich bei mir nicht übersetzen. Es wird versucht, host-libraries zu verwenden:
Code: 
/home/gene/freetz/freetz-trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc -shared  .libs/gd.o .libs/gdfx.o .libs/gd_security.o .libs/gd_gd.o .libs/gd_gd2.o .libs/gd_io.o .libs/gd_io_dp.o .libs/gd_gif_in.o .lib s/gd_gif_out.o .libs/gd_io_file.o .libs/gd_io_ss.o .libs/gd_jpeg.o .libs/gd_png.o .libs/gd_ss.o .libs/gd_topal.o .libs/gd_wbmp.o .libs/gdcache.o .libs/gdfontg.o .libs/gdfontl.o .libs/gdfontmb.o .libs/gdfonts.o .
libs/gdfontt.o .libs/gdft.o .libs/gdhelpers.o .libs/gdkanji.o .libs/gdtables.o .libs/gdxpm.o .libs/wbmp.o  -L/usr/lib -lm  -march=4kc -Wl,-soname -Wl,libgd.so.2 -o .libs/libgd.so.2.0.0
/home/gene/freetz/freetz-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.2.4/../../../../mipsel-linux-uclibc/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/home/gene/freetz/freetz-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.2.4/../../../../mipsel-linux-uclibc/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/home/gene/freetz/freetz-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.2.4/../../../../mipsel-linux-uclibc/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/home/gene/freetz/freetz-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.2.4/../../../../mipsel-linux-uclibc/bin/ld: skipping incompatible /usr/lib/libc.a w hen searching for -lc
Magels Zeit noch nicht weiter untersucht, eventuell nur -L Option falsch.

p.s. Und ist diese gd nicht die gleiche Lib, die auch php braucht. Es wäre nicht schlecht, wenn diese bei php dynamisch eingebunden wäre.
 
Das Löschen aller Pakete bei Veränderung irgendeines Parameters finde ich halt persönlich "zu unelegant" ;-).
Da die Differenz von $(PKG)_BINARIES_ALL und $(PKG)_BINARIES_ALL ja durchaus bekannt ist und sowas wie "$(PKG)_BINARIES_NOT_USED" wäre, kann man aus meiner Sicht durchaus statt des oben genannten Wegs auch diese Liste dann explizit zu löschen versuchen (auch, wenn sie gar nicht da sind), was dann eben nur genau solche "Spezialpakete" mit veränderbarem Binary-Umfangs erfasste.

Letztlich ist das aber reine Geschmackssache. Wo du auf jeden Fall Recht hast: die Code-Clones sind natürlich möglichst noch weiter zu beschränken, da ist OpenSSH noch ein guter Kandidat, mal sehen, wann ich etwas Zeit über habe....

Jörg
 
MaxMuster schrieb:
Das Löschen aller Pakete bei Veränderung irgendeines Parameters finde ich halt persönlich "zu unelegant" ;-).
Zum Vergrößern anklicken....
Hmm, alle? Es wird nur das Paket gelöscht, dessen SubOpts sich geändert haben. Mein "alles" bezog sich auf alle Dateien eines Pakets.
 
... das meinte ich ja auch ;-).
Wenn ich z.B. im OpenVPN irgendeine der vier Unteroptionen ändere, die das (einzige) Binary verändern, dann würde, wenn ich deinen Ansatz recht verstanden habe, auch dabei das Paketverzeichnis gelöscht, obwohl eingentlich "überflüssig"...

Ist ja auch nur meine Ansicht, und du hast danach gefragt ;-) ;-)

Jörg
 
Wieso ist es denn überflüssig? Nachdem Du openvpn mit liblzo gebaut hast, baust Du es jetzt ohne. Damit wird openvpn zum einen komplett neugebaut und zum anderen werden die alten Binaries im Zielverzeichnis dabei überschrieben. Jetzt lösche ich halt dieses Zielverzeichnis des Pakets komplett (in dem nochmal sowieso alles überschrieben wird) und löse damit gleichzeitig das Problem mit den abgewählten Binaries und zwar auf generische Art.
 
Ich versuche es mal etwas ausführlicher:

Soweit ich das verstanden hatte, bleibt (momentaner Stand) das komplette Verzeichnis packages/<welchespaket auch immer> genauso bestehen, wie es ist; nur die veränderten Binaries werden über ein vorhandenes kopiert und (das ist hier das Problem) die für die neue Auswahl nicht mehr benötigten Dateien (die "unnötigen" Binaries) bleiben ebenfalls vorhanden.
Für das OpenVPN-Beispiel heißt das: Nur und ausschließlich das geänderte OpenVPN-Binary wird in dem packages-Ordner geändert sein, genauso, wie ich es erwarten würde, wenn sich nur das Binary ändert.
Alle Änderungen, die ich an CGI, default-Werten usw. in dem Ordner gemacht habe, sind nach dem Make-Lauf noch immer vorhanden. Wie gesagt, das wäre auch mein Verständnis davon, was passiert, wenn ich im menuconfig die Binary-Optionen ändere.

Wenn ich deinen Ansatz richtig verstanden habe, würdest du in diesem Fall auch das komplette Verzeichnis löschen und aus dem "make/openvpn/files/root"-Ordner neu erstellen, das ist deutlich anders, als jetzt.

Aber vielleicht warten wir mal, ob sonst noch wer eine Meinung zu dem Thema hat...

Jörg
 
Hab keine Meinung mangels :noidea:

Hier noch ein Screenshot vom vnstat-cgi:
 
Zuletzt bearbeitet:
Beim Versuch vnstat-cgi zu bauen kommt nachfolgende Fehlermeldung:

Code: 
./libtool: line 841: X--tag=CC: command not found
./libtool: line 841: X--tag=CC: command not found
./libtool: line 874: libtool: ignoring unknown tag : command not found
./libtool: line 874: libtool: ignoring unknown tag : command not found
./libtool: line 841: X--mode=compile: command not found
./libtool: line 841: X--mode=compile: command not found
./libtool: line 1007: *** Warning: inferring the mode of operation is deprecated.: command not found
./libtool: line 1008: *** Future versions of Libtool will require --mode=MODE be specified.: command not found
./libtool: line 1151: X/home/chaos/test-trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc: No such file or directory
./libtool: line 1151: X-DHAVE_CONFIG_H: command not found
./libtool: line 1151: X-I.: command not found
./libtool: line 1151: X-I.: command not found
./libtool: line 1151: X-I.: command not found
./libtool: line 1007: *** Warning: inferring the mode of operation is deprecated.: command not found
./libtool: line 1008: *** Future versions of Libtool will require --mode=MODE be specified.: command not found
./libtool: line 1151: X-I/home/chaos/test-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include/freetype2: No such file or directory
./libtool: line 1151: X/home/chaos/test-trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc: No such file or directory
./libtool: line 1151: X-DHAVE_CONFIG_H: command not found
./libtool: line 1151: X-I/home/chaos/test-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include: No such file or directory
./libtool: line 1151: X-I.: command not found
./libtool: line 1151: X-I/usr/include: No such file or directory
./libtool: line 1151: X-Os: command not found
./libtool: line 1151: X-pipe: command not found
./libtool: line 1151: X-march=4kc: command not found
./libtool: line 1151: X-Wa,--trap: command not found
./libtool: line 1151: X-D_LARGEFILE_SOURCE: command not found
./libtool: line 1151: X-D_LARGEFILE64_SOURCE: command not found
./libtool: line 1151: X-D_FILE_OFFSET_BITS=64: command not found
./libtool: line 1151: X-MT: command not found
./libtool: line 1151: X-I.: command not found
./libtool: line 1151: Xgdfx.lo: command not found
./libtool: line 1151: X-I.: command not found
./libtool: line 1151: X-I/home/chaos/test-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include/freetype2: No such file or directory
./libtool: line 1151: X-MD: command not found
./libtool: line 1151: X-I/home/chaos/test-trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include: No such file or directory
./libtool: line 1151: X-MP: command not found
./libtool: line 1151: X-I/usr/include: No such file or directory
./libtool: line 1151: X-MF: command not found
./libtool: line 1151: X-Os: command not found
./libtool: line 1151: X.deps/gdfx.Tpo: No such file or directory
./libtool: line 1151: X-pipe: command not found
./libtool: line 1151: X-march=4kc: command not found
./libtool: line 1151: X-Wa,--trap: command not found
./libtool: line 1151: X-c: command not found
./libtool: line 1151: X-D_LARGEFILE_SOURCE: command not found
./libtool: line 1202: Xgdfx.lo: command not found
./libtool: line 1151: X-D_LARGEFILE64_SOURCE: command not found
./libtool: line 1207: libtool: compile: cannot determine name of library object from `': command not found
./libtool: line 1151: X-D_FILE_OFFSET_BITS=64: command not found
make[3]: *** [gdfx.lo] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
./libtool: line 1151: X-MT: command not found
./libtool: line 1151: Xgd.lo: command not found
./libtool: line 1151: X-MD: command not found
./libtool: line 1151: X-MP: command not found
./libtool: line 1151: X-MF: command not found
./libtool: line 1151: X.deps/gd.Tpo: No such file or directory
./libtool: line 1151: X-c: command not found
./libtool: line 1202: Xgd.lo: command not found
./libtool: line 1207: libtool: compile: cannot determine name of library object from `': command not found
make[3]: *** [gd.lo] Fehler 1
make[3]: Verlasse Verzeichnis '/home/chaos/test-trunk/source/gd-2.0.35'
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlasse Verzeichnis '/home/chaos/test-trunk/source/gd-2.0.35'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/home/chaos/test-trunk/source/gd-2.0.35'
make: *** [source/gd-2.0.35/.libs/libgd.so.2.0.0] Fehler 2

Umgebung: Ubuntu 9.10
Trunk 4052 frisch ausgecheckt
frische Config quasi nur vnstat-cgi ausgewählt
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 576 (Mitglieder: 7, Gäste: 569)

Neueste Beiträge

Statistik des Forums

Themen
246,195
Beiträge
2,247,818
Mitglieder
373,748
Neuestes Mitglied
fanti88
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück