I am Prasad Vejju 

How to take Thread Dump,Heap Dump in UNIX

Thread and Heap dumps ,we can use a single command to generate both of these.
But keep remember that generating a heap dump will hang the process you are applying on,till the required file got generated.

You have to set the below statement  at JVM during its start up.

-Xdump:java+heap+system+snap:events=user 

Command to generate dump : kill -3 <PID>  / kill -QUIT <PID>

Access this link if you need some more information.

mysqldump command for retreiving data from table with condition

mysqldump -t -uprasad -p*******  props base_properties  --where="snapshot_id in ('GA')" > sendTo.sql

Jboss Clustering

CREATING THE JBOSS CLUSTERS

Let us try configuring 2 nodes, say node1 and node2

• Create folders namely node1, node2 under jboss4.0.1sp1\server. (Create as many folders as the number nodes you require like node1, node2, node3 etc. Here we consider only 2)

• Copy the jboss4.0.1sp1\server\all to the folders node1, node2

• Create a folder named binding-manager under node1 and node2 folders

• Copy the folder jboss4.0.1sp1\docs\examples\binding-manager to jboss4.0.1sp1\server\node1\

• Rename the file to port-bindings.xml

• In the file jboss4.0.1sp1\server\node1\conf\jboss-service.xml, uncomment the block

<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name="StoreURL">some file </attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>

• Change the StoreURL as follows
<attribute name="StoreURL">file:../server/node1/binding-manager/port-bindings.xml</attribute>

• Ensure that the following is uncommented <server name="ports-01">

• Copy the folder jboss4.0.1sp1\docs\examples\binding-manager to jboss4.0.1sp1\server\node2\

• Rename the file to port-bindings.xml

• Ensure that the following is uncommented <server name="ports-02">

• In the file jboss4.0.1sp1\server\node2\conf\jboss-service.xml, uncomment the block

<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name="StoreURL">some file </attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>

• Change <attribute name="ServerName">ports-01</attribute> as
<attribute name="ServerName">ports-02</attribute>

• Change the StoreURL as follows
<attribute name="StoreURL">file:../server/node2/binding-manager/port-bindings.xml</attribute>

• Copy the file jboss4.0.1sp1\server\all\deploy\deploy.last\farm-service.xml to
jboss4.0.1sp1\server\node1\deploy.last and
jboss4.0.1sp1\server\node2\deploy.last

• Open the file jboss-4.0.1sp1\server\node1\deploy\jbossweb-tomcat50.sar\server.xml

• Replace <Engine name="jboss.web" defaultHost="localhost"> with
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">

• Open the file jboss-4.0.1sp1\server\node2\deploy\jbossweb-tomcat50.sar\server.xml

• Replace <Engine name="jboss.web" defaultHost="localhost"> with
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node2">
 

STARTING THE CLUSTERS
The simplest way to start a JBoss server cluster is to start several JBoss instances on the same local network. We can use the “run -c all” command for each instance. These server instances are all started in the “all” configuration and they detect each other automatically and form a cluster.



• Open Command Prompt

o Start node1 from command line with partition name

jboss4.0.1sp1\bin\ run -c node1

o Leave 10 seconds gap

• Open another Command Prompt

o Start node1 from command line with partition name

jboss4.0.1sp1\bin\ run -c node2

• Both the nodes should be up and running

• Now that we have made sure that the port numbers are changed by application server and so no longer we can access 8080 as the default port for web console for node1 and node2.

It might be 8180 and 8280 respectively.

So if you access thru http://localhost:8180/web-console you can access node1 and
similarly http://localhost:8280/web-console you can access node2 

                                                                                                                  Courtesy : Vibhuti Goel

Open Source Integration with Apache Camel By Jonathan Anstey

Take any integration project and you have multiple applications talking over multiple transports on multiple platforms. As you can imagine, in large enterprise applications this can get complex very fast. Much of the complexity stems from two issues:

1.  dealing with the specifics of applications and transports, and

2.  coming up with good solutions to integration problems.

Making your applications speak transports and APIs is relatively easy on its own. I'm sure everyone knows how to send JMS messages to their broker of choice; though it still requires in depth knowledge of the JMS specification, which many developers may not have. On top of that, what happens when you want to route that JMS message to another application? You then have to take care of mapping the JMS message to the application plus handle any new concepts related to the application. Add a dozen other applications into the mix and you've got quite a headache on your hands.

Ignoring the mechanics of how to connect with multiple transports and APIs, we can focus on the high level design of how applications interact. Fortunately, most solutions to enterprise integration problems have been formalized already. Gregor Hohpe and Bobby Woolfe's book, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, boils down years of experience from enterprise architects into a set of sixty five Enterprise Integration Patterns (EIPs). This is great but we still have to hand code all parts of these patterns; these are not packaged solutions, only recommendations. 

Apache Camel was created with the intention of addressing these two issues. In this article he'll first give you a quick overview of what Camel is. He’ll then guide you through how Camel solves a sample integration problem. Finally He’ll show off some new graphical tooling that makes it even easier to solve integration problems with Camel.

What is Camel?

Apache Camel is an open source Java framework that focuses on making integration easier and more accessible to developers. It does this by providing:

•     concrete implementations of all the widely used EIPs

•     connectivity to a great variety of transports and APIs

•     easy to use Domain Specific Languages (DSLs) to wire EIPs and transports together

Figure 1 shows how these three items actually map to Camel concepts. To give you a good understanding of how Camel is organized, we will discuss Components, Endpoints, Processors, and DSLs. There is of course a lot more going on here under the hood but we'll leave that for another discussion.

Figure 1: High level view of Camel's architecture (from Camel in Action).

Components are the extension point in Camel to add connectivity to other systems. The core of Camel is very small to keep dependencies low, promote embeddability, etc. and as a result contains only 13 essential components. There are over 80 components outside the core. To expose these systems to the rest of Camel, Components provide an Endpoint interface. By using URIs, you can send or receive messages on Endpoints in a uniform way. For instance, to receive messages from a JMS queue aQueue and send them to a file system directory "/tmp", you could use URIs like "jms:aQueue" and "file:/tmp".

Processors are used to manipulate and mediate messages in between Endpoints. All of the EIPs are defined as Processors or sets of Processors. As of writing, Camel supports over 40 patterns from the EIP book and many other useful Processors.

To wire Processors and Endpoints together, Camel defines multiple DSLs in regular programming languages such as Java, Scala and Groovy. It also allows routing rules to be specified in XML. Here are some DSL examples using different languages and staying functionally equivalent:

•       Java DSL

view sourceprint?

1.from ("file:/tmp").to("jms:aQueue");

•       Spring DSL

view sourceprint?

1.<route>

2.<from uri="file:/tmp"/>

3.<to uri="jms:aQueue"/>

4.</route>

•       Scala DSL

view sourceprint?

1.from "file:/tmp" -> "jms:aQueue"

In all the above examples we define a routing rule that will load files in the “/tmp” directory into memory, create a new JMS message with the file contents, and send that message to a JMS queue named aQueue.

These are the concepts that Camel was built upon. Since then many other interesting features have been added. He recommends reading Camel in Action, by Claus Ibsen and myself to really get the full picture of what Camel can do. But, to get you started, some of these extra features include:

•     Pluggable data formats and type converters for easy message transformation between CSV, EDI, Flatpack, HL7, JAXB, JSON, XmlBeans, XStream, Zip, etc.

•     Pluggable languages to create expressions or predicates for use in the DSL. Some of these languages include: EL, JXPath, Mvel, OGNL, BeanShell, JavaScript, Groovy, Python, PHP, Ruby, SQL, XPath, XQuery, etc. 

•     Support for the integration of beans and POJOs in various places in Camel.

•     Excellent support for testing distributed and asynchronous systems using a messaging approach

•     and much more...

Introducing Rider Auto Parts

The example in this article is based on a fictional motorcycle parts business used throughout the Camel in Action book. The company, named Rider Auto Parts, supplies parts to motorcycle manufacturers. Over the years, they’ve changed the way they receive orders several times. Initially, orders were placed by uploading comma-separated value (CSV) files to an FTP server. The message format was later changed to XML. Currently they provide a website through which orders are submitted as XML messages over HTTP.

Rider Auto Parts asks new customers to use the web interface to place orders, but because of service level agreements (SLAs) with existing customers, they must keep all the old message formats and interfaces up and running. All of these messages are converted to an internal Plain Old Java Object (POJO) format before processing. A high level view of the order processing system is shown in Figure 2.

Figure 2: High level view of order processing at Rider Auto Parts (from Camel in Action).

We need to find out the best way to implement the “Rider order frontend” in Figure 2 above. Let’s first see how this looks using notation from the Enterprise Integration Patterns book.

Solution using EIPs

Rider Auto Parts faces a pretty common problem; over years of operation businesses acquire software baggage in the form of transports/data formats that are popular at the time. Using patterns from the EIP book we can envision the solution as something like Figure 3.

Figure 3: This shows the solution to Rider Auto Parts integration problem using notation from the Enterprise Integration Patterns book.

So we have several patterns in use here.

1. There are two Message Endpoints; one for FTP connectivity and another for HTTP.

2. Messages from these endpoints are fed into the incomingOrders Message Channel

3. The messages are consumed from the incomingOrders Message Channel and routed by a Content-Based Router to one of two Message Translators. As the EIP name implies, the routing destination depends on the content of the message. In this case we need to route based on whether the content is a CSV or XML file.

4. Both Message Translators convert the message content into a POJO, which is fed into the orders Message Channel.

The whole section that uses a Content-Based Router and several Message Translators is referred to as a Normalizer. This composite pattern has a unique graphic to depict it but was left out here in favor of its sub-patterns to make things clearer.

Implementation using Camel

As mentioned before, Camel has a small core set of components included by default. The rest of the components exist as separate modules. In applications that require many types of connectivity it is useful to figure out what Camel modules to include. Listing 1 shows the dependencies using Apache Maven for the Camel implementation of the Rider Auto Parts example. Of course, you don't need to use Apache Maven for dependencies - it is just the easiest way to rapidly add new dependencies to your applications. The list of dependencies includes support for core Camel, ActiveMQ, JAXB marshaling, CSV marshaling, and HTTP. To make the example easier to try out, He've opted to use the File endpoint instead of the FTP. If we were using the FTP endpoint we would need to add a dependency on the camel-ftp module as well.

Listing 1: Maven dependencies for the Camel implementation

view sourceprint?

01.<dependencies>

02.<!-- Core Camel -->

03.<dependency>

04.<groupId>org.apache.camel</groupId>

05.<artifactId>camel-core</artifactId>

06.<version>${camel-version}</version>

07.</dependency>

08.<dependency>

09.<groupId>org.apache.camel</groupId>

10.<artifactId>camel-spring</artifactId>

11.<version>${camel-version}</version>

12.</dependency>

13. 

14.<!-- Embedded ActiveMQ broker -->

15.<dependency>

16.<groupId>org.apache.activemq</groupId>

17.<artifactId>activemq-core</artifactId>

18.<version>${activemq-version}</version>

19.</dependency>

20.<dependency>

21.<groupId>org.apache.xbean</groupId>

22.<artifactId>xbean-spring</artifactId>

23.<version>${xbean-spring-version}</version>

24.</dependency>

25. 

26.<!-- ActiveMQ connectivity for Camel -->          

27.<dependency>

28.<groupId>org.apache.activemq</groupId>

29.<artifactId>activemq-camel</artifactId>

30.<version>${activemq-version}</version>

31.</dependency>

32. 

33.<!-- Add support for JAXB marshaling -->

34.<dependency>

35.<groupId>org.apache.camel</groupId>

36.<artifactId>camel-jaxb</artifactId>

37.<version>${camel-version}</version>

38.</dependency>

39. 

40.<!-- Add support for CSV marshaling -->  

41.<dependency>

42.<groupId>org.apache.camel</groupId>

43.<artifactId>camel-bindy</artifactId>

44.<version>${camel-version}</version>

45.</dependency>   

46. 

47.<!-- Add support for HTTP -->

48.<dependency>

49.<groupId>org.apache.camel</groupId>

50.<artifactId>camel-jetty</artifactId>

51.<version>${camel-version}</version>

52.</dependency>

53. 

54.</dependencies>

While it is perfectly legitimate to use Camel as a standalone Java application, it is often useful to embed it in a container. In this case, we will be loading Camel entirely from Spring. In fact, the entire solution (except for the domain POJO and Maven build script) fits neatly into a single Spring XML file. This is because we are implementing our routing rules using the Spring XML configuration rather than one of Camel’s other DSLs. There are pros and cons to each of course but in this case he mainly wanted to show off some cool tooling that currently works with the XML based routing rules only. The Spring XML file is shown in Listing 2 below.

Listing 2: Complete Spring XML file that configures an embedded ActiveMQ broker and initializes a Camel Context with three routes.

view sourceprint?

01.<beans xmlns="http://www.springframework.org/schema/beans"

02.xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

03.xmlns:amq="http://activemq.apache.org/schema/core"

04.xsi:schemaLocation="

05.http://www.springframework.org/schema/beans

06.http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

07.http://activemq.apache.org/camel/schema/spring

08.http://activemq.apache.org/camel/schema/spring/camel-spring.xsd

09.http://activemq.apache.org/schema/core

10.http://activemq.apache.org/schema/core/activemq-core.xsd">

11. 

12.<amq:broker brokerName="localhost" persistent="false" useJmx="false"/>

13. 

14.<bean id="jms" class="org.apache.activemq.camel.component.ActiveMQComponent">

15.<property name="brokerURL" value="vm://localhost" />

16.</bean>

17. 

18.<camelContext xmlns="http://camel.apache.org/schema/spring">

19.<route id="FileToJMS">

20.<from uri="file:target/placeorder" />

21.<to uri="jms:incomingOrders" />

22.</route>

23. 

24.<route id="HTTPtoJMS">

25.<from uri="jetty:http://0.0.0.0:8888/placeorder" />

26.<inOnly uri="jms:incomingOrders" />

27.<transform>

28.<constant>OK</constant>

29.</transform>

30.</route>

31. 

32.<route id="NormalizeMessageData">

33.<from uri="jms:incomingOrders" />

34.<convertBodyTo type="java.lang.String" />

35.<choice>

36.<when>

37.<simple>${body} contains '?xml'</simple>

38.<unmarshal>

39.<jaxb contextPath="org.fusesource.camel" />

40.</unmarshal>

41.<to uri="jms:orders" />

42.</when>

43.<otherwise>

44.<unmarshal>

45.<bindy packages="org.fusesource.camel" type="Csv" />

46.</unmarshal>

47.<to uri="jms:orders" />

48.</otherwise>

49.</choice>    

50.</route>

51.</camelContext>

52.</beans>

In this file we first start an embedded Apache ActiveMQ broker and connect Camel to it. Next comes the camelContext element where we define our routing rules. Looking back at Figure 3, we need to receive orders from an FTP (substituted with File in this example) and HTTP endpoint, formatted as shown in Listing 3. In the Spring XML configuration we can specify these incoming endpoints with two from elements. The “FileToJMS” and “HTTPtoJMS” routes start off with these from elements. Both from elements are connected to a producer (to and inOnly elements) using the “jms:incomingOrders" URI, which will send the messages to a queue named incomingOrders on the ActiveMQ broker.

Listing 3: Incoming message formats; XML on the left, CSV on the right.

<?xml version="1.0" encoding="UTF-8"?> <order name="motor" amount="1"/>

"name", "amount" "brake pad", "2"

In the case of the HTTP endpoint, there are a couple of extra things to mention. First off the HTTP client will be expecting a response from the application so we have to handle that. In Camel, we have full control over what the client gets back from the HTTP endpoint. Each response is determined by the last method in our current route definition. In our case we use the transform method to set the response to the constant string "OK". Since we handle the response ourselves, we don’t want any response to come from the JMS incomingOrders queue. To send to this queue in a fire-and-forget fashion we use the inOnly element rather than the to element. 

The “NormalizeMessageData” route in Listing 2 specifies the Normalizer, complete with Content-Based Router and two Message Translators. First we specify that we want to consume messages from the incomingOrders queue on the ActiveMQ broker. The content based routing of the messages is done with the choice, when, and otherwise elements. In our case, we want to send CSV messages to one Message Translator and XML messages to another. To check what type of message data format we have we use a Simple expression which checks the message body for the “<?xml” start tag. Simple is an expression language built in to Camel. Of course, this is demonstration code only; for production cases you would want to add more thorough checking of content types.

To unmarshal the XML and CSV payloads into an Order object, we use Camel’s data formats. Listing 2 shows how these data formats are defined within the unmarshal elements. As shown in Listing 5, the Order object has JAXB and Camel Bindy annotations to describe the mapping to XML and CSV.

Listing 5: The Order domain class with JAXB/Bindy annotations for easy mapping to and from XML/CSV.

view sourceprint?

01.@XmlRootElement

02.@XmlAccessorType(XmlAccessType.FIELD)

03.@CsvRecord(separator = ",", skipFirstLine = true)

04.public class Order implements Serializable {

05.@XmlAttribute

06.@DataField(pos = 1)

07.private String name;

08. 

09.@XmlAttribute

10.@DataField(pos = 2)

11.private int amount;

12. 

13.public Order() {

14.}

15. 

16.public Order(String name, int amount) {

17.this.name = name;

18.this.amount = amount;

19.}

20.}

At this point, successfully normalized messages are sent to the orders queue for processing by some other application at the Rider Auto Parts business.

Implementation using Fuse IDE for Camel

As we’ve seen, Apache Camel certainly makes it easy to create integrations. The DSLs in various languages are designed to be concise, powerful and easy to read – all with the goal of making you, the developer, more productive. With improving productivity in mind, FuseSource has created an IDE for Camel development called Fuse IDE for Camel.

Fuse IDE is an Eclipse-based tool that allows you to drag and drop enterprise integration pattern (EIP) icons onto a canvas and connect them together to form routing rules. The backend of the IDE generates Camel routing rules in Spring XML for you so you don’t ever have to learn the specifics of Camel’s DSLs. Essentially you can create a picture like Figure 3 and have Fuse IDE generate the Camel application for you.

Figure 4 shows what the Fuse IDE designer looks like when we loaded our example configuration from Listing 2.

 

Figure 4: Spring XML file in Listing 2 loaded into Fuse IDE’s designer.

From the designer view we can see the graphical representation of each of the routes we created in Spring XML beforehand. From this point we can change how the EIP icons are connected, endpoint URI properties, add additional steps to the routes, and so on. Also, as of version 1.0, Fuse IDE will support all EIPs and components available in Apache Camel – so there is no waiting for version 2.0 to use your favorite Camel features.

In this article we started first by creating the Spring XML configuration by hand. This should not mislead you however - there is no requirement to do this. In fact, since Fuse IDE supports 1-to-1 round tripping between Camel Spring XML configuration and the designer view, you can use whichever you prefer. Figure 5 shows the source view of the Spring XML file. Any changes made to the routes in the source view will be matched when you switch back to the designer view.

 

Figure 5: Source view in Fuse IDE.

When you have finished constructing your routes, you can then take advantage of another neat feature included in Fuse IDE: that is the ability to generate a JUnit test case from any Camel Spring XML file. Once you are satisfied with your testing, you can then debug in a local Spring container or deploy to your container of choice – all from within the IDE. Of course, much more is planned for Fuse IDE in the future so Camel development will only get easier.

Summary

In this article he've shown two common problems that an integration developer may face: dealing with the specifics of applications and transports, and coming up with good solutions to integration problems. The Apache Camel project provides a nice answer to both of these problems. As the example has shown, solving integration problems with Camel is straight forward and results in very concise route definitions. Building on that we saw how Fuse IDE for Camel makes Camel development even easier.

Follow these steps compulsory for fine tuning JBOSS server..

I found this great article written by F.Marchioni at his website. You can read detailed article at his website by clicking here. This is my all time favorite reference for tuning up my JBoss.

I am just providing just a gist of what he is saying regarding the JBoss Performance Tuning.

1. Tune the garbage collector
2. Set -xms and -xmx to the same value
3. Use server vm
4. Turn off distributed garbage collection
5. Turn on parallel garbage collection
6. Don’t use huge heaps, use a cluster
7. Don’t choose an heap larger then 70% of your os memory
8. Tune the heap ratio
9. Monitor the free memory with monitors and snapshots
10. Tune the operating system
11. Lots of requests ? Check jboss thread pool
12. Check the embedded web container
13.  Turn off jsp compilation in production
14. lots of ejb requests ? Switch to the poolinvoker
15. Have you got readonly entity beans ? Tell it to jboss
16. Disable the hot deployer in production
17.  Configure the ejb container to use cache, when possible.
18. Use cache invalidation in a cluster for commit option a
19. Synchronize at commit time when possible.
20. Use prepared statement cache
21. Remove services you don’t need
22. Tell log4j to shut up !

Understanding UNIX permissions and chmod

Introduction

This is a topic that has been beaten to death both in books and on-line. For some reason, it seems that it is one of the most common misunderstandings that people have to face when learning how to write and/or configure their first cgi programs. This tutorial aims to clarify the concepts involved. Note that we will be referring to UNIX in a generic sense in this article. Most of what we are going to discuss here applies to all UNIX flavours. (such as Linux, SVR4, BSD etc.) It is also a good idea to type man chmod to check for the specific details on your system, too.

Users

A UNIX system serves many users. Users are an abstraction that denotes a logical entity for assignment of ownership and operation privileges over the system. A user may correspond to a real-world person, but also a type of system operation. So, in my system, I have user 'nick' that corresponds to me, but I also have user 'www' which corresponds to the privileges necessary to operate the local webserver. UNIX doesn't care about what the user means for me. It just knows what belongs to any given user and what each user is allowed to do with any given thing (file, program, device, etc) on the system. UNIX identifies each user by a User ID (UID) and the username (or login) such as 'nick' and 'www' is just an alias to the UID that makes humans more comfortable.

Groups

Users can be organized in groups. A user may belong to one or more groups of users. The concept of groups serves the purpose of assigning sets of privileges for a given resource and sharing them among many users that need to have them. (perhaps because they are all members of a project working team and they all need access to some common project files) So, on my system user 'nick' and user 'www' both belong to the group 'perlfect'. This way, they can have some shared privileges over the files for this site. User 'nick' needs them to edit the site, and user 'www' needs them to manage the webserver that will be publishing the site.

Ownership

Every file in UNIX has an owner user and an owner group. So, for any file in the system, user 'nick' may have one of the following ownership relations: 

• nick owns the file, i.e. the file's owner is 'nick'.
• nick is a member of the group that owns the file, i.e. the file's owner group is 'perlfect'.
• nick is neither the owner, nor belonging to the group that owns the file

Permissions

Every file on the system has associated with it a set of permissions. Permissions tell UNIX what can be done with that file and by whom. There are three things you can (or can't) do with a given file:

• read it,
• write (modify) it and
• execute it.

Unix permissions specify which of the above operations can be performed for any ownership relation with respect to the file. In simpler terms, what can the owner do, what can the owner group do, and what can everybody else do with the file. For any given ownership relation, we need three bits to specify access permissions: the first to denote read (r) access, the second to denote (w) access and the third to denote execute (x) access. We have three ownership relations: 'owner', 'group' and 'all' so we need a triplet for each, resulting in nine bits. Each bit can be set or clear. (not set) We mark a set bit by it's corresponding operation letter (r, w or x) and a clear bit by a dash (-) and put them all on a row. An example might be rwxr-xr-x.What this means is that the owner can do anything with the file, but group owners and the rest of the world can only read or execute it. Usually in UNIX there is also another bit that precedes this 9-bit pattern. You do not need to know about it, at least for the time being. So if you try ls -l on the command prompt you will get something like the following:

[nick@thekla src]$ ls -l 
-rwxr-xr-x 1 nick users 382 Jan 19 11:49 bscoped.pl 
drwxr-xr-x 3 nick users 1024 Jan 19 11:19 lib/ 
-rwxr-xr-x 1 nick users 1874 Jan 19 10:23 socktest.pl

The first column here shows the permission bit pattern for each file. The third column shows the owner, and the fourth column shows the owner group. By the time, the information provided by ls -l should be enough for you to figure out what each user of the system can do with any of the files in the directory.

Directories

Another interesting thing to note is that lib/ which is a directory has permissions, too. Permissions take a different meaning for directories. Here's what they mean:

• read determines if a user can view the directory's contents, i.e. do ls in it.
• write determines if a user can create new files or delete file in the directory. (Note here that this essentially means that a user with write access toa directory can delete files in the directory even if he/she doesn't have write permissions for the file! So be careful with this.)
• execute determines if the user can cd into the directory.

chmod

To set/modify a file's permissions you need to use the chmod program. Of course, only the owner of a file may use chmod to alter a file's permissions. chmod has the following syntax: chmod [options] mode file(s) The 'mode' part specifies the new permissions for the file(s) that follow as arguments. A mode specifies which user's permissions should be changed, and afterwards which access types should be changed. Let's say for example:

chmod a-x socktest.pl

This means that the execute bit should be cleared (-) for all users. (owner, group and the rest of the world) The permissions start with a letter specifying what users should be affected by the change, this might be any of the following:

• u the owner user
• g the owner group
• o others (neither u, nor g)
• a all users

This is followed by a change instruction which consists of a +(set bit) or -(clear bit) and the letter corresponding to the bit that should be changed. Let's see some examples:

$ ls -l socktest.pl 
-rwxr-xr-x 1 nick users 1874 Jan 19 10:23 socktest.pl* 

$ chmod a-x socktest.pl 
$ ls -l socktest.pl 
-rw-r--r-- 1 nick users 1874 Jan 19 10:23 socktest.pl 

$ chmod g+w socktest.pl 
$ ls -l socktest.pl 
-rw-rw-r-- 1 nick users 1874 Jan 19 10:23 socktest.pl 

$ chmod ug+x socktest.pl 
$ ls -l socktest.pl 
-rwxrwxr-- 1 nick users 1874 Jan 19 10:23 socktest.pl* 

$ chmod ug-wx socktest.pl 
$ ls -l socktest.pl 
-r--r--r-- 1 nick users 1874 Jan 19 10:23 socktest.pl

Strange numbers...

You might have encountered things like chmod 755 somefile and of course you will be wondering what this is. The thing is, that you can change the entire permission pattern of a file in one go using one number like the one in this example. Every mode has a corresponding code number, and as we shall see there is a very simple way to figure out what number corresponds to any mode. Every one of the three digits on the mode number corresponds to one of the three permission triplets. (u, g and o) Every permission bit in a triplet corresponds to a value: 4 for r, 2 for w, 1 for x. If the permission bit you add this value to the number of the permission triplet. If it is cleared, then you add nothing. (Some of you might notice that in fact, the number for a triplet is the octal value corresponding to the three-bit pattern - if you don't know what an octal value is, it doesn't really matter, just follow the intstructions) So if a file has rwxr-xr-x permissions we do the following calculation: Triplet for u: rwx => 4 + 2 + 1 = 7
Triplet for g: r-x => 4 + 0 + 1 = 5
Tripler for o: r-x => 4 + 0 + 1 = 5
Which makes : 755 So, 755 is a terse way to say 'I don't mind if other people read or run this file, but only I should be able to modify it' and 777 means 'everyone has full access to this file'

Further reading...

• It is a good idea to take a look at the manual page for chmod (you can do this with man chmod) where you will find out more details and options on how to set permissions, plus some other kinds of permissions that we avoided to discuss here for the sake of simplicity and clarity.