This, bizarrely, is something I had working fine and has now blown up in my face (as the delivery deadline looms).
User adds a device via a web form (MAC, IP), my PHP script adds a host entry to the dhcpd.conf file and restarts the dhcp server. It was all working and now it isn’t.
I have a shell script called startdhcp.sh, which contains
this:
/etc/init.d/dhcpd start
I have a PHP script which has this:
$output = shell_exec(“sudo /etc/startdhcp.sh”);
wwwrun is on the sudoers list as follows:
wwwrun ALL = (ALL) NOPASSWD: /etc/startdhcp.sh
I even tried putting wwwrun in the root group to see if that was the problem but it’s still no good.
Could some patient soul rewalk me through this. I can’t see what else I can do, and it really was working before!
Hello again, All.
OK. This is starting to destroy my life. No, no. Let’s get things in perspective. This is turning into a royal PITA.
I cannot, by any means, get Apache (wwwrun) to have permission to stop or start the DHCP service.
My sudoers file looks like this:
Defaults always_set_home
Defaults env_reset
Defaults env_keep = “LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE”
LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
wwwrun ALL = (ALL) NOPASSWD: /etc/init.d/dhcpd stop,/etc/init.d/dhcpd start,/etc/init.d/dhcpd restart
ALL ALL = (ALL) ALL
root ALL = (ALL) ALL
My PHP script is either:
$output = shell_exec(“sudo /etc/init.d/dhcpd start”);
OR:
$output = shell_exec(“sudo /etc/dhcpstart.sh”);
where dhcpstart.sh is file containing the command.
Apache error log is reporting a prompt for wwwrun’s password now.
Or, if i call without the sudo, simply:
sh: /etc/init.d/dhcpd: Permission denied.
Utterly, utterly stuck and wishing I’d been playing footie with the kids instead of being stuck in front of this blessed computer for the whole of my saturday… any help hugely appreciated.#
I set up something similar to run /etc/init.d/dhcpd status from a PHP script and it worked fine. However one difference is that my /etc/sudoers file contains the line
Defaults targetpw
as installed by default. This may have a bearing on your problem.
BTW, you should use the include directive in /etc/dhcpd.conf and edit a file called /etc/dhcpd.conf.local. It keeps things neater.
Getting absolutely nowhere with this. Apache log still reports a prompt for root’s password when I call:
$output = shell_exec(“sudo /etc/init.d/dhcpd start”);
line in sudoers is now:
wwwrun ALL = (root) NOPASSWD: /etc/init.d/dhcpd start …
It says no password but apache is being prompted for a password. Clearly there is something utterly gigantic that I have not understood about the term NO PASSWORD. It in fact seems to mean YES PASSWORD. Why oh why oh why is it so hard?
Please help!
I have now been at this screen for 12, yes 12 hours. , ;-( life really is too short for this lark.
Thanks for your patience on this one. A small step in the right direction but I now get an error over ownership of the log file … /var/log/rc.dhcpd.log
rm: cannot remove ‘/var/log/rc.dhcpd.log’ : Permission denied. So the dhcp binary seems not to have permission to clear its own log.
Is all of this something to do with the chroot jail option I see in the Yast config window?
That log file is removed in /etc/init.d/dhcpd. Since you are supposedly running as root, there should be no problem removing it. Ergo, perhaps you did not gain root power with the sudo.
Still stuck, I’m afraid. I’ve tried all the permutations I can think of in sudoers = ALL ALL ALL no password, run as root, Rebooting each time. But the apache log always reports a prompt for root’s password. IS there a way I can pass in root’s password, just to see if it works? Obvioulsy no good in a production box, but I need to demo this to a client today and am getting very frustrated.
I’ve been using the Yast sudoers GUI to make these changes. I then used VI (even though I know not the first thing about it - I wasted 20 minutes trying to figure out how to comment out a line - the hash key doesn’t enter a hash character, but hey that’s another lesson).
I took out the Defaults targetpw line to see if that was the problem. Instead of promting me for root’s password, the Apache log now reports a prompt for wwwrun’s password.
Also, quite an interesting aside, removing the Defaults targetpw line from sudoers, broke the root password for KDE … I couldn’t launch yast from a regular user login. I was prompted for the root password, but KDE said password incorrect. What a brilliant time I’m having!
Well in another thread someone said that he had problems with YaST’s sudoers editor. I did my edits using visudo, which invokes vi on sudoers and checks for syntax errors before committing, so that one isn’t locked out.
My belief is that you still have some sort of error in your sudoers file. Revert to the original from the package by reinstalling sudo, then add just one line:
wwwrun ALL = (ALL) NOPASSWD: /etc/init.d/dhcpd restart
You should be able to run that command with a sudo in front of it from wwwrun’s CLI without a password. Or substitute your account, if you prefer to test it from your account. Until you get past this, no point worrying about what Apache is doing.
And perhaps you should make sure that /etc/sudoers has the original ownership and permissions, which are root:root and 440. It could be that sudo is paranoid about permissions.
Hmm - That may well be what was wrong. I made the changes using visudo and, for the moment, Apache is being allowed to make the necessary calls to manage the DHCP service. Moral of the story here seems to be: that bit at the top of the sudoers file where it says 'You MUST (their capitals) edit this file with the visudo command … ’ er … they mean it.
So, the possibility that Yast fries the sudoers file, is that being looked into as a possible bug? Relative linux neophytes like myself rely heavily on the graphical tools, so it’s a fairly major issue.
That said, you quickly develop a taste for the power and speed of the command line!
Glad you got it working. Hope your demo went/goes well.
This is the first release that I’ve seen the sudo tool in YaST. I wouldn’t discount the possibility that it has bugs. I hope somebody can report this bug (after doing an edit with YaST and looking carefully at the resulting syntax to verify that there is a syntax error) so that it can be fixed, maybe even as a patch package soon. I may be an old **** but I understand that tools like this broaden the audience for Linux.
At least this is a bug in KDE. It asks for the root-password but (if defaultstargetpw is not set) expects the users password. Hopefully he has sudoers-rights too :-).