Archive for the tag 'Using'

fuser - identify processes using files or sockets

In order to look up processes using TCP and UDP sockets, the corresponding name space has to be selected with the -n option. By default fuser will look in both IPv6 and IPv4 sock-ets. To change the default, behavior, use the -4 and -6 options. The socket(s) can be specified by the local and remote port, and the remote address. All fields are optional, but commas in front of missing fields must be present:

[lcl_port][,[rmt_host][,[rmt_port]]]

Either symbolic or numeric values can be used for IP addresses and port numbers.

fuser outputs only the PIDs to stdout, everything else is sent to stderr.

root@dell:~# fuser -nv tcp 25
USER PID ACCESS COMMAND
25/tcp: root 3926 F…. master

FILES

/proc location of the proc file system

EXAMPLES

fuser -km /home kills all processes accessing the file system /home in any way.

if fuser -s /dev/ttyS1; then :; else something; fi invokes something if no other process
is using /dev/ttyS1.

fuser telnet/tcp shows all processes at the (local) TELNET port.

How to track which site is using the apache processes.

For apache 1.3, edit your /etc/httpd/conf/httpd.conf and add

ExtendedStatus On
<Location /httpd-status>
SetHandler server-status
</Location>

just after the code that says “ServerSignature On”. Save, exit, then restart apache. You can access the stats page by going to http://192.168.1.1/httpd-status where 192.168.1.1 is your server’s IP.

If you’re running apache 2.x with custombuild, then it’s already in the file:

/etc/httpd/conf/extra/httpd-info.conf

Change the “Allow from” lines to include your IP, or remove the line completely to allow from all.

Source : http://directadmin.com/

SBDavid

Using perl to make custom changes

Using perl to make custom changes to files

The below example shows how to make changes to the virtual host conf files. Here we are changing CustomeLog to #CustomLog.

perl -pi -e ’s/CustomLog/#CustomLog/’ virtual_host*.conf
SBDavid

Using NFS over TCP

Using NFS over TCP

To mount a shared directory using NFS over TCP, use the “proto=tcp” mount option:

# mount -o proto=tcp :/pub /usr/local/pub

Make sure the target directory, in this example /usr/local/pub, exists on the client.

You can verify the NFS over TCP mount using the mount command:

If you need NFS, it is recommended to use NFS over TCP since NFS over UDP is not very secure. All 2.4 and 2.6 kernels support NFS over TCP on the client side. Server support for TCP appears in later 2.4 kernels, and in all 2.6 kernels.

To verify whether your server supports NFS over TCP, use the wire-test command (/usr/sbin/wire-test is part of the am-utils package). If your server supports NFS over TCP, the output looks like this:

# wire-test localhost
NFS Version and protocol tests to host “localhost”…
testing vers=2, proto=”udp” -> found version 2.
testing vers=3, proto=”udp” -> found version 3.
testing vers=2, proto=”tcp” -> found version 2.
testing vers=3, proto=”tcp” -> found version 3.
#

Controlling Server Resources from denial of service using Xinetd

Another important feature of xinetd is its ability to control the amount of resources which services under its control can utilize.

It does this by way of the following directives:

cps = [number_of_connections] [wait_period] — Dictates the connections allowed to the service per second. This directive accepts only integer values.

instances = [number_of_connections] — Dictates the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.

per_source = [number_of_connections] — Dictates the connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.

rlimit_as = [number[K|M]] — Dictates the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.

rlimit_cpu = [number_of_seconds] — Dictates the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.

Using these directives can help prevent any one xinetd service from overwhelming the system, resulting in a denial of service.

« Prev - Next »