Understanding DNSBL Filtering
A DNSBL (commonly known as a ‘Blocklist”) is a database that is queried in realtime by Internet mail servers for the purpose of obtaining an opinion on the origin of incoming email. The role of a DNSBL such as Spamhaus’ SBL/XBL/PBL Advisory system is to provide an opinion, to anyone who asks, on whether a particular IP Address meets Spamhaus’ own policy for acceptance of inbound email.
The policy of the Receiver governs whether a message is blocked or not
Every Internet network that chooses to implement spam filtering is, by doing so, making a policy decision governing acceptance and handling of inbound email. The Receiver unilaterally makes the choices on whether to use DNSBLs, which DNSBLs to use, and what to do with an incoming email if the email message’s originating IP Address is “listed” on the DNSBL. The DNSBL itself, like all spam filters, can only answer whether a condition has been met or not.
Name-Based VirtualHosts and SSL
As a rule, it is impossible to host more than one SSL virtual host on the same IP address and port. This is because Apache needs to know the name of the host in order to choose the correct certificate to setup the encryption layer. But the name of the host being requested is contained only in the HTTP request headers, which are part of the encrypted content. It is therefore not available until after the encryption is already negotiated. This means that the correct certificate cannot be selected, and clients will receive certificate mismatch warnings and be vulnerable to man-in-the-middle attacks.
In reality, Apache will allow you to configure name-based SSL virtual hosts, but it will always use the configuration from the first-listed virtual host (on the selected IP address and port) to setup the encryption layer. In certain specific circumstances, it is acceptable to use a single SSL configuration for several virtual hosts. In particular, this will work if the SSL certificate applies to all the virtual hosts. For example, this will work if:
All the VirtualHosts are within the same domain, eg: one.example.com and two.example.com.
You have a wildcard SSL certificate for that domain (one where the Common Name begins with an asterix: i.e *.example.com)
Renaming a Volume Group
Use the vgrename command to rename an existing volume group.
Either of the following commands renames the existing volume group vg02 to my_volume_group
# vgrename /dev/vg02 /dev/my_volume_group
or
# vgrename vg02 my_volume_group
Backing Up Volume Group Metadata
Metadata backups and archives are automatically created on every volume group and logical volume configuration change unless disabled in the lvm.conf file. By default, the metadata backup is stored in the /etc/lvm/backup file and the metadata archives are stored in the /etc/lvm/archives file.
You can manually back up the metadata to the /etc/lvm/backup file with the vgcfgbackupcommand.
The vgcfrestore command restores the metadata of a volume group from the archive to all the physical volumes in the volume groups.
Splitting a Volume Group
To split the physical volumes of a volume group and create a new volume group, use the vgsplit command.
Logical volumes cannot be split between volume groups. Each existing logical volume must be entirely on the physical volumes forming either the old or the new volume group. If necessary, however, you can use the pvmove command to force the split.
The following example splits off the new volume group vgsmall from the original volume group vgbig.
vgsplit bigvg vgsmall /dev/disk1
Volume group “vgsmall” successfully split from “vgbig”
