Administrator (sudo) rights in Cubbli Linux

About

You can have administrator rights in your Cubbli Linux workstation or a laptop. Currently this is implemented by adding your user account to local sudo group on the local machine, so that you can access the root user account with your own password. Alternatively sudo access can be granted to a centrally managed active directory IDM group.

Students

When you have read all the bullet points in Mandatory reading regarding acquirement of sudo-rights you can run the command i-want-sudo-access in your Cubbli fuxi-laptop. The correct answer to the question Do you still want sudo access right, even after you read the instructions? is Yes I do.

Faculty

When you have read all the bullet points in Mandatory reading regarding acquirement of sudo-rights you can check the Flamma page for further instructions.

https://flamma.helsinki.fi/s/KZOA9

Mandatory reading regarding the acquirement of sudo-rights

• Linux offers almost no protection against mistakes made with admin rights. 
  • A typo or a wrong command, or just following bad instructions from a web page can destroy your system, make it unbootable or destroy or corrupt your files.
• If you break your system with your admin rights, helpdesk probably can't help you.
  • Debugging a broken Linux installation takes lots of time and effort, which would probably better be used elsewhere.  Most likely we will fix your broken Linux machine by reinstalling it from scratch. 
• This is the most common mistake: do not run programs as root.
  • If you try to run a web browser or any other GUI program as root, it will overwrite files in your home directory with files owned by root and your desktop will stop working. It is also likely that the program will write files in system directories. Non GUI-program can also do this. If a software can't do its job because of missing access rights, fix the access rights of the accessed resource instead. 
• Use the root account only for administrative purpose.
  • Like installing software from software repositories. If you need root account to run server software, the server software will need a separate user account for running, instead of root. 
• Do not remove the cubbli packages.
  • Even if apt dependency resolver asks for it. University configuration is implemented by those packages, and it will stop working if they are removed.
  • It is probably safe to remove cubbli-apps, cubbli-dev and cubbli-extra packages if you need space on the root file system.
• Do not use do-release-upgrade for upgrading to a newer distribution version.
  • It won't work with Cubbli and it will break your system so that it probably needs to be reinstalled. Your files can still be saved though. Instead, ask Helpdesk to do the upgrade. It can be done remotely when the machine is connected to a wired University network and it takes much less time than do-release-upgrade. 
• The root partition and root directory is intentionally small.
  • Anything important or large should be saved to the /home/ partition. If you use docker images, databases or virtual machines configure them to save data on /home/ partition.
  • If the root partition gets full, the Linux installation will stop working properly.
  • Only files in the /home/ partition will be copied to a new installation or preserved during reinstall. 
• Be careful and selective when configuring 3rd party software repositories.
  • If you add a 3rd party repository to a Cubbli host, always add the GPG key too which is used to sign the installed software packages.
  • Also, apt repositories provide no protection against malicious or just buggy packages: they can break your system, the repositories will have root access to your host (and your data!)  and they can stop automatic installation of security updates if there are any problems. 
• Consider the privacy of others. 
  • If there are other users using the same machine, the root account can access everything that the other user can, including files, kerberos tickets, web browser cookies, keyboard and mice events, network traffic and the screen. There is no way around this, which means that root access can only be given to a machine where there is only one user, or to a group where everybody knows that this is the case. 
• You don't need root rights to install, compile or develop software.
  • Software can be installed and run from your own home directory, including binary libraries and daemons.
  • Most programming environments for scientific computing provide tools to manage library dependencies without any administrator rights (Python, R, nodejs and probably many others).
  • If an installer or a compiled software tries to install itself by default to a system location (like /opt or /usr/local), just change the default (yes, you might need to read the manual). This has the added benefit that your development will survive operating system and machine upgrades and can be reproduced later when the original machine doesn't exist anymore. And you can have multiple different environments if you have multiple projects. 
• Use a virtual machine or docker images for development and testing. 
  • KVM virtual machines are easy to setup and they can be easily replaced (or returned from snapshots) if anything goes wrong with them. 
• If some software or a library is missing from Cubbli or is just too old, ask helpdesk to install or upgrade it.
  • We mostly don't know about missing software or a software dependency unless someone asks for it first.
• There are plenty of web pages with bad advice.
  • If you don't know what the commands you are running actually do, consider not running them.
  • Also don't blindly copy and paste stuff straight to the command line. Put them through a text editor first for added security.
• The machine needs to be reinstalled before it is given to the next user.
  • We here at IT department do not always know that the machine has changed ownership, so you should mention it to helpdesk.