- (Tim) Y2K Post-Mortem - Did anyone see any problems in their areas?
- (Bruce) - watstar backups. Given the success of the NFS backup system, and lack of concerns raised to date, EC is probably going to discontinue running tape backups of watstar servers within the next 1 to 2 weeks. Issues. Alternatives.
- (Bruce) - non accounting watstar print servers. printers attached to ports on watstar servers, and non accounting watstar print daemons can be converted to new methods (unix , NT) anytime. I'd like to work on setting a deadline for the discontinuation of the watstar non accounting print service.
- (Bruce) - departmental MAD k: disk. I'd like to work on setting a deadline for the discontinuation of the departmental K: disk, in favour of the app filer disk.
- (Bruce) - Are there any other watstar features we can stop using now (or soon) so that when the real Phase II deadline is selected, we have as few remaining issues as possible.
- (Bruce) - netapp backups. The legato backups of the netapps don't work at all in some cases, and work marginally in others. Can we get an overview of the progress (if any) made, and history of this problem, from an Information System and Technology (IST) perspective ? Contingency plans.
- (Bruce) - Intel/Unix. EC is moving to Solaris/Sparc for some main systems, but we will also be examining Solaris/Intel for other systems. If it is equal or better that FreeBSD, we *may* consider moving all remaining FreeBSD, even if they are not experiencing problems. Issues.
- (Ray) Space on E: disk
Problem: We have run out of disk space again in e:\w95 which may make it impossible to install new applications or updates. I have already removed any redundant files and moved as much as possible to other drives however Windows still insists on putting DLL's into e:\w95\system.
There are four possible ways to move forward:
1.Repartition/reformat the hard drive to make E: larger
2.Take over the F: drive and move one or more of the installed applications on the E: to the F: drive - may involve repartitioning and purchasing of new hard drives
3.Move an application or two off the E: drive and put them onto a Network drive. The list of applications are below any suggestions?
4.Put on a new version of Windows: possibly Win95b (I don't know if it is feasible yet) or do what I can to keep the programs current and move to Windows 2000 on an advanced timetable.
The following programs are on the E: drive:
Windows 95 base including directX, Norton Antivirus and Real player (with extra codecs) ~380
Microsoft Office 97 ~218
Corel WordPerfect Office 8 ~133
Lan Workplace for Windows ~29
Netscape 4.6 ~21
Adobe Acrobat Reader 4 ~12
Eudora 3.06 ~5
Pine ~4
Synchronize ~3
Wasted space do to FAT16 and Directory entries ~110 - (Nevil) Can something be done so the desktop settings are saved on Net app accounts? ie) stop the auto arrange of new icons
- (Nevil) Can the removall or relocating the clipart on the E drive be considered as an option for saving space?
- (Nevil) Can the wording of the scratch options be looked into or changed for less confusion when the web version is implemented?
- (Nevil) Can an office flag be added so office machines can use j:\utl3\admin /unlock without a privileged account?
- (Nevil) Is there any way of keeping the duplexing tray installed using SMBPRINT on the HP4000? Can the ppd file be copied and edited for a duplex capable 4000 and used in the pdrivers.pol?
- (Jim) The stuff that we have on K: is pretty big. JBuilder takes 15-20 seconds to load on a standalone system. It take at least 3 minutes normally. Considering the 15:1 station:server ratio that we enjoy, switched 100MB ether and the current load on hooke, I predict that our stations will actually see longer load times if we move our K: apps to Q:. When we originally configured our lab stations we included large disks such that we have F: and G: sitting idle. The original intent was to clone the K: on F:, but file protection of F: didn't work for a while, then there were other issues, and now it'd just be a hassle to move. Since we are now talking about the end of K:, I'd like to discuss using F: as a clone of our K:/Q: and optionally use the Q: as a central distribution point from which SYSCTL could grab updates for F:.
- (Jim) We still mount our NetApps on P:, and are still using watstar N:. We have a couple of reproducable cases where users have n:\etc\usefiler files and we are getting files created on N:. Worse, the n:\etc\polconn.ini has been created and corrupted several times. Has anyone else seen this yet? I doubt that it is interference from NT-TSE, but I won't rule it out.
- (Jim) Related to the above, we'd really, really like to separate our user file space such as:
home/jjohnston - Unix home directory home/jjohnston/Polaris - everything that Polaris needed on N:. home/jjohnston/NT-TSE - everything that NT-TSE needs home/jjohnston/MacOSX - For the fall when our macs labs are all running OS-X and also using hooke for home drives.
To this end, how can we configure Polaris to use N:\Polaris as its root? Most apps that I've looked at can be configured to use subdirectories. And since the W95 stuff that shows up on n:\ is either copied by hand or via special variables set in Polaris configs, are there any other real issues preventing such a change? If for no other reason, it would make is so that we could tell our users, "You are done with Polaris this term. To recover quota, rm -fr ~/Polaris." Currently, I couldn't tell them the entire list of things to delete. Worse, since NT-TSE uses some similarly named files/dirs, I can't be sure which environment created what. I'm trying to get our NT-TSE moved into a subdir as well. Even if we were to junk NT-TSE and the Macs today, I'd still feel strongly that Polaris should move to a subdir. - (Jim) We don't use Q:, and it causes us a lot of problems when users change their UNIX password, then the next time they login they can't get the Q: drive because the stored password is out-of-date, and they aren't prompted for a new one. At this point we'll see 'Polaris not responding', and if we kill it we're fine. Will it cause any problems to not supply a server for our Q:? IE. does the "stock" polaris require anything from the Q: yet?
