Jorge Martinez de Salinas

I’ll be using my Gmail account to send mail. The first step is to configure the local Postfix server as a relay. Edit /etc/postfix/main.cf:

sudo vim /etc/postfix/main.cf

Search for a “relayhost=” line and add the following after it:

relayhost = smtp.gmail.com:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_sasl_local_domain = yourdomain.com
#smtpd_sasl_application_name = smtpd
broken_sasl_auth_clients = yes
smtpd_pw_server_security_options = noanonymous
smtp_use_tls=yes
smtp_tls_security_level=encrypt
tls_random_source=dev:/dev/urandom

Next create /etc/postfix/sasl_passwd and add the following (replace username and password accordingly):

smtp.gmail.com:587 username@gmail.com:password

Next run the following commands:

$ sudo postmap hash:/etc/postfix/sasl_passwd
$ sudo chown root:wheel /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
$ sudo chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

You should be able to send mail from the command line now:

$ mail -s "Test" username@domain.com

You can check mail’s log file at /var/log/mail.log

To be able to send attachments from the command line (true attachments that graphical mail clients understand) install mutt:

$ curl -O ftp://ftp.mutt.org/mutt/devel/mutt-1.5.20.tar.gz
$ tar xfzvv mutt-1.5.20.tar.gz 
$ cd mutt-1.5.20/
$ ./configure
$ make
$ sudo make install

To send attachments use the following command:

echo "text body" | mutt -s "subject" -a file.dat -- username@domain.com

Or even better:

for i in {1..1000}; do echo "text body" | mutt -s "subject" -a file.dat -- username@domain.com; done

Happy mailing!

Have you ever been curious about the first registered domain name? Well, it was symbolics.com.

First upload your public key to the server you want to log in:

scp .ssh/id_rsa.pub user@1.2.3.4:/home/user

On the server, add the public key file to the authorized_keys file:

cat id_rsa.pub >> .ssh/authorized_keys

Now you can login using public key authentication and you don’t have to enter a password anymore.

To find which servers handle mail for a particular domain use dig:

# dig google.com MX

;; QUESTION SECTION:
;google.com.			IN	MX
 
;; ANSWER SECTION:
google.com.		561	IN	MX	100 google.com.s9a1.psmtp.com.
google.com.		561	IN	MX	100 google.com.s9a2.psmtp.com.
google.com.		561	IN	MX	10 smtp1.google.com.
google.com.		561	IN	MX	10 smtp2.google.com.
google.com.		561	IN	MX	10 smtp3.google.com.
google.com.		561	IN	MX	10 smtp4.google.com.

To start the video streaming execute:

# vlc -v -I rc movie.avi --sout "#standard{access=http,mux=ogg,dst=npserver.labplan.southpark:8080)

Since we’re using the remote control interface (-I rc), we don’t need a graphical environment. This feature is specially useful if we want to stream the video without starting an X Window session.

On the client side execute the following command to receive the stream:

# vlc http://npserver.labplan.southpark:8080

If the DNS server isn’t installed on your Linux box, install it with the following command:

yum groupinstall "DNS Name Server"

We need to configure two things. First we need to specify the domains we’re going to resolve in named.conf. We will resolve the labplan.southpark domain.
Our DNS server will support both direct (name->ip) and reverse (ip->name) resolution.

According to APNIC the use of ip6.int is deprecated in favor of ip6.arpa for
reverse resolutions. However, since many programs still use it, we’re going to define
the ip6.int version as well. We need to add the following lines to named.conf:

zone "labplan.southpark" IN {
type master;
file "labplan.southpark.zone";
};
//deprecated
zone "0.0.0.0.0.0.0.0.0.0.0.0.1.c.e.f.ip6.int" {
type master;
file"reverse-fec1_64i.IP6.INT";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.1.c.e.f.ip6.arpa" {
type master;
file "reverse-fec1_64.IP6.ARPA";
};

Next we have to fill the zone records. The information for direct resolutions is stored on labplan.southpark.zone:

$TTL    86400
@               IN SOA  @       root (
		42              ; serial (d. adams)
		3H              ; refresh
		15M             ; retry
		1W              ; expiry
		1D )            ; minimum
 
          IN NS           ns6.labplan.southpark.
 
 
ns6		 IN      AAAA    fec0::20c:29ff:fe8f:8f16
customer	 IN      AAAA    fec0::20c:29ff:feff:4b37
npserver	 IN      AAAA    fec0::20c:29ff:fe4a:fae0
an		 IN      AAAA    fec0::20c:29ff:feb4:bee2

The PTR records used for reverse resolution are stored on reverse-fec1_64i.IP6.INT (deprecated ip6.int) and reverse-fec1_64.IP6.ARPA (recommended ip6.arpa). This is the ip6.arpa zone (to edit an ip6.int zone just replace arpa with int):

$TTL 3d ; Default TTL 
@       IN SOA 0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. root (
                200906170       ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL 
)
                                IN     NS     ns6.labplan.southpark.
7.3.b.4.f.f.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.   IN PTR costumer.labplan.southpark.
0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.   IN PTR npserver.labplan.southpark.
2.e.e.b.4.b.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR an.labplan.southpark.
6.1.f.8.f.8.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR gw.labplan.southpark.
6.1.f.8.f.8.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR ns6.labplan.southpark.

From this moment on everything should work fine. We can check the name resolution with dig:

# dig @::1 -t AAAA npserver.labplan.southpark
;; QUESTION SECTION:
;npserver.labplan.southpark.    IN      AAAA
 
;; ANSWER SECTION:
npserver.labplan.southpark. 86400 IN    AAAA    fec0::20c:29ff:fe4a:fae0

To check reverse resolution use dig’s -x flag:

#dig @::1 -x fec0::20c:29ff:fe4a:fae0
;; QUESTION SECTION:
;0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.INPTR
 
;; ANSWER SECTION:
0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. 259200  IN  PTR  npserver.labplan.southpark.

IPv6 has three types of addresses, which can be categorized by type and scope:

• Unicast addresses. A packet is delivered to one interface.
• Multicast addresses. A packet is delivered to multiple interfaces.
• Anycast addresses. A packet is delivered to the nearest of multiple interfaces (in terms of routing distance).

IPv6 does not use broadcast messages.

Unicast and anycast addresses in IPv6 have the following scopes (for multicast addresses, the scope is built into the address structure):

• Link-local. The scope is the local link (nodes on the same subnet)(FE80::/64).
• Site-local. The scope is the organization (private site addressing)(FEC0::/48).
• Global. The scope is global (IPv6 Internet addresses).

In addition, IPv6 has special addresses such as the loopback address. The scope of a special address depends on the type of special address. Much of the IPv6 address space is unassigned.

One of the most interesting and potentially valuable addressing features imple- mented in IPv6 is a facility to allow devices on an IPv6 to actually configure themselves independently. In IPv4 hosts were originally configured manually. Later, host configuration protocols like DHCP enabled servers to allocate IP addresses to hosts that joined the network. IPv6 takes this a step further, by defining a method for some devices to automatically configure their IP address and other parameters without the need for a server. It also defines a method whereby the IP addresses on a network can be renumbered (changed en masse). These are the sorts of features that make TCP/IP network administrators drool.

The IPv6 autoconfiguration and renumbering feature is defined in RFC 2462, IPv6 Stateless Address Autoconfiguration. The word “stateless” contrasts this method to the server-based method using something like DHCPv6, which is called “stateful”. This method is called “stateless” because it begins from a “dead start” with no information (or “state”) at all for the host to work with, and has no need for a DHCP server.

Stateless autoconfiguration exploits several other new features in IPv6, including link-local addresses, multicasting, the Neighbor Discovery (ND) protocol, and the ability to generate the interface identifier of an address from the underlying data link layer address. The general idea is to have a device generate a temporary address until it can determine the characteristics of the network it is on, and then create a permanent address it can use based on that information. In the case of multi-homed devices, autoconfiguration is performed for each interface separately, as you would expect.

The following is a summary of the steps a device takes when using stateless autoconfiguration:

1. Link-Local Address Generation: The device generates a link-local address. Recall that this is one of the two types of local-use IPv6 addresses. Link- local addresses have “1111 1110 10” for the first ten bits. The generated address uses those ten bits followed by 54 zeroes and then the 64 bit interface identifier. Typically this will be derived from the data link layer (MAC) address as explained in the topic on interface identifiers, or it may be a “token” generated in some other manner.
2. Link-Local Address Uniqueness Test: The node tests to ensure that the address it generated isn’t for some reason already in use on the local network. (This is very unlikely to be an issue if the link-local address came from a MAC address but more likely if it was based on a generated token.) It sends a Neighbor Solicitation message using the Neighbor Discovery (ND) protocol. It then listens for a Neighbor Advertisement in response that indicates that another device is already using its link-local address; if so, either a new address must be generated, or autoconfiguration fails and another method must be employed.
3. Link-Local Address Assignment: Assuming the uniqueness test passes, the device assigns the link-local address to its IP interface. This address can be used for communication on the local network, but not on the wider Internet (since link-local addresses are not routed).
4. Router Contact: The node next attempts to contact a local router for more information on continuing the configuration. This is done either by listening for Router Advertisement messages sent periodically by routers, or by sending a specific Router Solicitation to ask a router for information on what to do next. This process is described in the section on the IPv6 Neighbor Discovery protocol.
5. Router Direction: The router provides direction to the node on how to proceed with the autoconfiguration. It may tell the node that on this network “stateful” autoconfiguration is in use, and tell it the address of a DHCP server to use. Alternately, it will tell the host how to determine its global Internet address.
6. Global Address Configuration: Assuming that stateless autoconfiguration is in use on the network, the host will configure itself with its globally-unique Internet address. This address is generally formed from a network prefix provided to the host by the router, combined with the device’s identifier as generated in the first step. Clearly, this method has numerous advantages over both manual and server-based configuration. It is particularly helpful in supporting mobility of IP devices, as they can move to new networks and get a valid address without any knowledge of local servers or network prefixes. At the same time, it still allows management of IP addresses using the (IPv6- compatible) version of DHCP if that is desired. Routers on the local network will typically tell hosts which type of autoconfiguration is supported using special flags in ICMPv6 Router Advertisement messages.

IEEE 802.1X provides authentication and authorization capabilities for WiFi and Ethernet networks. This article covers how to set up IEEE 802.1X authentication for Ethernet networks on Linux. For more articles see articles section.

To enable IPv6 routing on your Linux box you can use the following command:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

If you want to keep IPv6 routing enabled permanently, edit /etc/sysctl.conf and add the following line:

net.ipv6.conf.all.forwarding=1

Remember that IPv6 filtering rules are controlled via ip6tables.

Backing up your data is very recommendable (if you don’t do it start now!) and can save you a few headaches. This posts explains how to backup your Wordpress installation. You need to take care of 2 things:

• The Wordpress database
• The Wordpress files (plugins, themes, etc.).

For backing up the database I recommend the wp-db-backup plugin, which can be configured to send a daily backup of your database to your mail account.

If for any reason you lose your Wordpress data, you can retrieve the backup from your mail and restore it with the following command:

mysql --default_character_set=utf8 -h hostname -u username -p database < mybackup.sql

You can obtain the host, username and database name from wp-config.php. The encoding is important. If you don’t specify it your restored posts can look pretty messy.

Following the previous steps your posts and configurations are protected and chances of losing them are very low. The next step is to backup the Wordpress files (plugins, themes, config files, etc.). To perform this task I recommend rsync. This excellent tool is included on Unix-based systems (Linux, Mac, etc.). There are binaries for Windows also. Rsync performs folder synchronization (bot remotely and locally). One of its main advantages is that it does incremental backups (i.e. it only transfers the changed files). I use rsync to synchronize my remote Wordpress installation with a local folder. This way, every time something changes in the server, these changes are transferred to my local computer. The rsync syntax is as follows:

rsync -avvb --delete --backup-dir=/Users/jorge/rsync/backup_$(date +%y%m%d%H%M) username@somebox.bluehost.com:/home4/username/public_html /Users/username/bluehostbackup/

It’s a good idea to schedule a cron job to run that command daily (or hourly if you change things quite often).

And that’s it. Making use of wp-db-backup and rsync you get an easy and fast backup solution that can save you a lot of trouble.