5

This may seem like a question asked, but I have yet to find anything that works and I start suspecting it may be a bug in apt-get…

So, I have a python installer wrapping around apt-get, whose relevant functional basically amounts to:

echo -e "answer1\nanswer2\nanswer3\n" | DEBIAN_FRONTEND=teletype apt-get install -y foo.deb

This works fine! In a container… Yesterday first actual end-user run this script in a graphical Ubuntu under tmux, and this broke: installation hangs waiting for user to answer questions. It does accept user input, but the user isn't supposed to answer these, installer is. But graphical Ubuntu apt-get outright ignores stdin.

What I tried so far (from what I remember):

  1. DEBIAN_FRONTEND with backends readline, teletype, text. None of them make apt-get receive answers from stdin. They do kinda work, because the previous problem was graphical Ubuntu triggering TUI — setting the variable to either at least bypasses that.
  2. DEBIAN_FRONTEND=noninteractive: this just randomly answers questions, which isn't desired either.
  3. Looking in both DEBIAN_FRONTEND docs and apt-get docs for keyword stdin. No avail. As a matter of fact, it even lacks some DEBIAN_FRONTEND values (it at least doesn't mention teletype, even though apt-get complains you need to use it instead of readline when in a script)
  4. Asking AI, obviously. It gave some involved PTY changing code for python with incorrectly scoped vars, and I dropped the ball. It has to be something simple; well, unless I really just stumbled upon apt-get bug here and the teletype ought to be enough.

How to reproduce

postfix is one small package with a question, so assuming it either isn't installed or purgeed away, the:

echo -e 'No configuration\n' | DEBIAN_FRONTEND=teletype apt-get install -y postfix

…inside graphical Ubuntu hangs waiting for user to type-in the "No configuration".

Improve this question

1 Answer 1

Reset to default
10

This doesn’t answer your question as summarised in the title, but for well-designed packages that use debconf for configuration, the correct way to pick answers non-interactively is to set them ahead of time (“pre-seeding”). For postfix, that’s:

debconf-set-selections <<<"postfix postfix/main_mailer_type select No configuration"

The parameters are, in order, the package name, the configuration key, the configuration type, and the value. To find the appropriate values to give, you need to install the package or at least extract its contents, and look at /var/lib/dpkg/info/postfix.templates (replacing postfix as appropriate). This will show all the available configuration settings with their types and default values. In this instance:

Template: postfix/main_mailer_type Type: select Choices: No configuration, Internet Site, Internet with smarthost, Satellite system, Local only […] Default: Internet Site […]

The default value is “Internet Site”, so a non-interactive setup will use that value. Since that isn’t what you want, you need to change the setting ahead of time as described above.

For best results, you should also set DEBIAN_FRONTEND=noninteractive, since you want a non-interactive installation anyway.

Some packages add a layer on top of debconf; one example is dbconfig-common, which is the recommended way for packages requiring a database to configure their database connections, but which doesn’t work with debconf pre-seeding. The defaults for dbconfig-common are to use a local database (on localhost), so if that’s appropriate, DEBIAN_FRONTEND=noninteractive will do the right thing. Otherwise, you need to provide a configuration file in /etc/dbconfig-common, named after the package you want to configure; for example, /etc/dbconfig-common/bacula-director-pgsql.conf. The simplest way to construct this is to install the package once and answer the debconf prompts; dbconfig-common will then write a configuration file that can be re-used elsewhere (possibly removing the password).

Improve this answer
8
  • 1
    Well, I should admit it is very complicated… After doing lots of grepping an experimenting, I found that bacula-director-pgsql apparently uses dbconfig-common/remote/host from /var/lib/dpkg/info/dbconfig-common.templates. However, doing debconf-set-selections <<<"bacula-director-pgsql dbconfig-common/remote/host select localhost" still makes it ask this question upon installation. Commented Sep 19 at 8:38
  • 4
    Ah, dbconfig-common is another kettle of fish, see the updated answer. And yes, it is complicated, but in most cases if you perform a full installation once, you should be able to get all the required info to automate future installations. debconf-show in particular is your friend. Commented Sep 19 at 9:06
  • 1
    So, I just tested your suggestion about /etc/dbconfig-common/bacula-director-pgsql.conf: I saved its content from a system with everything installed, and then re-created on an empty system and launched installation. I still get asked "Configure database for bacula-director-pgsql with dbconfig-common? [yes/no]", etc. Commented Sep 19 at 12:03
  • That’s odd, I tested it when I wrote that part… I’ll check again. Have you tried noninteractive for bacula-director-pgsql? Commented Sep 19 at 12:04
  • 1
    Of course, it’s your question, you don’t owe me anything ;-). TBH I was rather dismayed at the lack of documentation around dbconfig-common (unless I’ve missed it)… Commented Sep 21 at 13:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.