[Fli4l_dev] Informationen zum Weekly-Tarball vom 13.6.2013 (r31115)

[Matthias Prager]

Hallo Christoph,

ich antworte mal für meinen Part: Danke für die Infos, ich für meinen
Teil finde solche Hintergründe, wie die conntrack Geschichte immer
interessant.

Ich weiß nicht, welches rrdtool Mark nutzt, aber ich habe in der Tat
hier auch noch das alte im Einsatz. Als ich vor einer Weile auf die
Tarball-Builds gewechselt habe konnte rrdtool3 irgendwas noch nicht so
wie rrdtool (weiß aber nicht mehr genau was das damals war). Also war
ich der Einfachheit halber bei rrdtool geblieben.

Werde das demnächst umstellen, und mich nochmal melden, falls es da noch
irgendwelche Probleme geben sollte.

Viele Grüße
Matthias

Am 17.06.2014 14:53, schrieb Christoph Schulz:
> Hallo!
> 
> Mark Gerber schrieb:
> 
>> Nun habe ich doch zwei Probleme entdeckt, die wohl auf Einsatz des neuen
>> Kernels zurückzuführen sind, weil sie mit dem Kernel 3.10.42-nonfree nicht
>> auftreten:
>>
>> 1. Die Verbindungen werden im Web-Interface nicht aufgeführt, sowohl auf
>> der Seite "Aktive Verbindungen" als auch im RRDtool unter "System" >
>> "Verbindungen".
> 
> Würde ich mir anschauen... wenn du "rrdtool3" geschrieben hättest. Deshalb 
> meine Frage: Vertipper? RRDtool ist End-of-Life, ein Ersatz durch rrdtool3 
> ist meines Wissens schon seit einer gefühlten Ewigkeit in Planung. Ich 
> wette, dass das Verhalten mit der im Kernel 3.15.0 abgeschalteten Option
> 
> CONFIG_NF_CONNTRACK_PROCFS
> 
> "       This option enables for the list of known conntrack entries
>         to be shown in procfs under net/netfilter/nf_conntrack. This
>         is considered obsolete in favor of using the conntrack(8)
>         tool which uses Netlink."
> 
> zu tun hat. Aber auch da werde ich das alte rrdtool wohl nicht mehr 
> anpassen, es sei denn, ich habe gerade gute Laune, viel Zeit oder jemand 
> zwingt mich dazu ;-)
> 
> Aber danke für den Hinweis zu den "Aktiven Verbindungen", dort muss ich den 
> Code so umstellen, dass er das conntrack-Programm nutzt.
> 
>>
>> 2. Das Dateisystem "tmpfs" fehlt und kann deswegen nicht mehr im RRDtool
>> protokolliert werden.
> 
> Huh? Was für ein Dateisystem "tmpfs"?? Ja, das gibt's auch nicht zwingend -- 
> wozu auch? Und wo in der fli4l-Dokumentation steht denn bitte, dass es ein 
> solches Dateisystem geben muss?  Dazu kommt, dass es theoretisch ganz viele 
> solche Dateisysteme geben kann. Hier ein Beispiel mit Kernel 3.10.40:
> 
> fence 3.9.0-r30933M-FFL-506 # uname -a
> Linux fence 3.10.40-virt #1 SMP Wed May 14 16:38:40 CEST 2014 i686 GNU/Linux
> fence 3.9.0-r30933M-FFL-506 # mkdir /tmp/tmpfs
> fence 3.9.0-r30933M-FFL-506 # mount -o size=1024k,mode=755 -t tmpfs tmpfs 
> /tmp/tmpfs/
> fence 3.9.0-r30933M-FFL-506 # mount
> rootfs on / type rootfs (rw)
> tmpfs on / type tmpfs (rw,relatime,size=126320k,nr_inodes=31580,mode=755)
> [...]
> tmpfs on /tmp/tmpfs type tmpfs (rw,relatime,size=1024k,mode=755)
> 
> Vom tmpfs-Dateisystem also auf bestimmte Einhägepunkte zu schließen ist 
> bestenfalls naiv.
> 
> Mit dem 3.15.0 wird das Wurzeldateisystem / so als rootfs-Dateisystem 
> eingebunden, dass man das zugrunde liegende Dateisystem tmpfs nicht sieht. 
> Das ist so und wird nicht geändert, denn das erspart uns die Migration eines 
> nicht Upstream-konformen Patches von Kernel-Version zu Kernel-Version. Bei 
> rrdtol3 gibt es da einen Bug im collectd, der verhindert, dass das 
> Wurzeldateisystem durch das df-Plugin analysiert wird -- das werde ich 
> korrigieren. Aber rrdtool werde ich mir vermutlich nicht mehr antun.
> 
> Vielleicht frage ich mal so herum: Was bietet rrdtool, was rrdtool3 (noch) 
> nicht bietet? Ich kenne darauf nur eine Antwort (verrate sie aber erstmal 
> nicht, um eine Beeinflussung zu verhindern ;-).
> 
> 
> Viele Grüße,
>