Drills for operations folks

Read this excellent article on focused practice. I've urged customers for many years to stage drills in operational readiness environments in order to test responsiveness to operational events and judge effectiveness of that response outside of production comfort zones.

Technorati Tags: operations, drills, software, tools

Posted at 02:50PM Jun 24, 2008 by tgardner in Internet  | 

Summer Solstice Google Art

Technorati Tags: google

Posted at 12:32PM Jun 20, 2008 by tgardner in Internet  | 

libxslt-1.1.23.tar.gz checksum errors

libxslt-1.1.23.tar.gz has a bad checksum (xmlsoft.org).

Technorati Tags: libxslt, opensource, xslt

Posted at 10:34AM Jun 17, 2008 by tgardner in Internet  |  Comments[1]

Solaris TCP/IP parameters: tcp_conn_req_max_q and tcp_conn_req_max_q0

“Trying 192.168.23.30... telnet: Unable to connect to remote host: Connection refused”

This blog entry will attempt to explain the parameters tcp_conn_req_max_q and tcp_conn_req_max_q0 and address the proper way to determine values for these parameters.

tcp_conn_req_max_q and tcp_conn_req_max_q0 are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.

The default value for tcp_conn_req_max_q on Solaris 8 and Solaris 9 is 128, the default value for tcp_conn_req_max_q0 on Solaris 8 and Solaris 9 is 4096. These defaults may be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. There is only one way to determine appropriate values, though. Read on!

It is pretty simple really: never change these parameters unless connections are refused because the values are too low. The only way to determine this empirically is to use ‘netstat –s | fgrep –i listendrop’. If tcpListenDrop is non-zero, increase tcp_conn_req_max_q. If tcpListenDropQ0 is non-zero, increase tcp_conn_req_max_q0.

Hang on a moment: maybe it is not quite that simple. Increasing tcp_conn_req_max_q to a value that is too high can result in a system that is vulnerable to SYN segment denial of service attacks. Solaris IP is brilliantly executed in this respect due to the separation of these parameters. Increase tcp_conn_req_max_q in increments of 256. Use tcp_conn_req_max_q0 to increase the number of “half-open” TCP connections that are available. If a software cannot service connections quick enough, increasing tcp_conn_req_max_q0 can prevent clients from not being able to connect at all. Connections from clients remain in the “half-open” state until the server software can process them.

The defaults on Solaris 8 and Solaris 9 are too low for a system that processes more than 128 incoming TCP connections or 4096 “half-open” TCP connection at a time. Change these parameters with great care. Do not change them unless tcpListenDrop or tcpListenDropQ0 are non-zero, or you expect the number of connections to change.

Technorati Tags: solaris, tcp_conn_req_max_q

Posted at 11:28AM Jun 12, 2008 by tgardner in Internet  |