From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: pmacct (was Core Update 156) Date: Tue, 11 May 2021 17:44:27 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7273434018854049356==" List-Id: --===============7273434018854049356== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 11 May 2021, at 14:51, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 11/05/2021 15:17, Michael Tremer wrote: >> Hello, >>> On 11 May 2021, at 13:42, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>> On 11/05/2021 13:29, Michael Tremer wrote: >>>> Hello, >>>>> On 11 May 2021, at 12:16, Adolf Belka wrote: >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> With the release of Core Update 156 out of the way is pmacct good to go= for Core Update 157 or are further changes required. >>>> I did not have any plans. The conversation around this has just died ano= ther time and I do not really remember where we left it. >>>=20 >>> Maybe that is my fault. After flagging it for Core Update 156 and it not = making it I presumed I should wait until all Core Update 156 release actions = had been completed as everyone would be busy with that. I didn't want to be a= nuisance with chasing it up. >> No I am not pointing any fingers and I am not annoyed with it being brough= t up again. >>>> I really do not want to carry around stuff that nobody cares about and t= hat the conversation has died multiple times suggests just that. In fact we a= re trying to drop more dead stuff because if nobody updates it and nobody use= s it, what is the point? >>> I understand your point about not wanting dead wood in the addons but I d= on't believe this will be in that category. It will be supported by myself. I= t is being used currently by Jon, Erik and @hellfire to my knowledge as local= addons. >> Yes, I am sure you will update the package, but how does a user use it? Go= ing to the console is a different kind of add-on. Why do we carry vnstatd as = well as pmacct? >>>> What is your view of the things around pmacct? Is it ready? What do user= s gain from having it in the distribution? >>> The v2 update patches were to implement the IPFire Initscript template, r= emove all other daemons except pmacct and pmacctd, remove the example config = files from /etc/pmacct. The v2 patch set was submitted into patchwork on 27th= March. I believe it is ready for release. >>> https://patchwork.ipfire.org/project/ipfire/list/?series=3D1869 >>> In terms of what users gain from having it in the distribution this is al= so in the patch commit and I paste it in here as reference. >>> ---------------------------------------- >>> - What is it? >> I know what it is. I am just asking the question from the angle of the ave= rage IPFire user: If I install it, what can I do with it? Go the configuratio= n file and figure out how to set it up? I could run Debian instead of IPFire = then if I do not get any graphical user interface, etc. >>> pmacct is a monitoring tool for network management tasks. Data collected >>> can be used for analysis and troubleshooting purposes to maintain the >>> health of the network. pmacct can collect, replicate and export network >>> information. It can cache in memory tables, store persistently to SQLit= e3 >>> and output to flat-files like CSV, formatted, and JSON. >>> - Why is it needed? >>> To monitor data usage (IP-based or MAC-based data accounting) down to t= he >>> client level. Net-Traffic will monitor traffic for the entire RED, GREE= N, >>> etc. networks, but it cannot pinpoint which client is using lots of dat= a. >>> Connections will take a snapshot but not show day by day sums. pmacct c= an >>> help admins keep tabs on users that use too much data. >>> - What are the use cases? >>> An ISP may implement data caps and if the limit is over-run then you ha= ve >>> to pay for every additional xxGB of data used. Typical charges can be >>> around $10 per 50GB. With pmacct you can identify the high users and ta= ke >>> action, hopefully before the limit is breached. >> I can=E2=80=99t because I cannot see this on the web UI. Do I build custom= SQL queries to figure this out? Users who can do that can compile pmacct for= themselves, too. >>> - This is being introduced as a command line only tool. However, at a lat= er >>> date, if it is useful to enough additional users a WUI page could be >>> developed as discussed in the development mailing list >>> https://lists.ipfire.org/pipermail/development/2021-January/009174.html >> What is the benefit of CLI-only tools? > OK, you are saying that with IPFire being a web UI based system then new ad= ditions really need to have a WUI provided otherwise the bulk of people won't= be able to use it. I am saying that IPFire is a distribution that is supposed to make configurin= g your network easier and makes that possible without the deepest knowledge o= f how Linux or networks work. The web UI is an essential part of that. There are definitely features that do not fall into that gap as in there are = always exceptions to every rule. > Those people who can cope on the command line with no problems can also bui= ld the addons as local versions. > So if we believe that something has benefits for IPFire we need to look at = it in the context of IPFire for all users. If we would add a line like =E2=80=9CIPFire now comes with pmacct=E2=80=9D to= the change log, we could just as well leave it out. You cannot see it, it is= difficult to use. It has no use for the average user and it provides a funct= ionality we already have in vnstat. Arguably pmacct has more features than vnstat. A system running both is going= to do a lot of work twice. I do not want to blow this out of proportion. I know that you guys have inves= ted a lot of time in it and you like the functionality it provides. So I will= merge it. I will regard it as a feature for developers. It would be great to have these conversations in the first place and then sta= rt working. We regularly get patches from various people (including me) where= someone has spent a lot of time and work. But there might be a reason why th= is should not be merged. The sunken cost fallacy (=E2=80=9Cbut I spent hours = on this=E2=80=9D) does not really matter. That is how we introduce bugs. If t= here is doubt that something isn=E2=80=99t right, it is best to fix it first = and then roll it out instead of trying to fix problems in the field. This case doesn=E2=80=99t have any technical reasons to be rejected, but ther= e are other reasons. I hope it is clear what I am trying to say. Best, -Michael > Regards, > Adolf. >>> ---------------------------------------- >>>> Apart from that, I wanted to close Core Update 157 pretty much this week= because the big things have been merged so far. We have some Python 2 migrat= ion stuff on the list which can wait for 158, it is important but not urgent. >>> Then if it is too late for Core Update 157 then I would like to have it c= ommitted for Core Update 158. >>>=20 >>> Regards, >>> Adolf. >>>> Did I miss anything? >>>> -Michael >>>>> Regards, >>>>>=20 >>>>> Adolf. >>>>>=20 >>>>> On 07/04/2021 18:43, Adolf Belka wrote: >>>>>> Hi All, >>>>>>=20 >>>>>> I submitted the v2 version of pmacct about 10 days ago based on the in= put to the first version. Is this package good to go for CU156 or is further = discussion still needed. >>>>>>=20 >>>>>> I am currently updating bash/readline and a patch will probably be sub= mitted later today or tomorrow. Looking at the changes in bash from 5.0 to 5= .1 I don't see anything that says this update needs to go into CU156 so I wou= ld leave it for CU157. >>>>>>=20 >>>>>> Regards, >>>>>> Adolf. >>>>>>=20 >>>>>>=20 >>>>>> On 07/04/2021 17:04, Michael Tremer wrote: >>>>>>> Hello, >>>>>>>=20 >>>>>>> I would like to formally close Core Update 156 as soon as possible to= merge it into =E2=80=9Cmaster=E2=80=9D and release it to a wider audience fo= r testing. >>>>>>>=20 >>>>>>> Does anyone have any changes that *must* be in this update? >>>>>>>=20 >>>>>>> I have the following things on my list: >>>>>>>=20 >>>>>>> * Dropping macvtap support: This is broken and I do not think that we= would need this because we have bridges. Please review my proposed patch: ht= tps://lists.ipfire.org/pipermail/development/2021-April/009858.html >>>>>>>=20 >>>>>>> * Jonatan wanted to drop the other templates for the web UI >>>>>>>=20 >>>>>>> * Peter has some sysctl changes >>>>>>>=20 >>>>>>> Apart from that I would like to move our attention to testing this up= date and collecting patches for the next update. Core Update 156 is already q= uite large (15 MB compressed on x86_64) and so I would reject any larger chan= ges unless really necessary. >>>>>>>=20 >>>>>>> Lots of thanks to Adolf for putting in so many hours to update all th= ese packages that have received so little love in the past. Especially Perl i= s one of those which take ages and ages :) >>>>>>>=20 >>>>>>> Best, >>>>>>> -Michael --===============7273434018854049356==--