UsernameNumber
September 10th, 2013, 10:50 PM
Hello all,
I'm working with a Kenya-based non-profit (tunapanda.org) that uses OSS to provide computing resources to schools where bandwidth is either nonexistent or prohibitively expensive. We provide a customized Edubuntu/LTSP setup which will host local versions of useful online resources like Kahn Academy (via ka-lite), Wikipedia (via Wikipedia For Schools), etc.
I'm serving as a sort of tech/Linux advisor for them, but not only have I never maintained a system with these particular challenges (details below), my knowledge is a bit out of date, and most of my experience is on the Red Hat side of things, so I'm still getting used to and learning about a lot of the Debian-isms over here.
My question is, how would you manage updates and configuration changes on a server that:
Is not physically accessible to you.
Has user data (so you can't just reinstall the whole system)
Does not have net access (local reps can download software to a USB drive and then bring it to the school).
Does not have much in the way of local technical expertise (so deployment would need to be pretty simple).
So far, the idea that seems most feasible is to do one of the following:
If all the user and server-specific data can be kept on its own partition(s) then maybe we could just do a full re-install for every update, using a preseed that re-uses, say, /home and /usr/local without formatting them. This is pretty easy with Kickstart, but I haven't tried it with a preseed file yet.
- or -
Set up the initial deployment to use a local apt repository containing packages that deploy our customizations, then deploy updates by...
Creating/updating packages that make any needed changes, and storing them in a remote repo
Local person downloads the repository data to a USB drive
Repo data is rsync'd from the USB drive to the local dir on the server
apt-get update && apt-get upgrade
Not having worked with .deb files much, I'm a bit concerned about conflicts. What if, say, we need to make changes to a monolithic config file (on without a convenient conf.d directory)? Is there a trick to avoid complications when the file is owned (and likely to be updated) by another package?
Anyway, before I devote too much time and effort to researching these options, I wanted to see if anyone else has ideas for what to try, just in case there's a magic bullet out there that I haven't heard about (has anyone used Chef or similar in a situation like this?).
Thanks!
I'm working with a Kenya-based non-profit (tunapanda.org) that uses OSS to provide computing resources to schools where bandwidth is either nonexistent or prohibitively expensive. We provide a customized Edubuntu/LTSP setup which will host local versions of useful online resources like Kahn Academy (via ka-lite), Wikipedia (via Wikipedia For Schools), etc.
I'm serving as a sort of tech/Linux advisor for them, but not only have I never maintained a system with these particular challenges (details below), my knowledge is a bit out of date, and most of my experience is on the Red Hat side of things, so I'm still getting used to and learning about a lot of the Debian-isms over here.
My question is, how would you manage updates and configuration changes on a server that:
Is not physically accessible to you.
Has user data (so you can't just reinstall the whole system)
Does not have net access (local reps can download software to a USB drive and then bring it to the school).
Does not have much in the way of local technical expertise (so deployment would need to be pretty simple).
So far, the idea that seems most feasible is to do one of the following:
If all the user and server-specific data can be kept on its own partition(s) then maybe we could just do a full re-install for every update, using a preseed that re-uses, say, /home and /usr/local without formatting them. This is pretty easy with Kickstart, but I haven't tried it with a preseed file yet.
- or -
Set up the initial deployment to use a local apt repository containing packages that deploy our customizations, then deploy updates by...
Creating/updating packages that make any needed changes, and storing them in a remote repo
Local person downloads the repository data to a USB drive
Repo data is rsync'd from the USB drive to the local dir on the server
apt-get update && apt-get upgrade
Not having worked with .deb files much, I'm a bit concerned about conflicts. What if, say, we need to make changes to a monolithic config file (on without a convenient conf.d directory)? Is there a trick to avoid complications when the file is owned (and likely to be updated) by another package?
Anyway, before I devote too much time and effort to researching these options, I wanted to see if anyone else has ideas for what to try, just in case there's a magic bullet out there that I haven't heard about (has anyone used Chef or similar in a situation like this?).
Thanks!