Hello, we're about to migrate a set of workstations (ubuntu 10.04 LTS) to a new kerberos/LDAP setup. Basically, this requires the installation of some required deb packages and to copy some new .conf files over the original ones.

We made a deb package having these "features":

1. requires the needed other packages as dependencies
2. backs up original conf files
3. copies the new conf files to the right places (i.e. /etc/krb5.conf, /etc/ldap.conf)

The problem is: apt-get complains because the deb is "touching" files owned by other packages (kerberos, ldap, etc.). Therefore, the only way to skip this check is either to force apt-get to proceed or using the "replaces" directive in the deb control file, specifying the clashing packages. Something like this:

The "replaces" directive is working but basically forces my package to steal the files originally used by nscd, openssh-client, sudo-ldap, libldap-2.4-2, dbus, etc.
If I remove my package, the files will be erased as well.

Any suggestion? Is the .deb approach feasible? We'd like to go for the deb file since it's easily deployable and doesn't require any major user intervention.

Thanks!

I wouldn't do it this way. Stepping on other packages seems frought with issues.

The way I'd do it is, rather than try to pack everything into one package, I'd write myself a script that installs the new deb packages individually, then copies the .conf files from a remote machine.

This still gets you the one-step install you're trying to accomplish by bundling it all in one package, without the disadvantage of breaking your package manager's ability to manage certain packages.

1 members found this post helpful.

Hi, thanks for the suggestion. I agree with you, actually. It's just a pity I can't modify the config files without taking ownership of them.
At the moment we're using a script similar to the one you described but, instead of pulling the files from a remote location, they're incorporated into the tar archive the script is shipped with. Your solution has its advantages (reusable script, conf files "always fresh" at each run).

What about mixing the two things? Shipping a deb that requires the dependencies and contains the conf files in a tar.gz, this one extracted by the deb postinst script. Any possible drawbacks I'm not aware of?

Tar is fine, too. When you get right down to it, you're doing two processes:

- Install packages
- Overwrite config files

The installation process is going to be predetermined, but there are a million different ways you could overwrite a file, so whichever one works for you, go for it.

I'm not familiar with deb, since I work on an rpm-based distro, and I don't even build my own rpms, so maybe I'm completely wrong... but I think you might be causing yourself some supportability issues by combining Kerberos and LDAP into a new package that you own. How does that affect you if you just need a code update for one or the other?

Yes, that's exactly what worries me most. I think apt-get will bug the user when she's upgrading/updating next time, since it finds out that the files have been modified (!= MD5). At this point, apt-get should ask her to choose how to proceed (namely: overwrite or keep the file?). This is acceptable, I guess.

In which case, I'd say it's better to let the package manager do its thing, so rather than trying to bundle those packages together in your own custom package, just install them individually. This takes a lot of human errors out of the equation. Presumably, you'd want to automate deployment of patches, and you'd have to set overrides for that. Also, you might need to install some other software later that requires Kerberos, and this allows that dependency to be resolved correctly for you, because you may or may not be on the correct level for that dependency, and you'd have to dig around to verify it, where normally apt-get would be able to tell you. The more you have to override the package manager's sanity checking, the more chance you have for your system to go insane.

If you were creating a new package because you had to modify source, or install from source, that'd make sense. But since the software is already in a neat deb package, it's best to take advantage of that.

In the end I've gone with this solution: a DEB package containing the default deb control files and shipping with a tar.gz with the configuration files I want to overwrite/update on the target systems. Some more details:

control: specifies the package details and the dependencies (listed under "pre-depends"), so apt-get can take care of installing them;
preinst: backup configuration files before doing anything;
postinst: move to root dir and extract the conffiles.tar. After this, remove the tar file from the hard disk and notify the user via notify-osd (reboot required, please!);

The only file the DEB archive contains, toghether with the files mentioned above, is the conffiles.tar.

I think it would do the job without bugging the apt-get dependency system too much (the package is just dependent by other system packages and does not replace other packages).