Louwrentius

Sometimes, people are using software that does not support encrypted connections using SSL. To provide SSL-support to such a client, ncat can be used. Ncat is part of nmap, the famous port-scanner.

The main principle is that the non-ssl capable software does not connect to the SSL-based service, but to the local host. Ncat will be listening on the localhost and will setup an SSL-connection with the SSL-based service on behalf of the non-ssl capable software.

This simple command allows an application to browse to port 80, and perform regular HTTP-request, while in fact, they are encapsulated within a SSL- connection:

ncat -l 80 -c "ncat (ip-address) (port) --ssl"

The -l option specifies the local port on which the SSL-tunnel will be listening. The ip-address and port refer to the SSL-based service.

So if the client connects to 127.0.0.1 on port 80 it will actually connect through the SSL-tunnel to the external service.

Often stunnel is used for this job but this software craps out on debian Etch with some error like:

SSL routines:SSL3_GET_RECORD:bad decompression

But ncat is an excellent alternative.

A: There is no single tool for this job, but it seems that Fdisk is just fine:

server:~# fdisk -l 2> /dev/null | grep Disk | grep -v identifier

Disk /dev/sda: 500.0 GB, 500028145664 bytes

Disk /dev/sdb: 500.0 GB, 500028145664 bytes

Disk /dev/sdc: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdd: 500.0 GB, 500028145664 bytes

Disk /dev/sde: 500.0 GB, 500028145664 bytes

Disk /dev/hda: 80.0 GB, 80026361856 bytes

Disk /dev/md5: 1500.0 GB, 1500084240384 bytes

The nice thing about using fdisk is that it automatically lists the size of all block devices.

Here is a list of my NAS, mentioned earlier.

Beast:~# fdisk -l 2> /dev/null | grep Disk | grep -v identifier

Disk /dev/sda: 60.0 GB, 60011642880 bytes

Disk /dev/sdb: 60.0 GB, 60011642880 bytes

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes

Disk /dev/md0: 57.9 GB, 57996345344 bytes

Disk /dev/md1: 2015 MB, 2015100928 bytes

Disk /dev/sdg: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdh: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdi: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdj: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdk: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdl: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdm: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdn: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdo: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdp: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdq: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdr: 1000.1 GB, 1000123400192 bytes

Disk /dev/sds: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdt: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdu: 1000.1 GB, 1000123400192 bytes

Disk /dev/sdv: 1000.1 GB, 1000123400192 bytes

Disk /dev/md5: 18002.2 GB, 18002220023808 bytes

I have experienced problems using a HighPoint RocketRaid 2320 and 2340 when they are using 'staggered spinup' in combination with Samsung Spinpoint F1, 1 (one) terrabyte disks.

The problem is that the F1 disks spinup very slowly and often seem to 'hang' while making ticking noises that will scare any computer user to death. When, after ages, you have the luck that no disks keeps hanging during startup, the first thing to do is to disable staggered spinup.

However, if staggered spinup is not used and all disks will spinup together, please note that you will need a strong PSU to handle the short peak load. For example, starting up 20 (twenty) disks will briefly generate a load of 550 Watt on my APC ups, according to its display.

I estimate that during startup, each disk is roughly consuming 20 Watt. Take this all into account when deciding which type of disks and controllers you will be using.