- Requesting administrative access on Engineering IT linux systems
- Other factors to EngineeringIT-only administrative access
- Exceptions / Requesting sudo access
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 requested to manage software installed on the system, to manage who can use the systems (accounts), or to control the configuration of the system (services, printers, display settings, etc.) 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.
- One-off, manual package additions don't have that functionality and often get overlooked.
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.
- If you need a software package that's not already a part of our distribution, we can add it, and then leverage that software elsewhere.
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 use the same password as other services (Exchange, campus wireless, etc.), as well as allowing consistent access across systems with respect to file sharing and other services.
- Accounts should only be centrally managed through the AD tools. Locally-defined accounts on the system can conflict with centrally-defined ones.
- We can support on-campus users or external collaborators, short-term guests, etc.
- In the near future, we'll be able to support self-service tools for faculty (or their designees) to manage (add/disable) accounts on their systems through a web-based tool.
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's 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:
- filling up disk space by putting large datasets/software in unexpected places
- putting user data on unexpected file systems/locations of the system, and that can be ignored or lost during updates
- software installs can conflict with newer installs and patches, causing system and security updates to fail (and perhaps go unnoticed)
- software installs can introduce security vulnerabilities to your system or accounts
The support for Engineering IT to fix a system that's broken and has been altered outside of Engineering IT is 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/usage of the 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 easy-to-fulfill, and give us insight into proactively modeling our environment. (Maybe the XEmacs editor should be installed by default across all of our systems?)
The user communication on what works and what does not is very helpful to Engineering IT, especially as we extend this linux managed environment out to different research groups, users, etc. 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.
When sudo permissions are granted to a user in an group, the following risks apply:
- sudo permissions are granted across all systems in the group
- Because of the shared permissions model, giving elevated access on one system can compromise all of them, so we make the sudo permission group-wide
- The sudo superuser has access to all processes, users, and files on the system. This means:
- a sudo user can 'switch into' another user account without the password
- a sudo user can read other users files
- Besides privacy concerns, faculty should be aware of FERPA and other class privacy concerns when storing academic information on their system and permitting sudo permission for their students
- a sudo user can control any process on the system, possibly making the system unstable or unusable
- a sudo user can do the administrative tasks listed above outside Engineering IT's managed environment
- These changes won't be recorded by our managed environment
- These changes could conflict with our managed environment and break some immediate or future functionality
The following information is required to request administrative access (sudo) permissions on Engineering IT managed linux systems:
- the faculty member / PI / authorized user-decider for those systems agrees to it
- the user acknowledges reading this page and what they should/should-not do with administrative privileges
Requests for sudo permissions can be sent to engrit-help [at] illinois [dot] edu and should include:
- your name and university netid
- the systems (hostnames) you are requesting sudo permission on
- a message from the faculty member granting permission, or contact information for the faculty member who can authorize sudo permissions
Assuming the appropriate approvals are in place, sudo requests are usually processed within one business day.
Questions about this topic? Don't see what you're looking for?
Email engrit-help [at] illinois [dot] edu, call the Help Desk at 217-333-1313, or contact your primary IT support professional.