Tag: BSD

BSD

How to Forward Root’s Mail to a Another User in FreeBSD

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

After setting up a FreeBSD system I can sometimes go long stretches without becoming the superuser again. When I finally do issue the su command I’m usually presented with the line “You have mail.” I sigh and enter the command mail, where I’m presented with a multitude of system-generated mail updating me on everything from the status of cron jobs that have run (or not) to security and daily run reports. It’s at this point that I think to myself “I really need to forward that mail to my inbox so I read them more often.” This post will describe how to setup FreeBSD so that the root user’s mail is forwarded to another user account.

The versions for the software used in this post are as follows:

  • FreeBSD 12.0-RELEASE

To forward the root user’s mail to another users’ inbox open the file /etc/aliases as root and look for the following line:

Uncomment this line and replace “me@my.domain” with the user name you’d like the mail forwarded to. For example, to forward root’s mail to the user iceflatline on the same host, the line would look like this:

Now we need to make the sendmail (sendmail is the default Mail Transfer Agent in FreeBSD) aware of the changes we’ve made to /etc/aliases before they’ll take effect: We’ll do that by using the newaliases command as root:

Now any mail the system (or anyone else) sends to root will also be forwarded to the user iceflatline’s mail inbox. To test whether mail is indeed being forwarded use the mail command to send root a message. Start by specifying a subject, then hit enter and type the message. When complete, hit enter enter again to place the cursor at the beginning of a blank line, then enter CTRL+D to send the message:

Now enter the mail command at the user prompt and you should see the message you just sent to the root user:

Conclusion

Well, that’s it. A couple of tweaks on FreeBSD and you’ll have no excuse for missing those system reports.

BSD

How to use Clonezilla to Create and Backup Disk Images to FreeNAS

FreeNAS is an open source storage platform based on FreeBSD that supports file sharing across Windows, Apple, and Unix/Linux systems. Clonezilla is an open source clone utility for doing bare-metal backup and recovery for disks and disk partitions.

In this post I will describe how to use Clonezilla to create image files of disks or disk partitions and backup those images in real time over a network to a machine running FreeNAS. All steps involved assume you have a running implementation of FreeNAS. The software versions used in this post were as follows:

  • Clonezilla v1.2.12-10
  • FreeNAS v0.7.1 Shere (revision 5127)

Configure FreeNAS

Let’s start by making a new directory in FreeNAS to hold the images we create using Clonezilla. For the purpose of example, let’s assume there is an existing mount point located at /mnt/files and create a new subdirectory called images at that location. Next, let’s enable Network File System (“NFS”) service in FreeNAS so that /mnt/files/images can be accessed from Clonezilla. Login into the FreeNAS web interface and navigate to Services -> NFS -> Settings and make sure that the check box for enabling NFS is checked then specify the number of servers that will run (Hint: the default value of four should easily handle dozens of users). Now select “Save and Restart.” Next, navigate to Services -> NFS -> Shares and select the “+” icon, where you are presented with the configuration screen for creating a new NFS share. Enter the path to be shared; the network that is authorized to access /mnt/files/images; and, make sure that the “All dirs” and “Quiet” check boxes are selected. The remaining options can remain at their defaults (See Figure 1). Then select “Add” then “Apply changes” (Note: If you would prefer to use Common Internet File System (“CIFS”) instead of NFS, navigate to Services -> CIFS/SMB and select the appropriate settings and add your network share).

Screenshot of NFS shared path configuration in FreeNAS

Figure 1

Using Clonezilla
Now it’s time to use Clonezilla. Download a copy of Clonezilla live and burn it to a CD (or place it on a bootable USB drive). Boot the system using the Clonezilla live disk, where you’ll be given the option to change the language and select an alternative keyboard keymap, eventually arriving at the “Start Clonezilla” Screen (See Figure 2).

Screenshot of Clonezilla's start screen

Figure 2

Highlight “Start Clonezilla” and select “Ok.” The screen that follows provides a choice of cloning/restoring a disk or disk partition using using an image, or cloning/restoring a disk or disk partition directly to another disk or disk partition. Since we’ll be creating an image of a disk, we should select “device-image work with disks or partitions using images” (See Figure 3).

Screenshot of Clonezilla menu option to work with with images or devices when cloning or restoring

Figure 3

Next, Clonezilla will ask us to define where the image will be saved to (or read from), providing you with several options for accomplishing this task. We’re interested in using an NFS server, so select “nfs_server Use NFS server” (See Figure 4).

Screenshot of Clonezilla options specifying where it should transfer images to/from

Figure 4

You’ll then be offered several choices on how Clonezilla should obtain IP network settings, including DHCP, static IP, PPPoE, or a shell prompt to manually define how it should go about doing obtain its settings. Select which option works best for you then select “Ok” (See Figure 5).

Screenshot of Clonezilla IP network configuration options

Figure 5

Clonezilla will then ask you whether it should use NFS version 2,3 or 4. Select “nfs NFS V2, V3,” then enter the IP address or the host name of your FreeNAS machine in the screen that follows. Next, you’re asked where the Clonezilla image will be saved to/read from. For the purpose of our example, we’ll enter “/mnt/files/images” to match the new directory we created earlier (See Figure 6).

Screenshot of Clonezilla option specifying where the image should be stored

Figure 6

Clonezilla will then mount /mnt/files/images and display its current disk usage. Select “Enter” to continue and you’ll be given a choice to use Clonezilla in either a beginner or expert mode. Select “Beginner mode: Accept the default options” and you’ll be presented with a choice of whether to create images of the entire disk and/or one or more partitions (Note: this screen is also where you would choose to restore disk or partition images). If you would prefer to create an image of a partition, select “saveparts Save_local_partitions_as_an_image” where you will be presented with a choice of which partition(s) to create images of. For the purpose our example, however, we’ll select “savedisk Save_local_disk_as_an_image” to create an image of the entire disk (See Figure 7).

Screenshot of Clonezilla options allowing user to specify whether to create or restore the images of disks or disk partitions

Figure 7

Next, we’ll enter a name for new image and then chose whether we want to check and repair the file system before Clonezilla creates the image. This option is only for supported for certain Linux files systems, like ext3/4, and not for NTFS, so unless you have one of the supported file systems and have reason to suspect the file system may be in error, you should simply select “Skip checking/repairing source file system.” Clonezilla will then ask if you’d like for it to check if the image it creates will be restorable. Don’t worry, it performs this test without actually writing any data to the drive, so let’s select “Yes, check the saved image.” Now select “Enter” to continue, and confirm that you’d like Clonezilla to create the image by entering “y” at the prompt. Clonezilla will then create the disk image and write it to /mnt/files/images on your FreeNAS machine. When complete, Clonezilla will test to make sure the image is indeed restorable and then give the option of powering off the machine, rebooting, using the command line or start over. Congratulations! You’ve just created an image of your disk and stored it on your FreeNAS machine, where it will live safely and happily until you need it.

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

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/