LAMP on debian (ubuntu mint etc) One line install
![]()
Installing a LAMP stack on deb has never been easier!
sudo tasksel install lamp-server

Howto replace duplicate files with hard links.
Like most people I have multiple backups of the same files, stored in an ad-hoc structure. I went hunting fir a good utility to remove duplicates, and replace them with hard links.
It surprised me that there is a tool for doing this on NTFS volumes under windows. Update: and another free one!
I found a perl script called trimtrees.pl You can find it in CPAN, it's describes itself such:
Traverse all directories named on the command line, compute MD5
checksums and find files with identical MD5. IF they are equal, do a
real comparison if they are really equal, replace the second of two
files with a hard link to the first one.Special care is taken to cope with C
error conditions.
The inode that is overbooked in such a way, is taken out of the pool
and replaced with the another one such that the minimum of files
needed is kept on disk.The C< --maxlinks> option can be used to reduce the linkcount on all
files within a tree, thus preparing the tree for a subsequent call to
C. This operation can be thought of the reverse of the normal
trimtrees operation (--maxlinks=1 produces a tree without hard links).
Rsync to backup
I'll turn this into a script and update the post, but for now:
rsync -avrxP --delete $FILESYSTEMS backup-server:backups/$HOSTNAME
-a, --archive archive mode; same as -rlptgoD (no -H, -A)
-v, --verbose increase verbosity
-r, --recursive recurse into directories
-x, --one-file-system don't cross file system boundaries
-P same as --partial --progress
--progress show progress during transfer
--partial keep partially transfered file in case of interuption,
should make a subsequent transfer of the rest of the file much faster.
Some caveats if you want to fully automate this...
- remove -vP (verbose w/ progress)
- --delete is NECESSARY to make sure deleted files get deleted from the
backup
- FILESYSTEMS should be any local filesystems you want backed up (-x
won't cross filesystems, makes backing up in NFS environment easier)
- obviously this doesn't preclude a bad guy checking out
backup-server:backups/otherhostname (use ssh keys, and invoke cmd="cd
backups/hostname; rsync with whatever daemon options" will limit that)
- on backup-server, rotate the backup every 12 hours or whatever.
- rsync -ar --delete store/hostname.2 store/hostname.3
- rsync -ar --delete store/hostname.1 store/hostname.2
- rsync -ar --delete backups/hostname store/hostname.1
# that could be better optimized, but you get the idea
I've used this rsync system to successfully maintain up to date backups w/
great ease, AND restore very quickly... use a LinuxCare Bootable Business
Card to get the target fdisked and ready, then mount the filesystems as
you desire, and rsync -avrP backup-server:backups/hostname /target. I got
a 700mb server back online in under 20 minutes from powerup to server
serving requests (the rsync itself is 3 to 5 minutes). Making sure you
do (cd /target; lilo -r . -C etc/lilo.conf)) is the only tricky part.
care of ted@psy_spam_ber.com
LVM volgroup creation Debian etch 4.0
I've just upgraded my home media server, and had to set up LVM again, and as i do it so infrequently, i completely forgot what i was doing... so i thought I'd make some notes:
We are going to set up a LVM across two drives, identical 750GB sata disks (sda & sdb), then format it with the jfs file system, which is arguably the best for large (>1GB) files. xfs is also a suitable file system, but ext3 is really slow. in fact I'm surprised anyone uses it at all any more, as reiser is much better for a system partition. Justin Piszcz has the figures to prove it.
First we need to install LVM and JFS suppport:
apt-get install jfsutils lvm2 lvm-common
Initialise the drives with cfdisk (fdisk is buggy and shouldn't be used. If you need bsd support or stuff cfdisk can't do then use sfdisk which is the best in terms of compatibility, but cfdisk is good at what it supports and the interface is nicer).
Create a single partition filling the whole disk. I chose the standard type for linux, 82, & it seemed to work OK, but I did notice that there is a specific type for LVM's (8E), That may be a better choice. I'll look into it and let you know.
now initialise the disks to LVM. this can be done to a partition instead of the whole disk, just use /dev/sda# instead of /dev/sda
pvcreate /dev/sda
pvcreate /dev/dsb
if you get errors you can wipe the disk with
*CAUTION*
dd if=/dev/zero of=/dev/sd# bs=1k count=1
Now create the VolGroup
vgcreate VG_Data /dev/sda /dev/sdb
you can add to an existing volgroup with
vgextend VG_Data /dev/sdc
now initialise the volgroup
vgchange -a y VG_Data
use vgdisplay to see your shiny new volgroup, and note how many extents it has (Total PE):
vgdisplay
Create a logical volume on the volgroup:
lvcreate -l[number of extents] -i[PV's to strip over] -I[stripe size, 32/64/128] -n[name] [VolGroup]
in my case
lvcreate -l357702 -i2 -I128 -ndata VG_Data
check to see the utilisation with vgdisplay, you can extend the logical vol with lvextend:
lvextend -L+2.4G /dev/VG_Data/data
now format the new volume:
mkfs.jfs /dev/VG_Data/data
And that's it, mount and play:
mkdir /mnt/data mount -tjfs /dev/VG_Data/data /mnt/data












