|Host Self-Administration Guide|
|Written by Todd Green|
|Monday, 05 November 2007 00:42|
Host Self-Administration Guide
It is for SoC faculty, staff, and students who administer, or are considering administering, a machine that is connected to the SoC network. This machine may be one that is owned by the SoC or it may be a personal laptop (personally owned desktop machines are not permitted to connect to the SoC network).
It is likely that the only undergraduate students affected by this information are those who are actively involved with a research group.
Not affected by this information are users of machines administered by the SoC support staff and users of machines that are connected to the Flux, SCI, CoE, campus, or any other network.
This is a machine connected to the SoC network whose system administrator is anyone other than the SoC support staff. The administrator of such a machine is personally responsible for its behavior. Informally, if you have root on a machine, or administrator access to a machine running Windows, then it is self-admin and you are the administrator. The OS and OS version that the machine runs is not relevant.
For most SoC faculty, staff, and students who work for a research group, this is the preferred way to connect to the Internet while you are in MEB/WEB. Also, you get access to SoC services that are not available from outside our firewall.
Note that an alternate way to put a machine inside the SoC firewall is to use the SoC's VPN. Or to put that a different way, there is little effective difference between a laptop in MEB that is connected to the SoC network and a laptop in MEB (or anywhere else in the world) that is connected to the Internet in any fashion, and that is connected to the SoC VPN.
No. If you must have root access then self-administration is your only option.
Please keep in mind that being root is a very blunt tool and it may not be the best solution to whatever problems you are having. Self-administration requires substantial expertise and time.
Furthermore, many problems that initially seem to require root access do not actually require root access. We are happy to discuss various options with you.
Students and staff, please also include the name of a faculty member who can claim responsibility for you (i.e., your adviser, supervisor, etc.) so this can be added to your point-of-contact information for security issues.
On a Windows host you can bring up a cmd window and run 'getmac /v'. On a *nix based host you can run 'ifconfig -a' (on some platforms you need to be root to do this). Many machines have multiple interfaces (wireless, wired, VPN, VMWare, etc.) so please be sure to report the MAC address for the interface you intend to use.
If your ip address ends in an even number use 188.8.131.52, then 184.108.40.206. Otherwise list .71 first. 220.127.116.11 may be used as a tertiary server.
If it turns out you have inherited a self-admin machine, you have three main options:
Although option 3 is initially the easiest, it can lead to major problems in the long run if the machine contains customizations that you are not aware of or do not fully understand. Regardless, this machine is now 100% your responsibility and any problems with it are your problems.
For Microsoft based machines, people affiliated with the SoC have access to a vast array of software including several versions of the OS through our MSDNAA service. Please see our MSDNAA FAQ for more information. If there is additional software that you would like to install, that is your prerogative and responsibility. We suggest that you check with the Office of Software Licensing or the University Bookstore before making a purchase, as you can sometimes save money by purchasing through the University.
For Linux, software is freely available on the Internet for whatever distribution you might be interested in. Please note that we do keep a local mirror of several of the more popular Linux distributions, which will greatly speed up your installation. Please see our Site Mirroring page for more details.
For every machine that you administer, you must:
The immediate consequence is that your network port will be turned off and filtering rules specific to your machine may be entered into the SoC firewall. These measures are necessary to protect the rest of the users of the SoC network. To get these reversed, talk to the SoC support staff and convince them that you have fixed the problem and that you can prevent it from happening again.
If your machines represent a persistent security hazard to the SoC network (i.e. they keep getting hacked) or if some significant abuse of the SoC computing policy occurs, then machines that you administer will permanently lose access to the SoC network.
Yes -- this is unavoidable. For this reason we recommend that multiple users (e.g. in student labs) avoid sharing a single network tap if any of the connected machines are self-admin.
Basically any SoC service that can be authenticated on a per-user basis is available to self-admin machines. The major service that cannot be authenticated per-user is NFS. Available services include
The facility is designed so that most users do not need to be system administrators. If you choose to live outside of this structure by becoming your own system administrator, then you are largely on your own. A middle ground -- sharing administration tasks between users and the support staff -- has been found to work poorly in practice.
A copy of the Linux Administration Handbook may be checked out from the front office.
The web is also a great resource for both *nix and Windows administration. These are two of the many sites available for Windows administration:
The SoC support staff is happy to take over a machine again, provided that it belongs to the SoC in the first place. We will install a new OS image (Windows or Linux) on the machine. After this, the machine will no longer be a self-admin machine. In general, data cannot be preserved across this transition, it must be backed up somewhere else until the reinstallation is complete.