Recent olpc-utils fixes

Martin Langhoff martin.langhoff at gmail.com
Wed Nov 25 10:49:39 EST 2009


On Wed, Nov 25, 2009 at 3:31 PM, Daniel Drake <dsd at laptop.org> wrote:
> Thanks for looking at olpc-utils. 2 comments:
> olpc-configure: use /etc/olpc-configure/devkey.html as template if
> exists (dlo#9731)
>
> Just curious, why is a .tmp file used here?

Atomicity. echo foo > final_path has some nasty results if yoir
process dies or errors out for any reason. Writing to a tmpfile
ensures that you only overwrite a potentially existing file once
you've completed writing to it.

Not that I think _this_ codepath is specially vulnerable. But I am
changing this block of code and the added atomicity is a good thing.

(Note: for real failsafe atomicity in the face of POSIX, I should add
a call to sync. But after the ext4 fallout, rationality is prevailing
and the semantics of data=ordered are here to stay.)

> olpc-configure: separate upg from firstboot, trigger activity upg
> (#9747)
>
> To fix #9747 I was planning just to remove that code altogether and not
> pop up a dialog. It was added in anticipation of G1G1 but (IMO) was
> never useful even for those users. For deployment users its just
> confusing, and we aren't preparing this OS release for anyone else.

I thought of removing it too, but looking at _why_ it was put in
place, the rationale behind having it in the first place (#7495) does
hold water: if you are managing a large deployment with OATS-triggered
upgrade ran by olpc-update, the activities in ~/Activities will need
an upgrade.

And olpc-configure is the only bit of code that can differentiate a
first install vs an upgrade. After it's run

This 'fix' is a step in the right direction. If you think of the
workflow for deployments there are things we could improve in the rest
of the machinery:

 - olpc-update should be able to include Activities as well. Maybe
just .xo files in a directory that are picked up, installed and purged
on first boot.

 - The trigger to update should wait until we are connected to a network

 - The trigger to update should just get the job done -- if we are on
a network and an activity server is available, block the UI and get
the job done.

but we have what we have. One fix at a time.

> Other things in that commit look a bit suspicious.
> I think it will reintroduce the problems with SSH files because
> update_home_permissions_to_v6 is run after set_home_permissions

Ugh, you're right. Fix coming.

> And this seems contradictory:
>
> + if [ -z "$olpc_home_version" ]; then
> + ### upgrades only

Of course -- I actually fixed that to be -n on the XO where I was
testing and then forgot to copy it back to the git repo copy. ID10T
error. Fix coming.

*Thanks* for the review.

> My vote would be to just remove the .sugar-update creation

I hope I can convince you that the need behind it exists :-) It was
just implemented a bit too broad.


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



More information about the Devel mailing list