Bug 13159

A clarification comment to summarize the discussion brought forward in the community forum by iptom (which discovered and reported the bug).

Since the introduction of multi-interface monitoring in version 1.7.1, a key configuration change has been introduced in pmacct. The configuration key for a single interface has been modified from `interface:` to `pcap_interface:`. This change is necessary to support the new functionality and should be updated accordingly in the configuration file provided by the plugin.

I forgot to mention that currently, if `pcmactt.conf` contains the line `interface:green0`, the software generates a warning. However, the interface is correctly assigned by default. My assumption is that if a user sets a different interface, `green0` will be the one assigned instead.

I opened an Issue report on pmacct GitHub:

https://github.com/pmacct/pmacct/issues/699

response from Paolo from pmacct GitHub:

> Yes, and once in a while we can claim victory of documentation: the fact interface and interface_wait were obsoleted was mentioned in the UPGRADE notes file.

https://github.com/pmacct/pmacct/issues/699#issuecomment-1610570014

And from the `UPGRADE` docs:
https://github.com/pmacct/pmacct/blob/master/UPGRADE#L55-L70

---

So bottom line is the "interface: to pcap_interface fix" for pmacct.conf is definitely the right fix!  And each user's pmacct.conf file would need a one line change from:
interface:  <existingWord>
-to-
pcap_interface:  <existingWord>

Without changing other lines in their config file.  At the moment I am not sure how to do this...

Do we ask users to do this manually?  Or does this become an update via pakfire?

(In reply to Jon from comment #3)
> 
> So bottom line is the "interface: to pcap_interface fix" for pmacct.conf is
> definitely the right fix!  And each user's pmacct.conf file would need a one
> line change from:
> interface:  <existingWord>
> -to-
> pcap_interface:  <existingWord>
> 
> Without changing other lines in their config file.  At the moment I am not
> sure how to do this...
> 

The simplest way would be to create a pmacct specific paks set of scripts and add into the install.sh script, after the backup restore step, a sed command to look for interface: and replace it with pcap_interface:

The regex needs to look for interface: starting at the first character of the line and only then replacing it with pcap_interface:

The step needs to be done after the backup restore so that the actually used conf file is modified.

The change also needs to be made in the default pmacct.conf file.

I made the changes to install.sh and I am waiting for make build to finish (and for me to test).

Below it the code I added...

```
. /opt/pakfire/lib/functions.sh

extract_files
restore_backup ${NAME}

#	update needed for a change in config file
#		temporary update added for CU 177
CONFIG="/etc/pmacct/pmacct.conf"
if grep -q "^interface" "${CONFIG}" ; then		#
	if sed -i .bak 's|^interface|pcap_interface|g' "${CONFIG}" ; then
		logger -t pmacct "updated ${CONFIG} and changed \"interface\" to \"pcap_interface\""
	fi
fi

# Add symlinks for runlevels
ln -s ../init.d/${NAME} /etc/rc.d/rc0.d/K85${NAME}
ln -s ../init.d/${NAME} /etc/rc.d/rc3.d/S50${NAME}
ln -s ../init.d/${NAME} /etc/rc.d/rc6.d/K85${NAME}
start_service ${NAME}

# EOF
```

Patch:
https://patchwork.ipfire.org/project/ipfire/patch/20230706021750.1739686-1-jon.murphy@ipfire.org/

Please hold this!  I added a space in a command and it is causing an error.

This line:
if sed -i .bak 's|

Should be this:
if sed -i.bak 's|


I will change it

Patch V2:

https://patchwork.ipfire.org/project/ipfire/patch/20230706210506.983914-1-jon.murphy@ipfire.org/

sorry for the screw-up (and extra noise!)

Sorry @Jon but ON_QA only gets set when the fix has been put into the Testing Repository, Core Update xxx Testing has been released with the fix comitted.

MODIFIED status only gets set when the patch fix has been comitted into the git repository (usually next).

So this bug still has to stay at ASSIGNED, or it could be changed to ON_DEV if the fix is taking a lot of work and testing to resolve.

See the wiki page on the bug workflow

https://wiki.ipfire.org/devel/bugzilla/workflow

I've been starring at the page since before I updated.  It not quite making sense...

So after I submit the patch in #C8, does the status change from ASSIGNED?

(In reply to Jon from comment #10)
> I've been starring at the page since before I updated.  It not quite making
> sense...
> 
> So after I submit the patch in #C8, does the status change from ASSIGNED?

No, I am afraid not. It stays at ASSIGNED after the patch is submitted. It only changes to MODIFIED when the patch you submitted has been reviewed and accepted and has been committed (ie merged) into the IPFire git repo.

There is no separate status for when the patch has been submitted.

Sorry @Jon. It looks like I made a mistake when I checked if the patch had been committed in my comment 9. Checking today I see the patch was committed on 13th July which is the day before I made my comment 9.

So this bug can now have its status changed to MODIFIED.

I should also have included the link to the commit.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=525e575e0463d9275904ec1273b650859e5358c3

(In reply to Adolf Belka from comment #12)
> Sorry @Jon. It looks like I made a mistake when I checked if the patch had
> been committed in my comment 9. Checking today I see the patch was committed
> on 13th July which is the day before I made my comment 9.
> 
> So this bug can now have its status changed to MODIFIED.

So what is it that you saw (and where) that told you it was committed?

I go into the IPFire2.x git repo and select next in the HEADS section and that gives you the shortlog of all commits from next backwards. I saw your entry 	pmacct: fix bug 13159 in the list

https://git.ipfire.org/?p=ipfire-2.x.git;a=shortlog;h=refs/heads/next

You can also go into the commit and see who committed it and when.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=525e575e0463d9275904ec1273b650859e5358c3

Patch is in CU177 Testing

https://blog.ipfire.org/post/ipfire-2-27-core-update-177-released