Trivial connlimit and IPMARK patch for 2.6.16

Trivial connlimit and IPMARK patch for 2.6.16

[Grzegorz Janoszka]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 469 bytes --]


Hello,

Due to move of some targets from iptables to xtables, some 
patches turned to "not applyable", becouse their Makefile.ladd files
tried to add iptables entries just after a target, that had been moved 
from iptables to xtables.

Attached patch solves this problem, it only modifies Makefile.ladd files 
of connlimit and IPMARK. The patch is to patch-o-matic-ng-20060401 but it 
should apply clearly on any latest pom-ng.

Please apply it.

-- 
Grzegorz Janoszka

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1245 bytes --]

diff -urN patch-o-matic-ng-20060401-old/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd patch-o-matic-ng-20060401/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd
--- patch-o-matic-ng-20060401-old/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd	2004-05-06 14:52:37.000000000 +0200
+++ patch-o-matic-ng-20060401/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd	2006-04-03 23:14:20.000000000 +0200
@@ -1,2 +1,2 @@
-obj-$(CONFIG_IP_NF_MATCH_STATE) += ipt_state.o
+obj-$(CONFIG_IP_NF_MATCH_TOS) += ipt_tos.o
 obj-$(CONFIG_IP_NF_MATCH_CONNLIMIT) += ipt_connlimit.o
diff -urN patch-o-matic-ng-20060401-old/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd patch-o-matic-ng-20060401/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd
--- patch-o-matic-ng-20060401-old/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd	2004-05-06 14:23:54.000000000 +0200
+++ patch-o-matic-ng-20060401/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd	2006-04-03 23:11:57.000000000 +0200
@@ -1,2 +1,2 @@
-obj-$(CONFIG_IP_NF_TARGET_MARK) += ipt_MARK.o
+obj-$(CONFIG_IP_NF_TARGET_TTL) += ipt_TTL.o
 obj-$(CONFIG_IP_NF_TARGET_IPMARK) += ipt_IPMARK.o

Re: Trivial connlimit and IPMARK patch for 2.6.16

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

On Tue, Apr 04, 2006 at 12:09:52AM +0200, Grzegorz Janoszka wrote:
> 
> Hello,
> 
> Due to move of some targets from iptables to xtables, some patches turned to "not applyable", becouse 
> their Makefile.ladd files
> tried to add iptables entries just after a target, that had been moved from iptables to xtables.
> 
> Attached patch solves this problem, it only modifies Makefile.ladd files of connlimit and IPMARK. The 
> patch is to patch-o-matic-ng-20060401 but it should apply clearly on any latest pom-ng.

I'm not really in the mood of manually adding such patches to svn.

I'm not really sure on the future of patch-o-matic as a whole.  At least
I haven't really used any of the patches from there or updated anything
or tested whether it applies for at least half a year.

So unless somebody actually wants to become patch-o-matic maintainer
(yes, we once had somebody for that job), I think it's going to die.

Patrick, any news on that 'patch o matic remote repositories' idea?

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

The future of patch-o-matic-ng

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

On Wed, Apr 05, 2006 at 09:52:48PM +0200, Grzegorz Janoszka wrote:
> On Wed, 5 Apr 2006, Harald Welte wrote:
> 
> >So unless somebody actually wants to become patch-o-matic maintainer
> >(yes, we once had somebody for that job), I think it's going to die.
> 
> I can try. 

Well, as it seems I should have read netfilter-devel in chronological
order rather than backwards.  Patrick has already posted on how to
proceed with patch-o-matic-ng a couple of days ago:  Have the original
authors (or other people who want to maintain patchlets) host their own
repositories.  Patch-o-matic-ng would then mostly only contain a list of
URL's to such remote repositories.  This way there is no need for the
netfilter developers themselves to maintain patchsets.

> Pom is used by many people, please don't let it die. If you have
> nobody to take care of it, give it to me.

As indicated in Patricks mail, there's a 30 day grace period.  Until
then the original authors (if they care) or other people can take
maintenance for individual patchlets and send us URL's to those
repositories.  We will add them to our list file, and distribute a
'runme' script which downloads those repositories off the net.

If you want to help, I suggest to wait for those patchlets that nobody
takes care of, and run a repository for them.

Also, I assume that there is a lot that can be done to improve that
patchlet-handling script, i.e. add suport for GPG signature checking and
the like.  I suggest you coordinate with Patrick on this.

If any of the 'patchlet maintainers' require a place where they can put
repositories online via http/ftp, please let me know, we have
people.netfilter.org accounts exactly for this purpose.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: The future of patch-o-matic-ng

[Patrick McHardy]

Harald Welte wrote:
> As indicated in Patricks mail, there's a 30 day grace period.  Until
> then the original authors (if they care) or other people can take
> maintenance for individual patchlets and send us URL's to those
> repositories.  We will add them to our list file, and distribute a
> 'runme' script which downloads those repositories off the net.
> 
> If you want to help, I suggest to wait for those patchlets that nobody
> takes care of, and run a repository for them.

As a side-note: anyone who decides to take maintanance for some
patchlet, please drop me a short note, so I can keep a list
of unmaintained patches.

> Also, I assume that there is a lot that can be done to improve that
> patchlet-handling script, i.e. add suport for GPG signature checking and
> the like.  I suggest you coordinate with Patrick on this.

Definitely. The code is very basic, it only makes sure a patchlet
1) doesn't overwrite anything outside of its patchlet directory
2) can only overwrite "Repository: external" patchlets

But doensn't do any signature verification. I'll add it today,
patches are welcome.

Re: The future of patch-o-matic-ng

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1699 bytes --]



On Thu, 6 Apr 2006, Patrick McHardy wrote:

> Harald Welte wrote:
>> As indicated in Patricks mail, there's a 30 day grace period.  Until
>> then the original authors (if they care) or other people can take
>> maintenance for individual patchlets and send us URL's to those
>> repositories.  We will add them to our list file, and distribute a
>> 'runme' script which downloads those repositories off the net.
>>
>> If you want to help, I suggest to wait for those patchlets that nobody
>> takes care of, and run a repository for them.
>
> As a side-note: anyone who decides to take maintanance for some
> patchlet, please drop me a short note, so I can keep a list
> of unmaintained patches.

If there are no other volenteers I would like to keep following patchlets:
  - TARPIT
  - connlimit
  - geoip
  - ipp2p
  - time

What about ROUTE, ipv4options, random, u32? Are they going to be 
included in mainline?

>> Also, I assume that there is a lot that can be done to improve that
>> patchlet-handling script, i.e. add suport for GPG signature checking and
>> the like.  I suggest you coordinate with Patrick on this.
>
> Definitely. The code is very basic, it only makes sure a patchlet
> 1) doesn't overwrite anything outside of its patchlet directory
> 2) can only overwrite "Repository: external" patchlets
>
> But doensn't do any signature verification. I'll add it today,
> patches are welcome.

So, this external repository will be used only by netfilter server to 
download patchlets? People will be still able to download complete pom-ng 
package? How it is better from giving access to the svn server?

Best regards,

 			Krzysztof Olędzki

Re: The future of patch-o-matic-ng

[Patrick McHardy]

Krzysztof Oledzki wrote:
> If there are no other volenteers I would like to keep following patchlets:
>  - TARPIT
>  - connlimit
>  - geoip
>  - ipp2p
>  - time

Thanks, I've updated my list. I think some of these are actually
actively maintained. If a maintainer itself offers to keep a
repository, he will most likely be prefered.


> What about ROUTE, ipv4options, random, u32? Are they going to be
> included in mainline?

ROUTE will be kept in pomng, ipv4options will be merged, random will
be merged with nth and then go into the kernel (I've already started
this), u32 will also go in the kernel.

>>> Also, I assume that there is a lot that can be done to improve that
>>> patchlet-handling script, i.e. add suport for GPG signature checking and
>>> the like.  I suggest you coordinate with Patrick on this.
>>
>>
>> Definitely. The code is very basic, it only makes sure a patchlet
>> 1) doesn't overwrite anything outside of its patchlet directory
>> 2) can only overwrite "Repository: external" patchlets
>>
>> But doensn't do any signature verification. I'll add it today,
>> patches are welcome.
> 
> 
> So, this external repository will be used only by netfilter server to
> download patchlets? People will be still able to download complete
> pom-ng package? How it is better from giving access to the svn server?

No, it will be used by users to download patchlets.

BTW, the code is in SVN now.

Re: The future of patch-o-matic-ng

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 700 bytes --]



On Thu, 6 Apr 2006, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> If there are no other volenteers I would like to keep following patchlets:
>>  - TARPIT
>>  - connlimit
>>  - geoip
>>  - ipp2p
>>  - time
>
> Thanks, I've updated my list. I think some of these are actually
> actively maintained. If a maintainer itself offers to keep a
> repository, he will most likely be prefered.

Sure! I volunteered as I have in my queue ready-for-send patches for
connlimit and geoip and have been sending patches for ipp2p/time (and some
other patchlets) in pom-ng for some time. But of course original authors 
are defintelly preferred.

Best regards,

 				Krzysztof Olędzki

Re: The future of patch-o-matic-ng

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Thu, Apr 06, 2006 at 12:34:21PM +0200, Krzysztof Oledzki wrote:
> So, this external repository will be used only by netfilter server to
> download patchlets? People will be still able to download complete
> pom-ng package? 

No, users will actually only download 

> How it is better from giving access to the svn server?

for security reasons we only do svn-over-webdav-over-https with client
based certificates.  Therefore, it's not very easy to handle, both on
the 'user/developer' side, as well with regards to maintenance on our
side.

Also, using fine-grained permission control (such as giving some 30+
individual developers access to only their patchlet-subdirectories) is a
configuration nightmare.

Therefore, we prefer not to give svn access to people outside the core
development community, webaster, etc.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: The future of patch-o-matic-ng

[Carl-Daniel Hailfinger]

Harald Welte schrieb:
> On Thu, Apr 06, 2006 at 12:34:21PM +0200, Krzysztof Oledzki wrote:
> 
>>So, this external repository will be used only by netfilter server to
>>download patchlets? People will be still able to download complete
>>pom-ng package? 
> 
> No, users will actually only download 

And exactly that's the problem with the proposed change. The value
of pom-ng was not a central list of patches (I can always get that
from the netfilter web site), but the packaged collection.

So if you really don't want to package patches from other sources
anymore, please be honest and call the new package pom-coreteam
or something like that.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: The future of patch-o-matic-ng

[Patrick Schaaf]

> So if you really don't want to package patches from other sources
> anymore, please be honest and call the new package pom-coreteam
> or something like that.

What has honesty to do with naming things?

As far as I can see, the core team is honestly telling us what
they are going to do, and why. Happy naming games don't enter
into this feeling of mine.

best regards
  Patrick

Re: The future of patch-o-matic-ng

[Carl-Daniel Hailfinger]

Patrick Schaaf schrieb:
>>So if you really don't want to package patches from other sources
>>anymore, please be honest and call the new package pom-coreteam
>>or something like that.
> 
> What has honesty to do with naming things?

Sorry, english is my second language. Maybe "broken expectation"
would be a better description.

> As far as I can see, the core team is honestly telling us what
> they are going to do, and why. Happy naming games don't enter
> into this feeling of mine.

Yes. I always treated pom-ng as patch collection which is usable
offline. With the proposed change, it becomes a mix of patch
collection and patch list. Packaging a patch list doesn't make
sense, but packaging a link to a package list makes sense. If
I already have to download patches on the machine where I want
to apply them (no offline capability anymore), I can as well
get the patch list from a link on the netfilter.org site.
And if the linux machine has no network, I can simply download
the packages via the link on the netfilter.org site on another
machine.

Changing the name to pom-coreteam would give others the chance
to provide a package with the same features and same name as
the current pom-ng.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: The future of patch-o-matic-ng

[Patrick McHardy]

Carl-Daniel Hailfinger wrote:
> Yes. I always treated pom-ng as patch collection which is usable
> offline. With the proposed change, it becomes a mix of patch
> collection and patch list. Packaging a patch list doesn't make
> sense, but packaging a link to a package list makes sense. If
> I already have to download patches on the machine where I want
> to apply them (no offline capability anymore), I can as well
> get the patch list from a link on the netfilter.org site.
> And if the linux machine has no network, I can simply download
> the packages via the link on the netfilter.org site on another
> machine.
> 
> Changing the name to pom-coreteam would give others the chance
> to provide a package with the same features and same name as
> the current pom-ng.

I honestly don't care about the name at all, but I don't really
see the point. We're pushing the good stuff to the kernel,
which should benefit everyone. Old, broken and obscure patches
are moved out, as are patches that are not ready for mainline
where we don't have enough interest in getting them ready ourselves.
You are of course welcome to work on these patches to get them
mergable. Ideally we will just obsolete pom.

Re: The future of patch-o-matic-ng

[Patrick McHardy]

Carl-Daniel Hailfinger wrote:
> Harald Welte schrieb:
> 
>>On Thu, Apr 06, 2006 at 12:34:21PM +0200, Krzysztof Oledzki wrote:
>>
>>
>>>So, this external repository will be used only by netfilter server to
>>>download patchlets? People will be still able to download complete
>>>pom-ng package? 
>>
>>No, users will actually only download 
> 
> 
> And exactly that's the problem with the proposed change. The value
> of pom-ng was not a central list of patches (I can always get that
> from the netfilter web site), but the packaged collection.

You can always do "runme --download" and you have the packaged
collection. We could also start doing two releases, one with
only patches maintained by the netfilter team and one with
all the patches.

> So if you really don't want to package patches from other sources
> anymore, please be honest and call the new package pom-coreteam
> or something like that.

Whats the point? We _do_ include other patches, just not every
random crap.

Re: The future of patch-o-matic-ng

[Patrick McHardy]

Grzegorz Janoszka wrote:
> On Thu, 6 Apr 2006, Harald Welte wrote:
> 
>> As indicated in Patricks mail, there's a 30 day grace period.  Until
>> then the original authors (if they care) or other people can take
>> maintenance for individual patchlets and send us URL's to those
>> repositories.  We will add them to our list file, and distribute a
>> 'runme' script which downloads those repositories off the net.
>> If you want to help, I suggest to wait for those patchlets that nobody
>> takes care of, and run a repository for them.
> 
> 
> I want to maintain my target IPMARK. A can take care of some other
> targets. At this moment I use IPMARK, nth, random and connlimit. The
> esiest for me would be to take care of a target/match I know and I use.

Thanks, I've updated my list for IPMARK. nth and random will be merged,
so this just leaves connlimit. Shall I add you for this as well?