Document prepared by: Troy Lancaster Date: 3/25/2012

Short Description:

Usage of sudo for root-level privileges

Detailed Description:
Use this procedure to use privs that have been provided for individual commands. Also in this guide is the format for which you can request new commands be added to speed the request.

Why SUDO:
Sudo is used in our environment to limit our risk on our system as well as to more easily meet our SOX audit requirements.

How SUDO works:

Individual commands are added to the sudoers configuration file. This allows a person to log into their standard non-priviledged account and run specific commands with full root access. Those commands can be configured to run with any parameter or specific parameters. A user logs into their own account, runs the SUDO command with the proper command following it and the system will verify that the user is allowed to run that command, and if so execute the command as root.

Mosaic SUDO access request:

If you are a Mosaic employee or contractor, then to request that a command be added to your sudo access the following information is required: Name of the account Name of the server that this needs to be on. Full path of the command Length of time the command is required Reason for the request Manager approval and GSD ticket

Here is an example of an email to the GSD/systems that will kick off this request:

GSD, Please open a ticket for the Systems team for this work. Systems team, Please add oraep2 account to have sudo access to /usr/bin/vi /etc/oratab on all of the EP2 servers permanently please. This is required to do standard oracle database maintenance.

Vendor SUDO access request:

If you are a Vendor that works with Mosaic and have access to the unix systems you have a slightly different process. The only difference here is that the Systems team will be opening the Mosaic change ticket based on an email coming in from the Vendor. The email will go straight to the unix support team. The following information is required: Name of the account Name of the server that this needs to be on. Full path of the command Length of time the command is required Reason for the request

Here is an example of an email that will kick off this request: Mosaic unix team, Please add tsmadmin account to have sudo access to /usr/bin/vi /etc/inittab on all Mosaic managed systems permanently please. This is required to perform initial setup on all TSM clients.

Usage:
Using sudo is pretty easy, but you have to make sure you include all the steps. First and foremost to remember is that FULL PATHS ARE REQUIRED FOR EVERYTHING. This does take some getting used to. Other than that just put the word sudo in front of your command. If password is required it is asking for your account password, not root. As root you could do the following: # cd /etc # vi oratab With sudo the following would be required: $ /usr/bin/vi /etc/oratab

Errors/Failures:
Config failure. Sometimes you can get a failure using SUDO if the sudoers file has a mistake. If you get this problem please let the Mosaic unix team know right away. This is what it looks like: alm6:/admin/config/sudo #sudo test >>> sudoers file: syntax error, line 18 <<< >>> sudoers file: syntax error, line 20 <<< >>> sudoers file: syntax error, line 21 <<< >>> sudoers file: syntax error, line 22 <<< sudo: parse error in /etc/sudoers near line 18

Command failure. The most common problem is that the command that is being tried is not being attempted correctly or is not in the sudoers file correctly. For example in our systems our SAP users are allowed to do this command: /usr/bin/rm /SAPworkdir*, \ This is what would happen if you didnt use fill paths: $ cd /SAPworkdir $ sudo rm myfile Sorry, user edxadm is not allowed to execute '/usr/bin/rm myfile' as root on wdssapms3. Run properly the same command could work: $ sudo /usr/bin/rm /SAPworkdir/myfile Configuration failure. If you do all of that properly and still get the not allowed then please copy and paste that error to the Unix team via email and let them know the command you are trying to run. The command is not covered by what is configured in SUDO, and either the command needs to change or it or its parameters need to be added to the SUDO file properly.

Additions Starting scheduler service examples: nohup sudo /usr/bin/dsmc sched > /dev/null 2>&1 & Stopping scheduler services: sudo /usr/local/bin/dsmc_kill