[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg divert in preinst scripts

On Tue, 13 Apr 2010 19:13:13 +1000
Brendan Simon <Brendan@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.


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

Attachment: pgphfIDmUv2y6.pgp
Description: PGP signature

Reply to: