Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Per the code: the entry looks good, so all members under Infra-DBA-Oracle should allow access to oracle with no passwd required.
cant say if this be a puppet issue, so what error you are getting while sudo'ing.
Per the code: the entry looks good, so all members under Infra-DBA-Oracle should allow access to oracle with no passwd required.
cant say if this be a puppet issue, so what error you are getting while sudo'ing.
This is what happens after logging-in as oracle:
Code:
[oracle@india ~]$ sudo su -
[sudo] password for oracle:
Check that "/etc/sudoers" has "#includedir /etc/sudoers.d" entry (# sign on front is essential). Check that user "oracle" is in group "Infra-DBA-Oracle".
Check that "/etc/sudoers" has "#includedir /etc/sudoers.d" entry (# sign on front is essential). Check that user "oracle" is in group "Infra-DBA-Oracle".
[1] #includedir... yes it is there at the end of the file:
Code:
# cat /etc/sudoers
###############################################################################
## THIS FILE IS MANAGED BY PUPPET
## YOUR CHANGES WILL NOT STICK
###############################################################################
#Defaults requiretty
Defaults !visiblepw
Defaults always_set_home
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults ignore_dot
Defaults insults
Defaults log_host
Defaults log_year
Defaults !mail_always
Defaults !mail_badpass
Defaults !mail_no_host
Defaults !mail_no_perms
Defaults !mail_no_user
Defaults shell_noargs
Defaults editor = /bin/vi
root ALL=(ALL) ALL
%wheel All=(ALL) ALL
#includedir /etc/sudoers.d
[2] yes, the user "oracle" is in the DBA... group:
Yes, "%Infra-DBA-Oracle" means that this entry affect only users belonging to this group. By this command you can check what sudo entires has specified user:
Code:
sudo -l -U oracle
Sorry, but something is understanded by me. You want the user "oracle" to execute command "sudo su - oracle"? Because this entry is in sudoers file. If you want "sudo su -" then specify that:
Also if you have sudo, then su is not needed, you can specify user with -U option. For example to become root, user "oracle" can do "sudo -i". You can give him group "wheel" for that, as it has relevant entry in sudoers already.
Yes, "%Infra-DBA-Oracle" means that this entry affect only users belonging to this group. By this command you can check what sudo entires has specified user:
Code:
sudo -l -U oracle
Please have a look at this output:
Code:
$ sudo -l -U oracle
Matching Defaults entries for oracle on this host:
!visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT
LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE
LINGUAS _XKB_CHARSET XAUTHORITY", ignore_dot, insults, log_host, log_year, !mail_always, !mail_badpass, !mail_no_host,
!mail_no_perms, !mail_no_user, shell_noargs, editor=/bin/vi
User oracle may run the following commands on this host:
So, user oracle cannot run anything by sudo. Please look my ealier post. You can add "su -" (without "oracle" at end) entry to sudoers, or make user "oracle" a "wheel" group and it can switch to root by "sudo -i".
So, user oracle cannot run anything by sudo. Please look my ealier post. You can add "su -" (without "oracle" at end) entry to sudoers, or make user "oracle" a "wheel" group and it can switch to root by "sudo -i".
So, one last thing just to be sure before I edit the *DBA* sudoers file:
Is this already correct:
Code:
# id -Gn oracle
oinstall dba
?
Or do I need to first run this command:
# usermod -G Infra-DBA-Oracle oracle
and then edit the said file? Or just adding "su -" to the file would do fine?
with sudoers , the last rule 'wins'
so it is possible for other files in /etc/sudoers.d/ to 'undo' /etc/sudoers.d/Infra-DBA-Oracle
for example
Code:
foo ALL=(root:root) NOPASSWD: /etc/init.d/reboot
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
foo is allowed to run 'reboot' as user root without password,
but if foo is a member of sudo, that rule is 'overwritten' and will be prompted for password.
Anyway, I don't think that is your problem.. ( although worth keeping in mind )
members of Infra-DBA-Oracle, can execute "/bin/su - oracle" or "/bin/su oracle" without password prompt.
BUT, your tests:
Code:
[oracle@india ~]$ sudo su -
user oracle is trying to get root, and needs a password.
if user oracle were to "sudo su - oracle" they would not require a password.
Obviously it is of little use for oracle to be able to "switch user" to oracle
instead , login as another member of Infra-DBA-Oracle
and sudo su - oracle you should then have a login shell as oracle.
If you want to user "oracle" be able to switch to "root" account, then the simplest method is to only add him to group "wheel", creating this group if it is not already present. After that he will be able to switch to root account, by executing command "sudo -i".
If you want to user "oracle" be able to switch to "root" account, then the simplest method is to only add him to group "wheel", creating this group if it is not already present. After that he will be able to switch to root account, by executing command "sudo -i".
I can't add the account "oracle" to wheel as the sudoers file is being managed by Puppet. I have posted the file's contents above.
There are groups-files in /etc/sudoers.d/ directory which correspond to privileges given to each group:
The user who is using the account "oracle" for the log-in is able to log-in to the server but he then wants to do a "sudo su -" and this action prompts for the oracle's password and then throws the error "Access denied".
According to the user, he was able to do a "sudo su -" earlier. I am not sure what needs to be done now to enable "oracle" to switch user as root: "sudo su -" or "sudo -i".
I think somebody has mistakenly included "oracle" in those two lines because they simply mean "oracle" can run "su - oracle" which is not required at all when oracle is already logged in, and it is meaningless. What do you say?
[oracle@india ~]$ sudo -i
[sudo] password for oracle:
...
[oracle@india ~]$ sudo su -
[sudo] password for oracle:
...
[oracle@india ~]$ groups
oinstall dba
[/code]
I really don't know the password for "oracle" and I don't need it because I have root privileges on the system so I can get in as root without any issue. The problem is why there is the password prompt for "oracle" when I try to switch user to root?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.