lunes, abril 30, 2012

Iniciando con BlackBerry Java Development Tools

Tomado de: Documento Original

This chapter provides the information developers need when beginning a BlackBerry Java development project and trying to select the right development tools to use. This chapter includes information on how to download and install the RIM’s Java development tools. Chapter topics are
  • Understanding the BlackBerry Java Application files
  • Selecting the right development platform for Java applications
  • Installing the BlackBerry Java development tools
  • Obtaining and installing the application signing keys needed to run applications that use controlled application programming interfaces (APIs) on BlackBerry devices
  • Using the Preprocessor to generate different versions of an application from a single set of source files
After the Java development platform is selected and the tools are installed, the chapters that follow describe how to use the individual development tools to build and debug Java applications for BlackBerry:
  • Chapter 13, “Using the BlackBerry Java Development Environment (JDE),” covers the BlackBerry JDE.
  • Chapter 14, “Using the BlackBerry JDE Plug-In for Eclipse (eJDE),” covers the BlackBerry eJDE.
  • Chapter 15, “Using the BlackBerry JDE Component Package Tools,” covers the BlackBerry JDE Component Package.

12.1 Understanding BlackBerry Java Application Files

The BlackBerry platform uses several types of files to contain application code and provide application deployment tools with the information they need about the application and its components. Developers must understand the role of each to be able to effectively build and deploy applications. The following sections describe each of the file types. Other files are used by development tools, but the files discussed here are only the ones deployed to devices or used when deploying applications to devices.

12.1.1 .cod Files

A BlackBerry .cod file is the compiled application file deployed to BlackBerry devices. The .cod file bundles together one or more compiled Java classes for use with the BlackBerry Java virtual machine. Unlike standard Java, which compiles individual Java classes into class files (with a .class extension) and aggregates compiled classes into JAR files (Java ARchives with a .jar extension), RIM uses this proprietary file format instead because it is optimized for the BlackBerry platform.
Each singleton .cod file contains one or more compiled Java classes (and is, therefore, roughly equivalent to the standard Java JAR file); however, it has a strict size limit of 64k of code and 64k of data. A sibling .cod file is an archive of multiple, separately built .cod files that help alleviate the size limit restriction of singleton .cod files. When an application approaches the .cod file size limit, a portion of the functionality of the application must be migrated off into separate modules (library projects in the JDE and eJDE), which are packaged by the development tools into a sibling .cod file for deployment.
A MIDlet application created for another platform (a .jar file) can be easily converted into a .cod file for deployment to a BlackBerry device; see the BlackBerry Developer’s knowledge base article DB-00055 for additional information about this topic.

12.1.2 .alx Files

An application’s .alx file is used by the BlackBerry Application Loader (through the BlackBerry desktop manager or the BlackBerry Enterprise Server), which is described in Chapter 16, “Deploying Java Applications,” to deploy application .cod files to a BlackBerry device. The .alx file is a simple text file that
  • Can be hand crafted (not really necessary, see next bullet)
  • Is automatically generated by the BlackBerry JDE and eJDE
  • Can reference multiple versions of an application (for deployment to different BlackBerry Device Software versions), device types, and capabilities
The file is in XML format and contains the information that the Application Loader needs to
  • Describe the application (in dialogs displayed to users during installation and in the installed applications list on the BlackBerry device)
  • Determine if the application is compatible with the target device
  • Understand which files need to be deployed with the application (depending on BlackBerry Device Software version)
A portion of the application information defined in the file is populated from developer-entered application properties (application name, version, vendor, and copyright) defined in the JDE and eJDE. A developer generates or updates the .alx file and makes it available (along with the application .cod files) to anyone who will deploy the application using the BlackBerry Application Loader. The options for deploying BlackBerry Java applications are described in detail in Chapter 16.
A simple .alx file for the URL Launch application (described in Chapter 11, “Building BlackBerry Java Applications”) is shown here:
<loader version="1.0">
<application id="URLLaunch">
  <name >
      URL Launch
    </name>
    <description>
      Launches the default browser and opens 
      www.bbdevfundamentals.com
    </description>
    <version >
      1.0
    </version>
    <vendor >
      BlackBerry Development Fundamentals
    </vendor>
    <copyright >
      Copyright  2009 com.bbdevfundamentals
    </copyright>
    <fileset Java="1.39">
      <directory >
      </directory>
      <files >
        URLLaunch.cod
      </files>
    </fileset>
  </application>
</loader>
A more sophisticated .alx file, one that deploys a different .cod file depending on the BlackBerry Device Software version the target device is running, is shown here. Notice how it uses the fileset element’s _blackberryVersion attribute and the <directory> element to point to the correct version of the application .cod file for the target device:
<loader version="1.0">
<application id="URLLaunch">
  <name >
      URL Launch
    </name>
    <description>
      Launches the default browser and opens 
      www.bbdevfundamentals.com
    </description>
    <version >
      1.0
    </version>
    <vendor >
      BlackBerry Development Fundamentals
    </vendor>
    <copyright >
      Copyright  2009 com.bbdevfundamentals
    </copyright>
      <fileset Java="1.34" _blackberryVersion="[4.1.0,4.2.3)">
         <directory>410_423</directory>
         <files>urllaunch.cod</files>
      </fileset>
      <fileset Java="1.34" _blackberryVersion="(4.3.0,4.3.1]">
         <directory>430_431</directory>
         <files> urllaunch.cod</files>
      </fileset>
   </application>
</loader>
See the BlackBerry Developer’s knowledge base article, “How To: Create a Single .alx File to Install Multiple Versions of an Application” (Article #DB-00028) for information on the more sophisticated options for the BlackBerry .alx file.

12.1.3 .jad Files

The .jad file is a simple text file used by the BlackBerry Application Web Loader, BlackBerry browser, and BlackBerry App World when deploying BlackBerry applications to a device (described in Chapter 16). The file can be hand crafted, but that’s not necessary because it is automatically generated by the BlackBerry JDE and eJDE whenever a BlackBerry Java development project is built. It contains information needed to verify the application files during deployment and other specifics about the application. A developer might generate or update the .jad file and make it available (along with the application’s .cod files) to anyone who will deploy the application using the listed tools. The options for deploying BlackBerry Java applications are described in Chapter 16.
A sample .jad file for the URL Launch application described in Chapter 11 is shown here. The line numbers are not part of the file; they have been added to make these descriptions easier to follow.
Line 3 defines the specific modules required by the application. The application will not deploy to a device if the required modules are not available.
Line 9 contains a Secure Hash Algorithm (SHA1) hash of the application’s .cod file that verifies the integrity of the .cod file.
Line 10 contains the .cod file size parameter; this value can be updated using the UpdateJad.exe file described in Chapter 15.
Lines 12 through 14 represent the application project’s properties (version, name, and vendor) populated in the JDE or eJDE.
1 Manifest-Version: 1.0
2 RIM-COD-Module-Name: URLLaunch
3 RIM-COD-Module-Dependencies: net_rim_cldc,net_rim_bbapi_
  browser
4 MIDlet-Jar-Size: 2832
5 MIDlet-1: ,,
6 RIM-COD-Creation-Time: 1242820557
7 MIDlet-Jar-URL: URLLaunch.jar
8 RIM-COD-URL: URLLaunch.cod
9 RIM-COD-SHA1: e1 c2 7b bc 14 0c 63 cc 43 80 bf b2 1e 47 a1 77 
  c9 08 95 7b
10 RIM-COD-Size: 1084
11 MicroEdition-Configuration: CLDC-1.1
12 MIDlet-Version: 1.0
13 MIDlet-Name: URLLaunch
14 MIDlet-Vendor: BlackBerry Development Fundamentals
15 MicroEdition-Profile: MIDP-2.0
16 RIM-MIDlet-Flags-1: 0

12.2 Selecting the Right Development Platform for Java Applications

Before digging into the development tools, it’s important to talk about which development platform to select when building an application. Subsequent chapters cover the ins and outs of the different tools, but what most developers miss is which BlackBerry environment to start with when building their applications.
The features a BlackBerry application can leverage on a device vary greatly, depending on the version of the BlackBerry Device Software running on it. When RIM adds new features to a device, it usually adds a corresponding set of APIs a developer can use to take advantage of them. Any applications that make use of particular features (and corresponding APIs) will only run on a device that supports the feature. Everything is forward compatible, so the feature will be available in future versions of the BlackBerry Device Software; you wouldn’t want the application breaking on a newer device. A BlackBerry Java application is tied to the minimum BlackBerry Device Software version for which it was created; it will not run on a device running any previous version of the BlackBerry Device Software.
When RIM releases a new version of the BlackBerry Device Software, the API libraries included with the corresponding version of the BlackBerry Java development tools are updated. This update also affects the online help and the code-completion capabilities in an Integrated Development Environment (IDE), the device simulators, and more.
Note - You might actually get your application to run on an earlier version of the BlackBerry Device Software, but it probably won’t. If it does work, don’t get complacent; just because it works doesn’t mean there won’t be other problems later. Running an application crafted for a particular BlackBerry Device Software version on an earlier version is not supported and should not be attempted. Doing so could “brick” the device—make the device permanently unusable.
Because each version of the BlackBerry Device Software has its own special version of the development tools, if you are developing applications for multiple BlackBerry Device Software versions, you have to install multiple versions of the tools.

12.3 Selecting the BlackBerry Java Development Environment

The BlackBerry Java development tools provide a complete set of APIs and tools that developers can use to develop Java applications that run on BlackBerry devices. RIM offers different development tools for Java developers, and the good news is that all of them are free. The only exception to this is the cost an organization incurs when purchasing a set of signing keys, as described later in this chapter.
Three types of Java development tools are available from the BlackBerry Developer’s website (http://www.blackberry.com/developers). The one you select will vary, depending on your preference for IDE. The available options are
  • BlackBerry Java Development Environment (JDE): A complete Java development environment for BlackBerry. Although not sophisticated as IDEs go, it is the tool RIM developers used for years to build the BlackBerry Device Software and associated applications. Developers might select this option if they didn’t care which IDE they used to build BlackBerry applications or if they wanted to keep all BlackBerry development segregated to a separate development environment.
  • BlackBerry JDE Plug-in for Eclipse (eJDE): Provides the same functionality as the JDE, but the tools are integrated as a plug-in to the Eclipse IDE. The benefit of this toolset is that developers get the development tools provided by the JDE along with all the other sophisticated features and plug-ins supported by the Eclipse platform. Developers might select this option if they were already familiar with Eclipse or if they were doing other types of development and wanted to use the same IDE for all. This is the development tool that RIM currently recommends developers use for Java development for the BlackBerry platform. Going forward, feature enhancements will only be made in the eJDE.
  • BlackBerry JDE Component Package: A collection of the tools developers need when developing BlackBerry Java applications using a different IDE than the ones listed in the previous bullets. Developers might select this option if they were already familiar with another development environment and were unwilling or unable, for whatever reason, to switch to one of the integrated BlackBerry tools.
The tools are also useful to developers who want to build automated processes for building or manipulating applications outside of an IDE.
Each tool is described in subsequent chapters.

12.4 Getting the BlackBerry Java Development Tools

When you are ready to download some BlackBerry development tools, open a browser and navigate to http://www.blackberry.com/developers. The site might change by the time you read this, so look for a section called Java Application Development Tools & Downloads and click the downloads link, as shown in Figure 12.1. When the page opens, look for a section on Java Development Tools. There should be a link for downloading the BlackBerry JDE and the BlackBerry JDE plug-in for Eclipse. The link for the BlackBerry JDE should also contain links to download the BlackBerry JDE Component Package.
12fig01.jpg
Figure 12.1 BlackBerry Development Tools & Downloads page
Depending on your selection, a different set of options appears. Pay special attention to the system requirements for each tool. Each requires that a version of the Sun Java Development Kit be installed on the system running the BlackBerry Java development tools.

12.4.1 Downloading and Installing the BlackBerry JDE or JDE Component Package

When downloading the JDE or BlackBerry JDE Component Package, scroll down the page until you locate a section of the page containing the links to download the specific versions of the tools. Select the appropriate downloads for your particular needs. If you’re building applications for multiple BlackBerry Device Software versions, you need to download an installer for each version you will be using. If you’re building for a single version or running a single application on multiple BlackBerry Device Software versions, you need to download the version that corresponds to the lowest BlackBerry Device Software version you will support.
To install the JDE or JDE Component Package, first make sure that a copy of the required Java SDK is installed on the system and launch the file you downloaded from the website. Follow the prompts to complete the installation, and you’ll be ready to go. Depending on your Windows configuration, you might have to add the JDK bin folder to the Windows PATH environment variable before you can launch the development tools.
Note - The BlackBerry MDS simulator is required to test BlackBerry applications (using the device simulators) that make use of network connections to access a remote server. For some reason, the 4.2 and 4.2.1 JDE did not ship with the MDS simulator (all other versions since 4.1 did). If you exclusively work with either of those versions of the JDE, be sure to download and install the MDS simulator and then configure the affected JDE to use it.
If working in conjunction with other JDE versions, the 4.2 and 4.2.1 JDE can be configured to use the MDS simulator included within one of the other JDEs.

12.4.2 Downloading and Installing the BlackBerry JDE Plug-In for Eclipse

When downloading the BlackBerry JDE Plug-In for Eclipse, a different set of options appears on the downloads page. In this case, a full installer includes the editor components and associated files plus one of the eJDE Component Packs (version 4.5, at the time of this writing), which contain the libraries and simulators for a particular version of the BlackBerry Device Software. At a minimum, you must download the full installation; you won’t be able to develop BlackBerry applications in Eclipse if you don’t. If you need to support building or maintaining applications for additional BlackBerry Device Software versions, you will likely want to download additional eJDE Component Packages (one for each version of the BlackBerry Device Software being supported).
Note - Because the eJDE components are installed as plug-ins to Eclipse, the Eclipse IDE must be installed in advance of the eJDE installation. You can download the latest version of Eclipse from http://www.eclipse.org.
The first step in the installation process is to install the BlackBerry Java development tools into the Eclipse IDE. Extract the eJDE full-installation package zip file to a local hard-drive folder; it doesn’t matter where the files are placed, as long as the Eclipse installation has access to them. After the files are extracted, launch the Eclipse IDE and complete the following steps:
  1. With the program open, access the Help menu and select the menu item labeled Software Updates.
  2. In the window that appears, select the Available Software tab and click the Add Site button.
  3. In the Add Site dialog, click the Local button.
  4. Using the standard Windows Open Folder dialog that appears, navigate to the folder where the installation files were extracted and open the folder.
  5. Back at the Add Site dialog, click the OK button to continue.
  6. Back at the Software Updates and Add-Ons window, ensure that the BlackBerry JDE Plug-In for Eclipse and BlackBerry Component Pack options are selected and then click the Install button. Eclipse prompts you to confirm the installation and finish the process, ultimately recommending that the IDE be restarted before continuing. At this point, the eJDE is installed and ready for use.
If you downloaded additional component packages, repeat the process for each of the additional component packages you want to use with this instance of Eclipse.
North American users can use the BlackBerry Eclipse update site to download and install component packages directly into an existing Eclipse installation. To do this, open the Software Updates and Add-Ons window and click the Add Site button. Instead of clicking Local to add a local reference, enter http://www.blackberry.com/go/eclipseUpdate in the Location field and click OK. Eclipse connects to the BlackBerry Eclipse Update site and retrieves a list of the components available for installation, as shown in Figure 12.2. Select the component that you want to install and click the Install button to download and install the selected component(s).
12fig02.jpg
Figure 12.2 Completing the Component Package installation

12.5 Application Signing Keys

Chances are that most developer will find themselves needing to use one of the controlled APIs described in Chapter 11. Subsequent chapters show how to sign an application in the different Java development tools, but now, it seems to be a good time to discuss how to get a copy of the signing keys needed to sign an application.
BlackBerry applications that use controlled APIs do not run on BlackBerry devices until they are signed with the appropriate keys. The applications run in the BlackBerry simulators, so it is possible to build and test applications without the appropriate keys. This allows a developer to do all the work necessary to determine the best way to implement a programmatic feature and only purchase the keys if a controlled API is used and it’s time to test on real devices.
Depending on the types of controlled APIs your application uses, you might need different sets of keys. Most controlled APIs can be used with the standard set of keys, which can be purchased for $20 from RIM directly. If your applications use any of the Certicom cryptography APIs, there is a separate process to secure a license from them. Considering that RIM recently completed a purchase of Certicom, it’s likely that this restriction will disappear in the future.
Here are some important facts about signing keys:
  • The keys must be installed on a system that has one of the BlackBerry Java Development tools installed.
  • Each set of signing keys is associated with a specific PC. If you want to sign applications on multiple PCs, you must purchase a set of signing keys for each PC that will be used to sign applications. Some organizations set up a single signing PC and do all of their application signing on that PC. Other organizations purchase a set of keys for every developer workstation.
  • Be prepared to associate a ten-digit personal identification number (PIN) with your signing key purchase. The PIN is needed when the keys are installed, so be sure to record it accurately and keep it in a safe place. This is not a device PIN; it’s just a special key you create to identify yourself to RIM when you purchase keys, then again later when you register them after the order is processed.
  • If you lose your keys or need to install them on a different PC, you must contact RIM Developer Support (devsupport@rim.com) to request a new set of keys.
  • When you purchase a set of keys, you do not have to pay for each application you sign. They keys are configured to support a large number of signings (millions), so you should be OK.
  • Keys are valid forever.
  • The registered owner of the signing keys receives email messages from the RIM Signing Authority whenever the keys have been used. An email message will be sent for each type of library used in the application. The emails are sent for security purposes, so the owner of the keys will know if someone uses the keys to sign an application. Make sure the registered owner is someone who doesn’t mind receiving a lot of emails. He can always use email filters to automatically redirect these messages to a folder or delete them automatically when they arrive.
Concerns About Signing Keys - One of the first questions most developers ask about the signing keys is, “Do I have to purchase a set of keys for each application I sign?” If you think about it, that would be a rather cumbersome process if it were true. No, you purchase one set of keys per PC, and you can sign as many applications as you want.
Actually, that’s not true; there is a limit on the number of signings you can do, but it’s such a huge number that you should be OK no matter what you do. In the set of keys installed to take the screen captures used in this chapter, the Signing Tool reports, “The client has 2,147,483,647 code signing request(s) left.” That’s more than enough signings for the normal developer’s lifetime.

12.5.1 Purchasing Signing Keys

To purchase a set of signing keys, open the Microsoft Internet Explorer web browser and go to http://www.blackberry.com/developers. On the page that appears, navigate to the area of the site responsible for Java Development and look in the right-side navigation for an item labeled Code Signing Keys. When you click the link, a page opens where you can find information about the signing keys and how to purchase a set. You can use a web-based form and your credit card to purchase directly online or you can fill out a form and fax the information to RIM for processing.
Signing Keys Payment Options - When purchasing a set of signing keys, the keys must be purchased using a credit card. Because the keys are used partially for security purposes, RIM must ensure that it knows the identity of the entity requesting them.
If a set of keys were used to create an application considered dangerous or to be used for nefarious purposes, RIM wants to associate those keys with a person (name and billing address).
After you complete the purchase of the keys, it might take one to three business days to receive the signing keys from RIM. If you do not receive your keys within this timeframe, email devsupport@rim.com to request a status of the order. After RIM processes the order, you receive at least three separate email messages from the BlackBerry Application Development Support Team. The emails each contain a file attachment (a .csi file) and instructions on how to complete the installation of the keys.

12.5.2 Installing Signing Keys

Before installing the keys, make sure at least one of the BlackBerry Java development tools is installed on the PC where the keys will be installed. The installation process varies, depending on whether you are installing the keys into the JDE or into the eJDE. Additionally, if you will work with multiple versions of the JDE or JDE Component Package, or if you will be working with the JDE and the eJDE, an additional configuration step must be completed to make the signing keys available across multiple tools. All this is described in the following sections.

Installing Signing Keys into the JDE

To install the keys into the JDE, each key file must be launched individually to integrate the keys into the BlackBerry Java development tools. The key files can be launched directly from the email messages containing each key, or each file can be downloaded from a message and launched from Windows Explorer or My Computer.
When a key file launches, the BlackBerry Signature Tool opens and manages the process of installing the keys, which is described in the section, “Completing the Signing Key Installation.” This process must be repeated for each signature key .csi file.
If you launch a .csi file and nothing happens, first ensure that a Java runtime environment and one of the BlackBerry JDE versions is installed on the system. In some cases, the Signing Tool will not launch automatically when the .csi files are launched. In that case, you need to register each .csi file manually from the command line. To start the manual installation, follow these steps:
  1. Copy the .csi files to the JDE bin folder. (For the 4.7 JDE, the folder location should be C:\Program Files\Research In Motion\BlackBerry JDE 4.7.0\bin.)
  2. Open a DOS command prompt in Windows and navigate to the folder containing the .csi files.
  3. For each of the .csi files, execute the following command:
  4. javaw -jar SignatureTool.jar [CSI_File_Name].csi
    In this command, [CSI_FILE_NAME] refers to the filename for the .csi file.
At this point, follow the steps described in the section, “Completing the Signing Key Installation.”

Installing Signing Keys into the eJDE

With the eJDE, the signature key file installation is integrated directly into Eclipse tools. To begin the process, access the BlackBerry menu in Eclipse, select the Install Signature Keys menu item, and follow the steps described next.

Completing the Signing Key Installation

When the first key installs, there are additional setup steps required to complete the process. The Signature Tool displays a dialog similar to the one shown in Figure 12.3, which indicates that the private key used to secure the signature keys cannot be located within the BlackBerry Java Tools installation. You must select Yes from the dialog to complete the installation, unless you believe this process has already been configured and you received the message in error. If you select No from the dialog, the installation process aborts.
12fig03.jpg
Figure 12.3 BlackBerry Signing Tool private key dialog
The Signature Tool then asks you to provide a password that will protect access to the signing keys on the PC, as shown in Figure 12.4. The password entered here is needed every time an application is signed using the keys. Select a password that is easy to remember when needed. If the password is lost, you need to obtain a new set of signature keys from RIM before you can sign Java applications. A replacement set of keys should be free; just send an email to devsupport@rim.com to request a replacement set.
12fig04.jpg
Figure 12.4 BlackBerry Signing Tool private key password
The private key is generated using information generated through random mouse movement and keyboard entry, as shown in Figure 12.5. Move the mouse around and type random keys on the keyboard until the progress bar reaches 100 percent. At this point, the information the Signature Tool needs to manage and secure the signing keys has been generated, and you will not be prompted to complete the process again for the PC.
12fig05.jpg
Figure 12.5 Generating random information for the private key
Because the signing keys are restricted to a single PC, the installation process includes a step where the key installation is registered with RIM.
The next step in the process must be repeated for each signing key. The Signing Tool prompts you to provide the PIN assigned to these keys during purchase and the private key password assigned in an earlier step, as shown in Figure 12.6. When the information is entered, click the Register button to register the signing key installation with RIM. Because the Signing Tool registers using an Internet connection, if the environment the keys are being installed into requires the use of a proxy server, you can provide the proxy server configuration settings after clicking the Configure Proxy button.
12fig06.jpg
Figure 12.6BlackBerry Signing Tool registration
If the registration process is successful, a dialog appears containing information about the key that was registered, including the number of signings supported by the key that was registered. If an error occurs in the process, search for the error in the Developer Knowledge Base at http://www.blackberry.com/developers and follow any appropriate instructions you find to resolve the problem.
Repeat this step for each key file you received. Because the private key has already been created, the only step in the process that must be completed is the registration of the additional keys with RIM.

Copying Signing Key Information

If you are using the eJDE exclusively, the signature information is installed with the plug-in and available across multiple versions of the eJDE Component Package. If using multiple versions of the JDE (one for each version of BlackBerry Device Software being supported) or the eJDE plus one or more versions of the JDE, there is an additional setup step required.
During the installation of the signing keys, the installation process creates two files containing information regarding your set of keys. These files must be available to each instance of the Signing Tool installed with the eJDE and JDE. The files are called sigtool.csk and sigtool.db, and they are created in the bin folder for the most recently installed version of the JDE or eJDE Component Package. To complete the installation, copy these two files into the same folder for each additional version of the JDE installed on the PC. For the JDE, the files are usually located in C:\Program Files\Research In Motion\BlackBerry JDE 4.7.0\bin (replacing the 4.7.0 with the version of the JDE you use). For the eJDE, the files are installed within the Eclipse installation, such as C:\Program Files\eclipse\plugins\net.rim.eide.componentpack4.7.0_4.7.0.46\components\bin.
Beginning with BlackBerry Device Software 4.3, the format of the signing key files was changed. To support signing applications using JDE versions prior to version 4.3, you must also copy the SignatureTool.jar file from the bin folder to the same folder in older versions of the JDE.

12.6 Conditional Compilation Using the Preprocessor

One of the issues that early BlackBerry Java developers faced was how to build Java applications for multiple versions of the BlackBerry Device Software. Say, for example, that a new feature became available in a newer Device Software version, and a developer wants to use it in his application. What the developer has to do is maintain separate source files for each version of the application: one that used the new feature and another for older versions of the BlackBerry Device Software. As an application gets more features and starts to support multiple devices, there might be more and more versions of the application being maintained. The developer could move the special code into libraries and link in the appropriate version when building, but this becomes complicated and requires some sophisticated configurations and special build tools.
It was only recently that RIM announced that the RIM Application Program Compiler (RAPC) supported preprocessing; a capability a developer can use to build multiple versions of an application from the same set of application source files.

12.6.1 Preprocessor Defines

To enable this feature, a developer creates Preprocessor Defines in the project file or on the command line to RAPC and then places special Preprocessor Directives into the source files to instruct the preprocessor on how to manipulate the source code at build time. The Preprocessor Defines are like special variables used only by the Preprocessor. Because the Preprocessor Defines are configured differently depending on which BlackBerry Java development is being used, they are covered in the chapters that address each development tool.

12.6.2 Preprocessor Directives

RAPC supports only a limited suite of Preprocessor Directives, but they’re enough to dramatically simplify the life of any developer building applications with multiple versions. The directives are placed into the application source files and instruct the Preprocessor on how to manipulate the code prior to compilation. This section describes the supported Preprocessor Directives available on the BlackBerry Java platform.

Enabling the Preprocessor

To enable the source file for preprocessing, the source file must contain the following directive. For readability and ease of use, it needs to be placed near the beginning of the source file. The proper syntax for the directive is
//#preprocess

Using an If, Else, EndIf Block

To execute different code branches depending on whether a particular Preprocessor Define value is defined, use the following structure:
//#ifdef <tag>
  [Code executed if the preprocessor define exists]
//#else
  [Code executed if the preprocessor define does not exist]
//#endif
In this case, the first block of code is executed if <tag> is defined as a Preprocessor Define within the project. If <tag> is not defined, the second block of code executes.
To see an example of this at work, look at the following code. In the URL Launch application described in Chapter 11, there was a special condition identified where the application would not work correctly on BlackBerry Device Software 4.2. To support BlackBerry Device Software 4.2, an additional line of code needed to be added to the application. In the following example, a Preprocessor Directive is defined that inserts the additional line of code only if the Preprocessor Define, called BBDS42, is defined for the project:
public urlLaunch() {
  // Get the default browser session
  BrowserSession browserSession = Browser.getDefaultSession();
  // Then display the page using the browser session
  browserSession.displayPage(appURL);
  //#ifdef BBDS42
  browserSession.showBrowser();
  //#endif
  // Once the URL is launched, close this application
  System.exit(0);
}

Using an If Not, Else, EndIf Block

To execute different code branches depending on whether a particular Preprocessor Define value is not defined, use the following structure:
//#ifndef <tag>
  [Code to be executed if the preprocessor define exists]
//#else 
  [Code executed if the preprocessor define does not exist]
//#endif
This example is the opposite of the previous one. The first block of code is executed if <tag> is not defined as a Preprocessor Define within the project. If <tag> is defined, the second block of code executes.

12.7 Additional Resources

A complete listing of links to these resources is available online at http://www.bbdevfundamentals.com.
The BlackBerry Java development tools can be downloaded from http://www.blackberry.com/developers.
Several interesting knowledge base articles are related to concepts in this chapter:
  • How To: Create a Single .alx File to Install Multiple Versions of an Application (Article #DB-00028)
  • How To: Compile a MIDlet into a COD File (Article #DB-00055)
  • How to: Manually Register the CSI Files (Article #DB-00100)
  • What Is: Signature Key Format Changes in BlackBerry JDE 4.3.0 (Article #DB-00639)
  • Support: Unable to Register Keys or Sign a File While Behind a Proxy Server (Article #DB-00105)
  • How To: Use the Preprocessor (Article #DB-00712)
To access the articles, go to http://www.blackberry.com/developers and search for the relevant knowledge base article.
The BlackBerry Developer’s website hosts several tutorials related to content in this chapter:

martes, abril 17, 2012

Seguridad en servidores Linux

Tomado de: ARTICULO ORIGINAL

Como llevo unos cuantos post filosóficos, vamos ahora con algo más técnico. Vamos a darle un pequeño repaso a algunas medidas de seguridad básicas para un linux y a su aplicación real hoy en día. Como veremos, muchas de las cosas que se venden como “seguridad en servidores linux”, han quedado obsoletas y no sirven para mucho. Empezaremos por repasar algunos conceptos de los de toda la vida, como la búsqueda de ficheros setuidados y la deshabilitación de servicios innecesarios. Tras esto, le daremos un repaso a la importancia actual de estas medidas de seguridad en un entorno corporativo actual. Finalmente, hablaremos de las nuevas tendencias en seguridad.

Puntos de montaje

Por defecto, FEDORA va a permitir la ejecución de archivos en /tmp/. Esto no es que sea muy grave, pero lo ideal sería montar /tmp en una partición aparte teniendo cuidado de ponerle los permisos adecuados:
/dev/sda4 /tmp ext3 defaults,nodev,noexec,nosuid 1,2
Que le dice a linux que no puedan crearse dispositvos, ni ejecutables ni archivos setuidados. Hoy en día, también hay que decirlo en honor a la verdad, estas cosas han quedado un tanto obsoletas. La seguridad de servidores se centra en las aplicaciones web y las bases de datos, y no en esto.

buscar archivos con el suid y el sguid

La búsqueda la hacemos así: find / (-perm -4000 -o -perm 2000 ) -type f -exec ls {} ;
En la salida, podemos ver que algunos de estos archivos no necesitan estos permisos especiales puestos, por ejemplo:
-rwsr-xr-x 1 root root 47524 2009-12-15 14:43 /bin/umount
-rwsr-xr-x 1 root root 70348 2009-12-15 14:43 /bin/mount
-rwsr-xr-x 1 root root 36876 2009-07-26 14:22 /bin/ping6
-rwsr-xr-x 1 root root 42072 2009-07-26 14:22 /bin/ping

Permisos laxos en directorios

Debemos buscar todos los directorios que tengan permiso de escritura demasiado laxo, por ejemplo directorios con un rw para todos, y que no tengan el sticky bit. Si nos fijamos, /tmp tiene dicho bit, que sirve para que cada usuario sea propietario de sus archivos, aunque todos los usuarios tengan permiso de escritura en el directorio.
ll /|grep tmp
drwxrwxrwt 10 root root 4.0K 2010-01-27 16:35 tmp/
Podemos hacer la búsqueda de archivos con permisos de escritura para “otros” y “todos” con este comando:
find / -type d ( -perm -g+w -o -perm -o+w ) -not -perm -a+t -exec ls -lad {} ;
Cuando obtenemos un directorio con estos permisos, por ejemplo el de debajo, deberemos buscar qué usuarios están en el grupo al que pertenece el archivo y ver que es correcto confiar en que puedan escribir:
drwxrwxr-x 3 root lp 4096 2010-01-20 11:48 /var/cache/cups
En este caso, no pasa nada ya que el grupo es el usuario que se usa para imprimir, lp.
En linux es posible controlar de forma mucho más granular los permisos de los archivos usando ACLs, pero la realidad es que resulta algo incómodo de administrar cuando tienes muchos usuarios y, por lo tanto, se acaba tirando por la calle de en medio y creando unos pocos grupos en los que acaba todo el mundo.
Tipicamente, un servidor linux que tenga una aplicación corriendo de la propia empresa va a tener directorios con los permisos mal puestos. En lugar de perder nuestro tiempo buscando fallos en el sistema operativo que son muy difíciles de explotar, como lo pueda ser que el binario ping esté setuidado, es siempre mejor ir a estos directorios de la empresa e intentar sacar información útil de ellos. Seguramente encontraremos scripts ejecutados por root y con permisos 777. Es cuestión de tiempo.

logs

Lo ideal es guardar todos los logs en un servidor remoto. Pero, si esto no se hace, al menos pueden ponerse los archivos de logs como “only append”, así:
chattr +a /var/log/secure
Lo que nunca dicen en los libros, es que la rotación de logs FALLA si se hace esto. En principio parece una tontería, porque /var/log/secure tampoco ocupa tanto, pero si hacemos esto con los logs de, por ejemplo, el apache tendremos que tener cuidado de incluir en nuestros scripts las correspondientes instrucciones para quitar el +a y volverlo a poner al final.
También existe la posibilidad de hacer que sea imposible quitar el +a sin reiniciar el servidor. Para ello hay que modificar CAP_LINUX_IMMUTABLE. Puedes leer más sobre esto, por ejemplo, en este link
De todas formas, no me cansaré de insistir en que lo mejor es guardar los logs en un servidor remoto.

Permisos mínimos para cada usuario

Seguramente tendremos unos cuantos usuarios que lleven distintos componentes del servidor, por ejemplo podríamos tener uno para administrar el apache y otro para la base de datos. Pues bien, hay que intentar restringir lo más posible lo que puede hacer cada usuario. Para esto, contamos con sudo.
Por ejemplo, imaginemos que el usuario pepe necesita hacer un backup del directorio etc. En este caso, lo que haremos será incluir una linea en /etc/sudoers conteniendo exactamente el comando del backup, con todos sus parámetros.
No me meto en describir cómo funciona esto porque hay información de sobras en internet, por ejemplo.

Quitar servicios innecesarios

Deberemos ver qué servicios corren en la máquina y eliminar aquellos innecesarios. En particular, con netstat -nlp veremos qué programas están escuchando en qué puertos, lo cual permite deshabilitar aquellos que no consideremos oportunos.
Por ejemplo, seguramente querrás quitar ip6tables (salvo que tengas ipv6, que no creo), cups (salvo que des servicios de impresión), …
netstat -nlp|grep 631|grep -v 127.0.0.1
udp 0 0 0.0.0.0:631 0.0.0.0:* 864/cupsd
En Fedora, RedHat y similares, con setup accedemos a habilitar/deshabilitar servicios.
Muchas veces los admins se saltan este paso porque hay un firewall que corta todos los servicios que no escuchan, lo cual está muy bien, pero no debemos olvidar que el hecho de tener un servicio escuchando innecesariamente puede abrirnos las puertas a nuevos ataques, aunque hoy en día esto es un tanto improbable.

Chroot

Chroot es un entorno restringido para los usuarios. Digamos que un linux “mínimo” en el que ejecutamos nuestros programas. En principio, una forma muy eficiente de restringir los privilegios de un usuario, como pueda ser el del apache o una base de datos, pero en la práctica resulta un poco complicado de instalar y, sobre todo, de mantener.
Posiblemente el ejemplo más fácil de entender para chroot sea con vsftp, uno de los servidores FTP más seguros actualmente que corre bajo linux. Un usuario que haga loggin bajo chroot estará restringido a su home y no podrá navegar por los directorios y bajarse /etc/passwd, que es la metedura de pata típica al configurar un FTP bajo linux.
Para restringir un usuario en vsftp lo único que hace falta es editar vsftpd.conf y poner chroot_local_user=YES. Esto debería ser suficiente.
Dedicaremos un artículo a cómo configurar chroot para un entorno interesante, y no lo típico que uno se encuentra por la red, que es ftp o ssh.

Snort

Snort es un detector de intrusos que detecta ataques basado en patrones conocidos. Ya hemos hablado de él en numerosas ocasiones, por ejemplo aquí.
La instalación de snort y su actualización es totalmente trivial bajándose las reglas de emerging-threats, cosa que en su día explicamos en este post.
Snort tiene la ventaja de cazar eficientemente escaneos desde herramientas conocidas, como puedan serwikto o nmap, permitiendo además, combinado con otro HIDS como pueda ser ossec, bloquear la IP atacante al instante.
El problema con snort es que no se entera del tráfico que va por ssl … aparte de no servir para mucho detectando ataques sobre aplicaciones web.

HIDS/Integrity checkers

Otra parte importante de la seguridad en linux es tener un buen HIDS (Host Intrution Detection System). Entre ellos, personalmente, me gusta ossec, que corre tanto bajo linux como bajo windows.
Un HIDS tiene una serie de tareas encomendadas, como puedan ser:
- monitorizar cambios en archivos importantes de linux, como puedan ser /etc/passwd o los binarios del sistema.
- detectar, combinado con un sniffer de red, ataques desde otros HOSTs.
- controlar el uso de recursos en busca de posibles ataques por denegación de servicio.
- buscar posibles troyanos, rootkits, backdoors, …, malware en general que haya podido ser instalado por un usuario malicioso (vease la famosa herramienta chkrootkit).
- guardar los logs en un servidor remoto donde no puedan ser manipulados
[...]
El problema con los HIDS es que, hoy en día, la mayoría de veces que se entra en un servidor es vía la web y los ficheros que se modifican son los de la aplicación web. En una aplicación con varios miles de archivos asp no es fácil monitorizar la integridad.
Así pues, la instalación de HIDS en servidores, que no niego que sea necesario y que ofrezca “cierta” seguridad, realmente no significa mucho.

Modificación de banners

Otra de las cosas típicas que recomiendan en todos los libros de seguridad es modificar los banners de las aplicaciones (ftp, servidor de correo), para añadir un cierto grado de dificultad a la explotación del servicio.
Ciertos servicios, como puedan ser FTP o SSH, son muy fáciles de tocar. Por ejemplo, en vsftp tenemos la opción banner_file, que sirve exactamente para esto. Otros, como sendmail, requieren recompilar.
Este es un ejemplo de banner de POSTFIX modificado:
smtpd_banner = $myhostname ESMTP Sendmail 8.12.9
Con esto conseguiremos confundir a algunas herramientas típicas, como puedan ser nmap o amap. Pero un hacker no necesita para nada saber la versión exacta de servicio que corre … ¿acaso no es posible lanzar todos los exploits tanto para postfix como para sendmail “a ver si cuela”?
Hoy en día, al tener frameworks como metasploit, no supone ningún esfuerzo lanzar unas docenas de exploits en minutos. Así pues, la seguridad por oscuridad ayuda, pero desde luego muy poquito. No podemos confiar en cambiar los banners.
Seguramente podríamos hablar y hablar de otras medidas de seguridad “a la vieja usanza” que pueden adoptarse en un servidor linux, pero estas son suficientes para pasar al siguiente punto …

CONCLUSIONES

De acuerdo, podemos quitar paquetes innecesarios, minimizar los servicios que corren, instalar HIDS, snort, tener logs remotos, buscar backdoors y troyanos en el sistema, cambiar banners, poner los servicios en CHROOT, … Podemos hacer todo esto y más pero, ¿sirve para algo?
Todas estas medidas antes mencionadas son requisito de normas como PCI-DSS, que es obligatorio para manipular tarjetas de crédito, y, sin embargo, siguen robándose tarjetas de crédito. ¿Por qué?
La explicación es que hoy en día nadie tiene demasiado interés en instalar un troyano en un sistema o en intentar explotar una versión vieja de sendmail (cosa casi imposible en una entidad mínimamente importante). Las intrusiones vienen por la web, principalmente vía sql-injection en entornos LAMP, y los hackers no tienen ningún interés en añadir un usuario al sistema.
Lo que se busca es acceder a la base de datos y bajársela, nada más. No importa que sea un entorno chroot, ya que seguiremos podiendo hacer queries contra el mysql, que es realmente lo que necesitamos. Tampoco importa que vigilemos todo el tráfico de entrada en busca de patrones conocidos, puesto que en realidad este tráfico es muy fácil de confundir con tráfico legítimo. ¿Para que sirven los IDS/IPS?
La seguridad “tradicional” a muerto. Hoy en día lo realmente importante es securizar a nivel de aplicación.¿Afrontamos el problema o lo seguimos ignorando?

viernes, abril 13, 2012

Genexus - Mi Primera Aplicacion REAL con BlackBerry

    Ejecute los siguientes pasos, en base a una serie de consultas mediante el GX Search y el Fabuloso Google.

    1. He seguido los pasos que indica esta URL: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?BlackBerry+Generator+Prerequisites,
    2. Instale el JDK 1.6.
    3. Descargue el BlackBerry_JDE_5.0.0.exe  desde https://swdownloads.blackberry.com/Downloads/contactFormPreload.do?code=DC727151E5D55DDE1E950767CF861CA5&dl=64708E60AB0D8A0A60409FE3DF90EF9B
    4. Descargue el archivo BlackBerry_Simulators_5.0.0.979_9700.exe  desde  https://swdownloads.blackberry.com/Downloads/contactFormPreload.do?code=DC727151E5D55DDE1E950767CF861CA5&dl=F8B968F24889EC1FE48A4E0599695F32 porque tengo un BlackBerry Bold 9700 con Sistema Operativo 5.
    5. Los ejecute para instalar, se realizo esta tarea sin problemas.
    6. Ingrese a esta URL: https://www.blackberry.com/SignedKeys/
    7. Llene los datos en el formulario.
    8. Inmediatamente me enviaron un correo donde  se notifica que estaban procesando la ORDEN, cuya respuesta sera en 2 Horas.
    9. Transcurrido los 120 Minutos, descargue el correo.
    10. Me enviaron tres CORREOS cada uno con el archivo con extensión .csi.
    11. Me ubique en donde esta instalado el SDK de BlackBerry generalmente en: c:\Program Files\Research In Motion\BlackBerry JDE 5.0.0\bin\
    12. Copie los tres archivos de extension .csi, en esa carpeta.
    13. Ejecute de la siguiente manera con el primer archivo con extension csi
    14. javaw -jar SignatureTool.jar client-RBB-1667089554.csi

      Aparece un cuadro de dialogo para continuar o no:
      •  Click Yes para crear el nuevo par de archivos
      •  Digite el password dos veces, no debe tener menos de ocho caracteres.
      • Le Recomienda mover el Ratón para que genere correctamente las claves
      • En el campo de PIN asignar el correspondiente de su BB.
    15. Click Register.
    16. Click Exit.
    17. Realice nuevamente los pasos 14 a 16 con los dos archivos faltantes (client-RCR-1667089554.csi y client-RRT-1667089554.csi), manteniendo siempre el mismo password.
    18. Por seguridad he creado un nuevo Environment
    19. Modifique en el Gx Ev2 dentro de la propiedad - BlackBerry Signature Tool Password, asignando el mismo Password que utilicè en el paso 14.
    20. Se realizo los cambios como consta en la siguiente gráfica:
    21. Realice un Rebuild All.
    22. Se publica la aplicación generando el .jad con la siguiente URL:  http://localhost:8080/bbb/blackberry/Menu_OS5.jad
    23. Ingrese al BlackBerry en el navegador digite esta URL: http://localhost:8080/bbb/blackberry/Menu_OS5.jad , descargo el archivo sin problemas y procedió a instalar.
    24. Ejecute dicha aplicación sin problemas.
    25. Cuando intento ingresar o modificar un registro, me reporta el siguiente Error: Internal Server Error . See Log for Details, pregunta donde veo el LOG.
    26. He revisado el Tomcat, en efecto existe un error que indica lo siguiente:

      lunes, abril 09, 2012

      Monitorizar AS400 / iSeries con Nagios / Centreon

      Tomado de: Articulo Original

      Screenshots

      Vista de Servicios por Host.


      Eventos producidos por mis servidores AS400


      Gráficas de uso de disco y cpu:

      iSeries Plugin para Nagios

      Monitorizar iSeries con el Plugin "check-iseries.php".

      El plugin para Nagios "check_iseries.php", desarrollado con licencia open source por esta compañia www.stic-online.de/stic/html/as400plugin.html, nos permite hacer una sesion telnet en nuestro servidor y recopilar informacióbn mediante mandatos de AS400 / iSeries.

      El funcionamiento podría describirse como:


      iSeries SNMP

      SNMP es un protocolo bastante enrevesado, pero útil, que posibilita el intercambio de información entre dispositivos de red. Y esto, implica cualquier dispositivo, ordenador que esté en la red, desde una cafetera que tenga su propio SNMP hasta el servidor más potente.

      Cada dispositivo (un switch, una impresora) o ordenador posee un identificador propio llamado "MIB" para cada "objeto" del dispositivo en la red. Este "objeto", describe un estado o un valor de nuestros dispositivo u ordenador.

      Para ser claros, hay un valor MIB para el estado "on/off" de un ordenador, para definir si la cafetera necesita más agua, para definir cuanto espacio hay en disco.

      Cada fabricante tiene su propio MIB. Para usar SNMP, necesitamos:
      1. tener SNMP activado en el dispositivo o servidor (no se si hay cafeteras que lo tengan).
      2. Activar una "comunidad" para conectarse al dispositivo o servidor. (activar SNMP en AS400)
      3. Un software para comunicarse desde un cliente mediante protocolo SNMP. (Desde linux basta con SNMPWALK).
      4. Conocer el mib del dispositivo.

      Instalar SNMP en Linux.

      Básicamente instalar el paquete:

      sudo apt-get install snmpd

      Probablemente el instalador requerirá alguna dependendencia, que en ese caso, se resuelve automaticamente o:
      sudo apt-get install paquete_requerido.

      Configurar SNMP en AS400

      CFGTCPSNMP ->
      1. CHGSNMPA SYSCONTACT('mi nombre') SYSLOC('mi nombre') SNDAUTTRP(*YES) OBJACC(*READ)
      2. trabajar con comunidades. Añadir un nombre que no sea "public" o el nombre del servidor (por razones de seguridad).

      Iniciar SNMP: STRTCPSVR *SNMP

      3. Test de SNMP.

      Probar desde linux el siguiente mandato desde la linea de comandos (si habeís instalado SNMPWALK)

      snmpwalk -v 1 -c micomunidadeniseries miip

      Si obtienes una larga lista de información, enhorabuena! SNMP funciona en tu AS400!

      Instalar Centreon

      Instalar Centreon.

      Sigo con el blog.

      Espero tener ahora un poco más de tiempo para trabajar en este blog.
      Actualmente os puedo decir que se puede hacer DE TODO con Nagios en AS400. Lo mejor de Nagios es que nos permite editar nuestros comandos (aqui es cuando necesitamos conocimientos en lenguajes como PHP, Python, perl, java) para escribir nuestros comandos.

      Actualmente estoy monitorizando, no solo el sistema, sino las aplicaciones. Ejemplos:

      1. Ejecutar un script php que compruebe que el servidor http está funcionando mientras ejecuto un query en el AS400. Puedo grabar el tiempo de respuesta en las gráficas de Centreon.
      2. Comprobar que las transaciones FTP funcionan, ejecutando RUNQRY desde Nagios.

      Asi que espero comenzar a describiros algunas cosas.

      Instalar Nagios

      Instalación de Nagios.

      Existe amplia documentación en internet sobre como instalar Nagios y no voy a dedicar este blog a explicar como hacerlo, pero si algunos detalles.

      En mi instalación tengo:

      1. Ubuntu Server. Si no tienes muchos conocimientos de Linux, recomiendo Ubuntu Desktop.
      2. Instalar PHP, Apache y MySQL (todos pueden ser instalados con apt-get o vienen por defecto en Ubuntu, según versión).
      3. Nagios 3.
      4. Paquetes como: SNMP, Perl, etc (los irá requiriendo la instalación).

      1. Preinstalación. Apache y PHP
      •sudo apt-get install build-essential
      •sudo apt-get install libgd2-xpm-dev
      •sudo apt-get install apache2
      •sudo apt-get install php5-common php5 libapache2-mod-php5
      (para Centreon) sudo apt-get install mysql-server

      Comprueba en http://localhost si Apache está funcionando.
      Si no, prueba a activarlo:

      sudo /etc/init.d/apache2 restart o sudo /etc/init.d/apache2 start

      Si Apache no viene configurado para usar PHP:
      sudo vim /etc/apache2/apache2.con

      y copia en el fichero:
      DirectoryIndex index.html index.php index.cgi


      2. Descargar Nagios. www.nagios.org

      Si es la primera vez que trabajas con Nagios, recomiendo que hagas una instalación limpia, sin usar "APT-GET INSTALL NAGIOS3", ya que APT-GET te va a crear otros directorios de instalación, y cuando instales Centreon, vas a tener que cambiar el instalador de Centreon, y es bastante complicado.

      Asi pues recomiendo descargar el fichero "tar" de nagios y seguir paso a paso la instalación. (usa el browser o wget):

      Nagios Core:
      sudo wget http://downloads.sourceforge.net/nagios/nagios-3.1.0.tar.gz?use_mirror=voxel

      Nagios Plugins (necesario):
      sudo wget http://downloads.sourceforge.net/nagiosplug/nagios-plugins-1.4.13.tar.gz?use_mirror=voxel

      3. Comenzar la Instalación.

      Descomprimir:
      sudo tar -zxvf nagios-3.1.0.tar.gz

      Crear usuarios:
      •sudo useradd -m nagios
      •sudo passwd nagios
      •sudo groupadd nagcmd
      •sudo usermod -a -G nagcmd nagios
      •sudo usermod -a -G nagcmd www-data

      Compilar Nagios:
      •sudo ./configure --with-command-group=nagcmd
      •sudo make all
      •sudo make install
      •sudo make install-init
      •sudo make install-config
      •sudo make install-commandmode
      •sudo make install-webconf

      4.Configurar el servidor WEB.
      vamos a añadir un usuario admin para la interfaz Web de nagios mediante este mandato:

      sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

      Y ahora, configuremos el directorio donde se ejecuta la aplicacion web de Nagios:
      ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin


      Options ExecCGI
      AllowOverride None
      Order allow,deny
      Allow from all
      AuthType Basic
      AuthUserFile /usr/local/nagios/etc/htpasswd.users
      Require valid-user


      Alias /nagios /usr/local/nagios/share


      Options None
      AllowOverride None
      Order allow,deny
      Allow from all
      AuthType Basic
      AuthUserFile /usr/local/nagios/etc/htpasswd.users
      Require valid-user


      ServerName localhost


      reinicia apache:sudo /etc/init.d/apache2 restart


      5. Instalando los Plugins de Nagios.


      Extraemos el fichero tar "nagios-plugin-xxx" y hacemos lo siguiente:


      •cd ~/
      •tar -zxvf nagios-plugins-1.4.13.tar.gz
      •cd nagios-plugins-1.4.13
      •sudo ./configure --with-nagios-user=nagios --with-nagios-group=nagios
      •sudo make
      •sudo make install

      Enlace simbolico para acceder a nagios
      sudo ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

      Verificar configuracion de Nagios (en nuestro caso debe de ser OK, ya que no la hemos editado):
      sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

      Start Nagios:

      sudo /etc/init.d/nagios start

      6. Test de Nagios:

      Web: http://localhost/nagios


      ERRORES.

      a. Faltan paquetes de instalación.

      Normalmente Nagios necesita paquetes especiales en función del plugin que usamos. Si usamos SNMP o plugin basados en perl o java, debemos de hacer la instalacion.

      Con suerte, Ubuntu es muy amigable para ayudarnos a hacer estas instalaciones con APT-GET.

      y para que "Centreon"?

      Centreon es un "front-end" para Nagios. Es una aplicación web instalada en el mismo servidor que Nagios. No es imprescindible, pero si muy útil.

      por que?
      Una vez instalamos Nagios, se nos hace un poco complicado configurarlo para añadir servicios y comandos. Se hace a través de archivos de texto
      Ademas, tenemos que parar Nagios cada vez que añadimos un nuevo servicio.

      Aunque no nos evita tener que repasar (o aprender) sobre Linux, es una herramienta muy interesante para que nos empiece a gustar Nagios y jugar con él (que es la mejor manera de aprender a vaces).

      Otra de las ventajas de Centreon es que se adapta muy bien a otros plugins para Nagios como la generación de gráficas (que es una de las cosas que necesitaba y más me han atraido). A parte, tiene la misma usabilidad que Nagios.

      Descargar Centreon:
      http://www.centreon.com/Centreon/download.html

      viernes, abril 06, 2012

      Fases de Madurez de SOA

      Blogs de Referencia:

      modelos-de-madurez-porque-tenerlos

      soa-maturity-model

      Modelo de Madurez SOA


      Tomado de: Fases de Madurez de SOA

      Aquellas organizaciones que se plantean iniciar una nueva iniciativa en el mundo tecnológico deben plantearse el siguiente interrogante: ¿Cómo determinar el grado de beneficio que aporta una tecnología a mi sistema empresarial? SOA no es diferente al resto de paradigmas tecnológicos por lo que centrará sus objetivos (tecnológicos y de negocio) en lograr unos beneficios, muy centrados en alta flexibilidad de respuesta y adaptación al negocio, y reducir los costes inicialmente planteados. La respuesta puede parecer sencilla: “Para evaluar el grado de beneficio es necesario medir los costes que suponen alcanzar los objetivos planteados”; sin embargo esta respuesta, por todas las organizaciones conocida, suele ser el inicio de enormes quebraderos de cabeza de usuarios de negocio, arquitectos, analistas funcionales, desarrolladores, jefes de proyecto, etc. Una vía de enfocar la evaluación y análisis del grado de madurez en SOA se puede basar en CMM (Capability Maturity Model, SEI, 1991) y sus niveles básicos:

      - Inicial: Procesos no instaurados, desarrollo de proyectos no transparentes.

      - Repetible: Proyectos gestionados y controlados durante el desarrollo de los mismos. Los resultados satisfactorios se repiten. - Definido: Forma de desarrollar proyectos se encuentra establecida y gestionada. Proceso de Ingeniería controlado.

      - Controlado y Cuantificado: Nivel en el que los proyectos se encuentran con objetivos fácilmente medibles y cuantificables.

      - Optimizado: Mejora continúa. Se producen iteraciones continuas para la mejora del desarrollo de los proyectos. A continuación podemos observar una pirámide donde se ven las fases de madurez de SOA relacionadas con el modelo de madurez CMM: Modelo de Madurez SOA – Niveles CMM Los niveles de madurez de SOA se dividen en:

      1. Servicios Iníciales: Fase en la que aun no se ha producido un alineamiento con las necesidades de negocio, simplemente se implementa tecnológicamente cierta funcionalidad para cubrir las primeras necesidades de negocio. 
      2. Servicios con Arquitectura: Se definen los límites que evitan un crecimiento descontrolado de los servicios de negocio implementados en la fase anterior del modelo. En esta fase crecen la consistencia, la fiabilidad y el control de los servicios. 
      3. Servicios de Negocio y Colaborativos: Se produce una consolidación de los procesos de negocio en forma de servicios, en esta fase la tecnología converge con las necesidades de negocio. Existen dos tipos de servicios: 


        • Servicios de negocio donde el mundo tecnológico se pone al servicio del negocio.
        • Servicios colaborativos donde se definen servicios que sirven de interacción entre entidades compuestas colaboradores, partners o los mismos departamentos de la organización. 


      1. Medición de los Servicios de Negocio: Se analizan los resultados de los servicios mediante el uso de métricas definidas y analizadas por usuarios de negocio y tecnológicos. 
      2. Optimización de los Servicios de Negocio: Fase en la que los servicios son analizados para encontrar puntos de mejora continúa. Esta fase se lleva a cabo dentro de un ciclo que tiene como final la retirada del servicio de negocio analizado. 

      Niveles de madurez SOA
      Es importante considerar que los servicios no solo de analizan de manera individual sino también de forma conjunta analizando las interacciones entre ellos. Determinar en qué nivel de madurez SOA se encuentra una organización suele ser una quimera en la mayoría de los casos, ya que una organización suele considerar que está más arriba de la pirámide cuando en realidad no es más que una ilusión. Es necesario realizar una evaluación realista no solo desde un punto de vista tecnológico, sino también funcional y de negocio. Una evaluación realista de donde nos encontramos nos llevara al éxito en cualquier iniciativa SOA que llevemos a cabo.



      Muchas cosas con las que he trabajado y otras de las que habia oido hablar (ESB, BAM, BPM, BPEL etc) hicieron sentido cuando revise el modelo de madurez.

      El modelo se compone de 5 niveles...

      • Initial Services: Indica fases de exploracion y adopcion SOA, se logra que en los proyectos de desarrollo se integre SOA como parte de la arquitectura, se utilizan como estandar WSDLSOAP, J2EE y .NET, en este nivel existen servicios creados para necesidades inmediatas NO para servicios de negocio
      • Architected Services: En este nivel entra la mediacion de servicios, ¿les suena a ESB?, en efecto, aqui entra en juego las caracteristicas de un ESB, mensajeria confiable (WS-RM), transformacion (Xquery), etc.. ademas de contar con un registros de los servicios como lo es UDDI. En este nivel se encuentra la integracion a bases de datos mediante EII.
      • Business Services/Collaborative Services: Aqui entra en juego un punto de vista importante de los usuarios: EL NEGOCIO. Para estar en este nivel, ya se debe contar con el desarrollo de servicios de negocio. Existe tambien lacolaboracion de servicios para lograr procesos que den mayor sentido a la organizacion, aqui es donde hace sentido lo que se conoce como Business Process Management
      • Mesuared Business Services: Aqui en punto principal es el monitoreo de procesos.. tal como lo marca Business Activity Monitoring, por ejemplo proactivity es uno de ellos. En este nivel puedes tener metricas de los procesos de negocio basados en servicios ;)
      • Optimized Business Services: como el nombre lo dice... ya que logarste tener metricas, viene la optimizacion de los procesos de negocio, aqui entra una cultura de mejoramiento continuo.
      Como veran muchos estamos en el nivel 1 o quizás 2, lo cual me dice que hay mucho trabajo que hacer.....