DOCSLIB.ORG

Zenoss Zeveloper's Guide Version

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Zenoss Zeveloper's Guide Version Zenoss, Inc. www.zenoss.com Copyright © 2008 Zenoss, Inc., 275 West St. Suite 204, Annapolis, MD 21401, U.S.A. All rights reserved. The Zenoss logo is a registered trademark of Zenoss, Inc. Zenoss and Open Enterprise Management are trademarks of Zenoss, Inc. in the U.S. and other countries. Flash is a registered trademark of Adobe Systems Incorporated. Java is a registered trademark of Sun Microsystems, Inc. Linux is a registered trademark of Linus Torvalds. SNMP Informant is a trademark of Garth K. Williams (Informant Systems, Inc.). Tomcat is a trademark of the Apache Software Foundation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. All other companies and products mentioned are trademarks and property of their respective owners. Zenoss Developer’s Guide for Version 2.3 Zenoss Developer’s Guide for Version 2.3 Table of Contents 1. Introduction ............................................................................................................................... 1 1.1. Overview ........................................................................................................................ 1 1.1.1. Model ................................................................................................................. 1 1.1.2. Availability .......................................................................................................... 1 1.1.3. Events ................................................................................................................. 1 1.1.4. Performance ......................................................................................................... 1 1.2. Detailed Architecture ........................................................................................................ 2 1.2.1. User Layer ........................................................................................................... 2 1.2.2. Data Layer ........................................................................................................... 2 1.2.3. Collection and Control Service Layer ........................................................................ 3 2. Getting Started ........................................................................................................................... 5 2.1. Working with the Source Code ........................................................................................... 5 2.1.1. Getting the Source Code ......................................................................................... 5 2.1.2. Keeping up-to-date with your checked-out code .......................................................... 5 2.1.3. Getting Patches ..................................................................................................... 6 2.1.4. Style Guidelines .................................................................................................... 6 2.1.5. Generating Diffs for new Fixes ................................................................................ 8 2.1.6. Submitting a Fix ................................................................................................... 8 2.2. Programming Techniques .................................................................................................. 8 2.2.1. Calling Methods Using REST .................................................................................. 8 2.3. zendmd: Command-line Access to the Device Management Database (DMD) ............................ 10 2.4. Programming Documentation ........................................................................................... 13 2.4.1. Python ............................................................................................................... 13 2.4.2. Zenoss API ......................................................................................................... 13 2.4.3. Other Resources .................................................................................................. 13 2.4.4. Contributing to the Documentation (Errors, Tips, HowTos) .......................................... 13 3. ZenPacks ................................................................................................................................. 14 3.1. Overview ...................................................................................................................... 14 3.2. Creating a ZenPack ........................................................................................................ 14 3.2.1. ZenPack Names ................................................................................................... 14 3.2.2. Specifying Dependencies ....................................................................................... 15 3.2.3. Locating ZenPack Source Outside of Zenoss ............................................................. 15 3.3. ZenPack Structure and Contents ........................................................................................ 15 3.4. Developing the ZenPack .................................................................................................. 17 3.4.1. Base ZenPack Class ............................................................................................. 17 3.4.2. Storing Objects in the ZODB ................................................................................. 18 3.4.3. Providing DataSource classes ................................................................................. 18 3.4.4. Providing daemons ............................................................................................... 19 3.4.5. setuptools and the zenpacksupport ........................................................................... 19 3.5. Building and Distributing ZenPacks ................................................................................... 20 3.5.1. Migrating between versions ................................................................................... 20 3.5.2. Converting older ZenPacks to ZenPack eggs ............................................................. 20 3.6. Where to Get More Information ........................................................................................ 21 4. Zenoss Datastores ..................................................................................................................... 22 4.1. Zope Object Database (ZODB) ......................................................................................... 22 4.2. MySQL Event database ................................................................................................... 23 4.2.1. Connecting to the Database ................................................................................... 24 4.3. Round-Robin Database .................................................................................................... 24 4.4. Python Pickle Files ......................................................................................................... 25 5. Events .................................................................................................................................... 26 5.1. Understanding an Event Entry .......................................................................................... 26 i 5.2. Sending an Event ........................................................................................................... 26 5.3. Adding an Event Class .................................................................................................... 27 5.3.1. Add to ZenEventClasses ....................................................................................... 27 5.3.2. Add the class to the import XML ........................................................................... 28 5.3.3. Write a migrate script ........................................................................................... 28 6. zProperty Management .............................................................................................................. 29 6.1. Adding a zProperty ........................................................................................................ 29 6.1.1. Adding a zProperty to an Event .............................................................................. 29 6.1.2. Adding a zProperty to a Device .............................................................................. 29 6.2. Migrating the zProperty Code ........................................................................................... 29 7. Device Management .................................................................................................................. 31 7.1. Adding Devices Programatically ....................................................................................... 31 7.1.1. Using a REST call ............................................................................................... 31 7.1.2. Using an XML-RPC Call from Python .................................................................... 31 7.1.3. XML-RPC Attributes ............................................................................................ 31 7.2. Editing Device Information .............................................................................................. 32 7.2.1. Using a REST call ............................................................................................... 32 7.2.2. Using an XML-RPC Call from Python ...................................................................
Load more

Recommended publications
  • Hacker Public Radio
    hpr0001 :: Introduction to HPR hpr0002 :: Customization the Lost Reason hpr0003 :: Lost Haycon Audio Aired on 2007-12-31 and hosted by StankDawg Aired on 2008-01-01 and hosted by deepgeek Aired on 2008-01-02 and hosted by Morgellon StankDawg and Enigma talk about what HPR is and how someone can contribute deepgeek talks about Customization being the lost reason in switching from Morgellon and others traipse around in the woods geocaching at midnight windows to linux Customization docdroppers article hpr0004 :: Firefox Profiles hpr0005 :: Database 101 Part 1 hpr0006 :: Part 15 Broadcasting Aired on 2008-01-03 and hosted by Peter Aired on 2008-01-06 and hosted by StankDawg as part of the Database 101 series. Aired on 2008-01-08 and hosted by dosman Peter explains how to move firefox profiles from machine to machine 1st part of the Database 101 series with Stankdawg dosman and zach from the packetsniffers talk about Part 15 Broadcasting Part 15 broadcasting resources SSTRAN AMT3000 part 15 transmitter hpr0007 :: Orwell Rolled over in his grave hpr0009 :: This old Hack 4 hpr0008 :: Asus EePC Aired on 2008-01-09 and hosted by deepgeek Aired on 2008-01-10 and hosted by fawkesfyre as part of the This Old Hack series. Aired on 2008-01-10 and hosted by Mubix deepgeek reviews a film Part 4 of the series this old hack Mubix and Redanthrax discuss the EEpc hpr0010 :: The Linux Boot Process Part 1 hpr0011 :: dd_rhelp hpr0012 :: Xen Aired on 2008-01-13 and hosted by Dann as part of the The Linux Boot Process series.
    [Show full text]
  • THE FUTURE of SCREENS from James Stanton a Little Bit About Me
    THE FUTURE OF SCREENS From james stanton A little bit about me. Hi I am James (Mckenzie) Stanton Thinker / Designer / Engineer / Director / Executive / Artist / Human / Practitioner / Gardner / Builder / and much more... Born in Essex, United Kingdom and survived a few hair raising moments and learnt digital from the ground up. Ok enough of the pleasantries I have been working in the design field since 1999 from the Falmouth School of Art and onwards to the RCA, and many companies. Ok. less about me and more about what I have seen… Today we are going to cover - SCREENS CONCEPTS - DIGITAL TRANSFORMATION - WHY ASSETS LIBRARIES - CODE LIBRARIES - COST EFFECTIVE SOLUTION FOR IMPLEMENTATION I know, I know, I know. That's all good and well, but what does this all mean to a company like mine? We are about to see a massive change in consumer behavior so let's get ready. DIGITAL TRANSFORMATION AS A USP Getting this correct will change your company forever. DIGITAL TRANSFORMATION USP-01 Digital transformation (DT) – the use of technology to radically improve performance or reach of enterprises – is becoming a hot topic for companies across the globe. VERY DIGITAL CHANGING NOT VERY DIGITAL DIGITAL TRANSFORMATION USP-02 Companies face common pressures from customers, employees and competitors to begin or speed up their digital transformation. However they are transforming at different paces with different results. VERY DIGITAL CHANGING NOT VERY DIGITAL DIGITAL TRANSFORMATION USP-03 Successful digital transformation comes not from implementing new technologies but from transforming your organisation to take advantage of the possibilities that new technologies provide.
    [Show full text]
  • Appendix a the Ten Commandments for Websites
    Appendix A The Ten Commandments for Websites Welcome to the appendixes! At this stage in your learning, you should have all the basic skills you require to build a high-quality website with insightful consideration given to aspects such as accessibility, search engine optimization, usability, and all the other concepts that web designers and developers think about on a daily basis. Hopefully with all the different elements covered in this book, you now have a solid understanding as to what goes into building a website (much more than code!). The main thing you should take from this book is that you don’t need to be an expert at everything but ensuring that you take the time to notice what’s out there and deciding what will best help your site are among the most important elements of the process. As you leave this book and go on to updating your website over time and perhaps learning new skills, always remember to be brave, take risks (through trial and error), and never feel that things are getting too hard. If you choose to learn skills that were only briefly mentioned in this book, like scripting, or to get involved in using content management systems and web software, go at a pace that you feel comfortable with. With that in mind, let’s go over the 10 most important messages I would personally recommend. After that, I’ll give you some useful resources like important websites for people learning to create for the Internet and handy software. Advice is something many professional designers and developers give out in spades after learning some harsh lessons from what their own bitter experiences.
    [Show full text]
  • Directing Javascript with Arrows
    Directing JavaScript with Arrows Khoo Yit Phang Michael Hicks Jeffrey S. Foster Vibha Sazawal University of Maryland, College Park {khooyp,mwh,jfoster,vibha}@cs.umd.edu Abstract callback with a (short) timeout. Unfortunately, this style of event- JavaScript programmers make extensive use of event-driven pro- driven programming is tedious, error-prone, and hampers reuse. gramming to help build responsive web applications. However, The callback sequencing code is strewn throughout the program, standard approaches to sequencing events are messy, and often and very often each callback must hard-code the names of the next lead to code that is difficult to understand and maintain. We have events and callbacks in the chain. found that arrows, a generalization of monads, are an elegant solu- To combat this problem, many researchers and practitioners tion to this problem. Arrows allow us to easily write asynchronous have developed libraries to ease the construction of rich and highly programs in small, modular units of code, and flexibly compose interactive web applications. Examples include jQuery (jquery. them in many different ways, while nicely abstracting the details of com), Prototype (prototypejs.org), YUI (developer.yahoo. asynchronous program composition. In this paper, we present Ar- com/yui), MochiKit (mochikit.com), and Dojo (dojotoolkit. rowlets, a new JavaScript library that offers arrows to the everyday org). These libraries generally provide high-level APIs for com- JavaScript programmer. We show how to use Arrowlets to construct mon features, e.g., drag-and-drop, animation, and network resource a variety of state machines, including state machines that branch loading, as well as to handle API differences between browsers.
    [Show full text]
  • Happy Birthday Linux
    25 Jahre Linux! Am Anfang war der Quellcode Entstehungsgeschichte und Werdegang von Linux Entwicklung und Diversifizierung der Distributionen Der Wert von Linux oder: „Wat nix kost, dat is och nix.“ Andreas Klein ORR 2016 1 Am Anfang war der Quellcode (70er) ● 1969, Ken Thompson u. Dennis Ritchie erstellen die erste Version von Unix in Assembler. ● Von 1969-1971 entwickeln sie gemeinsam die Programmiersprache B. ● Ab 1971 erweiterte in erster Linie Dennis Ritchie B, um weitere Elemente und nannte sie Anfangs NB (new B). ● 1973 waren die Erweiterungen soweit gediehen, das er die stark verbesserte Sprache C nannte (Brian W. Kernighan hat ebenfalls maßgeblich dazu beigetragen). //Unix=25 PCs ● Bis 1974 war das gesamte Betriebssystem UNIX vollständig in C implementiert und wurde mit einem C-Compiler kostenfrei an verschiedene Universitäten verteilt. ● 1978 wurden bereits über 600 Computer mit dem UNIX-Betriebssystemen betrieben. ● Das aufblühende Zeitalter der Computerisierung der 70er Jahre war geprägt vom regen und freien Austausch von Programmen und dessen zugrunde liegenden Ideen. Sinnvoller Weise tauschte man diese als Quellcode untereinander aus. ● 1979 wurde von AT&T die letzte UNIX-Version 7, mit freiem Quellcode veröffentlicht. Andreas Klein ORR 2016 2 Am Anfang war der Quellcode (80er) ● 1980 – 1983 AT&T sowie zahlreiche andere Unternehmen beginnen mit der Kommerzialisierung von UNIX, durch Koppelung an stark beschränkenden Lizenzen und Geheimhaltung des zugrunde liegenden Quelltextes. ● Richard Stallman kündigt am 27. September 1983 in den Newsgroups net.unix-wizards und net.usoft das GNU-Projekt an. ● Am 5. Januar 1984 begann Stallman offiziell mit der Arbeit am GNU-Projekt, nachdem er seine Stelle am MIT gekündigt hatte.
    [Show full text]
  • Zenoss Developer's Guide
    Zenoss Developer’s Guide Version 2.3.3 February 19, 2009 Zenoss Developer’s Guide Version 2.3.3 Copyright © 2009 Zenoss, Inc. All rights reserved. The Zenoss logo is a registered trademark of Zenoss, Inc. Zenoss and Open Enterprise Management are trademarks of Zenoss, Inc. in the U.S. and other countries. Zenoss can be contacted at: Zenoss, Inc. 275 West St. Suite 204 Annapolis MD 21401 U.S.A. Flash is a registered trademark of Adobe Systems Incorporated. Java is a registered trademark of Sun Microsystems, Inc. Linux is a registered trademark of Linus Torvalds. SNMP Informant is a trademark of Garth K. Williams (Informant Systems, Inc.). Tomcat is a trademark of the Apache Software Foundation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. All other companies and products mentioned are trademarks and property of their respective owners. Table of Contents 1. Introduction .............................................................................................................................. 1 1.1. Overview ...................................................................................................................... 1 1.1.1. Model ................................................................................................................ 1 1.1.2. Availability ......................................................................................................... 1 1.1.3. Events ...............................................................................................................
    [Show full text]
  • Analysis Report
    METU Computer Engineering AKAMAI WEB TOOLKIT ANALYSIS REPORT Members of the Team: • Ahmet Emin Tosun è [email protected] • Uğur Can Tekin è [email protected] • Hasan İşler è [email protected] • Vedat Şengül è [email protected] • Muhammet Yavuz Aşık è [email protected] 1. PROJECT DEFINITION, SCOPE AND GOALS 1.1 Project Definition 1.2 Project Scope and Goals 2. PROCESS 2.1 Team Organization 2.2 Process Model 2.3 Major Constraints 2.3.1 Project Schedule 2.3.1 Language Constraints 2.3.3 User Interface 2.4 Gantt Chart 3. MARKET RESEARCH 3.1 CURRENT PRODUCTS 3.1.1 APTANA 3.1.1.1 What is Aptana? 3.1.1.2 Main Features of Aptana 3.1.1.3 About the Aptana Editors 3.1.1.3.1 JavaScript Editor 3.1.1.3.2 HTML Editor 3.1.1.3.3 CSS Editor 3.1.1.4 Screenshots 3.1.2 AJAX JOYISTAR WEBSHOP 3.1.2.1 What is Ajax Joyistar Webshop? 3.1.2.2 Main Features of Joyistar Webshop 3.1.2.3 Screenshots 3.1.3 ZAPATEC 3.1.3.1 What is Zapatec 3.1.3.2 Main Features of Zapatec 3.1.4 GOOGLE WEB TOOLKIT 3.1.4.1 What is Google Web Toolkit? 3.1.4.2 Main Features of GWT 3.1.4.3 Google Web Toolkit Components 3.1.5 DOJO TOOLKIT 3.1.5.1 What is Dojo? 3.1.5.2 Main Features of Dojo 2 3.1.6 MORFIK WEBOS APPSBUILDER 3.1.6.1 What is Morfik WebOS AppsBuilder 3.1.6.2 Main Features of Morfik WebOS AppsBuilder 3.1.6.3 About the Morfik Editor 3.1.6.4 Screenshots 3.1.7 Comparison Table 3.2 Questionnaire 3.3 Interview 4.
    [Show full text]
  • Javascript Hijacking
    JavaScript Hijacking Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West {brian, katrina, jacob}@fortifysoftware.com March 12, 2007 Summary An increasing number of rich Web applications, often called Ajax applications, make use of JavaScript as a data transport mechanism. This paper describes a vulnerability we term JavaScript Hijacking, which allows an unauthorized party to read confidential data contained in JavaScript messages. The attack works by using a <script> tag to circumvent the Same Origin Policy enforced by Web browsers. Traditional Web applications are not vulnerable because they do not use JavaScript as a data transport mechanism. We analyzed 12 popular Ajax frameworks, including 4 server-integrated toolkits – Direct Web Remoting (DWR), Microsoft ASP.NET Ajax (a.k.a. Atlas), xajax and Google Web Toolkit (GWT) -- and 8 purely client-side libraries -- Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit. We determined that among them only DWR 2.0 implements mechanisms for preventing JavaScript Hijacking. The rest of the frameworks do not explicitly provide any protection and do not mention any security concerns in their documentation. Many programmers are not using any of these frameworks, but based on our findings with the frameworks, we believe that many custom-built applications are also vulnerable. An application may be vulnerable if it: • Uses JavaScript as a data transfer format • Handles confidential data We advocate a two-pronged mitigation approach that allows applications to decline malicious requests and prevent attackers from directly executing JavaScript the applications generate. 1. Introduction Although the term “Web 2.0” does not have a rigorous definition, it is commonly used in at least two ways.
    [Show full text]
  • Ajax, State of The
    AjAjaax,x, ststaattee ooff tthhee aarrtt Tarek Ziadé, Nuxeo [email protected] WWhhoo aamm ii ● I am engineer at Nuxeo ● I work on CPS, the famous ECM Plateform ;) ● I©ve been lately in charge of Ajax stuff in CPS ● I read Ajax related feeds before I go to bed WWhhaatt iiss AAjjaaxx ?? A dutch football club (a good one) A cleanser (really works) AA WWeebb 22..00 tteechchnnoollooggyy Asynchronous Javascript And XML WWhhaatt©©ss WWeebb 22..00 ?? TTiimm OO©©RReeiillllyy©©ss ©©ccoommppaacctt©© ddeeffiinniittiioonn:: Web 2.0 is the network as platform, spanning all connected devices; Web 2.0 applications are those that make the most of the intrinsic advantages of that platform: delivering software as a continually-updated service that gets better the more people use it, consuming and remixing data from multiple sources, including individual users, while providing their own data and services in a form that allows remixing by others, creating network effects through an "architecture of participation," and going beyond the page metaphor of Web 1.0 to deliver rich user experiences. MMaarrkkuuss AAnnggeerrmmeeiieerr©©ss vviieeww ooff WWeebb 22..00:: (courtesy of Markus Angermeier) WWeebb 22..00 AAppppss ✔ del.icio.us ✔ flickr ✔ Voo2do ✔ Digg ✔ Google Mail (Gmail) ✔ Writely ✔ Basecamp ✔ ... AjAjaaxx bbiigg ppiictctuurere 11//22 (courtesy of J. J. Garett) AjAjaaxx bbiigg ppiictctuurere 22//22 (courtesy of J. J. Garett) TThhee LLiistst ooff tthhiinnggss AjAjaaxx rereaallllyy bbririnnggss ✔ Increases interactivity ✔ Save bandwidth ✔ Helps avoiding some interactive
    [Show full text]
  • Linux Networking Cookbook™ by Carla Schroder
    Linux Networking Cookbook ™ Carla Schroder Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo Linux Networking Cookbook™ by Carla Schroder Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mike Loukides Indexer: John Bickelhaupt Production Editor: Sumita Mukherji Cover Designer: Karen Montgomery Copyeditor: Derek Di Matteo Interior Designer: David Futato Proofreader: Sumita Mukherji Illustrator: Jessamyn Read Printing History: November 2007: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Cookbook series designations, Linux Networking Cookbook, the image of a female blacksmith, and related trade dress are trademarks of O’Reilly Media, Inc. Java™ is a trademark of Sun Microsystems, Inc. .NET is a registered trademark of Microsoft Corporation. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Debugging Javascript
    6803.book Page 451 Thursday, June 15, 2006 2:24 PM APPENDIX ■ ■ ■ Debugging JavaScript In this appendix, I will introduce you to some tricks and tools to debug your JavaScript code. It is very important to get acquainted with debugging tools, as programming consists to a large extent of trying to find out what went wrong a particular time. Some browsers help you with this problem; others make it harder by having their debugging tools hidden away or returning cryptic error messages that confuse more than they help. Some of my favorites include philo- sophical works like “Undefined is not defined” or the MSIE standard “Object doesn’t support this property or method.” Common JavaScript Mistakes Let’s start with some common mistakes that probably every JavaScript developer has made during his career. Having these in the back of your head when you check a failing script might make it a lot quicker to spot the problem. Misspellings and Case-Sensitivity Issues The easiest mistakes to spot are misspellings of JavaScript method names or properties. Clas- sics include getElementByTagName() instead of getElementsByTagName(), getElementByID() instead of getElementById() and node.style.colour (for the British English writers). A lot of times the problem could also be case sensitivity, for example, writing keywords in mixed case instead of lowercase. If( elm.href ) { var url = elm.href; } There is no keyword called If, but there is one called if. The same problem of case sensi- tivity applies to variable names: var FamilyGuy = 'Peter'; var FamilyGuyWife = 'Lois'; alert( 'The Griffins:\n'+ familyGuy + ' and ' + FamilyGuyWife ); This will result in an error message stating “familyGuy is not defined”, as there is a variable called FamilyGuy but none called familyGuy.
    [Show full text]
  • Building Linux Software with Conary
    Building Linux Software with Conary Michael K. Johnson rpath, Inc. [email protected] Abstract of Conary terminology and design, you may want to read the paper Repository-Based Sys- tem Management Using Conary, in Proceed- This paper describes best practices in Conary ings of the Linux Symposium, Volume Two, packaging: writing recipes that take advan- 2004, kept updated at http://www.rpath. tage of Conary features; avoiding redundancy com/technology/techoverview/, which with recipe inheritance and design; implement- introduces Conary’s design and vocabulary in ing release management using branches, shad- greater detail. Terms called out in boldface in ows, labels, redirects, and flavors; and design- this paper without an explicit definition are de- ing and writing dynamic tag handlers. It de- fined in that overview. scribes how Conary policy prevents common packaging errors. It provides examples from our rpath Linux distribution, illustrating the de- sign principles of the Conary build process. It 1 Conary Source Management then describes the steps needed to create a new distribution based on the rpath Linux distribu- Unlike legacy package management tools, tion, using the distributed branch and shadow Conary has integral management for source features of Conary. code and binaries, and the binaries are directly associated with the source code from which Conary is a distributed software management they have been built. system for Linux distributions. Based on exten- sive experience developing Linux distributions Conary stores source files in source compo- and package management tools, it replaces tra- nents, and then uses a recipe (described later) ditional package management solutions (such to build binary components that it can in- as RPM and dpkg) with one designed to enable stall on a system.
    [Show full text]