Re: dnshash update.
On Tue, 12 Apr 2011 at 18:41:05 -0400, C. Scott Ananian csc...@laptop.org wrote: On Sun, Nov 15, 2009 at 10:04 PM, Michael Stone mich...@laptop.org wrote: I recently taught dnshash to ping potential addresses before returning them as results. This isn't a great solution, but it does appear to fix the problems observed in the use of the first version of dnshash with ssh and firefox and is therefore recommended for further testing. Michael -- I'd like to get an update on your work w/ this during my mesh week next week. Could you give me a brief update on code status, results of testing, other thoughts re: mesh? Scott, Here's a review of the current status of dnshash, a brief explanation of a failed alternate design that should inform other design attempts in this area, and an explanation of how you might go about porting dnshash to Android. Also, since this email is quite long enough already, I'll respond to your request for other thoughts re: mesh on another occasion. :) Regards, Michael ## Status Review 1. [Dnshash] is currently implemented as a (e)glibc [NSS] plugin, enabled through /etc/nsswitch.conf. This approach: * is usable by programs running on Linux that use e(g)libc's getaddrinfo() to do DNS resolution. * is probably straightforward to port to other operating systems and libc implementations with extensible getaddrinfo() implementations. (For the details for Android, please see the section below entitled Dnshash on Android.) * is not applicable to programs that do their own DNS resolution. (Also, the other obvious design for these programs turns out to be unimplementable due to unsatisfiable hard constraints described in the section below entitled Alternate design: recursive resolver.) 2. As mentioned above in November 2009, it turns out to be important, due to some popular programs' use of lengthy TCP timeouts, to avoid returning addresses without some evidence that the addresses are actually contactable. The current solution (shelling out to ping6) to this problem is hackishly implemented but seems to work okay under very light testing and has the great benefit of simplicity compared to the alternate designs of doing the pinging in the plugin itself (hard due to the need for CAP_NET_RAW) or in a daemon (a complex shared resource). 3. Regarding testing: dnshash has been tested successfully a handful of times in the past 18 months in two network scenarios: a) a physical network of 2-3 laptops running a mix of current-at-the-time versions of the Debian, Fedora, and OLPC operating systems all associated with a shared 802.11(g) access point b) a logical network built on top of Linux's network namespaces (CONFIG_NET_NS), ethernet bridges (CONFIG_BRIDGE), and virtual ethernet device pairs (CONFIG_VETH) running on a current-at-the-time Debian laptop. In each network scenario, the Installation, Use, Testing, and Cleanup test procedure was performed as described in the dnshash [README]. No errors were found. Finally, the set of planned but unscheduled testing work currently includes: * finishing the incomplete automation of the setup procedure for the logical network scenario available in the `xterm.py`, `test_gai.c`, and `newnetns.c` helpers in the dnshash git repo, * extending the logical network scenario to use the `netem` (CONFIG_NET_SCH_NETEM) traffic shaper to construct reproducible simulations of the effect of various packet loss, delay, and jitter processes on dnshash performance, * testing more client software and more input sequences. [Dnshash]: http://wiki.laptop.org/go/Dnshash [NSS]: http://www.gnu.org/s/libc/manual/html_node/Name-Service-Switch.html [README]: http://dev.laptop.org/git/users/mstone/dnshash/plain/README ## Alternate design: recursive resolver The NSS-plugin approach that I wound up implementing was always intended to be a quick hack on the way to a real implementation in the form of a modified local recursive resolver (probably based on djbdns' dnscache). Unfortunately, this backup plan is impossible because the design space is overconstrained as follows: 1. IPv6 has only one link-local prefix, fe80::, for all interfaces. 2. A single link-local address (e.g., fe80::3) may be bound to arbitrarily many interfaces so long as it is bound to at most one interface per link. 3. As a result of (1) and (2), link-local addresses are ambiguous: they don't, by themselves, give an IP stack with multiple interfaces enough information to figure out which interface to use to emit packets whose destination address is link-local. 4. Problem (3) was fixed in October 1998
Re: Mesh Potatos and OLPCs?
On Wed, 23 Mar 2011 at 20:47:44 -0400, Ed McNierney e...@laptop.org wrote: While I am not familiar with the Mesh Potato, I have spent some time trying to figure out whether wireless mesh networking is really as hard as the OLPC universe seems to find that it is. tl;dr: Mesh Potatoes might make decent APs for XOs but physical- and 802.11-level constraints will probably prevent them from succeeding in the densely packed, radio-congested classroom environments where the XO-1's draft-802.11(s) implementation presently fails. See below for the gory details. I have come to believe that both wired and wireless mesh networks are really doing pretty well out there in the world, *provided* the nodes are immobile, or relatively so. The keys to success seem to be unicast, immobile, sparse, proactively routed, carefully sited, actively managed, and better antennas. The examples you point to seem to fall into the immobile wireless category, and I think one is likely to find reasonable success in that field. And I don't mean *really* immobile, but rather don't move about very much. The wireless multi-room music systems from Sonos, for example, seem to use wireless mesh pretty successfully, but the nodes are pretty stable. And they don't get very dense (you don't put 30 sets of stereo speakers in one room). I have not found any examples of either (a) dense wireless mesh or (b) highly mobile wireless mesh. In case (a) I assume that is normally not a problem, so it's not being solved. In case (b) one encounters the classic OLPC mesh problem - 50 laptops scattered about in children's homes at night all want to act as mesh nodes, while those same 50 laptops all go into the same classroom the next day where they DON'T want to all act as mesh nodes (i.e. they create case (a)). I don't know of anyone who has successfully solved that problem, other than by the less-than-satisfactory route of giving the users a switch and expecting them to turn mesh on and off as they move. So I believe many people are having successes with relatively static wireless mesh networks, but I also believe that no one is having success in the scenario OLPC has always wanted to support. If my latter perception is wrong I would love to know of a counterexample (using any hardware, not just XO laptops). --8-- (the gory details) --8-- Here's what I've learned in the last two years, divided into three sorts of key points, about why this problem is actually hard: a) the media access control algorithm implemented in the XO-1 mesh is a jazzed-up version of the 802.11 Distributed Coordination Function (DCF) [1] b) the 802.11 DCF was analyzed [2] from first principles, with simulations, and with physical measurements at MIT in 2001 b) this choice of MAC algorithm, independent of /all/ higher-level protocol considerations, governs the fundamental behavior of the network, and c) the from-first-principles results, the simulations, and the experimental measurements cited all agree that per-node capacity: 1) is bounded above by O(n^-0.5) (with annoyingly small constants) 2) is inversely proportional to node density 3) is highly sensitive to network congestion These physical constraints are exacerbated by three sources of broadcast: i) layer 2 route selection, where routes expired every ~5-15 seconds to cope with a rapidly changing radio environment ii) DHCP broadcast, (and in other designs, IPv6 router advertisements, and IPv6 duplicate address detection) iii) flood-fill broadcast implementations of IP-level multicast, which was primarily used by mDNS and Salut and by two differences between ad-hoc broadcast and infrastructure unicast, which are that iv) broadcasts must be sent at a Supported Basic Rate [e.g., of 1 Mbps] instead of at the full Transmit Rate [e.g., 54 Mbps], and v) broadcasts are not acked, which forces higher-level protocol retransmit timers to fire more often, thereby triggering more broadcasts. Together, these facts appear to me to be sufficient to explain why the OLPC XO-1's draft 802.11(s) implementation exhibits the behavior we've all observed: i.e., tantalizing possibilities in lab experiments with small numbers of nodes in quiet radio environments and congestion collapse in school-like settings. Regards, Michael [1]: http://standards.ieee.org/getieee802/download/802.11-2007.pdf [2]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.6218 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 14 released
On Sun, 20 Mar 2011 at 18:46:12 +, Daniel Drake d...@laptop.org wrote:
On 20 March 2011 18:05, C. Scott Ananian csc...@laptop.org wrote:
so fakeroot (at least debian/unstable's version of fakeroot) should be
able to handle this just fine.
You're right, this should work.
But it doesn't, even with fakeroot 1.14.5.
Test case:
As root:
mkdir test
echo closed test/closed
chmod 000 test/closed
tar -cf test.tar test
rm -rf test
As user:
fakeroot
tar -xpf test.tar
ls -l test/closed
cat test/closed
Last command gives error.
Now exit from the fakeroot and:
ls -l test/closed
The 000 permissions somehow fell through onto the real filesystem, but
in your more simplistic testcase the 000 permissions stayed only
within the fake environment of fakeroot.
So..tar must be doing something different from chmod when applying
permissions.
A quick strace with fakeroot-1.14.5-2 and tar-1.25-3 on Debian Squeeze suggests
that tar is running something like:
umask(022) = 0
umask(0)= 022
mkdirat(AT_FDCWD, test, 0700) = 0
newfstatat(AT_FDCWD, test, {st_mode=S_IFDIR|0700, st_size=4096, ...}, 0) = 0
openat(AT_FDCWD, test/closed,
O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0) = 4
write(4, closed\n, 7) = 7
dup2(4, 4) = 4
fstat(4, {st_mode=S_IFREG, st_size=7, ...}) = 0
utimensat(4, NULL, {{1300653754, 616972565}, {1300653712, 0}}, 0) = 0
fstat(4, {st_mode=S_IFREG, st_size=7, ...}) = 0
fchown(4, 0, 0) = -1 EPERM (Operation not permitted)
close(4)= 0
...and, sure enough, we have a bug [1] entitled fakeroot: handle openat() and
friends.
Regards,
Michael
[1]: http://bugs.debian.org/402688
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Content-Centric Networking.
On Fri, 18 Feb 2011 at 11:00:52 -0500, C. Scott Ananian csc...@cscott.net wrote: Recapping for the list: Jim Gettys sent me a pair of papers to read yesterday, both linked from http://www.ccnx.org/content/content-centric-networking-resources 1) V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard (PARC) Networking Named Content, CoNEXT 2009, Rome, December, 2009. 2) V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, J. D. Thornton, R. L. Braynard, VoCCN: Voice Over Content-Centric Networks, ReArch '09, Rome, December, 2009. This is very interesting work, and offers an alternative to http://wiki.laptop.org/go/Network_principles In my mind, the best reason to continue to use DNS and IP routing to locate resources (as in the Network Principles document) is that deployments understand them. In my mind, a stronger reason for sticking with XMPP, HTTP, DNS, and IP is that XMPP, HTTP, DNS, and IP are standardized technologies with multiple interoperating free implementations. CCNx seems unlikely to reach this level of maturity in the near future (e.g., the next three years). On the other hand, if you're thinking about the problem further out than the near future, then I have more interest in the suggestion. However, the CCNx approach could offer significant bandwidth benefits, and potentially works better in the kids go home from school case (the Network Principles document requires IPv6 tunnels to solve this mobility problem). CCNx-over-ethernet will likely require ISPs to install new routers, no? And won't CCNx-over-IP will have the same mobility problem that your Network Principles were designed to solve? I think the CCNx ideas would be worth exploring, but OLPC would need active participation from the PARC CCNx folks. OLPC role would be integrator/deployer, *not* developer or researcher. So, with that in mind, the greatest missing piece I see is an HTTP gateway. Agreed. Here's how it would work: CCNx content bundles with a specially-formed name (like http/url/here) would get routed by specially-aware content routers over legacy HTTP. The contents, once fetched, would be stored in the CCNx network like all other content, making it a big web cache. Running such a CCNx gateway on the school server would turn it into the web cache we've always dreamed of (and which perhaps has been implemented in the past two years?). Why will a CCNx cache be more effective than a plain old HTTP cache? (i.e., aren't the constraints on memory usage, disk usage, and network bandwidth going to be fairly similar?) This would let all of the laptops talk pure CCNx to each other, This seems too strong. Perhaps you mean that This is one small but important node on the critical path to a functioning laptop-borne CCNx network that preserves web access. ? without losing web access, and make the web behave better when machines are disconnected. For bonus points, the CCNx routers would use something like rproxy ( http://rproxy.samba.org/doc/protocol/protocol.html) when searching for content from other CCNx routers, so that slightly changing content such as is found more typically on the web is still highly cacheable, and we get even more bandwidth improvement. This suggestion is worth forwarding to ccnx-...@ccnx.org -- I would be interested to hear their reaction. Both rproxy and the HTTP gateway are development projects; they're probably even research projects, since it's not immediately clear how HTTP's caching semantics (which need to be honored) translate into the CCNx namespace. I don't think it's a good idea for OLPC to do research projects, but if Van and his team are enthusiastic about collaboration, I'd hope that OLPC would be willing to integrate and deploy his ideas. The win for OLPC would be network bandwidth, which is a huge deal for the developing world; with solutions to some resource discoverability issues a secondary consideration. There's also the issue of the communications security story for CCNx. (To their credit, the CCNx folks have clearly indicated that this story is unfinished.) Note that the two papers I've read so far don't really address the resource discovery and naming issue. They make some suggestive remarks, such as We are also developing higher level name discovery mechanisms that are more efficient for exploring large name spaces (Networking Named Content, page 4). That's another area of concern for me. As we learned the hard way, just finding your friends and classmates in a large school can be a surprisingly difficult problem, and CCNx's reliance on multicast with a casual reference to standard multicast suppression techniques (Networking Named Content, page 3) causes me concern. But I'm sure OLPC would be more than willing to provide the test cases if they are interesting in proving that their name-discovery stuff actually works in the
Re: Help with signing messages
On Thu, 3 Feb 2011 at 15:02:21 -0200, Esteban Bordon ebor...@plan.ceibal.edu.uy wrote: 2011/1/29 Michael Stone mich...@laptop.org On Fri, 28 Jan 2011 at 14:40:54 -0200 Esteban Bordon wrote: I trying to make a notification system that reads messages from sqlite3 database and show them via dbus notifications. I want to store a hash of the message inside the db to verify each message before show it, but I don't know how I do it. I think sign the message using sig01 of bios-crypto but I don't know how I can verify this hash. Can I use some mfg-data tag to verify it (msg signed with masterkey appropiate)? Which command I have to use? Can you please say a bit more about the system you're building? (The choice of the right command almost certainly depends on some further details about your goals.) Hi Esteban, Thanks for the detailed responses and apologies for my delay in replying to you. In particular: * what does a typical message say? Institutional or relevant messages about XO and children. For example, New OS version is released or Your laptop will be blocked tomorrow, please update your blacklist * how are messages transmitted? Laptop download a XML from their school server with the messages. * are the messages addressed to one, many, or all possible recipients? (unicast, multicast, broadcast) All laptops should receive the same messages I'm confused here because, above, you said that a typical message might be Your laptop will be blocked tomorrow, please update your blacklist. Is this kind of message supposed to be: * received and displayed by all laptops? * received by all laptops and displayed by one or more addressed laptops? * received and displayed only by addressed laptops? * are the notifications one-way or will there be replies? one-way, for now. * are the messages solely intended for humans to read or are they also machine readable? This application is only for humans. * do you care if other people read the messages in transit? (secrecy) No matter, messages can be puclic. * do you care if the messages are modified in transit? (integrity) Yes. It's one reason for I want sign the messages. * is the recipient supposed to know who sent a message? (agreement on sender identity) Only school server should to send messages * is the sender supposed to know who received a message? (agreement on receiver identity) This feature isn't already implemented * do you care if a message is never delivered? (availability / reliability) If XO connect to server should get the XML. I don't think it as independent messages, all messages are into XML * do you care if a message is delivered multiple times? (replay) No, laptop application delete duplicate messages * do you care if messages are reordered in transit? (ordering) No. the application stores the messages into db file. * do you have other security goals not mentioned above? (availability, resource usage limits, non-repudiation, privacy...) Regards, Michael Regards, Esteban. Okay. Based on what you've told me here, I see three approaches that seem like they might do what you want at reasonable cost: a) Online signing w/ HTTPS: If you trust your school servers and your school-server technicians to keep secrets, then you can meet your goals with something like: curl --cacert ... https://my.school.server/messages.xml; The point is to 1) open an HTTPS connection to your school-server, 2) verify the cert-chain that you receive against a previously distributed CA cert that you issued, and, 3) download your XML over this authenticated, integrity-preserving connection b) Offline signing w/ OpenSSL: If you really want to do offline signatures, for example, because you don't trust your school server to keep secrets, then the OpenSSL command line tools like openssl rsautl can probably help. c) Offline signing w/ bios-crypto If you want to do offline signatures with the same crypto tools used for OFW and build signatures, then bios-crypto's cli_tool http://dev.laptop.org/git/bios-crypto/tree/cli.README may be what you want. Do any of these approaches look like they might work for you? Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with signing messages
On Fri, 28 Jan 2011 at 14:40:54 -0200 Esteban Bordon wrote: I trying to make a notification system that reads messages from sqlite3 database and show them via dbus notifications. I want to store a hash of the message inside the db to verify each message before show it, but I don't know how I do it. I think sign the message using sig01 of bios-crypto but I don't know how I can verify this hash. Can I use some mfg-data tag to verify it (msg signed with masterkey appropiate)? Which command I have to use? Can you please say a bit more about the system you're building? (The choice of the right command almost certainly depends on some further details about your goals.) In particular: * what does a typical message say? * how are messages transmitted? * are the messages addressed to one, many, or all possible recipients? (unicast, multicast, broadcast) * are the notifications one-way or will there be replies? * are the messages solely intended for humans to read or are they also machine readable? * do you care if other people read the messages in transit? (secrecy) * do you care if the messages are modified in transit? (integrity) * is the recipient supposed to know who sent a message? (agreement on sender identity) * is the sender supposed to know who received a message? (agreement on receiver identity) * do you care if a message is never delivered? (availability / reliability) * do you care if a message is delivered multiple times? (replay) * do you care if messages are reordered in transit? (ordering) * do you have other security goals not mentioned above? (availability, resource usage limits, non-repudiation, privacy...) Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Memory leak in Sugar -- how to dump Py data
See http://dev.laptop.org/ticket/10386 for details. The sugar-session process in 10.1.2 grows slowly... There's some form of leak somewhere. Maybe we are triggerin a real python leak, maybe we have reference loops. How do we trace this? Tomeu wrote some instructions here: http://wiki.laptop.org/go/Memory_leak_testing http://wiki.sugarlabs.org/go/Development_Team/Memory/Leak_testing (mirror) that might be of use to you. Also, it looks like guppy is now available directly from Fedora, packaged under the name python-guppy. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-update and deletion of old images
Dan, First and foremost, your approach seems reasonable to me. Second, here are some more detailed background comments: When olpc-update updates you from version A to version B, version A remains on the system and can be accessed by booting with the 'O' game key held down. As far as I know, this functionality is rarely used, The functionality is now rarely used because olpc-update is not used as frequently as it used to be and because the OS image testing process is working well enough that the fail-safe functionality has not been required at scale. Both of these, combined with the costs you mention, seem to me to be fine reasons for retiring the feature, so long as you think that they will continue to hold true for the foreseeable future. and has inherent problems. Specifically it requires Sugar developers to be able to predict the future. For example, if the datastore changes in a newer sugar version, the new sugar version will boot and convert the datastore to the new format. But if you then boot the old OS version, you won't see anything in your journal, since the old sugar doesn't support the new datastore format. (similar problems could occur in other parts of the system) These issues were thought to be acceptable when we thought the failsafe functionality was important and when OLPC and its partners were prepared to help Sugar develop in both backward- and forward-compatible ways. They are obviously less acceptable now. (Also, for what it's worth, we had a couple of plans on the back-burner for filing down the sharp edges here. As I recall, they included: a) introducing a plugin system for olpc-configure so that olpc-configure in the *new* build could inspect what old builds were available and could install best-effort downgrade scripts as needed. b) alternately, using one of the CoW filesystem primitives we were experimenting with to snapshot /home as well as the OS.) It also brings in more headaches. While the updates are somewhat efficient (files that do not change between 2 versions are only stored on disk once), there is always a space overhead in having 2 versions of the system on disk. And during big updates (e.g. F9 to F11), almost every file changes, meaning that little disk space is left after doing the update. Life sometimes requires compromises. Maybe you want to take a backup and to reflash your system partition instead? (Or to spend for a bigger disk?) There is no UI to delete the 2nd stored version, the only way to do it at the moment is from the Terminal (not suitable for deployments). True enough. As a matter of idle speculation, what sort of UI would be suitable for deployments? My proposal is to modify the initramfs, removing the code that supports alternate boot (O game-key). And if it encounters an old version stored on disk, it will delete it during the boot process. Having 2 copies remains an integral part of the olpc-update process, but the old version would be deleted as soon as its not needed. Makes sense to me. Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Fwd: Redesigning: Library, Read, Get-Books, and Content bundles
Gary, Yioryos, Here are a couple of thoughts for you on isolation issues. (I have thoughts on the Journal issues too but I'll save them for another occasion.) Step 3 is to introduce marks (hyperlinks?) in Read and Write where hovering over you get the tag opened to tell you what is about, and clicking transposes you to the relevant book/app-mark As noted already this would seem to break Sugars's security model, activities need to be sand-boxed from each other, one activity is not allowed to resume another. Yea, back to Journal, again! ;) Let's think about this a bit more deeply. As I see it: The key idea that Bitfrost offers is that system software needs to make it easy for the authors of benign apps to protect human interests. (A number of useful features are then proposed toward this end.) The key idea that Rainbow offers is that accounts are a good device for isolating processes. Within this problem domain, the key idea of Sugar is that people engage in fairly discrete sessions of activity which may be started, stopped, resumed, and isolated from one another. Significant isolation is possible because data rarely needs to move from session to another and, when it does, the motion may be orchestrated through a supervisor. Note, however, that the idea is that it doesn't matter much what actual processes run within a given session or whether there are many windows or one, many documents or none, many hosts contacted or none, etc. Indeed, we shouldn't worry so much about whether Browse invokes Read in order to render a downloaded PDF or whether Chat invokes Browse when the human operator clicks on a hyperlink -- Browse already had complete control over the contents and distribution of the PDF and Chat already had complete control over the text of the URI that Browse will see. Instead, what does matter is the ability to control what happens *when* Browse or Chat or Read becomes circumstantially malicious. What matters then is the ability of the human operator and the system supporting them to manage the mappings of I/O resources to sessions -- that is, crudely, of the start new vs. resume problem. :) Thoughts? Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
Aleksey wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software... rainbow should be more then essential requirement. Let's be clear: the actual requirement is for something more like safety or isolation. Rainbow is merely one of several reasonable approaches -- and competition and interoperability would be no bad thing here. Michael P.S. - Several other isolation shells that might be worth thinking about, if only to better understand the tradeoffs that rainbow makes, are briefly described at http://sandboxing.org P.P.S. - Also, either way, thanks for your encouragement. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Gnome vs Sugar -- The judgement day
Teachers demand a technological mean to solve a problem of discipline and computer literacy. Launch GNOME under a separate account with a quota and with limited or no sudo access. This will cut out most of the mayhem, thereby buying you time to work out a more integrated solution. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
Bert Freudenberg wrote: On 18.04.2010, at 14:10, Sascha Silbe wrote: On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote: Rainbow changes UID for every invocation [...] Yes, that's the default behaviour. Rainbow can be instructed to use a constant UID (Browse does); according to the OLPC wiki [1] you'd need to add a file activity/permissions.info, containing constant-uid on a single line. This is the least preferable solution, though. Apparently the create mask rainbow uses is 755 and group members do not have write access. It's not Rainbow that decides this. But arguably Rainbow could set a better default, no? Making files group-writable? Rainbow actually calls os.umask(0) here: http://dev.laptop.org/git/security/tree/rainbow/rainbow/inject.py#n263 However, it's entirely possible that some other logic in your program is setting umask(022) or is creating files with an explicitly specified mode. (You may recall that xulrunner's behavior here was the reason why constant-uid was introduced.) Hmm, how do I test if Rainbow is enabled, in a shell script, again? If you mean is sugar going to launch the next activity it launches under rainbow?, then test for the presence of /etc/olpc-security, e.g. with if [ -f /etc/olpc-security ]; then ... fi If you mean is my script currently running under rainbow?, then I don't have a perfect answer for you this instant. (A good but imperfect answer is to test whether whether getuid() 1 and getgid() 1, e.g. by parsing the output of the id command.) Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
George Hunt wrote: I had looked for an input mechanism to Rainbow's CONSTANT_RAINBOW_UID without success. So thanks for your pointer. Where did you look? (I'd like to go fix it...) I'm curious to know why you think using a constant UID is undesireable. Making things constant-uid in the sugar-0.82 + rainbow-0.7.* world removes all isolation between instances of the activity. At this point I'm looking for ways to simplify the next stages of debugging my program. My thinking is as follows: If I can get permissions off the table as a source of failure, while I deal with all the other problems I haven't foreseen, I can come back and tighten up security when my code is more solid. Your reasoning seems fine to me. (One word of caution, though: rainbow will probably not respond well to seeing a single activity bundle_id switch between the constant-uid and the (default) fresh-uid setting. Therefore, you should either use a fresh bundle_id when you switch or you should clean out rainbow's filesystem state in /etc/passwd, /etc/group, and /home/olpc/isolation/1/.) Regards, Michael P.S. - I really like ipython, so I'm excited to see your activity. Also, if you like ipython, check out bpython. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
Does the XO-1 host its own development tools? For all practical purposes, it does not. First, as you have noted, it takes quite a bit of bandwidth to install the toolchain and development headers. (And you have to know what they're called.) Second, to get anything done with C, you really need easy access to the man pages and you need to know quite a bit about how the system is put together. Third, you quickly run out of disk space when you try to compile things locally. I actually got as far as linking vmlinux before I ran out of space on my on-XO kernel compile. (Nevermind how long it took to get that far with no swap space! :) I don't think anyone has ever rebuilt the system from source code on an XO-1. I don't even know anyone outside the OLPC office who *has* the source code for an XO-1 software release. The source is available from Fedora CVS and from mock.laptop.org. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ANN: rainbow-0.8.6 release.
Friends, I am pleased to announce the release of rainbow-0.8.6. Rainbow implements portions of the isolation shell described in the Bitfrost threat model and security architecture. The key differences between this release and its predecessor include support for garbage collection of uids, ui sugar for resuming uids, bug fixes to the resume logic, and a simplified singly-linked list library. This release was made possible by encouragement and suggestions from Sascha Silbe, Bernie Innocenti, and Benjamin Mako Hill. It has been (minimally) tested on Debian Sid, Ubuntu Karmic, and Fedora Rawhide and has been packaged in Fedora Rawhide for your convenience. Interesting links for this release include: git:git://dev.laptop.org/users/mstone/security tar: http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.6.tar.bz2 browse: http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.6 setup: http://wiki.laptop.org/go/Rainbow/Installation_Instructions tests: http://wiki.laptop.org/go/Rainbow/Testing The shortlog from rainbow-0.8.5..rainbow-0.8.6 is: Bernie Innocenti (1): Capture XAUTHORITY. Michael Stone (19): Remove unused flexibility from the spool option parsing code. First pass at updated rainbow-gc. Clean up group membership. Protect sticky uids from garbage collection. Clean up some per-uid Xephyr data. Improve spool detection checks. Install rainbow-gc. Add some logging to rainbow-gc. Make xephyr usage resumable. Teach rainbow to resume uids with more auxiliary groups. Add a simple resume subcommand. Add INIT() and COPY() operators from dnshash. Add a novel singly-linked list implementation. Add test_endgrent script. Simplify list traversal logic. Fix Karmic sudo segfault. Tweak warnings and link flags. Set default spool location in rainbow-gc. rainbow-0.8.6. Kind regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ANN: rainbow-0.8.5 release.
Friends,
I am pleased to announce the release of rainbow-0.8.5. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.
The key differences between this release and its predecessor are bug fixes,
preliminary support for network isolation, and a better rainbow-sugarize
plugin.
This release was made possible by encouragement from Fabian Affolter, Luke
Faraone, Martin Langhoff, and my friends at sandboxing.org.
Interesting links for this release include:
git:git://dev.laptop.org/users/mstone/security
tar:http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.5.tar.bz2
browse:
http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.5
setup: http://wiki.laptop.org/go/Rainbow/Installation_Instructions
tests: http://wiki.laptop.org/go/Rainbow/Testing
The shortlog from rainbow-0.8.4..rainbow-0.8.5 is:
Michael Stone (10):
Correct a logging statement.
Make rainbow-sugarize set up /{data,instance,tmp}.
Temporarily disable $XAUTHORITY processing in rainbow-sugarize.
Drop config file management from rainbow-sugarize.
Add a network option enabling unshare(CLONE_NEWNET).
Make nss-rainbow's return and error codes more accurate.
Correctly calculate number of members of a struct group.
Make getpwent() resume on the correct uid.
Grant network access to rainbow-easy programs.
rainbow-0.8.5.
Finally, please note that:
* rainbow-run now calls unshare(CLONE_NEWNET) unless the -o network
command-line argument is given. This argument is given by the
rainbow-easy helper since X11 clients are unable start without it.
* rainbow's nss module must still be activated in /etc/nsswitch.conf in order
for the software to function correctly. See the setup instructions linked
to above for details.
Kind regards,
Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
DNS Mischief, cont'd: dnshash-0.3.0 released!
Friends, I am pleased to announce the release of dnshash-0.3.0. dnshash implements the hash-based DNS resolver described in Scott's Network Principles document. The key features of this release are better testing and more reliable results. * Better testing was accomplished via the network containerization features of recent kernels. * More reliable results are achieved by returning only live addresses: i.e., those which successfully respond to a ping within one second. Many thanks to Bernie Innocenti for his patches, to Cortland Setlow and Andres Salomon for assistance with testing, and to Aurelian Jarno for his prompt assistance with (e)glibc bugs. Interesting links for this release include: git:git://dev.laptop.org/users/mstone/dnshash browse: http://dev.laptop.org/git/users/mstone/dnshash/tree/?id=dnshash-0.3.0 readme: http://dev.laptop.org/git/users/mstone/dnshash/tree/README tests: http://dev.laptop.org/git/users/mstone/dnshash/tree/docs/unit_testing.txt bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557596 env:http://wiki.laptop.org/go/Network2 The shortlog from dnshash-0.2.0..dnshash-0.3.0 is: Bernie Innocenti (2): Eat up extra space in nsswitch.conf on 'make disable'. Make redirection work in /bin/sh; fix lint. Michael Stone (8): Only return live addresses as results. Add newnetns subcommand to ease testing. Teach dnshash to answer AF_INET6 queries. Add a manual unit-test script based on network namespaces. Teach dnshash to specify the proper prefix for addresses it suggests adding. Tuck in modprobe instructions, just in case. Add maintainer script. dnshash-0.3.0. Kind regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
versioned partitioned upgrading: safety boot configuration
Hi Dan, I'm working on updating olpc-update and the initramfs to be able to work with a partitioned layout where /boot is separate from the rest of the system. Thanks for the good documentation at http://wiki.laptop.org/go/Early_boot You're welcome; apologies that it isn't better. :) First one, I'm implementing the Create a safety boot configuration bit. I guess the purpose of this is to ensure that the current running OS is marked as current, and to free up the other OS image (so that it can be deleted soon after to make space for the incoming update). Correct. So onto the bit I have to add: (If partitioned: Make /boot/alt point to ../$a.) I don't understand this part. Surely the instructions for /boot would be equivalent to what was done above, i.e. on the boot partition: 1. make sure that /boot points at boot-versions/$a 2. remove /boot/alt First, understand that Scott+Mitch wrote the logic for updates with partitions. I am only a secondary source for this scenario. The primary source is the pre-formatted version of the upgrade procedure, which may be found here: http://wiki.laptop.org/index.php?title=Early_bootoldid=77286#Upgrade_procedure Second, unfortunately, the instructions as written are *not* equivalent: Mitch and Scott decided to simplify the partitioned design by insisting that a) boot:/boot be a symlink pointing to 'boot-versions/XXX' b) boot:/boot/alt be a symlink pointing to '../YYY'. Or have I just answered my own question through writing this mail? Step 1 is deemed unnecessary (we can assume that it's already pointing to the right place), and your instructions are simply making the alternate boot configuration point to exactly the same one that is booted (hence there is no longer an alternative) I concur with this answer to your question. Regards, Michael P.S. - Tit for tat: how is the correct root partition identified and communicated from ??? - OFW - initramfs - ??? - updater - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
versioned partitioned upgrading: clean up / config creation
Last question for now: http://wiki.laptop.org/go/Early_boot#Clean_Up This part of the page seems to suggest that you only create a /versions/configs entry for systems where an unpartitioned layout is being used, and no config would be created for a partitioned layout. Am I reading that right? I'm having a bit of trouble getting my head around the whole system and perhaps I'm missing something obvious .. Perhaps you designed it so that boot configs in /versions/configs are not necessary when we are booting from a partitioned system, because the current and alt image hashes can be deduced from the symlinks on the boot partition at /boot and /boot/alt ? Thanks, Daniel The configs mechanism is only used for unpartitioned systems. The linkage from boot data to tree-ids is, as you say, recorded in the boot:/boot and boot:/boot/alt symlinks. I don't think the current writeup says where the contents manifests should be stored on partitioned systems. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO automatic clock setting
2009/8/27 Martin Langhoff mar...@laptop.org: 4. sig02 leases are still unsupported in the latest OpenFirmware, but it looks like we have renewed interest in getting this finished off, so no initramfs changes will be needed in this area. Here Daniel skips the fact that there is a homely but IMO valid patch that -- when OFW tells us activate -- rechecks the filesystem for a valid lease before trying to activate. This is a good thing if we assume that the initramfs can evolve faster than OFW, =A0and the case OFW doesn't recognise this sig format but Initramfs does is a valid one. Except, unless I missed something in the last discussion, we don't fully understand why the system was ever designed like this. So I'm making the assumption that there is something important that we aren't understanding. Here is my recollection of the design thinking at the time: OFW knows how to examine activation leases as a common-case optimization in order to try to make booting faster. When OFW doesn't understand or can't find a lease, it should hand the lease to the (authenicated) initramfs, which is the last authority on whether or not to hand control to userland. We picked the initramfs as the site of this authority for three reasons: 1. because people who can update OFW are scarcer and more frequently on other critical paths than people who can update an initramfs 2. because we have a working limited rollback feature for the kernel+initramfs already implemented in the firmware 3. because it seemed easier to Scott at the time to deal with communications with the environment from Linux than from OFW Regards, and keep up the good work, Michael P.S. - I will try to make time to assist you with a more serious review per your earlier request. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] erasing the journal and config
Luke Faraone wrote: James Cameron qu...@laptop.org wrote: I've tested this method only on unlocked laptops. For locked laptops some similar method might be used. For locked laptops you would *need* to get a developer key, or have OLPC sign the file. The latter won't happen. OFW's recently-added multi-key support: http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support has been used by several deployments (including Uruguay and Paraguay) who might be interested in producing a wipe power. A scheme similar to the activation lease generation scheme could also be used to rate-limit how quickly such a power could be invoked. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DNS Mischief
On Sun, Jul 5, 2009 at 8:36 PM, Michael Stonemich...@laptop.org wrote: d) rewrite as an NSS module? This turned out to be only a few minutes' work and the result is really easy to compile and install. See http://dev.laptop.org/git/users/mstone/dnshash/tree/README http://dev.laptop.org/git/users/mstone/dnshash http://wiki.laptop.org/go/Dnshash and the accompanying helper scripts dnshash_attach -- add addresses for `hostname --fqdn` to your interfaces dnshash_detach -- remove said addresses dnshash_lookup -- a thin wrapper around getaddrinfo(); eases testing Enjoy, and please test, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: FIltering out languages via kickstart
Sayamindu, I like your answer but I think that it leaves some important goals unstated -- most notably, click2trans, horizontal distribution of translations, and translation undo. See http://cscott.net/Publications/OLPC/fudcon-i18n.pdf and http://lists.laptop.org/pipermail/devel/2008-June/015838.html for the writeups and http://dev.laptop.org/git/users/cscott/click2trans for the prototype code. Thoughts? Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DNS Mischief
On Sun, Jul 5, 2009 at 8:36 PM, Michael Stonemich...@laptop.org wrote: d) rewrite as an NSS module? e) rewrite in an external DNS resolver? Either of these would make it much easier to play with your patch, eliminating the whole now recompile your C library from scratch step. ;-) Pff. It got us this far. :) (d) would be the cleanest, and the code involved ought to be quite short. With (e) you could make the names available to other machines our your local network, which could be cute (or awful, as you like). The real advantage of (e) is that you can make it work on many platforms. The problem with (e) is that it seems to take more than 80 lines of code. Network-disconnection issues also bear thinking about -- if you use a local IPv6 address for a local resource, can you handle its migration to the real network later as it roams off the mesh? (It might be easiest to handle this as a clean disconnect/reconnect rather than going down the mobile IP path.) I've thought a bit about this and, for the time-being, my cost/benefit analysis (and recent professional experience) argues in favor of making apps better at tolerating address changes in preference to going down the mobility road. Thanks for running with this idea, Michael! My pleasure; thanks for taking the time to reply to me. (Although wearing my security hat I'd have to caution that MD5 has been deprecated for 13 years now, and even SHA1 is not recommended for new use. Use http://www.ouah.org/ogay/sha2/ -- it's just two files to add, tomcrypt not required.) I agree that MD5 and SHA1 are deprecated as /cryptographic/ hash functions, but I don't think that we care. Here's why: Cryptographic hash functions are characterized by three notable properties: 1. preimage resistance for a fixed result R, how hard is to it to find a message M such that H(M) == R? 2. second-preimage resistance for a fixed message M, how hard is it to find M' != M such that H(M) == H(M')? 3. collision resistance how hard is it to find two distinct messages M, M' such that H(M) == H(M')? My claim is that we only care about second-preimage resistance against a random attacker (as opposed to an optimal malicious attacker). I believe that this is true because I think that second-preimage attacks by random attackers accurately model the risk that a user types in a domain name which, /by chance, rather than by malice/, happens to hash to an address that collides with an address already being provided by a different service on the network, or, equivalently, the risk that a user randomly chooses a name the hash of which collides with the hash of an already present name. (In my present view, plain DNS was never meant to handle the threats posed by malicious adversaries and it should not be relied upon to do so. Those risks are, in my view, more adequately controlled by other tools like petnames, reputation systems, PGP, SSH, and TLS.) Am I just plain wrong? (Ob code review: I think you just want to fabricate a new link-local address entry based on the hash, rather than cloning and altering the existing LL address. Link-local addresses have the prefix fe80::/64, with the lower 64 bits constructed from the first 64 bits of SHA256(hostname). I chose to clone existing addresses because I thought it was a convenient way to get the addresses' zone ids (called sin6_scope_id in the sockaddr_in6 struct) right. Have you got a better way to do this part? You also should probably make sure that the hostname you're hashing is the full canonical host name, ie cscott.skiffserv.dyndns.org. (note trailing dot) not cscott or cscott.skiffserv or some other abbreviation. Hmm. I can see why you might want that from a network principles standpoint, but I'm not sure that I'm convinced by your argument. I guess: patches welcome. :) -- The design issue that I find myself most interested in after having gotten this far is: My current design is not in any way integrated into the recursive name resolution process. This means that people who want to bind multiple names must do so by adding an address to all their interfaces/zones for each name they want to bind. On the other hand, if I made something that were integrated into the name resolution process, they could just run a nameserver for their domain and then everything else should just work. (I think.) Thoughts? Kind regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
DNS Mischief
As many of you know, I've been fascinated for some time by Scott's Network
Principles [1].
Several weeks ago, I outlined in a lightly-circulated patch how one might hack
up libc's getaddrinfo() implementation to do the DNS resolution work described
in Scott's paper.
Here is a second copy of that patch, which I have improved to the point where I
am willing to recommend it for further testing, adaptation, and exploration.
(This new version uses libcrypt's MD5 implementation in favor of pulling in
chunks of libtomcrypt and it includes the minimum knowledge of gaih_service
structs necessary to work with ssh, wget, etc.)
To build it, grab your distro's libc6 packaging, apply the patch to
sysdeps/posix/getaddrinfo.c, and make sure that you define
crypt-in-libc = yes
in an appropriate configuration file. Then build normally. Some tests for
getaddrinfo() will fail but you should wind up with a fully functional
libc.so.6 which you may install or use via LD_PRELOAD like so:
# calculate an address for sonipes
LD_PRELOAD=/path/to/libc.so.6 python -c 'import socket; print
socket.getaddrinfo(sonipes, None)'
# suppose we get fe80::b3da:e0e7:3bd7:278d%eth0
# on sonipes:
sudo ip addr add fe80::b3da:e0e7:3bd7:278d%eth0 dev eth0
# elsewhere, on another computer on the same link as sonipes
sudo env LD_PRELOAD=/path/to/libc.so.6 ping6 sonipes
LD_PRELOAD=/path/to/libc.so.6 ssh sonipes
(rsync, wget, nc6, ...)
Enjoy,
Michael
[1]: http://wiki.laptop.org/go/Network_principles
P.S. - Improvements are definitely welcome -- I found the code very satisfying
to use on a local wireless network.
a) provide a cute one-liner for assigning appropriate addresses to interfaces
based on the machine's desired hostnames
b) check the code for endian-neutrality
c) figure out how to fully build and package the result for easier testing
d) rewrite as an NSS module?
e) rewrite in an external DNS resolver?
diff -u eglibc-2.9/debian/changelog eglibc-2.9/debian/changelog
--- eglibc-2.9/debian/changelog
+++ eglibc-2.9/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.9-13.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/rules.d/build.mk: build libcrypt into libc
+ * debian/patches/any/hack-up-getaddrinfo.diff: install getaddrinfo hack.
+
+ -- Michael Stone mich...@laptop.org Sat, 04 Jul 2009 19:06:59 -0400
+
eglibc (2.9-13) unstable; urgency=low
* debian/debhelper.in/nscd.init: fix return code when querying status
diff -u eglibc-2.9/debian/rules.d/build.mk eglibc-2.9/debian/rules.d/build.mk
--- eglibc-2.9/debian/rules.d/build.mk
+++ eglibc-2.9/debian/rules.d/build.mk
@@ -52,6 +52,7 @@
rtlddir=$(call xx,rtlddir) ; if test -n $$rtlddir ; then \
echo rtlddir = $$rtlddir $(DEB_BUILDDIR)/configparms ; \
fi
+ echo crypt-in-libc = yes $(DEB_BUILDDIR)/configparms
# Prevent autoconf from running unexpectedly by setting it to false.
# Also explicitly pass CC down - this is needed to get -m64 on
diff -u eglibc-2.9/debian/patches/series eglibc-2.9/debian/patches/series
--- eglibc-2.9/debian/patches/series
+++ eglibc-2.9/debian/patches/series
@@ -210,0 +211 @@
+any/hack-up-getaddrinfo.diff
only in patch2:
unchanged:
--- eglibc-2.9.orig/debian/patches/any/hack-up-getaddrinfo.diff
+++ eglibc-2.9/debian/patches/any/hack-up-getaddrinfo.diff
@@ -0,0 +1,111 @@
+From 55208c43bbd9ce5e21b7c9b77db6526e688ce612 Mon Sep 17 00:00:00 2001
+From: Michael Stone mich...@laptop.org
+Date: Thu, 11 Jun 2009 21:04:18 -0400
+Subject: [PATCH] Hack up getaddrinfo().
+
+---
+ sysdeps/posix/getaddrinfo.c | 74 ++
+ 1 files changed, 74 insertions(+), 0 deletions(-)
+
+Index: eglibc-2.9/sysdeps/posix/getaddrinfo.c
+===
+--- eglibc-2.9.orig/sysdeps/posix/getaddrinfo.c 2009-07-04 19:14:10.0 -0400
eglibc-2.9/sysdeps/posix/getaddrinfo.c 2009-07-05 13:52:29.0 -0400
+@@ -62,6 +62,7 @@
+ #include nscd/nscd-client.h
+ #include nscd/nscd_proto.h
+ #include resolv/res_hconf.h
++#include crypt/md5.h
+
+ #ifdef HAVE_LIBIDN
+ extern int __idna_to_ascii_lz (const char *input, char **output, int flags);
+@@ -251,6 +252,81 @@
+ } \
+ }
+
++static void
++hack_dns (const char *name, const struct gaih_service *service,
++ const struct addrinfo *req, struct addrinfo **pai,
++ unsigned int *naddrs, int *ret)
++{
++ /* XXX: Service processing! MS */
++ if (name == NULL
++ || (service != NULL service-num 0)
++ || ( req-ai_family != AF_INET6
++ req-ai_family != AF_UNSPEC))
++ return;
++
++ char buf[16];
++
++ __md5_buffer(name, strlen(name), buf);
++
++ struct ifaddrs *ifaddr, *ifa;
++
++ if (getifaddrs(ifaddr) == -1)
++return; /* Should we set *ret? MS */
++
++ unsigned int old_naddrs = *naddrs;
++
++ for (ifa = ifaddr; ifa != NULL; ifa = ifa-ifa_next)
++{
++ if (ifa-ifa_addr-sa_family != AF_INET6)
++continue;
++
++ struct
Re: [Sugar-devel] Browse.xo -- preserving a downloaded filename?
Martin Langhoff wrote: On Tue, Jun 30, 2009 at 7:25 PM, Bert Freudenbergb...@freudenbergs.de wrote: What's your use case? In the normal course of operation, the XOs will work with the XS over wireless, getting their individual leases. This is a fallback rescue leases.sig . Here's a gentle suggestion on how to more quickly (but narrowly) implement this use case: why not use Pippy to write a minimal activity that downloads the leases.sig file [e.g. with urllib2, wget, or curl], tests for mounted USB sticks, prompts the user if they're missing, and that copies the leases.sig file to the USB stick? I think this might be a good way to go because * it'll be faster than figuring out how to solve file management, * it doesn't depend on anyone else making changes, and * it may be of some educational value to people who want to understand how the system actually works and how they might automate it for themselves. Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: overhead in a G1G1 environment
A bit of background about olpc-update 'pushes': @pgf: as i recall, there was/is a provision for OLPC to push (via that polling mechanism) updates to the g1g1 machines. Correct. See http://wiki.laptop.org/go/Update_streams http://wiki.laptop.org/go/User:Mstone/Commentaries/Mass_olpc-update http://wiki.laptop.org/go/Theft_deterrence_protocol for details. i don't believe it's ever been turned on, and, in my opinion, is unlikely to be. Actually, it was used, as hinted in item #9 of http://lists.laptop.org/pipermail/community-news/2008-February/98.html to help get people onto 7.1.2 (656) which fixed several hard- and soft-bricking bugs in previous releases. (See http://wiki.laptop.org/go/Release_notes/7.1.1 http://wiki.laptop.org/go/Release_notes/7.1.2 for details.) Finally, as I recall, it was not used to push 8.1.* (703) because of http://dev.laptop.org/ticket/7093 and http://dev.laptop.org/ticket/7158 and it was not used to push 8.2.* because we didn't want to drop the UI reorganization on people who hadn't asked for it. Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ANN: rainbow-0.8.4 release.
Folks,
I've put together a new rainbow release, rainbow-0.8.4,
http://wiki.laptop.org/go/Rainbow
http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.4.tar.bz2
with three tasty new features which I think you might enjoy.
New Features
1) support for reusing existing containers (uids)
(this should be particularly useful for sugar since it gives activities
persistent $HOME dirs where they may save their configuration.)
rainbow-run option: -r 10001
2) better data-sharing functionality through isolated topic dirs
(these are just groups and matching setgid group-writable directories
like movies or banking which have both owning uids and isolated uids
as their members -- think of sugar's per-bundle $SAR/data dirs)
rainbow-run option: -i movies -i banking
3) experimental support for generating nested Xephyr X servers
(mainly as a thought experiment)
rainbow-run option: -o xephyr
Quality
---
This code is NOT KNOWN TO BE CORRECT [secure]. It just passes my most primitive
smoke tests. Therefore, please try it out and send me bug reports so that it
can one day become production-quality or, if you're feeling adventurous, do
some code-review (patch-level, module-level, whatever...) or test-case
submission (automated or otherwise) yourself so that we can all laugh at my
silly mistakes now instead of crying over them in the future. (Obviously, I'd
be happy to review patches that you send to me as well.)
code: http://dev.laptop.org/git/users/mstone/security
tests: mainly the example scripts on the wiki page
Compatibility
-
This code is definitely not backwards compatible with previous APIs.
The biggest compatibility-breaking changes that I presently know about are:
a) I no longer generate $HOME/{data,instance,tmp} since there's plugin-like
functionality which can be used to do so when it's necessary and because:
* data is subsumed by the topic dirs described above.
* instance was a design mistake which is finally fixed by support for
writable persistent $HOME dirs and container reuse
* tmp was removed because I'm not sure how to implement it correctly
and because $TMPDIR, /tmp, and /var/tmp are good enough for me at the
moment.
At any rate, I /think/ that Sugar activities which now require these dirs
can be made to work without modification with a little bit of
plugin-development by me and the Sugar team; my goal at the moment is to
make sure that rainbow is generally useful and that new activities can be
written against a less-contrived API.
b) I'm sure that I've broken rainbow's options support for things like
strace, constant-uid, and serial usage. (This should be easy to fix; I
just decided that I want to ship the rest of this code sooner rather
than later.)
Regards from Santorini,
Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Rainbow, olpc-update, and olpcrd.
The main and probably most major issues outstanding are the kernel/boot process - so kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of stuff of which I have no real idea about. Updates? Peter, Your remark does not contain any specific questions so it's a little hard for me to give you a coherent update. Instead, I'll make some general remarks in the hope that they will elicit further questions. 1. As has been recently pointed out, Rainbow is not currently in use on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*). However, some have wondered whether it might make a reappearance in sugar-*-0.86. To speed this outcome, I have prepared new versions of rainbow (0.8.*) which are easy to install and test on many different platforms. See http://wiki.laptop.org/go/Rainbow for current status information. (I await further rainbow-0.8.* questions, comments, concerns, and test results with particular interest.) 2. There is little change in the state of olpcrd and olpc-update. Daniel Drake did some nice work in February to make the toolchain support OFW-hosted key overlays and, so far as I know, is happily serving Paraguay-signed leases and software updates over Paraguay's test schools' wifi network. (Dan -- could you please update http://wiki.laptop.org/go/Security with links to a description of how you've deployed these technologies?) (Peter -- Did you have some specific question about the technology or about its inclusion [or lack thereof] in Fedora?) Regards from Athens, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] adding custom dns entries on XS
On Tue, Mar 17, 2009 at 04:04:06PM -0400, Daniel Drake wrote: 2009/3/17 Martin Langhoff martin.langh...@gmail.com: It's in my plans to have a means to do what you're doing. I was wondering about  - a conf.d approach  - a pre-processor for the .in files that handles ifdef-style blocks  - whether dnsmasq or djbdns can help us here I sure hope BIND won't be with us for ever. dnsmasq can certainly help. With dnsmasq you just have to add an entry in /etc/hosts on the server, and then dnsmasq automatically picks it up. Michael says that djbdns also can do what we want, and pointed me to some documentation, but it looked a lot more complicated than dnsmasq. Here's a rough outline of how you might redirect antitheft.laptop.org with djbdns on Debian Lenny. I can't promise that it's bulletproof, but it seems to do approximately the right thing in simple testing. sudo su - apt-get install djbdns useradd -s /bin/false dnslog useradd -s /bin/false tinydns useradd -s /bin/false dnscache export YOUR_IP=... # create empty dnscache and tinydns configurations dnscache-conf dnscache dnslog /etc/dnscache tinydns-conf tinydns dnslog /etc/tinydns 127.0.0.1 # tell dnscache where to bind, when to reply, and to proxy queries for at.l.o echo $YOUR_IP /etc/dnscache/env/IP touch /etc/dnscache/root/ip/10 # answer 10.0.0.0/24 echo 127.0.0.1 /etc/dnscache/root/servers/antitheft.laptop.org # give tinydns a zone containing at.l.o cd /etc/tinydns/root ./add-ns antitheft.laptop.org $YOUR_IP ./add-host antitheft.laptop.org $YOUR_IP make # tell supervise to run our services; see also update-service on debian ln -s /etc/dnscache /etc/service ln -s /etc/tinydns /etc/service # check that we're running and bound to proper ports svstat /etc/dnscache /etc/tinydns netstat -nulp | grep ':53 ' # read logs tail -f /etc/dnscache/log/main/current cat /etc/tinydns/log/main/current | tai64nlocal | less # optional -- resolve against your local dnscache echo domain schoolserver /etc/resolv.conf echo nameserver $YOUR_IP /etc/resolv.conf Questions? Michael P.S. - Is there a wiki page where this sort of thing is supposed to go? ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] notes on scaling ejabberd for the XO's
On Sun, Mar 15, 2009 at 06:30:17PM -0400, Daniel Drake wrote: 2009/3/15 Martin Langhoff martin.langh...@gmail.com: Client code for Gadget seems to be integrated in the Telepathy new Sugar present on the SoaS images. The server side -- the proper gadget code -- isn't on any XS, and I haven't seen or tested it (lack of time :-( ) Even if I had, it's a ton of new code, a lot more adventurous than what we're doing w moodle. So short/midterm, following ejabberd+moodle is lower risk from the perspective of a deployment today. One thing I still don't understand about gadget... how does it actually solve the problem? I'm assuming the problem it solves is lack of partitioning, and the fact that the neighborhood view becomes kind of impossible after 50 users, etc. Right? Wrong. Gadget is primarily intended to reduce the bandwidth consumed by Gabble under the load generated by Sugar. So what does gadget do? Think of it as a server-side keyword search engine which you can query for lists of matching people and activities. The purported bandwidth reduction comes from sending each client only what it asks for instead of everything, which is what the shared roster hack does. Is there a new client side UI for electing groups? Who chooses, the kids or the teachers? etc. Guillaume filed https://dev.laptop.org/ticket/7711 eight months ago but the absence of comments in that ticket and the current paucity of results in http://dev.sugarlabs.org/search?q=gadget suggests to me that the Sugar folks have completely ignored the necessary UI work in favor of more pressing issues. Regards, Michael --- To understand how Gadget works, read http://wiki.laptop.org/go/XMPP_Component_Protocol and skim the contents of http://dev.laptop.org/git/projects/gadget/tree/gadget paying particular attention to the automated tests. Then, if you're feeling brave, read the Gabble source code: http://git.collabora.co.uk/?p=telepathy-gabble.git;a=tree;hb=master paying particular attention to the files whose names contain 'olpc'. ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Mon, Mar 02, 2009 at 02:08:38PM +0100, Peter Robinson wrote: The changes to sugar might be minimal but the changes to the underlying OS are not so simple. From my (which is very basic) understanding there is patches to at least the kernel, initscripts, upstart and telepathy and possibly dbus to support rainbow. Peter, You're confusing rainbow (the activity isolation component of Bitfrost) with many other components including olpc-update, olpcrd, OFW, and hardware support. Please read http://wiki.laptop.org/go/Rainbow and let me know if you're still concerned about what's required to use Rainbow or about how I intend to make it easier still adopt. This makes it very hard to use it in a standard distro environment especially where Fedora (for example) already uses SELinux to implement some of the features of rainbow. I can see from reading the selinux-policy sources that lots of hard work has gone into confining all sorts of system services. Tell me, though -- what SELinux policy prevents a typical Abiword or Evince process, run by me from my desktop, from writing to my ~/.bashrc? Moreover, even supposing this policy exists, is it used by default on any Fedora spins, let alone on the main Fedora livecds? Rainbow has offered this safeguard, on by default on XOs, for over a year. (NB: Perhaps, we would be better served by spending our time wondering how the two technologies can complement one another, each sustaining guarantees that are too expensive [in complexity] for the other to maintain?) Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:09:26AM -0800, Carol Farlow Lerche wrote: My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), . things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. Carol, I can't promise that I've reached clearly lays out yet, but I /have/ worked a bit on unifying the Rainbow wiki page: http://wiki.laptop.org/go/Rainbow and I think that I could now use some more feedback about which parts are working for you and which parts aren't. Thanks, Michael P.S. - Other sugar folks might be interested to hear that Sascha Silbe (silbe) managed to launch some activities under rainbow inside sugar-jhbuild. You should follow up with him if you'd like to improve the system. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. So you've said in the past. What of it? I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. The justification which interests me the most goes something like: strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. The issue is that rainbow has been maintained and its downstream users (e.g. Sugar) need to give some feedback on the intermediate results so that there will be time for its upstream author to respond to that feedback. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it Thank you, no. I apologize if my writing contributed to this gross misunderstanding of my purpose. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote: Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Carol, Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. I'll see what I can cook up. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Do you have an example of documentation which you think really nailed the divide between what is needed, what exists, how good is it?, and how do I use it? Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. The purpose of the rainbow.txt document was to argue that a design /existed/ which would satisfy enough of the overall goals to be worth pursuing. The purpose of the Low-Level Activity API documentation is to explain what features of rainbow exist and can be twiddled by activities. As it happens, the main feature which exists is primitive filesystem isolation. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: How do I turn rainbow off for testing? which, in fact, is answered in the For Activity Developers section. http://wiki.laptop.org/go/Rainbow#For_Activity_Developers Obviously, a couple of people also found it helpful to tweak the isolation options in detailed ways as discussed in the API docs you cited earlier. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 03:45:33PM -0300, Daniel Drake wrote: Hi Michael, 2009/2/24 Michael Stone mich...@laptop.org: In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. How realistic is it to make rainbow something generic that all environments and applications could use? I consider it a realistic goal, with a few caveats. The rainbow-0.8.* redesign takes a big step in this direction by introducing an exec-wrapper interface which can be embedded in fd.o .desktop launchers, used from the CLI, and used by custom launchers like Sugar with equal ease. Privilege is acquired from a setuid helper; e.g. sudo. The design and automated tests now support limited concurrent multi-user operation, though the implementation needs a bit more work in order to operate securely in a multi-user environment. The only notable dependencies so far are on python and glibc. The caveats are: a) Usability sucks at the moment. For example, I need to implement some sort of garbage collection and some kind of user-facing UI, which might just be a simpler CLI wrapper. I probably also need to write a man page and to introduce more diverse error codes. b) We're going to need recent kernels for the fancier containerization stuff that I'd like to work on in the future. (Fortunately, upstream seems to be making good progress on the features I want :) c) I don't have any good idea how well or poorly the current design scales. (I think it will work fine for desktop use. I'm just not sure how far beyond that it will stretch.) More questions? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote: You are now talking about the implementation of rainbow that provides userland privilege isolation. For the record, rainbow only describes the userland privilege isolation part. The rest is just OFW, olpcrd, olpc-update, OATS (If somebody knows a better way to explain this stuff, speak up!) One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. I think this would have the effect of making rainbow much less generic than it currently is. On the other hand, it might still be worth doing if it made it much easier to implement important features. Maybe rainbow could insta-isolate creating selinux profiles for activities? I've been wondering about this for some time. Basically, while my reaction when it was initially proposed it was lukewarm, for all the usual reasons [1]. Since then, I've been very gradually warming to the idea, in part as SELinux matures, in part as I get to know the technology and people [2] better, and in part as I run up against limitations of the simple Unix approach that I've taken for the last year. Therefore, while it's not how /I/ intend to proceed in the near future, I'm happy to try to work with people who feel differently. I definitely have some ideas on the subject. Michael [1]: http://lists.laptop.org/pipermail/security/2008-January/000370.html [2]: http://danwalsh.livejournal.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 06:05:51PM -0500, Benjamin M. Schwartz wrote: Sugar/OLPC simply never had SELinux experts I'm pretty sure this is false. For instance, I know that ancient OLPC+RH kernels has SELinux enabled and I know that the SELinux folks at RH have always been excited to help me to understand their work whenever I took the time to ask them questions every few months. It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified secure to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. This is actually not such a big deal, in my opinion. The killer problem, as I learned from the vserver experience, is that novice activity authors /must/ be able to debug their work in any system which we might hope to ship. I don't think that I have very good ideas on how to make this part workable with technologies that are more complicated or more obscure than Unix DAC. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote: remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? Unfortunately, no. No one has yet completed an implementation of the gates needed to guard access to the DS and the glue needed to know which DS entries to fork over to which activities. (I got partway through an implementation of the gates, which are actually fairly simple, but didn't get to the glue. [8.2.0 intervened.] Later, Scott approached the problem from a completely different angle, i.e. with FUSE filesystems. Hopefully, though, Tomeu's simplified data store will make further work in this area a bit simpler, if any such work occurs.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RFC: Supporting olpc-ish Deployments - Draft 1
Folks, Pia Waugh (greebo) and I have spent a fair bit of time in the last month talking and thinking about what we can do in the next few months to best support present and future olpc-ish deployments (typically with XOs, typically running Sugar) and we'd like to share some of our thoughts with you. These thoughts are presented in draft form in order to solicit your feedback, which is eagerly awaited, and will likely be incorporated into future drafts. Regards, Michael -- 1. Motivation We think that many deployment-related needs are not being adequately met, particularly in the areas of: * knowledge-sharing and the ability to benefit from others' mistakes. * volume and quality of aid available for conducting deployments. * bandwidth, latency, and SNR of channels to other communities which work with deployments; e.g. other deployments, educators, software teams, distributions, researchers, consultants, and volunteers 2. Use Cases We're particularly interested in addressing these situations and needs: D1) I'm running a deployment... a) ...and I need help! Who shares my problem? Who can help me? b) ...and I want to do more! Who/what can I work with? c) ...and I want to share! Where do I go? What is needed? D2) I need to talk to people deploying XOs. a) Where do I go? b) What can I expect? D3) I'm working on a deployment plan. a) Where to I start? b) What have I forgotten? c) Am I using best practices? d) Can I get a review? D4) I need to know... a) real deployment numbers, b) maps, c) examples, d) photos, e) techniques, f) contact info, ... 3. Existing Resources for Use Cases Before we started, there were three basic mechanisms for addressing these use cases: 1) read the Deployment Guide and the Deployments page(s): http://wiki.laptop.org/go/Deployment_Guide http://wiki.laptop.org/go/Deployments http://wiki.laptop.org/go/Deployments_support 2) ask olpc-techsupp...@laptop.org. (Only available to large deployments?) 3) poke people on IRC. These three mechanisms are problematic because none of them can be relied upon, alone or in combination, to adequately address any of the use cases listed above. 4. New Resources for Use Cases So far, we've created two new resources which help bridge the gap: 4) weekly deployment support meetings, with minutes at http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes which get aggregated each month into 5) a Deployment FAQ, http://wiki.laptop.org/go/Deployment_FAQ similar in form and spirit to the G1G1 http://wiki.laptop.org/go/Support_FAQ We think that these two new resources, in combination with the pre-existing resources, will help us provide the next level of support for our use cases. 4. Projects We presently have several ongoing (interrelated) projects which you might like to become (more deeply) involved in: P1) Keep improving the deployment support meetings -- so far, so good! -- your participation in these meetings is our best current source of new content for the Deployment FAQ and for... P2) Organize material captured in the meetings as FAQ entries -- the meeting minutes are chronological, which is good for minutes, but not particularly helpful for random-access reads. -- FAQ entries seem like a good compromise between maintenance cost, timeliness, and satsifaction of the use cases P3) Update the Deployment Guide -- The Guide is now ~1 year out of date -- and it leaves too much to the imagination: just look at its advice on critical areas like connectivity, content acquisition, and means of participation in the larger community of 1-1 educational laptop programs in general and XO deployments in specific. 5. Status Project P1 (meetings) is rolling along quite happily only one month after its inception but it could use your help in order to become even more vibrant, dense, and ingrained in the olpc-psyche. Project P2 (FAQ) is just beginning -- we've done a first rough-cut which you should review for us and help us edit down into something awesome! Project P3 (Guide updates) is just a twinkle in our eyes -- and it needs your help to fly! In particular, three different mechanisms have been tentatively proposed for how to accomplish the update(s): a) By sprints, like the FLOSS Manuals sprints that created the XO and Sugar manuals. b) By accretion, like the rest of the wiki, performed on a piecemeal basis by participants in the deployment support meetings. c) By issue-tracking, like
[Server-devel] Mass olpc-update via XS?
Dear XS folks, Daniel Drake, currently in Paraguay, wants to try implementing the procedure described in http://wiki.laptop.org/go/User:Mstone/Commentaries/Mass_olpc-update via XSen (using DNS to redirect the XOs' theft-deterrence protocol requests to the local XS.) However, after briefly scanning the wiki, I noticed that we have http://wiki.laptop.org/go/XS_Blueprints:Lease_and_update_server http://wiki.laptop.org/go/XS-activation http://wiki.laptop.org/go/XS-rsync but no sign of an XS-ified theft deterrence protocol server. Now, to the best of my (limited) knowledge, there is one usefully complete implementation of the protocol, http://dev.laptop.org/git?p=users/cscott/act-server;a=summary which was deployed in production at antitheft.laptop.organd activation.laptop.org and used to update several thousand G1G1'07 machines. (The installation of the code on those machines is, as usual, thoroughly documented internally at Machine:antitheft and Machine:activation pages, for those with access; some small bits of censorship /are/ needed before publication.) In conclusion, do you currently know any problems that would prevent merging whatever packages he and I create for his XSen (probably based on Scott's code) into the main XS tree, assuming that we provide suitable documentation alongside them? Anyone got any better ideas about how to accomplish our goal? Thanks, Michael ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Reminder: Deployment Support Mtg @ UTC 2000; 3:00 PM Boston
Hi folks, Daniel Drake (dsd) asked me to send out an reminder to people who might be interested in asking and answering questions relevant to XO deployments. If you'd like to partake, please join us in #olpc-deployment on irc.freenode.net at UTC 2000 (3:00 PM Boston), which is in about 35 minutes. If you're unavailable, don't worry -- as always, minutes will appear at the bottom of http://wiki.laptop.org/go/Deployment_meetings and we'll try to address issues recorded on that page as agenda items or on http://wiki.laptop.org/go/Deployment_wishlist Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Minutes from olpc-friends' Feb. 03 and 10 Deployment Meetings
Folks, Last Tuesday, we held an awesome deployment meeting (at 2000 UTC on #olpc-deployment on irc.freenode.net) which featured sustained engagement with the Hernan's deployment troika: logistico, técnico y pedagógico, as well as extensive brainstorming of solutions for issues relevant to Peru, Sierra Leone, and Birmingham. Minutes: http://wiki.laptop.org/go/Deployment_meetings/20090203 Today, we had a quiet sharing of knowledge with Wade Brainerd, head of the Sugar Labs ActivityTeam, a nice Nepal update, some fine exploratory thoughts on the Rwanda deployment, and a pitch by Richard Smith for help with his long-awaited Multi-Battery Charger. Minutes: http://wiki.laptop.org/go/Deployment_meetings/20090210 Enjoy, and please join us in a few hours 0500 UTC or again next Tuesday at 2000 UTC. As always, please add items to the next meetings' agenda at the bottom of http://wiki.laptop.org/go/Deployment_meetings so that interested folks can prepare questions and remarks or update the http://wiki.laptop.org/go/Deployment_wishlist (For extra motivation, be sure to check out dsd's four most recent wishes -- contributed live, directly from Paraguay!) Voluntarily yours, Michael P.S. - Sorry that it took me so long to get last week's minutes posted -- they were hard to disentangle! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Please update etoys in 8.2.1
so after the 8.2.1 release the plan is to just switch to standard Linux distros? Speaking entirely as a volunteer: the answer depends on who you ask. Since I think that 8.2.0 wasn't half bad, I'm currently trying to persuade people who feel similarly to work with me to assemble an 8.2.2 with some useful bugfixes and software updates, because I think that a) it's the right thing to do b) it will complement various upstream efforts (both in Fedora, Sugar Labs, and the wider FOSS community at large) by helping to concentrate deployment-specific testing effort on the most relevant parts of their work c) that it's important to deliver a product which directly meets the needs of existing deployments even when those needs don't precisely match the needs and goals of the larger upstream communities. Does this help clarify the situation? Michael P.S. - My current ideal list of changes would include: * fix the memory stability issue * ship the new gabble w/ support for out-of-band stream tubes * ship the latest gnash and I'd be very happy to discuss shipping various sugar or platform updates as well; e.g. java. What do you want to see in a new release? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
8.2.1 Thoughts
Hey folks, Here are some more unofficial thoughts on how 8.2.1 is progressing: 1) Daniel Drake discovered some annoying wifi regressions (#9235). We need to find root cause here, e.g. by bisecting the kernel patches added since 8.2.0 and testing each resulting kernel with both the new and the old firmware. 2) The firmware looks awesome! Daniel and I both spent some time testing the new features of OFW q2e30 and we liked them so much that we worked together with Scott to implement some new initramfs features that make them easier to use. However, since they affect security critical code, they could always use more eyes. If you'd like to learn about how these components work, then please help test and review the patches! 3) More smoke testing, please! TJB did a full smoke test on staging-25, which went well modulo some wifi and collaboration concerns, but more exploratory testing is still needed. Consequently, we expect to announce a new build within the next day or two for you to help test. (The new build will feature an exciting Etoys update that missed 8.2.0 by a hair and which has been ripening ever since.) I'll announce this new image both by email and on http://wiki.laptop.org/go/Friends_in_testing as soon as it's ready. In conclusion, so far so good! Regards, Michael P.S. - A couple of people have asked about the possibility of future releases beyond 8.2.1, e.g. to offer access to new versions of gnash, telepathy, cerebro, etc. and to motivate folks to help fix long-standing 8.2.0 bugs like the memory stability issues. I'll just mention in passing that I'd be quite interested in facilitating an 8.2.2 release containing these updates, assuming the continued interest of the folks whose help is needed to actually do the integration, do the testing, and fix the bugs... Interested? (as a warm-up round toward bigger things?) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
On Wed, Feb 04, 2009 at 05:53:14PM -0500, Chris Ball wrote: Hi, This is Fedora's initramfs, right? Right. Peter's suggestion is to use pilgrim to create rawhide builds, hence using the olpc initramfs. That's an interesting idea. I don't like it long-term, because no-one's working on pilgrim or our initramfs, but it could help us get moving. Two small corrections: a) the initramfs continues happily under active volunteer development -- it received two new features and a bugfix contributed by a deployment support volunteer (dsd) in the last two weeks, along with patch review and volunteer testing by folks back here in the States. b) While pilgrim may be a dead-end, the ideas underlying it are not. This week, I translated pilgrim's ideas into the simplest form yet achieved, namely, a plain old Makefile: http://dev.laptop.org/git?p=users/mstone/puritan;a=tree;hb=make and used it to produce builds from the olpc4+joyride tree and the rawhide+olpc4+joyride tree (with minor edits). The former booted happily into Sugar and built on both Debian and Fedora. :) (The latter, still using the olpc initramfs, dies because upstart 0.5 still doesn't know how to run as non-pid-1. olpc4's upstart-0.3.9 has a patch which implements this feature.) Peter does not have an XO (g...@contrib program extreme slowness!) but may be able to help on other issues that surface as the result of an available public build... Oh, let's fix that. Ed, SJ, could one of you take care of sending Peter some XOs ASAP, please? Good idea. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Deployment Support Mtg -- Today, 2000 UTC, #olpc-deployment
Hey folks, This is just to remind you that we'll be meeting at 2000 UTC today (3:00 PM Boston) in #olpc-deployment on irc.freenode.net to chat about deployment support topics. Detailed minutes from this meeting will appear at http://wiki.laptop.org/go/Deployment_meetings/20090203 alongside the minutes from previous meetings, which can be found at http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes If you'd like to have an agenda, then please write one as indicated on the meeting notes link above. Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Summary Minutes from olpc-friends' Tuesday Deployment Meeting
Folks, We had an awesome deployment meeting this Tuesday at 2000 UTC on #olpc-deployment on irc.freenode.net. Almost 30 people came, with knowledge of 10 different deployments! Summary and minutes are now available at http://wiki.laptop.org/go/Deployment_meetings/20090127#Summary http://wiki.laptop.org/go/Deployment_meetings/20090127 Enjoy, and please join us next Tuesday at 2000 UTC or Wednesday at 0500 UTC. Also, please feel free to add items to the next meetings' agenda at the bottom of http://wiki.laptop.org/go/Deployment_meetings so that interested folks can prepare questions and remarks. Voluntarily yours, Michael P.S. - Would some kind English+Spanish-speaking soul be willing to provide a nice translation of Hernan's remarks: http://wiki.laptop.org/go/Deployment_meetings/20090127#hpachas.27_Remarks for interested illiterates like me? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
8.2.1 Release Status - Thursday, Jan. 29, 2008
Folks, I just thought I'd offer some unofficial advice on the state of 8.2.1 for interested listeners: a) In the last several weeks, there has been significant package churn at all levels of the stack including: kernel bootanim bootfw olpc-utils libX11 xkeyboard-config sugar-journal glibc glibc-common as described in more detail by http://dev.laptop.org/~bert/staging-pkgs.html and http://dev.laptop.org/~rwh/announcer/staging-pkgs.html As a result, we're bottle-necked on QA. b) Some dedicated volunteers -- notably S Page, dsd, TJB, kimquirk, Hal Murray, genesee, tiesj, greebo, Mikus, John Ferlito, and ivazquez (thanks all!) -- have done some fine work getting us unstuck on QA! In particular, their volunteer wifi testing turned up #9222 which dsd thinks he fixed this morning from Paraguay! However, I think that there might be more wireless regressions -- please keep trying to break things with recent staging builds! c) Mitch has worked long and hard on #9045, which was one of the tickets motivating this release! Today, he delivered a new firmware, q2e30, which you should all help test. It's available in staging = 25 and it needs both serious regression testing, e.g. http://wiki.laptop.org/go/1_hour_smoke_test and some dedicated feature testing according to the test plan laid out by Mitch here: http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support (I had so much fun making my own keys last night that I stayed up after an evening out on the town with Henry friends to help Mitch test this!) d) Somebody needs to provide appropriate activities for our smoke tests (preferably via customization stick) and to make sure that those activities are properly listed on the usual laptop.org wiki pages. Help wanted! Wade -- is this something that your new activity team would like to help with? e) In conclusion, 8.2.1 seems to me to have been put back on track by the unrivaled commitment of you, our dedicated Friends in Testing. Thanks! Regards, Michael (P.S. - Thanks also to Chris for keeping things rolling by wrangling builds and tickets at all hours of the day.) :) (P.P.S. - If you're looking for something to test this week, please try out my refreshed http://wiki.laptop.org/go/Friends_in_testing instructions!) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Small DNS questions.
Scott, I've been conducting some thought experiments with the imaginary DNS server you describe in http://wiki.laptop.org/go/Network_principles#Name_resolution and I've developed a couple of small questions which I'd like your advice on, e.g. a) When multiple links are present, does the DNS server synthesize an RR for every link? b) Presumably the DNS server should report itself as non-authoritative for everything except the local hostname(s)? c) Presumably the synthesized RRs should be non-authoritative except when they answer the local hostname(s)? d) How should the TTL of the synthesized records be set given that the records are link-dependent? (on a mobile device?) e) When, exactly, should our DNS server synthesize RRs? Some possible choices: always, when you can't get any other results, when you didn't find NXDOMAIN, configurable __ Thanks, Michael P.S. - People who are unfamiliar with the ideas and questions in this note who would like to contribute to the conversation should probably spend some time reading RFCs 1034, 1035, and 2460 and Scott's Network Principles document. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backlight control
David -- why quibble over ohm when you've got NM and HAL to worry about? Paul -- why are the /sys nodes only writable by root? Michael On 1/24/09, da...@lang.hm da...@lang.hm wrote: On Sat, 24 Jan 2009, Marco Pesenti Gritti wrote: On Sat, Jan 24, 2009 at 3:43 PM, p...@laptop.org wrote: but if ohmd is going to be in the middle, then the published api for requesting those changes should be more transparent than requiring every application be in python and have knowledge of dbus. There is no python dependency and I personally have no problems with a dep on dbus. Leaving aside technical considerations about dbus, pretty much everything in the desktop land requires it these days (and ohm is heavily based on it afaik). It's not worth to resist the flow ;) so is there a standard that says that every desktop must use dbus now? If so I missed the memo. I don't have much of a problem with any individual desktop deciding they want to use dbus (gnome, kde, etc) as I still have the choice to use other systems (lxde, windowmaker, etc) but to make fundamantal control of the hardware require dbus seems like a signficant step. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Notes from an impromptu 8.2.1 Release Mtg.
Hi folks, Kim Quirk kindly stopped by #olpc-meeting this evening and precipitated an impromptu discussion between herself, me, cjb, edmcnierney, mchua, and garycmartin on how to push 8.2.1 a few inches closer to release. The main conclusion that we reached after we updated http://dev.laptop.org/report/38 was that staging-9 [1] needs some testing! In particular, it's got long-awaited new wireless firmware and wifi kernel drivers which means that we need to know whether it still associates with your crazy encrypted access points. :) At any rate, the bottom line is that YOU can personally help 100k kids in Uruguay get access to 8.2.* faster by helping to test this build. (Guadalupe and Emiliano in Uruguay have already helped to test fixes for some of the issues they found in 8.2.0 but more (your!) testing help is still needed!) So, on that note, thanks very much in advance for any help that you can provide. Voluntarily yours, Michael P.S. - Bryan -- would you please update FiT with instructions for staging-9 wifi-testing? P.P.S. - I'd like to host a test party at 1cc sometime in the next two weeks to try to do some large-scale collaboration and wifi testing such as was requested by dsd [2] in preparation for his trip to Paraguay tomorrow [3]. Would interested people who might be in Boston in the next two weeks please mail me to let me know good days and times for them to come help test? P.P.P.S. - The major coding work left before we can wrap up 8.2.1 is currently resting on Mitch Bradley's capable shoulders [4]. I'm looking forward to receiving a new OFW snapshot from him for testing in the not-too-distant future. [1]: (http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/build9/devel_jffs2) [2]: http://wiki.laptop.org/go/Profiles/DanielDrake -- dsd, update you profile! [3]: http://wiki.laptop.org/go/Deployment_meetings/20090120#Summary [4]: http://wiki.laptop.org/go/Profiles/wmb ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Summary and minutes from Pia's first Deployment Meeting.
educat...@lists.laptop.org Cc: Bcc: Dulmandakh Sukhbaatar dulmand...@adsolux.com, guadalupe, emiliano Subject: Summary and Minutes from the Jan 20, 2009 Deployment Meeting Reply-To: Hi everyone, Here is the summary and the edited minutes for the first of Pia's new deployment support meetings: http://wiki.laptop.org/go/Deployment_meetings/20090120#Summary http://wiki.laptop.org/go/Deployment_meetings/20090120 Enjoy, and please consider joining us later today/tomorrow at 0800 UTC (0300 in Boston) in #olpc-deployment on irc.freenode.net to discuss the questions and comments raised in today's discussion or left waiting on pages like http://wiki.laptop.org/go/Deployment_meetings or http://wiki.laptop.org/go/Deployment_Wishlist Thanks! Michael (in his new-fangled volunteer capacity) P.S. - If you can't attend this week, please come next week instead! (And do read the minutes; they took forever to prepare... :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Farewell.
Like many of my esteemed colleagues, I am parting ways with OLPC. I will treasure the memory of our collective adventure... ...while naturally looking forward to new opportunities: professional, educational, and otherwise. Michael P.S. - (Anyone else wondering what happened to their social life over the last year? ;) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Customized images
On Mon, Jan 05, 2009 at 02:27:45PM -0500, Carlos Dario Isaza Zamudio wrote: I have a fully customized XO and i need to take an image from it to be installed on several computers inside the project. The thing is i need it to be separated from the activity pack, like the ones you use to update via USB. Hi Carlos, Thanks for the great questions. Questions 1) When i take the image from this one and install it into another, will i have two computers wchi are exactly the same? No. Each XO contains unique manufacturing data, stored in a non-volatile memory which is separate from the main (1GB) non-volatile memory. Moreover, when you boot an XO, it runs some software which dirties the filesystem. You'd want to clean the filesystem by undoing some of these edits before you clone the image onto lots of other machines. 2) In order to do this process does it have to be into a unblocked XO or with developer key? Because if that's the case, i can't do it since these are the computers we're gonna use for deployment. a) Why do you want the computers to be locked? b) You can temporarily unlock the computers in at least two ways. c) We're designing some software changes over at http://wiki.laptop.org/go/Partial_key_autonomy which might make this easier for you to maintain. 3) Out of the topic question but do you know how can i change the default page from the Browse activity? You need to edit the Browse source code here-ish: http://git.sugarlabs.org/projects/browse/repos/mainline/blobs/master/webactivity.py#line269 (i.e. search for load_uri in webactivity.py) Thanks for your replies You're very welcome. Please come back with more questions! Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 12:19:52PM -0800, Deepak Saxena wrote: On Jan 06 2009, at 14:42, Chris Ball was caught saying: Hi, I think I missed the previous conversation, re: estimate , but I'm thinking that swap will have significant impact on the lifetime of the flash chip. With only 256MiB of RAM, we are bound to swap a lot. I'd feel more comfortable if we did flash-wide wear leveling using UBI and created a swap partition on to pof that. That's fine with me too. Are we still planning on moving to UBI for 9.1? If not, maybe we can work out how to get swap files working on JFFS2 (where they would be wear-leveled)? At this point, with 2 months to desired release date, Deepak, I don't think I know anyone who can convincingly argue that the March date is realistic, based on current rates of change and the remaining distance to the objective. I asked in the last (maybe even the last two?) status meetings to re-evaluate that date but was blown off. Make of that what you will. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Greg, I don't mean to be nasty, but I do feel the need to be blunt: On Tue, Jan 06, 2009 at 04:28:36PM -0500, Greg Smith wrote: Hi Michael, We are definitely behind where I would like to be at this stage. How far behind? However, we'll only move the date when we must and we'll only do it to improve quality What exactly did you think Deepak and Chris were discussing doing? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Customized images
On Tue, Jan 06, 2009 at 03:52:44PM -0500, Erik Garrison wrote: On Tue, Jan 06, 2009 at 03:23:32PM -0500, Michael Stone wrote: On Mon, Jan 05, 2009 at 02:27:45PM -0500, Carlos Dario Isaza Zamudio wrote: I have a fully customized XO and i need to take an image from it to be installed on several computers inside the project. The thing is i need it to be separated from the activity pack, like the ones you use to update via USB. Hi Carlos, Thanks for the great questions. Questions 1) When i take the image from this one and install it into another, will i have two computers wchi are exactly the same? No. Each XO contains unique manufacturing data, stored in a non-volatile memory which is separate from the main (1GB) non-volatile memory. Moreover, when you boot an XO, it runs some software which dirties the filesystem. You'd want to clean the filesystem by undoing some of these edits before you clone the image onto lots of other machines. Dirty might be too general a word. Specifically there are a number of changes made to system files during the first boot of the machine which you might not want to copy between machines. (SSH keys, for instance, are generated once at first boot on every XO. Also, hardware-dependent information from the firmware is cached on the NAND after first boot.) We haven't worked on figuring out what pieces of the system are touched, so, as Michael notes, copying the machines can have unintended side effects. It seems that nearly everyone who tries to distribute images by cloning runs into some oddities. That said, it also seems that this method of customization is the most appealing and straightforward. It has come up several times recently and I think the time has come to properly evaluate it. Perhaps someone here could be tempted into writing a clean-up script like we discussed the last time this came up? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 07:40:07PM -0500, Reuben K. Caron wrote: Peter Robinson wrote: Hi Chris, I would remove the old fc9 build from the olpc_development repo (or even have one for 8.2.0 and one for 9.1.0 so they don't get mixed up). Surely it should be pulling cyrus-sasl from the Fedora repos anyway? I've just pushed a patch to pilgrim's joyride branch to switch the baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/ (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride should have been switched to write out the olpc4 baseurl when we created the new repo.) And, after the change, we don't have depsolving problems any more! Here's the list of packages to be downloaded -- the next question is going to be how to avoid many of these dependencies. Perhaps instead of trying the groupinstall, we should be hand-picking a smaller base of GNOME packages from this list? Well its the list up to the Installing for dependencies that is explicitly requested, all the below is pulled in for deps. I'm not sure how pilgrim builds the list but I think if it uses kickstart like the other fedora build systems do you should be able to do a specific -packagename and its removed from the list. Does pilgrim (Puritan?) use kickstart like files? Nope. If not, why do we not create builds using what seems to be fedora's standard build system? The short answer is that there has never been consensus among the people dealing with OLPC's builds that anaconda was the right tool for the job. The longer answer involves a lot of politics which I'm /really/ not interested in stirring up but which are unavoidable if you want to really understand how things came to be the way that they are. In order to navigate this quandary, I'm going to offer you a series of thought-questions which, I hope, will lead you to your own answer to your question. (If you want, you can ask me tomorrow for my answers to them but you should try to construct your own answers first.) Hope this helps, Michael - a) Requirements. 1. What do you think a build system for OLPC and for XOs needs to do? 2. What explorations have been made in the area of XO-related build systems? 3. What lists of requirements (or audiences) do each of these explorations seem to be trying to satisfy? b) History Incumbency of Pilgrim. 1. Why did davidz write pilgrim? 2. Why did pilgrim not use anaconda? 3. Why did davidz later write livecd-tools using anaconda? 4. What do you have to do in order to get OLPC to use a different build system? c) People Politics 1. Who has worked on build-system stuff for XOs? for OLPC? 2. How might we describe their knowledge, skills, interests, aims, etc at the time? 3. What demands were placed on them at the time they worked on build-system related things? 4. How should we describe their relationships with one another? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Emulating 8.2-767
On Mon, Jan 05, 2009 at 01:07:00PM -0500, Wade Brainerd wrote: I would love to convert my OLPC Installer for Windows over to VMWare. In my experience it provides a better experience on Windows. I'd also like to convert it over to using Bert's image rather than the stock 8.2.0 image. What would be even better would be for the OLPC guys to set up emulator builds which mirror the regular Joyride, Staging, etc. builds and apply Bert's customizations automatically. Wade, Is there something you need access to (e.g. an account?) that prevents you from doing this yourself? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Emulating 8.2-767
On Mon, Jan 05, 2009 at 01:18:53PM -0500, Wade Brainerd wrote: On Mon, Jan 5, 2009 at 1:16 PM, Michael Stone mich...@laptop.org wrote: On Mon, Jan 05, 2009 at 01:07:00PM -0500, Wade Brainerd wrote: I would love to convert my OLPC Installer for Windows over to VMWare. In my experience it provides a better experience on Windows. I'd also like to convert it over to using Bert's image rather than the stock 8.2.0 image. What would be even better would be for the OLPC guys to set up emulator builds which mirror the regular Joyride, Staging, etc. builds and apply Bert's customizations automatically. Wade, Is there something you need access to (e.g. an account?) that prevents you from doing this yourself? Knowledge and time. Well, just be aware that while I can't help much with the time part, I'm more than happy to help with the knowledge part in any way I can. Just let me know what works best for you. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Please help test our pre-release build of 8.2.1
On Fri, Jan 02, 2009 at 11:04:01PM +0100, Bert Freudenberg wrote: On 02.01.2009, at 17:09, Brian Pepple wrote: Hi All, A pre-release build of 8.2.1 is now available for testing. It has passed an initial smoke test and now needs broader testing. The build download and problem reporting instructions are here: http://wiki.laptop.org/go/Friends_in_testing#Current_status The very early draft release notes are here: http://wiki.laptop.org/go/Release_Notes/8.2.1 Please send a note to the list if you try this build even if you don't find anything interesting. We want to measure our test capacity. You should mention that you want people to test the latest staging build, not the latest 8.2.1 build (which is exactly the same as 8.2.0 at this point): http://dev.laptop.org/~bert/8.2.1-staging.html This is a significant change from previous release procedures (e.g., I was not even aware that staging builds were meant for testing). Bert, Here's the idea: (f10/olpc4)(f9/olpc3) | | v v joyride staging | | v v (9.1.0)8.2.1 \ \ available now. \ will be created eventually (This is the first time we've had two active integration streams.) Does this help clarify things? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems with Adobe Flash player on the XO.
On Fri, Jan 02, 2009 at 10:56:59PM +0800, Carlos Nazareno wrote: Ditto. I've tried Sugarizing newer versions of Opera myself, but we're out of luck because of the Rainbow Security implemented in newer XO OS builds don't allow writing of files by Activities to certain directories that Opera installs to. The Opera dudes will have to create a special OLPC Opera Activity for us like with 9.12 since Opera is not open sourced and we won't be able to do the proper modifications for Rainbow Security compatibility ourselves. Could you be more specific about what writes are failing? In the past, we've been able to achieve both isolation and a working activity (e.g. Scratch) with some easy filesystem tricks... Also, have you filed a bug? I've tried searching dev.laptop.org for opera rainbow but I didn't find any likely tickets... Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote: The solution to the performance problems is good old fashioned elbow grease These are the sorts of things that we need to find and squash - and yes, it will be very time consuming and a little boring. Several anecdotes for your amusement and reflection: * When was the last time someone posted to devel asking: what is the right algorithm or datastructure for task ? * When was the last time someone publicly analyzed the upper or lower bounds on the bandwidth, latency, or quantity of messages necessary to accomplish task ? * When was the last time that you published a performance goal for your software? Did you hit it? Did anyone notice? Michael P.S. - Charles Leiserson once remarked that performance is like a currency which programmers trade for (all) other worthwhile things like schedule targets, scope of features, other resource consumption, various kinds of security, etc [1]. This suggests that one would do better to ask for performance or but not both. Think of Blizzard. [1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On Thu, Dec 25, 2008 at 12:19:37AM -0800, John Gilmore wrote: along similar lines an issue I have been seeing with the network screen (but haven't gotten around to reporting). my home access point is encrypted and sometimes I can reconnect to it without a problem, but sometimes it acts as if it's never been connected to before (asking me for the encryption key). I've had to resort to printing the key and keeping it with me (not convienient or good for security). is this a known issue? is there anything I can do to help track down the issue? I see this all the time, too. There are some known bugs with encrypted access points, but I don't know if this one is clearly reported. Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Very frustrating. Access points with encryption have *never* worked reliably on the XO. I guess the programmers in Cambridge had better turn off their open access point, or it'll never be solved. Like the memory freezeups, I just assume that everyone is seeing this and nobody cares to work on it. Daniel Drake has repeatedly offered (and in the past, made good on his offer) to help debug reproducible association problems involving wireless encryption. Other members of the wireless team, including Ricardo Carrano has done the same. Finally, several wireless folks have reported that direct use of wpa_supplicant with correct flags (rather than indirect use of wpa_supplicant by means of NM) results in more frequently successful association attempts [1]. Perhaps they might be interested in working to write up the outline of a logic tree for debugging failed association attempts such as the one that Tomeu and Mel created for debugging memory leaks? Regards, Michael [1]: http://lists.laptop.org/pipermail/devel/2008-October/020757.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: communication among heterogeneous software versions
On Thu, Dec 25, 2008 at 12:41:37PM -0500, Mikus Grinbergs wrote: It's good that these heterogeneous-software-version XOs were able to see each other's presence. But being shown two different kinds of information in the output illustrated a potential exposure -- What if the systems at a given site do *not* all contain the same software version (e.g., from 2008 vs 2009). Will all those systems be able to correctly collaborate among themselves ? My experience suggests that the presumption should lie nearer to the idea that the systems will be incompatible until they are tested as being compatible than it does today. If not, do deployments need to be cautioned ? Yes, though gently, since things frequently work just fine. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
8.2.1 Smoke Testing
Hey folks. We could use your help testing our first real 8.2.1 integration build, named 'staging-7' You can find it at http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/build7/devel_jffs2/ The tickets which people think it fixes are here: http://tinyurl.com/8r6clm If you can't find the testcase for one of these changes, please push it back into the 'testcase' workflow state. (next action field). (See http://wiki.laptop.org/go/Trac_ticket_workflow for more details.) Thanks very much! Michael P.S. - I expect that Brian Pepple, our new Friends-in-Testing (FiT) coordinator will be improving http://wiki.laptop.org/go/Friends_in_testing to reflect this information shortly. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 Smoke Testing
P.S. - I know that Mel volunteers have done some awesome work on systematic testing for 8.2.1 here: http://wiki.laptop.org/go/Test_cases_8.2.1 and that results from the Old Smokey of OLPC testing, http://wiki.laptop.org/go/1_hour_smoke_test would be truly appreciated. P.P.S. - If I forgot anything else important, or if you have questions or improvements of your own to contribute, don't hesitate one second to reply. Thanks again! Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Deployment image customization
On Tue, Dec 23, 2008 at 09:18:51PM +0200, Morgan Collett wrote: On Tue, Dec 23, 2008 at 18:29, Daniel Drake d...@laptop.org wrote: On Tue, Dec 23, 2008 at 2:19 PM, Greg Smith gregsmitho...@gmail.com wrote: Your suggestion that we allow addition of RPMs and get those built into a signed image via pilgrim or puritan is certainly valuable and part of the requirement. However, it doesn't cover a few added things (language settings was specifically requested by Mongolia and others): - Updated language packs (I believe we are trying to make this an RPM which may solve it) - Starting language - Date, time and timezone - Network settings Both puritan and pilgrim install many unpackaged hacks; that's actually the major reason why they exist. (Some special indirection needs to be taken if you want to deploy hacks to /home via olpc-update, since it doesn't touch /home, but for whole-NAND-reflash tasks, either is certainly adequate.) It's also possible to combine a compose-tool like puritan or pilgrim with our existing image-builder technology (which generates mfg-ready images from customization-stick data.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Deployment image customization
On Tue, Dec 23, 2008 at 03:29:08PM -0500, p...@laptop.org wrote: daniel wrote: On Tue, Dec 23, 2008 at 8:08 PM, p...@laptop.org wrote: ssh host keys are probably generated on first boot as well. with partitioning support, it should be possible to have a r.o. root overlaid by a unionfs writeable mount, so machine-specific changes don't modify the released partition. this would make cloning quite a bit easier, i'd think. i have no idea what the performance hit of a unionfs setup would be, nor how such a partitioning would fit into the rest of the update strategy (e.g. olpc-update). unionfs isn't upstream and was quite unreliable last time I use it. And it adds the challenge of differentiating state that must be discarded for the cloned image, and state that must not be. For example, we would want to ssh keys generated during first boot to *not* be included in the clonable image, that's obvious. But if the user boots the OLPC image, goes into the control panel and sets a language, then we *do* want that language change to be included in the clonable image that is the output of the process. How would the system differentiate between those two? i dunno. i guess the lead engineer on the project would have to decide. :-) In my opinion, the simplest way to approach this is to add a hard-reset script (perhaps named olpc-hard-reset) which cleans up the image and then prints out a diff from the starting image to the result for manual review. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Problems revealed by a report of detailed changes to 8.2.1 tickets.
Ed, I made http://dev.laptop.org/report/39?TIME=80 in the image of one of my old 8.2.0 reports. (TIME is the number of seconds of history that you want to view so that URL shows you all changes to tickets with milestone 8.2.1 made in the last 9-10 days). At the time of this writing, over the past week, 7 out of 16 tickets have been updated, primarily by Deepak and Scott with some additional questions and discussion from Sayamindu, Bert, and Simon. I know that I find this degree of recorded progress less than satisfactory. Do you feel the same way? If so, you need to know that I feel neither empowered nor requested to push this along as fast as it can go. (Does anyone else feel similarly?) Consequently, if you want my full potential contribution to 8.2.1 to be realized, I strongly suggest that you, as 8.2.1 release manager, would do well to provide me with better and more regular instruction, e.g. by * assigning some 8.2.1 tickets to me, (I have none) * by requesting me to choose some tickets that I can handle, * by _promptly and regularly_ checking in with all of the people in the critical path to release to find and remove obstacles to their work, * or by delegating the responsibility and authority to do these things to someone else if that's the best way to get the job done. To summarize, Trac suggests to me that people are either not reporting their work or are stuck, perhaps because of deadlock, contention, starvation, challenge, or distraction. How are you going to solve the problem? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems revealed by a report of detailed changes to 8.2.1 tickets.
On Mon, Dec 22, 2008 at 01:57:56PM -0500, Ed McNierney wrote: Michael - Are we able to promptly and regularly generate 8.2.1 builds that reflect the work being done? For basic testing purposes, yes. Scott's weekend report indicated that he set up a 'staging' build stream on xs-dev. You can see its output at: http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ Input is provided hourly via the d.l.o package dropbox or via the local.8.2.1 and koji.dist-olpc3-testing branches of mock.l.o/repos. (P.S. - Scott -- you need to push the pilgrim configuration off of xs-dev up to pilgrim's main repo.) True 8.2.1 builds, being under full change control, require trained manual intervention to create, e.g. by cscott, dsd, or me. From last week's reports I get the impression that various bits of progress are being made, but we've had no 8.2.1 builds since the first one. What stimulus is supposed to prompt the creation of such a build? Since some people have refused to follow the workflow I helped write for 8.2.0 and since you have not reported on the outcome of your scheduled conversations with those people, it is not at all obvious how to proceed. Please let me know if there is anything I can do to assist. In my opinion, more active shepherding of changes and people by the release manager is clearly called for. For example have you: a) clearly broadcast what ticket workflow you are using? b) set any deadlines for the completion of any pending work? c) publicly poked people for status updates, or d) successfully synchronized people on the status and needs of 8.2.1 by either email or IRC meetings? Is there some reason why you feel that none of these forcing functions is necessary to the release effort or some other commitment that prevents you from carrying them out? If there is anything you (or anyone else) can do to ensure that bug fixes can quickly get into a build for testing, that would be very helpful and an excellent assignment. I spent a long time thinking about this remark and about my reaction to it. On the basis of that reflection, I need to apologize in advance that my patience has has worn so thin... my reply may be harsher than it needs to be. It consists of two responses, one outward-facing public response and one inward-facing critical response. Outward response: Sure, happy to help. I'll go poke the necessary people. Inward response: This remark is unacceptably vague. In order to be the release manager, you're supposed to know or to be able to figure out what needs to be done in order to make the release happen. Moreover, while I'm happy to help with many tasks, I don't really enjoy feeling like I'm prompting you. Example: if 8.2.1 builds concern you, why did you not make more noise about them last week? (e.g. by sending mail to devel@ or filing a ticket asking about them.) Does your process for getting the release unstuck actually consist of waiting for me to send you questions, then asking me or Scott to fill in the details of the segment of the critical path that lies immediately ahead? Thanks. You're welcome. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fixed Puritan bug on F10/Intrepid
On Tue, Dec 16, 2008 at 03:03:08PM -0500, Reuben K. Caron wrote: Michael, The build was successfully made on both F10 and Intrepid. How could I slip in a language pack? How could I set the Timezone for the build? How could I set the default language for sugar? Well, first, figure out how would you normally do these things. Then add the necessary files to the compilation directory and modify the 'install_hacks.py' file (or add a custom stage) to apply the changes. Would it help for me to work out an example for you in a subsequent reply? (Would you like to work out one as an example and post it for others to enjoy?) Thanks, Michael P.S. - You should try out the latest version of the ui and 767 compilation -- I worked up a nice automatic caching feature and I improved the interactive debugging mode too! (Be slightly wary though; the code is far from well-tested.) P.P.S. - You can use 'git pull' to pull down the latest versions of the ui and compilation. If you decide you don't like them, you can go back to the earlier versions with a combination of 'git log' to find out the commit-hash identifying the version you want and 'git reset --hard hash' to move to it. Again, let me know if a more verbose tutorial would be helpful. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fixed Puritan bug on F10/Intrepid
Reuben, I was able to reproduce and work around the rpmdb version problem you found today on a new Intrepid vm I created on weka.l.o. Would you mind retesting with my new 767 compilation? (To do so, just wipe the compilation and re-clone it. I modified the cloning instructions so that, in the future, you'd be able to run 'git pull' to update.) Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: a build reproducibility test
On Sat, Dec 13, 2008 at 03:53:14PM +1100, James Cameron wrote: On Fri, Dec 12, 2008 at 12:40:37PM -0500, Michael Stone wrote: On Fri, Dec 12, 2008 at 03:27:21PM +1100, James Cameron wrote: Why can't the build system be replicated so that each developer can test their change before releasing it? What is it about the build system that prevents it? I thought the build system was just a set of downloads and put-it-together processes. It can, it has been, and no one seems to care. See http://wiki.laptop.org/go/Build_system http://wiki.laptop.org/go/Building_custom_images http://wiki.laptop.org/go/Puritan http://wiki.laptop.org/go/User:Mstone/Commentaries/Releases_2#Practical_Matters for some historical records of the discussions. Thanks. Re: http://wiki.laptop.org/go/Puritan Tried the puritan on Debian, Thanks for test-run! (and I'm sorry to hear that you got stuck.) stopped at a missing /etc/mock/fedora-9-i386.cfg file sudo wget -O /etc/mock/fedora-9-i386.cfg \ http://teach.laptop.org/~mstone/fedora-9-i386.cfg should fix you up. I'm not sure why the debian packaging of mock is missing this file. but I thought the build had moved on to Fedora 10 now? in the sense that joyride's pilgrim configuration is now pulling from f10 yum repos rather than f9 yum repos. That's just a matter of changing the obvious lines in the compilation's 'bootstrap' (or 'bootstrap.py', in later versions) file. Why would it need Fedora 9 configuration file? Because I told it to construct the build environment out of F-9 materials regardless of what system you happen to be running on. At the time, this seemed like a good idea because I thought it would help achieve more reproducibile results and because I thought it would ease portability issues; now, I've come to think that it's a better idea just to run the software bare in whatever environment happens to be available. Where would I get a Fedora 10 configuration file from? If you want to set up a build environment with f10 versions of tools, then you'd want the f10 mock config (available mock on a fedora system or extractable from Fedora's koji buildserver.) If you want to try making builds with f10 packages, then you can use whatever build environment you like so long as you direct the compilation to pull from f10 package repos: http://mirrors.fedoraproject.org/publiclist/Fedora/10/i386/ Why does the current production build system have this file? For the record, puritan is not the current production build system. Pilgrim is. Puritan is just an expression of some of my ideas about what is required to make a nice build-system for putting software onto XOs. Thanks very much for your bug reports and assistance in improving it, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 2588 - Journal unusable
On Fri, Dec 12, 2008 at 03:27:21PM +1100, James Cameron wrote: G'day Chris, I'll give a partial line of reasoning response ... this is not complete, I'm short of time. Where I said public, I meant developer builds that can be used by other developers. I didn't mean to imply public builds for testing by non-developers. I mean the difference between what a developer does and what a developer releases. That isn't only OLPC originated code, that's also the choice of what RPMs to accept from outside. Accepting lots of RPMs at once is the same as making lots of code change. Why don't you have private build streams? That's what I can do with debxo, for instance ... build on my desktop, test on an XO, and then avoid releasing anything to the public until I've verified that what I've changed actually works. Why can't the build system be replicated so that each developer can test their change before releasing it? What is it about the build system that prevents it? I thought the build system was just a set of downloads and put-it-together processes. It can, it has been, and no one seems to care. See http://wiki.laptop.org/go/Build_system http://wiki.laptop.org/go/Building_custom_images http://wiki.laptop.org/go/Puritan http://wiki.laptop.org/go/User:Mstone/Commentaries/Releases_2#Practical_Matters for some historical records of the discussions. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Free Software Foundation Files Suit Against Cisco For GPL Violations
On Fri, Dec 12, 2008 at 11:52:54AM -0800, Edward Cherlin wrote: On Fri, Dec 12, 2008 at 11:14 AM, John Gilmore g...@toad.com wrote: OLPC is at risk of similar action unless it gets its act together. The project and its customers have skated by on GPL compliance, figuring that we're the good guys, and make halfhearted attempts every once in a while, so we won't get sued. That didn't work for Cisco. Even a public *allegation* by FSF that OLPC is not compliant would have an effect similar to the We're going Microsoft debacle, further alienating the free software development community who OLPC depends deeply upon. OLPC has, by distributing binaries under DRM, without source code, and with minimal notice, hung a sword over its head that just about anybody could unleash. John Some of us are new to one or another part of this issue, and need a bit more background. For some basic background, please see http://dev.laptop.org/ticket/4265 http://dev.laptop.org/ticket/4268 Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Free Software Foundation Files Suit Against Cisco For GPL Violations
On Fri, Dec 12, 2008 at 12:34:18PM -0800, Edward Cherlin wrote: On Fri, Dec 12, 2008 at 12:22 PM, Michael Stone mich...@laptop.org wrote: On Fri, Dec 12, 2008 at 11:52:54AM -0800, Edward Cherlin wrote: http://dev.laptop.org/ticket/4268 That's a lost cursor bug. I assume you meant some other one. Yes, http://dev.laptop.org/ticket/4286, thanks. Sorry for the confusion, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless activation improvements.
On Thu, Dec 11, 2008 at 03:35:53PM -0200, Martin Langhoff wrote: On Thu, Dec 11, 2008 at 3:27 PM, Daniel Drake d...@laptop.org wrote: The primary use case that the Ethiopia team is interested in is automating/simplifying the lease *renewal* which is done at schools, not a warehouse. Lease renewal is -- unfortunately -- missing big chunks in 8.2 . I don't think it's doable for 8.2.1. I'm trying to coordinate an effort (eith Ed's help) to team up with Michael and/or Scott to get this done as soon as 8.2.1 is out, with a target of 9.1 or (if people make a strong case for it) 8.2.2. Martin, If you boot a boot-locked machine with no valid lease, it will search for one on USB, SD, and the mesh. Therefore, while I agree that things would be nicer if leases were also renewed while the machine was running, it's obviously not preventing all use of the activation feature by our deployments. Finally, don't you agree that there are lots of different ways to solve this problem that are within the reach of those deployments interested in pushing our activation technology along faster? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 Bug review meeting - 1 PM EST Friday 12/12/08
On Thu, Dec 11, 2008 at 01:50:58PM -0500, Ed McNierney wrote: OK, someone made a boo-boo. Some time in the last hour or two Trac got updated with 308 new Milestone=8.2.1 tickets. I'd appreciate anyone who's recently made bulk updates reconsider their actions. Thanks! Someone closed the 8.2.0 milestone, which auto-pushed all the tickets in that milestone into the next milestone, which happens to be 8.2.1. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
8.2.1 builds now underway.
Dear world, I pasted together an 8.2.1 build stream by copying the 8.2 build stream on pilgrim.laptop.org, substituting 8.2.1 for 8.2 everywhere appropriate, adding a branch to mock.laptop.org's git repository, and updating the upgrade server's branch-url map. In short, you can now: download 8.2.1 builds from http://pilgrim.laptop.org/~pilgrim/xo-1/streams/8.2.1/ olpc-update 8.2.1-790 (and soon more) view 8.2.1 trac tickets at http://dev.laptop.org/report/35 Other comments: So far as I know, the http://wiki.laptop.org/go/Trac_ticket_workflow is still in force, though I'm certain that suggestions on ways that it could be improved would be more than welcome. I don't know yet what evidence Ed wants to see before accepting packaged changes into this buildstream but I imagine that we'll work it out soon. Regards, Michael P.S. - People who maintain build-announcers -- please update them; they're really helpful! Thanks! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Way to tell if it is an XO
On Wed, Dec 10, 2008 at 09:56:39AM -0200, Marcel Renaud wrote: Thanks a lot for your answers. Yes, I think a shared credentials are the best way. Basically we want to offer a service just for the Xos and are working now on the authentication model. We are going to use webservices with WSShttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss and place a signed key on each XO that is going to use the service, to authenticate with the webservice provider. Marcel, Is it important to keep the credential(s) secret? If so: * why? * for how long? * against what attack(s)? * how? * if (when) they leak, what next? Also, what are the incentives for keeping the credentials secret? for publishing them? Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Wireless activation improvements.
Ed, Kim, Emiliano, and Guadalupe, As described in http://dev.laptop.org/ticket/8976, I've succeeded in repairing wifi-activation to my satisfaction. However, in its present form, wifi-activation only makes use of the mesh and does not attempt to acquire leases over any 802.11b/g networks. Clearly, the wifi-activation technology would be more widely deployable if it could be used with access points as well as with the mesh. Therefore: do we have any interest in developing such a feature? Michael (Previous conversations with Emiliano and Guadalupe suggested to me that LATU would be pleased if we did so.) (Alternately, is LATU interested in developing such a feature with our aid, thereby expanding its skills in this area and potentially gaining access to the feature more quickly?) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: One instance activity
I believe that Browse already works this way. (There are many ways to implement the feature, given the shared data directory available to all instances of an activity.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Clone a whole dir from dev.laptop.org/git ?
How about: scp -r [EMAIL PROTECTED]/git/activities . ? (Or were you saying that you need a real shell on dev?) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Trac tickets for 8.2.1 release mislabeled
My fault; overeager scripting to the rescue. Apologies, Michael P.S. - People interested in improving or reusing said overeager scripting should examine and improve http://wiki.laptop.org/go/Trac_scripting ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wiki.laptop.org upgrade
On Fri, Dec 05, 2008 at 07:11:04AM -0500, Ed McNierney wrote: Michael - Thanks; welcome back! I have been working on the request you made last week, and on trying to have something out this week as I said I would. Good to hear. It's been important to me to ensure I'm reflecting OLPC's position as much as possible rather than simply my own personal opinion, and I've been having conversations to that effect. Absolutely! However, as David rightly points out, if it's going to be a joint statement then it needs to be developed jointly at some point. I'd like to see this happen by circulating a series of progressively better drafts until we're satisfied (or to until we give up). When can we expect a second draft from you? (I wrote a first draft last week and circulated it privately under 'distribute to anyone who should read this' terms.) Thanks again for the help. My (long-term) pleasure. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wiki.laptop.org upgrade
On Fri, Dec 05, 2008 at 01:47:02PM +1800, David Farning wrote: On Fri, Dec 5, 2008 at 10:41 AM, Ed McNierney [EMAIL PROTECTED] wrote: David - I don't understand that comment. What several efforts are you talking about? I don't think there were several efforts to publicize this outage - if so, the scope of those efforts wasn't sufficient IMHO. I was speaking of larger communication issues. Two week ago you said that a statement would be forthcoming about the relationship between Sugar Labs and OLPC. If you had _only_ failed to follow though, that would have been one thing. Instead, you asked one of your employees to to say that a statement would be coming. Thereby putting his reputation, not yours, on the line. For the record, I was the one who asked Ed and Kim to assent to participating in a joint statement; not the other way around. I requested this boon because I think that it's really quite important for the representatives of OLPC and SugarLabs who need to work together on a daily basis to be able to do so under mutually agreeable and agreed-upon terms. Now that I'm back from my visits with friends and family, I'll naturally do what I can to see that this is put to rest as I hoped was going to take place in my absence. Michael P.S. - Ed -- do you have any suggestions or edits that you'd like to make before I start more broadly circulating, in draft form, the points that I suggested to you last week? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Journal2 patches + timings + notes
Scott, I spent some more time with Journal2 today and implemented two minor features; namely, * display of the estimated no. of results - (which helps deal with the display of empty result-sets) * incremental display of results - (which makes it easier to time things). Please review and consider merging my patches, which can be found in http://dev.laptop.org/git/users/mstone/journal2. (That repo contains your journal2 code but none of the big pdfs or screencasts you made since these are very time-consuming to download onto an XO.) I also did a bit of timing on my XO, (see the 'timing' branch), wherein I learned, _anecdotally_ (i.e. with sample-size n=1) that: * startup time seems okay, but the initial query takes about 10s to return results. I have about 300 MB of data indexed under /home/olpc, plus a bit of other junk. (~/.pinot is ~ 35 MB). * it takes around 4.2 seconds to fetch and display each new result * the standard deviation in my sample was large, e.g. about 3.3 seconds. * 19 results were fetched. Notes: * I did not take care to ensure that the indexer had quiesced before my test run. (However, I don't think it was working hard since it did the bulk of the indexing yesterday; today, it only had to deal files changed by my editing and by the test run itself.) * With today's code, the search system is effectively unusable while the indexer is hard at work. * While I have not yet measured it carefully, it seemed to me that full indexing of a basic 767 system + activities _on XO_ may have taken as long as several hours. * With some, but not all queries, I noticed that the query failed because pinot failed to reply to journal2's blocking message sends within the usual dbus timeout of (30? 60?) seconds. I have no idea what was happening inside pinot. Michael P.S. - Thanks for the stimulating vacation entertainment. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: will there be an 8.2 update ?
On Sat, Nov 29, 2008 at 05:48:17PM -0500, Mikus Grinbergs wrote: My reason for asking is that I have a problem with Network Manager 0.6 (ticket #8343). If there is a chance that 8.2 will be improved, I will leave that ticket open. If 8.2's Network Manager will not be updated, then I can close that ticket as 'wontfix', and instead write a different ticket against the newer Network Manager. [What Network Manager 0.7 does/does_not_do needs to be described differently from what Network Manager 0.6 does/does_not_do.] Will a 'fixpack for 8.2' be released ? My rough impression is that if any point releases to 8.2 are made, they will be created at the behest of a deployment via existing country-support procedures. Therefore, I suspect your NM-0.7 ticket will appeal to a larger audience than your 0.6 ticket. However, for completeness, you should also be aware that people with Fedora CVS accounts and access to the joyride drop-boxes can supply new versions of packages for use with 'yum update' for 8.2. Therefore, while I am aware of little specific interest in releasing 8.2-bug-fixes before 9.1, it is technically feasible for interested volunteers to do so of their own accord. Does this help? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Journal2 recipe...
Scott, I've wanted to see Journal2 running on an XO for some time so I: 1. flashed 767 onto my XO and installed git. 2. checked out git://dev.laptop.org/users/cscott/journal2. * downloading and recompressing 80 MB of videos is really slow on an XO; please stick these in a submodule. 3. built myself a pinot rpm with your patches... * checkout git://dev.laptop.org/users/cscott/pinot * saved the diff from your pristine source import commit to HEAD; removed debian-specific hunks * checkout pinot from Fedora cvs and, on the F-9 branch, 'cvs up -r pinot_0_85-1_fc9 .' to return to pinot-0.85-1(f9 is on pinot-0.89) * modified the specfile to apply your cumulative patch * make mockbuild MOCKCFG=fedora-9-i386 * posted the result to http://teach.laptop.org/~mstone/pinot.rpm and installed it by 4. yum install pinot for deps, wget the patched pinot, then 'rpm -Uvh --force' updated pinot 5. as olpc, 'mkdir ~/Journal; cd journal2; python gui.py' This is adequate to bring up a nice journal gui but, unfortunately, searches yield no documents, presumably because none have been indexed. What should I do in order to try out searching? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal2 recipe...
On Sat, Nov 29, 2008 at 09:18:12PM -0500, Michael Stone wrote: Scott, This is adequate to bring up a nice journal gui but, unfortunately, searches yield no documents, presumably because none have been indexed. What should I do in order to try out searching? Casual inspection of http://pinot.berlios.de/ suggested that the main 'pinot' GUI can be used to instruct the pinot-dbus-daemon to start indexing useful things like /home/olpc. In the future, it would be helpful if journal2 came with a sample ~/.pinot/config.xml or if its README instructed users to enable indexing in some other fashion. Unsurprisingly, indexing on the XO is quite slow. More interestingly, though, result retrieval and display is slow as well. Perhaps result display is blocked on result retrieval which is, perhaps, competing with an indexing thread in a single low-priority process? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] G1G1 upgrade question I've received
On Fri, Nov 28, 2008 at 10:21:01AM -0500, [EMAIL PROTECTED] wrote: michael wrote: Just for the record, people using the 'olpc-update --usb' offline update method are probably going to want to use an 8.2 customization stick, e.g. the one archived in the 'gg-767-4.zip' file alongside the g1g1 composite image on download.laptop.org, to get recent activities. i wonder if we could come up with some boilerplate text that could be displayed at the top of our download pages that could explain what each file type is, and how one would use it. i.e., it seems we could make this: http://download.laptop.org/xo-1/custom/g1g1/gg-767-4/ or this: http://download.laptop.org/xo-1/os/official/767/jffs2/ a lot more user-friendly. Sure, but we could more easily pull the necessary links into a wiki page for each release and transclude it into the appropriate release notes. :) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] G1G1 upgrade question I've received
On Fri, Nov 28, 2008 at 10:49:14AM -0500, [EMAIL PROTECTED] wrote: maybe. but a README would be pretty easy. I like READMEs, but I don't want to be in the business of maintaining them. Unfortunately, I also don't really want to give the whole world shell access to download.l.o. Compromise suggestions? (e.g. boilerplate text, redirect-to-wiki, create restricted account, use a cronjob, ...) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
On Fri, Nov 28, 2008 at 04:18:11PM -0500, Chris Ball wrote: Comments welcome. Are there important power management bugs that I've left out? Yes; namely, finding or writing a good technical introduction to the subject of power management as it applies to our software and hardware. Such a document will be invaluable in coming months because, without it, we'll communicate at a fraction of the efficiency we can achieve if we're all starting from the same basic terminology and facts. Perhaps this document already exists and I just don't know about it? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] sugar 0.83 in joyride
On Wed, Nov 05, 2008 at 03:34:14PM +0100, Simon Schampijer wrote: Tomeu Vizoso wrote: On Wed, Nov 5, 2008 at 10:31 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Dear Masters of Joyride, have built updated sugar rpms and they seem to work fine on last joyrides. Marco pointed me out in #sugar that work fine may need some clarification. In fact, the following things are known to be broken currently: - no WAP support (simon is working on this) - no mesh support (sjoerd has done work on this) - rainbow is broken because depends on the old config file being present http://dev.laptop.org/ticket/8850 is the rainbow patch - Michael can you review and release a new rainbow when appropriate? Simon, The patch looks fine to me but I'm headed off to UY, so it would probably be best if someone else did the packaging. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pycon'09 CFP
Folks, Turns out that the Pycon'09 deadline for proposal submission is tomorrow. Are we giving any talks? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: setup for XO development
On Thu, Oct 30, 2008 at 02:55:00PM +0100, Paolo wrote: Hello, I would like to try out the XO software and get started with doing some development. As I am a security guy, I am mostly interested in core development, especially bitfrost/rainbow, and the document store. Music to my ears! If you haven't already found them, please check out http://wiki.laptop.org/go/Rainbow and http://wiki.laptop.org/go/Security There are a bunch 'TODOs' on those pages where your assistance would be most welcome, or if you prefer, you might suggest some topics that interest you. I expect an emulated environment would be a good choice for this type of development. Actually, for a variety of reasons, I'm working quite hard to make rainbow usable on stock linux machines like those represented by Debian and Fedora chroots. Therefore, if you can show me interesting rainbow patches that work in those environments, I'm quite likely to take them. Regards, Michael P.S. - One long-standing request which might interest you is to integrate rainbow into the sugar-jhbuild system used by many sugar developers so that they conduct their regular development in an environment more similar to that found on-XO. A nice side-benefit of this task is that you would become well-equipped to participate in further sugar-related and tinderbox-related development in the natural course of fulfilling the task. P.P.S. - What are you thinking about document storage? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
