Current Infrastructure Environment / Issues
Services provided by OCIO-IS
- Multiple mail systems(IMAP/GW and testing MS Exchange)
- Basic Spam filtering and mail controls
- Calendar services
- MNA directory services (LDAP)
- Database services (mySQL)
- DNS
- Multiple accounts. (MNA, Lynx)
- Backup (Netbackup, NFS connectivity to SAN/backup resource)
- File Server
- Limited enterprise web development services: web preview (wwwdev.musc.edu) and publish to www.musc.edu
- Relatively unconstrained web development services for personal web pages (people.musc.edu).
- Language extensions (Perl modules)
Enterprise services provided by the IT Lab
- Instant Messaging (XMPP/Jabber)
- Web accessible training (HIPAA, IT Security, OSHA etc)
Portal services (http://my.musc.edu )
- Workflow Management services (Sluice)
Blog services (http://update.itlab.musc.edu )
- webDAV services
Harvested and Aggregated weather advisories (http://www.itlab.musc.edu/weather)
- Employee services (Rumor Mill, Applause )
PhpESP: Web-based survey engine http://survey.itlab.musc.edu
Connectivity from DMZ to internal net resources
(see current firewall policy and procedures).
- Rules will be evaluated on a case by case basis
- Rules that require multiple, broad holes will be discouraged or disallowed(NFS, X11, etc..)
- Encrypted connections are encouraged
- Limited rsync, ssh and scp (back end file systems may not be compatible with front end file systems (e.g. file names, symbolic links).
Current points of conflict
- OCIO provided backup solution to SAN uses NFS mounts and cannot be moved to DMZ
- Developers/Users are unaware that the development web server environment(wwwdev) isn't comparable to production environment(www). Said another way, just because a web page / application runs on wwwdev does not mean it will run correctly on www after being published.
- www isn't in the internal network and wwwdev is. www cannot access the same resources as wwwdev without additional holes being opened from DMZ to the internal network.
- When using Net::SMTP to send mail from a web application, the mail host target appears to be different for www and wwwdev. For wwwdev, mailhost.musc.edu works, but fails with www.musc.edu. Using smtp.musc.edu as a mail host also fails for www.musc.edu
- Documentation of DMZ available resouces and configuration is not adequately published and accessible.
- unstated is that hosts in the DMZ that need to send mail have to be added to the DMZ mailhost for proper relaying. Requests for mail transport from within the DMZ need to be managed in a manner similar to requesting a firewall rule - i.e. web application for requesting and approving requests that then reside in a database with a web-accessible interface.
- Conflicts with standard language extensions (Perl modules) and custom MUSC system services (ACL).
- Standard Internet data transport protocols conflict with back end file services.
Roadmap
Firewall: Splitting our security zones into two zones separated by a firewall will require duplication of some resources. Though duplication of resources is discussed in http://www.musc.edu/infoservices/firewall/firewall-info.html, the OCIO firewall overview, OCIO has provided little insight into what resources will be duplicated.
Infrastructure: Strategic Principles http://people.musc.edu/~gadsden/drafts/infrastructure.html
- Responsivness of OCIO: Innovation is experimental and experiments that take forever and a day to initiate often die on the vine. Can we evolve a responsive systems staff without compromising the operational integrity and security of our core infrastructure resources? Said another way, does a standards-based core system software infrastructure facilitate infrastructure experiments without jeapordizing the operational integrity of production activities? (Examples: webDAV, distributed access control, ... )
- Web accessible monitoring(network, systems, mail blacklists/whitelists, etc...). Accessible monitoring enables the MUSC community to identify and track IT infrastructure problems without involving the Help Desk.
- Open web accessible bug/issue/faq tracking. Web accessible bug/issue/faq tracking increases the awareness of the MUSC community and offeres the opportunity to contribute to infrastructure solutions.
- Open CVS for software / web applications and required for shared ownership software / web applications.
- Web-accessible encryption services (document and binding signatures to documents)
- Central Funding of SSL certificates or Central Distributuion of SSL certificates (internally generated)
- Application language support: modules and module management
- Single IMAP based Mail solution
- Advanced spam filter and mail control
- Instant Messaging (XMPP/Jabber)
- Full shell access web server development environment for web application development and prototyping
- Direct connectivity to SAN resources via standard protocols (rsync, ssh).
- Single MNA based network account repository accessible by LDAP, AD, Kerb, etc..
- Backup (Netbackup, SSH connectivity to SAN/backup resource)
- Database access within the DMZ and internal zone (mySQL, Postgres, sybase, oracle)
- Management of applications that have shared ownership.(parts of the app are owned by OES, some by OCIO, for example)
- Web Accessible change management resource for OCIO and shared ownership applications
- Web Accessible bug tracking / help desk / incident tracking