From jpiszcz at lucidpixels.com  Tue Jan 19 11:36:38 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 04:36:38 -0500 (EST)
Subject: [Gross] grossd 1.0.2 compilation error on linux/x86_64
Message-ID: <alpine.DEB.2.00.1001190433430.4897@p34.internal.lan>

Hi,

Distribution: Debian/Testing x86_64

Currently using 1.0.1:

Issue with 1.0.2:

$ make
make  all-recursive
make[1]: Entering directory `/home/user/gross-1.0.2'
Making all in src
make[2]: Entering directory `/home/user/gross-1.0.2/src'
cc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -I/usr/local/include  -g -O2 -MT utils.o -MD -MP -MF .deps/utils.Tpo -c -o utils.o utils.c
In file included from utils.c:22:
../include/utils.h:42: error: conflicting types for 'getline'
/usr/include/stdio.h:651: error: previous declaration of 'getline' was here
make[2]: *** [utils.o] Error 1
make[2]: Leaving directory `/home/user/gross-1.0.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/user/gross-1.0.2'
make: *** [all] Error 2
Command exited with non-zero status 2
0.03user 0.01system 0:00.04elapsed 91%CPU (0avgtext+0avgdata 35536maxresident)k
0inputs+0outputs (0major+6238minor)pagefaults 0swaps

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-6)

Justin.



From steeeeeveee at gmx.net  Tue Jan 19 12:46:29 2010
From: steeeeeveee at gmx.net (Steve)
Date: Tue, 19 Jan 2010 11:46:29 +0100
Subject: [Gross] grossd 1.0.2 compilation error on linux/x86_64
In-Reply-To: <alpine.DEB.2.00.1001190433430.4897@p34.internal.lan>
References: <alpine.DEB.2.00.1001190433430.4897@p34.internal.lan>
Message-ID: <20100119104629.184080@gmx.net>


-------- Original-Nachricht --------
> Datum: Tue, 19 Jan 2010 04:36:38 -0500 (EST)
> Von: Justin Piszcz <jpiszcz at lucidpixels.com>
> An: gross at lists.utu.fi, eino at utu.fi, antti at utu.fi
> Betreff: [Gross] grossd 1.0.2 compilation error on linux/x86_64

> Hi,
> 
> Distribution: Debian/Testing x86_64
> 
> Currently using 1.0.1:
> 
> Issue with 1.0.2:
> 
> $ make
> make  all-recursive
> make[1]: Entering directory `/home/user/gross-1.0.2'
> Making all in src
> make[2]: Entering directory `/home/user/gross-1.0.2/src'
> cc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -I/usr/local/include
>  -g -O2 -MT utils.o -MD -MP -MF .deps/utils.Tpo -c -o utils.o utils.c
> In file included from utils.c:22:
> ../include/utils.h:42: error: conflicting types for 'getline'
> /usr/include/stdio.h:651: error: previous declaration of 'getline' was
> here
> make[2]: *** [utils.o] Error 1
> make[2]: Leaving directory `/home/user/gross-1.0.2/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/user/gross-1.0.2'
> make: *** [all] Error 2
> Command exited with non-zero status 2
> 0.03user 0.01system 0:00.04elapsed 91%CPU (0avgtext+0avgdata
> 35536maxresident)k
> 0inputs+0outputs (0major+6238minor)pagefaults 0swaps
> 
> $ gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6'
> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch
> --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.3.4 (Debian 4.3.4-6)
> 

Execute this in your GROSS source directory after you have extracted it but before you compile:
-----------------------
sed -i -e "/^int[\t ]\{1,99\}getline[\t ]*(.*/d" ./include/utils.h
-----------------------

Then try again.


> Justin.
> 
> _______________________________________________
> Gross mailing list
> Gross at lists.utu.fi
> https://lists.utu.fi/mailman/listinfo/gross

-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


From jpiszcz at lucidpixels.com  Tue Jan 19 13:10:52 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 06:10:52 -0500 (EST)
Subject: [Gross] grossd 1.0.2 compilation error on linux/x86_64
In-Reply-To: <20100119104629.184080@gmx.net>
References: <alpine.DEB.2.00.1001190433430.4897@p34.internal.lan>
 <20100119104629.184080@gmx.net>
Message-ID: <alpine.DEB.2.00.1001190610120.310@p34.internal.lan>



On Tue, 19 Jan 2010, Steve wrote:

>
> -------- Original-Nachricht --------
>> Datum: Tue, 19 Jan 2010 04:36:38 -0500 (EST)
>> Von: Justin Piszcz <jpiszcz at lucidpixels.com>
>> An: gross at lists.utu.fi, eino at utu.fi, antti at utu.fi
>> Betreff: [Gross] grossd 1.0.2 compilation error on linux/x86_64
>
>> Hi,
>>
>> Distribution: Debian/Testing x86_64
>>
>> Currently using 1.0.1:
>>
>> Issue with 1.0.2:
>>
>> $ make
>> make  all-recursive
>> make[1]: Entering directory `/home/user/gross-1.0.2'
>> Making all in src
>> make[2]: Entering directory `/home/user/gross-1.0.2/src'
>> cc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -I/usr/local/include
>>  -g -O2 -MT utils.o -MD -MP -MF .deps/utils.Tpo -c -o utils.o utils.c
>> In file included from utils.c:22:
>> ../include/utils.h:42: error: conflicting types for 'getline'
>> /usr/include/stdio.h:651: error: previous declaration of 'getline' was
>> here
>> make[2]: *** [utils.o] Error 1
>> make[2]: Leaving directory `/home/user/gross-1.0.2/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/user/gross-1.0.2'
>> make: *** [all] Error 2
>> Command exited with non-zero status 2
>> 0.03user 0.01system 0:00.04elapsed 91%CPU (0avgtext+0avgdata
>> 35536maxresident)k
>> 0inputs+0outputs (0major+6238minor)pagefaults 0swaps
>>
>> $ gcc -v
>> Using built-in specs.
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6'
>> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch
>> --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
>> --without-included-gettext --enable-threads=posix --enable-nls
>> --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu
>> --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic
>> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
>> --target=x86_64-linux-gnu
>> Thread model: posix
>> gcc version 4.3.4 (Debian 4.3.4-6)
>>
>
> Execute this in your GROSS source directory after you have extracted it but before you compile:
> -----------------------
> sed -i -e "/^int[\t ]\{1,99\}getline[\t ]*(.*/d" ./include/utils.h
> -----------------------
>
> Then try again.
>
>
>> Justin.
>>

Thanks, would it make sense to put out a gross though that does not 
require this to avoid future users/people upgrading the same problem?

e.g., gross-1.0.2.1

Justin.


From steeeeeveee at gmx.net  Tue Jan 19 13:22:01 2010
From: steeeeeveee at gmx.net (Steve)
Date: Tue, 19 Jan 2010 12:22:01 +0100
Subject: [Gross] grossd 1.0.2 compilation error on linux/x86_64
In-Reply-To: <alpine.DEB.2.00.1001190610120.310@p34.internal.lan>
References: <alpine.DEB.2.00.1001190433430.4897@p34.internal.lan>
 <20100119104629.184080@gmx.net>
 <alpine.DEB.2.00.1001190610120.310@p34.internal.lan>
Message-ID: <20100119112201.184080@gmx.net>


-------- Original-Nachricht --------
> Datum: Tue, 19 Jan 2010 06:10:52 -0500 (EST)
> Von: Justin Piszcz <jpiszcz at lucidpixels.com>
> An: Steve <steeeeeveee at gmx.net>
> CC: gross at lists.utu.fi
> Betreff: Re: [Gross] grossd 1.0.2 compilation error on linux/x86_64

> 
> 
> On Tue, 19 Jan 2010, Steve wrote:
> 
> >
> > -------- Original-Nachricht --------
> >> Datum: Tue, 19 Jan 2010 04:36:38 -0500 (EST)
> >> Von: Justin Piszcz <jpiszcz at lucidpixels.com>
> >> An: gross at lists.utu.fi, eino at utu.fi, antti at utu.fi
> >> Betreff: [Gross] grossd 1.0.2 compilation error on linux/x86_64
> >
> >> Hi,
> >>
> >> Distribution: Debian/Testing x86_64
> >>
> >> Currently using 1.0.1:
> >>
> >> Issue with 1.0.2:
> >>
> >> $ make
> >> make  all-recursive
> >> make[1]: Entering directory `/home/user/gross-1.0.2'
> >> Making all in src
> >> make[2]: Entering directory `/home/user/gross-1.0.2/src'
> >> cc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT
> -I/usr/local/include
> >>  -g -O2 -MT utils.o -MD -MP -MF .deps/utils.Tpo -c -o utils.o utils.c
> >> In file included from utils.c:22:
> >> ../include/utils.h:42: error: conflicting types for 'getline'
> >> /usr/include/stdio.h:651: error: previous declaration of 'getline' was
> >> here
> >> make[2]: *** [utils.o] Error 1
> >> make[2]: Leaving directory `/home/user/gross-1.0.2/src'
> >> make[1]: *** [all-recursive] Error 1
> >> make[1]: Leaving directory `/home/user/gross-1.0.2'
> >> make: *** [all] Error 2
> >> Command exited with non-zero status 2
> >> 0.03user 0.01system 0:00.04elapsed 91%CPU (0avgtext+0avgdata
> >> 35536maxresident)k
> >> 0inputs+0outputs (0major+6238minor)pagefaults 0swaps
> >>
> >> $ gcc -v
> >> Using built-in specs.
> >> Target: x86_64-linux-gnu
> >> Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6'
> >> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
> >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --enable-multiarch
> >> --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
> >> --without-included-gettext --enable-threads=posix --enable-nls
> >> --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
> --enable-clocale=gnu
> >> --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
> --with-tune=generic
> >> --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu
> >> --target=x86_64-linux-gnu
> >> Thread model: posix
> >> gcc version 4.3.4 (Debian 4.3.4-6)
> >>
> >
> > Execute this in your GROSS source directory after you have extracted it
> but before you compile:
> > -----------------------
> > sed -i -e "/^int[\t ]\{1,99\}getline[\t ]*(.*/d" ./include/utils.h
> > -----------------------
> >
> > Then try again.
> >
> >
> >> Justin.
> >>
> 
Hallo Justin,

> Thanks, would it make sense to put out a gross though that does not 
> require this to avoid future users/people upgrading the same problem?
> 
> e.g., gross-1.0.2.1
> 
it's not under my control. However. The issue is known since 1.0.1 -> http://code.google.com/p/gross/issues/detail?id=81#c0

> Justin.
>
// Steve
-- 
Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02


From eino at utu.fi  Tue Jan 19 13:42:43 2010
From: eino at utu.fi (Eino Tuominen)
Date: Tue, 19 Jan 2010 13:42:43 +0200
Subject: [Gross] grossd 1.0.2 compilation error on linux/x86_64
In-Reply-To: <20100119112201.184080@gmx.net>
References: <alpine.DEB.2.00.1001190433430.4897@p34.internal.lan>
 <20100119104629.184080@gmx.net>
 <alpine.DEB.2.00.1001190610120.310@p34.internal.lan>
 <20100119112201.184080@gmx.net>
Message-ID: <4B559AB3.3040608@utu.fi>

Steve wrote:
>
>>>>
> Hallo Justin,
> 
>> Thanks, would it make sense to put out a gross though that does not 
>> require this to avoid future users/people upgrading the same problem?
>>
>> e.g., gross-1.0.2.1
>>
> it's not under my control. However. The issue is known since 1.0.1 -> http://code.google.com/p/gross/issues/detail?id=81#c0

Hello,

I try to find time to push 1.0.3 out.

Also, if there's anybody interested in participating in this project, 
please let me know!

-- 
   Eino Tuominen


From jpiszcz at lucidpixels.com  Tue Jan 19 13:45:56 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 06:45:56 -0500 (EST)
Subject: [Gross] gross rbl weight question
Message-ID: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>

Hi,

Example:

dnsbl = ix.dnsbl.manitu.net;2
dnsbl = combined.njabl.org
dnsbl = cbl.abuseat.org
dnsbl = dnsbl.sorbs.net

Jan 19 06:44:36 l1 grossd: #960d6910: a=greylist d=254 w=3 c=217.15.118.148 s=donovanmv6 at northbluffapts.com r=webmastern at solarrain.com h=hreex-148.ecoweb.co.zw m=cbl.abuseat.org+1 m=dnsbl-1.uceprotect.net+1 m=ix.dnsbl.manitu.net+1

How come ix.dnsbl.manitu.net is not given a (+2) for its weight?

Justin.



From eino at utu.fi  Tue Jan 19 14:24:24 2010
From: eino at utu.fi (Eino Tuominen)
Date: Tue, 19 Jan 2010 14:24:24 +0200
Subject: [Gross] gross rbl weight question
In-Reply-To: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
Message-ID: <4B55A478.3020100@utu.fi>

Justin Piszcz wrote:
> Hi,
> 
> Example:
> 
> dnsbl = ix.dnsbl.manitu.net;2
> dnsbl = combined.njabl.org
> dnsbl = cbl.abuseat.org
> dnsbl = dnsbl.sorbs.net
> 
> Jan 19 06:44:36 l1 grossd: #960d6910: a=greylist d=254 w=3 c=217.15.118.148 s=donovanmv6 at northbluffapts.com r=webmastern at solarrain.com h=hreex-148.ecoweb.co.zw m=cbl.abuseat.org+1 m=dnsbl-1.uceprotect.net+1 m=ix.dnsbl.manitu.net+1
> 
> How come ix.dnsbl.manitu.net is not given a (+2) for its weight?

Hello,

grossd logs the configuration when starting up. Look for lines 
containing 'adding' in the log.

-- 
   Eino Tuominen



From jpiszcz at lucidpixels.com  Tue Jan 19 14:26:54 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 07:26:54 -0500 (EST)
Subject: [Gross] gross 1.0.2 not starting up/state file issue
In-Reply-To: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
Message-ID: <alpine.DEB.2.00.1001190726250.310@p34.internal.lan>

May also be causing the problem below:

# grossd -C
Grossd shutdown with exit code 2: statefile not configured
# grossd -C
Grossd shutdown with exit code 2: statefile not configured

hmm..

On Tue, 19 Jan 2010, Justin Piszcz wrote:

> Hi,
>
> Example:
>
> dnsbl = ix.dnsbl.manitu.net;2
> dnsbl = combined.njabl.org
> dnsbl = cbl.abuseat.org
> dnsbl = dnsbl.sorbs.net
>
> Jan 19 06:44:36 l1 grossd: #960d6910: a=greylist d=254 w=3 c=217.15.118.148 
> s=donovanmv6 at northbluffapts.com r=webmastern at solarrain.com 
> h=hreex-148.ecoweb.co.zw m=cbl.abuseat.org+1 m=dnsbl-1.uceprotect.net+1 
> m=ix.dnsbl.manitu.net+1
>
> How come ix.dnsbl.manitu.net is not given a (+2) for its weight?
>
> Justin.
>
>


From jpiszcz at lucidpixels.com  Tue Jan 19 14:55:56 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 07:55:56 -0500 (EST)
Subject: [Gross] gross rbl weight question
In-Reply-To: <4B55A478.3020100@utu.fi>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
 <4B55A478.3020100@utu.fi>
Message-ID: <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan>



On Tue, 19 Jan 2010, Eino Tuominen wrote:

> Justin Piszcz wrote:
>> Hi,
>> 
>> Example:
>> 
>> dnsbl = ix.dnsbl.manitu.net;2
>> dnsbl = combined.njabl.org
>> dnsbl = cbl.abuseat.org
>> dnsbl = dnsbl.sorbs.net
>> 
>> Jan 19 06:44:36 l1 grossd: #960d6910: a=greylist d=254 w=3 c=217.15.118.148 
>> s=donovanmv6 at northbluffapts.com r=webmastern at solarrain.com 
>> h=hreex-148.ecoweb.co.zw m=cbl.abuseat.org+1 m=dnsbl-1.uceprotect.net+1 
>> m=ix.dnsbl.manitu.net+1
>> 
>> How come ix.dnsbl.manitu.net is not given a (+2) for its weight?
>
> Hello,
>
> grossd logs the configuration when starting up. Look for lines containing 
> 'adding' in the log.
>
> --
>  Eino Tuominen
>

Hi,

Found the problem, it was the configuration file location, looking at the 
next issue now (statefile), I gzipped it to see if that was the problem, 
want to make a new one, and -C is not working.

Justin.


From jpiszcz at lucidpixels.com  Tue Jan 19 15:07:00 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 08:07:00 -0500 (EST)
Subject: [Gross] gross rbl weight question
In-Reply-To: <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
 <4B55A478.3020100@utu.fi>
 <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan>
Message-ID: <alpine.DEB.2.00.1001190806480.15656@p34.internal.lan>



On Tue, 19 Jan 2010, Justin Piszcz wrote:

>
>
> On Tue, 19 Jan 2010, Eino Tuominen wrote:
>
>> Justin Piszcz wrote:
>>> Hi,
>>> 
>>> Example:
>>> 
>>> dnsbl = ix.dnsbl.manitu.net;2
>>> dnsbl = combined.njabl.org
>>> dnsbl = cbl.abuseat.org
>>> dnsbl = dnsbl.sorbs.net
>>> 
>>> Jan 19 06:44:36 l1 grossd: #960d6910: a=greylist d=254 w=3 
>>> c=217.15.118.148 s=donovanmv6 at northbluffapts.com 
>>> r=webmastern at solarrain.com h=hreex-148.ecoweb.co.zw m=cbl.abuseat.org+1 
>>> m=dnsbl-1.uceprotect.net+1 m=ix.dnsbl.manitu.net+1
>>> 
>>> How come ix.dnsbl.manitu.net is not given a (+2) for its weight?
>> 
>> Hello,
>> 
>> grossd logs the configuration when starting up. Look for lines containing 
>> 'adding' in the log.
>> 
>> --
>>  Eino Tuominen
>> 
>
> Hi,
>
> Found the problem, it was the configuration file location, looking at the 
> next issue now (statefile), I gzipped it to see if that was the problem, want 
> to make a new one, and -C is not working.
>
> Justin.
>

Found the other issue,
statefile = /var/lib/grossd/grossd.state

Will try out 1.0.2 now, thanks all.

Justin.


From eino at utu.fi  Tue Jan 19 15:08:52 2010
From: eino at utu.fi (Eino Tuominen)
Date: Tue, 19 Jan 2010 15:08:52 +0200
Subject: [Gross] gross rbl weight question
In-Reply-To: <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
 <4B55A478.3020100@utu.fi>
 <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan>
Message-ID: <4B55AEE4.201@utu.fi>

Justin Piszcz wrote:
> 
> Hi,
> 
> Found the problem, it was the configuration file location, looking at 
> the next issue now (statefile), I gzipped it to see if that was the 
> problem, want to make a new one, and -C is not working.

Hmm. I'm not sure if I understand, but just make sure you have statefile 
configured in the config file and make sure that the file doesn't exists 
and you can (or the grossd prosess user) write to the statefile path. 
Then grossd -C should do the trick.

-- 
   Eino Tuominen



From jpiszcz at lucidpixels.com  Tue Jan 19 15:12:48 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 08:12:48 -0500 (EST)
Subject: [Gross] gross rbl weight question
In-Reply-To: <4B55AEE4.201@utu.fi>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
 <4B55A478.3020100@utu.fi>
 <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan> <4B55AEE4.201@utu.fi>
Message-ID: <alpine.DEB.2.00.1001190811090.15656@p34.internal.lan>



On Tue, 19 Jan 2010, Eino Tuominen wrote:

> Justin Piszcz wrote:
>> 
>> Hi,
>> 
>> Found the problem, it was the configuration file location, looking at the 
>> next issue now (statefile), I gzipped it to see if that was the problem, 
>> want to make a new one, and -C is not working.
>
> Hmm. I'm not sure if I understand, but just make sure you have statefile 
> configured in the config file and make sure that the file doesn't exists and 
> you can (or the grossd prosess user) write to the statefile path. Then grossd 
> -C should do the trick.
>
> --
>  Eino Tuominen
>

Someone needs to add grossd as a Debian package =)

Justin.


From jpiszcz at lucidpixels.com  Tue Jan 19 15:35:19 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 08:35:19 -0500 (EST)
Subject: [Gross] one last grossd problem (1.0.2)
In-Reply-To: <alpine.DEB.2.00.1001190811090.15656@p34.internal.lan>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
 <4B55A478.3020100@utu.fi>
 <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan> <4B55AEE4.201@utu.fi>
 <alpine.DEB.2.00.1001190811090.15656@p34.internal.lan>
Message-ID: <alpine.DEB.2.00.1001190834400.15656@p34.internal.lan>

Hello,

How do I stop this?

Jan 19 08:32:53 p34 grossd: grossd status summary (begin, end, trust, match, greylist, block): 1263907672, 1263907973, 0, 0, 0, 0
Jan 19 08:32:53 p34 grossd: grossd processing average delay (begin, end, trust[ms], match[ms], greylist[ms], block[ms]): 1263907672, 1263907973, 0.000, 0.000, 0.000, 0.000
Jan 19 08:32:53 p34 grossd: grossd processing max delay (begin, end, trust[ms], match[ms], greylist[ms], block[ms]): 1263907672, 1263907973, 0.000, 0.000, 0.000, 0.000

The following does not work in 1.0.2?

# 'stat_type' is the name of the requested statistic. There can be multiple
# 'stat_type' options in the configuration file (Using both none and full is
# undefined). Default is none. Valid options are currently:
# full: grossd sends all possible statistics
# none: no statistics at all
# status: basic statistics set
# since_startup: basic set since the startup 
# delay: processing delay statistics
# EXAMPLE: stat_type = status
# EXAMPLE: stat_type = delay
stat_type = none

# 'stat_interval' is the number of seconds between status log entries
# DEFAULT: stat_interval = 3600
stat_interval = 0

Justin.



From jpiszcz at lucidpixels.com  Tue Jan 19 15:39:34 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Tue, 19 Jan 2010 08:39:34 -0500 (EST)
Subject: [Gross] one last grossd problem (1.0.2)
In-Reply-To: <alpine.DEB.2.00.1001190834400.15656@p34.internal.lan>
References: <alpine.DEB.2.00.1001190643280.310@p34.internal.lan>
 <4B55A478.3020100@utu.fi>
 <alpine.DEB.2.00.1001190755180.15656@p34.internal.lan> <4B55AEE4.201@utu.fi>
 <alpine.DEB.2.00.1001190811090.15656@p34.internal.lan>
 <alpine.DEB.2.00.1001190834400.15656@p34.internal.lan>
Message-ID: <alpine.DEB.2.00.1001190839190.15656@p34.internal.lan>



On Tue, 19 Jan 2010, Justin Piszcz wrote:

> Hello,
>
> How do I stop this?
>
> Jan 19 08:32:53 p34 grossd: grossd status summary (begin, end, trust, match, greylist, block): 1263907672, 1263907973, 0, 0, 0, 0
> Jan 19 08:32:53 p34 grossd: grossd processing average delay (begin, end, trust[ms], match[ms], greylist[ms], block[ms]): 1263907672, 1263907973, 0.000, 0.000, 0.000, 0.000
> Jan 19 08:32:53 p34 grossd: grossd processing max delay (begin, end, trust[ms], match[ms], greylist[ms], block[ms]): 1263907672, 1263907973, 0.000, 0.000, 0.000, 0.000
>
> The following does not work in 1.0.2?
>
> # 'stat_type' is the name of the requested statistic. There can be multiple
> # 'stat_type' options in the configuration file (Using both none and full is
> # undefined). Default is none. Valid options are currently:
> # full: grossd sends all possible statistics
> # none: no statistics at all
> # status: basic statistics set
> # since_startup: basic set since the startup
> # delay: processing delay statistics
> # EXAMPLE: stat_type = status
> # EXAMPLE: stat_type = delay
> stat_type = none
>
> # 'stat_interval' is the number of seconds between status log entries
> # DEFAULT: stat_interval = 3600
> stat_interval = 0
>
> Justin.
>
> _______________________________________________
> Gross mailing list
> Gross at lists.utu.fi
> https://lists.utu.fi/mailman/listinfo/gross
>

My error, please disregard, PATH issue to config file.

Justin.


From jpiszcz at lucidpixels.com  Fri Jan 22 16:54:59 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Fri, 22 Jan 2010 09:54:59 -0500 (EST)
Subject: [Gross] grossd 1.0.2: Segmentation fault
Message-ID: <alpine.DEB.2.00.1001220949510.4607@p34.internal.lan>

Grossd:

Fri Jan 22 09:49:33 2010 #f5a9910: threadpool 'dnsbl' idling
Fri Jan 22 09:49:33 2010 #f4a8910: threadpool 'rhsbl' idling
Fri Jan 22 09:49:33 2010 #efa3910: threadpool 'postfix' idling
Segmentation fault

Reason: (forgot to specify rhsbl = )
# 'rhsbl' is analogous to 'dnsbl'
black.uribl.com;4

Input check issue, maybe ignore or ERROR on invalid lines/syntax?

Justin.


From jpiszcz at lucidpixels.com  Fri Jan 22 17:00:02 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Fri, 22 Jan 2010 10:00:02 -0500 (EST)
Subject: [Gross] grossd 1.0.2: Segmentation fault
In-Reply-To: <alpine.DEB.2.00.1001220949510.4607@p34.internal.lan>
References: <alpine.DEB.2.00.1001220949510.4607@p34.internal.lan>
Message-ID: <alpine.DEB.2.00.1001220959460.4607@p34.internal.lan>



On Fri, 22 Jan 2010, Justin Piszcz wrote:

> Grossd:
>
> Fri Jan 22 09:49:33 2010 #f5a9910: threadpool 'dnsbl' idling
> Fri Jan 22 09:49:33 2010 #f4a8910: threadpool 'rhsbl' idling
> Fri Jan 22 09:49:33 2010 #efa3910: threadpool 'postfix' idling
> Segmentation fault
>
> Reason: (forgot to specify rhsbl = )
> # 'rhsbl' is analogous to 'dnsbl'
> black.uribl.com;4
>
> Input check issue, maybe ignore or ERROR on invalid lines/syntax?
>
> Justin.
> _______________________________________________
> Gross mailing list
> Gross at lists.utu.fi
> https://lists.utu.fi/mailman/listinfo/gross
>

Hmm, added rhsbl = still failing, continuing to look further.


From jpiszcz at lucidpixels.com  Fri Jan 22 17:10:16 2010
From: jpiszcz at lucidpixels.com (Justin Piszcz)
Date: Fri, 22 Jan 2010 10:10:16 -0500 (EST)
Subject: [Gross] gross 1.0.2: Segmentation fault [problem found and
 reproducible]
Message-ID: <alpine.DEB.2.00.1001221006170.9216@p34.internal.lan>

Hi,

If your dnsbl list is too long, grossd will segfault.
http://home.comcast.net/~jpiszcz/20100122/grossd.conf.too.long.txt

However, this works
http://home.comcast.net/~jpiszcz/20100122/grossd.conf.working.txt

Output (-DD -d)
http://home.comcast.net/~jpiszcz/20100122/segfault_output.txt

Justin.


From alvaro at hostalia.com  Fri Apr 30 11:25:30 2010
From: alvaro at hostalia.com (=?ISO-8859-15?Q?Alvaro_Mar=EDn?=)
Date: Fri, 30 Apr 2010 10:25:30 +0200
Subject: [Gross] N-way cluster
Message-ID: <4BDA93FA.4090004@hostalia.com>

Hi all,

new to this list :)
Searching for scripts/programs to apply greylisting to dynamic ranges I 
found MARBL, and then I found gross. I've test it and runs fine!

Now, I want to implement it on my production environment, with 13 
antispam servers, but I've read about "problems" with replication with 
clusters with more than 2 servers and this message:

https://lists.utu.fi/pipermail/gross/2008/000142.html

but I suposse that it'll be ready for the v2 of gross, with the new 
architecture:

http://code.google.com/p/gross/wiki/VersionTwoArchitecture

and not for this v1. Am I rigth?

Another question...I read on the FAQ:

===
Q: Are there risks of database problems?

Answer: [...] If you get more than 10 million messages a day you might 
need to adjust the default values.
===

I receive ~50mill/day so I've to adjust the default values...should I 
increase these ones?

filter_bits=24
number_buffers=8

Thank you!
Regards,

-- 
Alvaro Mar?n Illera
Hostalia Internet
www.hostalia.com



From jesse.thompson at doit.wisc.edu  Fri Apr 30 17:30:16 2010
From: jesse.thompson at doit.wisc.edu (Jesse Thompson)
Date: Fri, 30 Apr 2010 09:30:16 -0500
Subject: [Gross] N-way cluster
In-Reply-To: <4BDA93FA.4090004@hostalia.com>
References: <4BDA93FA.4090004@hostalia.com>
Message-ID: <4BDAE978.2080207@doit.wisc.edu>

On 04/30/2010 03:25 AM, Alvaro Mar?n wrote:
> Hi all,
>
> new to this list :)
> Searching for scripts/programs to apply greylisting to dynamic ranges I
> found MARBL, and then I found gross. I've test it and runs fine!
>
> Now, I want to implement it on my production environment, with 13
> antispam servers, but I've read about "problems" with replication with
> clusters with more than 2 servers and this message:
>
> https://lists.utu.fi/pipermail/gross/2008/000142.html
>
> but I suposse that it'll be ready for the v2 of gross, with the new
> architecture:
>
> http://code.google.com/p/gross/wiki/VersionTwoArchitecture
>
> and not for this v1. Am I rigth?

If I interpret Eino's plan correctly, n-node clustering will benefit you 
in terms of scalability, not fault tolerance.  You will still be 
dependent on the 2 master servers being available for the service to 
function.  So, the only reason you would need n-node clustering is if 
your load is so high that 2 nodes can't handle the traffic.  However, if 
the 2 nodes can handle your peak traffic, then you don't actually need 
the n-node cluster.

I'd be willing to bet that 2 nodes could handle your traffic just fine. 
  We had one day where a misconfigured spam bot attempted to send 100 
million messages.  Gross greylisted them all.  I didn't see any adverse 
effects from this load.  I didn't even know about it until I looked at 
our daily message volume report the following day.

Also, keep in mind that you may not need to process as many messages as 
you think.  Greylisting causes a dampening effect on your overall 
volumes.  Before gross we were peaking at 10 million messages/day.  Now 
we are down to a measly 3 million (with only 15% of the messages that 
make it past gross being spam.)


> Another question...I read on the FAQ:
>
> ===
> Q: Are there risks of database problems?
>
> Answer: [...] If you get more than 10 million messages a day you might
> need to adjust the default values.
> ===
>
> I receive ~50mill/day so I've to adjust the default values...should I
> increase these ones?
>
> filter_bits=24
> number_buffers=8

We ran into false matches, and I do remember changing those settings. 
According to the doc: "lowering filter_bits will increase the 
probability of false matches".  We are at 22, which is lower than the 
default of 24.  Perhaps the default value used to be lower than 22?

Or, I think that you could raise number_buffers to decrease the 
probability of false matches.  We do have this setting raised to 12 
(from the default of 8)

I hope this helps!

Jesse

>
> Thank you!
> Regards,
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3317 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.utu.fi/pipermail/gross/attachments/20100430/dec97fc1/attachment.p7s>

From spamcatcher at uni.de  Tue Dec 14 14:42:19 2010
From: spamcatcher at uni.de (spamcatcher at uni.de)
Date: Tue, 14 Dec 2010 13:42:19 +0100
Subject: [Gross] Question about version
Message-ID: <3093.1292330539@uni.de>

Hello,
i am new to the list and hppy to have found gross - it seems to do what i ever wanted from a greylisting daemon :)

A question about the version:

Currently, i downloaded version 1.0.2 and it compiled fine and runs!

Then, i noticed that the SVN contains a somewhat different version.

Which is recommended?

[ Das-Hunger-Projekt.de: Wer mehr ?ber die Arbeit in Mexiko erfahren m?chte, ist herzlich zur n?chsten Veranstaltung am 24. November 2010, 18.30 ? 21.30 im Bachbett (Holzstra?e 28, 80469 M?nchen) Uhr eingeladen. Alle Infos hier: http://uni.de/redaktion/ehrenamtliches-Engagement ]


From spamcatcher at uni.de  Tue Dec 14 15:26:51 2010
From: spamcatcher at uni.de (spamcatcher at uni.de)
Date: Tue, 14 Dec 2010 14:26:51 +0100
Subject: [Gross] Configuration questions
Message-ID: <3202.1292333211@uni.de>

Hello again,
thanks for your reply about the version, Eino!

If you can use help for tests or whatever, i can try :)

I run a site with several domains, but a quite low mail-traffic ...
Still, spam mails started to come up several times a day.
This is on a very low volume.

So, i am not sure about the right configuration settings for me.

I did read the documentation incl. the Configuration options wiki entry!
But still, i cannot decide on the configuration ...

Could you help me?

I just list some of my thoughts and questions:

#######################################
grey_delay
10

Having read about other greylisting implementations, i seem to remember that this is often set to 10 or 20 minutes!
Why is that only 10 seconds per default?
Do i missunderstand the the effect of that setting?

*confused*

#######################################
query_timeout
5000

pool_maxthreads
100

This means, that the server is configured to handle 5000/1000 * 100 = 500 mails per second, right?
That seems *way* to high for my servers :D

10 mails per second would already be too high.

So, i *could* use smaller settings to save resources - but *what* to set lower?

query_timeout 100?
pool_maxthreads 2?

Or better not touch that, even if oversized?
#######################################


Greetings,
Thomas

[ Das-Hunger-Projekt.de: Wer mehr ?ber die Arbeit in Mexiko erfahren m?chte, ist herzlich zur n?chsten Veranstaltung am 24. November 2010, 18.30 ? 21.30 im Bachbett (Holzstra?e 28, 80469 M?nchen) Uhr eingeladen. Alle Infos hier: http://uni.de/redaktion/ehrenamtliches-Engagement ]


From spamcatcher at uni.de  Thu Dec 16 14:25:35 2010
From: spamcatcher at uni.de (spamcatcher at uni.de)
Date: Thu, 16 Dec 2010 13:25:35 +0100
Subject: [Gross] Configuration questions
Message-ID: <36680.1292502335@uni.de>

Hello :)

Did that mail get through?

*duck*


And, BTW, another question:

What exactly is the meaning of "d=*" in the grossd logs?
I understand, it is a "delay", but it varies between 0 and some hundred, an i am not sure what it actualy means or comes from.

Thank you :)


Thomas schrieb:
> Hello again,
> thanks for your reply about the version, Eino!
>
> If you can use help for tests or whatever, i can try :)
>
> I run a site with several domains, but a quite low mail-traffic ...
> Still, spam mails started to come up several times a day.
> This is on a very low volume.
>
> So, i am not sure about the right configuration settings for me.
>
> I did read the documentation incl. the Configuration options wiki entry!
> But still, i cannot decide on the configuration ...
>
> Could you help me?
>
> I just list some of my thoughts and questions:
>
> #######################################
> grey_delay
> 10
>
> Having read about other greylisting implementations, i seem to remember that this is often set to 10 or 20 minutes!
> Why is that only 10 seconds per default?
> Do i missunderstand the the effect of that setting?
>
> *confused*
>
> #######################################
> query_timeout
> 5000
>
> pool_maxthreads
> 100
>
> This means, that the server is configured to handle 5000/1000 * 100 = 500 mails per second, right?
> That seems *way* to high for my servers :D
>
> 10 mails per second would already be too high.
>
> So, i *could* use smaller settings to save resources - but *what* to set lower?
>
> query_timeout 100?
> pool_maxthreads 2?
>
> Or better not touch that, even if oversized?
> #######################################
>
>
> Greetings,
> Thomas
>


[ Die Reise geht f?r 2 Personen in ein 5-Sterne Luxushotel f?r 1 Woche.. aber wohin ?? ;-) weiter dran bleiben und den 24. Dezember vormerken!.. www.uni.de/adventskalender ]
                 




From jesse.thompson at doit.wisc.edu  Wed Dec 22 01:02:06 2010
From: jesse.thompson at doit.wisc.edu (Jesse Thompson)
Date: Tue, 21 Dec 2010 17:02:06 -0600
Subject: [Gross] Configuration questions
In-Reply-To: <36680.1292502335@uni.de>
References: <36680.1292502335@uni.de>
Message-ID: <4D1131EE.1060700@doit.wisc.edu>

On 12/16/2010 06:25 AM, spamcatcher at uni.de wrote:
> What exactly is the meaning of "d=*" in the grossd logs?
> I understand, it is a "delay", but it varies between 0 and some hundred, an i am not sure what it actualy means or comes from.

IIRC, it is the time it took for all of the DNSBL queries to finish.  I 
think that it short circuits if there is a hit and/or if your 
block/greylist thresholds have been met, so IPs that aren't on DNSBLs 
will have longer values for d=

I see the same values as you, so I wouldn't worry about it if I were you.

Jesse

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.utu.fi/pipermail/gross/attachments/20101221/4ee5e231/attachment.p7s>

From jesse.thompson at doit.wisc.edu  Wed Dec 22 01:04:32 2010
From: jesse.thompson at doit.wisc.edu (Jesse Thompson)
Date: Tue, 21 Dec 2010 17:04:32 -0600
Subject: [Gross] Configuration questions
In-Reply-To: <4D1131EE.1060700@doit.wisc.edu>
References: <36680.1292502335@uni.de> <4D1131EE.1060700@doit.wisc.edu>
Message-ID: <4D113280.1000609@doit.wisc.edu>

On 12/21/2010 05:02 PM, Jesse Thompson wrote:
> On 12/16/2010 06:25 AM, spamcatcher at uni.de wrote:
>> What exactly is the meaning of "d=*" in the grossd logs?
>> I understand, it is a "delay", but it varies between 0 and some
>> hundred, an i am not sure what it actualy means or comes from.
>
> IIRC, it is the time it took for all of the DNSBL queries to finish. I
> think that it short circuits if there is a hit and/or if your
> block/greylist thresholds have been met, so IPs that aren't on DNSBLs
> will have longer values for d=
>
> I see the same values as you, so I wouldn't worry about it if I were you.

I believe that the 'query_timelimit' option defines the upper bound.

Jesse

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.utu.fi/pipermail/gross/attachments/20101221/1b444a99/attachment.p7s>

From jesse.thompson at doit.wisc.edu  Wed Dec 22 01:27:08 2010
From: jesse.thompson at doit.wisc.edu (Jesse Thompson)
Date: Tue, 21 Dec 2010 17:27:08 -0600
Subject: [Gross] Configuration questions
In-Reply-To: <3202.1292333211@uni.de>
References: <3202.1292333211@uni.de>
Message-ID: <4D1137CC.8030500@doit.wisc.edu>

On 12/14/2010 07:26 AM, spamcatcher at uni.de wrote:
> Hello again,
> thanks for your reply about the version, Eino!
>
> If you can use help for tests or whatever, i can try :)
>
> I run a site with several domains, but a quite low mail-traffic ...
> Still, spam mails started to come up several times a day.
> This is on a very low volume.
>
> So, i am not sure about the right configuration settings for me.
>
> I did read the documentation incl. the Configuration options wiki entry!
> But still, i cannot decide on the configuration ...
>
> Could you help me?
>
> I just list some of my thoughts and questions:
>
> #######################################
> grey_delay
> 10
>
> Having read about other greylisting implementations, i seem to remember that this is often set to 10 or 20 minutes!
> Why is that only 10 seconds per default?
> Do i missunderstand the the effect of that setting?
>
> *confused*

Setting it to 10 prevents the spammers who cheat by just firing off 2 
messages simultaneously.

 From what I can tell, most spammers do not even bother retrying.

You could raise it.  I don't know what the practical limit is.

Consider that any spammer that is willing and able to wait and retry 
won't be thwarted by you raising the setting.

The only benefit that I see to raising it is to increase the delay so 
that the spammer will get on more blacklists.

You'll have to do your own experiments to find out if it worth it.


> #######################################
> query_timeout
> 5000
>
> pool_maxthreads
> 100
>
> This means, that the server is configured to handle 5000/1000 * 100 = 500 mails per second, right?
> That seems *way* to high for my servers :D
>
> 10 mails per second would already be too high.
>
> So, i *could* use smaller settings to save resources - but *what* to set lower?
>
> query_timeout 100?
> pool_maxthreads 2?
>
> Or better not touch that, even if oversized?

I think that pool_maxthreads applies to the thread pool for querying 
DNS.  Which means that if you lower pool_maxthreads too much, then you 
may start getting DNS query contention.

Your calculation forgets that multiple DNSBLs are [probably] queried for 
each message.

I would assume that these threads are light weight, so it shouldn't hurt 
to aim high.  If you do lower the setting, maybe you could lower 
pool_maxthreads to 10.

Don't lower query_timeout, especially if you are not running a local 
caching DNS server.

Jesse

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.utu.fi/pipermail/gross/attachments/20101221/32e43698/attachment.p7s>