September 23rd, 2013 14:00

So does this mean there is no way for OME to use "MY" user account which has "ALL=(ALL) ALL" set if i put in the credentials when doing the task?  That it HAS to be a user with NOPASSWD set?

Thanks,

Denny

327 Posts

September 23rd, 2013 14:00

If you want to apply system updates using sudo, select Enable Sudo and update the SSH port number.


Before you apply system updates using sudo, create a new user account, edit the sudoers file using the visudo command, and add the following:
-  For target systems running a 32-bit operating systems: Cmnd_Alias OMEUPDATE = /bin/tar, /opt/dell/srvadmin/bin/omexec,/tmp/LinuxPreInstallPackage/runbada,/tmp/LinuxPreInstallPackage/omexec ALL=OMEUPDATE, NOPASSWD:OMEUPDATE.
- For target systems running a 64-bit operating systems: Cmnd_Alias OMEUPDATE = /bin/tar, /opt/dell/srvadmin/bin/omexec,/tmp/LinuxPreInstallPackage64/runbada,/tmp/LinuxPreInstallPackage64/omexec ALL=OMEUPDATE, NOPASSWD:OMEUPDATE.
 

NOTE: Applying system updates using sudo is not supported for SUSE Linux Enterprise Server targets.

 

Thanks,
Raj Shresta

September 25th, 2013 12:00

Anyone able to confirm this?  There is NO way to do updates with  a users account who has ALL=(ALL) ALL, without nopasswd?  I need to know before i start deployment.

Thanks,

Denny

327 Posts

September 26th, 2013 10:00

We are checking few things internally and should have a response soon.

Thanks,
Raj Shresta

327 Posts

September 26th, 2013 16:00

Sudo user is not allowed to update the system under ALL ALL ALL privileges. It does not give all the root privileges or update execution privilege for the DUP. Permissions ALL ALL ALL only gives the user read and write access but no execution access which we need to provide specifically using the path as mentioned earlier.

The Sudo user needs to execution level privileges for system updates. One way is by adding the path as suggested earlier. Not sure if there is any other mechanism to provide machine level execution access to the user.

Thanks,
Raj Shresta

September 26th, 2013 16:00

in the sudoers file.. an entry like the following:

username ALL=(ALL) ALL

or 

%usergroup ALL=(ALL) ALL

allows a user or a group of users to run any command as root.  With the above.. i would be able to do:

"sudo whoami" on my OWN user, and it would say 'root' after prompting me for my password.  This is how systems administrators generally manage systems as it is not best practice to use the root login to do systems administration tasks.

The OMECMDS alias your defining in the previous post just gives a set of commands that a user omeuser can run when THEY use sudo (those commands).  This is how sudoers works.

The NOPASSWD flag you have added to the omeuser simply means that it will not be prompted for a password when it runs "sudo command".  

This however requires that a seperate user be set up for OME tasks, and is not ideal in an centrally managed environment.  Ideally, OME should allow me to use my user credentials in a task, and it should sudo and run the command, and enter the password I provided when prompted.

If the OME command set requires a NOPASSWD entry in order to run these tasks, this is a design flaw.  

ALL=(ALL) ALL is in no way a read only, non-executable methodology of sudo, as sudo has nothing to do with read/only and is all about execution.

So can we confirm that it does in fact REQUIRE a "NOPASSWD" sudoers entry for a user in order to run tasks/updates from the OME Gui?

Thanks

2 Intern

 • 

1K Posts

October 1st, 2013 08:00

Hi Denny,

In OME when we support SUDO, it means that we are allowing non root users to execute SU tasks. The idea of implementing NOPASSWORD parameter is to avoid being prompted for a password as OME does not support interactive tasks. Even when you are executing a remote task, the credentials need to be provided in the script or in the task itself.

It is necessary to create a NOPASSWD entry for the user to run tasks/updates from OME GUI. This is done to avoid being prompted for a password.

No Events found!

Top