On Tue, 13 Apr 2010 19:13:13 +1000 Brendan Simon <bren...@brendansimon.com> wrote:
> On 13/04/10 5:33 PM, Neil Williams wrote: > > On Tue, 13 Apr 2010 09:13:19 +1000 > > That gets recursive very, very quickly. I don't know of any maintainer > > scripts that are truly architecture-neutral because even a shell script > > ends up calling binary executables to do the work. How much can you > > realistically do in a POSIX shell without calling 'cp', 'ls', 'grep', > > 'echo', 'mv' or 'ldconfig'? What about the shell interpreter itself? > > That's compiled. > > > Most of these are generic tools just compiled for a particular > architecture. Can't the host tools be used to perform these activities > (ehco, mv, cp, etc). There's a lot of fiddling around getting the paths set correctly, otherwise 'rm -rf /etc/foo/' in a maintainer script will be a world of pain on the desktop system. (I've tried to rescue a desktop system after a test of a script to do this kind of thing actually removed /etc/ instead of ./etc/ - it is NOT fun.) That's why it will be easier to use Baked and do only the work you specifically require from outside the foreign chroot using your normal native shell or whatever scripts/programs you want to use, as a multistrap hook. If it's called via multistrap, it will be easy to set the required prefixes and paths and ensure that the right files are modified. If you leave it to the maintainer scripts themselves, you will get unexpected results because they are expecting / to be / not /dir/ and as it's a foreign chroot, you cannot let the scripts do things in / without resorting to an emulator. > But some embedded systems are quite fat (have lots of memory and storage > -- e.g. routers, firewalls, etc), and are quite suitable for grip packages. In which case, those are likely to need complex config. Using Grip directly means retaining compatibility with Debian or unexpected things will break. Compatibility with regard to dpkg and apt means retaining most of the functionality of the maintainer scripts - or at least providing no-ops for the various tools that you don't want maintainer scripts to try to run. > > The other solution is a prefix - replace the interpreter location with > > one outside the foreign environment. The problem then is just when and > > how do you decide which queries and instructions need to get > > information from which environment? Could easily end up configuring the > > foreign system to work like the desktop that created it instead of the > > embedded device it needs to be at boot. > > > Does this mean using the host system tools and/or the host system > "environment" ?? That's the issue - the scripts will not be able to reliably tell and could end up reading or writing config to/from the wrong one. A maintainer script removing something in /etc/ instead of ./etc/ might be easy to notice - a slight modification of a file already in /etc/ and ./etc/ could be much harder to debug. Maintainer scripts are adept at making subtle changes to configuration files, that's why they exist. Second-guessing all of them is HARD. > > No maintainer scripts can be safely allowed to run until after first > > boot - it doesn't matter how they are written. > > > Why not ?? > > Couldn't the 'first boot' be mocked on the host system somehow ?? I'm > _not_ talking about processor/system emulation (e.g. qemu). If you're dealing with a very fixed package set then maybe you can (hence Baked) but Grip involves using packages that are binary-compatible with Debian and that is hard to anticipate. (Moving target etc.) It all depends on how many packages are involved and whether you need to allow for future upgrades. If yes, use Grip and try to work around the issues of a first-boot configuration step. If no, set the configuration manually and consider something like Baked. (Basically, that means telling me you'd like Baked to be available. I can get it into the next release of emdebian-grip.) > >> I would like someway to configure these on the host and have them set on > >> the target, preferably with the packages believing they are already > >> configured, or as an alternative, configuring using a known set of > >> values (pre-seed ??) > >> > > Yes, pre-seeding is the answer. Create the configuration outside - > > using a native chroot that can be automatically configured as close as > > possible to the desired config and then tweaked to resolve corner cases > > - and then just dump that config onto the foreign filesystem. > > > Phew. > Does this also solve the 'first boot' issue above ?? Emdebian Baked will, yes. We need a "at-first-boot-run-this" script for Grip - it's been an idea for a long time but nobody has written one yet. Having packages believe they are configured is simply telling dpkg to set the status files that way. Multistrap can do that (or it can if no maintainer scripts exist in the packages.) > For a networking device, things like a shell interpreter, an snmp agent, > an ssh server, a web server, etc. > > e.g. A 'fat' networking device may have: libc6, bash, coreutils, > net-snmp, openssh-server, openssl, apache. > > e.g. A 'thin' networking device may have: uclibc, busybox, net-snmp, > dropbear, appweb. OK. I'm expecting that networking devices like that will (generally) fit the criteria for Baked - i.e. that once produced, the device itself will not need or expect to install new updates via dpkg or apt and will therefore not want maintainer scripts installed. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgpt3QDI9evxq.pgp
Description: PGP signature
