Linux Tomorrow

Author : Vincent Danen, ZDNet Asia

Scrub your data using the shred command for files that contain sensitive information, so that they cannot be recovered later with data retrieval tools.

There are two utilities on a typical Linux box that can be used to delete files. Most users are familiar with the rm command. Most of the time, this command is sufficient for routine deletion, but for files that contain sensitive data, you might need to scrub them so that they cannot be recovered later with other data retrieval tools.

To delete files with sensitive content, rm is not sufficient. Instead, consider using the shred command, which not only deletes a file, but deletes it in such a way that it cannot be recovered. Shred overwrites the file multiple times with garbage prior to deleting it, ensuring that if anything does get retrieved, it isn't your top-secret data.

For instance:

$ echo "this is private data" >private.txt

$ cat private.txt

this is private data

$ ls -l private.txt

-rw-r--r-- 1 vdanen vdanen 21 Mar  4 09:36 private.txt

To illustrate how shred works, call it without any command-line options so that the garbage in the file can be viewed:

$ shred private.txt

$ cat private.txt

?9?-?w?K?=???l;b8SƉ?b???????@,?18!??DM??P?

...

$ ls -l private.txt

-rw-r--r-- 1 vdanen vdanen 4096 Mar  4 09:36
private.txt

The rest of the output is removed as it is binary gibberish. You can also see the file size has changed.

To delete the file after overwriting it with garbage, use the -u option. To see what shred is actually doing, give it the verbose -v option:

$ shred -u -v private.txt

shred: private.txt: pass 1/25 (random)...

shred: private.txt: pass 2/25 (cccccc)...

shred: private.txt: pass 3/25 (111111)...

shred: private.txt: pass 4/25 (000000)...

shred: private.txt: pass 5/25 (999999)...

shred: private.txt: pass 6/25 (aaaaaa)...

shred: private.txt: pass 7/25 (924924)...

shred: private.txt: pass 8/25 (b6db6d)...

shred: private.txt: pass 9/25 (6db6db)...

shred: private.txt: pass 10/25 (888888)...

shred: private.txt: pass 11/25 (492492)...

shred: private.txt: pass 12/25 (db6db6)...

shred: private.txt: pass 13/25 (random)...

shred: private.txt: pass 14/25 (ffffff)...

shred: private.txt: pass 15/25 (bbbbbb)...

shred: private.txt: pass 16/25 (777777)...

shred: private.txt: pass 18/25 (dddddd)...

shred: private.txt: pass 19/25 (333333)...

shred: private.txt: pass 20/25 (555555)...

shred: private.txt: pass 21/25 (222222)...

shred: private.txt: pass 22/25 (eeeeee)...

shred: private.txt: pass 23/25 (666666)...

shred: private.txt: pass 24/25 (249249)...

shred: private.txt: pass 25/25 (random)...

shred: private.txt: removing

shred: private.txt: renamed to 00000000000

shred: 00000000000: renamed to 0000000000

shred: 0000000000: renamed to 000000000

shred: 000000000: renamed to 00000000

shred: 00000000: renamed to 0000000

shred: 0000000: renamed to 000000

shred: 000000: renamed to 00000

shred: 00000: renamed to 0000

shred: 0000: renamed to 000

shred: 000: renamed to 00

shred: 00: renamed to 0

shred: private.txt: removed

As you can see, shred overwrites the file 25 times with garbage. After this, it renames the file 11 times before deleting it.

Shred can also be used to overwrite entire disks instead of just files. If you wished to overwrite the contents of an entire hard drive, a process which would definitely take a fair amount of time, use:

# shred -u -n 30 /dev/hda

This will overwrite the data on the drive with garbage using 30 passes. The drive will need to be re-formatted after this as even the filesystem structure will be destroyed.

Author : kian

Network UPS Tools is a collection of programs which provide a common interface for monitoring and administering UPS hardware.

The primary goal of the Network UPS Tools (NUT) project is to provide reliable monitoring of UPS hardware and ensure safe shutdowns of the systems which are connected.

This is a developing project to monitor a large assortment of UPS hardware. Many models have ports on the back to allow other devices to check the status. If it gives basic information about the power and battery status, it can probably be supported without too much difficulty. More advanced features on the higher-end models are also supported to allow tracking of values over time such as temperature and voltage.

Network communications are used so that multiple systems can monitor a single physical UPS and shut down together if necessary without any special "sharing hardware" on the UPS itself.

Pre-installation

Before you have everything up and running on the server, plug the UPS to a power outlet and connect the signal cable (serial or USB) to the server that will run upsd. Do not connect any server power cables to the outlet on the UPS until you feel that you are confident with the working of NUT and how it behaves with your hardware. It is often advised that you use a dummy load such as a lamp when testing the UPS. This will also show you when the UPS delivers power and when it is off, giving you the opportunity to experiment safely and gain confidence with the commands in a way you can't do once you hook up a production server to the UPS.

Installation

Install the nut RPM package. If you use YaST2, required packages will automatically be added. From the command line, you can use

yast2 -i nut

as root.

In OpenSuSE 10.3, you will get nut 2.2.0 installed.

This will place all the necessary binaries in your path and a set of skeleton configuration files. You will have to edit the files as root in order to define your UPS hardware

Configuration

Configuration of a locally connected UPS

Either open a root shell, or use e.g.

sudo vi

to edit the configuration files.

In the file /etc/ups/ups.conf you have a dummy section with default values that looks like this:

[myups]
     driver = undefined
     port = /dev/undefined
     desc = "Local UPS"

Edit the file and set the driver to point to the correct driver for your UPS, the port to where you connected the signal cable and add a description. See /usr/share/nut/driver.list for a list of supported brands and models.

Here is my entry for an APC SmartUPS 1400 connected to the serial port.

[apc_smartups_1400]
     driver = apcsmart
     port = /dev/ttyS0
     desc = "APC SmartUPS 1400"

You have to modify the /etc/ups/upsd.users file to configure users and permissions. The passwords are automatically generated during installation, so you can leave them set to these random values if you like. If you want to use a password that you can remember, edit the file. There are two entries in the default file, I also added an admin user so I can calibrate and test the UPS from the command line.

Note that these users can only connect from localhost, so for now security is not a big issue here. With remote slaves, you should use a more advanced password than what I have in these examples.

Here are the three users defined in the /etc/ups/upsd.users file.

[upsmaster]
      password = masterpass123
      allowfrom = localhost
      upsmon master
[upsslave]
      password = slavepass123
      allowfrom = localhost
      upsmon slave
[upsadmin]
      password = upspass
      allowfrom = localhost
      actions = SET
      instcmds = ALL

The upsd daemon only polls the UPS, you need other programs to check upsd for status. Edit their config files to reflect the new name of the UPS and the login and password.

/etc/ups/upsmon.conf

# MONITOR myups@localhost 1 upsmaster 67fc9377aa master
MONITOR apc_smartups_1400@localhost 1 upsmaster masterpass123 master

I also prefer to get a "wall" notice when power is restored in case I work remotely and there is a short power failure. Change the line:

NOTIFYFLAG ONLINE   SYSLOG

to

NOTIFYFLAG ONLINE   SYSLOG+WALL

in the /etc/ups/upsmon.conf file.

/etc/ups/hosts.conf is only for the included CGI programs, but you can add the correct information here as well

/etc/ups/hosts.conf

# MONITOR myups@localhost "Local UPS"
MONITOR apc_smartups_1400@localhost "APC SmartUPS 1400"

Now we can finally start all of these programs:

rcupsd start

linux:~ # rcupsd start
Starting NUT UPS drivers done
Starting NUT UPS server done
Starting NUT UPS monitor done

Check that you are up and running and that you can read the stored values from the UPS. First list available devices with

upsc -l

... then read all values with:

upsc

linux:~ # upsc -l
apc_smartups_1400
linux:~ # upsc apc_smartups_1400
battery.alarm.threshold: 0
battery.charge: 100.0
battery.charge.restart: 00
[...]

Testing

Before you connect your server to the power, test a realistic power failure unplugging the power cord to the UPS unit. It should fail over to battery and you get a warning message. If you are logged in and running KDE you get a popup from KWrited with a message such as:

Broadcast Message from upsd@linux
(somewhere) at 22:51
UPS apc_smartups_1400@localhost on battery

Plug the cable back in and observe the reassuring messages that power has been restored.

Broadcast Message from upsd@linux
(somewhere) at 22:51
UPS apc_smartups_1400@localhost on line power

If this works, you can shut your server down and connect the power cord to the UPS. In case of a power failure, you will get the messages you saw during testing. Once the battery charge is so low that the UPS sends a "low battery" signal, NUT will shut down the server. You may be able to set this threshold in the UPS registers, or you will have to script something that does a

shutdown -h -t

(system halt after ) as soon as the UPS is on battery, and then does a

shutdown -c

(cancel shutdown) when the UPS is back on line power. Not all UPS devices will send this "restored" message, though. This is where you just have to test and customize.

Running your equipment on UPS

So your server is now running on battery power until the batteries run out. You may want to once actually run the server until the batteries fail, just to have an idea of how much battery time you have. Most UPS devices can show you the load and a battery charge percentage. UPSes are great when you are working on something really important and there is a short power surge or brownout, and in case of a long lasting blackout you can get the machine to suspend, hibernate or shut down when batteries are low.

If you set your BIOS to start the machine automatically when it starts to received power, it will automatically boot when power is restored. In case of recurrent power failures, you don't want to keep a server running and drain the batteries. Just think of a UPS as a unit that protects you from power surges and spikes, and can provide you with a clean shutdown in case of power failure. Don't run a server on battery just because you can. Batteries in a UPS are not meant to be drained, and when power is restored they normally take a few hours to restore full charge. You don't want to run the servers without a safety net right after a blackout - shut servers down with plenty of battery power left and save it for the rough time period just after power restore when every appliance in the entire city starts up simultaneously and starts to guzzle power. For the same reason, limit what you keep on UPS to important servers. Don't forget to add necessary supporting hardware such as network equipment, KVMs and monitors needed to operate the servers during power failure. Avoid running printers and most workstations on UPS power. Keep emergency light in the server room so you can work there when the normal lights are out. If you keep servers running for a while with your own power source (such as a generator), you may even want to keep HVAC on the same power to avoid overheating the room.

Also remember that when all equipment starts to draw poewr at once - servers and workstations all simultaneously boot, all monitors and lights light up and laser printers start to warm up - you must expect to blow a fuse or two. Which then prolongs your blackout. Make sure all non-critical equipment is shut off during power failures and manually switched on again afterwards.

Remote clients

Allowing remote clients

Now that you know the local UPS is working as it should - keeping the server running on power and notifying the OS via serial port or USB - you may want to connect more servers to the rest of the power outlets. However, there is only one USB or serial cable. This is when you need the NUT upsd daemon on the machine with the serial cable to notify the other servers via the network.

Start by editing the /etc/ups/upsd.conf to allow clients. Here the entire subnet is allowed, you may want to make it more fine-grained and only include specific IPs.

ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32
ACL upsnet  192.168.1.0/24
ACCEPT localhost
ACCEPT upsnet
REJECT all

Now allow the slave to connect from this network in /etc/ups/upsd.users:

[upsslave]
      password = slavepass123
      allowfrom = localhost upsnet
      upsmon slave

Restart the upsd daemond again to pick up the changes.

rcupsd restart

linux:~ # rcupsd restart
Shutting down NUT UPS monitor done
Shutting down NUT UPS server done
Shutting down NUT UPS drivers. done
Starting NUT UPS drivers done
Starting NUT UPS server done
Starting NUT UPS monitor done

Or better, reload the configuration, this is much faster than restarting the daemons when you only need to reconfigure any setting except for the driver settings which demands a service restart as above.

rcupsd reload

linux:~ # rcupsd reload
Reload service NUT UPS (excluding upsdrvctl) done

And allow the clients through the firewall (OpenSuSE by default runs an iptables firewall called SuSEfirewall). upsd listens on TCP port 3493, and by default listens on all interfaces.

Create a SuSEfirewall2 service definition, since the RPM didn't include one. Make a new file named /etc/sysconfig/SuSEfirewall2.d/services/upsd . with this content:

# Service description for upsd, the UPS daemon from NUT
# (Network UPS Tools)
#
## Name: NUT upsd
## Description: Allows remote monitoring of UPS power status
# space separated list of allowed TCP ports
TCP="3493"
# space separated list of allowed UDP ports
UDP=""
# space separated list of allowed RPC services
RPC=""
# space separated list of allowed IP protocols
IP=""
# space separated list of allowed UDP broadcast ports
BROADCAST=""

Now start

YaST

as root and choose "Security and Users" -> "Firewall". Select the correct network and choose NUT upsd in the drop-down list. Add the service and click the Next button. This adds upsd to the list of allowed services in the FW_CONFIGURATIONS_EXT variable in the /etc/sysconfig/SuSEfirewall2 configuration script. Port 3493 is now allowed through the iptables firewall.

Configuring remote clients

Install nut on a remote machine, this one is called linux64.

Comment out everything in /etc/ups/ups.conf since we don't have a local UPS attached:

#[myups]
#       driver = undefined
#       port = /dev/undefined
#       desc = "Local UPS"

Edit /etc/ups/upsmon.conf to monitor the server where the UPS is connected:

#MONITOR myups@localhost 1 upsmaster 04fb251a3f master
MONITOR apc_smartups_1400@linux 1 upsslave slavepass123 slave

Add the UPS server to /etc/ups/hosts.conf:

#MONITOR myups@localhost "Local UPS"
MONITOR apc_smartups_1400@linux "APC SmartUPS 1400"

Now start the upsd service, which will ignore the actual upsd and UPS driver since they are unconfigured, and only start upsmon.

rcupsd start

linux64:~ # rcupsd start
Starting NUT UPS monitor done

Check that the connection is working, and that you can read the status values of the remote UPS server.

upsc apc_smartups_1400@linux

linux64:~ # upsc apc_smartups_1400@linux
battery.alarm.threshold: 0
battery.charge: 094.0
battery.charge.restart: 00
[...]

Test the UPS again, and check that the new client also picks up the message

Broadcast Message from upsd@linux64
(somewhere) at 0:13 ...
UPS apc_smartups_1400@linux on battery

Connect the power cable for this server to the UPS, and you now have two servers protected from blackouts and they are both monitoring power status.

References

• Tne Network UPS Tools (NUT) homepage