New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkgng provider on FreeBSD does not do BATCH=yes #27056

Closed
oogali opened this Issue Sep 11, 2015 · 16 comments

Comments

Projects
None yet
7 participants
@oogali

oogali commented Sep 11, 2015

The pkgng provider on FreeBSD does not use the "BATCH=yes" environment setting when installing new packages.

This is problematic when installing packages that have an interactive post-install script (e.g. mail/postfix). The lack of the batch flag causes pkg to forever wait for a user response (which it will never receive), which in turn causes the minion to "hang".

# pkg install -qy postfix
===> Creating users and/or groups.
Using existing group 'mail'.
Creating group 'maildrop' with gid '126'.
Creating group 'postfix' with gid '125'.
Creating user 'postfix' with uid '125'.
Adding user 'postfix' to group 'mail'.
Would you like to activate Postfix in /etc/mail/mailer.conf [n]? ^C

But, because the minion is still reachable by the master, your highstate never completes or times out, and you then have to log in, kill the minion child, manually install the package in question, and then restart your highstate run.

# salt --versions-report
           Salt: 2015.5.2
         Python: 2.7.9 (default, Aug 27 2015, 01:28:02)
         Jinja2: 2.7.3
       M2Crypto: 0.22
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.11
          ioflo: Not Installed
          PyZMQ: 14.6.0
           RAET: Not Installed
            ZMQ: 4.1.3
           Mako: Not Installed
@jfindlay

This comment has been minimized.

Contributor

jfindlay commented Sep 11, 2015

@oogali, thanks for the report.

@oogali

This comment has been minimized.

oogali commented Nov 17, 2015

Any traction? This is preventing me from fully using salt-cloud to orchestrate hosts in Amazon EC2.

@jfindlay

This comment has been minimized.

Contributor

jfindlay commented Nov 17, 2015

@oogali, not that I know of. You could ask @cedwards or @kim0 if they think this would be an easy fix.

@abednarik

This comment has been minimized.

Contributor

abednarik commented Dec 15, 2015

HI @oogali

I'm not an expert, but I'm trying to fix this. Would be great if you can test this, of course not in production. I do not have any FreeBSD around.,

Thanks

#29707

@abednarik

This comment has been minimized.

Contributor

abednarik commented Dec 21, 2015

Sorry for any inconvenience, but please read my last comment #29707
I was trying to fix the old pkd module and this one is related to the new one.

@oogali

This comment has been minimized.

oogali commented Dec 22, 2015

@abednarik Adding -y is not enough. -y simply tells pkg not to prompt to install the package, but has no effect on interactive post-install scripts.

See my original report in which I have -y in the arguments passed to pkg in a shell, but it still prompts me to take action.

@abednarik

This comment has been minimized.

Contributor

abednarik commented Dec 22, 2015

Thanks @oogali. In that case we also need ASSUME_ALWAYS_YES=YES is this correct?

Cheers

@ohauer

This comment has been minimized.

ohauer commented Dec 22, 2015

No, ASSUME_ALWAYS_YES is he same as the already present "-y".
The issue is in the postfix installation script!

The script waits for an user input [y/n] without timeout (read -p).
In case the env. POSTFIX_DEFAULT_MTA=yes is set the default for the answer will be "yes" else "no".

In my opinion the solution is to set a timeout in the postfix install script read loop, say 5min and then go on with proceeding the install script using the default "no" or in case the env. POSTFIX_DEFAULT_MTA=yes was found with "yes" as the answer.

Another idea is to use additional "test -t" inside the postfix install script and detect this way if the package is installed without terminal...

A workaround would be to install "/etc/mail/mailer.conf" with postfix as default before installing the postfix package (salt-cp or managed file)

I suspect with a fixed fixed postfix install script, something like this will do the trick

postfix:
 - env:
  - POSTFIX_DEFAULT_MTA: yes

Maybe someone has an insight if there is an salt specific environment variable that can be used for further decisions inside a script?

Given the date I can only work next week on a good solution but I expect I can update the ports before next year.

@oogali

This comment has been minimized.

oogali commented Dec 23, 2015

@ohauer I think the high-level solution of BATCH=yes would more than suffice, and scale (in terms of development effort) for installing any and all packages on FreeBSD that have some sort of interactive post-install script.

The BATCH environment variable is a standard pattern within post-install scripts that instructs ports/pkg to not even ask the interactive question, so there's no need for the fragile logic of sleep-poll-decision.

See:

@rallytime

This comment has been minimized.

Contributor

rallytime commented Jan 27, 2016

It appears from the comments that this still needs a little bit of work. Removing the Fixed Pending Verification label.

@abednarik

This comment has been minimized.

Contributor

abednarik commented Jan 28, 2016

Ok. Thanks for that information.

I can add a new optional param to set that env variable when running this module.

@oogali

This comment has been minimized.

oogali commented Jul 27, 2016

Any update here?

@jfindlay

This comment has been minimized.

Contributor

jfindlay commented Jul 27, 2016

@abednarik, are you still able to work on this?

@abednarik

This comment has been minimized.

Contributor

abednarik commented Jul 27, 2016

HI

I can have a look again. I'm using SaltStack in production under FreeBSD. In the next days will check this again.

Thanks.

@bgdnlp

This comment has been minimized.

bgdnlp commented Jun 5, 2017

Hello. Any news on this issue?

@fzipi

This comment has been minimized.

Contributor

fzipi commented Jul 24, 2018

I have this exact problem when installing postfix using the postfix-formula.

First I tested using env vars and shell, with these results (using bash):

[root@salt]# export ASSUME_ALWAYS_YES=YES
[root@salt]# pkg install -y postfix
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating Perceptyx repository catalogue...
Perceptyx repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	postfix: 3.3.1_1,1 [FreeBSD]

Number of packages to be installed: 1

The process will require 7 MiB more space.
[1/1] Installing postfix-3.3.1_1,1...
===> Creating groups.
Using existing group 'mail'.
Using existing group 'maildrop'.
Using existing group 'postfix'.
===> Creating users
Using existing user 'postfix'.
[1/1] Extracting postfix-3.3.1_1,1: 100%
Would you like to activate Postfix in /usr/local/etc/mail/mailer.conf [n]?

So it keeps waiting there for interaction, even when explicitly adding ASSUME_ALWAYS_YES=YES.

Next step is using BATCH=true:

[root@salt]# export BATCH=true
[root@salt]# pkg install postfix
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating Perceptyx repository catalogue...
Perceptyx repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	postfix: 3.3.1_1,1 [FreeBSD]

Number of packages to be installed: 1

The process will require 7 MiB more space.
[1/1] Installing postfix-3.3.1_1,1...
===> Creating groups.
Using existing group 'mail'.
Using existing group 'maildrop'.
Using existing group 'postfix'.
===> Creating users
Using existing user 'postfix'.
[1/1] Extracting postfix-3.3.1_1,1: 100%

===============================================================
Postfix was *not* activated in /usr/local/etc/mail/mailer.conf! 

To finish installation run the following commands:

  mkdir -p /usr/local/etc/mail
  install -m 0644 /usr/local/share/postfix/mailer.conf.postfix /usr/local/etc/mail/mailer.conf
===============================================================

Message from postfix-3.3.1_1,1:

To use postfix instead of sendmail:
  - clear sendmail queue and stop the sendmail daemons

Run the following commands to enable postfix during startup:
  - sysrc postfix_enable="YES"
  - sysrc sendmail_enable="NONE"

If postfix is *not* already activated in /usr/local/etc/mail/mailer.conf
  - mv /usr/local/etc/mail/mailer.conf /usr/local/etc/mail/mailer.conf.old
  - install -m 0644 /usr/local/share/postfix/mailer.conf.postfix /usr/local/etc/mail/mailer.conf

Disable sendmail(8) specific tasks,
add the following lines to /etc/periodic.conf(.local):
  daily_clean_hoststat_enable="NO"
  daily_status_mail_rejects_enable="NO"
  daily_status_include_submit_mailq="NO"
  daily_submit_queuerun="NO"

If you are using SASL, you need to make sure that postfix has access to read
the sasldb file.  This is accomplished by adding postfix to group mail and
making the /usr/local/etc/sasldb* file(s) readable by group mail (this should
be the default for new installs).

If you are upgrading from prior postfix version, please see the README
files for recommended changes to your configuration and additional
http://www.postfix.org/COMPATIBILITY_README.html

So using that the package gets installed.

So for me working solution will be to force install using batch when you add 'Force=true' for example.

I created PR #48730 with this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment