Hello Robin,

Thanks for your email.

I have seen your patches and I had hoped that somebody else would jump on it and give it a good review.

My priority was indeed lying on getting the current update together and a couple of other things I am working on.

On 7 Apr 2021, at 16:39, Robin Roevens robin.roevens@disroot.org wrote:

Hello

It would be nice to have my zabbix_agentd update in this core update too, which I provided at the start of previous week and seems to be requested by a community member (https://community.ipfire.org/t/zabbix-agent-on-stable-release/3636) since October.

And of course as a newbie here I can't wait for my submission to be reviewed/included. But that should of course not be the reason to try to squeeze it in this update. And apart from that, other than the fact that the current version of zabbix_agentd is very old (august 2019), I don't see any sudden urgent reasons to really have this package included in update 156 as it already was not updated for so long.. And I understand, seeing how much patches where submitted here in the meantime, that the priorities currently are not set on some arbitrary addon package like zabbix_agentd.

Yes this is old. So thank you for looking into this.

So I guess it can wait for 157.

I also noticed that in the meantime there is a Zabbix Agent v5.0.10 (LTS) available, so I will re-submit my patchset shortly upgrading current 4.2.6 to 5.0.10. And then hopefully have it included in 157? Unless you still see a possibility to have it included in 156? :-)

I won’t promise anything, but if I find some time I will review the patches and then we will see.

-Michael

Regards

Robin

Michael Tremer schreef op wo 07-04-2021 om 16:04 [+0100]:

...

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

-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.

Hello,

On 7 Apr 2021, at 17:43, Adolf Belka adolf.belka@ipfire.org 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.

Unless it is security-critical there is probably no difference.

It would be good if we could tag another toolchain soon so that we can merge everything that is still pending in that regard, but we will probably break add-ons if we do not bump the major version number.

Best, -Michael

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

-- Sent from my laptop

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.

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?

What is your view of the things around pmacct? Is it ready? What do users gain from having it in the distribution?

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.

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

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?

---

...

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

Hello,

On 11 May 2021, at 14:51, Adolf Belka adolf.belka@ipfire.org wrote:

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.

I am saying that IPFire is a distribution that is supposed to make configuring your network easier and makes that possible without the deepest knowledge of 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 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.

If we would add a line like “IPFire now comes with pmacct” 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 functionality 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 invested 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 start 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 this should not be merged. The sunken cost fallacy (“but I spent hours on this”) does not really matter. That is how we introduce bugs. If there is doubt that something isn’t 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’t have any technical reasons to be rejected, but there 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 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

Hi,

On 07.04.2021 20:32, Michael Tremer wrote:

Looks like this should be in it:

https://lists.clamav.net/pipermail/clamav-announce/2021/000054.html

Who wants it?

Me.

Update is compiled, ready and running on my production machine.

I'm in the midst of checking and could upload in a few minutes... ;-)

Best, Matthias

-Michael

...

On 7 Apr 2021, at 16:04, Michael Tremer michael.tremer@ipfire.org 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

Hi,

Thank you. That was fast.

My builder is building other things right now, so I will probably merge it in the morning.

-Michael

On 7 Apr 2021, at 20:52, Matthias Fischer matthias.fischer@ipfire.org wrote:

Hi,

On 07.04.2021 20:32, Michael Tremer wrote:

...

Looks like this should be in it:

https://lists.clamav.net/pipermail/clamav-announce/2021/000054.html

Who wants it?

Done. Running. Tested. Works. ;-)

=> https://patchwork.ipfire.org/patch/4119/

=> https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=52d8c885...

Best, Matthias

...

-Michael

...

On 7 Apr 2021, at 16:04, Michael Tremer michael.tremer@ipfire.org 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