> [snip]
>
> > Please evaluate it and let me know if you want it or not.  Any feedback on
> > how well or not it works is very much appreciated.  Any information on how
> > you plan to possibly use it would be very interesting.
>
> Well, it's looking good so far, but I get lines and lines of the following
> messages in my syslog when dansguardian starts:
>
> Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2021 In
> _str_cpy sval is = .mpeg
> Feb 15 13:54:05 servername dansguardian:
> Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2024 In
> _str_cpy bb is = .mpg
[snip]
> Feb 15 13:54:05 servername dansguardian:
> Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2020 In
> _str_cpy tmpii is = 4
>
> It goes on for ages and ages and causes dansguardian to take ages to start.
>

That's easy.  You did not edit the String Makefile correctly!  You need to
comment out the line:

# To enable 'full debug ' tracing uncomment line below:-
#MYCFLAGS=-g3 -DDEBUG_STR -DDEBUG_MEM -DDEBUG_PRT -Wall

And uncomment the line:

# To build the library, and main test program  uncomment line below :-
MYCFLAGS=-O -Wall

You will need to do a 'make clean', then a new 'make' and recopy the file(s).

That'll fix that one.

> I also had a few messages as follows in the syslog:
>
> Feb 15 14:56:40 servername dansguardian: nbpp::TimeoutException: Timed out
> waiting for input
> Feb 15 14:57:00 servername last message repeated 4 times
> Feb 15 14:57:16 servername dansguardian: nbpp::SocketException: Connection
> reset by peer
> Feb 15 14:58:35 servername last message repeated 4 times
> Feb 15 15:02:59 servername dansguardian: nbpp::TimeoutException: Timed out
> waiting for input
> Feb 15 15:04:04 servername dansguardian: nbpp::TimeoutException: Timed out
> waiting for input
> Feb 15 15:08:06 servername dansguardian: nbpp::SocketException: Connection
[snip]
> Feb 15 16:26:04 servername dansguardian: nbpp::SocketException: Connection
> reset by peer
> Feb 15 16:27:07 servername dansguardian: nbpp::TimeoutException: Timed out
> waiting for input
> Feb 15 16:27:12 servername dansguardian: nbpp::TimeoutException: Timed out
> waiting for input
> Feb 15 16:45:56 servername dansguardian: nbpp::SocketException: Connection
> closed
> Feb 15 16:48:13 servername dansguardian: nbpp::SocketException: Connection
> closed
> Feb 15 16:48:48 servername dansguardian: nbpp::TimeoutException: Timed out
> waiting to send output
>
> I'm guessing the second lot of messages is just about the verbosity of nbpp,
> I guess if I had a look I could probably redirect the output elsewhere.  But
> the first one looks like there was a compile problem, or I don't have the
> right librarys.  Any suggestions?

This one is slightly more tricky.  I've set the timeouts so that it is
optimised for a LAN.  You might want to increase them in the dansguardian.cpp
file.

On my LAN I only get these if the remote web server is down or very very
slow or I cancel a fetch.  These are only there because I put them there for
debug.  Inrease the timeouts and try again and let me know.

[snip]
> Regards
>
> David Anso
> Systems Administrator - ZIP Internet
>
> Email:  sysadmin@...



--
Daniel Barron

Hi all,

I've just installed danguardian and I have a few questions.

Well, it's looking good so far, but I get lines and lines of the following
messages in my syslog when dansguardian starts:

Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2021 In
_str_cpy sval is = .mpeg
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2024 In
_str_cpy bb is = .mpg
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2027 In
_str_cpy sval is = .mpgg
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2029 In
_str_cpy sval is = .mpg
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2162 rhs
value is = .mpg
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 162 In dstr
sval is = .mpg
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 44 In
cstr(char *bb) sval is = .avi
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2005 In
_str_cpy bb is = .avi
Feb 15 13:54:05 servername dansguardian:
Feb 15 13:54:05 servername dansguardian: Debug String.cpp: Line: 2020 In
_str_cpy tmpii is = 4

It goes on for ages and ages and causes dansguardian to take ages to start.

I also had a few messages as follows in the syslog:

Feb 15 14:56:40 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 14:57:00 servername last message repeated 4 times
Feb 15 14:57:16 servername dansguardian: nbpp::SocketException: Connection
reset by peer
Feb 15 14:58:35 servername last message repeated 4 times
Feb 15 15:02:59 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 15:04:04 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 15:08:06 servername dansguardian: nbpp::SocketException: Connection
reset by peer
Feb 15 15:08:20 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 15:08:32 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 15:08:56 servername dansguardian: nbpp::SocketException: Connection
reset by peer
Feb 15 15:08:56 servername dansguardian: nbpp::SocketException: Connection
reset by peer
Feb 15 15:09:34 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 15:15:55 servername dansguardian: nbpp::TimeoutException: Timed out
waiting to send output
Feb 15 16:18:17 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 16:18:39 servername dansguardian: nbpp::SocketException: Connection
reset by peer
Feb 15 16:21:07 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 16:22:41 servername last message repeated 4 times
Feb 15 16:23:15 servername last message repeated 2 times
Feb 15 16:26:04 servername dansguardian: nbpp::SocketException: Connection
reset by peer
Feb 15 16:27:07 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 16:27:12 servername dansguardian: nbpp::TimeoutException: Timed out
waiting for input
Feb 15 16:45:56 servername dansguardian: nbpp::SocketException: Connection
closed
Feb 15 16:48:13 servername dansguardian: nbpp::SocketException: Connection
closed
Feb 15 16:48:48 servername dansguardian: nbpp::TimeoutException: Timed out
waiting to send output

I'm guessing the second lot of messages is just about the verbosity of nbpp,
I guess if I had a look I could probably redirect the output elsewhere.  But
the first one looks like there was a compile problem, or I don't have the
right librarys.  Any suggestions?



Regards

David Anso
Systems Administrator - ZIP Internet

Email:  sysadmin@...

The improvements are:

The denied url perl script page is now automatically in the exceptions so
that people who don't have 'no proxy on' set to the server with the script
don't have DG go in an endless loop.
A bug that caused sites in the exceptions list to cause DG to crash fixed.
This bug was introduced around 0.7.0.
The format of the bannedphraselist file is now improved.
All the config files can have comments now.
DG can now cope with the list config files having extra space or CR
characters.  These are stripped.

All changes above are due to user feedback.  All feedback is appreciated.

You can download from:  http://dansguardian.org/download.html

Meanwhile, work on 0.8.0, with logging, continues.  This is not an easy task
as multiple threads may need to write at once.  It is also important to code
it in a way that it slows responsiveness as little as possible.

--
Daniel Barron

In message <5.0.2.1.0.20010211010759.009f84c0@...> you wrote:
[snip]
> >
> >If you still had problems compiling 0.7.1, then 0.7.2 should fix them.
> >Please let me know.
>
> Now it's 100% ok.
>

Excellent.

> --
>
> I made more investigation on the problem I have with the perl script which
> is not displayed when a "blacklisted page" is requested. In fact just a
> certain category of perl script wasn't shown : they are all of them which
> displays the arguments. Let me explain. When a "bad word" is found in a
> site, dansguardian redirects to the script ... but if one connect to the
> server via dansguardian to access the script, dansguardian detects again
> this bad word on, then it redirects again to the script etc ... what a
> beautifull loop, isn't it ?
>
> I set the browser to avoid connecting to the local network via the proxy as
> you suggested in a precedent mail and that way it works well. But I think
> it might be better to manage this problem in dansguardian itself. This is
> why I tested to add the IP address (192.168.0.1) of my web server in
> /etc/exceptionsitelist but dansguardian crashes each time a blacklisted
> word appairs in a page. So it does not work but I didn't find why yet. Any
> ideas ?

On the crashing; don't know.  On the no proxy on; that's how it's designed to
be.  On all networks I set up (I set up a lot) I have the internal server
not proxied for these sorts of reasons.  However what you say is a fair
point - not everyone wants it like me.  Consider it fixed for the next
release.

>
> I also discovered a bug in the function which reads /etc/exceptionsitelist.
> If the file contains one or more empty lines (I mean just one CR)
> dansguardian crashes as soon as it is requested to act as a proxy. That's
> probably due to a typo in that function :

Well, again - it's as was designed.  The option files reading was just a
quick bit of code to get it going.  It's the sort of thing that gets
improved later on.


>
>          OptionContainer::readeslfile(const char* filename)
>
> This test looks wrong :
>
>          if (!(listfile.eof() && linebuffer.length() == 0))
>
> I beleive it should rather be :
>
>          if ( ! listfile.eof() && linebuffer.length() != 0 )
>
> I noticed that a same problem may occur also in the other read*file functions.

I'll look at the code and check it.

>
> BTW it could be nice to put comments in these config files as well. May I
> suggest the following code ?

Yes, of course.  It was planned one day.


>
>          while (!listfile.eof())
>          {
>                  getline(listfile, linebuffer);
>                  if ( ! listfile.eof() && linebuffer.length() != 0 )
>                  {
>                          if( linebuffer[0] == '#' )
>                                  continue;       // Comment line : ignore it
>
>                          // to avoid checking length for each loop
>                          int nLength = linebuffer.length();
>                          for(j = 0; j < nLength; j++)
>                                          linebuffer[j] =
> tolower(linebuffer[j]);
>
>                          exceptions_site_list.push_back(linebuffer);
>                  }
>          }
>

I'll look at what you propose and implement it.

> I think it can even be improved for removing any extra space characters
> (especially the ones which are placed after the keyword, because we can't
> see them). There is several way to perform that and I guess you don't need
> help for. How sounds this ?

The banned extension, banned mime type, and exception list all could do
with extra space characters being removed.  However the banned phrase list
/must/ keep them.  For example just 'sex' matches 'Middlesex University',
and ' sex ' just matches the word 'sex' by itself.  Including the spaces is
actually a feature by design!  I suppose I could make it clearer with line
starts and line ends.

>
> Well, now I'm going to sleep. It's 2:35 pm local time and I'm a little bit
> tired ! :-)

You mean am don't you!

Thanks for all you effort and contributions.

--
Daniel Barron

In message <003d01c093b6$3a0ebff0$8249a8c0@...> you wrote:

> Hello, Dan!
>
>     I'm trying to compile Dan's Guardian, but I can't find the string class
> on the page you reference!  Perhaps I just didn't see it (a lot of stuff
> there).  Could you please double check it?  If you can't find it, could you
> please send it to me?

The site that the String class on won't let me link directly to the file,
so I have to link to the page.  I think it checks the referer site address
in the request stopping people link directly in.

Go to http://dansguardian.org/installation.html.

Go to the last line of point 3.  There is a link to my copy of the String
class.  It's been make'd so you aught to do a make clean first before using
it unless you get compile problems.

--
Daniel Barron

The improvements from 0.7.1 to 0.7.2 can be found on the download page:
http://dansguardian.org/download.html

If you still had problems compiling 0.7.1, then 0.7.2 should fix them.
Please let me know.

> Date: Thu, 8 Feb 2001 20:18:12 -0600
> From: Matt Hays <matt@...>
> Subject: run problems
>
> Hi,
>
> I got dansguardian to compile on my rh 7.0 box w/ the recent 0.7.2
> release...cool stuff.
>

Good.

> The only problem I have is that dansguardian only runs for like 5 minutes,
> then it will shutdown.  I will be surfing along, read that page or
> something, then go to another page and get a 'cannot find server' (in IE)
> like the www.website.com is down or something.  Then I look at processes and
> dansguardian isn't running.  Also, if i make a change to the config or
> something and restart w/ the sysv init script, it won't shutdown...that's
> b/c it wasn't running in the first place..it has already shut itself down in
> 5 min. or whatever.

Does it shutdown without usage as well as with usage?  I've had dg 0.7.2
running for 12 hours non stop with no usage and some usage with no probs on
my rh6.2.  Can you check /var/log/Messages for any exceptions logged.

Are there any particular sites that cause this to happen?

What os and browser and version are you using?  I.e. what's the client?

I remember you saying nb++ had problems compiling on RH7.  Do all the tests
when installing nb++ pass?  It's possible its a problem with the nb++ side
of dg.  Not that I am trying to move blame!

What are the permissions on /etc/dansguardian/*. They need to be o+r unless
squid owns them.

>
> Thanks,
> Matt


--
Daniel Barron

The improvements from 0.7.1 to 0.7.2 can be found on the download page:
http://dansguardian.org/download.html

If you still had problems compiling 0.7.1, then 0.7.2 should fix them.
Please let me know.

--
Daniel Barron

See http://dansguardian.org/download.html

If you previously had problems compiling, please try this version and
report back.  Thanks.

--
Daniel Barron

In message <HHELIKGHDEHLHCKADNOKIEBACBAA.jettm@...> you wrote:

> Daniel, are you working on the FAQ yet?  I know, stupid question.  I guess
> what I am asking is would it help if I volunteered to start putting it
> together?

There is the general FAQ about the project.  What I suspect you mean is an
FAQ on usage, installation.  The only work I've done is on collating
information in my head on plans for it.

>
> There are still features (logging in 0.8.0 :)) that I would like to see, but

0.7.2 and 0.8.0 don't exist yet - it's mearly the release plan.  I hope to
have 0.7.1 and 0.7.2 released this weekend.  0.8.0 to follow shortly.
0.7.1 is very nearly ready.

> I would expect that new people are going to start looking for some
> documentation.  Since you are quite obviously able to take this where it
> needs to go from a programming standpoint, I personally would rather you do
> that and I'll help out by starting on some documentation...
>
> Let me know what you think.

The whole dansguardian.org site needs re-doing.  I've ordered a book on PHP4.
I expect to learn it enough to resdesign the site along the lines of the
design here: http://www.squirrelmail.org/ .  Part of the reorganisation was
going to include documentation such as the FAQ on usage, installation etc.
Whats held me up on that is waiting for the book to arrive from amazon.co.uk.
I won't use frames as they're no longer fasionable.

However, I would have no problem with you sending me FAQs, docs, etc to
include on the site.  Go ahead and make some and send it to me privately
(attachments are not really a good idea on a mailing list).  Send it to
daniel@....  When I get them I'll mod/incorperate them as needed.


>
> Mike Jett

[snip]

--
Daniel Barron

Daniel, are you working on the FAQ yet?  I know, stupid question.  I guess
what I am asking is would it help if I volunteered to start putting it
together?

There are still features (logging in 0.8.0 :)) that I would like to see, but
I would expect that new people are going to start looking for some
documentation.  Since you are quite obviously able to take this where it
needs to go from a programming standpoint, I personally would rather you do
that and I'll help out by starting on some documentation...

Let me know what you think.

Mike Jett

Sorry to flood the list...

In message <ea1e3d494a.DG@...> you wrote:
[snip]
> >
> > [matt@mail DansGuardian-0.7.0]$ make
> > c++ -O3 -w -c DataBuffer.cpp
> > c++ -O3 -w -c HTTPHeader.cpp
> > HTTPHeader.cpp: In function `ostream &operator<< (ostream &, const
> > HTTPHeader &)':
> > HTTPHeader.cpp:76: passing `const String' as `this' argument of `String
> > String::before (char *)' discards qualifiers
> > make: *** [HTTPHeader.o] Error 1
> > [matt@mail DansGuardian-0.7.0]$

I've just gone back and looked at this.  It has the same error on my
compilation, but does not class it so seriously and continues.
It just needs a cast I expect.  I need to go through the source code and
try and remove _all_ warning that come up and this should make it compile
on more strict compilers.  Most of the warning can be fixed with a cast.

[snip]
> I'll do two things to solve this.  1. Upgrade my mission critical server
> with the latest RPMs so I get the problems and then can solve them.
[snip]

Well, actually I'll hold off and sort the warning first to see if it fixes
it.  Anyway you can download the precompiled in the mean time.


--
Daniel Barron

In message <4.2.0.58.20010207151705.00972d10@...> you wrote:

[snip]
>
> Now, after some hours of work I succeed ! For that I had to do some mods in
> the source code to get my compiler happy with. Most of the problems have
> been cured adding a cast operator (ie to convert a "const char *" into a
> "char*"). So it works okay but I guess other people who are using a SuSE
> distribution (or even perhaps any other recent one) are going to have the
> same problem. Daniel, I propose to send you my mods ; anyway you can do
> what you want with !
>
> Now I have another problem. When I try to access to a web-page which
> contains a "black-listed" word through the proxy, dansguardian well detects
> it but there is no way to get the perl script running. Then the navigator
> tells me that the web page is unavailable (after a timeout). The same
> problem occurs if I configure dansguardian to run any perl script. So it is
> not due to Daniels's one. Anyway, if I access the script directly from the
> navigatore (entering this url :
> http://192.168.0.1/cgi-bin/dansguardian.pl?...) it's ok even through the
> dansguardian proxy.
>
> Note I'm sure to have well configurated this in /etc/dansguardian.conf.
>
> BTW if I configure dansguardian to open a html page rather than a perl
> script it works.
>
> Any idea ?
>
> Regards,
> Olivier Le Cam,
> France.
[snip]

I'm not sure what's wrong.  I've tested it with 5 different browsers and it
works here.  Maybe its a change you made that caused the problem?  But
unlikely.

What address have you tried that works?  Is it a 192,168.0.1/mywebpage.html
or an external one?

Do you have 192.168.0.1 in the no-proxy section of your browser
configuration?  Do you have an upstream proxy configured in squid?  If so,
the redirection will be forced through the upstream proxy which won't know
about 192.168.0.1.  The no-proxy bit does not work for a redirection.  This
would explain the problem.

BTW, I've uploaded a precompiled version of DansGuardian so all you need to
do is a make install (after nb++ and String of course).  It's on the
installation page: http://dansguardian.org/installation.html

Also send me your mods and I'll incorperate them.


--
Daniel Barron

-----Original Message-----
From: Daniel Barron [mailto:dg@...]
Sent: Wednesday, February 07, 2001 1:34 PM
To: dansguardian@yahoogroups.com
Subject: [dansguardian] RE: Compilation problems again

> Hi,
>
> I run RH 6.2, 2.2.18.

A-ha!  I've got several linuxes that compile squidguard and db perfectly.
However those I've updated with the up2date rpms from redhats site won't
compile.  I wonder if there is a problem with later glibc or something.

BTW, have you found 2.2.8 as an RPM yet?

>
> ######## Cut #########
>
> [matt@mail DansGuardian-0.7.0]$ make
> c++ -O3 -w -c DataBuffer.cpp
> c++ -O3 -w -c HTTPHeader.cpp
> HTTPHeader.cpp: In function `ostream &operator<< (ostream &, const
> HTTPHeader &)':
> HTTPHeader.cpp:76: passing `const String' as `this' argument of `String
> String::before (char *)' discards qualifiers
> make: *** [HTTPHeader.o] Error 1
> [matt@mail DansGuardian-0.7.0]$
>
> ######## Cut #########
>
> I compiled nb++, although, in DaemonBase.cpp, on line 56/82.  I had to add
> `int OPEN_MAX;` because it was complaining about OPEN_MAX uninitialized.  I
> don't know any C++, (or C for that matter) but it seemed to compile okay.  I
> wonder if that's what the problem could be here?  Also, I used your
> pre-compiled String.h and libString.a after compiling my own didn't work.
> Same result.
>
> Thanks,
> Matt

I'll do two things to solve this.  1. Upgrade my mission critical server
with the latest RPMs so I get the problems and then can solve them.
2. I'll put up a precompiled copy of DG 0.7.0 which you can untar then
just do a make install.

These will happen at some time tonight so dansguardian.org may be down when
you try.

Unfortunately I'll lose my uptime since last millennium :(



--
Daniel Barron



To unsubscribe from this group, send an email to:
dansguardian-unsubscribe@egroups.com

In message <4.2.0.58.20010207151705.00972d10@...> you wrote:

> Hi folks,
>
> I reported Daniel yesterday that I can't compile dansguardian due to too
> many warnings generated by the compiler. I was thinking the fault were
> somewhere with the libString.a library but I were wrong !
>
> Now, after some hours of work I succeed ! For that I had to do some mods in
> the source code to get my compiler happy with. Most of the problems have
> been cured adding a cast operator (ie to convert a "const char *" into a
> "char*"). So it works okay but I guess other people who are using a SuSE
> distribution (or even perhaps any other recent one) are going to have the
> same problem. Daniel, I propose to send you my mods ; anyway you can do
> what you want with !

Send them straight away!

I'll answer the rest of your email later - tea's burning...

[snip]

--
Daniel Barron

> Hi,
>
> I run RH 6.2, 2.2.18.

A-ha!  I've got several linuxes that compile squidguard and db perfectly.
However those I've updated with the up2date rpms from redhats site won't
compile.  I wonder if there is a problem with later glibc or something.

BTW, have you found 2.2.8 as an RPM yet?

>
> ######## Cut #########
>
> [matt@mail DansGuardian-0.7.0]$ make
> c++ -O3 -w -c DataBuffer.cpp
> c++ -O3 -w -c HTTPHeader.cpp
> HTTPHeader.cpp: In function `ostream &operator<< (ostream &, const
> HTTPHeader &)':
> HTTPHeader.cpp:76: passing `const String' as `this' argument of `String
> String::before (char *)' discards qualifiers
> make: *** [HTTPHeader.o] Error 1
> [matt@mail DansGuardian-0.7.0]$
>
> ######## Cut #########
>
> I compiled nb++, although, in DaemonBase.cpp, on line 56/82.  I had to add
> `int OPEN_MAX;` because it was complaining about OPEN_MAX uninitialized.  I
> don't know any C++, (or C for that matter) but it seemed to compile okay.  I
> wonder if that's what the problem could be here?  Also, I used your
> pre-compiled String.h and libString.a after compiling my own didn't work.
> Same result.
>
> Thanks,
> Matt

I'll do two things to solve this.  1. Upgrade my mission critical server
with the latest RPMs so I get the problems and then can solve them.
2. I'll put up a precompiled copy of DG 0.7.0 which you can untar then
just do a make install.

These will happen at some time tonight so dansguardian.org may be down when
you try.

Unfortunately I'll lose my uptime since last millennium :(



--
Daniel Barron

Hi folks,

I reported Daniel yesterday that I can't compile dansguardian due to too
many warnings generated by the compiler. I was thinking the fault were
somewhere with the libString.a library but I were wrong !

Now, after some hours of work I succeed ! For that I had to do some mods in
the source code to get my compiler happy with. Most of the problems have
been cured adding a cast operator (ie to convert a "const char *" into a
"char*"). So it works okay but I guess other people who are using a SuSE
distribution (or even perhaps any other recent one) are going to have the
same problem. Daniel, I propose to send you my mods ; anyway you can do
what you want with !

Now I have another problem. When I try to access to a web-page which
contains a "black-listed" word through the proxy, dansguardian well detects
it but there is no way to get the perl script running. Then the navigator
tells me that the web page is unavailable (after a timeout). The same
problem occurs if I configure dansguardian to run any perl script. So it is
not due to Daniels's one. Anyway, if I access the script directly from the
navigatore (entering this url :
http://192.168.0.1/cgi-bin/dansguardian.pl?...) it's ok even through the
dansguardian proxy.

Note I'm sure to have well configurated this in /etc/dansguardian.conf.

BTW if I configure dansguardian to open a html page rather than a perl
script it works.

Any idea ?

Regards,
Olivier Le Cam,
France.

On Tue 06 Feb, Olivier Le Cam, f5mzn wrote:
> Hi Daniel -
>
> I downloaded your program DansGuardian from your web site. Thanks for this
> piece of code ; I'm working in a school here in France (I'm a teacher) and
> I was looking for a such powerfull proxy filter for monthes !
>
> I'd like to have your opnion about a problem I have during the compilation.
> In fact I never get your program working here yet. I well installed as
> described on your pages nb++ as well as the String class library but c++
> always stops compiling and displays an error message. I copied a (short)
> capture at the end of this mail.
>
> It looks like libString.a is not used at all even it is well copied in the
> right directory as described (/usr/lib). BTW I get the same error message
> even if I delete libString.a from /usr/lib ! :-) I also checked the
> makefile, but I didn't get a chance to cure my problem in any way.
>
> My config is : Suse 6.4, kernel 2.2.14, gcc 2.95.2 - do you have an idea on
> what is wrong ?
>
> Best regards, and thanks in advance !
>
> Olivier Le Cam,
> http://www.f5mzn.online.fr
>
> PS : I apologize for my english which I hope you will understand !
>
> --- part of the capture ---
> HTTPHeader.cpp:22: no matching function for call to `String::toInteger ()'
> HTTPHeader.cpp: In method `class String HTTPHeader::getcontenttype()':
> HTTPHeader.cpp:31: no matching function for call to `String::startsWith
> (const char[14])'
> HTTPHeader.cpp: In method `bool HTTPHeader::iscontenttype(String)':
> HTTPHeader.cpp:43: no matching function for call to `String::startsWith
> (const char[14])'
> HTTPHeader.cpp:49: no matching function for call to `String::startsWith
(String
> &)'
> HTTPHeader.cpp: In function `class ostream & operator <<(ostream &, const
> HTTPHeader &)':
> HTTPHeader.cpp:76: passing `const String' as `this' argument of `class
> SubString String::before(const char *, int = 0)' discards qualifiers
> HTTPHeader.cpp: In function `class istream & operator >>(istream &,
> HTTPHeader &)':
> HTTPHeader.cpp:94: no matching function for call to `String::startsWith
> (const char[29])'
> HTTPHeader.cpp:94: no matching function for call to `String::startsWith
> (const char[29])'
> HTTPHeader.cpp:98: no matching function for call to `String::startsWith
> (const char[23])'
> HTTPHeader.cpp:98: no matching function for call to `String::startsWith
> (const char[23])'
> make: *** [HTTPHeader.o] Error 1
> linux:/usr/local/src/DansGuardian-0.7.0 #

Looks like a problem with the libString.a you compiled.  I've uploaded my
copy of the String class to http://dansguardian.org/installation.html .
It contains the compiled results.  Try these.

It is also possible that suse uses a different place for it's library
files.  We shall see.


--
Daniel Barron

DansGuardian-0.7.0 is now available.

It includes the following updates since 0.6.3:

Added 2 new features; denied mime-type and extension list filtering. So now
you can stop kiddies downloading porn movies and hacking software. Fixed bug
with url encoded reporting. Banned phrase list config file name change.

So DansGuardian now filters by content, PICS, mime-type and extension.

Any problems/sucess with it let me know.

Also, if you spot any spelling mistakes on the site let me know directly
please.

The next feature I am working on is the log file generation.  I've searched
for hours on the Web for tutorials on syslog and using it for your own
custom logs rather than writing my own code from scratch.  I've not found
any.  So if you have a url please let me know.

Get it at:
http://dansguardian.org/download.html
http://dansguardian.org/

--
Daniel Barron

On Thu 01 Feb, Ralf Kirmis wrote:
> Hi,
>
> have you ever thought of integrating a virus scanner into your Software ?
> It would be great, if all content getting out of the web, were scanned.
>
>
> So long,
>
> Ralf Kirmis
>
> PGP Key via pgpkeys.mit.edu:11371

Whoa!  Heavy CPU usage man.  But OK if we are talking about dedicating a
server to be the dansguardian 'proxy' with plenty of ram and processor.

It is an idea and it is a possibility one day.  I am always greatful for any
imput.

One feature that would be very easy to add would be a list of denied mime
types.  You could deny all execuatables, zips, tar.gzs, mp3s, avis, etc.
Infact that is such a good idea I intend to do it soon.

BTW, I've cc'ed this to the dansguardian mailing list.  If this is a problem,
I'll delete the message from the archive imediatley.



--
Daniel Barron
[Never disclose my email address to third parties]

In message <HHELIKGHDEHLHCKADNOKMEODCAAA.jettm@...> you wrote:

> A couple of questions regarding logging...
>
> 1 - Can logging be setup to log pages that were filtered by dg?  Good info
> to have would be the site, reason, and the client IP.

How exciting my first feature request!  Of course I'll add logging as soon
as I've fixed a couple of bugs.

> 2 - SquidGuard does a nice job of logging, but the client for all the web
> pages, after being run through dg, is localhost.  This hides the original
> client IP which is necessary info to have.  Any suggestions, or am I doing
> something wrong?

Thanks for bringing this to my attention.  This is actually quite important.
You are doing nothing wrong.  If I fix point 1 then point 2 will be moot.

>
[snip]

--
Daniel Barron

In message <HHELIKGHDEHLHCKADNOKGEOCCAAA.jettm@...> you wrote:

> First, you're my hero...  :)  And yes to both of your questions, I would
> like to know what the issue was, and I am going to put it into beta...

DansGuardian and Active Guardian were written to HTTP/1.0 connection
specifications.  I.e. no persistant connections.  The client sends a request
and then gets a response and the connection closes.  This is inefficient
as for each single image, frame, etc a seperate connection has to be
negotiated.  HTTP/1.1 has a number of improvements one is persistant
connections.  With this the browser can request multiple files on the same
connection, and even ask for them before they have all completed.  The
requests get queued.  To quote from RFC2616:

Persistent HTTP connections have a number of advantages:

       - By opening and closing fewer TCP connections, CPU time is saved
         in routers and hosts (clients, servers, proxies, gateways,
         tunnels, or caches), and memory used for TCP protocol control
         blocks can be saved in hosts.

       - HTTP requests and responses can be pipelined on a connection.
         Pipelining allows a client to make multiple requests without
         waiting for each response, allowing a single TCP connection to
         be used much more efficiently, with much lower elapsed time.

       - Network congestion is reduced by reducing the number of packets
         caused by TCP opens, and by allowing TCP sufficient time to
         determine the congestion state of the network.

       - Latency on subsequent requests is reduced since there is no time
         spent in TCP's connection opening handshake.

       - HTTP can evolve more gracefully, since errors can be reported
         without the penalty of closing the TCP connection. Clients using
         future versions of HTTP might optimistically try a new feature,
         but if communicating with an older server, retry with old
         semantics after an error is reported.

(Me talking again): However HTTP/1.1 Persistent connections provide a
mechanism by which a client and a server can signal the close of a TCP
connection. This signaling takes place using the Connection header field.
Once a close has been signaled, the client MUST NOT send any more requests on
that connection.

The web browsers I was testing DansGuardian with support HTTP/1.1, but do
not take advantage of persistent connections and signal in their header
request that they want to close the connection after the request.  I.e.
act just like a HTTP/1.0 connection.

IE and Netscape use HTTP/1.1 and take advantage of persistent connections.
What was happening was they were sending multiple requests on the same
connection and wondering what was happening and stalling waiting for pages
and images that will never come.

DansGuardian (like Active Guardian) is not a true proxy.  It simply
intercepts the request and response from the browser to the proxy and checks
the content of the responce.  It can not deal with persistent connections.

To overcome the problem I stuck in he following code:

if (line.startsWith("Proxy-Connection: Keep-Alive") ||
line.startsWith("Proxy-Connection: keep-alive")) {
       line = "Proxy-Connection: Close";  // Need to force HTTP/1.1 clients
                      // and servers to use non persistant connections
     }
     if (line.startsWith("Connection: Keep-Alive") ||
line.startsWith("Connection: keep-alive")) {
       line = "Connection: Close";  // ditto
     }

So basically when the browser requests persistent connections DansGuardian
rewrites them to request an non-persistent connection before sending it on
to the squid proxy.  When the proxy replies it will let the browser know it
will close the connection after the first request/response.  Even if it does
not DansGuardian rewrites it so.

Well you did ask!

One day DansGuardian may take advantage of persistent connections, but
don't hold your breath.  On a lan the advantage of this is not so great.

>
> Our target site will be a K-12 school with approximately 200 PC's total and
> a Full T-1 internet connection, with SquidGuard as well...  I can give more
> details if desired, and will keep the list updated with the status on this
> project.
>

Pah!  A T-1 is only 1500Kbits/sec.  I've got a 2Mbit/sec connection for just
me at home!  Well my girlfriend shares it and do my cats ;)

I would be quite interested in any reports/updates you have.

[snip]

--
Daniel Barron

-----Original Message-----
From: Daniel Barron [mailto:dg@...]
Sent: Wednesday, January 31, 2001 6:14 PM
To: dansguardian@yahoogroups.com
Subject: Re: [dansguardian] Serious bug in DansGuardian (and other news)

In message <c7ffa1434a.DG@...> you wrote:

> A new(but probably old) serious bug:
> This is a real show-stopper.  IE5.5 and Netscape 6 work intolerably slow with
> DansGuardian.  Lynx, Fresco and Oregano all work really really quickly - as
> quickly as without DansGuardian filtering infact.  I have no idea as to the
> cause and I am investigating.  Don't bother trying DansGuardian if your
[snip]

This bug is now fixed so you can actually use DansGuardian in a real
situation now!

If you are interested in the technical reason why all previous versions had
this problem, email me.

I expect to be testing DansGuardian on a 1000 user (150 computer) network
later today with a 512 Kbit permanent Internet connection.  The Linux is a
PII 450 196Mb RAM.  I expect it to cope easily with the traffic.  This is my
first wide scale beta test.  If you are testing out DansGuardian, I would
like to hear.

The lastest version 0.6.3 is available now.

http://dansguardian.org/download.html
http://dansguardian.org/

--
Daniel Barron



To unsubscribe from this group, send an email to:
dansguardian-unsubscribe@egroups.com

-----Original Message-----
From: Daniel Barron [mailto:dg@...]
Sent: Wednesday, January 31, 2001 6:14 PM
To: dansguardian@yahoogroups.com
Subject: Re: [dansguardian] Serious bug in DansGuardian (and other news)

In message <c7ffa1434a.DG@...> you wrote:

> A new(but probably old) serious bug:
> This is a real show-stopper.  IE5.5 and Netscape 6 work intolerably slow with
> DansGuardian.  Lynx, Fresco and Oregano all work really really quickly - as
> quickly as without DansGuardian filtering infact.  I have no idea as to the
> cause and I am investigating.  Don't bother trying DansGuardian if your
[snip]

This bug is now fixed so you can actually use DansGuardian in a real
situation now!

If you are interested in the technical reason why all previous versions had
this problem, email me.

I expect to be testing DansGuardian on a 1000 user (150 computer) network
later today with a 512 Kbit permanent Internet connection.  The Linux is a
PII 450 196Mb RAM.  I expect it to cope easily with the traffic.  This is my
first wide scale beta test.  If you are testing out DansGuardian, I would
like to hear.

The lastest version 0.6.3 is available now.

http://dansguardian.org/download.html
http://dansguardian.org/

--
Daniel Barron



To unsubscribe from this group, send an email to:
dansguardian-unsubscribe@egroups.com

In message <c7ffa1434a.DG@...> you wrote:

> A new(but probably old) serious bug:
> This is a real show-stopper.  IE5.5 and Netscape 6 work intolerably slow with
> DansGuardian.  Lynx, Fresco and Oregano all work really really quickly - as
> quickly as without DansGuardian filtering infact.  I have no idea as to the
> cause and I am investigating.  Don't bother trying DansGuardian if your
[snip]

This bug is now fixed so you can actually use DansGuardian in a real
situation now!

If you are interested in the technical reason why all previous versions had
this problem, email me.

I expect to be testing DansGuardian on a 1000 user (150 computer) network
later today with a 512 Kbit permanent Internet connection.  The Linux is a
PII 450 196Mb RAM.  I expect it to cope easily with the traffic.  This is my
first wide scale beta test.  If you are testing out DansGuardian, I would
like to hear.

The lastest version 0.6.3 is available now.

http://dansguardian.org/download.html
http://dansguardian.org/

--
Daniel Barron

A new(but probably old) serious bug:
This is a real show-stopper.  IE5.5 and Netscape 6 work intolerably slow with
DansGuardian.  Lynx, Fresco and Oregano all work really really quickly - as
quickly as without DansGuardian filtering infact.  I have no idea as to the
cause and I am investigating.  Don't bother trying DansGuardian if your
clients are Windross based.

And other news:
A major update to DansGuardian is due out soon.  It greatly inreases speed
of handling of html and text pages as well as fixing other bugs.  The
DataBuffer class (one of my first ever C++ classes) has been totally re-
written for speed and better programming style.  It makes the code more
simple, smaller and so quicker.  The bodge that was the DansData class is
now no longer required.

A bug that closed the connection to the client browser before it had
recieved the entire page has been fixed.  This is only noticable on faster
linux servers.  I noticed it because the DataBuffer class is now much faster.
I am compiling and testing DansGuardian on a P166!
All of the source code is now commented fully.  Previously DataBuffer was
not commented.

The HTTPHeader class is now slightly more efficient and smaller.
A bug that made some (2 I know of) forms on web pages not work has been
fixed.

A bug that made some browsers (Netscape 6, IE5, Oregano) not work with some
forms has been fixed.  Interestingly Fresco and Lynx both did not have this
problem which made it difficult to track down.
A bug in the Makefile meant that it did not create /etc/dansguardian.  I hope
this is now fixed.

The lastest version 0.6.2 will be available by the time you read this.
http://dansguardian.org/download.html

--
Daniel Barron

https://associate.com/digests/c_lug/ezmlm.cgi

has a DansGuardian thread.

associate.com is also posting an article on the front site page at
http://associate.com to appear Sunday.


--
Daniel Barron

So go get it...

The download page has information on the updates, but the main ones are
a Makefile and a SysV script.  Making compilation and installation easier.

http://dansguardian.org/
http://dansguardian.org/download.html


--
Daniel Barron

So go get it...

The download page has information on the updates.

http://dansguardian.org/
http://dansguardian.org/download.html

--
Daniel Barron