Re: [Server-devel] DansGuardian (was What's cooking in the XS pot this week, (2008-10--01))

2008-10-06 Thread David Van Assche
You may want to look into SquidGuard... it may be an alternative to
Dansguardian as it seems much lighterweight and more customizable in
the way you've been doing the bash side of things on the XS to date:
http://www.squidguard.org/

Kind Regards,
David Van Assche

On Sun, Oct 5, 2008 at 1:01 PM, Martin Langhoff
[EMAIL PROTECTED] wrote:
 On Sun, Oct 5, 2008 at 3:02 PM, Martin Langhoff
 [EMAIL PROTECTED] wrote:
 I'm still a bit ambivalent with regards to DG and how much of a good
 fit it is, so let's be clear - long term, what we want is a good
 quality content filter.

 Been ruminating on this a bit. The more I think about it, the more
 clear it is that DG on the XS is not a good long term solution.

  - from reports, it seems to be fairly cpu and memory heavy
  - and its content scanning is fairly primitive - not bayesian

 For DG to be effective, I'd like to do Bayesian filtering, with the
 ability to train it. Or something in thesame family of strategies but
 smarter. The problem is that the XS will not have enough cpu/mem to
 handle this task.

 So it's a task better pushed to a proxy/filter upstream at the ISP
 network -- for any large deployment, we should start advising the
 local team to arrange with the ISP(s?) involved the co-location of 1
 server. This server gives us an opportunity to perform

  - filtering at one central place
   = better scale up / scale out economies (making bayesian costs more
 reasonable)
   = larger scoring pool, so good/bad content gets flagged faster
 and for everyone
   = white/blacklisting is immediate and for everyone
   = better bandwidth/traffic efficiency - unwanted content never
 clogs the slow/limited school pipe
   = unsure if DG is the tool of choice here

  - smart upstream proxing
   = run an rproxy upstream or similar
   = provide seed content for downstream proxies to pull

  - With this setup, laptops can be configured to attempt to use the
 upstream proxy even when connected via a non-school AP. This way, the
 protections extend to kids accessing internet outside of school. This
 is somewhat hard to enforce - we are protecting kids that want to be
 kids. Once a kid is at a cybercafe and has the intention to sidestep
 the filter, the genie is out of the bottle: he/she could just use one
 of the other machines anyway.

 On every XS I want to include blacklisting facilities so that teachers
 can exert local control in a hurry, but that is simple, blunt, and
 hardly needs DG :-)

 In any case, we can still think of DG as a pilot deployment filter.

 cheers,



 m
 --
  [EMAIL PROTECTED]
  [EMAIL PROTECTED] -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
 ___
 Server-devel mailing list
 Server-devel@lists.laptop.org
 http://lists.laptop.org/listinfo/server-devel

___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


[Server-devel] XS testing

2008-10-06 Thread Tony Anderson
Hi,

I think there are several levels of testing, e.g. regression, 
functional, and stress. I am not planning on anything special for any
of these.

What I think we need urgently is a simple procedure someone in the field 
can use to verify an XS installation. It has to be simple and effective, 
because this person is also bringing up a school-set of XOs.

Our model is that the installer has a usb drive with XS to install at 
the school. We hope that the embedded install script will provide a 
complete configuration including network, firewall, and Moodle. The 
installer should then do things like:

1. Reboot the server and log in as root.
2. From an XO verify that it can connect with the server network.
3. From an XO verify that the 'schoolserver' link on the browser 
displays the Moodle site page.
4. From an XO verify that the browser can access the OLPC Wiki.
5. Verify that the XO sees ejabberd (telepathy-gabble)
6. Verify that two XOs connected via ejabberd can see and 'chat' with 
each other.
7. Verify that an XO receives access denied attempting to download an 
exe file
8. Verify that the XO can log in to a Moodle course with the correct 
student identification.

Naturally, I am hoping for suggestions of additional essential server 
capabilities that need to be tested (e.g. verifying backup/restore of 
the journal/datastore, access the library, install an activity).
However, we need to be careful to keep it simple and avoid testing 
features. (For example, verifying that Moodle pops up a pdf correctly is 
not a test to determine if it is running. That test is needed back in 
the development lab.)

Tony


  Regarding the testing methods, I believe that Tony is hoping to hear
   that his work creating testing scripts won't be totally orphaned.

Oh, is he working on some? Fantastic! Tony, can you post your notes /
plans / intentions!  :-)


___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] [ejabberd] Memory use with SSL connections

2008-10-06 Thread Douglas Bagnall
Evgeniy Khramtsov wrote:

 Does anyone have any tips, patches, or configuration options that might
 help?

 Most likely, OpenSSL eats all the memory. So, the solution is to rewrite
 SSL/TLS code without this library :)

Right, thanks.

That looks easy in the sense that it seems to only involve the 300
lines of src/tls/tls_drv.c, but difficult in that I have no experience
of low level SSL or XMPP programming.

Does ejabberd use a wide range of OpenSSL's functionality, or might
one of the light libraries with flakey standards coverage (e.g.,
yassl) work well enough?  It seems no-one's openssl compatibility
layer is actually compatible.


Douglas
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel