Could you confirm that you have web_user: web
?
Also, on the remote server…
Contents should look like this:
web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm *
Could you confirm that you have web_user: web
?
Also, on the remote server…
Contents should look like this:
web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm *
group_vars/all/users.yml
contains web_user: web
Also the web-services file exists and only contains
web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm *
I’m not familiar with sudoers beyond what has been addressed above. When I start a google search on the topic, the first few results are instances of the NOPASSWD
entry being overridden by subsequent matching sudoer entries. You might check your /etc/sudoers
and ensure that the last line is the include statement #includedir /etc/sudoers.d
and that there aren’t somehow other files in /etc/sudoers.d
that could have competing entries.
Perhaps someone more familiar with sudoer issues will comment, but you may have to become that sudoer expert, coming to understand it well enough to diagnose and debug.
I just added web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm *
directly to the visudo
file and deploying worked. Not sure why the host is ignoring the web-services
file.
Proper fix, noted here for prosperity
My /etc/sudoers
was missing this line:
#includedir /etc/sudoers.d
Make sure there’s no space between #
and includedir
otherwise it will be treated like a comment.
Also ensure files in /etc/sudoers.d/
have the permissions 0440.
i had some similar issues, deploy failed after trellis update
Sorry, user web is not allowed to execute '/usr/sbin/service php7.1-fpm
reload' as root on servername.
fatal: [xxx.xx.xx.x]: FAILED! => {"changed": true, "cmd": "sudo service php7.1-fpm reload", "delta": "0:00:00.035018", "end": "2017-06-01 14:40:51.216976", "failed": true, "rc": 1, "start": "2017-06-01 14:40:51.181958", "stderr": "Sorry, user web is not allowed to execute '/usr/sbin/service php7.1-fpm reload' as root on servername.", "stdout": "", "stdout_lines": [], "warnings": []}
If you are getting the above error when updating to php 7.1 from 7.0, make sure you update the group_vars/all/users.yml
change the last line to
- "/usr/sbin/service php7.1-fpm *"
from - "/usr/sbin/service php7.0-fpm *"
and provision the remote server again, then deploy
Hello mate I have been facing the same issues and turn to various forums but didn’t got any satisfying answer. Instead of trying it again and again I launch DigitalOcean WordPress on managed platform which eventually help me solve this issues. Cheers
Same here. No fix as of yet either
If you’re getting this error after updating Trellis, SSH into your server and check sudo service --status-all
, you may have two versions of php-fpm
installed. Disable both and try provisioning and deploying again.
Nope, only one php7.1-fpm running
failed_when
in template_root
check with wp-cli 1.5.0”MODULE FAILURE
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/tackettz/.ssh/config
debug1: /home/tackettz/.ssh/config line 1: Applying options for *
debug1: /home/tackettz/.ssh/config line 17: Applying options for www-test
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 11127
debug3: mux_client_request_session: session request sent
debug1: mux_client_request_session: master session id: 2
debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Received exit status from master 0
Shared connection to lib-web-lp001.mgt.private closed.
[sudo] password for tackettz:
{“changed”: true, “end”: “2018-02-15 14:27:04.711012”, “stdout”: “”, “cmd”:
“sudo service php7.1-fpm reload”, “failed”: true, “delta”: “0:05:00.289022”,
“stderr”: “”, “rc”: 1, “invocation”: {“module_args”: {“warn”: false,
“executable”: null, “_uses_shell”: true, “_raw_params”: “sudo service
php7.1-fpm reload”, “removes”: null, “creates”: null, “chdir”: null, “stdin”:
null}}, “start”: “2018-02-15 14:22:04.421990”, “msg”: “non-zero return code”}
fatal: [www-test]: FAILED! => {
“changed”: false,
“failed”: true,
“rc”: 0
}
to retry, use: --limit @/home/tackettz/environments/trellis-rc2/deploy.retry
PLAY RECAP *************************************************************************************************************************************************************************************************
localhost : ok=0 changed=0 unreachable=0 failed=0
www-test : ok=38 changed=15 unreachable=0 failed=1
That is the error I am getting when trying to deploy
Oh you just saved my butt, @Simeon.
Is this a worthy bug fix to Trellis, to stop previously running versions of php-fpm when provisioning? This happened to me when jumping from php-fpm7.0 to php-fpm7.2.
I think the latest version of Trellis checks if 7.1 is running…
Yeah. The times I’ve run into this error have been when I’ve updated Trellis and not the server, and they disagree on which version of PHP to check/reload.
We never did this before, but yeah the update to 7.2 specifically checks for existing 7.1 and deals with it. But that’s only for going from 7.1 -> 7.2
Got the same error with timeouts on service php7.4-fpm reload
or restart.
My problem wasn’t the sudoers file, but the wrong user for that command inside the playbook.
playbook had a become_user: www-data
task failed
added become_user: deploy-bot
to task (replace with your management user)
task run successfully