Service Desk Knowledgebase: Resources

From Computer Laboratory System Administration
Jump to navigationJump to search


This is the Resources content page of the CL Wiki Service Desk Knowledgebase. Its purpose is to provide information to the Service Desk team on how to handle problems and requests about this CL service. If you are involved with the provision of this CL service please feel free to add to the knowledge about that it.

If CL staff need to tell the Service Desk team about problems with this service please email
sys-admin-aside@cl.cam.ac.uk.

Return to the Service Desk Knowledgebase SERVICE PORTFOLIO

Key Service Description & URLs

William Gates Building Floor Plans (inc. Room Codes):

CL Customer Documentation

Further CL Sys-Admin Resources

[NOTE: The Personresponsible is actually the one who is financially responsible.]

People

Equipment storage

All the monitors on the bottom shelf of the racking on the West wall of room GC20 are available.

Underpinning Services

  • Computer Lab Administration Database, Mail Server, Networking & RT

Customer-base for this Service

  • All staff and students of the Computer Laboratory

Costs

  • Visitors, Interns & RAs equipment should be funded by the Sponsor for anything substantial but short term loans are possible
  • RARS (Research Assistants registered for a PhD) should be treated as RAs but some funding bodies do not permit this (in which case Lab funding is used)
  • Staff equipment for new arrivals is funded by the department

SLA

  • N/A

Service Desk Call Handling Procedure

  • RT tickets can be escalated by changing the Queue to backoffice with the Owner set to Nobody and the Status as new. Tell the requestor:
    I am passing this request over to the experts who will be in contact when they have more questions or have some progress to report.

Delaying RT Tickets

  • To delay a ticket for automatic re-activation on a given date set the Status to Stalled then use Dates to set a Due: date and [Save Changes].

New Research Students

Processing of postgraduate student admissions by administrative staff automatically generate an RT ticket with the following format:
Academic Year RS GivenName FamilyName crsid kit
for example:
#96184: 2015/10 RS Marcel ten Wolde mw245 kit
when they are added to the database.

The body of the message contains the name and crsid of the supervisor and the email address of the Research Student (RS). For example: 

 Supervisor: gt19
 Email: mw245@cam.ac.uk

The following procedure applies ONLY to the above messages and NOT to other New Arrivals (where the New Arrivals procedure below should be used instead).

graduate admin

The auto-generation of these tickets relies on various heuristics which are sometimes wrong, and sometimes things change. The definitive source of all information relating to RSs (and RARSs) is graduate-admin@cl.cam.ac.uk. Information channels are not always clear, so if you get any information, please pass it on. If anything unexpected is revealed (a RS or supervisor says that a RS is not coming; someone says that the arrival date has been deffered; etc) forward the email graduate-admin@cl.cam.ac.uk pointing out the anomaly, and asking for confirmation that 'the system' is wrong and needs updating. Do not use an RT comment to do this, as graduate admin cannot 'reply' to an RT comment.

STOP Before progressing at the start of each intake, please ensure the year (paragraph 1) and date (paragraph 2) are updated for the new year in the pro forma email in phase 2 sent to students. If in doubt of the correct date, speak to graduate admin graduate-admin@cl.cam.ac.uk

PLEASE NOTE The workflow is changing for this process, and the below instructions are currently being revised, and will be updated in due course.

Phase 1

  • Before doing anything with this ticket link it as a child of this years parent ticket:
    #115779: AY2020-2021 PhD RS arrivals parent ticket 2020/10 RS
  • Note the student's name/CRSid and copy the child tickets's RT number
  • Visit the arrival tracking database, add the RT ticket number to the PhD database by clicking on Select of the appropriate record then Edit the table that appears and insert the value as a number only, set Status to "supervisor" and click on Update.
  • The next step is to return to the child RT ticket copy the supervisor's CRSid and use People then Type: Requestor and E-mail: CRSid and select CRSid@cl.cam.ac.uk and then Requestors: [tick] "Graham Titmus" <gt19@cl.cam.ac.uk> and [Save Changes] to make the supervisor as the sole requestor of the ticket.
  • Before emailing the supervisor, you need to establish if the incoming RS is already a user at the lab with a machine, by using the staff list and inventory (e.g. they could be an RA who is going to start a PhD). If they are already here and have a machine, use Display and Reply to the initial email to confirm with the supervisor whether or not they will continue to use the same machine. If they are continuing with the same machine then go to Phase 2, as more work may be required on the machine (e.g. they may want the OS to be refreshed etc).
  • If they require a new machine (e.g. they are a new arrival, an existing user who's supervisor has advised they need a new machine, or they are a historic user returning after a while) then use Display and Reply to the initial email (or the email confirming a new machine is required) with the following message (note: If they are an existing user who's machine is being replaced, the first paragraph can be omitted):
 You have one or more Research Students arriving this year.
 
 Are you happy for us to ask if they will be arriving with a laptop and can use 
 that for the first month or so until it is clear what their requirements will be? 
 
 Or do you as Supervisor want to recommend particular 
 HW or OS, or even restrict the choice to a particular HW or OS?  
   
 We will contact the student directly to decide what they
 want if you allow them to choose.
 
 http://www.cl.cam.ac.uk/local/sys/platforms/
 
 Regards,
  • Put the following comment into the RT ticket:
 Go to Phase 2 of the New Research Students procedure at
 https://wiki.cam.ac.uk/cl-sys-admin/Service_Desk_Knowledgebase:_Resources#Phase_2
 when the Supervisor replies with the requested information.
  • Then set the RT ticket owner as nobody with the status as stalled with a Date Due of one week hence.

Phase 2

  1. Copy the student's email address from the initiating email
  2. Click People to set the following:
    1. Type: Requestor and E-mail: student's email address for the student
    2. Type: Cc and E-mail: CRSid and select CRSid@cl.cam.ac.uk for the supervisor
    3. Requestors: [tick] <CRSid@cl.cam.ac.uk> to remove the supervisor as the requestor
  3. [Save Changes] to make the student the Requestor and the Supervisor the Cc
  • Display the RT ticket
  • If you established in Phase 1 that the Research Student has a CRSid, and you have confirmed the student is already in the Inventory database as an assigned user of a machine (i.e. is already at the CL). Then, note the details and add the machine's name to the RT Ticket's subject.
  • Update the arrival tracking database
    • update Status. If the supervisor has specified the system to use, select the appropriate value, such as Install OS, Install HW or completed. Otherwise, set it to Student - asking student for their requirements
    • update the Notes field. If the supervisor has stipulated a preferred or mandatory provision then briefly summarise the info, along with any information from the Inventory database. For example:
 CRSID mw245 
 USN 301711634 
 RT 96184 
 OS Std Linux  
 Hardware std PC and LCD  
 Machine 19138
 Status completed
 Notes keep existing machine

STOP Before progressing at the start of each intake, please ensure the year (paragraph 1) and date (paragraph 2) are updated for the new year in the pro forma email in phase 2 sent to students (below). If in doubt of the correct date, speak to graduate admin graduate-admin@cl.cam.ac.uk

  • Using Reply email the incoming Research Student with the following message (editing as required):
According to the database, we are expecting you to come to the University
of Cambridge Computer Laboratory to start a PhD in October 2019. Welcome!

Are you still planning to come then?  If so then please note that you should
not expect any departmental resources to be available ahead of the induction date (Tuesday October 8th).

If you are coming, you'll be allocated a pool machine as described in
the link below, which also has information about the choice of operating system.
  
http://www.cl.cam.ac.uk/local/sys/platforms/
 
Regards,

If they already have an assigned machine add: 

I note you are already using machine "<<machine name>>", would you like to continue
to use that and if so do you want the OS refreshed to the latest version, leaving
scratch space as it is?

If the supervisor has specified or suggested an operating system add the following (with the appropriate OS and machine type set): 

Your supervisor has suggested you start with Ubuntu 18.04 LTS on a standard Computer Lab PC
Please let us know if you don't think that is suitable.

If the supervisor has not specified anything then add: 

Please let us know what equipment and OS you would prefer.
  • Put the following comment into the RT ticket:
 Go to Phase 3 of the New Research Students procedure at
 https://wiki.cam.ac.uk/cl-sys-admin/Service_Desk_Knowledgebase:_Resources#Phase_3
 when the Research Student replies with the requested information.
  • Then set the RT ticket owner as nobody with the status as stalled with a Date Due of one week hence. If the due date is reached and the ticket reverts to open, email the Research student again as above, and stall the ticket again with the date another week hence.

Phase 3

  • If the Supervisor replies that the student is not coming: pass the info on to graduate-admin@cl.cam.ac.uk by email (not RT) , mark the ticket as Rejected, move it from being a Children: to being Referred to by:, and update the arrival tracking database to have Status of withdrawn or deferred and summarise it briefly in Notes.
  • If the Research Student says that they are not coming: thank them, email their supervisor, pass the info on to graduate-admin@cl.cam.ac.uk by email (not RT) , mark the ticket as Rejected, move it from being a Children: to being Referred to by:, and update the arrival tracking database to have Status of withdrawn or deferred and summarise it briefly in Notes.
  • If the Research Student replies with "I have not yet received a formal offer":
    • pass the info on to graduate-admin@cl.cam.ac.uk by email (not RT)
    • Stall ticket until the RS receives an offer, graduate admin convinces the RS that (s)he does have an offer, or the offer is declined (as advised by Graduate Admin)
    • Update the arrival tracking database Notes field with a *brief* summary of the info useful at *this* stage of the process with something like:
      "Has not received formal offer. graduate-admin asked to clarify"
    • Issues could be:
      • formal letter was sent, but didn't arrive
      • formal letter should have been sent, but by mistake was not
      • the automated WorkFlow has triggered a user to be put into the system too early (gt10 needs to fix)
  • When the Research Student replies with their requirements:
    • Add the options they have chosen to the PhD arrival tracking database - Select and then use Edit at the bottom of the list, e.g.
      OS: Linux
      Hardware: Std PC and LCD
      Status: Allocate - Awaiting allocation of equipment
    • Thank them for the information using a message such as:
Thank you for letting us know about your requirements.  If we need any further 
details we will contact you shortly.

In the meantime you may care to familiarise yourself with the IT ethos of the department
by reading
http://www.wiki.cl.cam.ac.uk/rowiki/SysInfo/BedtimeReading
and the pages to which it points.
  • The RT ticket then needs to be passed on to backoffice queue to provision with status set to new and owner to nobody.

New arrivals

Processing of new arrivals by administrative staff automatically generate an RT ticket with the following format:
CRSid has a HR Role starting ??/??/2015 requiring equipment v#VisitorID visitor name
when they are added to the database.

  1. Copy the RT ticket number (without the #)
  2. Click on the URL in ticket like: https://dbwebserver.ad.cl.cam.ac.uk/Administration/Visitors/VisitorDetails.aspx?ID=999
  3. Enter your CRSid & Computer Lab password if requested
  4. Click the [Edit] button at the bottom left of the form
  5. Paste in the RT_Ticket & click [Update]
  6. Desks & Rooms: Allocation of desks/rooms is done by Reception - we don't care about them until we actually need to install equipment. Reception see a parallel workflow and use the OpenRoomMap (ORM). If there seems to be a problem, contact them, and ask them which desk/room to use (but remember that they cannot reply to an email sent to them using an RT comment!) Once the 'OpenRoomMap (ORM) is updated use it to see where the user 'will be'. If room information is available [Edit] Allocated_Office & [Update].
  7. Copy notes for any specific instructions to paste into the RT ticket
  8. Return to RT
  9. Click Comment and paste specific equipment requests into the RT ticket
  10. What happens next depends on what's been requested and who has the equipment:
    • If there are no specific equipment requests Reply to the RT ticket requestor asking:
      What do you intend to provide for the person please?
      In RT set the Owner as Nobody & Status as Stalled (with a suitable Due date) & leave the Queue as Sys-Admin and then [Edit] the inventory database Equipment_state with Asking and [Update]
    • If a computer has been requested or allocated to the person but is already allocated to someone else who is still here, Reply to the RT ticket requestor asking if the new person should be made the "assigned user" of the computer (i.e. User in the inventory, the person who has 'cl-asuser' and 'sudo' privileges to do things such as install software on a managed Linux PC, & have access to the machines BMC if it has one). In RT set the Owner as Nobody & Status as Stalled (with a suitable Due date) & leave the Queue as Sys-Admin.
    • If a non-specific machine (e.g. Linux machine) is requested for an RA, reply and ask the PI whether they already have a machine, or whether they want to buy one. If they say that their grant explicitly forbids buying WSs, then they are allocated a charity case or grace and favour machine - see Special information for re-use of PCCL0xx machines for 2015/10 for more on this for the academic year 2015/16.
    • If a computer has been requested or allocated to the person and is not allocated to anyone or their end date has passed then the new person should be made the "assigned user" (i.e. User in the inventory, the person who has 'cl-asuser' and 'sudo' privileges to do things such as install software on a managed Linux PC, & have access to the machines BMC if it has one).
    • If access to servers is required Reply and CC the Sponsor/Personresponsible for each server as they need to formally agree to that access in order to meet the Cam AUP (even though almost all machines are accessible by anyone in the Computer Lab by default). In RT set the Owner as Nobody & Status as Stalled (with a suitable Due date) & leave the Queue as Sys-Admin.
  11. When all the required information has been gather escalate the RT ticket by leaving on the backoffice queue with Status as new and Owner as Nobody. Backoffice will assign a machine and then handed it over to the operators for the actual install of the OS and the positioning of the hardware.


NOTE: If the user has their own laptop/equipment then we will need to check this is OK by asking the user to let us know if there are problems with its connectivity. You may also consider asking the user if they are happy with a connection to Eduroam/WiFi or do they require a wired connection. Finally send a reply on RT such as: 

 Dear 'Name',
             I notice you have chosen to use your own machine here the computer lab.
 If your machine has not been registered in the CL inventory then please register the machine at
 https://dbwebserver.ad.cl.cam.ac.uk/sysadminuser/RegisterNewMachine.aspx?return=DHCPRequest2
 and send us the MAC address of the machine.
 
 Regards
 
 Rob Taylor

Machine Install

This is logically an operator task but is usually done by the helpdesk. Instructions are at Machine Setup.

Post-Install Tasks

When the operators have completed their tasks they will pass the RT ticket back to sys-admin for the following POST INSTALL tasks to be done. Some are needed by all systems, some only by certain ones (e.g. Linux, Windows, Unix, Macs or Has a BMC. Note that Linux, Macs and FreeBSD are all Unix). So for all systems you need to:

4.0 Check Database: 4.1 WoL - Wake on LAN: 4.5 Machine name: 4.6 Tell the user - when done: 4.9 Finishing up:

BUT If it says do this 'type' then do it only of the machine of 'type' (e.g. Linux, Unix, Macs, Windows). The conditional ones are: BMC Accessibilty - if present: 4.2 ssh_known_hosts (Unix): 4.4 User Admin (Linux): 4.7 ownfiles (Unix):

  • 4.0 Check Database:
    Check the RS database or "Visitors" database work queue to check the person's details and the task is marked "post-install - Complete Post install tasks" in the case of an RS, or "Post-install tasks to be done" in the case of a visitor.
  • 4.1 WoL - Wake on LAN:
    To ensure that WoL is available, on laira run:
/usr/groups/netmaint/boot/wol_file-add.pl $HOST

If it reports: 

/usr/groups/netmaint/boot/wol_file-add.pl: FAILED: missing MAC address

then find the machine's MAC address in the Inventory then use the following to specify the MAC address (with or without colons): 

/usr/groups/netmaint/boot/wol_file-add.pl $HOST $MAC-ADDRESS

for example: 

/usr/groups/netmaint/boot/wol_file-add.pl gwendreath 0023AE91CFC1

When the entry is added, install it on the web server using 

make -C /usr/groups/netmaint wol

If you need to remove a MAC then use: 


 rjt58@laira:/usr/groups/netmaint$ ls boot/wol_file.src
 boot_wol_file.src

To find the file and then: 

 rjt58@laira:/usr/groups/netmaint$ vi boot/wol_file.src
 rjt58@laira:/usr/groups/netmaint$

Once you've edited the old MAC and added the new the repeat the: 

 make -C /usr/groups/netmaint wol

to complete the task.



  • BMC Accessibilty - if present:
    If the machine has a BMC (true for most machines, not Macs) check that the address is pingable (it may take 30 seconds for it to wake up) and then check the "assigned user" access to BMC: on svr-ssh-1, sandy or laira run cl-amttool $host user list
 kikyo-bmc  Registered 3 AMT user accounts:
  $$uns                  1 realm    LocalAccessPermission    Enabled  <system account>
  $$OsAdmin              6 realms   LocalAccessPermission    Enabled  <system account>
  qg216                 21 realms   AnyAccessPermission      Enabled

to check that the user has AnyAccessPermission Enabled. This may fail on newer systems - it is not a problem, process anyway. On laira, check that the user credentials are correctly setup using 

AMTUSER=$CRSid PAGE=index,acl /usr/groups/netmaint/iamt-web $host

which should show a summary and then "User names: [One of: $CRSid]". If it does the former, then reports "/usr/groups/netmaint/iamt-web: acl.htm from $host-bmc failed 6: Username/password authentication failure.", the user has not been granted full access. If there are problems, follow the procedures at (4.7) BMC ACL - when up if present.

  • 4.2 ssh_known_hosts (Unix):
    To be able to ssh to Linux or Mac machines, the host's ssh key needs to be known. So long as the machine is up and running an ssh server, on laira it should be possible to
/global/src/usr.bin/ssh/fetch-host-key scan $HOST

to get the info, and if there are any changed, then run: 

 sudo ssh -tt radyr '(cd /global/src/usr.bin/ssh && make dist)'
 sudo cl-update-system

to make the new ssh keys available on laira.

  • 4.4 User Admin (Linux):
    If oper were not told the 'assigned user', on $HOST so after ssh -K into the $HOST run the following to check the assigned user:
cl-asuser cl-hostid-fix --user $CRSid

The output shows what needs to be done to make that $CRSid the "assigned user" so NO OUTPUT is good! Should things need doing to make $CRSid the "assign user" then use the following to change the assigned user: 

cl-asuser cl-hostid-fix --user $CRSid -a
  • 4.6 Tell the user - when done:
    Check that the machine name *IS* actually in the RT Ticket's subject line - if not add it first then send 'std email' to user [NOTE: make the user a requester on the ticket and send the email on ticket, rather than just emailing them, as it's useful to have a record of the communication]. The email might be along the lines of:
 The machine mentioned in the Subject: line has now been re-installed for 
 you and should be ready to use. Please login and check that the basics work, 
 i.e. that you can login, access the web, and send email.  If not, please 
 reply to this ticket, which will re-open it, and we will try to sort the 
 problem.

 If you have other requests, please do NOT reply to this ticket, 
 but instead open a new ticket, and mention this one.

 Now may be a good time to look again at
 http://www.wiki.cl.cam.ac.uk/rowiki/SysInfo/BedtimeReading
 and the pages to which it points.
  • 4.7 ownfiles (Unix):
    To ensure that ownfiles data is collected for Linux and Mac systems, on laira run
(umask 2; cd /usr/groups/linux/ownfiles/CKSUM/; test -e $HOST || touch $HOST)

normally if a command works it just returns. It is possible to check it did complete by checking the return code on the line after the command you can type 

 echo $?

and you should see a 0 if it worked correctly.

  • 4.8 Finishing up:
    When the above is completed, update the RS or "Visitors" work queue to mark the task to be "completed" in the case of an RS, or "OK" in the the case of a visitor (also adding the Inventory number and name of the PC after, e.g. "OK Inv#16200 ouse") [NOTE: The Equipment_state field requires OK Inventory No.???? MachineName to complete it and stop it being picked up as a "Outstanding equipment requests for arriving visitors/staff".] and update the RT Ticket with a comment of the collected history for 4.7 to 4.8 then Resolve the RT ticket.

Creating accounts for people arriving

See Account creation request for <CRSid> arriving <date>" or Outstanding equipment requests for arriving visitors/staff

Requests for machine moves

The move process involves:

  1. Reception allocate people to a free desk in a room using OpenRoomMap (ORM).
  2. When people are physically moved into a room, whoever moves them (e.g. the operators) checks that the OpenRoomMap (ORM) information is correct, reporting any erros to Reception, then moves them and when the move is complete updates the Staff List.
  3. Users can update their details within a room (e.g. if they move tables etc).


Requests for machine moves are raised by Reception after they allocate a new office.

  1. Take the RT ticket and check the equipment the person has in the Inventory.
  2. Check what phone may need moving in the VOIPList.
  3. If there is some equipment to move then list it and pass the ticket over to the operators.
  4. Set the Queue to oper, the Owner to Nobody and with Status as new.

Post move

After the operators have moved the machine they should provide details of which port the machine is now plugged into on the ticket and pass it back to the sys-admin queue. In the case of just moving a machine (rather than installing a new machine), the only checks which are needed are that it has been correctly network connected, so a simple "ping" of the host is sufficient to check that the wiring is correct and the port correctly configured. As the SW, BMC, etc have not been changed, there shouldn't be a need to check them. So do the following checks:

0. Check the ticket:
Check that the ticket's Subject: line includes all the info, such as the user's CRSID, the rooms between which the move is being made, the name of the machine(s), whether there is a phone, etc.

1. Inventory Check:
Take the RT ticket and then update the inventory with the new location for the machine and its LCD.

2. Staff List Check:
Check that the information in the Staff List and the OpenRoomMap (ORM) is correct. If not then email Reception@cl.cam.ac.uk to get it updated.

3. VLAN:
Using Updating VLANs in the Cisco switches note the VLAN of the old switch port and then set the old switch port where the machine was to no longer be on the VLAN it was with no switch port access vlan vlan# then set the new switch port to access the VLAN that was removed.

4. BMC Accessibility - if present:
Check that the wiring and configuration is correct by pinging the BMC if it has one. Note that iAMT BMCs may take 10 seconds or so to respond, so give it a while. For host $host use the command

ping -c 15 $host-bmc

5. host Accessibility - if no BMC:
It the BMC accessibility test could not be used, then find the host's name and ping it. If the raw name does not work (ping -c 3 $host), look for it in /global/src/etc/named/src/cl.data (grep $host /global/src/etc/named/src/cl.data ), or guess the domain from the VLAN - e.g. $host.ad for windows, $host.mac for a Mac, etc. If the name is found, but it does not respond, try waking it, e.g. by running "cl-boot-mc $host". If it is still not pingable, when contacting the user to say that the move has been done, explain that it has been moved but that it was not possible to test the wired connection, and ask them to confirm whether it works. If it does not, check the switch configuration, and if there isn't an obvious fix, ask the operators to investigate.

6. Notify user:
If the Accessibility check worked, resolve the ticket taking care to send a copy to the requestor saying what has been done (e.g. what was moved). If it was not possible to check the networking, do an RT reply saying what has been done (e.g. what was moved), and asking them to check that the network works. Stall the ticket for a week. When it is known to work, resolve the ticket.

Leaving Procedure

We will be notified of someone having been marked as left in the database by an RT ticket with a title like User crsid (supervisor crsid) has left - complete tidies in which case start at step 2.

If you are told someone has left then start at 1.

1) Tell Reception that the user has left - they update the staff list at https://dbwebserver.ad.cl.cam.ac.uk/Administration/HR/HRList.aspx to say the user is no longer Valid.

Put something like: 

 'Dear reception,
        It appears this Phd student 'NAME'  (crsid) who was located in office 'Location' has left as of
 'DATE'. Can you please update the Database to reflect this change?
 
 Kind regards.
 Rob'

2) First, check the user is not valid before proceeding (they could have been marked invalid in error, spawning the ticket, but immediately marked as valid again). Contact the user and/or their supervisor to make sure they have actually finished. If they have not, their supervisor should be able to tell us their new finish date or approve them staying on as a "discretionary" user.

Use People then Type: Requestor and E-mail: CRSid of supervisor and select CRSid@cl.cam.ac.uk and then Requestors: [tick] "Graham Titmus" <gt19@cl.cam.ac.uk> and [Save Changes] to make the supervisor as the sole requestor of the ticket.

Use Display and Reply

Check the Inventory Database to see what equipment is assigned to the user and tailor your reply relevant to this information. The user may be registered in the Inventory database as having lab owned pool equipment, lab owned non-pool equipment, non-lab owned equipment, a combination of these or no equipment.

Below are examples of the sort of reply you will be giving (these are not comprehensive examples due to the fact that the message will be tailored). 

 Hello
     
 I have a ticket stating that ‘NAME’ (crsid) has now left the Computer Lab. Is this correct?
 
 (crsid) is the registered user of a PC named $HOST (Inventory #12345).
 
 If this user has left, I will arrange collection of the lab pool equipment described above.
 
 Kind regards
 
 'YOUR NAME'  

 Hello
     
 I have a ticket stating that ‘NAME’ (crsid) has now left the computer lab. Is this correct?
 
 The inventory is showing that this user is not assigned any equipment. Can you also confirm whether or not this is correct?
 
 Kind regards
 
 'YOUR NAME'  

 Hello
 
 I have a ticket stating that ‘NAME’ (crsid) has now left the Computer Lab. Is this correct?
 
 (crsid) is the registered user of a PC called $HOST (Inventory #12345) and its corresponding monitor 
 (Inventory #12345). What would you like me to do with this equipment? (e.g. assign it to another user or donate 
 it to the lab pool etc)
 
 (crsid) is also the registered user of a laptop named $HOST (Inventory #12345). This device was not 
 purchased with lab money, is this a personal machine that can now be deleted from the inventory?
 
 Kind regards
 
 'YOUR NAME'

3) Anything which is 'Lab pool' (typically owned by 'RTSG', pb22, gt19, 'Lab', 'PWF' or other pseudo users) should be returned to GC20 - ask oper to do that - phone to GC12.

4) Update hosts.props using WHERE=WHERE_GC20 /global/src/usr.lib/hosts.props-add.pl $host (For information, when a machine is taken from GC20 and deployed you would use WHERE=unset /global/src/usr.lib/hosts.props-add.pl $host)

5) Check if the person has a valid off-site address registered. If not then contact them or if they don't reply their supervisor to ask for a valid email address to forward then @cl.cam.ac.uk email to. Add this to their entry at https://usermailadmin.ad.cl.cam.ac.uk/forwarding.


[NOTE: STUDENT MOVES:- Students may be moved to a Hot Desk/Writing Up area (the Library) before actually leaving. OpenRoomMap at http://www.cl.cam.ac.uk/research/dtg/openroommap/static/ shows where people 'will' be - it's used for office allocation by Reception. The Staff List at https://dbwebserver.ad.cl.cam.ac.uk/Administration/HR/HRList.aspx shows where people (and their kit) actually *ARE* and is updated by Reception. It is differences between the two which generate the WorkList for the operators to move people etc, so if the Staff List is not updated by Reception when kit (and thus people) are moved, the move remains on the WorkList. Reception@cl.cam.ac.uk may need to be asked to do this.]

User Can't install Software under Linux

See Adding privileged or 'assigned' users

Machine Hardware Problems

Graham Titmus (22 Apr '15)

Machines with noise issues etc.:
Change the RT ticket queue to hw-admin with status New AND email a comment Nick Baterham (nb@cl.cam.ac.uk) to alert him.

Operating System Upgrades

and

Dual boot requests

Piete Brooks (06 May '15)

Dual booting is discouraged in favour of running virtual machines instead. The options are either Computer Lab Windows + virtual Linux, or Computer Lab Linux + virtual Windows See http://www.cl.cam.ac.uk/local/sys/platforms/#dualboot

Reclaiming Equipment after someone leaves

1) Ask the visitor's sponsor if the visitor has left and if it's OK to reclaim the equipment
2) Once the sponsor has replied in the affirmative, add 'Reclaim' to the subject line and move the ticket to the Oper queue

Removing a physical machine or a VM

When a machine is no longer required then the information about it needs tidying up.

Information in the following places should be updated.

  • delete from DNS - comment out the line to remove this and check it is not target of any CNAMEs
  • delete from hosts.props - comment out the line or delete.
  • cease ownfiles processing and archive -
  • remove any DHCP entries - go to inventory record and then each interface and delete each DHCP record in turn.
  • mark machine deleted in Inventory - updating the deleted_bool flag will cause the deleted date to be set.
  • check not in the router ACLs especially if this machine has acted as a server.

Contacts

Primary

Availability

  • Monday:
  • Tuesday:
  • Wednesday:
  • Thursday:
  • Friday:
  • Saturday: Closed
  • Sunday: Closed

Hints, Tips & Known Issues

Finding out a machine's operating system

Graham Titmus (26/05/15)

Whilst it's only the best guess you can try logging into laira and running the command:
cl-hosts -p MachineName
to find out what operating system a machine is believed to have.


Typical "Standard Lab PC" (Linux & Windows) Spec.

Graham Titmus 

 Typical Standard Computer Lab PC Spec. Dated 15/04/15:  
 
 Qty     Item            Price   Total   Description 
 1       Med-ATXB        £66     £66     Med Tower ATX Case High Efficiency 80Plus 350W PSU 
 1       SH-W163A-BL     £18     £18     Samsung Internal 22xDVD-RW SATA Black 
 1       Q87M-E  £98     £98     ASUS 1150 Q87M-E Executive Series /SI M-ATX Haswell 
 1       SV300S37A/240G  £70     £70     Kingston V300 - 240GB - Read 450MB/s - Write 450MB/s - 533 DW 
 1       i5-4670 £169    £169    Intel Haswell Core i5-4670 3.4-3.8 GHz 4 Cores, 84W, HD Graphics 4600 
 2       KVR16N11/8      £53     £106    8GB 1600MHz DDR3 Non-ECC CL11 DIMM 
 2       25SATSAS35      £11     £22     StarTech.com 2.5 inch SATA/SAS SSD/HDD to 3.5 inch SATA Hard Drive Converter 
 2       HSB100SATBK     £14     £28     StarTech.com 5.25 inch Tray-Less Hot Swap Mobile Rack for 3.5 inch Hard Drive 
 1       USB2.0Header    £3      £3      USB 2.0 Header plate 
 1       Header  £5      £5      Serial Header plate 
 1       USB3.0Header    £9      £9      USB 3.0 Header plate 
 1       K/B-Mouse-Bl    £17     £17     Microsoft USB Wired Desktop 600 Keyboard+Mouse Black 
 Total:          £611.00 
 Discount:       £30.55 
 Total Ex-VAT:   £580.45 
 VAT:            £116.09 
 Total:          £696.54
 
 to which you need to add a screen - a 4K screen costs about £300 + VAT.

Categorising Keywords

  • Resources PC machines new arrivals upgrades failures
Retrieved from "https://wiki.cam.ac.uk/wiki/cl-sys-admin/index.php?title=Service_Desk_Knowledgebase:_Resources&oldid=3536"