BSD

cron Howto

(20170327 — The steps in this post were amended to address changes in recent versions of software — iceflatline)

cron is a time-based job scheduler in BSD, Linux and other Unix-like operating systems. It is commonly used to schedule system maintenance or administrative tasks, however it can also be used by system users to schedule their own tasks.

Tasks scheduled to run from cron are typically referred to as “cron jobs.” A “crontab” (cron table) is a configuration file which contains one or more “cron job” entries (i.e., commands and/or scripts to be run at specified dates and/or times.

This post will discuss the use of cron in FreeBSD and Ubuntu server, including the location of cron-related files. The software versions used in this post were as follows:

  • FreeBSD 11.0 RELEASE
  • Ubuntu 16.04.2 LTS

Using cron

There are several different ways to use cron. In the /etc directory in many Linux distributions, for example, you’ll likely find some sub-directories called cron.hourly, cron.daily, cron.weekly, and cron.monthly. If you place a command into one of those directories it will be run hourly, daily, weekly or monthly, respectively. If you require more granularity, you can add cron job entires directly to the system-wide crontab file /etc/crontab. Editing this file directly however is usually discourage as it can be overwritten when the system is upgraded.

A second type of system-wide crontab can often be found in /etc/cron.d/. Within this directory are small named crontabs. The directory is often used by packages, however system users can also place a file here containing cron jobs. The file must share the same name as the user so that the system knows which user is to be associated with the commands contained within it.

Perhaps a better solution though is to create your own crontab. User crontabs allow individual users to schedule tasks without the need for root privileges. Each user can have their own crontab, and cron jobs in a users’ crontab run with the permissions of the user who creates the crontab. Although the system-wide crontab /etc/crontab is usually associated with root, the root user can also have an independent crontab just like any other user. When created, user crontab files are saved in various locations under /var. These files are not intended to be edited directly, however, but rather by using the crontab command. Here’s the crontab command’s basic syntax:

-u – Specifies the name of the user whose crontab is to be created or edited. If this option is not given, crontab examines “your” crontab; i.e., the crontab of the person executing the crontab command.

-l – Displays the contents of the crontab file.

-r – Removes the current crontab file.

-e – Creates a new crontab file (or edits an exiting one) using the users default command line editor specified in the environment variables. After you successfully save and exit from the editor, the modified crontab file will be installed automatically. Note that if you are running the crontab -e command inside of su you will create or edit the crontab file of the root user. Likewise if you use the command sudo crontab -e.

Each line in a crontab file contains seven fields from left to right:

Minute – Any integer from 0 to 59.

Hour – Any integer from 0 to 23.

Day – Any integer from 1 to 31 (must be a valid day if a month is specified).

Month – Any integer from 1 to 12, or the abbreviated form of the month; e.g., jan, feb, etc.

Day of week – Any integer from 0 to 7, where 0 or 7 represents Sunday, or the abbreviated name of the week; e.g, sun, mon, etc.

User – Specifies the user under which the cron jobs are run

Command – the command to execute (the command can either be a command or the name of a script containing one or more commands)

There are also several ways of specifying multiple values in a field:

  • Using a comma specifies a list of values, for example: 1,3,4,7,8. Using a hyphen specifies a range of values, for example: 1-6, which is equivalent to 1,2,3,4,5,6.
  • Using an asterisk specifies all possible values for a field; e.g., every hour or every day.
  • The forward slash can be used to skip a given number of values. For example, “*”/3 in the hour field is equivalent to the hours 0,3,6,9,12,15,18,21. The “*” specifies “every hour” but the “/3” means that only the first, fourth, seventh,…etc hours starting at midnight are used.

Here’s some example cron job entries using the rsync command. As you can see, you could add one or many cron job entries to your crontab depending on your needs:

cron will email to the user all output of the commands it runs. To silence this, the output can be redirected to a log file or to /dev/null. Note also that individual users’ crontab files (i.e., those edited via crontab -e, sudo crontab -e or under su for root’s), omit the user field since the system understands that crontab file belongs to the user. The /etc/crontab and the files in /etc/cron.d and /etc/cron.{hourly, daily, weekly, monthly}, however, do require a field for the user.

cron in FreeBSD

  • cron daemon: /usr/sbin/cron
  • cron start script: /etc/rc.d/cron
  • crontab command: /usr/bin/crontab
  • System-wide crontab files: /etc/crontab
  • crontab file location created using crontab -e (The crontab file name = the user name): /var/cron/tabs/
  • Log location: /var/log/cron

cron in Ubuntu server

  • cron daemon: /usr/sbin/cron
  • cron start script: /etc/init.d/cron
  • crontab binary: /usr/bin/crontab
  • System-wide crontab files: /etc/crontab and /etc/cron.d
  • Other crontab locations: /etc/cron.{hourly, daily, weekly, monthly}
  • crontab file location created using crontab -e (The crontab file name = the user name): /var/spool/cron/crontabs/
  • Log location /var/log/syslog

Conclusion

Um… cron… ’nuff said.

References

http://ss64.com/bash/cron.html

http://www.freebsd.org/doc/handbook/configtuning-cron.html

http://www.marksanborn.net/linux/learning-cron-by-example/

https://help.ubuntu.com/community/CronHowto

News

What’s Your IP?

I’ve added a Your IP tab at the top of the site that will bring you to a page that displays your current IP address as well as some other http connection-related information. A geeky little task I’ve been meaning to do for awhile now. Here’s the code I hacked together for it. As always, please report any problems you encounter with it, and any suggestions you may have for ways to improve the code and/or experience.

BSD

Backup FreeNAS Files Remotely Using FreeBSD and rsync

FreeNAS is an open source storage platform based on FreeBSD that supports file sharing across Windows, Apple, and Unix/Linux systems. rsync is an open source file copying utility for Linux/Unix systems. It’s famous for its “delta-transfer” algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination. It offers a large number of options, including the ability to copy locally, to/from another host over any remote shell, or to/from a remote rsync daemon; and, the ability to preserve symbolic links, hard links, file ownership, permissions, devices and times.

In this post I will describe how to configure FreeBSD, FreeNAS and rsync to securely backup files located on FreeNAS to a FreeBSD machine located at a remote location. All steps involved assume you have a running implementation of FreeBSD and FreeNAS. The software versions used in this post were as follows:

  • FreeBSD 9.0-RELEASE (x64)
  • FreeNAS v0.7.1 Shere (revision 5127)
  • rsync v3.0.9

Configure FreeNAS

There are two ways for the FreeBSD machine to contact FreeNAS using rsync: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsync daemon directly via TCP. We’re going to use ssh as our transport method. We’ll also create a new user account in FreeNAS named “rsync,” which we will enable access to via ssh but limit its use solely for the purpose of backing up files using rsync.

Begin by logging into the FreeNAS web interface, navigate to Access->Users and Groups->Users and select the “+” icon to create a new user account. The following parameters will need to be configured:

Name – This is the login name of the new user. You’re welcome to use any user name you’d like here. For purposes of our example though let’s enter rsync.

Full Name – This field should match the Name field, so enter rsync again here.

Password – Our plans include generating and using ssh keys to authenticate the FreeBSD machine to the FreeNAS machine and not passwords, so leave these fields blank.

User ID – Unless you have a specific reason to change the User ID you should retain whatever FreeNAS has chosen for you here, typically UID 1001 if this is your first new user account on FreeNAS.

Shell – This parameter specifies the login shell for our new user rsync. The nologin option should not be selected as it will not permit access to the account. For purposes of our example, we’ll select the good old sh shell.

Primary group – This parameter sets the primary group that the user rsync will belong to. Unless you have a specific reason to change the group, the default group Guest should be retained here.

Additional group – No other group memberships need be selected.

Home directory – Here’s where we’ll enter the path to the home directory for the rsync user, which for purposes of our example should be set to /usr/home/rsync.

When complete, the configuration should resemble Figure 1. Now select “Add” to accept the changes and add rsync as a new user.

Screenshot of the FreeNAS new user setup page

Figure 1

Now let’s configure and activate the rsync service in FreeNAS. Navigate to Services->Rsync->Server->Settings and check the “Enable” box, then click on the drop down list under “Map to user” and select rsync. The remaining fields can remain at their default settings. When complete, the configuration should resemble Figure 2. Now select “Save and Restart” to accept the changes and start the rsync server.

Screenshot of the FreeNAS rsync server setup page

Figure 2

Next, we need to ensure the ssh service is running in FreeNAS. Navigate to Services->SSH and check the “Enable” box. To help improve security, we’ll avoid using the default TCP port 22 and, for purposes of our example, use port 13725 instead. Check the “Permit root login” box and ensure that “Password authentication” box is checked. When complete, the configuration should resemble Figure 3. Now select “Save and Restart” to accept the changes and start the ssh server.

Screenshot of the FreeNAS SSH setup page

Figure 3

Finally, connect via ssh to the the root account of the FreeNAS machine and create the directory /usr/home/rsync/.ssh, which we’ll use to hold the public RSA key that we’ll eventually generate and copy from the FreeBSD machine. Note: Alternatively, you can create this directory using FreeNAS’s built-in file management tools by navigating to Advanced->File Manager. Make sure to provide the correct local IP address or host name of the FreeNAS machine. If this machine is located on another network, then make sure to provide the correct IP address or URL of the network where the FreeNAS machine is located, as well as ensure that any NAT gateway is configured to pass TCP port 13725 traffic to the correct host:

Okay, we’re finished with thr FreeNAS configuration for now. Let’s move on and configure the FreeBSD machine.

Configure FreeBSD

The following steps assume you have the FreeBSD Ports Collection installed. If not, you can install it by using the following commands:

If the Ports Collection is already installed, make sure to update it:

Navigate to the rsync port and build it, accepting the default configuration options:

Next, we’ll choose a location that will be used to backup the FreeNAS files. For purposes of our example, we will create the subdirectory backup within the primary user’s home directory on the FreeBSD machine:

Then make sure the user owns this directory, as well as any files and subdirectories within it:

Recall that we shunned conventional password authentication when creating the rsync user account on FreeNAS. Instead, we’re going to generate an RSA public/private key pair on the FreeBSD machine, and copy the public key to the FreeNAS machine. rsync will be able to login and authenticate itself to the FreeNAS machine without the need for a password because the FreeBSD machine has the corresponding private key. rsync can now run autonomously because it will not be prompted for a password each time it attempts to login:

By default the RSA keys are 2048 bits. If you’re really paranoid you can increase this to 4096 bits if desired with the -b flag:

You’ll be asked by the ssh-keygen script where it should store the keys (~/.ssh is the default), and then asked to enter and confirm a password for the private key that will be stored in this machine. In our particular case, we don’t want to be prompted for a password so simply press enter. The private key (id_rsa) and the public key (id_rsa.pub) are generated and then stored in ~/.ssh (if you accepted the default directory). Now that our keys are generated, let’s copy the public key to the FreeNAS machine using the venerable secure copy command:

Note that in the case of the scp command we must designate the ssh port number using the upper-case -P option, and pass to it the same ssh port number that was designated when we configured FreeNAS. Here again, make sure to provide the correct local IP address or host name of the FreeNAS machine or, if this machine is located on another network, the correct IP address or URL of the network where the FreeNAS machine is located. When you successfully connect you’ll likely receive a message concerning the authenticity of the FreeNAS machine, along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by typing yes and you’ll be presented with a password prompt for the root user on the FreeNAS machine. Enter the password and the public key will be copied.

Now let’s connect again via ssh to the root account of the FreeNAS machine and copy the public key to /home/rsync/.ssh/authorized_keys so that rsync can securely connect to FreeNAS without the need for a password. We’ll also take this opportunity to remove the public key from the root account:

Then lock down permissions and make sure the user rsync owns of all files and subdirectories within its home directory:

Finally, let’s make sure we can connect to the rsync account on FreeNAS using only public/private key authentication:

When you successfully connect you’ll once again receive a message concerning the authenticity of the FreeNAS machine. Accept by typing yes and you’ll be securely connected to the rsync user’s home directory (/home/rsync/) on FreeNAS without the need to enter a password.

Okay, let’s move on and configure rsync.

Configure rsync

For purposes of example, let’s assume that on the FreeNAS machines there is directory /mnt/files/foo containing a number of files along with two subdirectories – /mnt/files/foo/bar1 and /mnt/files/foo/bar2 – that we wish to backup on a routine basis to the FreeBSD machine. You could issue the following command to the FreeBSD machine accomplish that:

Long command, right? Let’s walk through it. First, we invoke the rsync command and pass to it the following options:

-a – Specifies that the files are transferred in “archive” mode, which ensures that any symbolic links, devices, attributes, permissions, ownerships etc are preserved.

-v – Increases the verbosity of the command so that you know in a little more detail what rsync is/is not doing.

-z – Specifies that rsync should use compression to reduce the size of data portions of its file transfers.

–delete – Specifies that rsync should delete files in the destination that no longer exist on the source side. This helps to keep the file systems specified in the source and destination synchronized.

Then we tell rsync that we’d like to use ssh and port 13725 by using the “-e ssh -p 13725” option. Finally, we tell rsync what the source and destination file systems are.

Another rsync option that I find handy is –exclude. Let’s say that for whatever reason you’d like to exclude the subdirectory /mnt/files/foo/bar2 and all the files therein. You’d use the following command to accomplish that:

Please consult the rsync man pages for further information on what rsync options are available for your specific needs.

Once you get the rsync command configured the way you’d like it, then it’s time to add it to cron on the FreeBSD machine so that it will perform backups on a routine basis. cron is a *nix utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are typically referred to as “cron jobs.” A “crontab” is a file which contains one or more cron job entries to be run at specified times. You can create a new crontab (or edit an exiting one) using the system’s default command line editor by using the command crontab -e under your user account. Here’s some example cron job entries using our rsync command. You could add one or many rsync cron job entries to your crontab depending on your needs, then simply uncomment the one you want to use. Also, cron will attempt to email to the user the output of the commands it runs. To silence this, we’ll redirect the command output to /dev/null:

While placing the full rsync command in the crontab works just fine, it can become a bit unwieldy, particularly if the command is lengthy. A more elegant approach is to capture the command and associated options in a shell script and invoke the script in a crontab instead of the full command. Here’s what a basic shell script might look like, again utilizing our example rsync command:

You’ll notice that in addition to running the rsync command, the script will also create the log file /home/iceflatline/cronlog and append the date/time and a brief summary of what transpired to it every time script runs. To use this script, modify its values to suit your particular need, including the correct IP address or URL for the FreeNAS machine, and give it a name, say for example rsync-freenas. Then create a bin/ subdirectory in the home directory on the FreeBSD machine, copy the file to that location, and make it executable:

Now then, a crontab entry invoking this script would look like this; i.e., a whole lot less complex:

Final Steps

Now that we have everything configured, login again to the FreeNAS web interface. Navigate to Services->SSH and uncheck both the “Permit root login” and “Password authentication” boxes. When complete, select “Save and Restart” to accept the changes and restart the ssh server.

Tips

Here’s a few of tips that may help improve your experience when using rsync in the manner described in this post

  • There’s no requirement that the machine you’re backing up FreeNAS files to be based on FreeBSD. You could just as easily use a machine based on a Linux distribution for example. Simply download and install rsync via the distribution’s package manager or compile it from source. The remaining steps should work as described.
  • Regardless of which operating system you use, backing up to a separate partition or, better yet, a separate hard disk(s) is recommended. This partition or disk can simply be mounted at a location in your file system, for example the /home/iceflatline/backup we used in our example, then, if something should require you to reinstall the OS, your files would still be intact. I prefer using a separate hard disk. That way, if/when I need to restore some or all of the files to FreeNAS, I need only unmount the drive from the FreeBSD machine, mount it in FreeNAS and have access again to the files.
  • Depending on the quantity and size of the files you want to backup, you may wish to consider initially locating the FreeBSD machine on the same network as the FreeNAS machine. The initial backup will likely go much faster on a 100 Mbps or 1000 Mbps local area network than it would over a wide area network. Once the initial backup is complete, then the FreeBSD machine can be moved to a remote location to start performing incremental backups.
  • A VPN (“Virtual Private Network”) can be setup between the FreeNAS and FreeBSD machine, thus perhaps eliminating the need to use a non-standard ssh port. Another benefit of using a VPN to connect the two machines is the ability to easily connect to the FreeBSD machine from within the FreeNAS machine’s network; handy if/when you want to quickly retrieve a file or perform routine maintenance on the FreeBSD machine.
  • Occasionally, you may add large and/or numerous files to FreeNAS where the time it takes to incrementally back them up to FreeBSD exceeds the time specified between cron jobs in the crontab. For example, if the cron job runs the rsync script or command every 60 minutes, but it takes 75 minutes to incrementally backup the new files added to FreeNAS, then errors will occur when the cron job triggers rsync to run again. To avoid this problem, you can edit the crontab to lengthen the time between cron jobs, or stop the cron job from running by commenting it out in the crontab and run rsync manually instead. Once rsync has fully backed up you can use the crontab again.

    • Conclusion

    This concludes the post on how to remotely and securely backup and synchronize files located on a FreeNAS machine to a FreeBSD-based machine, using rsync, a fast and versatile file copying tool.

    References

    http://ss64.com/bash/cron.html

    http://www.marksanborn.net/linux/learning-cron-by-example/

    http://troy.jdmz.net/rsync/index.html

    BSD

    How to Install Apache, MySQL, PHP, and phpMyAdmin on FreeBSD

    (20170107 — The steps in this post were amended to address changes in recent versions of software. Minor editorial corrections were also made — iceflatline)

    This post will describe how to install and configure Apache, MySQL, PHP and phpMyAdmin on FreeBSD for basic local web development. Once set up, you’ll be able to use your “FAMP” server to do web development, code testing, maintain local copies of your web sites, etc.

    The software discussed in this post are available as free and open source under various licensing structures. The versions of software discussed in this post are as follows:

    • FreeBSD 11.0-RELEASE
    • apache24-2.4.25_1
    • mysql57-server-5.7.17
    • mod_php70-7.0.14
    • php70-7.0.14
    • php70-extensions-1.1
    • phpMyAdmin-4.6.5.2
    • WordPress 4.7

    The following steps discussed in this post assume you have the FreeBSD Ports Collection installed. If not, you can install it using the following commands:

    If the Ports Collection is already installed, make sure to update it:

    Okay, let’s get started. All commands are issued as the user root. While building the various ports you should accept all default configuration options unless otherwise instructed.

    Install Apache

    Navigate to the Apache server port and build it:

    Once Apache has been successfully installed, use the sysrc command to add the following line to /etc/rc.conf so that the Apache server will start automatically at system boot.

    Now let’s start Apache to make sure it works:

    Point your web browser to the host name or IP address of the FreeBSD host you’ve installed Apache on and you should see the venerable “It works!”

    Install MySQL

    Navigate to the MySQL server port and build it:

    Add the following line to /etc/rc.conf using sysrc:

    And start the mysql server:

    Then set a password for the MySQL root user:

    You’ll be requested to enter a password. Enter the random initial root password contained in /root/.mysql_secret. You’ll now be at the command prompt for the mysql server. Change your root password using the following command:

    Enter ‘quit’ to exit the server. You may now delete /root/.mysql_secret.

    Install PHP

    Next, we’ll build PHP:

    Then add the extensions to PHP to round out its capabilities. Before we build this port though we’ll want to add support for MySQLi (an improved interface to MySQL) in order to communicate with the MySQL server.

    In the corresponding menu you should select “MYSQLI”, then proceed with building the port:

    Now let’s add the module required to support PHP applications on Apache:

    Install phpMyAdmin

    phpMyAdmin is a free software tool written in PHP intended to handle the administration of MySQL from your web browser. phpMyAdmin supports a wide range of operations with MySQL, including managing databases, tables, fields, relations, indexes, users, permissions, etc., from an easy-to-use web page, while you still have the ability to directly execute any SQL statement from the command line if you prefer. Installing phpMyAdmin is optional but it’s a nice tool to have:

    Configuration

    Now that we have the requisite ports built and installed it’s time to configure them. First, let’s create the file /usr/local/etc/php.ini to hold our PHP options. The simpliest way to do this is to copy the file /usr/local/etc/php.ini-development which will add the default settings for new PHP installations. This configuration is suitable for development purposes, but NOT necessarily for production purposes. If your plans include a production server, then among other things, and before going online with your site, you should consider copying /usr/local/etc/php.ini-production instead and consult the recommendations at http://php.net/manual/en/security.php.

    Now let’s configure Apache. Open the file /usr/local/etc/apache24/httpd.conf and look for the following line:

    And change it so it reads as follows:

    Then append the following lines to the end of the file in order to support PHP files as well as phpMyAdmin, which normally lives outside of the Apache document root. Note: if you elected not to install phpMyAdmin, then you need only add the FilesMatch directives.

    Now restart Apache:

    That’s it for our Apache configuration. Now let’s configure phpMyAdmin. We’ll do this by creating the file /usr/local/www/phpMyAdmin/config.inc.php, the basic configuration file for phpMyAdmin. Traditionally, users have manually created or modified /usr/local/www/phpMyAdmin/config.inc.php, but now phpMyAdmin includes a nice setup script, making it much easier to create this file with the settings you want. Start by creating the directory /usr/local/www/phpMyAdmin/config and make it writable by the phpMyAdmin setup script:

    Then make /usr/local/www/phpMyAdmin/config.inc.php readable by the phpMyAdmin setup script:

    Now open your web browser and navigate to http://your-hostname-or-IP-address/phpmyadmin/setup where you will see the phpMyAdmin setup Overview page. Select “New server” and then select the “Authentication” tab. Under the “Authentication type” choose “http” from the drop-down list (using HTTP-Auth to sign-in into phpMyAdmin will avoid storing login/password credentials directly in config.inc.php) and remove “root” from the “User for config auth”(See Figure 1).

    Screenshot of the phpMyAdmin setup page

    Figure 1

    Now select “Apply” and you will be returned you to the Overview page where you should see a new server listed. Select “Save” in the Overview page to save your configuration as /usr/local/www/phpMyAdmin/config/config.inc.php. Now let’s move that file up one directory to /usr/local/www/phpMyAdmin where phpMyAdmin can make use of it.

    Now let’s try out phpMyAdmin to make sure it works. Point your web browser to http://your-hostname-or-IP-address/phpmyadmin where you will be presented with a pop-up box requesting you to log in. Use “root” and the MySQL password you set up previously, then you should be directed to the phpMyAdmin administration page. We no longer need the /usr/local/www/phpMyAdmin/config directory so let’s remove it, as well as the read permission we added previously to /usr/local/www/phpMyAdmin/config.inc.php:

    And wrap up by restarting the Apache and MySQL servers:

    Testing our installation using WordPress

    WordPress is a full-featured website/blog platform that makes heavy use of Apache, MySQL and PHP. We’ll install it on our newly created implementation to ensure we have these packages installed and working correctly. Once again, all commands are issued as the root user or by simulating the root user using the command su. Let’s start by downloading the latest WordPress directly from the developers site to your home directory and untarring the package:

    You should now see the new directory wordpress in your home directory. Next we need to create the file ~/wordpress/wp-config.php and make some changes to it so WordPress can access the MySQL server. First, let’s copy the file ~/wordpress/wp-config-sample.php to use as a template:

    Open ~/wordpress/wp-config.php in your favorite editor and enter the database name as well as your MySQL login and password in the appropriate lines. When complete, it should look like the following:

    Now move the wordpress directory to Apache’s document root:

    Next, let’s create an MySQL database for our WordPress installation. Open phpMyAdmin in your browser and create a database by selecting the “Databases” tab at the top. Enter a name for it in the “Create database” field. For purposes of our example, I’ll use “wordpress” as the database name. You’re free to use a different database name, just make sure to use the same name in the define(‘DB_NAME’, ‘your-DB-name’); line in ~/wordpress/wp-config.php as described above. Then select “Create.”

    Now let’s run the WordPress script that will populate its database with the requisite tables. Open your web browser and navigate to http://your-hostname-or-IP-address/wordpress/wp-admin/install.php. If everything is configured correctly you should see the WordPress installation wizard page (See Figure 2). Enter a title for your site, username, password, and an e-mail, then select “Install WordPress.” Then login with your newly created WordPress credentials and you should be presented with the default WordPress administration page.

    Screenshot of WordPress installation page

    Figure 2

    Common problems

    An error that occasionally pops up when attempting to start the Apache server is the following:

    This can be fixed by adding the following line to /usr/local/etc/apache24/httpd.conf:

    HTTP 403 permission problems when trying to access phpMyAdmin is another area that seems to sometimes trip people up. This is usually caused by errors in the way either the Alias or Directory Apache directives for phpMyAdmin have been written in /usr/local/etc/apache24/httpd.conf. As an example, a missing “/” in the Alias statement cost me two hours of troubleshooting time!

    Conclusion

    Well, that’s it. A few hours of your time with the FreeBSD Ports Collection and you can a get a fully configured “FAMP” web development server up and running on your FreeBSD box.

    References

    http://caffetine.org/freebsd-amp.php

    https://httpd.apache.org/docs/2.4/upgrading.html

    http://dev.mysql.com/doc/refman/5.7/en/

    Hardware

    PC Build: Intel Core i7 Sandy Bridge

    Recently I decided it was time to upgrade my main desktop computer. My current system, featuring an Intel DP55KG motherboard (P55 Chipset/Socket 1156), Intel Core i7-860 (Lynnfield) processor, AMD Radeon HD 5870 GPU, and 8 GB of DDR3-1600 Mushkin RAM, had served me well, but I was anxious to give Intel’s “Sandy Bridge” architecture a try. This post will document my upgrade, starting with the parts I selected and why; the assembly of the system and the challenges I encountered; and finally, a few thoughts on overclocking the upgraded system.

    The Parts

    As I stated in my previous posts concerning my Lynnfield build, I’ve built a good many PCs over the years. My goal now, as it was then, was to use the best quality components I could find for a low price, and build a good, fast, and reliable machine. In other words, build a machine that’s a good value.

    The Case – Thermal management in Intel processors have progressed to the point where unless you’re planning on doing some serious overclocking there’s really no reason to consider using water cooling over a good air cooling solution. Consequently, I was looking for a mid-tower case with good air flow. Since the NZXT Tempest case I used for my Lynnfield build had served me well in this regard, I decided to go with the next generation of this case, the NZXT Tempest Evo. Among other things, this case features dual 120mm intake and 140mm exhaust fans, with an additional side 120mm fan and rear 120mm fan, making it one of the better cases for air cooling. Another nice feature that was added to this case is a slightly wider side panel design, thus increasing the available space behind the motherboard for cable routing, as well as a punchout behind the processor so one doesn’t have to completely remove the motherboard from the case in order to replace the heatsink and fan.

    The Power Supply – I’ve almost exclusively used power supplies from two manufacturers: Fortron for lower cost builds and PC Power & Cooling. This time however, I decided to go with the Corsair TX750. This is a slightly less expensive unit than a comparable one from PC Power & Cooling, but Corsair does maintain quality products and this unit still features a dedicated, single +12V rail for maximum and efficient power distribution.

    The Processor – With Sandy Bridge Intel launched with no less than 29 different SKUs (15 for mobile and 14 for desktop) once again presenting a very challenging decision for the gamer/enthusiast building a new desktop system. After doing some research and giving it much consideration, I chose the Intel Core i7-2600k processor with a 3.4 GHz core clock, 8 MB of L3 cache and hyper-threading. Besides the featuring the highest core clock among the Sandy Bridge desktop processors, the “K” suffix means the “turbo mode” multipliers, from 16x all the way up to 57x, are fully unlocked, giving this processor a lot of overclocking potential.

    The Motherboard – I’ve traditionally used ASUS motherboards but then began to run into reliability problems with them over the years. I also grew tired of the growing list of “features” their boards began to offer that I had no use for on my desktop machines (e.g. WiFi, Bluetooth, etc.), resulting in time spent maintaining drivers for these features or trying to disable them altogether. For my Lynnfield build I used Intel’s DP55KG and really liked it. No it didn’t have all the features and overclocking capabilities of say an ASUS or Gigabyte motherboard at the time, but it turned out to be sufficiently overclockable for my needs and has been 100% reliable. However, The Sandy Bridge processor ushered in yet one more socket change by Intel, Socket 1155, taking the option to use my existing Socket 1156-based Intel DP55KG motherboard off the table. Even so, given my overall good experience with Intel motherboards, I initially decided to go with them again for this build and chose their DP67BG. However, no sooner had this board arrived than Intel announced that they had discovered a design error in the P67 chipset. In some cases, the Serial-ATA (SATA) ports within the chipset may degrade over time, potentially impacting the performance or functionality of SATA-linked devices such as hard disk drives and DVD-drives. Since I had just purchased the product I returned it as defective for a full refund. Then I waited for Intel to roll out the next (so called “B3”) version of this board. Unfortunately that day never came, and Intel showed no sign that they would upate this product, so I once again looked to ASUS to meet my needs and ended up selecting their Sabertooth P67 board, my first I should add that featured a Unified Extensible Firmware Interface (“UEFI”). I also purchased a small 50 mm fan from Evercool to help improve upon the board’s “TUF Thermal Armor” cooling capabilities.

    The Heatsink – I chose the Cooler Master Hyper 212 after doing a bit a research to make sure it would clear the surrounding components on the motherboard, including the RAM. To improve its already very good cooling capabilities, I purchased an additional 120 mm fan from Cooler Master that matched the fan the product shipped with and set it up in a push/pull configuration. This fan configuration combined with the NZXT case should provide excellent overall processor cooling. Finally, to ensure that both fans would rotate at reasonably the same speed, I used a PWM splitter from Rosewill to power and control both fans from the processor fan header.

    The RAM – I was looking for an 8 GB DDR3-1600 dual kit (2 x 4 GB) with the timings as low as possible. Another factor that I was glad I considered ahead of time was whether the RAM would fit under the processor’s fan/heatsink due to the close proximity of the RAM slots to processor. I ended up eliminated a couple of products (Corsair’s “Dominator” as an example) because they were too tall to fit. I ended up selecting G.Skill’s RipjawsX DDR3-1600 8 GB dual kit, which runs at 1.65v with timings that spec at 7-8-7-24-2N. I had heard and read good things about G.Skill memory and was anxious to finally have the opportunity to give one of their products a try.

    The Graphics – I have no particular allegiance to either AMD or Nvidia and was willing to go with a product from either depending on its price versus performance. I ended up going with AMD this time around and chose the MSI R6950 Twin Frozr II OC. For ~$290, I felt it provided the best performance for the money.

    The Hard Drives – When I built my Lynnfield-based rig, solid state drive (SSD) prices were still relatively high compared to conventional spindle drives and firmware support for features like “trim” so fluid I decided to stick with with my trusty Western Digital “Raptor” drives. SSD prices have since dropped and trim support is now fully implemented so I decided it was time to upgrade. While I wanted to spring for a new SATA revision 3.0 (SATA 6 Gb/s) drive, I could not justify the cost at this time, so I chose instead the OCZ Vertex 2 80 GB SATA revision 2.0 (SATA 3 Gb/s) SSD. This will serve as my system drive, and a Western Digital Caviar Black 1TB 7200 RPM 64MB cache SATA 3.0 drive will hold my data.

    The Optical Drive – Believe it or not I actually still use one of these :). I didn’t spend much time shopping for it though, instead I went to Newegg, navigated to CD/DVD Burners, selected “Best Rating” from among the search options, and dutifully paid for the ASUS DRW-24B1ST.

    The Operating System – Not much of a surprise here, I went with Windows 7 Pro 64-bit. Why the Pro version instead of Home Premium? Remote Desktop. Home Premium doesn’t support it and I need this feature so I can access this machine remotely. Why Windows and not Linux? Games. I’m a PC gamer and this is my gaming rig (there are many like it but this one’s mine…). Someday perhaps computer gaming on *nix-based systems will be a viable option. No one hopes that day will will come more than I do, but it’s not today.

    The Build

    With the component selection and purchase out of the way it was time to put them all together. I like to build systems outside of the the case. Then, when I’m sure everything is running well, I’ll place the components in the case and dress up the wiring (See Figure 1).

    Screenshot of my Core i7 Sandy Bridge build outside of the computer case

    Figure 1

    The SATA 2.0 and SATA 3.0 ports are mounted horizontally, facing the back of the case, instead of vertically, making it much easier to connect/disconnect disk drives with the graphics card in place. I placed the 80 GB OCZ Vertex 2 drive, which will hold the operating system, on the P67 controller’s SATA 3.0 GB port 1, and the 1TB WD Caviar Black drive on the SATA 3.0 port 2. These are the Brown SATA ports on the ASUS Sabertooth P67 motherboard.

    The Sabertooth P67 is equipped with what ASUS calls “TUF Thermal Armor,” a rather fancy term for what is essentially a heatsink that encompasses nearly the entire motherboard. The idea behind this somewhat unorthodox design is to conduct the hot air generated by cards and components out of the case through special air flow channels, thus reducing the overall temperature of the motherboard, and by extension the inside the the PC case. To do this effectively, however, ASUS recommends that system builders use a processor fan that directs air downward into the motherboard. Unfortunately, like most processor fan/heatsink products made for the PC enthusiasts market, the Cooler Master Hyper 212 Plus is mounted vertically, directing air out the back of the case, not downward towards the motherboard’s components. In anticipation of the situation, ASUS provides a spot on the motherboard that allows one to mount a small 50mm “assistant” fan, in order to improve the air flow through the TUF Thermal Armor (See Figure 2).

    Screenshot of the 50 mm fan from Evercool installed on the ASUS P67 motherboard

    Figure 2

    After successfully assembling the components, and firing up the system without issue, I proceeded to update the P67 Sabertooth’s UEFI firmware to the latest version. Fortunately ASUS makes updating the firmware incredibly easy, offering a number of ways to perform the task, including directly from Windows. The one that worked best for me was to perform the update directly from within the UEFI. First, I inserted a USB drive contained the latest UEFI ROM file into a USB port. Then I entered the “Advanced Mode” of UEFI, navigated to the “Tool” menu, and selected “ASUS EZ Flash Utility.” I highlighted the USB drive containing the ROM file and selected “Enter” to proceed with the UEFI firmware update.

    With updated UEFI firmware now place, it was time to explore the UEFI settings, ensuring that my drives were detected correctly, disabling unwanted features, etc. One issue I noticed fairly quickly was that my processor temperature was idling at ~42C at a room temperature of ~21C, a little hotter than what I would expect when using the Cooler Master Hyper 212 Plus. It should be noted here that on the P67 Sabertooth, the processor temperature reading in the UEFI can be anywhere between ~5C – ~10C higher than in Windows. That’s normal as the UEFI does not send idle commands to the processor, as is the case when the OS is running. Investigating this issue further led me to this Benchmark Reviews article discussing the best thermal paste application methods for heat-pipe direct touch coolers. After a bit of experimentation, I obtained the lowest processor temps using my Cooler Master Hyper 212 Plus by applying two thin lines of Artic Silver 5 thermal compound to the two center mounting base partitions (See Figure 3), lowering my processor temps to ~37C in UEFI and ~31 when measured from within Windows using Real Temp.

    Screenshot showing where to apply thermal compound on the Cooler Master Hyper 212 plus heatsink

    Figure 3

    Windows Professional (x64) installed without issue on the OCZ Vertex 2 drive, but this is where my progress came to a temporary halt. One of the first applications I typically install shortly after I finish installing the OS is CPU-Z in order to evaluate processor core stepping and core voltage; internal and external processor clocks and clock multipliers; and memory frequency and timings. CPU-Z showed that the processor multiplier was “stuck” at 1.6 GHz (multipler = 16x), never allowing the processor to rise to its specified default operating frequency of 3.4 GHz (multiplier = 34x) or its default Turbo mode frequency of 3.8 GHz (multiplier = 38x). After trying numerous UEFI tweaks, I gave up and concluded that the board was defective. The replacement board was received a week or so later and after reassembling the requisite parts it worked as designed.

    Another issue I encountered involved updating the firmware on the OCZ Vertex 80 GB drive to the most recent version – 1.33 at the time of this post. The OCZ Toolbox firmware update tool did not see the SSD drive because the tool is currently incompatible with the Intel Rapid Storage Technology (“RST”) driver software – V10.0.0.1046 at the time of this post. The work around for this problem was to remove the Intel RST driver, update the firmware, then reinstall the Intel RST driver. Incidentally, I took the opportunity to run a few benchmark tests against this drive using ATTO Disk Benchmark and came away with the 272 MB reads and 258 MB writes (128 KB transfer size).

    With all of the device drivers installed Window’s Device Manager was still indicating that a driver for the “PCI Simple Communications Controller” was still missing (The dreaded yellow exclamation mark). It turned out that I needed to download and install Intel’s Management Engine Interface utility from ASUS in order to clear that error.

    Finally, to improve the reliability of the P67 Sabertooth’s Wake on Lan feature, I decided to download and install the Intel drivers for the Sabertooth P67’s 82579V Ethernet network interface controller. Then, I entered the UEFI’s Advanced mode, navigated to Advanced -> APM and enabled “Power On By PCI.”

    With these issues out of way I continued on, updating Windows, adding applications, tweaking options and generally letting the system burn-in for a bit. Then it was time to move on to overclocking the system.

    The Overclock

    With the advent of Intel’s “Turbo Mode” feature starting in its Nehalem “Bloomfield” processor, the Base Clock (BCLK) multiplier value was able to automatically increase beyond its default value if the processor was operating within what the design considered to be a safe temperature tolerance. For example, in the Bloomfield architecture, processors were allowed to raise the stock multiplier value by 1 or 2 depending on the number of cores being used so long as the processor’s core temperatures did not rise beyond an arbitrary threshold. Intel’s Lynnfield processors generally ran cooler and so were allowed to be considerably more aggressive with Turbo Mode, increasing Turbo Mode multipliers within a range of ~2-5. In practice what this meant was that when fewer processor cores were in demand by a given application or process, larger multiplier values were used, thus allowing the processor to temporarily run at a higher clock rate than the default multiplier would normally allow. In the case of my Core i7 860 for example, with its BCLK of 133 MHz, it was not uncommon to see it use a multiplier value of 26 in single-threaded applications, yielding a processor speed of 3.46 GHz, well above its stock speed of 2.8 GHz when using the default multiplier of 21.

    Consequently, when it came to overclocking, the Lynnfield architecture offered the user somewhat of a choice. You could attempt to overclock the system with Turbo Mode enabled, requiring you to be mindful of the headroom necessary when higher turbo multiplier values kicked in, or you could simply disable Turbo Mode and go with the more traditional overclocking approach. Either way, the steps were similar: adjust the BCLK to achieve your desired processor frequency; adjust the memory multiplier to compensate for the change in BCLK; and, if necessary, adjust the processor voltage, memory voltage, and Uncore voltage to stabilize the system; rinse and repeat.

    The new Sandy Bridge technology, however, is a bit more challenging when it comes to overclocking. The new 100 MHz BCLK of Sandy Bridge processors doesn’t give users a lot of latitude in terms of increasing its value. If you’re lucky you can get it to run reliably at say 110 MHz. Multiply that value with your maximum Turbo Mode multiplier value, 38 in the case of the Core i7 2600K, and you’ll achieve ~4.2 GHz. Fortunately, with the K series processor, your overclocking options aren’t limited by the BCLK value; you’re also offered an unlocked multiplier ranging from 34 to 57, allowing you to potentially reach much higher processor speeds when operating in Turbo Mode.

    Not unlike most of the “enthusiasts” motherboards on the market today, the Sabertooth P67 offers a method to automatically overclock your system, dispensing with the need in most cases to independently adjust BCLK, memory and voltage settings. In fact, the Sabertooth P67 offers two methods: one is available by navigating to the in the UEFI’s “EZ Mode” settings and selecting the “Performance” option. The other is available by navigating to Advanced Mode -> Ai Tweaker and selecting “OC Tuner.” I decided to give the EZ Mode Performance option a go and was quite happy with the results (See Figure 4).

    Screenshot of the ASUS Sabertooth P67 Ai Tweaker settings after invoking the "Performance" option in EZ Mode

    Figure 4

    The BCLK was increased to 103 MHz and the Turbo Mode multiplier for all four cores to 43. This resulted in an overall processor speed of ~4.4 GHz when running in Turbo Mode. My DDR3-1600 memory settled at a speed of 1648 MHz. None of this is going to set any overclocking records, but you know what? It’s plenty fast for me for the time being, with plenty of headroom to make further increases at a later time if desired.

    Next, I adjusted my memory timings to the 7-8-7-24 and ran Memtest86+ for a couple of passes to ensure those timings were stable. Then I ran the 64-bit version of Prime 95 using the “Large in-place FFT” setting for ~24 hours to ensure that the system stability and maximum processor core temperatures were kept in check. I should note that ambient room temperature during the Prime 95 testing was ~21 C. The tests resulted in no errors and the maximum processor core temperatures were ~65 C. (See Figure 5).

    Screenshot of my desktop showing Prime 95, CPU-Z and Real Temp running simultaneously

    Figure 5

    Conclusion

    Intel’s Core i7 2600K processor and ASUS’s Sabertooth P67 motherboard turned out to be a good mid-range combination. Throw in the MSI R6950 Twin Frozr II graphics card and the 8 GB DDR3-1600 dual kit from G.Skill and I couldn’t be more pleased with the results of my first Sandy Bridge build. Since its completion, the system has been 100% stable. Future plans for this system likely include replacing the 80 GB SATA 2.0 drive with a SATA 3.0 drive, and of course do a bit more overclocking.

    References
    https://www.asus.com/us/Motherboards/SABERTOOTH_P67/