• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
2011 NASA Open Source Summit - Forge.mil
 

2011 NASA Open Source Summit - Forge.mil

on

  • 2,333 views

 

Statistics

Views

Total Views
2,333
Views on SlideShare
2,248
Embed Views
85

Actions

Likes
1
Downloads
82
Comments
0

2 Embeds 85

http://gov20.govfresh.com 75
http://lanyrd.com 10

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    2011 NASA Open Source Summit - Forge.mil 2011 NASA Open Source Summit - Forge.mil Presentation Transcript

    • Forge.mil – DoD Collaborative Software Development Guy Martin, Forge.mil Community Manager [email_address] Richard Bullington-McGuire, Director, Technology [email_address] IT Innovators Award
    • Forge.mil Vision
      • TODAY
      • Siloed development environments
      • Expensive and time consuming start-up
      • Limited exposure, sharing, or re-use
      • Duplication of effort
      Developer Tester User Certifier Shared Test & Development Tools/Services/Environments Shared Asset Libraries & Repositories Developer
      • FORGE.mil
      • OSS best practices applied to internal projects
      • Cross-program sharing: software and services
      • Early and continuous collaboration
      • Integrated approach to development life cycle
      • Extensible platform to support delivery of partner capabilities
    • Forge.mil Services Free, collaborative development environment for internal open-source and DoD community source software On-demand, fee-for-service development environment for individual internal programs and projects
      • Multi-Tenant Environment
      • Isolated project spaces for each customer
      • Shared infrastructure
      • Private Environment
      • Full environment dedicated to your program
    • Forge.mil Community Approach DOD Acquisition Community DOD Test and Evaluation Community DOD IA Community DOD NETOPS Community DOD Development Community Government, Industry & Academia Collaborative Development & Test Note: Forge.mil != DoD & External OSS Community
    • Forge.mil Key Features
      • Application lifecycle management (ALM) services
      • for the DoD Enterprise
      Requirements management Source code management Discussion forums Project wiki Document management Project management for distributed development teams Tasking & alerts Release management Real-time reporting Software development services Bug, Issue Tracking Share software, best practices, information
    • Community Challenges
        • Hierarchical, process & command driven culture
        • Extreme risk aversion (with good reason!)
        • Heavy reliance on documents, in-person meetings, email
        • Skepticism of new processes/tools
        • Certification/accreditation of client-side tools (SVN, etc.)
    • Community Lessons Learned
        • Government community building is a 'contact sport’
        • Both ‘carrot’ (grassroots) & ‘stick’ (top-down) needed
        • Categorization (project, artifact, etc.) VERY important
        • Documentation/process socialization critical to acceptance
        • Platform/tool MUST tie into email (notifications)
        • “ You can’t forklift a revolution…”
    • Community Lessons Learned
        • Don’t assume inquisitiveness
        • FAQ lists are important (even if not read the first time)
        • Seek out, support, & encourage community leaders
        • Grow community efforts first around existing tools/tech
        • Don’t be afraid to use chain of command to jumpstart things
        • Have realistic expectations
    • Community Victories
      • Sampling of Hosted Projects
      • Army
      • Apps 4 Army: Innovation contest to develop new ‘mashup’s of Army data
      • SOSCOE: System of Systems Common Operating Environment - tactical middleware
      • Navy
      • Gargoyle: a network activity monitoring and analysis system
      • NEP-O: Naval Enterprise Portal Oceanography – Agile process used heavily
      • Vulnerator: Aggregation of security readiness findings for systems
      • Air Force
      • AF EIM: code supporting Air Force’s Enterprise Information Management
      • UAS TSPI Server: a common network interface to multiple UAS ground-stations for sensors requiring real-time telemetry source
      • Marine Corps
      • DCGS-MC: Distributed Common Ground/Surface System – Marine Corps
      • MAGTF C2: Marine Air Ground Task Force Command and Control
      • Joint Chiefs & DISA
      • NSLDSS: National Senior Leadership Decision Support Service
      • DIB: Distributed Common Ground/Surface System (DCGS) Integration Backbone
      • CommunityCAC: CAC Utilities/Firefox plugin
      • DODBastille: RHEL STIG lockdown utilities
      • Initial Forge.mil capability (April 2009) supporting collaborative software development & reuse
      • Today (March 2011)
      • Over 2700 software releases available
      • ~47,000 software releases downloaded
      • Over 36,000 bugs/requirements tracked
      • Over 39,000 code checkins
      • Over 3500 discussion posts
      • ~ $160M in software asset reuse ROI
      Mar 26
    • Forge.mil Implementation: Open Source Enabled Agility How we achieved our mission by both producing and consuming Open Source Software (while moving at a very rapid pace) Disclaimer: These implementation notes reflect the experiences and opinions of the author, Richard Bullington-McGuire, the architect for the initial implementation phase of Forge.mil, and do not represent DISA’s official positions Slides following marked with a “*” are contributed by Richard Bullington-McGuire
    • First Challenge: Secure it Fast *
        • Implementation effort began on Nov. 10, 2008
        • First fielded in production (LOA) on Jan 23, 2009 (< 90 days)
        • Biggest Roadblock: Security
          • Application Security and Development STIG Requires:
            • PKI User Authentication
              • Support both soft cert and CAC hardware token
              • Clients: Web browser, Subversion, and SOAP API
            • Encrypt system passwords at rest (including database user names and passwords)
        • Solution: Extend open source elements of software stack
    • Forge.Mil Internal Architecture * Key Concepts and Architecture
        • CollabNet TeamForge 5.x on Red Hat Enterprise Linux 5.x
        • Open Source foundations: Apache HTTP Server, mod_ssl, mod_python, JBoss, Tomcat, Subversion, Lucene, Apache James, PostgreSQL
        • Key insight: extend security features by building on the open source components below CTF using Python and Java modules
        • Key insight: enable CAC token authentication in Subversion clients by extending and distributing new client binaries
      Deployment Architecture software.forge.mil Application Server svn.forge.mil Integration Server Single Sign On (SSO) Database Application Database Forge.mil User With x509 Client Certificate (CAC/ECA)
    • Consuming Open Source *
        • Server-side:
          • All custom extensions and amendments built on software shipped with RHEL 5. Goal: keep system as vanilla as possible. Use RPM for packaging extensions.
          • PKI enablement required updating stock mod_python with newer version, and writing user mapping logic tied to SSL
          • Secure password storage required the m2crypto library for the mod_python extension layers, and extending JBoss with a module for reading the encrypted passwords using a key stored on a RAM disk. Password encryption functions : m2secret
        • Client-side:
          • CAC-enabled Subversion with TortoiseSVN 1.5.5
    • Producing Open Source *
        • Main Roadblock: lack of hardware token support in SVN clients. Only TortoiseSVN 1.5.5 had support for hardware token authentication with the CAC (we redistributed it)
          • We developed and distributed:
            • A working Windows CLI svn client with CAC support
            • A modified Subclipse client with CAC support
            • A cross-platform Java SVN client with CAC support
            • Updated versions of TortoiseSVN with CAC support
        • These efforts helped inspire broader support for hardware token-driven SVN clients (see the latest releases of: CollabNet Desktop for Eclipse and Visual Studio, which support hardware tokens)
    • Achieving Mission Success Fast *
        • We would not have been able to field this service so quickly without both producing and consuming open source software
        • Leveraging Open Source let our small team make architecture-level tweaks to vendor-supplied software stacks that would have taken the vendors much longer to make
        • We focused on using OSS to solve real security issues, and worked within the DoD certification & accreditation process
        • Licensing: we produced & consumed the software under the original terms of the various licenses (no new licenses introduced, no artificial hurdles in the reasonable distribution of software we modified under existing licenses)
    • BACKUP SLIDES
    • Upcoming Capabilities: Full Application Life-cycle Support Development Zone Validation/ Pre-Production Zone Dashboard, Reporting & Monitoring Build Libraries & Code Repositories Production Zone Agile Software Development Unit, Integration & Regression Testing Static Code Analysis System Testing IA Certification IT & Data Standards Today Release & Operations Management Q2 11 Q4 10 Q4 11 Q4 12 Cloud Hosting Environment
    • Policy and Guidance
      • HR 2647, National Defense Authorization Act for Fiscal Year 2010, Sec. 804.
      • “ The Secretary of Defense shall develop and implement a new acquisition process for information technology systems. The acquisition process developed and implemented pursuant to this subsection shall, to the extent determined appropriate by the Secretary —
      • . . . be based on the recommendations in chapter 6 of the March 2009 report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology; and
      • . . . be designed to include —
        • early and continual involvement of the user;
        • multiple, rapidly executed increments or releases of capability;
        • early, successive prototyping to support an evolutionary approach; and
        • a modular, open-systems approach.”
    • Benefits of Using Forge.mil Forge.mil reduces administrative costs, increases productivity, and improves visibility. Key benefits include: FOR DEVELOPERS FOR MANAGERS FOR EXECUTIVES
      • Access a full featured development platform over the web or directly from your IDE
      • Have fewer meetings and less administration when collaboration is part of everyday development
      • Link to continuous integration servers and provision build and test servers in the cloud whenever you need them
      • Speed new project startup
      • Secure access to project assets
      • Enhance team productivity and collaboration
      • Improve visibility into project status
      • Reduce management and administrative overhead
      • Access critical team assets via the web or your Microsoft Windows desktop
      • Consolidate and centralize to reduce administration, licensing, and infrastructure costs
      • Establish governance and regulatory compliance
      • Improve predictability of the development organization
      • Integrate easily into existing systems to extend return on investments
    • Forge.mil PKE changes: HTTPD modules * Application Database Single Sign On (SSO) Database software.forge.mil / svn.forge.mil Application Server or Integration Server Red Hat Enterprise Linux 5 Vmware ESXi
      • mod_python
      • sfauth (svn auth)
      • sf_sso
      • looks up cert->user mappings in SSO db
      • sf_pki
      • calls TeamForge login() method via SOAP using master password, redirects user through alternate login path accepting username + session ID
      • JBoss
      • On App server only
      • Web Rendering
      • SOAP Server
      • JAAS module: masterpassword.jar
      • Tomcat
      • James Mail
      • Lucene Indexes
      • SCM viewer (on integration server)
      PostgreSQL 8.2 Databases On Separate RHEL 5 VMs Apache HTTPD Forge.mil User Service w/ x509 Server Cert, Reused as Client Cert Client -> Server https / TCP 443
      • Client Software
      • Web browsers (IE, Firefox)
      • Subversion clients (DAV over https)
      • Custom SOAP clients
      • All must use client cert auth.
      http proxy + SOAP Server -> Database PostgreSQL / TCP 5432 JBOSS -> Tomcat Java RMI PKE changes to baseline are listed in italics
    • Ongoing Challenges & Opportunities *
        • Is Forge.mil the One True Path for DoD software development?
          • Walled garden protected by CAC & ECA certificates is a disincentive to public participation. However, public participation is not the primary function of Forge.mil.
          • Forge.mil is trying to solve the internal collaboration problems within the DoD using OSS methodologies.
          • Not every project (Open Source or otherwise) will be a good fit for Forge.mil, but many projects will be a fit that would not be a good fit for a more public repository.
        • Having this service available has helped shape the ongoing community discussion about what normative behavior should be regarding producing and consuming Open Source in the context of DoD projects.