19

I am writing a script for a unattended install of a package that is in our repo, it is a software package with one of Debian's marked config files. Is there any option that I can pass to apt-get/aptitude so that it accepts the new config files?

Basically I need an apt/aptitude equivalent of dpkg --force-confnew

I need to answer the following question posed while apt-get is installing with a Y


Configuration file ``/opt/application/conf/XXX.conf`'

==> File on system created by you or by a script.
==> File also in package provided by package maintainer.

What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D     : show the differences between the versions
  Z     : background this process to examine the 

The default action is to keep your current version.

Additional Info:

Also, I am passing the sudo password in a pipe to execute the command

echo "mysudopass"|sudo -S apt-get mypackage

This is flagging an error in installation when the installation is at the config interactive phase.

I am on Ubuntu 10.04
apt version: apt 0.7.25.3

Why I cannot use dpkg: These Debians are to be installed from Repo and I don't have local Debians on my machine

21

You can pass dpkg parameters to apt-get like this

apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confnew install pkgname1 pkgname2 ...

With --force-confdef if old config files still exist, they won't get overridden. So you probably won't use it, I'm just documenting it for others.

sudo will not ask for a password if you negate the authenticate option for the user or add the NOPASSWD tag in the specific entry. e.g.

someuser ALL = NOPASSWD: /usr/bin/apt-get
6

You could try the following:

export DEBIAN_FRONTEND=noninteractive
apt-get -q -y install whatever-2

But note that this has implications, like empty default passwords (maybe you'd like some deployment/config tool like puppet, chef, fabric...?).

See sudoers(5) about how to allow password-less sudo invocations.

2

Alternatively to what forcefsck suggested I suggest you add this into APT settings so you are not required to add these hard-to-write options all the time. Also, this would be helpful for unattended upgrades if you have these setup.

Create /etc/apt/apt.conf.d/71debconf file to have the following content:

Dpkg::Options {
  "--force-confnew";
};

Note (from Geoff): this change would be a global change. If you have other packages on the system that you want to get unattended upgrades but have also manually configured, this would not be the appropriate solution.

  • This may be a good option, however it's important to note that this would be a GLOBAL change. If you have other packages on the system that you want to get unattended upgrades but have also configured, this would not be the appropriate solution. – Geoff Oct 17 '18 at 1:45
1

In addition to the other answers, you may also have to set the environment UCF_FORCE_CONFFNEW=1.

E.g. openssh in debian stretch uses ucf (not debconf) in it's openssh-server/openssh-7.4p1/debian/openssh-server.postinst to ask about the config file. (You can see the openssh-server.postinst by using dget against http://security.debian.org/debian-security/pool/updates/main/o/openssh/openssh_7.4p1-10+deb9u4.dsc)

We've had to use all the tricks on this page in addition to being liberal users of debconf preseeding.

We did however stop just short of export DEBIAN_FRONTEND=noninteractive because we want to know if we missed something (that could be important). Our use case is an operator starting the operation. The upgrade is expected to be non-interactive, but the operator is present if something goes wrong and a dialog presents itself. Your situation may be different.

But export DEBIAN_FRONTEND=noninteractive is your proverbial sledgehammer.

Just beware: Setting -o Dpkg::Options::=--force-confnew and/or UCF_FORCE_CONFFNEW=1 means that all config files from installed packages revert to the upstream ones. So e.g. in the case of openssh-server, your /etc/ssh/sshd_config will be reset to factory settings. And e.g. PermitRootLogin=yes will be removed. But of course you don't use that, so you'll be fine! ;-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.