m_stone> greebo: note that there's some ability to deploy updates en masse w/ olpc-update greebo> m_stone, practically how does one do that centrally? I can see how to do it from the laptop easily enough. Is there any way planned to _push_ updates out? m_stone> greebo: yes, it's already implemented even. rather, the laptops poll for updates but it's the same effect. greebo> For a real implementation I was thinking of pointing all laptops to our own repo of the sw, and then setting them all to check for updates daily and autoupdate. Then we could just put the up to date stuff in our repo after we can test locally and control the updates somewhat. m_stone> greebo: want an explanation of how it works? greebo> m_stone, please :)
m_stone> okay. on your laptop is a program called olpc-update-query ( http://tinyurl.com/64cpbj ). cron and NetworkManagerDispatcher both run that periodically: ( http://tinyurl.com/5qcshl ) and ( http://tinyurl.com/6mahou ). olpc-update-query's job is to rate-limit queries. olpc-update-query, when it runs, executes something called the theft deterrence protocol. greebo> ok. and they see the up to date stuff online, but do they install them? I've run the software update app and it requires me to actually install the updated apps hence my confusion.
m_stone> the relevant section for you is the 'update' field of the server response. (what's happening here is the client tries to connect back to 'http://antitheft.laptop.org/antitheft/1' ( <-- note lack of https for ease of dns tricks ) and asks, among other things, for instructions on what build to update toward ). the requests include the laptop's SN so they can be answered on a per-laptop basis.
Quozl> m_stone: for a "locked" laptop what antitheft.laptop.org (or alias) provides has to be signed. therefore greebo in using "unlocked" laptops will be able to provide updates using an alias. m_stone> Quozl: hang on. the response from antitheft.laptop.org is cryptographically verified by code here: http://dev.laptop.org/git?p=users/cscott/leases;a=tree
m_stone> at present, this code works with a hardcoded list of keys: ( http://tinyurl.com/569w3m ). greebo can modify this using mechanisms I'll describe in a few minutes. (the OATS key is the relevant one; it is threaded through the code from here: ( http://tinyurl.com/6lo5ba ). anyhow, if the signature check passes, then olpc-update-query invokes 'perform_update' on the data it received. that data include both a statement of what build should be installed as well as a collection of urls for where to get it.
greebo> right, what if a proxy username and password is required to get out to the internet? I have the proxy details in the server, and the users get internet browsing once they put their username and password into browse. if I put the username and password into the XS once a month to allow straight through traffic then that could be a cute way to artificially control updates without changing anything on the laptop m_stone> no support is presently provided (that I know of) for proxying configuration. (that might be a good thing to file a bug requesting, though we're unlikely to get to it for 8.2.0). however, if you're willing to play DNS tricks, then you should be able to configure the system so that it's unnecessary and so that it pulls the builds directly from the XS. martin wrote some software called xs-rsync to make it easier to host builds on the xs. (upgrade-server would work fine too but may be a bit more complicated than what you want) greebo> yeah cool, I think I'll stick with what I'm thinking which is to simply put the username and password into the XS when I want to update them, and then leave it open for a day or two to allow for the laptops to update
greebo> just to clarify, that is for system updates right? and hence the differentiation between the applications update m_stone> greebo: yup. (though 8.2.0 has some smarts for application update as well)
greebo> so the laptops would upgrade from 760 to 762 when it comes out automatically if connected online? m_stone> greebo: they could be made to do that, with some ingenuity. morever, the system can be made to preserve itself using the custom-rpms setup. _and_ you get to use the rollback buttons if anything goes wrong. so basically, since we'd like to make this easier to use and since you sound like you might be willing to try it out for us, we may be able to help one another out. :)
greebo> m_stone, just to clarify again, the xo update script actually installs updates to the xo? m_stone> the olpc-update-query program will call perform_update which runs the same python code that the olpc-update commandline wrapper uses. then scott's sugar update-control-panel entry can be used to update activities. in 9.1, there should be even better delegation features that will make the networking configuration (for updating, anyway) much easier. greebo> m_stone, cool, let me know what you want me to do. Happy to test stuff. I have some pretty complicated networks I'm working in.
greebo> m_stone, when I run olpc-update-query on my laptop it doesn't do anything. When I run it with -v it just sayd questions the antitheft url. Is there anything else it should be doing? m_stone> I don't think it's supposed to do anything -- most of the time. remember that it's intentionally non-deterministic. (though there are some arguments that it can receive that might change that?) ...basically, the system has its security goals and it strives to reach them.