Re: [Server-devel] [XSCE]
I can also give my personal opinion. Responses inline. On Sat, Oct 12, 2013 at 8:54 AM, Tim Moody t...@timmoody.com wrote: Everyone will be shy to respond, but here's my take. First, the motivation is that the benefit of a school server, especially in non or occasionally connected environments, is assumed. Secondly, let's be clear that you asked about goals, not what we've accomplished. The goal of the XSCE project is to continue development of the OLPC XS project along the following lines: 1. Absorb features from all the various incarnations of XS including 0.7, Nepal, Australia, and any others and make it available on a variety of platforms including intel, but also incredibly cheap and incredibly low power devices, such as the XO but also raspi, trimslice, cubox, and others as they come to market. These features fall into three broad categories, infrastructure such as routing, support for XO specific services, and general (web) server based applications and content. 2. Move installation and configuration from something that happens along with the OS installation to something an end user could do using a gui whenever she likes, if required. 3. Provide a mechanism whereby features can be contributed by interested members of the community without rebuilding a disk image or an rpm. I had contacted various deployments over the summer, and through conversations with them, compiled a list of considerations: https://sugardextrose.org/projects/xsce/wiki/primary_considerations Answers to specific questions below. -Original Message- From: Tony Anderson Sent: Friday, October 11, 2013 11:10 AM To: xsce-de...@googlegroups.com Subject: Re: [XSCE] Hi, All Help me understand a little about where this project is going. I understood XSCE initially as an attempt to use an XO as the school server. This was motivated by two requirements: (1) support for deployments which were constrained to use XO and (2) use of the XO-1.75 as the school server to enable use of the lower power ARM architecture. and also make use of various other low power ARM hardware, like trimslice, etc. There is no constraint, that the XSCE is limited to just these platforms. It is intended to run on generic x86 equally well. Apparently one outcome is that the XS-0.7 install procedure was replaced by a requirement to add school server capabilities to a previously installed build (e.g. 13.2). The XS architecture separated the disk into two partitions: root and library. The intent was to separate software (root) from content (library). This would support backup of the library partition since the root partition could be restored by a new install followed by simple copy of the backup to the library partition. Does XSCE maintain this architecture? XSCE requires that the OS be pre-installed, so the disk partitioning is a priori. However, some of us have encouraged people to place content in the /library directory so that it can take advantage of a separate partition if there is one. It would certainly be possible to mount external devices as /library. The XO build is installed as a copy of an image from a usb drive to the internal store. Work is being done on this installation mechanism, but up to now server content has been installed as an rpm, which has dependencies on other rpms and scripts to do various work like configuring networking, etc. The repositories can be remote or local. The new ansible install still operates at the time of initial installation, but avoids having to build rpms and holds the promise of incremental configuration. The XS install is a normal OS install in which a minimal Linux OS executes a script from a ramdisk to access the USB flash drive, decompress files and to copy them to the newly created partitions. Apparently, XSCE is installed by the previously installed OS (13.2). What is the dependency of XSCE on this OS? Does the XSCE install replace it? In the rpm and ansible scenarios it does not replace the OS on the XO or any other device. Naturally, the XO software build is for a client machine. It is based on graphical user interface, keyboard, and track pad. A server is intended to supply services to other computers (clients) via a network. As such, it is intended to be operated headless. Control of the server is normally by a remote login and command line operations. How does XSCE handle the change from a client machine to a server? Does it require a monitor and keyboard (or touchscreen)? Like XS, XSCE requires a monitor and keyboard (built into the XO) for installation, but can be basically headless thereafter. Most of us turn on sshd and do the entire install remotely. Probably other devices can come up with sshd capability already on and be entirely headless, if you can figure out their ip address. +1 The intent is to install and update on headless hardware. There is discussion of a home page.
Re: [Server-devel] [XSCE]
Hi Tony, I'd add to Tim's comments: Sridhar, early in the XSCE design, made a distinction between project, and product, which I find useful -See- https://docs.google.com/document/d/1dnhU2F6EntepVXTgN8QpkME8fZVUuPjcCoMUfAVKbcc/edit-- follow the Product vs Distribution vs Product link. XS0.7 was a product, whereas XSCE is attempting to be a project. By reconceptualizing, and restructuring the install process, now with the higher level server description language, called ansible, we are attempting to position the code base to be flexible, and applicable, to new distributions, hardware, processors, needs and requirements. As such, XSCE is not meant to be directly usable until it is married with specific hardware, and a set of requirements. Two examples come to mind: 1. In September, I installed an XO4 and a trimslice at two schools in Haiti. One with gateway function via 3G modem and Internet In A Box on an XO4, the other with IIAB function on a Trimslice, and a large storage battery, to deal with intermittent power. 2. There is now a $100 low power quad core ARM becoming available (6 watt 2GB memory- CubeBox ) which XSCE software stack may be adapted to. XSCE project moved away from Centos, partially because we wanted to run on ARM as well as i386/x86_64. Also, we did not want dependencies on punji, kickstart, or anaconda that would lock us into fedora, as we looked forward towards running on debian/ubuntu, or such. Yes, much of what we have done does not directly add value in the classroom. But hopefully it positions our code base to be relevant in the classroom for the next 10 years. It's also true that we have not yet defined a product, or turnkey solution. Be we have a growing cadre of programmers, with skills to do that. It appears that Activitycentral is moving in that direction with DXS. George On Sat, Oct 12, 2013 at 11:54 AM, Tim Moody t...@timmoody.com wrote: Everyone will be shy to respond, but here's my take. First, the motivation is that the benefit of a school server, especially in non or occasionally connected environments, is assumed. Secondly, let's be clear that you asked about goals, not what we've accomplished. The goal of the XSCE project is to continue development of the OLPC XS project along the following lines: 1. Absorb features from all the various incarnations of XS including 0.7, Nepal, Australia, and any others and make it available on a variety of platforms including intel, but also incredibly cheap and incredibly low power devices, such as the XO but also raspi, trimslice, cubox, and others as they come to market. These features fall into three broad categories, infrastructure such as routing, support for XO specific services, and general (web) server based applications and content. 2. Move installation and configuration from something that happens along with the OS installation to something an end user could do using a gui whenever she likes, if required. 3. Provide a mechanism whereby features can be contributed by interested members of the community without rebuilding a disk image or an rpm. Answers to specific questions below. -Original Message- From: Tony Anderson Sent: Friday, October 11, 2013 11:10 AM To: xsce-de...@googlegroups.com Subject: Re: [XSCE] Hi, All Help me understand a little about where this project is going. I understood XSCE initially as an attempt to use an XO as the school server. This was motivated by two requirements: (1) support for deployments which were constrained to use XO and (2) use of the XO-1.75 as the school server to enable use of the lower power ARM architecture. Apparently one outcome is that the XS-0.7 install procedure was replaced by a requirement to add school server capabilities to a previously installed build (e.g. 13.2). The XS architecture separated the disk into two partitions: root and library. The intent was to separate software (root) from content (library). This would support backup of the library partition since the root partition could be restored by a new install followed by simple copy of the backup to the library partition. Does XSCE maintain this architecture? XSCE requires that the OS be pre-installed, so the disk partitioning is a priori. However, some of us have encouraged people to place content in the /library directory so that it can take advantage of a separate partition if there is one. It would certainly be possible to mount external devices as /library. The XO build is installed as a copy of an image from a usb drive to the internal store. Work is being done on this installation mechanism, but up to now server content has been installed as an rpm, which has dependencies on other rpms and scripts to do various work like configuring networking, etc. The repositories can be remote or local. The new ansible install still operates at the time of initial installation, but avoids having to build rpms and
Re: [Server-devel] [XSCE]
On Sat, Oct 12, 2013 at 9:58 AM, George Hunt georgejh...@gmail.com wrote: Hi Tony, I'd add to Tim's comments: Sridhar, early in the XSCE design, made a distinction between project, and product, which I find useful -See- https://docs.google.com/document/d/1dnhU2F6EntepVXTgN8QpkME8fZVUuPjcCoMUfAVKbcc/edit -- follow the Product vs Distribution vs Product link. XS0.7 was a product, whereas XSCE is attempting to be a project. The correct answer to the million dollar question. Excellent! Sameer By reconceptualizing, and restructuring the install process, now with the higher level server description language, called ansible, we are attempting to position the code base to be flexible, and applicable, to new distributions, hardware, processors, needs and requirements. As such, XSCE is not meant to be directly usable until it is married with specific hardware, and a set of requirements. Two examples come to mind: In September, I installed an XO4 and a trimslice at two schools in Haiti. One with gateway function via 3G modem and Internet In A Box on an XO4, the other with IIAB function on a Trimslice, and a large storage battery, to deal with intermittent power. There is now a $100 low power quad core ARM becoming available (6 watt 2GB memory- CubeBox ) which XSCE software stack may be adapted to. XSCE project moved away from Centos, partially because we wanted to run on ARM as well as i386/x86_64. Also, we did not want dependencies on punji, kickstart, or anaconda that would lock us into fedora, as we looked forward towards running on debian/ubuntu, or such. Yes, much of what we have done does not directly add value in the classroom. But hopefully it positions our code base to be relevant in the classroom for the next 10 years. It's also true that we have not yet defined a product, or turnkey solution. Be we have a growing cadre of programmers, with skills to do that. It appears that Activitycentral is moving in that direction with DXS. George On Sat, Oct 12, 2013 at 11:54 AM, Tim Moody t...@timmoody.com wrote: Everyone will be shy to respond, but here's my take. First, the motivation is that the benefit of a school server, especially in non or occasionally connected environments, is assumed. Secondly, let's be clear that you asked about goals, not what we've accomplished. The goal of the XSCE project is to continue development of the OLPC XS project along the following lines: 1. Absorb features from all the various incarnations of XS including 0.7, Nepal, Australia, and any others and make it available on a variety of platforms including intel, but also incredibly cheap and incredibly low power devices, such as the XO but also raspi, trimslice, cubox, and others as they come to market. These features fall into three broad categories, infrastructure such as routing, support for XO specific services, and general (web) server based applications and content. 2. Move installation and configuration from something that happens along with the OS installation to something an end user could do using a gui whenever she likes, if required. 3. Provide a mechanism whereby features can be contributed by interested members of the community without rebuilding a disk image or an rpm. Answers to specific questions below. -Original Message- From: Tony Anderson Sent: Friday, October 11, 2013 11:10 AM To: xsce-de...@googlegroups.com Subject: Re: [XSCE] Hi, All Help me understand a little about where this project is going. I understood XSCE initially as an attempt to use an XO as the school server. This was motivated by two requirements: (1) support for deployments which were constrained to use XO and (2) use of the XO-1.75 as the school server to enable use of the lower power ARM architecture. Apparently one outcome is that the XS-0.7 install procedure was replaced by a requirement to add school server capabilities to a previously installed build (e.g. 13.2). The XS architecture separated the disk into two partitions: root and library. The intent was to separate software (root) from content (library). This would support backup of the library partition since the root partition could be restored by a new install followed by simple copy of the backup to the library partition. Does XSCE maintain this architecture? XSCE requires that the OS be pre-installed, so the disk partitioning is a priori. However, some of us have encouraged people to place content in the /library directory so that it can take advantage of a separate partition if there is one. It would certainly be possible to mount external devices as /library. The XO build is installed as a copy of an image from a usb drive to the internal store. Work is being done on this installation mechanism, but up to now server content has been installed as an rpm, which has dependencies on other rpms and scripts to do various work like configuring networking, etc.
Re: [Server-devel] Server-devel Digest, Vol 78, Issue 15
Hi, George The following from Sridhar's page appears to be relevant: Project vs Distribution vs Product It is important to define the concepts of project, distribution and product. A projectis an ongoing effort to develop a technical solution. It is under constant flux and hence is not generally intended for end-users. A distributionis a packaging of a version/snapshot of the project's files, often configured for a particular purpose. A productis more comprehensive, providing properties such as ease of use, QA and accompanying documentation. What makes a product really stand out is integration with other parts of the deployment organisation's business. This can include factors such as supply chain, technical support and the educational programme. The community XS is a project, open to participation/use by anyone. Deployments are encouraged to create their own distribution/product to better suit their needs. For OLPC Australia, this will take the form of our One Network https://docs.google.com/document/d/1dnhU2F6EntepVXTgN8QpkME8fZVUuPjcCoMUfAVKbcc/edit?pli=1#heading=h.60mn085jgn8eproduct. This section outlines the architecture of the community XS. Scenarios Here are some scenarios that the community XS should be compatible with. Non-conflicting combinations of these should also be possible. 1. it hosts the network, acting as an access point itself 2. it hosts the network, and bridges to an external wireless access point 3. it acts as a gateway to another network, such as the Internet 4. it participates on an existing network, without hosting core services 5. one XS server serves the whole school 6. many XS servers participate on the same network 7. the XS optionally provides services such as collaboration, registration, roster groups (presence segregation), backups and content on a modular basis I do not see the distinction you make between XS and XSCE. XS-0.7 was developed by Daniel Drake as an ongoing effort started by Martin Langhoff. The major difference is that this project was a part of OLPC and not the community. The real question is whether the community is adopting and continuing the XS project or starting a new one. As a continuation of the XS project, the first step could have been to build XS-0.7 with a Fedora base. This essentially requires performing the build process with a Fedora repository instead of CentOS. This would have made XS-0.7 available for ARM-based platforms. Sridhar did not mention 'remix' in his description. Generally for servers, the distinction is distribution + desktop vs distribution + server. In the discussion of scenarios, Sridhar does not mention the most important point of the school server architecture, the distinction between LAN and WAN. Here is a revised description. Note: all of Sridhar's scenarios are currently fully supported by XS-0.7. 1. it hosts the LAN network 2. it may be connected to one or more wireless routers 3. it acts as a gateway to another network (WAN), such as the Internet 4. it participates on an existing network (WAN) , without hosting core services for that network 5. one or more XS servers serve the whole school, dependingi on the number of XOs deployed. 6. many XS servers may participate on the same (WAN) network 7. the XS provides services such as collaboration, registration, roster groups (presence segregation), backups and content. These services may be used or not at the discretion of the deployment. See below for specific comments. On 10/12/2013 12:57 PM, server-devel-requ...@lists.laptop.org wrote: Message: 2 Date: Sat, 12 Oct 2013 12:58:28 -0400 From: George Huntgeorgejh...@gmail.com To: xsce-develxsce-de...@googlegroups.com, XS Devel server-devel@lists.laptop.org Subject: Re: [Server-devel] [XSCE] Message-ID: CADfCcpU-XQ2=wDjWRbHcrwfmJKTZs=tangb_kiseio6zsnw...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi Tony, I'd add to Tim's comments: Sridhar, early in the XSCE design, made a distinction between project, and product, which I find useful -See- https://docs.google.com/document/d/1dnhU2F6EntepVXTgN8QpkME8fZVUuPjcCoMUfAVKbcc/edit-- follow the Product vs Distribution vs Product link. XS0.7 was a product, whereas XSCE is attempting to be a project. By reconceptualizing, and restructuring the install process, now with the higher level server description language, called ansible, we are attempting to position the code base to be flexible, and applicable, to new distributions, hardware, processors, needs and requirements. I still do not understand who is the user of Ansible. It would seem to a be a tool for use of the XSCE project, not its clients. As such, XSCE is not meant to be directly usable until it is married with specific hardware, and a set of requirements. Two examples come to mind: 1. In September, I installed an XO4 and a trimslice at
Re: [Server-devel] [XSCE] ansible
Fri, Oct 11, 2013 at 10:04 AM, tkk...@nurturingasia.com wrote: Managed to install it. Nice ansible and all the goodies for server management An install note - sometimes the first runthrough of runansible fails for me. Not always, I think it's the vagaries of my internet and/or wifi. I simply runansible again (and again, if needed) until it finally finishes. How stable is the system? I am able to load the IIAB demo files (on a USB stick). It will work for a while and then crash... Just as on the XSCE, on the DXS we've noticed stability issues on low end 1.75 units. The 1.75's with 512MB of RAM, to be specific. In particular, yes, IIAB crashes the low end 1.75 if a few (as in 3) clients try to access IIAB content at the same time. I think folks determined it was some sort of kernel issue. But yeah, the system freezes up, is totally unresponsive even on the local console, and I have to do a hard reboot (as in walk over to it, press down the power button till it powers off, then power back up). I don't try to put that crappy 1.75 up on my public URL anymore, I've found it to be entirely too unstable. However, my testing cycles can be very short and rather specific, thus sometimes I need to reflash a unit several times a day. For those testing cycles confined to my LAN, I mostly use the crappy 1.75 because it wouldn't break my heart if it broke, unlike these units below: *What I have found to be very stable for XSCE and DXS* 1. The XO 1.5 (got one up right now public, uptime 9 days with the full IIAB TB drive) Apparently there's almost 1GB RAM [root@schoolserver] html free -m total used free sharedbuffers cached Mem: 936824112 0 60543 2. The XO 1.75 HS with the chicklet keyboard Looks like this thing has 840MB RAM? -bash-4.2# free -m total used free sharedbuffers cached Mem: 840418422 0 21146 3. The XO-4 For stability testing, I typically make the XSCE or DXS public. During end of cycle testing, I try to keep the install up public at least a week, if not longer. I have ejabberd users who always notice when my server goes down. Not only can I see downtime in my scrollback in Pidgin or Psi or Gajim (any chat client that handles XMPP), but my users will literally call me on my telephone to let me know if my server is down. So far with XSCE/DXS testing, I haven't gotten any phone calls. Again, the only stability issue we've run into was when I tried to run the XSCE/DXS on the crappy 1.75 with IIAB. Anna -Original Message- From: Anna [mailto:ascho...@gmail.com] Sent: Friday, October 11, 2013 08:20 AM To: 'xsce-devel' Cc: 'Server Devel' Subject: Re: [XSCE] ansible Couple of postinstall notes: xs-authserver has some sort of conflict with the library versions that IIAB installs. This gets xs-authserver working (don't worry, it doesn't break IIAB): pip install --upgrade --force-reinstall Werkzeug Flask systemctl restart xs-authserver OLPC Backup needs a permissions fix in /etc/rssh.conf, so uncomment: allowrsync allowsftp Here's my testing checklist. Thought I'd paste this in so y'all can see how similar to XSCE DXS is, and also how to access DXS specific things like Munin, Ajenti, and xs-authserver. Item Access from Note dhcpd Client Client gets an IP address in the 172.18.x.x range dhcpd Server Check /var/lib/dhcpd/dhcpd.leases for client leases idmgr Client Registration - Register the XOidmgr Server Check /library/users for the XO's Serial Number dir ejabberd Client 2 registered clients can see each other ejabberd Server `ejabberdctl connected_users` reports the 2 registered clients ejabberd Clients Share the chat activity and communicate httpd Client http://schoolserver and http://schoolserver.local resolves to Apache test page Moodle Client http://schoolserver.local/moodle autologs in Authserver Client http://schoolserver.local:5000 greets with the XO buddy name Squid Server Check /library/cache size, load webpage on client, verify size has increased Dansguardian Client Try to look at porn? No way!IIAB Client http://schoolserver/iiab resolvesOLPC-Backup Server du -sk /library/users/* indicates backups Stats Server A client's rrds are in /library/sugar-stats/rrd/ Monit Server Halt services and see if they restartMunin Client http://schoolserver/munin user:admin pass:munindxs Ajenti Client http://schoolserver:9990 user:root pass:admin Ajenti Wondershaper Client Verify bandwidth edits via online speedtest such as speakeasy.net/speedtest Upload Activity N/A /var/www/html/upload_activity.php is currently not present - WIP On Thu, Oct 10, 2013 at 2:46 PM, Anish Mangal an...@activitycentral.com wrote: Documented in the githup repo here:
