Upgraded IOS on 6509 and 3640 on 3/15/2004. 6509 upgraded from IP W/SSH/3DES12.2(14)SX1 to 12.2(17d).SXB. 3540 upgraded from IP 12.2(T1) to 12.23.
Upgraded 3005 vpn to ver 4.1.2 on 3/10/2004.
Mail server slowness I
The University mail server began to timeout clients and slow down at approximately noon today. The cause of the problem is unclear.
The number of process running on the server appearred to be at a normal load average. The servers response from secure shell was slow. It appearred as though the system was having a problem allocating resources for the processes running, but memory and disk space were both available.
We shut down process to try and identify the cause of the slowness. Imapd and Ipop3d were disabled with no luck. The web server was shutdown, no luck. Then mailman and sendmail. At this point things improved.
I disabled the webmail interface and brought sendmail and mailman backup. I then brought the web server backup. The server still appeared to be responding in a slower than normal, but somewhat timely manner. I restarted the ipop3d daemon and about five minutes later the imapd daemon. The server still looked good–slower than normal, but somewhat timely. After restarting the webmail interface things when into the tank.
We tried restarting the webmail server between 3:00 and 3:30 pm, but the unbareable slowness remained.
We then rebooted the mail server at about 3:40pm.
The server was back to normal after the reboot.
Media Server testing
At 10:30 am load testing of the media server was performed. This testing involved an audio file that was over 19 minutes long (19:37) and 69 workstations with the real media client.
The clients were located in Wyatt 203, McIntyre 324, and basement of the library with a few clients in the I-Commons. The majority of these machines were connected to campus network via cabletron 6000 switches.
The test lasted for the length of the audio file. During that time, no adverse network activity was observed. The server was relatively uneffected as well. At most, 18% of the cpu was consumed for a brief period of time. No service related calls were logged by the Help Desk concerning network issues during the testing. It should be noted that this test was performed during Spring Break.
SurgeFTP server license key problems II
A new license key was generated, and was put into place when the web server was restarted today. Wu-ftpd was stopped.
Web server restarted
The disk on the University’s web server filled up sometime last week, causing several cron processes to hang and “zombify”. In order to clear up these problems, the web server was rebooted.
SurgeFTP server license key problems I
The license key for the SurgeFTP server was apparently incorrectly generated. As a consequence, the server was running on the demo key, which expired today. SurgeFTP was stopped, and WU-ftpd was restarted so that people can upload their files. We are writing
Antivirus gateway hung
Due to a reconfiguration, the University’s antivirus gateway stopped forwarding email. The system was rebooted, and the problem was cleared. A slight email backup occurred, which was cleared in 1-2 hours.
ASUPS web server moved to the server room
The ASUPS web server was moved into the server room today, since the University calendar system developed by ASUPS has become an official service.
Loss of MX record
During the implementation of e-mail routing changes on 2/2/04 the MX record for the ups.edu domain on the internal DNS server was inadvertantly disabled.
This problem has been fixed and a backlog of messages, held by the anti-virus gateway are now being delivered.
High volume of messages in AVG queue
A high volume of messages has been noticed in the queues of the anti-virus gateway. The cause of this situation is not clear. Currently message are taking anywhere from 15 minutes to several hours to be delivered. One cause may be the high volume of virus/worm traffic.
Mail service reconfiguration
The University e-mail service has been reconfigured to route as many messages as possible through the anti-virus gateway before they are sent off-campus or recieved by the University’s mail servers.
This additional stop for messages increases the delivery time, but in necessary to reduce the propogation of e-mail viruses and worms.
Shares on new academic file server repaired
File shares on the new ALEXANDRIA academic file server had incorrect share permissions set. This caused users to be locked out of their file space. The permissions were reset to the proper values.
Replacement for academic file server goes live
ALEXANDRIA, the academic file server wnet live this morning.
Wounded IP Pool in Union Ave (Greek Row) exhausted
Due to the problem with the DHCP server today, students in Greek Row subnet had problems registering, which caused them to back up in the wounded IP range, exhausting the wounded pool.
The wounded pool was increased in all subnets to relieve the problem.
Resnet DCHP server conf file refresh failed
As on 15 September, 2003, the auto-restart script on the Resnet DHCP server failed. The script was restarted, and this solved the problem.