Re: dnshash update.

2011-04-16 Thread Michael Stone
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?

2011-03-23 Thread Michael Stone
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

2011-03-20 Thread Michael Stone
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.

2011-02-18 Thread Michael Stone
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

2011-02-13 Thread Michael Stone

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

2011-01-29 Thread Michael Stone
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

2010-10-07 Thread Michael Stone
 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

2010-09-06 Thread Michael Stone
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

2010-07-24 Thread Michael Stone
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

2010-07-07 Thread Michael Stone
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: [Sugar-devel] Activity packaging

2010-07-06 Thread Michael Stone
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.

 XO and SoaS distributions are configured for sudo with no password.

Yes. However, Uruguay does not maintain this configuration choice.

 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.

Rainbow, on the other hand, has seen a major new release, feature development
that spurred new work in general Linux sandboxing, and is now available in more
distributions than ever before thanks to dedicated support by folks like Luke,
Sascha, and Jonas. 

Finally, if rainbow itself now receives little day-to-day attention, this is
because it mostly does what its authors require and it does it well enough not
to require their continued hand-holding. 

 and nobody volunteered to work on it. 

If you check the dates carefully, you'll find that most of my recent work on
rainbow and rainbow/sugar integration has occurred while I was on vacation from
my real job. So please do count that as volunteer hours.

 The bottom line is that *nowadays*, any activity can escalate root
 privileges.

Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then
we will all rue the day when we had the opportunity to make it safe and chose
not to.

 A non-privileged account can already effectively do anything that a spammer
 would like to do.

And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch?

(Or have you a better approach?)

 Even in a Rainbow-enabled environment, privileged vs unprivileged
 installation isn't by itself the source of security issues. Packages
 could easily be checked to ensure that all bundled files are within a
 specific path, like we currently do with the zip files. Post-install
 scriptlets can be disabled.

I am still much more satisfied with the approach taken by 0install. [2]

Regards,

Michael

[1]: Except by accident, like with GNOME and Sugar today.

[2]: Thanks again, Aleksey, for pushing this work forward and for all the
improvements you've already contributed back to 0install to make this work
better for us!

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [IAEP] Gnome vs Sugar -- The judgement day

2010-06-25 Thread Michael Stone
 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

2010-04-18 Thread Michael Stone
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

2010-04-18 Thread Michael Stone
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

2009-12-27 Thread Michael Stone
 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.

2009-12-21 Thread Michael Stone
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.

2009-11-28 Thread Michael Stone
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!

2009-11-23 Thread Michael Stone
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

2009-11-04 Thread Michael Stone
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

2009-11-04 Thread Michael Stone
 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-08-27 Thread Michael Stone
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

2009-08-27 Thread Michael Stone
 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

2009-07-12 Thread Michael Stone
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

2009-07-10 Thread Michael Stone
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

2009-07-08 Thread Michael Stone
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

2009-07-05 Thread Michael Stone

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?

2009-06-30 Thread Michael Stone
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

2009-05-29 Thread Michael Stone
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.

2009-04-12 Thread Michael Stone
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.

2009-04-08 Thread Michael Stone
 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

2009-03-17 Thread Michael Stone
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

2009-03-17 Thread Michael Stone
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?

2009-03-02 Thread Michael Stone
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?

2009-03-01 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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?

2009-02-24 Thread Michael Stone
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

2009-02-18 Thread Michael Stone
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?

2009-02-18 Thread Michael Stone
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

2009-02-17 Thread Michael Stone
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

2009-02-10 Thread Michael Stone
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

2009-02-06 Thread Michael Stone
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

2009-02-05 Thread Michael Stone
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

2009-02-04 Thread Michael Stone
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

2009-02-03 Thread Michael Stone
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

2009-01-29 Thread Michael Stone
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

2009-01-29 Thread Michael Stone
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.

2009-01-25 Thread Michael Stone
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

2009-01-24 Thread Michael Stone
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.

2009-01-22 Thread Michael Stone
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.

2009-01-20 Thread Michael Stone
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.

2009-01-09 Thread Michael Stone
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

2009-01-06 Thread Michael Stone

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

2009-01-06 Thread Michael Stone
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

2009-01-06 Thread Michael Stone
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

2009-01-06 Thread Michael Stone
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

2009-01-06 Thread Michael Stone
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

2009-01-05 Thread Michael Stone
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

2009-01-05 Thread Michael Stone
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

2009-01-05 Thread Michael Stone
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.

2009-01-02 Thread Michael Stone
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

2008-12-31 Thread Michael Stone
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

2008-12-25 Thread Michael Stone
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

2008-12-25 Thread Michael Stone
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

2008-12-24 Thread Michael Stone
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

2008-12-24 Thread Michael Stone
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

2008-12-23 Thread Michael Stone
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

2008-12-23 Thread Michael Stone
On Tue, Dec 23, 2008 at 11:46:09AM -0800, Edward Cherlin wrote:
On Tue, Dec 23, 2008 at 11:26 AM, Michael Stone mich...@laptop.org wrote:
 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.)

Would it be possible to apply these tools to creating LiveCDs and
qemu-ready image files? I certainly don't want to add to the burdens
of over-burdened staff, but can some of us volunteers do that part? I
ask in large part because recent LiveCDs and image files don't work on
my computer.

With some work, yes. (The QEMU images are much easier than the livecds
since you only have to make it work on one kind of hardware and since
both programs already have support for generating QEMU images.)

Whether it is wise to use them for this purpose is a separate question
-- and, in a sense, a religious war.

Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Deployment image customization

2008-12-23 Thread Michael Stone
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.

2008-12-22 Thread Michael Stone
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.

2008-12-22 Thread Michael Stone
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

2008-12-17 Thread Michael Stone
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

2008-12-15 Thread Michael Stone
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

2008-12-13 Thread Michael Stone
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

2008-12-12 Thread Michael Stone
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

2008-12-12 Thread Michael Stone
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

2008-12-12 Thread Michael Stone
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.

2008-12-11 Thread Michael Stone
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

2008-12-11 Thread Michael Stone
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.

2008-12-11 Thread Michael Stone
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

2008-12-10 Thread Michael Stone
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.

2008-12-10 Thread Michael Stone
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

2008-12-09 Thread Michael Stone
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 ?

2008-12-09 Thread Michael Stone
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

2008-12-09 Thread Michael Stone
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

2008-12-05 Thread Michael Stone
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

2008-12-04 Thread Michael Stone
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

2008-12-01 Thread Michael Stone
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 ?

2008-11-29 Thread Michael Stone
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...

2008-11-29 Thread Michael Stone
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...

2008-11-29 Thread Michael Stone
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

2008-11-28 Thread Michael Stone
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

2008-11-28 Thread Michael Stone
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.

2008-11-28 Thread Michael Stone
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

2008-11-06 Thread Michael Stone
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


  1   2   3   4   5   >