Hi Michael,
On 11/05/2021 15:17, Michael Tremer wrote:
Hello,
On 11 May 2021, at 13:42, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 11/05/2021 13:29, Michael Tremer wrote:
Hello,
On 11 May 2021, at 12:16, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
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 another time and I do not really remember where we left it.
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 brought up again.
I really do not want to carry around stuff that nobody cares about and that the conversation has died multiple times suggests just that. In fact we are trying to drop more dead stuff because if nobody updates it and nobody uses it, what is the point?
I understand your point about not wanting dead wood in the addons but I don't believe this will be in that category. It will be supported by myself. It 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? Going 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 users gain from having it in the distribution?
The v2 update patches were to implement the IPFire Initscript template, remove 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=1869 In terms of what users gain from having it in the distribution this is also 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 average IPFire user: If I install it, what can I do with it? Go the configuration 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 SQLite3 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 the client level. Net-Traffic will monitor traffic for the entire RED, GREEN, etc. networks, but it cannot pinpoint which client is using lots of data. Connections will take a snapshot but not show day by day sums. pmacct can 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 have 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 take action, hopefully before the limit is breached.
I can’t 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 later 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 additions really need to have a WUI provided otherwise the bulk of people won't be able to use it. Those people who can cope on the command line with no problems can also build 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.
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 migration 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 committed for Core Update 158.
Regards, Adolf.
Did I miss anything? -Michael
Regards,
Adolf.
On 07/04/2021 18:43, Adolf Belka wrote:
Hi All,
I submitted the v2 version of pmacct about 10 days ago based on the input to the first version. Is this package good to go for CU156 or is further discussion still needed.
I am currently updating bash/readline and a patch will probably be submitted 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 would leave it for CU157.
Regards, Adolf.
On 07/04/2021 17:04, Michael Tremer wrote:
Hello,
I would like to formally close Core Update 156 as soon as possible to merge it into “master” and release it to a wider audience for testing.
Does anyone have any changes that *must* be in this update?
I have the following things on my list:
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: https://lists.ipfire.org/pipermail/development/2021-April/009858.html
Jonatan wanted to drop the other templates for the web UI
Peter has some sysctl changes
Apart from that I would like to move our attention to testing this update and collecting patches for the next update. Core Update 156 is already quite large (15 MB compressed on x86_64) and so I would reject any larger changes unless really necessary.
Lots of thanks to Adolf for putting in so many hours to update all these packages that have received so little love in the past. Especially Perl is one of those which take ages and ages :)
Best, -Michael