I've allowed root ssh access on a test ESX server here at work. When I'm on this box, or any other ESX as root, I can run the esxcfg-firewall command ... yet on this new ESX test machine I've created a new user (in VI client) and threw it in all the groups that the root user is in, gave the new account full admin permissions, yet when I run the same command I get "command not found"
I've since removed this new account from all groups but root, removed from the permissions tab VI client, and when I ssh to the ESX as the new user and elevate (su) to root I still can't run this command...and many others I assume.
why is this? argh..
plz halp.
Try using su - the dash allows you to keep utilize the path for the user root
sounds like it may be a path issue with the non-root account. esxcfg-firewall is in /usr/sbin.
If you do an echo $PATH for the non root user is /usr/sbin in the path
you could try editing the .bash_profile of the non root account. It is the home directory of that user.
you should see something like the following
User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
change to PATH=$PATH:$HOME/bin:/usr/sbin
don't know if you need more then that to have the esxcfg commands function properly
Try using su - the dash allows you to keep utilize the path for the user root
This worked, thanks!
Still unsure why, when only using "su" and and being in the /usr/sbin directory, I still couldn't run esxcfg-firewall.. but this works.
The reason being is there is an arguement that you were missing. the command "su -" is used to include the profiles 'enviromental' variables, such as PATH. so you can "su - bob" and you will change user and import their 'settings'.
So, the "su -" command (root is implied) will change your user to root and import their PATH and other settings.
good deal that things are working, the su - is short for su -l or su -login, meaning that when you change that user it runs its login scripts, su alone just switches users