2013-01-25

HOWTO: make Jigdo use local APT cache

If you like to build Debian install CD images with Jigdo (i. e., with jigdo-lite), you may consider using packages from your local APT cache to save some network traffic.
To make it easily selectable from the Jigdo interface, make sure to add the following line to the ~/.jigdo-lite config file:
scanMenu='/var/cache/apt/archives/ /media/cdrom/'
BTW: /var/cache/apt/archives is a local APT cache directory (containing already downloaded DEB packages); /media/cdrom is a standard CD mount point, so you can reuse the files from the mounted CD image you've previously generated with Jigdo.

References:
  1. More About Scan Sources - Debian Jigdo mini-HOWTO

2013-01-15

FTP search engines: quick list

Usually, the conventional WWW (World Wide Web) search engines can do the Internet search job well, but sometimes (e. g., if you are looking for some particular file name) FTP search, cataloging & indexing engines can be of great help.
Here is a quick list of such sites.

2013-01-14

Free & open source data encryption software: quick list

Here is a quick list of free & open source on-the-fly filesystem (FS) encryption software.
  • Entire disk / volume / partition encryption & "virtual disk" (container file)-based software:
    • LUKS / dm-crypt [Linux (FS driver is implemented at kernel level); encrypted volumes are supported by FreeOTFE in MS Windows];
    • FreeOTFE [MS Windows];
    • DiskCryptor [MS Windows];
    • TrueCrypt [MS Windows, Mac OS X, Linux] (discontinued in 2014-05).
  • File-level encryption tools:
    • eCryptfs [Linux (FS driver is implemented at kernel level)];
    • EncFS [Linux (FUSE-based FS); experimental MS Windows port exists: encfs4win];
    • antigift (a ccrypt wrapper) [Linux, FreeBSD, Mac OS X, MS Windows].
---
Last updated: 2014-06-19

2013-01-06

HOWTO: stress-test a USB flash drive for bad blocks in Linux

Once upon a time you may like to test your USB flash drive [or maybe a SATA HDD, who knows] for bad blocks.

First of all, backup all the data stored on the target drive;
then you should unmount any mounted partitions located on that drive:
# umount /dev/sdz1
Then you can begin the tests (CAUTION: these tests will destroy all the stored data on the tested drive).

You can use dd utility to fill the drive with zeros:
# dd if=/dev/zero of=/dev/sdz
or with pseudorandom data:
# dd if=/dev/urandom of=/dev/sdz
and it will stop unexpectedly on a bad block.

And there's also a little more handy utility called badblocks:
# badblocks -wso /tmp/badblocks.log /dev/sdz
It will sequentially fill the entire /dev/sdz device with some patterns (0xAA, 0x55, 0xFF, 0x00), then read and compare the read data with an actual pattern. A list of bad blocks will be written to /tmp/badblocks.log file.

References: