On Thu, Feb 19, 2009 at 3:37 PM, Chris Ball <[email protected]> wrote: > Sorry about that, I should have written this up.
Thanks for telling more :-) > The change here is the addition of an "xs-upserv" script, and it's > probably not useful for the XS -- you already have an xs-rsync setup > that does the same thing. We wrote it while in UY for their non-XS > school server, as a quick script to turn any machine into an update > server: it takes a directory tree with a build per directory, creates > an rsyncd.conf that exposes each build, and launches rsyncd with the > new config to serve the builds. hmm hmmm. Maybe we can include it anyway, and set a "canonical" dir where it scans for trees. In fact, I think it already unpacks anything it finds in /library/xs-rsync/xobuids-packed/ . The rpm can probably install and Just Work with alien, I made sure all its deps are in Debian. Was there a strong reason to avoid xinetd? Strong reason to avoid fakechroot? (Assuming you removed them for ease-of-coding, I'd keep them for unified maintenance...) > At the time, we needed something to prove that UY's modified 767 build > could be upgraded to by their modified 649 build using their local > school servers, without the assumptions made by the xs-rsync setup. Assumptions being the "insert-usb-disk" triggers? Or something else? cheers, m -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
