The Triquetra

 
Résumé
index

Résumé
(summary)

Thoughts
(Yes, I do
have them.)

Humor &
Poetry
(adult)

 

 

Assistant Director, Systems,
Academic Technology Services
Northeastern University
Boston, MA. 02115
1992 > present

Skill Sets Accomplishments
management skills, planning, software engineering, C, PERL, CGI, Apache server, HTTP, HTML, DHTML, system administration, security, system security hardening, sendmail, network administration, TCP/IP, client server models, NFS, NIS, UNIX (various flavors), MySQL, DBI/DBD PERL interface to MySQL, SQL, VMS, shell programming, real-time programming, network programming, distributed systems.

I ran the academic systems group at this point. Since I ran the group, one can safely make the assumption that my hand was in everything mentioned here. I either I did it, oversaw it, or was involved in it. Systems supplied support for at least the following services at NU. And please note that the entire Systems staff consisted of me and two other people as of December, 1998. We’re a busy little group. As of October 1999 the systems group consisted of me and one other person, I was the entire programming staff. Some, but not all, of the things we supported, maintained, have created and occasionally hand hold are, [Top of page]

 
 
mail tracing, news tracing, header reading, security programming, cisco routers, filtering, packet tracing, wrappers, probing, policy writing, interfacing with law enforcement agencies.

 
System security services for networked systems was a top priority for the Systems group. Networks can be dangerous places and there is no C2 or better certified general purpose operating system on a network today. Systems was therefore involved heavily in hardening it’s own UNIX, VMS (when they were still here), and NT systems, firewall port blocking with routers, determining threats to systems on campus, and tracking down those who abuse the systems at Northeastern whether they are internal to or external to Northeastern including harassment, threats, and fraud as well as DoS attacks, break-ins, theft or misuse of another’s identity or identity theft, copyright issues and violations, etc. Systems security duties also include dealing with Unsolicited Commercial E-mail also called UCE or, more commonly, spam. Filters and mail blocking can be provided if necessary as well as tracking and reporting such to sourcing ISP’s for further attention.

I invented computer system and network security procedures at Northeastern University. I was responsible for writing the first Appropriate Use Policy at Northeastern. I was also the liaison between Northeastern’s network and the Internet as well as law enforcement when the need came up. I invented interdepartmental procedures including those between my functions and the university counsel’s office as well as the public saftey department. I’ve had the FBI in my office as well as on the phone. Other agencies I’ve found myself talking to have been CERT, the Pentagon, DoD, and CIAC in the U.S. as well as various CERT equivalents in other countries. Kids will be kids and NU has a lot of them as does the Internet. You’re bound to run into the odd problem here and there. Other security related issues and inter-departmental policies are often initiated by me.

I was also responsible for securing, hardening and or tightening all the systems listed below. In the 17 years I have been doing SysAdmin work or been responsible for security on these systems, not one of these systems has ever been compromised at the root or system level. Not a bad track record.

[Top of page] [Accomplishents]

 
 

PERL, HTML, DHTML, real-time programming, log and data analysis, system tuning, planning.

 

Performance monitoring and system tuning was continuously done on all the systems described here by scripted programs written here for the purpose. The data so gathered is analyzed, reported and used for systems tuning on UNIX, and formerly the VMS systems, to decrease existing response times, level load across systems, and plan for growth. All the tools written for this produce Web pages for browser viewing from anywhere on the Web. One such system monitors the network services such as router bandwidth and e-mail rates and is viewable on the Web at http://isn.dac.neu.edu/. The data is used for tuning but also the location of the misuse of network resources.

January of 1999 a new USENET news server was put in place and required system tuning, as news is a very large database like application. The tuning for such a system is similar in many ways to tuning for a large ORACLE database system. This was accomplished and the system now runs very smoothly.

[Top of page] [Accomplishents]

 
 

UNIX, NFS, NIS, ALPHA systems, AdvFs, tuning, Apache server, HTML, TCP/IP, FTP, system administration, PERL, real-time programming, network administration, wrappers.

 

The lynx system is run by the Systems group. The lynx system is currently the largest single e-mail system on campus serving over 43,800 students, faculty, and staff. It is a TRU64 UNIX based system and is distributed across four COMPAQ ALPHA boxes with 40 gigabytes of disk space providing local access as well as both POP and IMAP client access to e-mail. It used to be one single ALPHA but was upgraded in January 1998 to distributed status in order to better handle the ever increasing load. The system moves between 50,000 and 65,000 e-mail messages per day and is capable of much more. Systems was responsible for development, maintenance, growth, and up time of this system which is generally a 7 x 24 operation. We also use the system to provide Web page services to system users, mostly students. We run other facilities for faculty, staff, departmental, and student group Web pages. See below. It should also be noted that this system was built and has been run with no university funding of any kind other than that available from the depatmental budget.

From time to time I also found myself tuning these UNIX systems to increase or even out their performance as the demand on them changed.

[Top of page] [Accomplishents]

 
 

VMS, VAX, DECNET, DCL, tuning, TGV/Multinet, TCP/IP, FTP, system administration, network administration.

 

A 2,200 plus username research computer facility was run by the Systems group until April of 2000, This system was a Digital Equipment Corporation VAXCluster the last incarnation of which consisted of two 6440 nodes with vector processors. Prior to this it had been an 8650 and an 11/780. Prior to that it was three 11/780’s. VAXen have been in nearly continuous operations at Northeastern University since 1980. The VAXCluster serviced the needs of research faculty as well as students.

[Top of page] [Accomplishents]

 
 

UNIX, VMS, VAX, DECNET, DCL, tuning, TGV/Multinet, TCP/IP, FTP, system administration, network administration, VAX mail, sendmail, PERL..

 

Migrating users off a VAXCluster to an ALPHA system was accomplished by the Systems group. My group ran a VAXCluster primarily for research. This was the home of the original computer based research facility on campus as well as the first e-mail system on campus. It serviced over 2,200 faculty and students. Classes are no longer taught on this system. It provided large scale storage and statistical software for data ranging across the fields of sociology, economics, biology, physics, geology, electronics, and, NU being a university, anything else you can think of. It also provided e-mail services using direct local access and both POP and IMAP remote mail clients as does lynx.

As of September, 1999, the VAXCluster users were moved off to a much newer and 50 times (minimum) faster ALPHA system running TRU64 UNIX. My group was responsible for the move which included both data and e-mail accounts. The trick is to do this without losing anything. The VMS and UNIX mail formats are totally dissimilar. Tools had to be written (by me) to assist the account migration process.

[Top of page] [Accomplishents]

 
 

modems (RACAL, USR), Nortel ANNEX 4000 terminal servers, UNIX, security, PPP, filtering.

 

A modem bank of 192 33.6kb modems was run by the Systems group. The modems were split between RACAL and newer U.S. Robotics racks. A plan was under way to upgrade the system to all USR’s and maybe go to 256 lines. The modems were connected to Bay Network (Nortel) Annex 4000 series terminal servers which provide command line, SLIP, and PPP service as well as security logging and access control for over 25,800 campus users. The modems handle at least 3000 to 6500 calls per day as of March 2000 and will handle more after service expansion. Direct command line Telnet access to off campus was blocked due to the anonymity of such access. But SLIP and PPP off-campus direct Internet access was permitted as these accounts required a username/password pair and are logged.

[Top of page] [Accomplishents]

 
 

Apache server, HTML, DHTML, HTTP, CGI, PERL, C, realaudio server, planning, DNS, virtual domain implementation, tuning, UNIX, shell programming, policy writing.

 

A Web server used by faculty and student groups was run and maintained by, and had growth planed by the Systems group, primarily me. This server was a central Web server facility used by faculty and student groups. The server provides Web access and storage space for departmental home pages, faculty home pages, and student group home pages for over 540 university departments and student groups and ran over 110 virtual domains. This server also housed two trial Web based course systems, Web Course in a Box and WebCT, which were being used and evaluated by the faculty as teaching tools for both local and distance learning. Systems was also responsible for service expansion using a well coordinated Web farm paradigm and for system security. Part of the Web farm was a Web Crossing system used for student/teacher interaction outside of class. Other than typical system and Web server security, security and access restriction mechanisms must be maintain for, among other things, commercial product information license compliance.

In June of 1998 I oversaw and did the server switch from Netscape’s Web server to the Apache server. Apache offered a few bells and whistles which were needed that Netscape did not. Apache also provided correct functionality in places where Netscape did not.

Tuning on this system occurred from time to time to increase or level performance so as to minimize response times to Web page requests.

In March of 1999 an EMC Symmetrix with a Celerra NFS server was purchased which included 100 Gigabytes of storage devoted to this Web server. I was responsible for the testing of the Celerra portion as well as the integration of same with the running Web server over a 100mb full duplex link.

Systems also added a MySQL database server to this system for full SQL database service and Web applications using the DBI/DBD PERL interface for the user community.

[Top of page] [Accomplishents]

 
 

Apache server, HTML, DHTML, HTTP, CGI, PERL, C, MySQL database system, DBI/DBD PERL interface to MySQL, SQL, realaudio server, planning, DNS, virtual domain implementation, UNIX, shell programming, policy writing, real-time programming.

 

The Educational Technology Center at Northeastern which provides faculty with Web hosting services for Web based and general multimedia tools for on campus, remote campus and other distance learning is supported by the Systems group. Systems provided the EdTech Center with Web server support for the newer technology based education programs involving static and dynamic Web page support, CGIs, and RealAudio and RealVideo streams. Systems was responsible for server maintenance, planning for growth, coordinated expansion of services using a Web farm approach, and system security. A MySQL database server with the DBI/DBD PERL interface to MySQL was added to provide full relational database capability on the EdTech/ATS Web server for the Web user community to use via CGIs.

[Top of page] [Accomplishents]

 
 

UNIX, system administration, NNTP, INN, network management, tuning, security.

 

A campus USENET news server is a necessary part of any campus information technology. USENET news is the oldest and largest electronic bulletin board system in the world. Systems had a news server in nearly continuous operation since 1987. The news system moves between 30GB and 38GB of news articles per day. In addition to the over 11,400 outside newsgroups hosted here, Systems also provides 109 local groups 85 of which are used for course work and student to student and student to teacher interaction outside of class.

[Top of page] [Accomplishents]

 
 

system planning and configuration, system implementation.

 

Support for an internal data base service and Remedy system has been given since 1992 by the Systems group. The original Remedy trouble ticket system used SyBase as the back-end database engine. In May of 1998 this system was migrated from an RS6000 AIX UNIX system to a Compaq Microsoft NT server base system using Microsoft SQL as the database engine. This system was planned and purchased by the Systems group and includes two Compaq servers with RAID 5 disk sets and a Qualstar robotic tape backup and archive unit. One of the systems is a backup and development system but can take over the job of the primary production system should the primary production system fail.

[Top of page] [Accomplishents]

 
 

PERL, graphics, CPAN, real-time programming, UNIX, log analysis.

 

Service log analysis and Web based presentation of service statistics is done by the Systems group. The system is prettier than it was the first time it was done, is straight forward and lives at http://isn.dac.neu.edu/ if you care to look. The pages where once built by a combination of scripts in shell and PERL as well as plotting programs. This has recently been rewritten (by me) to be PERL code using CPAN modules. The uses to which these pages have been put are many and varied. But they frequently helped us locate network, modem, and system problems by using automated methods of threshold detection with weighted averaging, derivative, and cluster analysis techniques.

[Top of page] [Accomplishents]

 
 

network design, network planning, network management, cisco routers, filtering, network security.

 

The NUnet project, or Northeastern University network, was a corporate level centrally funded and administrated project, the goal of which was to network every office, lab, class room, and residence hall on campus. As of December 1998 the system consisted of a core FDDI ring with three cisco routers. Beyond this are building Ethernet switches and hubs all linked with fiber. Cat 5 cabling is used from hubs to wall mount face plates. At this time the system connects well over 6000 nodes. NUnet was by design modular in nature such that any layer from the core out can be replaced with new infrastructure allowing for higher speed communications layers such as gigabit Ethernet, 100 megabit Ethernet, or even ATM. There is a plan to increase the core speed to gigabit Ethernet although at the time of this writing only an average of three to four percent of the core FDDI ring is in use. This number was determined using the log analysis system mentioned above and on the Web at http://isn.dac.neu.edu/. As of this writing the distributed model of NUnet which we had been using up until now is changing to a slightly more centralized paradigm requiring a much bigger core network bandwidth (a much bigger pipe).

I was involved with in the initial stages of NUnet and am still involved in the security aspects of the project as it relates to the systems which use NUnet and what traffic is allowed from where.

[Top of page] [Accomplishents]

 
 

TCP/IP, Internet performance, network design, implementation scheduling, cisco routers, CSU/DSU, T1, T3.

 

The campus Internet link was upgraded in late February of 1998 from two T1’s to a fractional T3 at 6 mb/s. We went to 9 mb/s on 1-Aug-1998 and have planned for going 12 mb/s shortly after January 1999. The Internet bandwidth requirements of the university are starting to doubled every year. This trend seems to be accelerating. As a result we will have max’ed out the T3 in two years. Plans are under way to go to ATM with Internet II however if the doubling trend continues OC3 will be max’ed out two years after the T3.

Part of the Internet link history which I have overseen follows

Service
Start date
Full T1 Sep-1989
Dual T1 Aug-1991
T3 @ 6mb Feb-1998
T3 @ 9mb Aug-1998
T3 @ 12mb Jan-1999

[Top of page] [Accomplishents]

 
 

project planning, project implementation, system test design, System testing, UNIX, Apache server, INN, cron, sendmail.

 

For Y2K compliance, one could try to legitimately argue that it is a little easier to arrange for academic systems than it is for business systems since date arithmetic is seldom involved. One could, but then one would also be ill informed. Research, especially in the social sciences does use date arithmetic quite a bit. Therefore all software run on Systems group supported hardware needed to be Y2K compliant for research if nothing else. There were of course other reasons. Y2K compliancy involved chasing vendors, searching Web pages, and obtaining patches where necessary. Or, if all else failed, understanding a system’s limitations and replacing it or working with it using modified procedures. This last is important since some vendors had issued end of support notices for 31-Dec-1999. All this needed to be prepared for prior to the dreaded date. In our case it involved servicing all systems listed above and some which aren’t such as all the statistical and other software on the research system. ATS systems had, as of 13-Nov-1998, either all been shown to be Y2K compliant or very shortly thereafter became such. Internal testing had been done. One of the people who worked for me had been collecting Y2K compliance information for Systems. At my suggestion she started a web page for Y2K compliance to be used as a Y2K communications tool in house and for keeping track of our progress in this area. Tests performed include transitions from 1999 to 2000, 28-Feb-2000 to 29-Feb-2000, and 2000 to 2001 and monitoring the function of batch systems, service logs, and date based archives.

Due the nature of research the Y2K issue is not as easily defined as is in the case of business software. This made the problem more of a challenge.

[Top of page] [Accomplishents]

 

Author: Chris Johnson
Version: 2.0.1