Installation: "sudo: no tty present and no askpass program specified"

We're also getting this on platform "verify". For us this is happening when importing a platform on the local machine.

We're using ubuntu '16.04.2 LTS' with PHP 7.1

The test on Gitlab is also showing this warning ...

Any function problems that could be caused by this?

There is a hint about using 'ssh -t' on http://stackoverflow.com/questions/21659637/how-to-fix-sudo-no-tty-prese...

Same pb here on a fresh Aegir3.10 install using deb packages.

Pb showed immediately after install on verify hostmaster task:

Calling hook drush_zz_fix_ownership_post_provision_verify	
sudo: no tty present and no askpass program specified	
Returned from hook drush_zz_fix_ownership_post_provision_verify	
Calling hook drush_zz_fix_permissions_post_provision_verify	
sudo: no tty present and no askpass program specified	
Returned from hook drush_zz_fix_permissions_post_provision_verify

Disable "Fix Permissions" and "Fix Ownership" features in Hosting/Experimental to discard messages.

This pb is discussed here: https://www.drupal.org/node/2616426#comment-11867530

What is the correct sudoers line to add to the sudoer file?

i have this and it doesn't seem to work:
aegir ALL=NOPASSWD: /usr/local/bin/fix-drupal-site-permissions.sh
aegir ALL=NOPASSWD: /usr/local/bin/fix-drupal-site-ownership.sh

You'll need to grant permissions for the two platform scripts, as well:

aegir ALL=NOPASSWD: /usr/local/bin/fix-drupal-platform-ownership.sh
aegir ALL=NOPASSWD: /usr/local/bin/fix-drupal-platform-permissions.sh
aegir ALL=NOPASSWD: /usr/local/bin/fix-drupal-site-ownership.sh
aegir ALL=NOPASSWD: /usr/local/bin/fix-drupal-site-permissions.sh

This problem happen us after upgrading from 3.186 -> 3.190

While we were in 3.186 all our platforms verify task finished OK, but just after upgrade in Ubuntu 18.04 with debian packages, a server verification task with all its platforms were automatically run and all the platforms finished with this warning.

I found that commit f85b6e5214607235f190bccc05a3d372164f0f90 from #3149961: BOA backport calls this fix-drupal-platform-ownership.sh script without checking if the module is enabled.

Who can make a patch that adds such a check?

Note that the module has an extra install.sh script which is mentioned when the module is installed.

PS: this is diverting a bit from the original issue here, the mentioned commit just adds extra calls to sudo.

My understanding is that some verification task calls certain drush hooks from "Fix Permissions" and "Fix Ownership" modules when these modules are enabled. However, in order to properly install the "Fix Permissions" and "Fix Ownership" modules, an extra install script on the backend has to be called. This step is often overlooked and skipped at manual installs, and this step is not part of the debian package, since these are optional golden modules.

If overlooked for any reason, but the modules are enabled, the aegir user won't have proper sudo permissions to run some related backend scripts, and throwing these warnings. For a quick fix after every platform install see https://www.drupal.org/project/provision/issues/2842473#comment-13804339

"Fix Permissions" and "Fix Ownership" modules are disabled in my environment. Aegir is installed with Debian package 3.192 and I'm getting this warnings when verifying platforms.

The scripts referenced in comment 7 are not present in my environment. Should I download them from anywhere?

While testing Aegir 3 on Ubuntu 20, I am seeing this warning from sudo during Verify tasks; it doesn't stop anything from working but might be relevant here:

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

I don't have those scripts in my /usr/local/bin on my install.

They are all in /var/aegir/hostmaster-7.x-3.192/profiles/hostmaster/modules/aegir/hosting_tasks_extra/fix_{permissions/ownership}/scripts

The install seemed fine from the command line feedback but I am getting the host verification warning in the UI saying that

sudo: no tty present and no askpass program specified.

edit - oh, I do see those warnings in the install output

==============================================================================

.
.
sudo: no tty present and no askpass program specified [warning]
.
.
Client home directory for admin path /var/aegir/clients/admin is [success]
writable.
Created symlink /var/aegir/clients/admin/aegir-master.xxx.us [success]
to /var/aegir/hostmaster-7.x-3.192/sites/aegir-master.xxx.us
sudo: a password is required [warning]
sudo: a password is required [warning]
Changed permissions of [success]
/var/aegir/hostmaster-7.x-3.192/sites/...to 640
.
.
.
Congratulations, Aegir has now been installed.

You should now log in to the Aegir frontend by opening the following link in your web browser:

http://aegir-master.xxxx.us/user/reset/1/xxxxxx/login

==============================================================================

'drush' cache was cleared. [success]
Enabling hosting-queued daemon
The following extensions will be enabled: hosting_queued
Do you really want to continue? (y/n): y
hosting_queued was enabled successfully. [ok]
Enabling Hosting queue daemon feature. [status]
Synchronizing state of hosting-queued.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable hosting-queued

ssh-rsa xxxxxxConsidering dependency setenvif for ssl:

-----BEGIN OPENSSH PRIVATE KEY-----
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
Module rewrite already enabled
To activate the new configuration, you need to run:
systemctl restart apache2
AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/conf-enabled/aegir.conf:3
Aegir frontend bootstrap correctly, operation was a success!
Use this URL to login on your new site:
http://aegir-master.xxxxx.us/user/reset/1/1614636727/xxxxx/login
Setting up aegir3 (3.192) ...
Setting up php-symfony-console (3.4.6+dfsg-1ubuntu0.1) ...
Setting up composer (1.6.3-1) ...
Processing triggers for systemd (237-3ubuntu10.44) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-21) ...

Copying the scripts into /usr/local/bin and updating my aegir sudoers file as pointed out in #7 worked for me.

It's also necessary to add similar checks for the fix-drupal-site-ownership.sh and fix-drupal-site-permissions.sh. Following an install from the Debian package, there were also notifications for these two scripts:

aegir3-deb-unstable-no-puppet.test : Aug  2 15:55:40 : aegir : a password is required ; TTY=unknown ; PWD=/var/aegir/hostmaster-7.x-3.192 ; USER=root ; COMMAND=/usr/local/bin/fix-drupal-site-ownership.sh --site-path=/var/aegir/hostmaster-7.x-3.192/sites/aegir.example.com --script-user=aegir --web-group=www-data

aegir3-deb-unstable-no-puppet.test : Aug  2 15:55:40 : aegir : a password is required ; TTY=unknown ; PWD=/var/aegir/hostmaster-7.x-3.192 ; USER=root ; COMMAND=/usr/local/bin/fix-drupal-site-permissions.sh --site-path=/var/aegir/hostmaster-7.x-3.192/sites/aegir.example.com

Here's a potential patch that addresses one of the instances, as it's called directly from verify.provision.inc.

It doesn't address the two other instances highlighted in #15, so is only a partial fix.

I believe those instances are called when the hostmaster site is verified. The only way I think those can be called are from hosting_tasks_extra/fix_ownership/drush/zz_fix_ownership.drush.inc and hosting_tasks_extra/fix_permissions/drush/zz_fix_permissions.drush.inc. I don't presently understand why those would be loaded in the context of installing the hostmaster though.

From the install.log, in verbose it's definitely being invoked:

11.82 MB]
sudo: a password is required [75.8 sec, 11.82 MB]                    ESC[1;33;40mESC[1m[warning]ESC[0m
Returned from hook drush_zz_fix_ownership_post_provision_verify [75.8    [debug]
sec, 11.82 MB]
Calling hook drush_zz_fix_permissions_post_provision_verify [75.8        [debug]
sec, 11.82 MB]
sudo: a password is required [75.8 sec, 11.82 MB]                    ESC[1;33;40mESC[1m[warning]ESC[0m
Returned from hook drush_zz_fix_permissions_post_provision_verify        [debug]
[75.8 sec, 11.82 MB]

This doesn't happen in subsequent runs of

drush @hostmaster provision-verify

though. I think this is because once the hostmaster is verified the first time,

/var/aegir/.drush/drushrc.php

is created, and it contains a list of modules to exclude since the feature is disabled.

Eg.

$options['exclude'] = array (
  0 => 'backup_window',
  1 => 'nginx_https',
  2 => 'platform_composer_git',
  3 => 'platform_composer',
  4 => 'platform_git',
  5 => 'subdirs',
  6 => 'ssl',
  7 => 'nginx_ssl',
  8 => 'nginx',
  9 => 'server_data',
  10 => 'site_data',
  11 => 'example',
  12 => 'signup',
  13 => 'git_tag',
  14 => 'git_commit',
  15 => 'civicrm_cron',
  16 => 'civicrm',
  17 => 'fix_ownership',
  18 => 'fix_permissions',
  19 => 'drush_alias',
  20 => 'dns',
  21 => 'tasks_extra',
);

So, it might be possible to explicitly create drushrc.php before running hostmaster-install in the debian package, or as part of hostmaster-install; however, this feels a little weird since we're working around a hook in a contrib module.

It's probably best to wrap the drush hooks in fix_permissions and fix_ownership so that it does verify that the feature is enabled before running.

Here's a patch (against hosting_tasks_extra) which verifies that the feature is enabled before running any of the commands from the drush hook. It appears to stop the sudo warnings during initial installation. I tested it in combination with the patch from #16.

Thanks @kienan your patch in #16 almost worked for me. I needed to tweak it to use the fix_permissions feature that the scripts are in though, as the attached patch does.

Steven Jones commented about a month ago
Thanks @kienan your patch in #16 almost worked for me. I needed to tweak it to use the fix_permissions feature that the scripts are in though, as the attached patch does.

@steven-jones but the path should really check for fix_ownership, right? Since this is the module that will provide /usr/local/bin/fix-drupal-platform-ownership.sh.

Hello, may I ask you a question as very beginner?
What is the best practice to apply these three patches?
I did some research and I found many techniques.

Two options that I found are:

curl https://www.drupal.org/files/[patch-name].patch | git apply -

wget -q -O - https://www.drupal.org/files/[patch-name].patch | git apply -

If I try to call it as aegir user the result is:

curl https://www.drupal.org/files/issues/2021-08-03/hosting_tasks_extra-28424... | git apply -

fatal: cannot come back to cwd: Permission denied
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--100 2226 100 2226 0 0 18864 0 --:--:-- --:--:-- --:--:-- 19025
(23) Failed writing body

Thank you

@sseidel spot on.

Thanks everyone!