Gregory Machin wrote:
I'm trying to configure a group %linuxadmins .. My account is a member of linuxadmins , when I sudo iptables -h I get "sudo: iptables: command not found". If I sudo /sbin/iptables -h it works fine.
If you sudo bash and then echo $PATH, what do you see?
I'm guessing /sbin won't be in it -- sudo uses the target account's $PATH, not your account's.
[macgre(a)ns2 ~]$ sudo echo $PATH /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/macgre/bin
no it's missing .. how do I get sudo to add this ?
According to man sudo:
Environment variables to be set for the command may also be passed on the command line in the form of VAR=value, e.g. LD_LIBRARY_PATH=/usr/local/pkg/lib. Variables passed on the command line are subject to the same restrictions as normal environment variables with one important exception. If the setenv option is set in sudoers, the command to be run has the SETENV tag set or the command matched is ALL, the user may set variables that would overwise be forbidden. See sudoers(5) for more information.
so you could (presumably) sudo PATH=/bin:/sbin iptables -h, or clog up your sudoers some more, but I can't say that those'd really be any improvement over just using sudo /sbin/iptables. is there any particular reason against the latter? (PATH=$PATH may be worth looking into; you'll probably find that the shell substitutes your path, which I think is what you're after. specifying an overly-limited path may well confuse iptables; it'll *definitely* confuse other programs.) Me, I'd go for sudo /sbin/iptables. it's clear, it's repeatable, it won't cause any surprises later if anyone mucks with account paths. butting