Attending

Gordon, Loren, Kevin, Mark, Daniel

Out of town:

  • Eric M., Klark

===Daniel===

Discussion Action
  • Work on health check script for uptime report
  • Collect and publish statistics for monthly report

===Gordon===

Discussion Action

Help desk monitor updates are in progress, building floor plans are ready.

  • Assure that help desk monitor updates are easy and doable by anyone including Loren and members of his group
  • Updated building floor plan
  • Help desk services report

===Eric===

Discussion Action

==== Email Confirmation ==== We discussed for fall semester requiring students to provide an email address as we were not creating email addresses for them (email resolution). A thought is to rather encourage them to update their Route-Y email and use Route-Y as the default reader. For example, on first login to an account, an email is sent to the listed Route-Y email. The next login is not allowed until the person responds to the prior email. We note that we will use the Route-Y listed email as our contact email with the student. If they do not like that email, then they might consider changes it to be something else, which we will confirm as well when we note the change from Route-Y. Thoughts?

==== Help Desk Review Schedule ==== I understand that we are going to review our help desk services much the same way we review our TAs each semester. When do we plan to do these reviews in Spring and Summer?

==== Review tickets ==== ====State of the Union Address: Computing Facilities==== We need to report to faculty what we are doing on the computing committee. How are we using our time and efforts? What are we trying to accomplish?

====SVN Servers====

  • Lab usage summary report for committee and faculty in regards to winter semester (general summary).
  • Add hardware to services table with backup policies along with Loren's systems.

===Kevin===

Discussion Action

==== Server Room AC ==== Kevin spoke with the AC designer, who passed along the message that this was not a good thing, and that we would like to be notified in the future before they do work in the room. However, they now have the ability to remotely control our AC system in the server room. Loren is working on getting automatic notification when they use the remote system to make changes. Also, the problems will be alleviated somewhat by the Fall when we migrate to newer equipment that is less sensitive to temperature fluctuations.

==== Computer Room Policy ====

Kevin is pushing this back a couple weeks.

  • Work at a higher level to coordinate maintenance in these server rooms with AC work — Make big stink about last incident to avoid it in the future where possible
  • Write a draft policy to manage resources in the new basement computer room: space, power, hardware, etc. Write draft policy by Jun 32nd. Need to include clearness in policies.

===Klark===

Discussion Action
  • Figure out how to allow open lab machines to be rebooted by faculty and students and come up safely without NFS problems.
  • Have the same version of the OS on the web server as on open lab and/or schizo machines – students need a way to develop code that will run on the web server.
  • Allow a combined CS/Route Y login for wireless and for consoles in open labs if possible. Would make it easier for faculty to provide access to non-CS students in their classes, and would provide a convenience for those who prefer to have one Route Y login for everything.
  • Obtain certificates for VPN server and get VPN working in general.
  • Migration plan to new server on Scheduled Maintenance
  • Email Daniel monthly downtime journal
  • Bring up lab 1057 and 1062 (set new date)
  • Write script to log students off of console at lab closing hours to encourage them to go home. Block console login when labs are closed
  • Assess and replace batteries to cover 3 hours of outage
  • Rename gin.cs.byu.edu to dasterdly.cs.byu.edu

===Loren===

Discussion Action

==== Drupal ====

Loren has a student learning Drupal and then will be creating ticket system version 2.0. Desirable features include: (a) showing only the last x days in the quick ticket analysis, (b) having a 'non-critical but ASAP' option for things like DHCP requests, etc., © providing a link for all the raw data that can be downloaded and imported into a spreadsheet.

==== AC Alarms ====

Loren sent email about getting automatic notification from the remote AC system.

==== Calendars ====

Loren now has the ability to use the CS calendar system to notify everyone about scheduled maintenance.

==== Airflow Controls ====

Loren will remove the cardboard airflow controls as soon as Tim starts putting his servers into the room, which will be soon.

==== Backups ====

Loren is providing backups on a regular basis. The wikis still need to be backed up in this system. We may need to start providing backups of class home pages (Gordon will check if this is a requirement).

==== SAS vs SAN ====

Loren got a very high ($80,000) estimate for getting the SAN on a maintenance contract and modernized. Wants to use a SAS for backups since it is cheaper. May need a SAN for virtual machines if a SAS doesn't provide connections to multiple servers for the virtual system. Needs to do a cost analysis to see if it is cheaper to have every faculty buy their own, inexpensive SAS for lab file servers or to pool resources and buy a more expensive SAN system.

  • Explore and report on Drupal as an option to unify the ticket reporting (quick and current system)
  • Tap into the AC alarms. When they turn off, then we need to shut down. SMTP traps to shutdown.
  • Visit with webmasters (use the calendar by default) to see what options we have to report scheduled maintenance in a more public way.
  • Remove cardboard airflow controls from downstairs server
  • Clearly define backup policy
  • Email Daniel monthly downtime journal
  • Explore SAS versus SAN option for disk array

===Mark===

Discussion Action

==== Status of Machines ====

Submitted a help ticket on this issue, but Klark is not sure this is a good use of student time. The main concern is that if a student or faculty reboots a machine, it fails to come up properly because of NFS issues. Moving this to an item under Klark's agenda.

==== Web Server OS ====

Submitted a help ticket on this issue. This is frustrating for students because they can't develop CGI scripts for classes and put them in their ~student/public_html directory – the server doesn't recognize the executable format. Need to find a way for students to have this capability — maybe move the web server to a schizo machine or to a virtual server with a matching OS?

==== Schedule Graphics Lab ====

The lab is now available on the CS scheduler.

  • Have sysadmins check status of machines
  • Web server needs to have same OS as development machines
  • Schedule graphics lab?
cc/18-jun-2009.txt · Last modified: 2014/09/23 20:28 by tmburdge
Back to top
CC Attribution-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0