[Server-devel] XS testing

[Tony Anderson]

Thanks for your point about the 'headless' server. The install usb must 
ensure that ssh access from an XO is sufficient to complete the install 
process. As far as I know all of our installed servers will be headless.

This means the first two 'tests' should be changed:

 >> 1. Reboot the server and log in as root.
 >> 2. From an XO verify that it can connect with the server network.

1. Reboot the server and log in as root from an XO using SSH.

I don't think it makes any difference in the implementation if the usb 
drive is used to install XS at the 'depot' or at the school. At the 
'depot', it may be desirable to have the servers boot from the network. 
As I understand it, this can be done using the same files used to create 
the usb drive.

Incidentally, one point in favor of a laptop as server is that it's 
battery may come in handy in schools with unstable power.

Tony

Martin Langhoff wrote:
> On Tue, Oct 7, 2008 at 7:04 AM, Tony Anderson <tony_anderson at usa.net> wrote:
>> 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.
> 
> This is great. I had not thought of this, but the moment Bryan
> mentioned I clicked with it. Excellent idea.
> 
>> 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.
> 
> This is one of the possible scenarios, and likely to be common in
> pilots. In large deployments it makes sense to preinstall the XS image
> at HQ because
> 
>  - it can be done in parallel
>  - OS install can be network-based
>  - Additional content can be installed via the network
>  - checks that the machine works while there's a good chance you have
> spare parts too! :-)
> 
> Which is a long-winded way of saying: we need to take multiple
> scenarios into account. In some of the scenarios the user may not have
> root access or shell access. In some scenarios, the machine will be
> completely headless...
> 
>> 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.
> 
> Good list. Here's my challenge: I think we can do everything in the
> list without logging in / using the shell console at all on the XS.
> 
>> 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.
> 
> Agreed. If the tests are simple enough, they can even be performed by
> a teacher, which means that the local team has a goodtool to use
> before they send a technician to the field.
> 
> So we'd have 2 sets:
>  - tests you can run from an XO
>  - addittional tests you can run if you have shell / root access
> 
> what do you think?
> 
> 
> 
> m