1 / 26

On The Fly Management of UNIX Hosts Using CFEngine

On The Fly Management of UNIX Hosts Using CFEngine. Ryan Adamson. Introduction. Overview of CFEngine Overview of ORNL’s Device Management Systems Configuration Management with CFEngine Customized Reporting with CFEngine. CFEngine Overview. CFEngine -- What is it?

clarke-norton
Télécharger la présentation

On The Fly Management of UNIX Hosts Using CFEngine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On The Fly Management of UNIX Hosts Using CFEngine Ryan Adamson

  2. Introduction • Overview of CFEngine • Overview of ORNL’s Device Management Systems • Configuration Management with CFEngine • Customized Reporting with CFEngine

  3. CFEngine Overview • CFEngine -- What is it? • “Cfengine is an autonomic maintenance system not merely a change management roll-out tool.” • Straight from cfengine.org • In general, computers are members of different classes • Depending on class membership, the appropriate policy is applied

  4. CFEngine Overview • Hard coded class membership is tough to maintain • An example: • If the hostnames change or machines are added/deleted, we have to manually change the classes in CFEngine

  5. ORNL Device Management • NetReg (Network Registration) • End user can register and modify device information at will • DES (Device Exception System) • End user can request exceptions to security policy for valid business reasons • CSR (Cyber Security Reports) • Reports to the end user on overall compliance • CFEngine reports compliance to the CSR

  6. ORNL Device Management Topology

  7. CFEngine @ ORNL • Goals • Provide a framework for the automated management of systems on the ORNL network • Provide additional reporting capabilities to aid in cyber threat mitigation • Design Philosophy • Be Flexible • Be Robust • Be Polite

  8. CFEngine @ ORNL - Design • The Wrong Way

  9. CFEngine @ ORNL - Design CFEngine Installations at ORNL by Distribution

  10. CFEngine @ ORNL - Design • Flexibility • Different packaging formats • Modular code • Separate out policy files • Screensaver locking (Gnome/KDE) • Patching • Centralized syslogconfiguration • Directory structure for each OS

  11. CFEngine @ ORNL - Design • Robustness • Change detection: • Hostname • Hardware • Network Configuration • Device Registration • OS • Scalability • Client check-ins are distributed • Separate back end database server • Geographic distribution of servers

  12. CFEngine @ ORNL - Design • Politeness • Limit invasive configuration management • Patching • Syslog configuration • Screensaver • Local and centralized snapshots of modified files • CPU Intensive tasks are done at night • Packages are easy to install • Statically compiled Solaris packages • Centralized download location • ORNL Distributed RHN package

  13. CFEngine @ ORNL - Implementation • The Old Way

  14. CFEngine @ ORNL - Implementation • Question: For any given device, what policies do we apply? ORNL Policy Standards + OS Specific Requirements + Device Type Specific Requirements – DES Exceptions Applicable policies

  15. CFEngine @ ORNL - Implementation • Question: How do we do that? • Scripts gather information from DES and NetReg and store into local database tables • Another local database table has configuration standards information: • Bitwise arithmetic to the rescue!

  16. CFEngine @ ORNL - Implementation • Example: Fedora 10 desktop with Screensaver exception • Screensaver policy not enforced in this case, but other device requirements are

  17. CFEngine @ ORNL - Implementation • A directory is created for each client • Empty text files with the names of classes to be turned on • Each file corresponds to an appropriate policy needed for the client • Example: Fedora 10 desktop with Screensaver exception • Text files in its directory would be: • Autopatch • Syslog

  18. CFEngine @ ORNL • Automatically generates a class list for each client on a recurring basis • Advantages: • Changes in baseline policy, os type policy, or exceptions for individual clients are immediately propagated • Disadvantages: • Extra complexity

  19. CFEngine @ ORNL - Reporting • CFEngine automatically reports: • Packages installed with native package manager • Versions of packages installed • Compliance with ORNL standards • Users and Groups • Hardware information • And can be configured to report almost anything else

  20. CFEngine @ ORNL - Reporting • Our modified CFEngine database allows us to dynamically reference data collected from • CFEngine • DES • NetReg • WHOs database of personnel • All of these are stored as relational tables in the CFEngine DB keyed on a unique identifier • SQL queries are used to retrieve meaningful data

  21. CFEngine @ ORNL – Reporting Example • We need to notify everyone running Fedora 9 that their OS will no longer be supported • Run a customized query • Find all Fedora 9 computers • Cross-Index these computers with NetReg to find the system owners • Cross-Index the system owners with WHOs to find their email addresses

  22. CFEngine @ ORNL – Reporting In Style • What if we don’t like using a command line? • LCARS offers a web interface for quick browsing • Laboratory • Computer • Autonomic • Reporting • System • Not to be confused with LCARS:

  23. CFEngine @ ORNL – Reporting In Style

  24. CFEngine @ ORNL – Still Flexible • CFEngine @ ORNL offers • Flexible and robust configuration management • Simple reporting tools • Powerful data aggregation • But, it has been designed so that new features, policies, and reports can be implemented quickly and easily

  25. CFEngine @ ORNL • Questions? Don’t forget the BoF session afterwards!

  26. Other ORNL presentations which might be of interest • SharePoint • Monday, 11:45-Using SharePoint UI to Deliver General Use Applications, Connie Begovich • Tuesday, 11:45-SharePoint at ORNL, Brett Ellis • Cyber Security • Monday, 1:30-Development of a Process for Phishing Awareness Activities, Phil Arwood • Monday, 2:15-How I Learned to Embrace the Chaos, Mark Lorenc • Monday, 4:15-TOTEM:The ORNL Threat Evaluation Method,John Gerber/Mark Floyd • Desktop Management • Monday 4:15-On the Fly Management of UNIX Hosts using CFEngine,Ryan Adamson • Tuesday, 11:00-Implementation of Least User Privileges, Doug Smelcer • Wednesday, 11:45, Microsoft Deployment Using MDT and SCCM, Chad Deguira • Incident Management • Wednesday, 11:00-Helpdesk Operations for Clients Without Admin Privileges, Bob Beane/Tim Guilliams • IT Modernization • Monday, 2:15-12 Months of Technology, Lara James

More Related