Engineering Computer Committee

February1 and 3, 2006

Attending: Matt Kuhn, Sig Lillevik, Kent Thompson, Peter Osterberg

Guest: Joe Holstein (IS)

Matthew reminded everyone our meeting’s goal was to put together our (Engineering’s) functional requirements for IS / Bryon. Peter’s table is oriented towards both hardware and support services. The committee has been asked to specifically indicate on a table provided by IS, the functional requirements, currently provided by hardware in Room 214.

Matthew will create a list of functional requirements which will be included in the School’s 5-year plan. This plan will be sent to Bryon as a letter from Zia. Faculty will have the opportunity to comment on a draft of the letter.

As indicated by Bryon and confirmed by Kent and Joe, modems will be going away. Dial in access to the S drive and specific machines will be accessible via putty, telnet or WinSCP for now.

Minimum requirements for Engineering:

Access to files on the “S” drive or future comparable drive and files on PC remotely and on campus

Ability to read / write on various applications from campus or remotely

Ability to access own personal websites and publish from home and remotely

Provide remote UNIX shells from home windows boxes

“Native” UNIX applications, Unix emulators, Linux for classes/labs. Specific needs for this application are to be able to:

Compile

Debug

Network access

Access to printers in Unix / Linux file servers and environments

Program development

Call up “X-Term” for all commands

Unix software required is LEdit, MatLab and PSpice in addition to windows versions of these software programs

All Sun machines up and running

IMAP server – provide capability of archiving email and ability to handle large applications sent by students to faculty for class/project homework, report and/or projects

Unix print service and more network printers for faculty – at least one large capacity printer on each floor.

Need ftp access to Lewis

Keep drive replication services

ACM club needs servers for club activities

Wireless network in Engineering compatible University-wide

Kent is currently working with IBM on a “Linux on Power” project that includes University of Portland and 2 other locales worldwide. What we need is documentation that Kent is working with IBM on specific projects if we want to maintain our relationship with IBM and inform IS / Bryon of what and how this benefits Engineering and UP. This project is only on two IBM machines – ibm4 and ibm5.

Peter felt that Bryon’s issue with the IBM machines was that we are violating University Bylaws, but we need to clarify that is not the case.

Sun machines do authentication and network services for all engineering workstations. If sun0 and sun1 were turned off, it would black out part of our world as these map to our domains. While we have an engineering network, these are essential. When we no longer have an engineering network, these may no longer be needed.

If the goal is to make all networks across campus compatible and similar, a concern was raised as to our desire to have non-engineering students using our computer lab because it’s available, accessible and open. How could we limit use on our engineering computers to only engineering students? We’re also required by some software companies and our agreement with them (MSDNAA, in particular) to allow access to those programs to ONLY engineering students. We do not want to jeapordize relationships with vendors at the expense of being “accessible” to everyone.

Kent suggested, as an idea, that ACL’s could be developed that would keep programs and computers exclusive to our students.

Kent provided an Engineering Network Node List that includes some machines that are not on the IS list. These need to be kept as machines that Engineering currently uses for classes / labs and faculty/staff applications. They are:

guardian = DNS

up = firewall, nat, port-forward

sun, sun0, sun1 = NIS, print drivers, license servers

suns = applications (this is ALL sun machines, not an “s” machine)

ibma = administration files (servers that house staff files)

ibmd = imap

ibmb, ibmc = Windows license servers

ibme, ibmf = CS (Linux machines, alternate telnet machines. Network monitoring tool on ibmf)

ibm0, ibm1 = UNIX print services (currently qpr printer – only network printer available to faculty in Engineering)

ibm4, ibm5 = IBM (Kent’s project with IBM)

ibm7 = modem server

ibm9 = web server

ibm48 = security (main access for portals, remote shell)

ibmg = remote ssh, CS (ibmf and ibmg are clone sisters, provides “contrib.” Capabilities)

file1a = faculty files (S drive)

file2a = student files

It was also requested that any changes / deletions / upgrades to our current computer set up in Engineering 214 have Kent as a key part of the team so we ensure continuous service and reliability with our system change-over. Kent originally built and designed the engineering network and is familiar with specific needs and requests for our programs for our students, faculty and staff.

IBM servers provide a variety of functions, as noted in Kent’s list above. Removal of these would affect Engineering.

Question was asked if we lose ibm9, which is our current machine for personal websites via contrib, how would this affect engineering? Sig puts all his information on lewis and that seems to work well, as long as it’s up and running. Sig said that the University’s version of ftp to Lewis has some kind of “special sauce” in front page that makes it work well.

Kent was asked how Engineering would be affected if guardian/DNS machine was turned off. Our network would disappear. However, Kent indicated that if it was done in a transitional way, he would be able to help the transition without losing valuable service and access to machines.

Our IMAP server according to Kent has more capacity than Outlook / University server. Do we want to preserve? Yes as we need some capability to archive email and able to handle large applications sent by students to faculty for assignments, projects, etc.

S:\office\faculty\kuhn\OCIO-EGR Computer Committee\MeetingMiutes_Feb1and3.06.doc