All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
Subject: Re: xtables does not reconise ipportiphash/ipportnethash sets
Date: Thu, 23 Sep 2010 01:30:39 +0100	[thread overview]
Message-ID: <4C9A9FAF.8090804@googlemail.com> (raw)
In-Reply-To: <alpine.LNX.2.01.1009230206250.9682@obet.zrqbmnf.qr>


> You willingly chose to use Redhat/Fedora. Now endure the pain! :-)
>   
I just wished I hadn't! 5 minutes ago I found yet ANOTHER bug - this 
time in selinux-policy - the SELinux context on all iptables executables 
is set wrong simply because whoever wrote the policy choose the wrong 
location of these files - in FC13 they are all installed in /sbin, but 
iptables.fc says /usr/sbin so the context is not set. Lovely stuff!

>> Since the 2 kmod-* and xtabbles-addons rpms do not recognise the custom-built
>> string after the kernel version -
>>     
>
> Sounds like another Fedora problem. I know it works in openSUSE,
> but that is probably because they make sure the custom string is
> actually _in_ the version (as evidenced by `uname -r`).
>   
So is on FC13 - I just checked and it is displayed - version + custom 
string. The problem is that the scripts are actually looking for the 
kernel numbers, ASSUMING there is nothing after it. How daft is that?


> Yes, someone made a big boo and furthermore did not send the fix to
> -stable (actually I don't know that), but what I know is that it
> did not appear in -stable yet. And then there is that 2.6.34 is
> no longer maintained. Let alone distros mostly don't even think
> about updating. So everybody using linux-glibc-devel-2.6.34
> (that is the userspace package providing /usr/include/linux) is
> screwed.
> http://bugs.gentoo.org/show_bug.cgi?id=325257
>   
I just found that out to my cost - need to download the patch, update my 
source and rebuild the kernel again, then rinse, repeat with xtables and 
hope that it works.

  reply	other threads:[~2010-09-23  0:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-22 19:19 xtables does not reconise ipportiphash/ipportnethash sets Mr Dash Four
2010-09-22 20:27 ` Jan Engelhardt
2010-09-22 23:23   ` Mr Dash Four
2010-09-23  0:03     ` Mr Dash Four
2010-09-23  0:18     ` Jan Engelhardt
2010-09-23  0:30       ` Mr Dash Four [this message]
2010-09-23  0:55         ` Jan Engelhardt
2010-09-23  1:01           ` Mr Dash Four
2010-09-23 10:28             ` Jan Engelhardt
2010-09-23 10:48               ` Mr Dash Four
2010-09-23 10:57                 ` Jan Engelhardt
2010-09-23 11:21                   ` Mr Dash Four
2010-09-23 12:16                     ` Jan Engelhardt
2010-09-23 12:21                       ` Mr Dash Four
2010-09-23 12:24                         ` Jan Engelhardt
2010-09-23 12:31                           ` Mr Dash Four
2010-09-23 12:49                           ` Mr Dash Four

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C9A9FAF.8090804@googlemail.com \
    --to=mr.dash.four@googlemail.com \
    --cc=jengelh@medozas.de \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.