olpc-update wipes out persistent activity directories

[bert]

After olpc-update from 305 to 319, the /activities directory only had empty subdirectories. The persistent files in $SUGAR_ACTIVITY_ROOT/data are gone.

[bert]

IMHO this should be an Update.1 blocker ...

[cscott]

cc'ing mstone. I know nothing about this. If it is not in /home, it is not going to be preserved, by design.

[bert]

Replying to cscott:

cc'ing mstone. I know nothing about this. If it is not in /home, it is not going to be preserved, by design.

An argument could be made that the persistent activity data should reside in /home ...

[mstone]

While we clearly could store rainbow's spool inside /home or /security, both of these directories have pre-existing semantics that differ from what we want. Why do you prefer to change the semantics of one of these directories instead of inventing a new directory?

[mstone]

cscott points out that major hacks would be required to olpc-update in order to get it to preserve /etc/passwd and /etc/group. Consequently, we need to save the Rainbow-supplied component of these files elsewhere on disk. The most straightforward 'good' implementation seems to be to write an NSS module that will supply this information.

I'm presently intending to finesse the data storage issues here by storing a fixed array of records in a sparse file. This way, POSIX locking can be used for safe concurrent updates and read-only mmap's can be used for efficient reads.

[cscott]

As a kludge for update.1, we could consider just logging all additions to a file in /security and adding a snippet to olpc-configure which will replay the log on upgrade. /activities could then be moved to /security/activities easily.

[cscott]

where by "additions" above I mean "additions to /etc/password and /etc/group".

[mstone]

joyride-1508 contains versions of rainbow, sugar-datastore, and olpc-utils which give us a working build (custom activity installation, datastore resume, network access all work) and which preserve or regenerate rainbow's spool information across updates.

It may still be worth pursuing the NSS module scheme since this will improve the efficiency of olpc-update; however, I am content that we have a workable solution to this bug for Update.1.

Special thanks are due to Bernie who was extraordinarily helpful in producing and qualifying these packages, and to Scott for suggesting this implementation strategy.

Reassigning to ApprovalForUpdate, where these packages can be vetted for as long as seems wise.

[dgilmore]

nothing will go in without specific versions. I will not guess at the versions.

[mstone]

'The versions of rainbow, sugar-datastore, and olpc-utils contained in joyride-1508' is a perfectly precise description of packages; however, I support your desire to be picky so I suggest: rainbow-0.7.6-1

Bernie, Tomeu: please indicate what versions of sugar-datastore and olpc-utils should be used.

[bernie]

At least these:

sugar-datastore-0.7.2-2 olpc-utils-0.63-1

[tomeu]

Note that sugar-datastore-0.7.3-1.olpc2 is already tagged for update.1

[bernie]

olpc-utils-0.63-1 is also in update.1-677. Can we close this bug then?