text:
Difference between revisions of "Dm-crypt"
(→Use LUKS container as pseudorandom number generator (alternate): spelling errors; removed expansion)
(→LVM: Logical Volume Manager: removed stub section)
|Line 145:
|Line 145:
It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM).
It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM).
A usage scenario for LUKS on LVM exists where utmost flexibility for assigning available diskspace or a mix of unencrypted and encrypted volumes is desired. Upon boot the LVM is setup and assigned before the LUKS-encrypted volumes are opened. In order to manage changes of volumes in a LUKS on LVM setup, both module layers' setup have to be taken into account, i.e. shrinking or expanding an encrypted volume has to include the resizing of the encrypted LUKS blockdevice to ensure integrity of it and the filesystem. That said, in simpler scenarios the usage of LVM may be superfluous.
A usage scenario for LUKS on LVM exists where utmost flexibility for assigning available diskspace or a mix of unencrypted and encrypted volumes is desired. Upon boot the LVM is setup and assigned before the LUKS-encrypted volumes are opened. In order to manage changes of volumes in a LUKS on LVM setup, both module layers' setup have to be taken into account, i.e. shrinking or expanding an encrypted volume has to include the resizing of the encrypted LUKS blockdevice to ensure integrity of it and the filesystem. That said, in simpler scenarios the usage of LVM may be superfluous.
====Creating Disk Partitions====
====Creating Disk Partitions====
Revision as of 09:30, 15 October 2012
zh-CN:System Encryption with LUKS Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary end
This article focuses on how to set up full system encryption on Arch Linux, using dm-crypt with LUKS.
dm-crypt is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.
LUKS is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.
For more details on how dm-crypt+LUKS compares to other disk encryption solution, see Disk Encryption#Comparison table.
- 1 Caveats
- 2 Initial Setup
- 2.1 Overview and Preparation
- 2.2 Secure erasure of the hard disk drive
- 2.3 Partitioning
- 3 Configuring LUKS
- 3.1 Mapping Physical Partitions to LUKS
- 3.2 Storing the Key File
- 3.2.1 External Storage on a USB Drive
- 3.2.2 Generating the keyfile
- 3.2.3 Storing the keyfile
- 3.2.4 Configuration of initcpio
- 3.2.5 Storing the key as a plain (visible) file
- 3.2.6 Storing the key between MBR and 1st partition
- 3.3 Encrypting the Swap partition
- 3.4 Using a swap file for suspend-to-disk support
- 4 Installing the system
- 4.1 Prepare hard drive for Arch Install Scripts
- 4.2 Configure initramfs
- 4.3 Kernel parameter configuration of the bootloader
- 4.4 Fstab
- 4.5 AIF Instructions (out of date)
- 5 Remote unlocking of the root (or other) partition
- 6 Backup the cryptheader
- 7 Encrypting a loopback filesystem
- 8 Encrypting a LVM setup
- 8.1 LVM with Arch Linux Installer (>2009.08 <2012.07.15)
- 8.2 Applying this to a non-root partition
- 8.3 LVM and dm-crypt manually (short version)
- 8.3.1 Notes
- 8.3.2 Partitioning scheme
- 8.3.3 The commands
- 8.3.4 Install Arch Linux
- 8.3.5 Configuration
- 8.3.6 After rebooting
- 8.4 / on LVM on LUKS
- 9 Using GPG or OpenSSL Encrypted Keyfiles
- 10 Securing the unencrypted boot partition
- 11 Automount user homes on login
- 12 Resources
Initial Setup
Overview and Preparation
The Arch installation media comes with all the tools required for system encryption. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the Installation Guide or the Beginners' Guide after the encrypted partitions are set up. You will have to adjust the System Configuration to be able to boot from your Luks-Volumes tough.
Routine creation of an encrypted system follows these general steps:
- Secure erasure of the hard disk drive(s)
- Partitioning and setup of encryption (LVM optional)
- Routine package selection and installation
- System Configuration
Secure erasure of the hard disk drive
It is recommended to wipe all data accesible on your drive or partition using random data. Random data should be completely indistinguishable from all data later written by dm-crypt for security reasons. Secure erasure of the hard disk drive involves overwriting the entire drive with random data.
Both new and used disks should be securely overwritten. This helps ensure the privacy of data located within the encrypted partitions. The contents of disks purchased directly from a manufacturer is not guaranteed. If the drive was filled with zero bits then after writing encrypted data, it is relatively simple to identify where the encrypted data ends and the zeroed data begins. Since an encrypted partition should be indistinguishable from random data, the lack of random data on a zeroed drive makes the encrypted data an easier target of cryptanalysis.
Repartitioning or reformatting a used hard drive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straightforward using File Recovery Software to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent data recovery.
In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.
Use LUKS container as pseudorandom number generator (alternate)
The cryptsetup FAQ mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.
# dd if=/dev/zero of=/dev/mapper/luks-container
Wipe free space with encrypted file after Installation
The same effect can be achieved if a file is created on each encrypted partition that fills the partition completely after the system is installed, booted and filesystems mounted. That is because encrypted data is indistinguishable from random.
# dd if=/dev/zero of=/file/in/luks-container # rm /file/in/luks-container
Obviously the above process has to be repeated for every container created.
Wipe LUKS keyslots
#cryptsetup luksKillSlot <device> <key slot number>
This will only wipe a single keyslot.
Wipe LUKS header
The partitions formatted with dm-crypt/LUKS contain a header with the cipher and crypt-options used, which is referred to
dm-mod when opening the blockdevice. After the header the actual random data partition starts. Hence, when de-commissioning a drive (e.g. sale of PC, switch of drives, etc.) it may be just enough to wipe the header of the partition, rather than overwriting the whole drive - which can be a lengthy process.
Wiping the LUKS header will delete the PBKDF2-encrypted (AES) master key, salts and so on.
/dev/sda1 in this example) and not directly to the disks device node. If you did set up encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID then write to RAID respectively.
A header with one single default 256 bit size keyslot is 1024KB in size. It is advised to also overwrite the first 4KB written by dm-crypt, so 1028KB have to be wiped. That is
1052672 Byte.
For zero offset use:
#head -c 1052672 /dev/zero > /dev/sda1; sync
For 512 bit key length (e.g. for aes-xts-plain with 512 bit key) the header is 2MB.
If in doubt, just be generous and overwrite the first 10MB or so.
#dd if=/dev/zero of=/dev/sda1 bs=512 count=20480
When wiping the header with random data and the header is followed by encrypted data written ontop random data everything left is random data.
Discard/TRIM support for solid state disks (SSD)
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will not forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device. An illustration and discussion of the issues arising from activating TRIM is available in the blog of a
cryptsetup developer.
As of linux version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in cryptsetup version 1.4.0 and up. To add support during boot, you will need to add
:allow-discards to the
cryptdevice option. The TRIM option may look like this:
For the main
cryptdevice configuration options before the
:allow-discards please refer to the sections following.
For more information, including specific commands and details on dm-crypt TRIM pass-through, see also these mailing list threads:
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134 * http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166
After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.
There are multiple ways to create disk partitions:
LUKS is compatible with systems that require LVM and/or RAID as well as with with standard primary, extended, and logical partitions.
Standard Partitions
These are the partitions that most people are familiar with. They come in three flavors: primary partitions, extended partitions, and logical partitions.
- Primary Partitions
- These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.
- Extended Partitions
- These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.
- Logical Partitions
- These are the partitions that are defined within extended partitions.
LVM: Logical Volume Manager
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the Article on LVM which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.
LVM on LUKS
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKS). The deployment of LVM on LUKS is considered much more generalizable. In a LVM on LUKS scenario, the LUKS-partition has to be opened and mapped before LVM can access the underlaying setup volumes.
One reason for this is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In that case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.
LUKS on LVM
It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM). A usage scenario for LUKS on LVM exists where utmost flexibility for assigning available diskspace or a mix of unencrypted and encrypted volumes is desired. Upon boot the LVM is setup and assigned before the LUKS-encrypted volumes are opened. In order to manage changes of volumes in a LUKS on LVM setup, both module layers' setup have to be taken into account, i.e. shrinking or expanding an encrypted volume has to include the resizing of the encrypted LUKS blockdevice to ensure integrity of it and the filesystem. That said, in simpler scenarios the usage of LVM may be superfluous.
Creating Disk Partitions
Disk partitions are created using:
# cfdisk
This will display a graphical interface for creating disk partitions.
There are two required partitions for any encrypted system:
- root file system
/Will be encrypted and store all system and user files (
/home, etc.)
- initial boot partition
/bootWill not be encrypted; the bootloader needs to access the
/bootdirectory where it will load the initramfs/encryption modules needed to load the rest of the system which is encrypted (see Mkinitcpio for details). For this reason,
/bootneeds to reside on its own, unencrypted partition.
Single Disk Systems
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However, if LVM is to be used, the space unoccupied by
/boot and swap should be defined as single large partition which will be divided up later at the LVM level.
Multiple Disk Systems
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the
/boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.
Configuring LUKS
This section covers how to manually utilize LUKS from the command line to encrypt a system.
Mapping Physical Partitions to LUKS
After writing the partition table to the MBR (optionally set up LVM thereafter) the next step is to create the LUKS and dm-crypt magic and make device mapper mount it to the filesystem of the installation system.
When creating LUKS partitions they must be associated with a key. The key is used to unlock the header of the LUKS-encrypted partitions.
A key is either a:
- Passphrase
- Keyfile
It is possible to define up to 8 different keys per LUKS partition. This enables the user to create access keys for save backup storage. Also a different key-slot could be used to grant access to a partition to a user by issuing a second key and later revoking it again without the need to re-encrypt the partition.
Using LUKS to Format Partitions with a Passphrase
/etc/crypttab is deprecated.
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.
# cryptsetup [OPTION...] <action> <action-specific>
# cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random --verify-passphrase luksFormat <device>
Common options used with luksFormat:
|Available options
|Cryptsetup defaults
|--cipher, -c
|Use the AES-cipher with CBC/ESSIV.
|XTS. For volumes >2TiB use
aes-xts-plain64 (requires kernel >= 2.6.33).
|--key-size, -s
|The cipher is used with 256 bit key-size.
|XTS splits the supplied key into fraternal twins. For an effective AES-256 the XTS key-size must be
|--hash, -h
|Hash algorithm used for PBKDF2.
|--iter-time, -i
|Number of milliseconds to spend with PBKDF2 passphrase processing.
|Using a hash stronger than sha1 results in less iterations if iter-time is not increased.
|/dev/urandom is used as randomness source for the (long-term) volume master key.
|Avoid generating an insecure master key if low on entropy. Will block if the entropy pool is used up.
|--verify-passphrase, -y
|Default only for luksFormat and luksAddKey.
|No need to type for archlinux at the moment.
When comparing the defaults with the example, it has to be taken into account that a number of the options stated affect system performance just for creating the initial crypt-blockdevice or opening it, but not the disk-io operations when the system is running. A full list of options
cryptsetup accepts can be found in the manpage.
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher. Other ciphers can be used with cryptsetup, and details about them can be found here: Wikipedia:Block_cipher
Formatting LUKS Partitions
First of all make sure the device mapper kernel module is loaded by executing the following:
# modprobe dm_mod
In order to format a desired partition as an encrypted LUKS partition execute:
# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>
Enter passphrase: <password> Verify passphrase: <password>
Check results:
# cryptsetup luksDump /dev/<drive>
This should be repeated for all partitions except for
/boot and possibly swap.
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as XTS-AES).
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2
/boot partition must remain separate and unencrypted in order to load the kernel and boot the system.
Unlocking/Mapping LUKS Partitions with the Device Mapper
Once the LUKS partitions have been created it is time to unlock them.
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that
/dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the
/dev/mapper/<name> so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to backup the cryptheader after finishing setup.
In order to open an encrypted LUKS partition execute:
# cryptsetup luksOpen /dev/<partition name> <device-mapper name>
Enter any LUKS passphrase: <password> key slot 0 unlocked. Command successful.
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:
- cryptsetup luksOpen /dev/sda2 swap
- Once opened, the swap partition device address would be
/dev/mapper/swapinstead of
- cryptsetup luksOpen /dev/sda3 root
- Once opened, the root partition device address would be
/dev/mapper/rootinstead of
- cryptsetup luksOpen /dev/sda3 lvmpool (alternate)
- For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like
/dev/mapper/lvmpoolinstead of
/dev/sda3. LVM will then give additional names to all logical volumes created, e.g.
In order to write encrypted data into the partition it must be accessed through the device mapped name.
/boot is not encrypted, it does not need a device mapped name and will be addressed as
Using LUKS to Format Partitions with a Keyfile
What is a Keyfile?
A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume. Therefore if these files are lost or changed, decrypting the volume will no longer be possible.
Why use a Keyfile?
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:
- keyfile.passphrase:
- this is my passphrase I would have typed during boot but I have placed it in a file instead
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.
- keyfile.randomtext:
- fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.
- keyfile.binary:
- where any binary file, images, text, video could be chosen as the keyfile
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.
Creating a Keyfile with Random Characters
dd is used to generate a keyfile of 2048 bits of random characters.
# dd if=/dev/urandom of=mykeyfile bs=512 count=4
The usage of
dd is similar to initially wiping the volume with random data prior to encryption.
Creating a new LUKS encrypted partition with a Keyfile
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> /path/to/mykeyfile
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.
Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition
LUKS supports the association of up to 8 keys with any single encrypted volume. Keys can be either keyfiles or passphrases.
Once an encrytped partition has been created, the initial key is associated at slot 0. Additional keys will occupy slots 1–7.
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the
luksAddKey extension.
# cryptsetup luksAddKey /dev/<encrypted volume> /path/to/mykeyfile
/dev/<encrypted volume> is the volume that is to have the new key associated with it.
If the bolded area is present, cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.
Storing the Key File
External Storage on a USB Drive
Preparation for Persistent block device naming
For reading the file from an external storage device it is very convenient to access it through udev's Persistent block device naming features and not by ordinary device nodes like
/dev/sdb1 whose naming depends on the order in which devices are plugged in. So in order to assure that the
encrypt HOOK in the initcpio finds your keyfile, you must use a permanent device name.
Persistent symlinks
A quick method (as opposed to setting up a udev rule) for doing so involves referencing the right partition by its UUID, id (based on hardware info and serial number) or filesystem label.
Plug the device in and print every file name under /dev/disk:
#ls -lR /dev/disk/
/dev/disk/: total 0 drwxr-xr-x 2 root root 180 Feb 12 10:11 by-id drwxr-xr-x 2 root root 60 Feb 12 10:11 by-label drwxr-xr-x 2 root root 100 Feb 12 10:11 by-path drwxr-xr-x 2 root root 180 Feb 12 10:11 by-uuid /dev/disk/by-id: total 0 lrwxrwxrwx 1 root root 9 Feb 12 10:11 usb-Generic_STORAGE_DEVICE_000000014583-0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 12 10:11 usb-Generic_STORAGE_DEVICE_000000014583-0:0-part1 -> ../../sdb1 /dev/disk/by-label: total 0 lrwxrwxrwx 1 root root 10 Feb 12 10:11 Keys -> ../../sdb1 /dev/disk/by-path: total 0 lrwxrwxrwx 1 root root 9 Feb 12 10:11 pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 12 10:11 pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdb1 /dev/disk/by-uuid: total 0 lrwxrwxrwx 1 root root 10 Feb 12 10:11 baa07781-2a10-43a7-b876-c1715aba9d54 -> ../../sdb1
Using the filesystem UUID for persistent block device naming is considered very reliable. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.
The right device node for what is now
/dev/sdb1 will always get symlinked by
/dev/disk/by-uuid/baa07781-2a10-43a7-b876-c1715aba9d54. Symlinks can be used in the bootloaders "cryptkey" kernel option or anywhere else.
For legacy filesystems like FAT the UUID will be much shorter but collision is still unlikely to happen if not mounting many different FAT filesystems at once.
In the following example a FAT partition is labeled as "Keys" and will always get symlinked by
#mkdosfs -n >volume-name< /dev/sdb1
#blkid -o list
device fs_type label mount point UUID ------------------------------------------------------- /dev/sdb1 vfat Keys (not mounted) 221E-09C0
sdb2, ...) but not to the USB device (
sdb) itself. Use something like
/dev/disk/by-id/* or alternatively create a udev rule as described in the following section.
Persistent udev rule
Optionally you may choose to set up your flash drive with a udev rule. There is some documentation in the Arch wiki about that already; if you want more in-depth, structural info, read this guide. Here is quickly how it goes.
Get the serial number from your USB flash drive:
lsusb -v | grep -A 5 Vendor
Create a udev rule for it by adding the following to a file in
/etc/udev/rules.d/, such as
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"
$SYMLINK and
$SERIAL with their respective values.
%n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).
Rescan your sysfs:
udevadm trigger
Now check the contents of
ls /dev
It should show your device with your desired name.
Generating the keyfile
Optionally you can mount a tmpfs for storing the temporary keyfile.
# mkdir ./mytmpfs # mount tmpfs ./mytmpfs -t tmpfs -o size=32m # cd ./mytmpfs
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.
So copy your keyfile to some place you consider as secure before unmounting.
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g.
The keyfile can be of arbitrary content and size. We will generate a random temporary keyfile of 2048 bytes:
# dd if=/dev/urandom of=secretkey bs=512 count=4
If you stored your temporary keyfile on a physical storage device, remember to not just (re)move the keyfile later on, but use something like
cp secretkey /destination/path shred --remove --zero secretkey
to securely overwrite it. For overaged filesystems like FAT or ext2 this will suffice while in the case of journaling filesystems, flash memory hardware and other cases it is highly recommended to wipe the entire device or at least the keyfiles partition.
Add a keyslot for the temporary keyfile to the LUKS header:
# cryptsetup luksAddKey /dev/sda2 secretkey
Enter any LUKS passphrase: key slot 0 unlocked. Command successful.
Storing the keyfile
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure). In any case you have to do some further configuration, if not already done above.
Configuration of initcpio
You have to add two extra modules in your
/etc/mkinitcpio.conf, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell
mkinitcpio about it:
MODULES="ata_generic ata_piix nls_cp437 vfat" FILES="/etc/udev/rules.d/8-usbstick.rules"
In this example it is assumed that you use a FAT formatted USB drive. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.
Additionally, insert the
usb hook somewhere before the
encrypt hook.
HOOKS="... usb encrypt ... filesystems ..."
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the
keymap hook before
Generate a new image (maybe you should backup a copy of your old
/boot/initramfs-linux.img first):
# mkinitcpio -p linux
Storing the key as a plain (visible) file
Be sure to choose a plain name for your key – a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) – the
encrypt hook will fail to find the keyfile during the boot process.
You have to add a kernel parameter in your
/boot/grub/menu.lst (GRUB). It should look something like this:
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey
This assumes
/dev/usbstick is the FAT partition of your choice. Replace it with
/dev/disk/by-... or whatever your device is.
That is all, reboot and have fun!
Storing the key between MBR and 1st partition
We will write the key directly between the Master Boot Record (MBR) and the first partition.
If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors (actually, it depends on the type of the file system, so do not rely on this too much), so you would have to replace
seek=4 with
seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key.
Optional If you do not know if you have enough free space before the first partition, you can do
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors hexcurse 64sectors # determine free space xxd 64sectors | less # alternative hex viewer
Write your key to the disk:
dd if=secretkey of=/dev/usbstick bs=512 seek=4
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.
You should not simply use
rm as the keyfile would only be unlinked from your filesystem and be left physically intact.
Now you have to add a kernel parameter in your
/boot/grub/menu.lst file (GRUB); it should look something like this:
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048
Format for the
cryptkey option:
OFFSET and
SIZE match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048
That is all, reboot and have fun! And look if your partitions still work after that ;-).
Encrypting the Swap partition
Without suspend-to-disk support
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random master key with each boot. This is accomplished by using dm-crypt directly without LUKS extensions.
/etc/crypttab is well commented and you can basically just uncomment the swap line and change <device> to a persistent symlink.
# <name> <device> <password> <options> # swap /dev/hdx4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
- <name>
- Represents the name (
/dev/mapper/<name>) to list in /etc/fstab.
- <device>
- Should be the symlink to the actual partition's device file.
- <password>
/dev/urandomsets the dm-crypt master key to be randomized on every volume recreation.
- <options>
- The
swapoption runs mkswap after cryptographic's are setup.
Persistent block device naming is implemented with simple symlinks. Using UUID's or filesystem-labels is not possible as plain dm-crypt writes only encrypted data without a persistent header like LUKS. If you are not familar with one of the directories under
/dev/disk/ read on in the section on #Preparation for Persistent block device naming
#ls -l /dev/disk/*/* | grep sda2
lrwxrwxrwx 1 root root 10 Oct 12 16:54 /dev/disk/by-id/ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part2 -> ../../sda2
Example line for the
/dev/sda2 symlink from above:
# <name> <device> <password> <options> swap /dev/disk/by-id/ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part2 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
This will map
/dev/sda2 to
/dev/mapper/swap as a swap partition that can be added in
/etc/fstab like a normal swap.
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be overwritten once.
With suspend-to-disk support
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before
/etc/crypttab can be used, it is required to create a hook in
/etc/mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.
If you want to use a partition which is currently used by the system, you have to disable it first:
# swapoff /dev/<device>
To create the swap partition, follow steps similar to those described in mapping partitions above.
- Format the partition you want to use as swap with the
cryptsetupcommand. For performance reasons, you might want to use different ciphers with different key sizes.
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device>
Check the result with:
# cryptsetup luksDump /dev/<device>
- Open the partition in
# cryptsetup luksOpen /dev/<device> swapDevice
- Create a swap filesystem inside the mapped partition:
# mkswap /dev/mapper/swapDevice
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in
/etc/crypttab which uses this device. Now you have to create a hook to open the swap at boot time.
- Create a hook file containing the open command:
# vim: set ft=sh: run_hook () { cryptsetup luksOpen /dev/<device> swapDevice }
- Then create and edit the hook setup file:
# vim: set ft=sh: build () { MODULES="" BINARIES="" FILES="" SCRIPT="openswap" } help () { cat<<HELPEOF This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice HELPEOF }
- Add the hook
openswapin the
HOOKSarray in
/etc/mkinitcpio.conf, before
filesystembut after
encrypt. Do not forget to add the
resumehook after
HOOKS="... encrypt openswap resume filesystems ..."
- Regenerate the boot image:
# mkinitcpio -p linux
- Add the mapped partition to
/etc/fstabby adding the following line:
/dev/mapper/swapDevice swap swap defaults 0 0
- Set up your system to resume from
/dev/mapper/swapDevice. For example, if you use GRUB with kernel hibernation support, add
resume=/dev/mapper/swapDeviceto the kernel line in
/boot/grub/menu.lst. A line with encrypted root and swap partitions can look like this:
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro
At boot time, the
openswap hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed after
openswap in the
HOOKS array. Please note that because of initrd opening swap, there is no entry for swapDevice in
/etc/crypttab needed in this case.
Using a swap file for suspend-to-disk support
- Choose a mapped partition (e.g.
/dev/mapper/rootDevice) whose mounted filesystem (e.g.
/) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.
- Create the swap file (e.g.
/swapfile) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with
swaponand also add it to your
/etc/fstabfile afterward.
- Set up your system to resume from your chosen mapped partition. For example, if you use GRUB with kernel hibernation support, add
resume=your chosen mapped partition and
resume_offset=see calculation command below to the kernel line in
/boot/grub/menu.lst. A line with encrypted root partition can look like this:
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro
You can calculate the
resume_offset of your swap file like this:
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'
- Add the
resumehook to your
etc/mkinitcpio.conffile and rebuild the image afterward:
HOOKS="... encrypt resume ... filesystems ..."
- If you use a USB keyboard to enter your decryption password, then the
usbinputmodule must appear in front of the
encrypthook, as shown below. Otherwise, you will not be able to boot your computer because you couldn't enter your decryption password to decrypt your Linux root partition!
HOOKS="... usbinput encrypt ..."
Installing the system
Prepare hard drive for Arch Install Scripts
This assumes you want to install an encrypted system with the Arch Install Scripts, have created partitions for
/ (e.g.
/dev/sdaX) and
/boot (
/dev/sdaY) at least, following the Installation Guide and deciding against using LVM. Prior to creating the partitions you have done a preparation of the disk for encryption according to your necessities (the necessary tools are on the installation-ISO).
First check, if the blockdevice mapper
dm_mod is loaded with
# lsmod | grep mod
If one wants to use the default LUKS-cipher algorithm, there is no need to specify one for the luksFormat. At the time of writing the default is set to an AES variant with 256 bit key-length. With that a dm-crypt/LUKS blockdevice for the crypted root can be created
# cryptsetup -y -v luksFormat /dev/sdaX
# cryptsetup luksOpen /dev/sdaX cryptroot
formatted with your desired filesystem
# mkfs -t ext4 /dev/mapper/cryptroot
and mounted
# mount -t ext4 /dev/mapper/cryptroot /mnt
At this point, just before installing the base system, it might be useful to check the mapping works as intended:
# umount /mnt # cryptsetup luksClose cryptroot
and mount it again to check.
If you created a separate
/home partition, the steps have to be adapted and repeated for that.
What you do have to setup is a non-encrypted
/boot partition, which is needed for a crypted root. For a standard MBR/non-EFI
/boot partition that may be achieved by formatting
# mkfs -t ext2 /dev/sdaY
creating a mount-point for installation
# mkdir /mnt/boot
and mounting it
# mount -t ext2 /dev/sdaY /mnt/boot
That is basically what is necessary at this point before installing the base system with the Arch Install Scripts. Take care to install the bootloader to
/mnt/boot with the
pacstrap script. Additional configuration steps must be followed before booting the installed system.
Configure initramfs
One important point is to add the hooks relevant for your particular install in the correct order to
/etc/mkinitcpio.conf. The one you have to add when encrypting the root filesystem is
encrypt. Others needed, e.g.
keymap, should be clear from other manual steps you follow during the installation and further details in the following. For detailed information about mkinitcpio and its configuration refer to Mkinitcpio.
encrypt hook is only needed if your root partition is a LUKS partition (or a LUKS partition that needs to be mounted before root). The
encrypt hook is not needed for any other encrypted partitions (swap, for example). System initialization scripts (
/etc/rc.sysinit and
/etc/crypttab among others) take care of those.
You have to make sure that your
HOOKS array looks something like this:
HOOKS="... encrypt ... filesystems ..."
It is important that the
encrypt hook comes before the
filesystems hook. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:
HOOKS="... usb encrypt ... filesystems ..."
For safety, add
usb before
encrypt because the hooks are run in the order they appear.
If you need support for foreign keymaps for your encryption password, you have to specify the hook
keymap as well. I suggest putting this in
/etc/mkinitcpio.conf immediately before
If you have a USB keyboard, you will need the
usbinput hook in
/etc/mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.
If your root partition is a LUKS partition, add the used filesystem to the
MODULES section.
MODULES="... ext3 ext4 xfs ..."
Kernel parameter configuration of the bootloader
The article on GRUB2 gives a brief introduction and features a small section on configuration for system encryption.
The recommended way for configuring GRUB is
/etc/default/grub where the kernel line has to be adjusted so GRUB can pass to the kernel how to map the (encrypted) root device.
The syntax for cryptdevice is:
- <device>
- The path to the raw encrypted device. Usage of Persistent block device naming is advisable.
- <dmname>
- The name given to the device after decryption, will be available as
So if the encrypted root device is in example
/dev/sda2 and the decrypted one should be mapped to
/dev/mapper/cryptroot the kernel line must look like:
Depending on the setup other parameters are required as well:
GRUB_CMDLINE_LINUX="cryptdevice=<device>:<dmname> root=<device> resume=<device> cryptkey=<device>:<fstype>:<path>"
- root=<device>
- The device file of the actual (decrypted) root filesystem. If the filesystem is formatted directly on the decrypted device file this will be
/dev/mapper/<dmname>. If LVM is in between sth. like
/dev/<volgroup>/<pvol>does the trick.
- resume=<device>
- The device file of the decrypted (swap) filesystem used for suspend2disk.
- cryptkey=<device>:<fstype>:<path>
- Required for reading a keyfile from a filesystem.
The syntax for the optional cryptkey parameter is:
- <device>
- The raw block device where the key exists.
- <fstype>
- The filesystem type of <device> (or auto).
- <path>
- The absolute path of the keyfile within the device.
The device name your harddrive should be mapped to depends on your setup and configuration. If you are directly decrypting your root partition, the parameter
root=/dev/mapper/cryptroot will indicate the expected name. In case of LVM this name can be any arbitrary name, as LVM will parse all available devices if specified as the next hook.
The Article on Syslinux describes in the basic config-section how to use LUKS for system encryption (added 2012):
APPEND root=/dev/mapper/<name> cryptdevice=/dev/sda2:<name> ro
GRUB Legacy
GRUB Legacy: You have to make some small changes to the entries generated by the installer by replacing
/dev/mapper/root with
/dev/sda3. The important point to remember here is to use the same
cryptdevice name you assigned when you initially unlocked your device. In this example, the device name is
cryptroot; customize yours accordingly:
# (0) Arch Linux title Arch Linux root (hd0,0) kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro initrd /initramfs-linux.img
For kernels older than 2.6.37, the syntax is:
# (0) Arch Linux title Arch Linux root (hd0,0) kernel /vmlinuz26 root=/dev/sda3 ro initrd /kernel26.img
LILO: Edit the Arch Linux section in
/etc/lilo.conf and include a line for the
append option, over the initrd, with the
root=/dev/sda3 parameter. The
append section makes the same kernel line as in GRUB. Also, you can omit the
root option above the
image option. The section looks like this:
# Arch Linux lilo section image = /vmlinuz-linux # root = /dev/sda3 label = Arch initrd = /initramfs-linux.img append = "root=/dev/sda3" read-only
cryptkey option. See the corresponding section below.
Further, double-check the
genfstab scripts result for your
/dev/mapper/cryptroot and other mounts.
AIF Instructions (out of date)
Prepare hard drive for AIF
Now that
/dev/mapper/root and
/dev/mapper/home are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.
# /arch/setup
Skip the Partitioning and Auto-Prepare steps and go straight to manual configuration.
Instead of choosing the hardware devices (
/dev/sdaX) directly, you have to select the mapper devices created above.
/dev/mapper/root for your root and
/dev/mapper/home as
/home partition respectively and format them with any filesystem you like.
The same is valid for a swap partition which is set up like the
/home partition. Make sure you mount
/dev/sda1 as the
/boot partition, or else the installer will not properly set up the bootloader.
Select and Install packages
Select and install the packages as usual: the base package contains all required programs.
Exit Install
Now that the install is finished the only thing left to do is add entries to the
/etc/crypttab file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g.
/home, swap, etc.
# vi /mnt/etc/crypttab
Add one of the following for the
/home partition.
/etc/crypttab is deprecated: see http://firstname.lastname@example.com/msg02115.html
home /dev/sda5 /etc/mypassword1
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described above.
Then add the following information to the
/etc/crypttab file for automounting:
home /dev/sda5 /path/of/your/keyfile
If you used a USB device to store your keyfile, you should have something like this:
home /dev/sda5 /dev/sd*1/keyfile
Or if the keyfile was stored in the MBR, it should be like this:
home /dev/sda5 /dev/sd*:2048:2048
After rebooting you should now be presented with the text
A password is required to access the root filesystem:
followed by a prompt for a LUKS password. Type it in and everything should boot.
Once you have logged in, have a look at your mounted partitions by typing
mount. You should have
/dev/mapper/root mounted at
/ and, if you set up a separate encrypted home partition,
/dev/mapper/home mounted at
/home. If you set up encrypted swap,
swapon -s should have
/dev/mapper/swap listed as your swap partition.
Remote unlocking of the root (or other) partition
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the
net hook along with an SSH server in initrd. Install the dropbear_initrd_encryptAUR package from the AUR and follow the post-installation instructions. Replace the
encrypt hook with
dropbear encryptssh in
/etc/mkinitcpio.conf. Put the
net hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.
If you would simply like a nice solution to mount other encrypted partitions (such as
/home)remotely, you may want to look at this forum thread.
-–allow-discards from
/boot/grub/menu.lst. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use
fstrim.For a temporary solution just add
-–allow-discards to every cryptsetup line of
/lib/initcpio/install/dropbear(1 line) and
/lib/initcpio/hooks/encryptssh(3 lines)
Backup the cryptheader
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much as a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. A damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table.
Therefore, having a backup of the headers and storing them on another disk might be a good idea.
Attention: Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure! In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key is encrypted with your passphrases or keyfiles. But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader! I.e. if someone has got your cryptheader and one of your keys he can decrypt the master key and access all your data. Of course the same is true for all backups you create of your partions. So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not. See also the LUKS FAQ for further details on this.
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)
cryptsetup luksDump /dev/sdaX | grep "Payload offset" Payload offset: 4040
Now that you know the value, you can backup the header with a simple dd command
dd if=/dev/sdaX of=./backup.img bs=512 count=4040
Using cryptsetup
You can also use the luksHeaderBackup command instead:
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition). Restoring the wrong header or restoring to an unencrypted partition will cause data loss.
Again, you will need to the same values as when backing up:
dd if=./backup.img of=/dev/sdX bs=512 count=4040
Using cryptsetup
Or you can use the luksHeaderRestore command:
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img
Note: All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.
Encrypting a loopback filesystem
[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]
Preparation and mapping
First, start by creating an encrypted container!
dd if=/dev/urandom of=/bigsecret bs=1M count=10
This will create the file
bigsecret with a size of 10 megabytes.
losetup /dev/loop0 /bigsecret
This will create the device node
/dev/loop0, so that we can mount/use our container.
/dev/loop0: No such file or directory, you need to first load the kernel module with
modprobe loop. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with
losetup -f.
cryptsetup luksFormat /dev/loop0
This will ask you for a password for your new container file.
Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors, then run
modprobe dm-mod.
cryptsetup luksOpen /dev/loop0 secret
The encrypted container is now available through the device file
Now we are able to create a partition in the container:
mkfs.ext2 /dev/mapper/secret
and mount it...
mkdir /mnt/secret mount -t ext2 /dev/mapper/secret /mnt/secret
We can now use the container as if it was a normal partition! To unmount the container:
umount /mnt/secret cryptsetup luksClose secret losetup -d /dev/loop0 # free the loopdevice.
so, if you want to mount the container again, you just apply the following commands:
losetup /dev/loop0 /bigsecret cryptsetup luksOpen /dev/loop0 secret mount -t ext2 /dev/mapper/secret /mnt/secret
Encrypt using a key-file
Let us first generate a 2048 byte random keyfile:
dd if=/dev/urandom of=keyfile bs=1k count=2
We can now format our container using this key
cryptsetup luksFormat /dev/loop0 keyfile
or our partition :
cryptsetup luksFormat /dev/hda2 keyfile
Once formatted, we can now open the LUKS device using the key:
cryptsetup -d keyfile luksOpen /dev/loop0 container
You can now like before format the device
/dev/mapper/container with your favorite filesystem and then mount it just as easily.
The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.
Resizing the loopback filesystem
First we should unmount the encrypted container:
umount /mnt/secret cryptsetup luksClose secret losetup -d /dev/loop0 # free the loopdevice.
After this we need to expand our container file with the size of the data we want to add:
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret
Be careful to really use TWO
>, or you will override your current container!
You could use
/dev/zero instead of
/dev/urandom to significantly speed up the process, but with
/dev/zero your encrypted filesystems will not be as secure. (A better option to create random data quicker than
/dev/urandom is
frandom [1], available from the AUR).
Now we have to map the container to the loop device:
losetup /dev/loop0 /bigsecret cryptsetup luksOpen /dev/loop0 secret
After this we will resize the encrypted part of the container to the maximum size of the container file:
cryptsetup resize secret
Finally, we can resize the filesystem. Here is an example for ext2/3/4:
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs resize2fs /dev/mapper/secret
You can now mount your container again:
mount /dev/mapper/secret /mnt/secret
Encrypting a LVM setup
It's really easy to use encryption with LVM. If you do not know how to set up LVM, then read Installing_with_Software_RAID_or_LVM.
The easiest and best method is to set up LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: Arch Linux: LVM on top of an encrypted partition
The most important thing in setting LVM on top of encryption is that you need to have the
encrypt hook before the
lvm2 hook (and those two before the
filesystems hook, but that's repeating) because they are processed in order.
To use encryption on top of LVM, you have to first set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of
/dev/sdXy in the guide with its LVM counterpart. (E.g.:
/dev/sda5 ->
/dev/<volume group name>/home). This is used to setup partitions (inside the LVM) which can be unlocked separately or a mixture of encrypted and non-encrypted partitions.
For encrypted partitions inside an LVM, the LVM-hook has to run first, before the respective encrypted logical volumes can be unlocked. So for this add the
encrypt hook in
/etc/mkinitcpio.conf after the
lvm2 hook, if you chose to set up encrypted partitions on top of LVM. Also remember to change
USELVM in
/etc/rc.conf to
LVM with Arch Linux Installer (>2009.08 <2012.07.15)
In between Arch Linux installation media release 2009.08 and 2012.07.15 LVM and dm_crypt had been supported by the installer out of the box. This made it very easy to configure a system for LVM on dm-crypt or vice versa. Actually the configuration is done exactly as without LVM: see the corresponding section above. It differs only in two aspects.
The partition and filesystem choice
Create a small, unencrypted boot partition and use the remaining space for a single partition which can later be split up into multiple logic volumes by LVM.
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params /dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512 /dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params /dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params /dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M /dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params /dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params
The configuration stage
- In
- In
/etc/mkinitcpio.confadd the
encrypthook before the
lvm2hook in the
HOOKSarray, if you set up LVM on top of the encrypted partition.
That is it for the LVM & dm_crypt specific part. The rest is done as usual.
Applying this to a non-root partition
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in
/lib/initcpio/hooks/encrypt (the first one to your
/dev/sd* partition, the second to the name you want to attribute). That should be enough.
The big advantage is you can have everything automated, while setting up
/etc/crypttab with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of
/etc/fstab (at least).
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking
/etc/rc.sysinit or similar files. Unlike
/etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the
/dev/mdX device in
/lib/initcpio/hooks/encrypt is not enough; the
encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the
encrypt hook is run. You can solve this by putting the RAID array in
/boot/grub/menu.lst, like
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). GRUB can handle multiple array definitions just fine:
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5
LVM and dm-crypt manually (short version)
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.
Partitioning scheme
/dev/sda2-> LVM
The commands
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2 dd if=/dev/urandom of=/dev/mapper/lvm cryptsetup remove lvm lvm pvcreate /dev/sda2 lvm vgcreate lvm /dev/sda2 lvm lvcreate -L 10G -n root lvm lvm lvcreate -L 500M -n swap lvm lvm lvcreate -L 500M -n tmp lvm lvm lvcreate -l 100%FREE -n home lvm cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root cryptsetup luksOpen /dev/lvm/root root mkreiserfs /dev/mapper/root mount /dev/mapper/root /mnt dd if=/dev/zero of=/dev/sda1 bs=1M mkreiserfs /dev/sda1 mkdir /mnt/boot mount /dev/sda1 /mnt/boot mkdir -p -m 700 /mnt/etc/luks-keys dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256
Install Arch Linux
USELVM="no" to
lvm2 and
encrypt (in that order) before
filesystems in the
HOOKS array. Again, note that you are setting encryption on top of LVM.)
if you want install the system on a usb stick, you need to put
usb just after
root=/dev/hda3 to
For kernel >= 2.6.30, you should change
root=/dev/hda3 to the following:
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root
if you want install the system on a usb stick, you need to add
/dev/mapper/root / reiserfs defaults 0 1 /dev/sda1 /boot reiserfs defaults 0 2 /dev/mapper/tmp /tmp tmpfs defaults 0 0 /dev/mapper/swap none swap sw 0 0
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512 tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512
After rebooting
The commands
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home mkreiserfs /dev/mapper/home mount /dev/mapper/home /home
home /dev/lvm/home /etc/luks-keys/home
/dev/mapper/home /home reiserfs defaults 0 0
/ on LVM on LUKS
Make sure your kernel command line looks like this:
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group>
For example:
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg
Or like this:
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root
Using GPG or OpenSSL Encrypted Keyfiles
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article System Encryption using LUKS with GPG encrypted keys:
- GnuPG: Post regarding GPG encrypted keys This post has the generic instructions.
- OpenSSL: Post regarding OpenSSL encrypted keys This post only has the
Note that:
- You can follow the above instructions with only two primary partitions one boot partition
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have
as many partitions as you need, but most importantly it should contain at least root, swap, and
home logical volume partitions. This has the added benefit of having only one keyfile for all
your partitions, and having the ability to hibernate your computer (suspend to disk) where the
swap partition is encrypted. If you decide to do so your hooks in
should look like
HOOKS=" ... usb usbinput (etwo or ssldec) encrypt(if using openssl) lvm2 resume ... "
and you should add to your
kernel line(if using grub,
/boot/grub/menu.lst) or
GRUB_CMD_LINE(if using grub2,
- If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an
unencrytped disk. Even better make sure to store them to RAM such as
- If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package gnupg1
- It is possible that an update to OpenSSL could break the custom
ssldecmentioned in the second forum post.
Securing the unencrypted boot partition
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under
/boot for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2). There is also an AUR package: chkbootAUR
After installation:
- For classical sysvinit: add
/usr/local/bin/chkboot.sh &to your
- For systemd: add a service file and enable the service: systemd. The service file might look like:
[Unit] Description=Check that boot is what we want [Service] Type=oneshot ExecStart=/usr/local/bin/chkboot.sh [Install] WantedBy=multi-user.target
There is a small caveat for systemd: At the time of writing the original
chkboot.sh script provided contains an empty space at the beginning of
#!/bin/bash which has to be removed for the service to start successfully.
/usr/local/bin/chkboot_user.sh need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties).
With Arch Linux changes to
/boot are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so:
#!/bin/bash # # Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically # echo "Pacman update [1] Quickcheck before updating" & sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> /usr/local/bin/chkboot.sh sync # sync disks with any results sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> echo "Pacman update [2] Syncing repos for pacman" pacman -Syu /usr/local/bin/chkboot.sh sync sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> echo "Pacman update [3] All done, let's roll on ..."
Automount user homes on login
See Pam mount.
- cryptsetup FAQ - The main and foremost help resource, directly from the developers.
- FreeOTFE - Supports unlocking LUKS encrypted volumes in Microsoft Windows.
- Arch cryptsetup example video - A HowTo video on setting up an encrypted Arch system from scratch. The video still shows an installation with AIF, which is at the time of writing deprecated / not developed further. The important partitioning and cryptsetup are shown outside AIF though.
- Install Arch Linux on top of RAID1, LVM2, and encrypted partitions - The HowTo instructs to make a full Fedora 13 Install only to set up the mapping. Then legacy AIF is used.


text:
Map Unavailable
Date(s) - 20/10/2020
10:15 am - 11:30 am
Montclair Public Library
At the Write Group's core meeting, we go around the table to share our writing progress. Then we discuss writing craft issues. Finally, we cover Write Group business. Afterward, we schmooze in the café area. You never know what writing nuggets you'll pick up in this networking opportunity with your fellow writers!
In the library's conference room!

subset: commoncrawl


text:
By continuing to use this service you will be deemed to have accepted the updated Terms of Use
You can store your downloads in your account when you signup!
By clicking Sign Up, you are agreeing to the Terms of Service
Over 7 million templates sold!
Our website uses images, trademarks and names of third party products which are the property of their respective owners.
Drag & drop not supported, but you can still upload via this input field:


text: Besides our wide selection, we also offer guaranteed best pricing on A+ Childsupply kids furniture, with items starting as low as $47.66. At Unbeatablesale.com, we celebrate the quality of our service, not just our products. We take every step we can to make sure your online shopping experience is simple, secure, and efficient.You can check the status of your order anytime on our order status page so you know exactly where your package is. Shop Unbeatablesale.com today for a great experience!


text:
Arcade Games
This page contains Cheats for Rolling Thunder organized by sections for Arcade. This game has "Action Shooter" as genre, made by Namco. If you can't find a hint or secret in our list, then please check this page periodically for the latest updates.
Boxshot & Details
- Developer: Namco
- Publisher: Atari
- Genre: Action Shooter
- Release: Not Set
- ESRB: Not Set
Game Walkthroughs
Added on: 03-04-2016
Submit Cheats
If you know cheat codes, secrets, hints, glitches or other level guides for this game that can help others leveling up, then please Submit your Cheats and share your insights and experience with other gamers.
Ask a Question
Stuck in this game? Set a specific, clearly defined question and let other gamers answer your question or view answers to previously asked questions. If you think you are an expert then please try to help others with their questions.
Your Question
Gameplay Videos
Rolling Thunder - Gameplay Video
- Added on: May 14, 2014
More Options
Games You May Like
Released Games
- Wakuwaku Hamburger, (ARC)
- Marvel Contest Of Champions, (ARC)
- Fighting EX Layer, (ARC)
- Beat Mania IIDX 26: Rootage, (ARC)
- Beat Mania IIDX 25 Cannon Ballers, (ARC)
- Skycurser, (ARC)
- Nostalgia, (ARC)
- Wangan Midnight Maximum Tune 5DX Plus, (ARC)
Popular Games
- Pokemon Tretta, (ARC)
- Silver Strike Bowling, (ARC)
- Pinball Action, (ARC)
- Neo Bomberman, (ARC)
- Golden Tee Golf, (ARC)
- Wangan Midnight Maximum Tune 5, (ARC)
- Jojo's Bizarre Adventure, (ARC)
- Miss World '96 Nude, (ARC)
- Mappy, (ARC)


text:
Because the cause of inflammatory bowel disease is unknown, there are currently no guidelines for reducing your risk of inflammatory bowel disease.
But, some evidence does suggest that eating a diet high in fiber and fruits may lower your risk of Crohn's disease. And a diet high in vegetables may lower your risk of ulcerative colitis.
As our understanding of the disease grows, your doctor may have more information regarding steps for reducing your risk of inflammatory bowel disease.
Revision Information
- Reviewer: EBSCO Medical Review BoardDaus Mahnke, MD
- Review Date: 09/2018 -
- Update Date: 09/17/2014 -


text:
Asset Efficiency Optimization (AEO)
Implementing AEO effectively requires being able to ask and answer the following five questions routinely, accurately, at the same time, and across your unique organization:
- What must I do?
- Why must I do it?
- Who must do it, when?
- How must I do it?
- What must I do next time?
The Asset Efficiency Optimization methodology combines a broad range of strategic and tactical tools to help you answer these questions to achieve maximum effectiveness and efficiency to reduce your Total Cost of Ownership (TCO).
SKF will work with you to define areas of focus in order to get the fastest return on your investment. Your customized AEO programme can include everything from training and logistics, to a full predictive maintenance (PdM) service contract with qualified manpower and technology to help maintain your plant – even remotely.
SKF expertise in machinery maintenance and operational efficiency can help you reduce your energy usage and improve the sustainability footprint of your plant.


text:
It is good that you are actively thinking about what steps you can take to prevent history from repeating itself. Although cardiovascular disease (CVD)—the number one killer and a leading cause of premature, permanent disability in the US—may be more common in families with a positive family history of CVD, the outlook is far from hopeless.
Scientists have established that several risk factors—both modifiable (such as diet, physical activity level, and tobacco use) and nonmodifiable (such as age and genetics)—play a role in the development of CVD. Moreover, scientists are not even sure if the increased risk of developing CVD in someone with a family history of the disease is solely a result of a shared genetic predisposition or if it simply represents a greater exposure to the same harmful environmental influences.
Genetics and Cardiovascular Risk
The Human Genome Project was completed in 2003. The project was a scientific undertaking to identify all the genes in human DNA. It was done to assess specific genes to determine individual disease risk. Examples of genetic influences on cardiovascular risk that researchers studied included the following:
- Genes that appear to predispose a person to congenital heart disease (defects present at birth)
- Apolipoproteins B and E, which are proteins that combine with a lipid that affect blood cholesterol concentrations
- The angiotensinogen gene variant, an alteration in the hormone angiotensinogen, which is associated with high blood pressure
- Homocysteine, an amino acid which contributes to atherosclerosis by irritating vascular endothelial cells lining the blood vessels
- C-reactive protein, a protein that is a marker of inflammation and may predict future cardiovascular risk
However, while genetic and protein markers may identify enhanced CVD risk (and would allow for targeted prevention) further confirmation is required before widespread clinical use is appropriate.
What is known is that CVD occurs more commonly in families with a positive family history of the condition. This means that your risk of CVD is increased if any of your immediate relatives, such as siblings, parents, or children, have or had heart disease, a heart attack, or stroke, especially before age 50.
How Knowing Your Family History Can Help
Research clearly demonstrates that family history of CVD is an independent predictor of disease. One study looking at CVD in families in Utah found that while only 14% of families had a strong positive family history of coronary artery disease (CAD), these same people accounted for 72% of all CAD events, such as heart attack and coronary bypass surgery.
And, while only 11% of families had a positive family history of stroke, 86% of all early strokes occurred in these families. Since major cardiovascular risks (such as smoking and excessive alcohol consumption) may be less prevalent in Utah than in other states, these results may not apply throughout the country.
Nonetheless, because family members share not only the same positive family history, but also other modifiable risk factors, family history can help doctors capture the underlying complexities of both genetic and environmental influences leading to the appearance of disease.
Perhaps most important, people at risk for CVD because of their genetic makeup can benefit from modifying their behavior. For instance, quitting smoking is projected to decrease CAD to a greater extent in men with a positive family history of CAD compared to men without a positive family history.
Thus, family history is an important tool used by doctors to evaluate the risk of CVD.
What to Do If You Think You Might Be at Risk
In the future, as the genetic basis of CVD is unraveled, doctors may be able to diagnose disease based on tests for genetic markers.
In the meantime, while a family history of CVD does not doom you to the same fate, you are at a higher risk. Therefore, modifying certain risk factors for CVD, may help you reduce your risk of disease. These modifiable risk factors include the following:
- Quitting smoking—the single, most important risk factor that you can change
- Reducing the total fat, trans fat, and saturated fat in your diet
- Increasing fiber in your diet
- Controlling your blood pressure
- Controlling diabetes
- Exercising regularly—aim for at least 30 minutes per day on most days of the week
- Maintaining an ideal body weight
- Managing your stress
- Moderating your alcohol intake—1 or less drinks per day for women, 2 or less drinks per day for men
- Controlling cholesterol—lowering total cholesterol, LDL, and triglyceride levels while elevating HDL levels
Some doctors may also recommend taking aspirin daily or other medications. Talk to your doctor to find out if this is suitable for you.
Remember, prevention is key. Keep in mind, too, that if you have a family history of CVD, your children are at an increased risk as well. But you can set them on the right path to a healthful lifestyle. Children learn from example. So, if they see you eating right, not smoking, and getting plenty of exercise, they will be more likely to follow your lead.
- Reviewer: Michael Woods, MD, FAAP
- Review Date: 02/2017 -
- Update Date: 03/06/2015 -


text:
You have no items in your shopping cart.
Currently Shopping by:
Oolong tea comes from China and is transcribed from two words meaning "black" and "dragon". It goes through a semi-oxidization process that ranges from 1% - 99%. Shortly after picking, the leaves are withered and semi-oxidized in the sun then shade dried. The leaves are then basket-tossed to break down their surface cells and wok fired, halting the oxidization process. To learn more about oolong tea click here


text:
If you want to download the video, click the download button and download up to 720p quality (if available).
Watch Pattaya Babe In Medeval Punishment. AsianSex10.com free asian porn you want in every porn category. Asian sex video it is here.
Every day 5 new videos, we select the videos manually to maintain the maximum quality possible. We embed new videos from sites like Pornhub, we have a category with exclusive Asian sex videos, where we search for videos from forums that provide download links.


text:
This page conforms to the XHTML standard and uses style sheets. If your browser doesn't support these, you may not see the page as designed, but all the text is still accessible to you.
Bringing the heritage of Schenectady County, New York to the world since 1996russian hair lace wigshuman wig hair but no part in front of wig black ladies
You are here: Home » Cemeteries
If you have any suggestions for sites to add to this page, please let us know.
Go to top of page
You are here: bob wig with bangs makeup » Cemeteries
http://www.schenectadyhistory.org/cemeteries/index.html updated March 30, 2015
Copyright 2015 Schenectady Digital History Archive — a service of the Schenectady County Public Librarychild's cleopatra wig


text:
Tourette syndrome (TS) is a chronic disorder of the nervous system. It is a type of tic disorder that includes both motor and vocal tics. These tics are rapid, involuntary movements or sounds that occur repeatedly.
Many people with TS also have one or more of the following problems:
- Obsessions
- Compulsions and ritualistic behaviors
- Attention deficit disorder with or without hyperactivity (ADD or ADHD)
- Learning disabilities
- Difficulties with impulse control
- Sleep disorders
The exact cause of TS is unknown. However, brain chemicals called dopamine and serotonin are most likely involved.
There may be a genetic link to TS, although some have no known family history.
Risk Factors
Males are 3-4 times more likely to be affected. Other factors that may increase your chance of TS include:
- Family history of TS
- Having other tic disorders
- Obsessive-compulsive disorder
- Maternal stress during pregnancy
- Daily use of coffee, cigarettes, and alcohol by the mother before pregnancy
Tics are the main symptoms of TS. To be TS, the tics must be involuntary and:
- Both motor and vocal tics
- Be present for more than 1 year
- Start before age 18
- Not absent at any time for more than 3 months
- Not be due to a physiological cause like substances or a medical condition
Tics will usually happen daily, range from mild-to-severe, and change in type over time. They can occur suddenly and vary in the amount of time that they last. Tics may temporarily decrease with concentration or distraction. During times of stress and tension, they may occur more often.
Tics are divided into motor and vocal. The following are some common examples:
Motor tics
- Simple—eye blinking, head jerking, arm or shoulder shrugging
- Complex—jumping, smelling, touching things or other people, twirling around
Vocal tics
- Simple—throat clearing, coughing, sniffing, grunting, yelping, barking
- Complex—saying words or phrases that do not make sense in a given situation, saying obscene or socially unacceptable words—called coprolalia
Tics may occur throughout life, but symptoms may improve during later teen years.
You will be asked about your symptoms and medical history. A physical exam will be done.
The diagnosis of TS is usually made by the symptoms alone. Your doctor may order tests to rule out other medical conditions as the cause of the tics.
Talk with your doctor about the best treatment plan for you. Education and therapy are usually parts of the treatment plan. In some cases, medications may be needed.
Education and Therapy
Learning about TS is a very important part of treatment. Education can also be helpful for your family, friends, and coworkers.
Therapy can also help you develop habits to help manage tics or other related symptoms. Types of therapy include:
- Behavior therapy can help people with TS learn to substitute their tics with other movements or sounds that are more acceptable.
- Cognitive behavioral therapy can help reduce obsessive-compulsive symptoms.
- Psychotherapy can help people with TS and their families cope with the disorder.
In addition, relaxation, biofeedback, and exercise can help to reduce stress.
Medication is not required in most cases. No medication works in all people with TS. If a doctor prescribes medication, there are usually strong side effects.
Medications that may be prescribed include:
- Clonidine—usually the first medication tried to control tics, but may not be effective
- Antipsychotics—to help control tics
- Antidepressants—to manage related obsessive-compulsive habits
- Stimulants or medication used to treat high blood pressure—to manage symptoms related to ADD and ADHD
Revision Information
- Reviewer: EBSCO Medical Review Board Rimas Lukas, MD
- Review Date: 03/2018 -
- Update Date: 05/06/2014 -


text:
Ideological and political study guide third year of full-time regular senior high school textbooks (the trial) a full one (with handwriting)(Chinese Edition)(Old-Used)
Libreria AbeBooks dal 7 aprile 2009Quantità: 1
Foto dell'editore
Libreria AbeBooks dal 7 aprile 2009Quantità: 1
Riguardo questo articolo
Dati bibliografici
Titolo: Ideological and political study guide third ...
Legatura: paperback
Condizione libro: Good
Descrizione libreria
Visita la pagina della libreria
We guarantee the condition of every book as it's described on the Abebooks web sites. If you're dissatisfied with your purchase (Incorrect Book/Not as Described/Damaged) or if the order hasn't arrived, you're eligible for a refund within 30 days of the estimated delivery date. If you've changed your mind about a book that you've ordered, please use the Ask bookseller a question link to contact us and we'll respond within 2 business days. Please Note:We don't sell any international Edition to you...Ulteriori informazioni
Most orders are shipped within 24 hours. We will delivery these items to you by AIRMAIL, EUB, EMS, TNT etc.
Metodi di pagamento
accettati dalla libreria
PayPal Bonifico bancario


text: Wednesday, August 29, 2012 New Podcast: Introduction to the Therapy Cap Manual Medical Review Process A new APTA podcast and transcript provide an overview of the manual medical review process for Medicare claims for beneficiaries who reach $3,700 in outpatient therapy expenditures in a calendar year. Under the new therapy cap exceptions process, outpatient therapy patients will still be eligible for an automatic exception at the 2012 therapy cap level of $1,880. Therapists will follow the same process of applying the KX modifier on the claim form when a patient exceeds the cap amount. Claims for patients who then meet or exceed $3,700 in therapy expenditures will be subject to a manual medical review process that will be implemented in 3 distinct phases beginning October 1, November 1, and December 1. (See last week's News Now article for more information about provider assignment to the phases.) Additional information regarding the therapy cap and the manual medical review process is available on APTA's website. CMS also provides a fact sheet and question-and-answer document regarding the process. Next week, APTA will record a webinar that will address the therapy cap and the manual medical review process. News Now will provide a link to the recording, which will be free to members, when it is available.


text:
We're sorry, no medication results were found.
DISCLAIMER: This Health Library is for educational purposes only and does not necessarily reflect the services provided by this practice/facility.
Medication Information
The information contained in this tool is intended as an educational aid only. It is not intended as medical advice for individual conditions or treatment. It is not a substitute for a medical exam, nor does it replace the need for services provided by medical professionals. Talk to your doctor, nurse or pharmacist before taking any prescription or over the counter drugs (including any herbal medicines or supplements) or following any treatment or regimen. Only your doctor, nurse, or pharmacist can provide you with advice on what is safe and effective for you.
The use of this tool is at your sole risk. These products are provided "AS IS" and "as available" for use, without warranties of any kind, either expressed or implied. HCA makes no representation of warranty as to the accuracy, reliability, timeliness, usefulness or completeness of any of the information contained in the products. Additionally, HCA makes no representation or warranties as to the opinions or other service or data you may access, download or use as a result of use of this tool. ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE OR USE ARE HEREBY EXCLUDED. HCA does not assume any responsibility or risk for your use of this tool.
By searching using the form below, you hereby agree to the above conditions.
If you are not certain how to spell the term, try using the first few letters to get a list of possible matches. (i.e. as for Aspirin)


text:
Our fulfillment center is operational and we are still here to serve your collecting needs! The Dave & Adam's sales team is working remotely from home to get your orders processed and shipped out in a timely manner.
We sincerely thank you for your business!
Please note, while Sean & DC are set up at their homes to conduct group breaks we will not be conducting personal breaks for the time being. We appreciate your patience and look forward to seeing you in some breaks!
Stay indoors & stay safe!
Dave & Adam's
2011/12 Upper Deck SPx #189 Adam Henrique RC Jersey Autograph /799
Please note that the image shown is a stock photo. The card you receive may vary from the image shown if we have more than one in stock.
Sorry, it looks like your browser doesn't have cookies enabled. Dave & Adam's only uses cookies to keep track of your shopping cart while you browse dacardworld.com. Please enable cookies to further enjoy your shopping experience. If you have cookies enabled, please refresh your browser.


text:
The headphones as shown in pictures are not included.
MAS002 Studio Gaming Headphone Headset Holder / Wall Mount / Hanger
|Manufacturer Part No:
|Product Type:
|Product Family:
|Shipping Weight:
|0.259 kg
|PB Part No:
|Product Model:
|12 months local warranty *
* Warranty period is as stated above unless the manufacturer has chosen to specify a longer period.
All warranties are return to base unless otherwise specified.
This headphone hook is sturdy, discreet, well sized and comes with no clutter or extra rubbish packed in with it. Just a great hook This headphone hook is sturdy, discreet, well sized and comes with no clutter or extra rubbish packed in with it. Just a great hook
The headphones as shown in pictures are not included.
MAS002 Studio Gaming Headphone Headset Holder / Wall Mount / Hanger
"We have had an ongoing issue with a nanostation that started with a lost password over a year..."
"I recently purchased an ex-lease refurbished Dell laptop from PB Tech: ..."
"I would like to recommend the service center team in NS branch from Auckland for their..."
"As the General Manager of Rugged Phone Store Australia and Rugged Phones NZ, I highly recommend..."
"I love PBTech and have been shopping with them since the first store opened in 1993 Auckland,..."
"Brought a Brother Laser Printer that advertised on the Brother website that the printer could..."
"Recently purchased a wifi extender (WO1847316). This was very easy to install and has..."
"My tech savvy son in law recommended PBTech to me some time ago, and I've never been..."
"PB Tech has been great over the past few years I have been using them. Their service is second..."
Copyright © PB Technologies Ltd All rights reserved. 587 Great South Road, Manukau, Auckland, New Zealand
PB Technologies Ltd is not responsible for typographical errors. All prices and specifications are subject to change without notice.
The estimated time to ship for each product we sell is detailed on the individual product page just underneath the price. From when your items ship, products typically arrive within 1 working day for North Island deliveries and 2 working days for South Island deliveries. Rural deliveries may take an extra working day, and bulk deliveries may take an extra 2-4 working days.
Need your order in a hurry? PB Tech offers same day delivery for the Auckland region. Simple place your order before 2pm (provided your items are in stock) and select one of our same day delivery options 'Evening Delivery' or 'Urgent 3-hour Delivery' in the checkout. T&C's apply. Learn more about Same Day Delivery.
Shipping costs vary based on your location and the items being shipped and in some cases shipping may even be FREE.
To calculate what the shipping costs will be for your order, add the items you are interested in to your cart, view the Shopping Cart page, and select your 'Delivery Area' to calculate the shipping cost.
All orders shipped by PB Tech are sent via a courier with a signature required for each delivery. In some cases, and only where you have given the courier company permission to leave orders at a designated location, your order may be delivered without requiring a signature. All orders sent by PB Tech are fully insured in the unlikely event that your item(s) are damaged or go missing in transit.
You can pick-up your online order from any of our branches nationwide. You can select which branch you want to pick up from the checkout. Please note that if the branch you want to pick up from doesn't have stock of one or more of the items in your order, it may take 3-4 working days to transfer the stock to the branch so your order can be fulfilled.
PB Tech regularly ships overseas to Australia and beyond. If you are located in Australia, you can order directly from our Australian site www.pbtech.com/au. If you are from another country you can order from www.pbtech.com
PB Tech holds a significant amount of stock in our New Zealand based logistics centre and can ship stock from this location usually within 2-4 working days (see the timeframes mentioned on each product page for more accurate delivery estimates).
In most cases, items ordered from the NZ Logistics Centre are first transferred to our Head Office / Distribution Centre before being shipped to the final destination.
Unfortunately no pick-up options are available directly from this location, you can select a pick up from one of our branches however and we will transfer your order there so you can pick up.
Products marked as 'In stock with Supplier' are shipped from one of our suppliers / vendors. The time frame for shipments can vary so please refer to the shipping time frames mentioned on each product page for more accurate delivery estimates.
In most cases, items ordered from suppliers are first transferred to our Head Office / Distribution Centre before being shipped to the final destination.
If you change your mind after making a purchase, or realise you have ordered the incorrect item, you can enjoy the peace of mind that we offer a 7 day exchange policy.
To exchange a product, goods must be sealed / unopened, with packaging in original condition, and accompanied by a valid receipt dated no more than 7 calendar days from when you request an exchange.
If there is not a suitable product that can be exchanged for your returned item you will be offered a credit on your account or gift card based on the value paid at the time of purchase.
Please note, items purchased on finance cannot be exchanged for a gift card.
If your product develops a fault within the manufacturer warranty period, you can either contact the manufacturer directly (some manufacturers provide a high level of warranty service - including free pickup or in some cases onsite repair), or return to one of our services centres / stores. Where the product has been directly imported by PB Tech, you need to contact us directly or present the product at any one of our service centres / stores together with your proof of purchase.
If your product develops a fault outside of the manufacturer warranty or PB Tech warranty period, we offer a full repair service and are an authorised repair agent for leading brands such as Samsung, HP, Toshiba, Lenovo and more.
To contact the manufacturer directly to troubleshoot your product or to request a warranty repair, please view the list of manufacturer / brand warranty contacts (for products imported directly by PB Tech please return to us directly by completing our request a return form).
To return a product to PB Tech directly, please complete our request a return form.
Or view our returns policy for more information.


text:
With the Senate rejecting Thursday both the last-minute Democratic and Republican proposals, the $85 billion in sequester cuts kicked in on Friday. President Barack Obama stated Thursday that the Senate, by failing to accept either measure, "voted to let the entire burden of deficit reduction fall squarely on the middle class."
"Republicans in the Senate faced a choice about how to grow our economy and reduce our deficit," Obama said. "And instead of closing a single tax loophole that benefits the well-off and well-connected, they chose to cut vital services for children, seniors, our men and women in uniform and their families."
While $85 billion in cuts will take effect in the remaining seven months of this fiscal year, the across-the-board reductions will total $1.2 trillion over nine years.
Obama said that he planned to meet Friday with leaders from both parties "to discuss a path forward." As a nation, he said, "we can't keep lurching from one manufactured crisis to another. Middle-class families can't keep paying the price for dysfunction in Washington. We can build on the over $2.5 trillion in deficit reduction we've already achieved, but doing so will require Republicans to compromise. That's how our democracy works, and that's what the American people deserve."
What happens now and in the months to come? According to The Wall Street Journal, the timeline for cuts and other measures will look like this:
- March 1: The White House is expected to alert agencies their budgets have been cut. Agencies will begin notifying employees, contractors and states that spending will contract over the next seven months.
- Early to mid-March: Furlough notices will begin being sent by agencies to many of their employees, warning that unpaid leave could begin in 30 more days.
- March 27: Unrelated to the sequester, funding for some federal programs and agencies expires. If an agreement isn't reached, a partial government shutdown could ensue.
- Early to mid-April: If a shutdown is averted, many agencies will begin unpaid leave for employees, typically one day per week or one day every other week. The cuts' impact may become more visible, possibly affecting places like airports.
- Sept. 30: The federal budget year ends, meaning the cuts have to be accounted for by this time.
- Oct. 1: The next federal budget year begins, triggering a second year of sequester cuts.
Joe Lieber of Washington Analysis says that Congress will most likely wait until after the March 27 deadline for extending the continuing resolution (CR) now funding the government before returning to address the sequester. "Disagreement over how to 'pay for' a delay—with tax increases, spending cuts or some combination of the two—will continue to forestall a near-term agreement," he said.
Lieber says to brace for "mass furloughs" beginning in April. The mass furloughs will pressure Congress "to reach agreement on how to delay the policy once again," Lieber says. "While this will likely occur sometime after Congress addresses the CR, just when that takes place depends on how acutely the impact is felt."
Having made little progress in coming up with the requisite $1.2 trillion in offsets for a wholesale cancellation of the sequester, Congress will settle "upon another short-term, stopgap measure," Lieber predicts. "Such delays could very well become the new normal as this year's highly partisan Congress continues to clash over fundamental differences on tax and spending policy. Investors should expect ongoing uncertainty and budget constraints as Congress chips away at the sequester it created for itself a year and half ago."


text:
About us
Beetroot Books was set up as a shoestring indy to promote those few writers and independent publishers who have something both positive and useful to say. Of course, we're committed to the common sense principles of diversity over homogeneity, freedom of expression and care and reverence for people and our planet, but we also think that small is sometimes better. We know everyone we sell and we only sell what we care about.
Beetroot, it's not for everyone – unless you like it earthy, tasty and natural.
Thanks for your support