How can I know what configure options were used to compile it?

You can see the configure options using the mysqlbug command-line utility.

In your shell type mysqlbug and you'll see a template e-mail for bug submission.
At the bottom end of that e-mail you can see the configure line with all the options your copy of MySQL was compiled with.

Reference: http://serverfault.com/questions/62212/configure-options-mysql-server-was-compiled-with

How To Change PostgreSQL Root Password

Here is how to change the PostgreSQL root password from the Linux command line. Replace “root” with any user name to change any password. It is important to note that PostgreSQL does not have an actual “root” user name. The “postgres” user is the super-user for PostgreSQL.

# su postgres
# psql -d template1
template1=# ALTER USER postgres WITH PASSWORD '${POSTGRESQL_POSTGRES_PASSWORD}';

You can replace “postgres” with any user name

Viewing a Name Server's Cache

You want to view a name server's cached data.

Solution
Use rndc dumpdb (BIND 9) or ndc dumpdb (BIND 8) to dump the cache to disk, then look through the dump file.

Discussion
BIND 9 name servers only dump the contents of the cache to disk by default, but BIND 8 name servers dump both the contents of cache and authoritative zone data to disk, so you'll have to find the cached records in the file.

To determine which records in a BIND 8 database dump were cached, look at the TTLs and the contents of the comment field. Authoritative zone data will have the nice, round TTLs you configured, while cached records will have had their TTLs decremented by the number of seconds they've been in the cache. Cached records will also have "Cr=" as a comment at the end of the record, giving the credibility level of the record (an indication of the quality of the cached record). For example, these records were cached from an authoritative response from the name server at 128.9.0.107:

. 518380 IN NS I.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS E.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS D.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS A.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS H.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS C.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS G.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS F.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS B.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS J.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS K.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS L.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS M.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]

Remember that dumping the cache to disk has no effect on the contents of the cache. If you want to flush (clear) the cache, see Flushing (Clearing) a Name Server's Cache.

Flushing (Clearing) a Name Server's Cache
Problem
You want to flush bad records from a name server's cache.

Solution
If you run a BIND 9.2.0 or newer name server, you can flush the cache with rndc flush. With older name servers, you need to kill the name server and restart it to flush the cache. You can do that in one fell swoop with rndc restart or rndc exec.

Discussion
Clearing the cache is really a side effect of killing the name server, since BIND name servers only store cached data in memory. Since restarting the name server takes time, especially if the name server is authoritative for many zones, rndc flush is a better option.

If you run multiple views on your BIND 9.2.0 or newer name server, you can flush the cache in only one view using rndc flush viewname. For example:

# rndc flush internal
BIND 9.3.0 will support flushing all of the records attached to a particular domain name with rndc flushname. For example:

# rndc flushname cnn.com

Modifying Zone Data Without Restarting the Name Server
Problem
You want to modify your zone data without restarting the name server.

Solution
Make the change to the zone data file. For BIND 9, run:

# rndc reload domain-name-of-zone
For BIND 8, run:

# ndc reload domain-name-of-zone
If you've modified multiple zones, just list them after reload. For example:

# rndc reload foo.example bar.example
Discussion
Remember to increment the serial number in your zone's SOA record after changing the zone data. The primary master reloads the zone regardless of whether you've incremented the serial number, since the file's modification time has changed, but your zone's slaves only have the serial number to tell them whether the zone has been updated.

Reloading individual zones, as shown above, was introduced in BIND 8.2.1 and again in 9.1.0. With older versions of BIND, just use rndc reload or ndc reload, as appropriate. That takes a little more time, since the name server checks all zone data files to see which have changed.

If you're reloading a zone that exists in multiple views on a BIND 9 name server, specify the view with rndc reload domain-name-of-zone class view. For example:

# rndc reload foo.example in external
Unfortunately, you can't leave out the class, even though you're unlikely ever to reload a non-Internet class zone.

Telling a BIND 9 name server to reload a dynamically updated zone has no effect, since the name server doesn't expect you to update the zone manually. Telling a BIND 8 name server to reload a dynamically updated zone may work--or you may lose your manual changes.

Dynamic update is, of course, another way to update zone data without restarting the name server

Where is default configuration path for spamassassin?

The default rules directory is /usr/share/spamassassin

The site rules directory is /etc/mail/spamassassin

The updated rules directory is /var/lib/spamassassin

Clarification of changes on "allow-recursion" and "allow-query-cache" in BIND 9.4.1

Everyone upgrading from older BIND versions to BIND 9.4.1 or newer should check if this change has effects on the nameserver:

There has been some confusion surrounding the changes to the "allow-recursion" and "allow-query-cache" options made with BIND 9.4.1-P1.

This document will attempt to clarify the change and the impact that it makes on BIND servers.

In BIND 9.3, there was no segregation of queries between cache and authoritative data.

The release of BIND 9.4 added fine-grained differentiation between queries against authoritative data ("allow-query") and cached data ("allow-query-cache"). This allows more precise control, particularly if you do not want your clients to use any cached data, for example, in an authoritative-only nameserver.

Prior to the release of BIND 9.4.1-P1, the default action of "allow-recursion" and "allow-query-cache" was to permit the query. The P1 patch to BIND 9.4.1 caused two changes in this behavior:

1) If not explicitly set, the ACLs for "allow-query-cache" and "allow-recursion" were set to "localnets; localhost;".

2) If either "allow-query-cache" or "allow-recursion" was set, the other would be set the same value.

Upgrading from the BIND 9.3 branch to BIND 9.4.1-P1 will significantly restrict those servers that were previously recursive servers for more than "localhost; localnets;" unless configuration changes are made.

To retain the behavior prior to BIND 9.4.1-P1, the following entries should be created in your named.conf file:

Code:

options {

...

allow-recursion { any; };

allow-query { any; };

allow-query-cache { any; };

...

};

We strongly advise against this configuration because clients spoofing queries can use your servers to launch distributed denial-of-service attacks.

The recommended method is to create ACLs that match hosts that should be allowed access to cache and recursion on the servers. For example, if you wanted to provided recursion and access to the cache to clients you trusted, you could list them in an ACL such as the following:

Code:

acl "trusted" {

192.168.0.0/16;

10.153.154.0/24;

localhost;

localnets;

};

options {

...

allow-query { any; };

allow-recursion { trusted; };

allow-query-cache { trusted; };

...

};

This example ACL includes 192.168.0.0/16 and 10.153.154.0/24 as sample networks that would require access. You must replace these sample networks with networks that correctly reflect your environment. This will allow anyone to query your server for authoritative data, but only those hosts within the "trusted" ACL access to your cache and recursion.

how to upgrade CPAN module for perl

run these command

perl -MCPAN -e 'shell'

then enter these command

# install Bundle::CPAN

# reload cpan

how to install perl module

method 1:

run command

perl -MCPAN -e 'install Module::Name'

or run

perl -MCPAN -e 'shell'

then enter these command

# install Module::Name

Module::Name is name of module which need to install

method 2:

download module source code you need to install

- extract source code archive (untar and unzip)

- change directory to source code path

- run these commands.

# perl MakeFile.PL

# make

# make test

# make install

Prereq 'v0.002.1' for 'Net::DNS::Resolver::Programmable' is not supported by Module::Build::Compat

Problem:

When I run

perl -MCPAN -e 'install Mail::SPF'

I get this

CPAN: Storable loaded ok

Going to read /root/.cpan/Metadata

Database was generated on Sat, 06 Feb 2010 07:43:02 GMT

Running install for module Mail::SPF

Running make for J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz

CPAN: Digest::MD5 loaded ok

CPAN: Compress::Zlib loaded ok

Checksum for /root/.cpan/sources/authors/id/J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz ok

Scanning cache /root/.cpan/build for sizes

Mail-SPF-v2.007

Mail-SPF-v2.007/MANIFEST

Mail-SPF-v2.007/TODO

Mail-SPF-v2.007/CHANGES

Mail-SPF-v2.007/META.yml

Mail-SPF-v2.007/MANIFEST.SKIP

Mail-SPF-v2.007/INSTALL

Mail-SPF-v2.007/README

Mail-SPF-v2.007/Makefile.PL

Mail-SPF-v2.007/LICENSE

Mail-SPF-v2.007/Build.PL

Mail-SPF-v2.007/SIGNATURE

Mail-SPF-v2.007/lib

Mail-SPF-v2.007/lib/Mail

Mail-SPF-v2.007/lib/Mail/SPF.pm

Mail-SPF-v2.007/lib/Mail/SPF

Mail-SPF-v2.007/lib/Mail/SPF/Server.pm

Mail-SPF-v2.007/lib/Mail/SPF/Util.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mod.pm

Mail-SPF-v2.007/lib/Mail/SPF/Result.pm

Mail-SPF-v2.007/lib/Mail/SPF/Request.pm

Mail-SPF-v2.007/lib/Mail/SPF/MacroString.pm

Mail-SPF-v2.007/lib/Mail/SPF/SenderIPAddrMech.pm

Mail-SPF-v2.007/lib/Mail/SPF/Exception.pm

Mail-SPF-v2.007/lib/Mail/SPF/Base.pm

Mail-SPF-v2.007/lib/Mail/SPF/Term.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech.pm

Mail-SPF-v2.007/lib/Mail/SPF/Record.pm

Mail-SPF-v2.007/lib/Mail/SPF/v1

Mail-SPF-v2.007/lib/Mail/SPF/v1/Record.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mod

Mail-SPF-v2.007/lib/Mail/SPF/Mod/Redirect.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mod/Exp.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech

Mail-SPF-v2.007/lib/Mail/SPF/Mech/PTR.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/A.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/All.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/IP6.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/MX.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/Include.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/Exists.pm

Mail-SPF-v2.007/lib/Mail/SPF/Mech/IP4.pm

Mail-SPF-v2.007/lib/Mail/SPF/v2

Mail-SPF-v2.007/lib/Mail/SPF/v2/Record.pm

Mail-SPF-v2.007/debian

Mail-SPF-v2.007/debian/libmail-spf-perl.install

Mail-SPF-v2.007/debian/spf-tools-perl.postinst

Mail-SPF-v2.007/debian/rules

Mail-SPF-v2.007/debian/compat

Mail-SPF-v2.007/debian/changelog

Mail-SPF-v2.007/debian/watch

Mail-SPF-v2.007/debian/spf-tools-perl.prerm

Mail-SPF-v2.007/debian/copyright

Mail-SPF-v2.007/debian/spf-tools-perl.install

Mail-SPF-v2.007/debian/control

Mail-SPF-v2.007/bin

Mail-SPF-v2.007/bin/spfquery

Mail-SPF-v2.007/t

Mail-SPF-v2.007/t/Mail-SPF-Test-lib.pm

Mail-SPF-v2.007/t/90-author-pod-validation.t

Mail-SPF-v2.007/t/00.01-class-util.t

Mail-SPF-v2.007/t/10.00-rfc4408.t

Mail-SPF-v2.007/t/rfc4408-tests.yml

Mail-SPF-v2.007/t/10.01-rfc4406.t

Mail-SPF-v2.007/t/00.04-class-server.t

Mail-SPF-v2.007/t/00.05-class-macrostring.t

Mail-SPF-v2.007/t/00.00-class-misc.t

Mail-SPF-v2.007/t/00.02-class-request.t

Mail-SPF-v2.007/t/rfc4406-tests.yml

Mail-SPF-v2.007/t/00.99-class-misc.t

Mail-SPF-v2.007/t/00.03-class-result.t

Mail-SPF-v2.007/sbin

Mail-SPF-v2.007/sbin/spfd

Removing previously used /root/.cpan/build/Mail-SPF-v2.007

CPAN.pm: Going to build J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz

# running Build.PL

Creating new 'MYMETA.yml' with configuration results

Creating new 'Build' script for 'Mail-SPF' version 'v2.7.0'

Prereq 'v0.002.1' for 'Net::DNS::Resolver::Programmable' is not supported by Module::Build::Compat

Running make test

Make had some problems, maybe interrupted? Won't test

Running make install

Make had some problems, maybe interrupted? Won't install

Resolution:

run this command

perl -MCPAN -e 'install Bundle::CPAN'

with successfully installed

TCP/IP Stack Hardening

If you run a UNIX-like operating system, you can make it more secure by slightly modifying the behavior of its TCP/IP implementation.

This page lists modifications for the various TCP/IP protocols. For the most part, these are commands that would go into a boot script such as /etc/rc.sysinit or /etc/rc.local.

The tables only list the possible commands — some tuning steps are not possible (at least as far as I know) on certain UNIX implementations.

If there is a dangerous type of packet that might be allowed under a strict interpretation of the protocols, but which is currently considered to be risky, the listed commands frequently list how to both ignore inbound packets and refuse to send outbound packets. This prevents your host from being victimized and prevents it from being used to launch attacks.

This page only describes how to harden the TCP/IP stack on UNIX-like operating systems. It is based on the recommendations found in the following pages, plus my commentary and explanation:

ARP

Decrease the ARP cache cleanup interval.

AIX	no -o arpt_killc=20
FreeBSD	sysctl -w net.link.ether.inet.max_age=1200
Solaris	ndd -set /dev/arp arp_cleanup_interval 60000

Consider static ARP (but also consider the maintenance problems!). This does not scale well to routine use on LANs, but it might be worth its trouble on a small sensitive LAN — a DMZ LAN in your network perimeter, or a small LAN populated by a few sensitive servers and a router port.Remember that if you change the Ethernet card in one machine, you must then modify and re-run the static ARP script boot script on every host on that LAN!

If you want to do this, you will need a script like the following, with IP and MAC addresses changed as needed. For thorough paranoia, define a MAC address for all possible IP addresses on the LAN, even ones not in use. For the unused IP addresses, use a MAC address that you know will not exist on that LAN (maybe that of an Ethernet card on another LAN).

arp -s 10.1.1.1 00:02:E3:05:9F:A3 arp -s 10.1.1.2 00:08:C7:29:E7:31 arp -s 10.1.1.3 00:60:97:B9:3B:B5 ... and so on ...

ICMP

Disable ICMP broadcast echo activity. Otherwise, your system could be used as part of a Smurf attack:

AIX	no -o directed_broadcast=0
FreeBSD	sysctl -w net.inet.icmp.bmcastecho=0
HP-UX	ndd -set /dev/ip ip_respond_to_echo_broadcast 0 ndd -set /dev/ip ip_forward_directed_broadcasts 0
IRIX	systune allow_brdaddr_srcaddr 0
Linux	sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
OpenBSD	Already ignores these by default
Solaris	ndd -set /dev/ip ip_respond_to_echo_broadcast 0 ndd -set /dev/ip ip6_respond_to_echo_multicast 0 ndd -set /dev/ip ip_forward_directed_broadcasts 0

Disable ICMP routing redirects. Otherwise, your system could have its routing table misadjusted by an attacker.

AIX	no -o ipignoreredirects=1 no -o ipsendredirects=0
FreeBSD	sysctl -w net.inet.ip.redirect=0 sysctl -w net.inet.ip6.redirect=0
HP-UX	ndd -set /dev/ip ip_send_redirects 0 ndd -set /dev/ip ip_forward_directed_broadcasts 0
IRIX	systune icmp_dropredirects 1
Linux	sysctl -w net.ipv4.conf.all.accept_redirects=0 sysctl -w net.ipv6.conf.all.accept_redirects=0 sysctl -w net.ipv4.conf.all.send_redirects=0 sysctl -w net.ipv6.conf.all.send_redirects=0
OpenBSD	sysctl -w net.inet.icmp.rediraccept=0 sysctl -w net.inet6.icmp6.rediraccept=0 Those two disable the acceptance of ICMP Redirect. To disable sending ICMP Redirect messages: sysctl -w net.inet.ip.redirect=0 sysctl -w net.inet6.ip6.redirect=0
Solaris	ndd -set /dev/ip ip_ignore_redirect 1 ndd -set /dev/ip ip6_ignore_redirect 1 ndd -set /dev/ip ip_send_redirects 0 ndd -set /dev/ip ip6_send_redirects 0

Disable ICMP router solicitations and advertisements, and ICMP subnet mask requests and replies. An attacker might be able to use unsolicited advertisements and replies to misadjust host routing tables. An attack also might be able to use solicitations and requests to reverse engineer some details of your network infrastructure. It appears that you will have to do this with packet-filtering rules on the host.

Disable ICMP broadcast probes. Otherwise, an attacker might be able to reverse engineer some details of your network infrastructure.

AIX	no -o icmpaddressmask=0
FreeBSD	sysctl -w net.inet.icmp.maskrepl=0
HP-UX	ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0 ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
IRIX	You will have to block these with a packet filter like ipfilterd
Linux	You will have to block these with a packet filter like iptables
OpenBSD	Already ignores these by default
Solaris	ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0 ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0

IP

Disable IP source routing. The only use of IP source routing these days is by attackers trying to spoof IP addresses that you would trust as internal hosts.

AIX	no -o ipsrcroutesend=0 no -o ipsrcrouteforward=0
FreeBSD	sysctl -w net.inet.ip.sourceroute=0 sysctl -w net.inet.ip.accept_sourceroute=0
HP-UX	ndd -set /dev/ip ip_src_route_forward 0
IRIX	systune ipforward 2
Linux	sysctl -w net.ipv4.conf.all.accept_source_route=0 sysctl -w net.ipv4.conf.all.forwarding=0 sysctl -w net.ipv4.conf.all.mc_forwarding=0
OpenBSD	Already ignores these by default
Solaris	ndd -set /dev/ip ip_forward_src_routed 0 ndd -set /dev/ip ip6_forward_src_routed 0

Enforce sanity checking, also called ingress filtering or egress filtering. The point is to drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived.

Linux

sysctl -w net.ipv4.conf.all.rp_filter=1

Log and drop "Martian" packets. A "Martian" packet is one for which the host does not have a route back to the source IP address (it apparently dropped in from Mars). These days most hosts have a default route, meaning that there would be no such thing as a Martian packet, but to be safe and complete...

Linux

sysctl -w net.ipv4.conf.all.log_martians=1

Enforce strict multi-homing for non-forwarding multi-homed systems. If a host is connected to more than one LAN, but it should not act as an IP router, make certain that it does not forward IP datagrams between networks. Maybe it is a firewall, or maybe it is just a multi-homed host.

Solaris

ndd -set /dev/ip ip_strict_dst_multihoming 1 ndd -set /dev/ip ip6_strict_dst_multihoming 1

TCP

Increase resiliance under heavy TCP load (which makes the system more resistant to SYN Flood attacks). There are five major steps to making a system more resiliant under heavy, possibly malicious, TCP load:

• Buy more RAM. Each inbound SYN packet is intended to establish a TCP circuit, which requires resources on the server. The TCP buffers require memory to be allocated.
• Use TCP SYN Cookies (Linux and BSD only). With TCP Syn Cookies, the kernel does not really allocate the TCP buffers unless the server's ACK/SYN packet gets an ACK back, meaning that it was a legitimate request.
• Reduce the allowed number of HALF_OPEN TCP circuits. Further requests are refused, a denial of service, but at least the server hasn't run out of memory.
• Reduce the amount of time an opening TCP circuit can stay in the HALF_OPEN state. The server is made less patient — if the TCP circuit is not fully established quickly, it is dropped and the client, if legitimate but very slow, must start again.
• Reduce the amount of time a closing TCP circuit can stay in the TIME_WAIT state. Some clients are very rude, apparently Microsoft Explorer is particularly bad. They establish a connection, get their data, but then refuse to participate in cleanly shutting down the TCP circuit. At least for busy web servers, make them very impatient with such nonsense, dropping these no longer active connections and freeing resources.

The following show the vendor recommendations for tuning the TCP queue length and circuit establishment timers, and how to reduce TCP TIME_WAIT to 60 seconds.

AIX	no -o clean_partial_conns=1
FreeBSD	sysctl -w kern.ipc.somaxconn=1024
HP-UX	ndd -set /dev/tcp tcp_syn_rcvd_max 1024 ndd -set /dev/tcp tcp_conn_request_max 200 ndd -set /dev/tcp tcp_time_wait_interval 60000
IRIX	systune tcp_2msl 60 The kernel automatically limits the queue of pending connections.
Linux	sysctl -w net.ipv4.tcp_max_syn_backlog=1280 sysctl -w net.ipv4.tcp_syncookies=1 Already drops inactive TCP connections within 60 seconds
OpenBSD	Already has a resilient TCP implementation by default
Solaris	ndd -set /dev/tcp tcp_conn_req_max_q 1024 ndd -set /dev/tcp tcp_conn_req_max_q0 4096 ndd -set /dev/tcp tcp_time_wait_interval 60000

Defend against TCP connection hijacking by following the recommendations of RFC 1948. Most UNIX implementations use RFC 1948 recommendations to generate initial sequence numbers, but Solaris (at least up through Solaris 8) needs a little help.

Solaris

ndd -set /dev/tcp tcp_strong_iss 2 To configure this behavior to be the default after future reboots, put the line TCP_STRONG_ISS=2 in the file /etc/default/inetinit

Increase TCP send and receive window sizes to at least 32 kbytes. But do not increase these above 64 kbytes unless you fully understand and support both RFC 1323 andRFC 2018.

AIX	no -o tcp_sendspace=32768 no -o tcp_recvspace=32768
FreeBSD	sysctl -w net.inet.tcp.sendspace=32768 sysctl -w net.inet.tcp.recvspace=32768
HP-UX	The TCP send and receive spaces are 32 kbytes by default.
IRIX	The TCP send and receive spaces are 64 kbytes by default.
Linux	The kernel supports RFC 1323 and RFC 2018 and dynamically adjusts the TCP send and receive space by default
OpenBSD	The kernel supports RFC 1323 and RFC 2018 and dynamically adjusts the TCP send and receive space by default
Solaris	ndd -set /dev/tcp tcp_xmit_hwat 32768 ndd -set /dev/tcp tcp_recv_hwat 32768

Reference:

http://www.cromwell-intl.com/security/security-stack-hardening.html

How do I get rid of old 10.x patches or superseded patches?

DO NOT USE SWREMOVE!  swremove will check the scripts for
the patch you ask it to remove, and happily remove whatever
file you tell it to, and replace it with an earlier version
of the patch from /var/adm/sw/patch/ (if one exists).

NOTE:  If you have already removed previous OS version
patches with swremove, you will either
1) need to restore from backup, or 2) reload the OS.

First download and install one of the following patches,
which contain the HP-UX patch tools:

o 10.x:  PHCO_20824  ('cleanup' only)
o 11.00: PHCO_27779  ('cleanup', 'check_patches', &
                   'show_patches')
o 11.11: PHCO_27780  ('cleanup', 'check_patches', &
                   'show_patches')

The patch tools come with 11.00, but you should still install
patch PHCO_24347 to fix several bugs that exist in it.

The 'cleanup' tool is used to commit patches while preserving
a set level of rollback, remove HP-UX 10.x patch information
from the IPD, and prune superseded patches from a depot.
The 'check_patches' utility checks for partially installed
(split) patches, incorrect patch_state, patch attribute
corruption, and objects within an archive library.  The
'show_patches' tool can display the set of active or
superseded patches on a system.

To remove old 10.x patches from /var/adm/sw/patch/, use the
command:

# cleanup -i

Committing a patch causes rollback files associated with
that patch to be deleted from /var/adm/sw/save/.

To commit all patches that have been superseded at least
twice, use the command:

# cleanup -c 2

On 11.x, to commit a patch that has not been superseded,
use the command:

# swmodify -x patch_commit=true 

In case you were wondering, 'cleanup -c 0' does not work.

WARNING: Once the above swmodify command has been executed,
        you CANNOT roll back (remove) the patch unless you
        remove the associated base software that the patch
        modified.  For this reason, I do not recommend
        doing it unless you desperately need to free up
        space under /var, and you have exhausted all
        other means of doing so.

Reference:
http://www.faqs.org/faqs/hp/hpux-faq/section-158.html

How do I configure swlist to not display superseded patches?

A new option to swlist, "show_superseded_patches", was
introduced in HP-UX 11.00 via the SD-UX cumulative patch
PHCO_20078.  In 11.00, by default, swlist displays all
installed patches, including superseded ones.  In 11.10+,
by default, swlist does not display superseded patches.

Assuming you have PHCO_20078, or any more recent SD-UX
cumulative patch installed, you may change the default
behavior of swlist in 11.00. To do so, add the following
line to the file /var/adm/sw/defaults:

swlist.show_superseded_patches = false

Reference:
http://www.faqs.org/faqs/hp/hpux-faq/section-160.html

How can I install multiple HP-UX patches, without having to reboot more than once?

Use swcopy(1M) on each patch to copy the patch into a local
depot, then use swinstall(1M) to install all patches
contained in the local depot.

# swcopy -s /tmp/PHCO_12345.depot \
 -x enforce_dependencies=false \* \
 @ /tmp/my_patch_depot
# swcopy -s /tmp/PHCO_67890.depot \
 -x enforce_dependencies=false \* \
 @ /tmp/my_patch_depot

etc..

# swinstall -s /tmp/my_patch_depot -x autoreboot=true \*

The following script automates the process of creating the
depot:

#!/sbin/sh
# cd to the directory where the patches are (PHxx_xxxx)
# and start this script. it will extract the patches one
# by one and create a patch-depot in $PDEPOT.

PATH=/usr/bin:/usr/sbin
PDEPOT=/tmp/my_patch_depot
for PFILE in PH*[0-9]; do
sh $PFILE
rm $PFILE
done
# It's a good habit first reading the PHxx_xxxx.text
# files before deleting them.
# rm *.text
for PFILE in PH*depot; do
swcopy -s -x enforce_dependencies=false $PWD/$PFILE \* \
@ $PDEPOT
done
clear
echo \
"*******************************************************"
echo \
"PLEASE NOTE: The Patch depot $PDEPOT has been created."
echo \
"*******************************************************"
echo \
"Please start swinstall with $PDEPOT as the source, and"
echo \
"don't forget to unregister the depot"
echo \
"(e.g. swreg -u -l depot $PDEPOT)."


Reference:
http://www.faqs.org/faqs/hp/hpux-faq/section-159.html