Process and reasoning behind sudo access on EngrIT systems
Since the system is part of Engineering IT's managed Linux environment, our usual counter-question is "Why do you need root access?"
Our preference is to not issue administrative access to Engineering IT managed systems, and instead handle typical needs-requests through our normal support channels. Synonyms for administrative access in a Linux environment are root access, superuser access, sudo access.
Administrative access is usually request to manage software, accounts, or settings on the system. Each of those are better handled through Engineering IT, for the following reasons:
Engineering IT's managed Linux environment includes a centralized system for software distribution, with the following features:
By centralizing our software installation, we add consistency and repeatability to the systems we manage. If we add a package to any one of your systems, it will be added on all of them - including new ones when they're first installed and or when older systems get reinstalled.
We can also easily and quickly leverage existing software packages used elsewhere in our managed environment. We can quickly install shared packages like Matlab or Mathematica without the manual install. Those package additions share the same consistency and repeatability listed above. We can also support multiple versions of software on a single system without conflict and still have ease of use, using environment modules.
Additionally, there are many ways to do software installation into your home directory that do not require administrative access or Engineering IT involvement. We can help you learn how to do this; please ask us.
User accounts on Engineering IT managed Linux systems are UOFI Active Directory (AD) based. Managing those accounts in a central directory allows us to use the same password as other services. Active Directory based accounts create consistent access across systems.
Similar to our software management, Engineering IT centralizes most of the main system configuration on our managed Linux systems. This means things like who can login, what network shares are available, what printers are available, what services are running, etc. By managing these settings centrally, we leverage consistency and repeatability. (For example, systems in CS will automatically get the Siebel Center printer queues added to them.)
If special services are needed on a system (like webhosting, file shares, etc.), we can work with you to find a sustainable way to provide those services.
Engineering IT managed Linux installations are not like typical end-user desktop installations. The methods of system administration differ, and may conflict if a user tries to manipulate the managed system like a standalone desktop. It is safer to discuss your needs with Engineering IT and have them provision it for you than to assume what works on your home system will also work here.
The more consistent your Linux system is with the rest of the Engineering IT environment, the easier it is for us to support you. Altering the system through self management can cause a number of problems:
The support for Engineering IT to fix a system that's broken and has been altered outside of Engineering IT is very limited. In some extreme scenarios, Engineering IT may only support re-installation of the system back to its supported-base.
There is value in the communication we receive from our users about their needs and usage of their systems. For example: you may not want to bug us with small software requests like having XEmacs installed on your desktop. But those requests are simple and give us insight into proactively modeling our environment. Requests like this give us the questions to consider what software should be installed across all your systems, or all systems in general.
The user communication on what does and does not work is very helpful to Engineering IT. Your feedback helps us build better, more usable solutions for you.
Although Engineering IT strives to provide the best managed Linux environment possible, we recognize situations may arise where user administrative rights are necessary. Ideally, those circumstances lie outside of the conditions listed in this page. For example, root level access required for kernel level debugging, or to initialize services that cannot be run as a normal user.
In those scenarios, administrative access can be granted via the 'sudo' command. The root administrative password is not shared with users, but sudo allows an authorized user to run processes (or a shell) as root. Sudo permissions are not granted by default to users; they must be requested.
Sudo access can be granted in two ways:
When sudo rights are granted without restriction to specific commands or applications the following risks apply:
The following information is required to request administrative access (sudo) permissions on Engineering IT managed Linux systems:
Requests for sudo permissions can be sent to email@example.com and should include:
Assuming the appropriate approvals are in place, sudo requests are usually processed within one business day.