The daemon tries to use either the ipaddr module or the ipaddress module. ... try: import ipaddress except ImportError: import ipaddr as ipaddress ... However, the ipaddress module codepath contains a bug as reported by user bojan against python-ipaddress: https://admin.fedoraproject.org/updates/FEDORA-2015-8290/python-ipaddress-1.0.7-1.fc21 I believe this is because it presumes that if the ipaddress module is present that the environment is Python 3.x+. This is a bad assumption. The end result is that the daemon breaks when python-ipaddress is installed. I propose that pypolicyd-spf be fixed and that it depend on either python-ipaddr or python-ipaddress.
Not as simple as that, it seems. For instance, this package: ---------------- python-pyspf-2.0.11-1.fc22.noarch ---------------- Has the file: ---------------- /usr/lib/python2.7/site-packages/spf.py ---------------- Which does: ---------------- try: # Python standard libarary as of python3.3 import ipaddress except ImportError: try: import ipaddr as ipaddress except ImportError: print('ipaddr module required: http://code.google.com/p/ipaddr-py/') ---------------- So, essentially the same thing as policyd-spf. Even if I just import ipaddr inside /usr/libexec/postfix/policyd-spf, that's not sufficient. It still throws a whole lot of exceptions because the python-pyspf is also using the new ipaddress thing and fails. The python-spf package needs the same change to make things work. And I'm not sure whether that's the whole story... PS. The comment on the updates page is me. :-)
OK, so something like this maybe: ------------------------------------------- --- policyd-spf.original 2014-10-01 13:06:12.000000000 +1000 +++ policyd-spf 2015-06-17 16:38:06.869298047 +1000 @@ -38,10 +38,16 @@ if int(micro) < 7: raise ImportError("At least pyspf 2.0.7 is required.") import policydspfsupp -try: - import ipaddress -except ImportError: - import ipaddr as ipaddress +if sys.version_info[0] >= 3: + try: + import ipaddress + except ImportError: + print('ipaddress module required: http://code.google.com/p/ipaddr-py/') +else: + try: + import ipaddr as ipaddress + except ImportError: + print('ipaddr module required: http://code.google.com/p/ipaddr-py/') try: import authres except: ------------------------------------------- And: ------------------------------------------- --- spf.py.original 2014-12-06 03:20:07.000000000 +1100 +++ spf.py 2015-06-17 16:35:40.192512523 +1000 @@ -98,10 +98,13 @@ from email.message import Message except ImportError: from email.Message import Message -try: +if sys.version_info[0] >= 3: # Python standard libarary as of python3.3 - import ipaddress -except ImportError: + try: + import ipaddress + except ImportError: + print('ipaddress module required: http://code.google.com/p/ipaddr-py/') +else: try: import ipaddr as ipaddress except ImportError: -------------------------------------------
No. That's not right. The package should be able to use the ipaddress module so long as it does not presume Python 3 semantics for the ipaddress module. Properly speaking, I actually think the right thing to do is to remove the dependency on python-ipaddr altogether.
I'm not a python guy at all, so I have no idea what I'm doing there. If you have a better approach/patch etc., please feel free.
Can you get a quick resolution for this problem upstream?
I agree with Nathaniels statement in comment 3. The code should just use the backport of the Python 3.4 ipaddress module. The Python 2.7 backport is fully compatible, with one exception: for packed IP addresses ('\x7f\x00\x00\x01' for 127.0.0.1) the input must be bytesarray instead of bytes. I'm currently travelling, I don't have the sources on my laptop and wifi in my hotel room isn't great. Please try something like this for e.g. policyd-spf import ipaddress import sys def _cidrmatch(ip, netwrk): """Match connect IP against a CIDR network of other IP addresses.""" # ipaddress refuses to work on Python 2.x str # use this workaround if your code never passed packed IP addresses as str if sys.version_info.major < 3: if isinstance(ip, str): ip = ip.decode('ascii') if isinstance(netwrk, str): netwrk = netwrk.decode('ascii') address = ipaddress.ip_address(ip) network = ipaddress.ip_network(netwrk) return address in network print(_cidrmatch(u'192.168.1.15', u'192.168.0.0/22')) print(_cidrmatch('192.168.1.15', '192.168.0.0/22'))
(In reply to Christian Heimes from comment #6) > The Python 2.7 backport is > fully compatible, with one exception: for packed IP addresses > ('\x7f\x00\x00\x01' for 127.0.0.1) the input must be bytesarray instead of > bytes. Again, not a python guy, but can't someone just overload that method to take both? Or is this something python cannot do?
No. This is a language difference between Python 2.x and Python 3.x. If you're not able to fix the package code itself, you should: 1. File an upstream bug. 2. Provide a link to the upstream bug in this bug. 3. Add a Conflicts statement to your package until it works properly.
OK, I'll give patch a along the lines of comment #6 a try. However, python-pyspf will also need to be fixed in a similar way before any of this can work.
I'm building the new packages now, but the update will have to wait for python-pyspf fix (i.e. fix of bug #1232595).
*** Bug 1223173 has been marked as a duplicate of this bug. ***
*** Bug 1241863 has been marked as a duplicate of this bug. ***
It appears bug #1232595 has been resolved. Is there any update for policyd-spf available for fc22 yet?
(In reply to Alex Regan from comment #13) > It appears bug #1232595 has been resolved. Is there any update for > policyd-spf available for fc22 yet? That other bug is not resolved yet.
This is really pretty bad: if you have a server configured with pypolicyd-spf and you upgrade to 23 (or 22?) email delivery will silently break! I only just realized that my server's been rejecting mail to happyassassin.net since I upgraded it on Sunday...
(In reply to awilliam from comment #15) > This is really pretty bad: if you have a server configured with > pypolicyd-spf and you upgrade to 23 (or 22?) email delivery will silently > break! I only just realized that my server's been rejecting mail to > happyassassin.net since I upgraded it on Sunday... Yes, I know. I've been trying to get the maintainer of the other package to release a build with a fix, but to no avail. BTW, the workaround on F-22 for me was to remove python-ipaddress and just leave python-ipaddr.
sadly I can't do that as freeipa-client requires it :( (my servers are all members of my freeipa domain)
(In reply to awilliam from comment #17) > sadly I can't do that as freeipa-client requires it :( (my servers are all > members of my freeipa domain) I'll try to obtain commit access to that other package later on today to fix this. Have to do some other things in the meantime, but hopefully we get this fixed soon.
(In reply to awilliam from comment #17) > sadly I can't do that as freeipa-client requires it :( (my servers are all > members of my freeipa domain) I didn't get commit access yet, but I just attached a package patch to bug #1232595. If you get that, clone the python-pyspf repo, apply the patch and rebuild, you'll get a package that works (at least it did for me). https://bugzilla.redhat.com/attachment.cgi?id=1090446
(In reply to awilliam from comment #15) > This is really pretty bad Still didn't get commit access to that other package (python-pyspf) to fix it and there was no other action in that bug. If you have have The Force with these things, please feel free to wave your hand now... :-)
Bojan, firstly, thanks for creating the patch. Since it looks like we might still be waiting a while for an official fix, any chance of elaborating on your instructions above so I can patch my F23 install?
I can do it, but I'd just like to be clear: your patch appears to make unnecessary/cosmetic changes to pyspf-2.0.11-python2.patch , but the only practical change is to make python-pyspf depend on python-ipaddress instead of python-ipaddr. Is that what it's intended to do, and you're sure that solves the problem?
(In reply to awilliam from comment #22) > I can do it, but I'd just like to be clear: your patch appears to make > unnecessary/cosmetic changes to pyspf-2.0.11-python2.patch , but the only > practical change is to make python-pyspf depend on python-ipaddress instead > of python-ipaddr. Is that what it's intended to do, and you're sure that > solves the problem? It is not a cosmetic change. It removes attempts to use ipaddr as ipaddress, which, if successful, causes the failures. Instead, it just uses ipaddress directly.
(In reply to Peter Pindsle from comment #21) > Bojan, firstly, thanks for creating the patch. Since it looks like we might > still be waiting a while for an official fix, any chance of elaborating on > your instructions above so I can patch my F23 install? Clone python-pyspf git repository (fedpkg clone python-pyspf). Apply the patch to checked out directory. Build locally (fedpkg local).
Bojan: huh, that's odd - when I looked at the patch a couple of hours back it did not have all the changes in it that it has now. Strange.
I'd certainly like to see a change like this submitted upstream too, btw. It's not a good thing to carry downstream in the long term.
I just submitted F22 and F23 updates with Bojan's patch.
(In reply to Bojan Smojver from comment #24) > (In reply to Peter Pindsle from comment #21) > > Bojan, firstly, thanks for creating the patch. Since it looks like we might > > still be waiting a while for an official fix, any chance of elaborating on > > your instructions above so I can patch my F23 install? > > Clone python-pyspf git repository (fedpkg clone python-pyspf). Apply the > patch to checked out directory. Build locally (fedpkg local). Thanks Bojan, I instead downloaded the RPM from https://bugzilla.redhat.com/show_bug.cgi?id=1232595 and confirmed that it works for me
pypolicyd-spf-1.3.1-4.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-87253fc4b9
pypolicyd-spf-1.3.1-4.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update pypolicyd-spf' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-87253fc4b9
pypolicyd-spf-1.3.1-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.