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

[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

[Server-devel] XS testing

[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] DansGuardian (was What's cooking in the XS pot this week, (2008-10--01))

[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