Re: [Server-devel] Regarding my OLPC XS Wishlist
There's OBS (build packages for multiple distros) and suse studio, the latter builds isos, and if I understand it correctly not just suse isos, its kind of a drag and drop tool where you choose what your iso should contain And I would hardly say openSUSE is a minor distro... next to Ubuntu and Fedora, probably the most known and used... though I guess much more so outside the US, seeing as its German in origin... kind regards, David Van Assche On Thu, Jun 2, 2011 at 11:20 AM, Aleksey Lim alsr...@activitycentral.orgwrote: On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: On 28 May 2011 08:31, Aleksey Lim alsr...@activitycentral.org wrote: On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote: On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Thank you! Forwarding this to the Dextrose list as well. I've also CCed guys who do XS work in .au Abhishek: thanks for sharing your wishlist. From my side, I see the whole picture in case of school server like having: * sugar-server[1], the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so) * any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace[2]). * final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs. We are looking to make our XS-AU[0] more modular to suit different use cases. Our initial goal (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? sugar-server in that case is a new project w/ more tough and localized design. work on a single interface to integrate well into existing networks. Installation is via USB and fully scriptable via kickstart files. The current XS is very monolithic and bureaucratic. It requires moderate sysadmin skills to install and maintain. Maintaining the presence service is cumbersome and impractical in our schools. The turnover of teachers and students is far too high to ensure that anything gets managed properly. We're looking to slim down the XS-AU such that we can have a simple collaboration server (which we currently call XS Lite) that is installable in a classroom as a drop-in appliance. ie, just having jabber server and somehow let students know where it is? is an ejabberd. btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Registration, Moodle, Squid, backups and so on are unnecessary. Each teacher can run their own server for their own class. Conveniently, this could easily run on an XO (XS-on-XO). in other workds there is no need in sugar specific stuff at all - just install jabber server from packages (maybe w/ sugar specific patches) and write its url on studensts' boxes. My own running though your wishlist keeping in mind sugar-server plans: 1) Porting XS to new version of Fedora sugar-server will be build on OBS[3] for distros that are being used in the field (deb or/and rpm based). So, downstream can just use these packages, add new one and create the final product (there is an idea to teach OBS to create isos for not only SUSE, obs is designed originally) You're using SuSE as a base? That sounds like an awful lot of work porting to a distribution that isn't widely used. Why not stick with the current platform, which benefits from Red Hat engineering and has a much larger developer, installation and user base? Not to mention that the XOs use the same platform, meaning that skills can be shared across client and server. OBS is not only suse (in fact, they renamed it from openSuse Build Service to Open Build System recently). In other words, it can create package for any rpm/deb based distro, but, afaik, it can create iso only for opensuse for now (and plan is looking how it might be done for other distros, but anyway using obs as a packages farm is good w/o having isos). The XS-AU has been working pretty well on Fedora 11 for quite some time. We've
Re: [Server-devel] Regarding my OLPC XS Wishlist
Hi, I hope we can keep Abhisek in the loop as he has detailed information on the XS version deployed in Nepal. The procedure there is to build XS and release it as an img. The image is loaded to a usb drive (mkusbinstall.sh). This key is used to install all of the deployed school servers. I have attached the instructions for installing NEXS from the olenepal redmine (slightly edited). I am very internet-challenged (at this campground I arrived on Thursday and used the internet for about two hours and then it died - now on Sunday evening it is working intermittently!), so I think some of my previous comments have not been received. So please be patient if you have read this before: I think the separation of the server into two components XS and XC is very valuable. The XC build should provide a working schoolserver which can be accessed via the LAN from an XO using ssh. With the XS-Au fix for the 'race' condition in kickstart, it should be possible to do this install 'headless' on a server which supports booting from the usb drive when present (and bootable). XC provides the content for the /library partition. However, with Daniel Drake's usbmount scripts XC could be used to install any optional packages such as Dan's Guardian, Moodle (forgive me, Martin), Fedora Commons, Fez, mediawiki, and so on. The netsetup.sh script should be used to configure the WAN network and should not be needed when the school server is not connected to an external network (the LAN network is configured the same in every school as 172.18.0.1). The LAN should be configured for the baseboard (RJ45) port and the WAN for a secondary port (e.g. usb-ethernet). Essentially this is the procedure used in Nepal with considerable success over the past two years (success measured by the schoolserver very rarely being a problem requiring service (UPS failures seem far more frequent). Tony P.S. http://wiki.laptop.org/go/OLE_Nepal:Procedure_to_build_NEXS_from_OLPC_XS gives a description of the build procedure used for XS-0.4. It provides details on the installation of the extra packages as of that time. Abhishek Singh can provide more recent details. On 06/03/2011 04:21 PM, Sridhar Dhanapalan wrote: On 4 June 2011 00:00, Aleksey Limalsr...@activitycentral.org wrote: On Fri, Jun 03, 2011 at 09:40:48AM -0400, Martin Langhoff wrote: On Fri, Jun 3, 2011 at 7:49 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 3 June 2011 21:31, Aleksey Limalsr...@activitycentral.org wrote: btw, did someone try to use cloning paradigm for setting up new school servers instead of using regular install way? Just clonning the system will lest avoid many issues by design. Do you mean creating an image of a server installation and applying it to other machines? We've done that with the XS-AU (using clonezilla), and I'm pretty sure it works with an OLPC XS. Note that without a script that cleans up config state, you're bound to have some fun problems with the resulting systems. Do you mean particular script, which one? You'll need to clean up: /etc/udev/rules.d/70-persistent-net.rules (delete the lines that refer to all the eth devices) /etc/sysconfig/network-scripts/ifcfg-eth* (remove the HWADDR line) ssh keys (/etc/ssh/ssh_host_*) postgresql server.crt Info: http://dev.laptop.org.au/issues/422 Sridhar NEXS installation¶ From USB¶ 1. Take a USB disk, create a single partition with type 0x83 (Linux) (e.g. using fdisk) and format it as VFAT (e.g. using mkfs.vfat) * This conflict of partition type vs filesystem is intentional; the Anaconda installer seems a bit sensitive to other configurations and may get confused at the bootloader install stage if you don't use this configuration 2. Download the NEXS .iso corresponding to the NEXS version that you want to install to your hard disk 3. Download http://hg.olenepal.org/NEXS-image-builder/raw-file/tip/mkusbinstall to your hard disk 4. Run: # sudo bash ./mkusbinstall /path/to/nexs.iso /dev/sdb1 * where /dev/sdb1 is the partition of your USB disk 5. Plug the USB disk into the Wind computer 6. Turn on and press F11 until menu appears 7. Choose USB device from the boot device menu 8. Choose the default Install with kickstart option from the boot menu 9. After a few seconds, you will see an error that says that the kickstart file cannot be found. Wait 5 seconds, then press enter twice to retry. * This is an Anaconda bug where it tries to access the USB disk before it is ready 10. You may see another error message saying that the installation media cannot be found. If so, try selecting /dev/sdc1 as the installation device (the default is sdb1) * This is because on some Wind systems, the onboard SD card reader takes the sdb position Once installation completes, the system will reboot. Remove the USB disk at this time, and continue with the
Re: [Server-devel] Regarding my OLPC XS Wishlist
On 06/05/2011 09:42 PM, Tony Anderson wrote: Hi, I hope we can keep Abhisek in the loop as he has detailed information on the XS version deployed in Nepal. The procedure there is to build XS and release it as an img. The image is loaded to a usb drive (mkusbinstall.sh). This key is used to install all of the deployed school servers. I have attached the instructions for installing NEXS from the olenepal redmine (slightly edited). I am very internet-challenged (at this campground I arrived on Thursday and used the internet for about two hours and then it died - now on Sunday evening it is working intermittently!), so I think some of my previous comments have not been received. So please be patient if you have read this before: I think the separation of the server into two components XS and XC is very valuable. The XC build should provide a working schoolserver which can be accessed via the LAN from an XO using ssh. With the XS-Au fix for the 'race' condition in kickstart, it should be possible to do this install 'headless' on a server which supports booting from the usb drive when present (and bootable). XC provides the content for the /library partition. However, with Daniel Drake's usbmount scripts XC could be used to install any optional packages such as Dan's Guardian, Moodle (forgive me, Martin), Fedora Commons, Fez, mediawiki, and so on. The netsetup.sh script should be used to configure the WAN network and should not be needed when the school server is not connected to an external network (the LAN network is configured the same in every school as 172.18.0.1). The LAN should be configured for the baseboard (RJ45) port and the WAN for a secondary port (e.g. usb-ethernet). Essentially this is the procedure used in Nepal with considerable success over the past two years (success measured by the schoolserver very rarely being a problem requiring service (UPS failures seem far more frequent). Tony P.S. http://wiki.laptop.org/go/OLE_Nepal:Procedure_to_build_NEXS_from_OLPC_XS gives a description of the build procedure used for XS-0.4. It provides details on the installation of the extra packages as of that time. Abhishek Singh can provide more recent details. On 06/03/2011 04:21 PM, Sridhar Dhanapalan wrote: On 4 June 2011 00:00, Aleksey Limalsr...@activitycentral.org wrote: On Fri, Jun 03, 2011 at 09:40:48AM -0400, Martin Langhoff wrote: On Fri, Jun 3, 2011 at 7:49 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 3 June 2011 21:31, Aleksey Limalsr...@activitycentral.org wrote: btw, did someone try to use cloning paradigm for setting up new school servers instead of using regular install way? Just clonning the system will lest avoid many issues by design. Do you mean creating an image of a server installation and applying it to other machines? We've done that with the XS-AU (using clonezilla), and I'm pretty sure it works with an OLPC XS. Note that without a script that cleans up config state, you're bound to have some fun problems with the resulting systems. Do you mean particular script, which one? You'll need to clean up: /etc/udev/rules.d/70-persistent-net.rules (delete the lines that refer to all the eth devices) /etc/sysconfig/network-scripts/ifcfg-eth* (remove the HWADDR line) ssh keys (/etc/ssh/ssh_host_*) postgresql server.crt Info: http://dev.laptop.org.au/issues/422 Sridhar Hi Tony, and all, Greetings from Nepal. I would like to correct a few things in Tony's descriptions and elaborate upon what he discussed. NEXS (the Nepalese version built upon OLPC XS) has separated the content part from the base server. We call the content part NEXC (C for content). This separation has helped us a lot in managing content bundles and content updates. The NEXC generally contains: 1. Content of the digital library (see http://www.pustakalaya.org), which is spanned across: * Database dumps for Fedora Commons and Fez * Fedora Commons datastream files * Fez's customized interface (that is being used at pustakalaya.org) 2. Wiki for schools 3. English Wiktionary 4. Nepali Dictionary 5. External Content: All the other static content (e.g. video files, maps etc) are packaged as external content 6. Learn English Kids from British Council (recently added) We have a 3-month NEXC release schedule. At every release, we'll bundle the most recent content and put it on a USB HDD, test it internally on our test school server, and then finally release it. After every release, the deployment team will go to the schools with the USB HDDs and plug it to the school server at the site schools. Daniel Drake's usbmount script takes care of installing/updating the content from the USB HDDs - you just nee to listen to the starting and the ending beep during which all the content update is done. We have tried updating it over Internet, but the
Re: [Server-devel] Regarding my OLPC XS Wishlist
On 28 May 2011 08:31, Aleksey Lim alsr...@activitycentral.org wrote: On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote: On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Thank you! Forwarding this to the Dextrose list as well. I've also CCed guys who do XS work in .au Abhishek: thanks for sharing your wishlist. From my side, I see the whole picture in case of school server like having: * sugar-server[1], the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so) * any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace[2]). * final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs. We are looking to make our XS-AU[0] more modular to suit different use cases. Our initial goal (completed over a year ago) was to make it work on a single interface to integrate well into existing networks. Installation is via USB and fully scriptable via kickstart files. The current XS is very monolithic and bureaucratic. It requires moderate sysadmin skills to install and maintain. Maintaining the presence service is cumbersome and impractical in our schools. The turnover of teachers and students is far too high to ensure that anything gets managed properly. We're looking to slim down the XS-AU such that we can have a simple collaboration server (which we currently call XS Lite) that is installable in a classroom as a drop-in appliance. All we really need is an ejabberd. Registration, Moodle, Squid, backups and so on are unnecessary. Each teacher can run their own server for their own class. Conveniently, this could easily run on an XO (XS-on-XO). My own running though your wishlist keeping in mind sugar-server plans: 1) Porting XS to new version of Fedora sugar-server will be build on OBS[3] for distros that are being used in the field (deb or/and rpm based). So, downstream can just use these packages, add new one and create the final product (there is an idea to teach OBS to create isos for not only SUSE, obs is designed originally) You're using SuSE as a base? That sounds like an awful lot of work porting to a distribution that isn't widely used. Why not stick with the current platform, which benefits from Red Hat engineering and has a much larger developer, installation and user base? Not to mention that the XOs use the same platform, meaning that skills can be shared across client and server. The XS-AU has been working pretty well on Fedora 11 for quite some time. We've reconfigured it so that it runs as a set of packages on top of Fedora 11[1] rather than being a fork. We're quire confident that it'll work on Fedora 13 without much effort. Fedora 14 will need a bit of work since it has a newer version of Python. Sridhar [0] http://dev.laptop.org.au/projects/xs-au/wiki [1] http://dev.laptop.org.au/projects/xs-au/wiki/Install_on_an_existing_Fedora_installation Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: On 28 May 2011 08:31, Aleksey Lim alsr...@activitycentral.org wrote: On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote: On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Thank you! Forwarding this to the Dextrose list as well. I've also CCed guys who do XS work in .au Abhishek: thanks for sharing your wishlist. From my side, I see the whole picture in case of school server like having: * sugar-server[1], the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so) * any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace[2]). * final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs. We are looking to make our XS-AU[0] more modular to suit different use cases. Our initial goal (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? sugar-server in that case is a new project w/ more tough and localized design. work on a single interface to integrate well into existing networks. Installation is via USB and fully scriptable via kickstart files. The current XS is very monolithic and bureaucratic. It requires moderate sysadmin skills to install and maintain. Maintaining the presence service is cumbersome and impractical in our schools. The turnover of teachers and students is far too high to ensure that anything gets managed properly. We're looking to slim down the XS-AU such that we can have a simple collaboration server (which we currently call XS Lite) that is installable in a classroom as a drop-in appliance. ie, just having jabber server and somehow let students know where it is? is an ejabberd. btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Registration, Moodle, Squid, backups and so on are unnecessary. Each teacher can run their own server for their own class. Conveniently, this could easily run on an XO (XS-on-XO). in other workds there is no need in sugar specific stuff at all - just install jabber server from packages (maybe w/ sugar specific patches) and write its url on studensts' boxes. My own running though your wishlist keeping in mind sugar-server plans: 1) Porting XS to new version of Fedora sugar-server will be build on OBS[3] for distros that are being used in the field (deb or/and rpm based). So, downstream can just use these packages, add new one and create the final product (there is an idea to teach OBS to create isos for not only SUSE, obs is designed originally) You're using SuSE as a base? That sounds like an awful lot of work porting to a distribution that isn't widely used. Why not stick with the current platform, which benefits from Red Hat engineering and has a much larger developer, installation and user base? Not to mention that the XOs use the same platform, meaning that skills can be shared across client and server. OBS is not only suse (in fact, they renamed it from openSuse Build Service to Open Build System recently). In other words, it can create package for any rpm/deb based distro, but, afaik, it can create iso only for opensuse for now (and plan is looking how it might be done for other distros, but anyway using obs as a packages farm is good w/o having isos). The XS-AU has been working pretty well on Fedora 11 for quite some time. We've reconfigured it so that it runs as a set of packages on top of Fedora 11[1] rather than being a fork. We're quire confident that it'll work on Fedora 13 without much effort. Fedora 14 will need a bit of work since it has a newer version of Python. Sridhar [0] http://dev.laptop.org.au/projects/xs-au/wiki [1] http://dev.laptop.org.au/projects/xs-au/wiki/Install_on_an_existing_Fedora_installation Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au -- Aleksey
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 02, 2011 at 09:20:55AM +, Aleksey Lim wrote: On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? sugar-server in that case is a new project w/ more tough and localized design. btw whats the clon url for http://dev.laptop.org.au/projects/xs-au/repository reading sources from web pages is not too useful -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, 2011-06-02 at 09:37 +, Aleksey Lim wrote: On Thu, Jun 02, 2011 at 09:20:55AM +, Aleksey Lim wrote: On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? sugar-server in that case is a new project w/ more tough and localized design. btw whats the clon url for http://dev.laptop.org.au/projects/xs-au/repository reading sources from web pages is not too useful git.laptop.org.au/xo-au/ git.laptop.org.au/xs-au/ Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
Hi, My most important wish on the list has been fulfilled, the developers are talking to each other on the same list! My own two cents. OLE Nepal has been very successful in dividing the server into two components: XS - the base server (Sugar server) and XC - the content install. The XC install uses Daniel Drake's usbmount and is made from an external hard drive (the size of the content is too large for a usb stick to be economical). The concept is that XS provides the basic LAMP stack plus the Sugar specific needs (ejabberd, lease-activation, XO registration, and so on). Once XS is installed, there is enough functionality to install the packages and associated content (e.g. mediawiki, Java, and so on). XC is an appropriate time and place to provide the optional packages. For example, Dan's Guardian and Moodle are currently in the OLE Nepal XS but could be installed as part of XS. An important factor in XC is to ensure that all content be in the /library partition (directly or be symbolic link). Earlier versions of NEXS included the netsetup.sh script on the XS drive. This had the advantage of being easier to edit (if necessary) since placing it in the XS build means a new build just to change the script. The NEXS build configured the baseboard (RJ45) port for the LAN (router with network 172.18.0.) and the second port (usb-ethernet) to connect to an XO by cross-over patch for SSH admin. The netsetup.sh script was needed only when the schoolserver was to be connected to a WAN (internet) and re-configured the second port accordingly. So my next wish on the wishlist is that it be separated into an XS and XC component. Some minor additions on my wishlist: 1. Try to make the XS install 'headless'. This should be possible if the server firmware supports configuring a boot from the usb drive ahead of the hard drive. It requires the XS-Au fix to the 'race' condition in Kickstart. Currently, a support technician (in principle) needs to carry an lcd monitor and usb keyboard to a school to be able to deal with server problems. If the XS install could be done without a reformat to /library (and all of the content were there), it would be possible to re-install XS and, if ssh were then working, deal with the problem. 2. Try to fix the mkusbinstall script so that it works with a 'store-bought' usb drive - setting up the partition, label, boot flag. 3. Provide a generic install script from usbmount so that the XC install scripts can be on the XC drive. Again, this makes it possible for a deployment to reconfigure XC without rebuilding or updating XS. For example, the XC drive could have a root folder IXC (install XC). If usbmount finds this folder, it invokes a script /media/usb0/IXC/xcInstall.sh (for example). This way, an XC drive could have other files (e.g. development folders with install scripts) and be mounted without reinstalling XC itself (Just mv IXC to XC, for example, would cause usbmount to not see it as an XC disk). Tony On 06/02/2011 10:29 AM, Sridhar Dhanapalan wrote: On 28 May 2011 08:31, Aleksey Limalsr...@activitycentral.org wrote: On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote: On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Thank you! Forwarding this to the Dextrose list as well. I've also CCed guys who do XS work in .au Abhishek: thanks for sharing your wishlist. From my side, I see the whole picture in case of school server like having: * sugar-server[1], the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so) * any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace[2]). * final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs. We are looking to make our XS-AU[0] more modular to suit different use cases. Our initial goal (completed over a year ago) was to make it work on a single interface to integrate well into existing networks. Installation is via USB and fully scriptable via kickstart files. The current XS is very monolithic and bureaucratic. It requires moderate sysadmin skills to install and maintain. Maintaining the presence service is cumbersome and impractical in our schools. The turnover of teachers and
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 2, 2011 at 5:20 AM, Aleksey Lim alsr...@activitycentral.org wrote: btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Have you spent any time learning how to configure ejabberd? Diagnosing your problem? Discussing it on the ejabberd mailing list? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 02, 2011 at 11:42:52AM -0400, Martin Langhoff wrote: On Thu, Jun 2, 2011 at 5:20 AM, Aleksey Lim alsr...@activitycentral.org wrote: btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Have you spent any time learning how to configure ejabberd? Diagnosing your problem? Discussing it on the ejabberd mailing list? Well, I assume OLPC people did it many times before me, I just reused their experience tryinhg to follow wiki.l.o docs and using native packages from fedora. My plan is trying to figure out why 0.92 doesn't work w/ Prosody and run it on jabber.sl.o to see how much resources it will take in comparing w/ ejabberd. -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 2, 2011 at 11:56 AM, Aleksey Lim alsr...@activitycentral.org wrote: Have you spent any time learning how to configure ejabberd? Diagnosing your problem? Discussing it on the ejabberd mailing list? Well, I assume OLPC people did it many times before me, I just reused their experience tryinhg to follow wiki.l.o docs and using native packages from fedora. Yes -- everytime we saw a perf problem we diagnosed. Right now we don't see performance problems when load testing the XS. If you see perf problems in your specific setup, I can only suggest you diagnose -- perhaps with the help from the ejabberd developers via their mailing list. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, 2011-06-02 at 09:20 +, Aleksey Lim wrote: On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: On 28 May 2011 08:31, Aleksey Lim alsr...@activitycentral.org wrote: On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote: On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Thank you! Forwarding this to the Dextrose list as well. I've also CCed guys who do XS work in .au Abhishek: thanks for sharing your wishlist. From my side, I see the whole picture in case of school server like having: * sugar-server[1], the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so) * any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace[2]). * final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs. We are looking to make our XS-AU[0] more modular to suit different use cases. Our initial goal (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? more or less, yes. [1] sugar-server in that case is a new project w/ more tough and localized design. As long as it can offer the all the same core services as the XS, I'm game, as dextrose is where we want to go anyway. work on a single interface to integrate well into existing networks. Installation is via USB and fully scriptable via kickstart files. With the usb race fixed with a revised anaconda rpm [1] headless in now possible, you get need to tweak the kickstart files to your liking. The current XS is very monolithic and bureaucratic. It requires moderate sysadmin skills to install and maintain. Maintaining the presence service is cumbersome and impractical in our schools. The turnover of teachers and students is far too high to ensure that anything gets managed properly. We're looking to slim down the XS-AU such that we can have a simple collaboration server (which we currently call XS Lite) that is installable in a classroom as a drop-in appliance. ie, just having jabber server and somehow let students know where it is? Populating a single field in sugar control panel is trivial, OK class right click - My Settings - network - add needed info to the Server: field. click check. That can be a first day in class routine IMHO. is an ejabberd. btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Registration, Moodle, Squid, backups and so on are unnecessary. Each teacher can run their own server for their own class. Conveniently, this could easily run on an XO (XS-on-XO). in other workds there is no need in sugar specific stuff at all - just install jabber server from packages (maybe w/ sugar specific patches) and write its url on studensts' boxes. see above. As an offshoot of this you could turn this XO into an updates server quickly with the mini-server idea of mine. [3] Jerry 1. http://dev.laptop.org.au/projects/xs-au/wiki 2. http://download.laptop.org.au/XS/F11/XS-AU/bleeding/RPMS/ 3. http://dev.laptop.org.au/projects/mini-server/wiki/Using ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
