Bug 1131064 - When renaming icmptype dbus objpath is changing
Summary: When renaming icmptype dbus objpath is changing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1017034
TreeView+ depends on / blocked
 
Reported: 2014-08-18 12:50 UTC by Jakub Jelen
Modified: 2014-11-01 16:26 UTC (History)
2 users (show)

Fixed In Version: firewalld-0.3.12-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-01 01:42:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jakub Jelen 2014-08-18 12:50:22 UTC
Description of problem:
There is non-logical behaviour of firewalld when working with icmptypes through d-bus interface.

Renaming ICMP type changes it's object path in d-bus which causes some problems:

 * There is no way how to catch Renamed signal - it is not send to old path and you don't get new object path until you call getIcmpTypeByName but by that time signal is long time gone.

 * Instead of this action fires Remove signal on the old ICMP type which should inform program that it shouldn't work with given path, but it can't resolve if it is really deleted or just renamed.

Why is object path changing when renaming? Is there any good reason?

Version-Release number of selected component (if applicable):
upstream git

How reproducible:
deterministic

Steps to Reproduce:
1. add new icmp type [...config.addIcmpType()]
2. rename to other name [...config.icmptype.rename() on correct path]
3. try to continue working with path from previous point

Actual results:
fails - org.freedesktop.DBus.Error.UnknownMethod

Expected results:
scripts should be able to continue to work wit allocated object patch even after rename. Otherwise it should be mentioned in d-bus documentation.
Additionally there is no point in firing signals on new object paths that were just created.

Comment 1 Jakub Jelen 2014-08-25 12:33:28 UTC
applicable also for zones and services. I'm not sure how to work with this. If you leave me here some note, it would be nice.

Comment 2 Thomas Woerner 2014-08-25 13:09:23 UTC
I agree, it should not happen in this way.

Comment 4 Jakub Jelen 2014-08-26 11:06:28 UTC
Verified. Works fine for me. Updated tests to current behaviour to cover missing parts. Thanks.

Comment 5 Fedora Update System 2014-10-14 16:49:12 UTC
firewalld-0.3.12-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/firewalld-0.3.12-1.fc21

Comment 6 Fedora Update System 2014-10-14 16:50:24 UTC
firewalld-0.3.12-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/firewalld-0.3.12-1.fc20

Comment 7 Fedora Update System 2014-10-16 17:16:56 UTC
Package firewalld-0.3.12-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firewalld-0.3.12-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12912/firewalld-0.3.12-1.fc21
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-11-01 01:42:01 UTC
firewalld-0.3.12-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2014-11-01 16:26:00 UTC
firewalld-0.3.12-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.