AdSense Mobile Ad

Showing posts with label freebsd. Show all posts
Showing posts with label freebsd. Show all posts

Friday, October 17, 2014

Installing Drupal on FreeBSD

Drupal ports have been available on FreeBSD since quite a long time, and binary packages can be installed very quickly. However, manual setup is required to connect Drupal to the database and have Apache serve the Drupal website. In this post I'll describe the setup procedure of Drupal 7 on FreeBSD 10.0. The process will not be very different if different versions of Drupal or FreeBSD are used.

Installing Drupal

Drupal ports are available on FreeBSD and, in fact, multiple versions are available:

# pkg search drupal
drupal6-6.31
[...snip...]
drupal7-7.31
[...snip...]

Unless there is a compelling reason not to do so, install the latest one:

# pkg install drupal7

To successfully run Drupal, you need:
  • The Apache HTTP Server.
  • PHP.
  • A supported database server (PostgreSQL or MySQL).

The Drupal port, however, does not enforce these dependencies, so that you have to satisfy them manually.

Installing the Apache HTTP Server

Unless there is a compelling reason not to do so, install the latest available Apache port (apache24 at the time of writing):

# pkg install apache24

Once the port is installed, enable the corresponding service adding the following line to /etc/rc.conf:

apache24_enable="YES"


Installing the Database

Drupal supports both PostgreSQL and MySQL but the Drupal port does not install any, by default, although it installs the MySQL client utilities. In this post MySQL will be used but if you prefer using PostgreSQL instead, just skip this section and read this article instead.

Since the Drupal port by default defines the MYSQL option, when you install the binary package using pkg you'll also get a MySQL client port, such as what I got at the time of writing:

mysql55-client-5.5.40

As a consequence, you have to install the matching mysqlXX-server port:

# pkg install mysql55-server-5.5.40

If you try to install a different version (at the time of writing mysql56 is available), you may be requested to remove Drupal itself because of the inter-dependencies between the client and server MySQL packages.

Once MySQL is installed, enable the corresponding service adding the following line to /etc/rc.conf:

mysql_enable="YES"


Installing PHP

The installation of PHP is taken care of by the Drupal port. However, the PHP module for the Apache HTTP Server is not installed and must be installed manually. Make sure you install the PHP module that corresponds with the PHP version installed by the Drupal port. At the time of writing, the following modules are available:

# pkg search mod_php
mod_php5-5.4.33_1,1
mod_php55-5.5.17_1
mod_php56-5.6.1

Since the port depends on php5, then mod_php5-5.4.33_1,1 should be installed:

# pkg install mod_php5-5.4.33_1,1

The port takes care of modifying the Apache HTTP Server configuration file so that the PHP module is loaded. If you did not install the packages in order suggested by this post, then you may have lost that piece of configuration. In any case, make sure a line similar to the following is present in /usr/local/etc/apache24/httpd.conf:

LoadModule php5_module        libexec/apache24/libphp5.so


Installing drush

drush is an optional package offering an amazingly good command line interface to perform many Drupal-related management tasks: drush could even be used to install Drupal, but this topic is not covered by this post, since I prefer relying on a port tested specifically on FreeBSD. However, once you have tested that a specific release works correctly, you may find drush very useful to streamline your installations. If you are interested in using drush, you will find plenty of good information on the Internet. To install drush, the following command may be used:

# pkg install drush


Creating a Database for Drupal

A database for Drupal must be created in the DB server installed in the previous section. The MySQL port sets no password for the root user connecting from localhost; for this reason, setting its password is recommended (in bold the text input by the user):

# mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
[...snip...]
mysql> set password for root@localhost=PASSWORD('your-password')
mysql> exit
Bye

Once the password is set, you can try to reconnect (in italic bold the variables whose name should be changed with your values of choice):

# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
[...snip...]
mysql> create database drupal_database_name;
mysql> create user 'drupal_user'@'localhost' identified by 'password';
mysql> grant all privileges on drupal_database_name.* to 'drupal_user'@'localhost' with grant option;
mysql> flush privileges;


Configuring the Apache HTTP Server

Now that everything is in place, we can configure the web server so that it starts serving the Drupal web application. The tasks to perform are the following
  • Configuring the required modules.
  • Configuring a virtual host to serve Drupal.
  • Configuring a MIME/type for PHP.

The modules required to run Drupal are mod_rewrite and the PHP module. The latter was configured automatically by the PHP module port, and the latter can be configured uncommenting the following line from /usr/local/etc/apache24/httpd.conf:

LoadModule rewrite_module libexec/apache24/mod_rewrite.so

The cleanest way to segregate the Drupal configuration is creating a virtual host for it. An additional advantage of this approach is that Drupal will be served from the root path (/) and you won't need to use any rewrite rule to achieve the same result. Assuming the host name and the port where Drupal will be published is drupal.host.name:80, then create a file in /usr/local/etc/apache24/Includes named drupal.conf and define the skeleton of the virtual host:

<VirtualHost *:80>
  ServerName drupal.host.name

  # Drupal directory configuration placeholder
  
  ErrorLog ${APACHE_LOG_DIR}/drupal-error.log
  LogLevel warn
  CustomLog ${APACHE_LOG_DIR}/drupal-access.log combined
</VirtualHost>

In the default configuration of Apache in FreeBSD, any .conf file in this directory is included automatically, so that no additional code is required to add the virtual host to the web server configuration. In this fragment I've used an environment variable (${APACHE_LOG_DIR}) to separate some server configuration variables that could be reused in external scripts. To define environment variables, a .env file must be created in /usr/local/etc/apache24/envvars.d such as:

The Drupal directory fragment defines the DocumentRoot of the virtual host and some of the required options:

DocumentRoot /usr/local/www/drupal7
<Directory "/usr/local/www/drupal7">
  Options Indexes FollowSymLinks
  AllowOverride All
  Require all granted
</Directory>

The option AllowOverride set to All is required so that .htaccess files shipped with Drupal are taken into account by the Apache HTTP Server. In this fragment, the path of the Drupal installation directory of the FreeBSD port is used. If you installed Drupal using alternative methods (such as drush), update the path accordingly.

The complete virtual host configuration file is:

Finally, the Apache HTTP Server must be instructed to execute the PHP code contained in PHP pages and to do so we need to add a MIME/type for them adding the following line in httpd.conf:

<IfModule mime_module>

  # Content has been trimmed

  # Add MIME type for PHP
  AddType application/x-httpd-php .php

</IfModule>

Once all the settings are in place, Apache can be restarted and you can point your browser to http://drupal.host.name/ where the Drupal installation wizard will welcome you and will require you to input the database configuration and other Drupal website settings.

To restart the Apache HTTP Server, the following command can be used:

# service apache24 restart

Configuring Drupal behind a Proxy Server

Machines connecting to enterprise network often are not connected directly to the Internet but require the use of a web proxy server instead. Drupal can be configured to use a web proxy server by setting the following variables in ${DRUPAL_HOME}/sites/default/settings.php. If this file does not exist, copy the file default.settings.php (shipped with Drupal) into settings.php. The configuration variable that enable proxy support are the following:

Depending on your proxy settings, different values may be used.

Beware that although Drupal itself (Core) supports a proxy, many third-party modules still do not. One notable exception at the time of writing is the reCaptcha module which will not work without a direct Internet connection.

Setting Up Clean URLs

Last but not least, clean URLs support may be enabled. Drupal performs a sanity check and will not allow you to enable the Clean URLs feature if the test does not pass. However, I have found plenty of false negatives when running Drupal 7 on FreeBSD: if the Clean URL test fails in your installation, try checking if clean URLs are working and use the workaround described in the official Drupal documentation and forcibly enable Clean URLs.

Saturday, September 27, 2014

fswatch 1.4.5 - Release Notes

fswatch 1.4.5 has been released.

New features and bug fixes added since v. 1.4.0 are:

  • Add custom record formats.
  • Localize fswatch and libfswatch using GNU gettext.
  • Add Italian (it) localization.
  • Add Spanish (es) localization.
  • Fix Makefile.am because of broken link when DESTDIR installs are performed.
  • Fix bug in fswatch-run wrapper script for ZSH which caused last argument not to be split when passed to xargs.
  • Add batch marker feature to delimit the boundaries of a batch of events.
  • Add Texinfo documentation.
  • libfswatch API is now versioned.
  • Improved Autoconf checks.
  • The inotify monitor now waits for events and honours the latency settings.
  • Automaticaly generate the ChangeLog using Git.
  • Update autogen.sh to honour some commonly used environment variables.
  • The inotify monitor now provides the same functionality provided by all the other monitors.
  • Recursive directory monitoring is now implemented.
  • Version and revision is now determined dynamically from Git by ancillary scripts invoked by the GNU Build System.
  • fswatch does not compile on OS X < 10.9 because some required C++11 classes are not supported by the C++ runtime.
  • fswatch does not compile on OS X < 10.9 because some required C++11 classes are not supported by the C++ runtime.
  • The libfswatch library has been added with bindings for C and C++.
  • fswatch let users specify the monitor to use by name.

Friday, June 20, 2014

Installing Logstash v 1.4 (and Greater) on FreeBSD

In a previous post I described how to install Logstash (v. 1.3 and previous) on FreeBSD and in this post I will describe how to install Logstash v. 1.4 and greater.

Until version 1.3 included, Logstash was distributed as a single JAR file, and when version 1.4 was released a new packaging style was introduced. As a consequence, new instructions are required to properly setup Logstash in FreeBSD and registering it as a service. Further information about the new    distribution layout can be found in the Logstash release notes.

As seen in the previous post, a Logstash FreeBSD port exists, but it is currently outdated since it bundles Logstash v. 1.2. But while this could be used as a starting point for JAR-based Logstash installations (as we have seen, the update process only required updating the Logstash JAR), this is not possible with the new Logstash distribution because the included rc script will fail to work.

Edit: I've managed to patch the broken Logstash dependency and I'm waiting for the pull request to be merged upstream. In the meantime you can use an updated FreeBSD port I've created to install Logstash on FreeBSD 10.

Edit: The Logstash port has been updated and I'm the new maintainer. Also, the pull request solving a JRuby bug on FreeBSD has been merged to upstream and will hopefully hit a Logstash release soon.

Skimming through the original post is recommended because it provides general information about Logstash and FreeBSD which is required to properly plan and execute a Logstash setup.

Prerequisites

The essential prerequisites required to execute Logstash are:
The former is required because LogStash is a JRuby application while the latter, although not technically a requirement, is the recommended output for Logstash.

Installing Java

To install OpenJDK on FreeBSD you can use pkg to install a ready-to-use binary package:

# pkg install openjdk

Currently, this command will install an instance of OpenJDK v. 7 in both FreeBSD 9 and 10. If you'd rather install a different version, you can search the available packages and pick the one you prefer (command output has been filtered for brevity):

# pkg search openjdk
openjdk-7.60.19,1
openjdk6-b31_3,1
openjdk8-8.5.13_7
# pkg install openjdk8-8.5.13_7

Installing ElasticSearch

Logstash includes an embedded ElasticSearch instance you can use for standalone installations (see my previous post for an introductory view on Logstash operation modes). The required configuration to bootstrap the embedded ElasticSearch instance and to have Logstash use it as its outputs is described in the following sections.

Although simpler from the standpoint of the configuration, Logstash installations using separate ElasticSearch instances are out of the scope of this post.

Installing Logstash

Logstash installation procedure is fairly simple since it is distributed as a tarball:
  • Download Logstash from the official website.
  • Extract the tarball in the designated installation directory (my personal suggestion is to avoid /usr/local because it is used by ports and to use /opt instead).

Creating an rc.d Script

An rc.d script is required in a BSD system to register a service, define its configuration and have the rc framework manage its lifetime. The following script can be used as is or as a starting point to customise your own. If used as is, be aware that the script uses the following default values:
  • Installation directory: ${logstash14_home="/opt/logstash-1.4.1"}
  • Configuration file path: ${logstash14_config="/usr/local/etc/${name}/${name}.conf"}
  • ElasticSearch data directory: ${logstash14_elastic_datadir="/var/db/logstash14"}
  • Java home: ${logstash14_java_home="/usr/local/openjdk6"}
You can override any of the supported configuration values in the /etc/rc.conf file. If, for example, you want to use an alternate Java home path, just add the following line to /etc/rc.conf setting the desired value:

logstash14_java_home="/usr/local/openjdk7"

Testing the Service

To test the Logstash service, the following command can be used:

# service logstash14 onestart

To stop it, use:

# service logstash14 onestop

To help troubleshooting any problem you might find you can enable the Logstash log, setting the logstash14_log variable to YES in the /etc/rc.conf file:

logstash14_log="YES"

The log file location is specified by the logstash14_log_file variable, whose default value is set by the service rc file (only the relevant lines are shown):

name=logstash14
logdir="/var/log"
: ${logstash14_log_file="${logdir}/${name}.log"}

The log file location can be overridden setting the logstash14_log_file variable in the /etc/rc.conf file.

Enabling the Service

Note that the rc script described above does not enable the Logstash service:

: ${logstash14_enable="NO"}

If everything works, you can enable the Logstash service just adding the following line to /etc/rc.conf:

logstash14_enable="YES"

Wednesday, June 18, 2014

Pkg Update Fails in FreeBSD 9.2 Because of a Python Setuptools Conflict

Today I launched pkg to upgrade some binary packages installed in a FreeBSD 9.2 instance but suddenly pkg failed complaining about a locally installed python package (py27-setuptools-2.0.1) conflicting with the version required by it. The error began with the following statement, followed by a long list of repetitions of the same warning message:

WARNING: locally installed py27-setuptools-2.0.1 conflicts on /usr/local/bin/easy_install with:
- py27-setuptools27-2.0.1

All the software in this box was installed using pkg binary packages, so that at first this error sounded really strange to me.

Even though you use pkg to simplify package installations instead of compiling software from the ports collection, there is a file you should be aware of, especially if you are experiencing installation problems:

/usr/ports/UPDATING

This file contains important information about the update procedure and since binary packages are built from the port tree, the information applies even when installing with pkg.

A quick search starting from approximately the date of the last update of the affected machine pointed me in the right direction:

20140307:
  AFFECTS: users of devel/py-setuptools dependent ports
  AUTHOR: sunpoet@FreeBSD.org

  devel/py-setuptools is being used for every python ports (if USE_PYDISTUTILS
  defined) since r336553. Due to PKGORIGIN limitation, we cannot build one
  python port with python27 and the other with python33 since they require
  different setuptools versions which have same PKGORIGIN. With the addition
  of py-setuptools{27,32,33}, we could now have py27-foo and py33-bar coexist
  in one system.
  [...]

The suggested solution for pkg users is:

# pkg set -o devel/py-setuptools:devel/py-setuptoolsXX

where XX is the affected Python version. After running

# pkg set -o devel/py-setuptools:devel/py-setuptools27

pkg upgrade went fine and the problem was solved.

Saturday, February 15, 2014

fsw: a File System Event Monitor for OS X and *BSD Systems

A very often demanded feature by many different types of users is the possibility of receiving an event when a change in a specific file or directory occurs. One of the most common way to consume such an event in a UNIX(-like) system would be:
  • Having a command which lets you watch a set of files or directories outputting on standard output a detailed record for each event received.
  • Piping such a process to a shell script that reacts accordingly.

Many UNIX and UNIX-like systems provide kernel facilities, subsystems and programs providing the possibility of receiving file system change events:
  • Silicon Graphic's portable FAM.
  • FreeBSD's kqueue, originated in FreeBSD and available on many *BSD systems.
  • Linux inotify.
  • Apple OS X FSEvents API.

However, unlike Linux (where inotifywatch is available), neither OS X nor kqueue-enabled *BSD systems provide a user-land program for users to take advantage of those APIs. That's why I decided to fill the gap and write a small C++ program: fsw, a shell-friendly file system event notifier for OS X and kqueue-enabled *BSD systems, hosted on GitHub.

fsw

fsw will let you subscribe to file system change events on multiple files or directories:

$ fsw file-0 ... file-n

When a file system event is received, fsw prints a complete record of the event such as

Sat Feb 15 00:26:30 2014 - /full/path/to/file:created renamed modified changeOwner isFile 
Sat Feb 15 00:26:31 2014 - /full/path/to/file:created renamed modified changeOwner xattrMod isFile

that include the following information:
  • The timestamp when the event was received.
  • The full path of the changed file or directory.
  • The list of event flags, describing the type of change that occurred.

Watchers

fsw implements three kind of watchers:
  • A watcher based on the File System Events API, available only on Apple OS X.
  • A watcher based on kqueue, an event notification interface introduced in FreeBSD 4.1 and supported on most *BSD systems (including OS X).
  • The poll watcher, a watcher which periodically stats the file system, saves file modification times in memory and manually calculates file system changes.

The limitations of fsw depend largely on the watcher being used:
  • The FSEvents watcher, available only on Apple OS X, has no known limitations and scales very well with the number of files being observed.
  • The kqueue watcher, available on any *BSD system featuring kqueue, requires a file descriptor to be opened for every file being watched. As a result, this watcher scales badly with the number of files being observed and may begin to misbehave as soon as the fsw process runs out of file descriptors. In this case, fsw dumps one error on standard error for every file that cannot be opened.
  • The poll watcher, available on any platform, only relies on available CPU and memory to perform its task. The performance of this watcher degrades linearly with the number of files being watched.

Recommendations

  • On OS X, use only the FSEvents watcher.
  • If the number of files to observe is sufficiently small, use the kqueue watcher. Beware that on some systems the maximum number of file descriptors that can be opened by a process is set to a very low value (values as low as 256 are not uncommon), even if the operating system may allow a much larger value. In this case, check your OS documentation to raise this limit on either a per process or a system-wide basis.
  • If feasible, watch directories instead of watching files.
  • If none of the above applies, use the poll watcher. The authors' experience indicates that fsw requires approximately 150 MB or RAM memory to observe a hierarchy of 500.000 files with a minimum path length of 32 characters. A common bottleneck of the poll watcher is disk access, since stat()-ing a great number of files may take a huge amount of time. In this case, the latency should be set to a sufficiently large value in order to reduce the performance degradation that may result from frequent disk access.

Configuring the Latency

Events are passed to the watching process via a callback and every callback call pass an array of events. When creating the event stream, a latency is specified and it defines how many seconds d (a double value) elapse between a callback invocation and another. fsw lets users specify the desired latency using the -l/--latency options:

$ fsw -l 5 .

In this case, fsw receives change events every 5 seconds.

Other Options

fsw currently supports the following options:
  • -f, --format-time: Print the event time using the specified format.
  • -h, --help: Show this message.
  • -k, --kqueue: Use the kqueue watcher.
  • -l, --latency=DOUBLE: Set the latency.
  • -n, --numeric: Print numeric event mask.
  • -p, --poll: Use the poll watcher.
  • -r, --recursive: Recurse subdirectories.
  • -t, --time-format: Print the event time using the specified format.
  • -u, --utc-time: Print the event time as UTC time.
  • -v, --verbose: Verbose output.

Installing fsw

fsw is a C++ project using the GNU Build System and can be installed on any supported system (OS X, v. >= 10.6 or any *BSD system supported kqueue).

Regular users should download a release tarball, uncompress it, configure it and build it:

$ ./configure
$ make

If you're a developer and have the GNU Build System installed on your machine, you can clone the git repository to get the sources:

$ git clone https://github.com/emcrisostomo/fsw.git

Then, cd into fsw directory, bootstrap the GNU Build System, configure it and build it:

$ ./autogen.sh
$ ./configure
$ make

Finally, no matter you used a release tarball or the repository sources, you can install it system-wide to /usr/local by running the following command:

$ sudo make install

If you cannot install it on /usr/local or you just prefer to install it on a private directory, you can use the following command instead:

$ DESTDIR=/installation/path make install

Documentation

fsw ships with a detailed man page you can consulting using the following command:

$ man fsw

Getting Help or Giving Feedback

If you experience some issues or simply want to give your feedback, please contact me.

Wednesday, January 22, 2014

Installing Logstash on FreeBSD

Some time ago, I decided to centralise all the logs generated by a client's production systems to a syslog server and, after assessing a bunch of products, we chose Logstash (now part of the ElasticSearch family) as the tool to organise the unstructured logs into meaningful data structures which can then be searched, filtered and exploited.

The platform chosen to run Logstash is FreeBSD (9.x at the time), a rock-solid and very well documented UNIX-like operating system. Besides, it also ships a production-ready ZFS implementation which always comes handy in the data center.

Installation

Installing Logstash in FreeBSD is very easy because a good Logstash port exists and the binary package can be installed with a one-liner:

# pkg install logstash

The FreeBSD package manager will take care of installing Logstash and all its dependencies.

If the OpenJDK is installed during this process, a warning will instruct the administrator to mount the fdesc and proc file systems, since they are required for the correct operation of the OpenJDK. To make the change permanent, the following lines can be added to /etc/fstab:

fdesc  /dev/fd  fdescfs  rw  0  0
proc   /proc    procfs   rw  0  0

To mount them once after this change, execute:

# mount -a

To check they are mounted correctly, the mount command can be used:

# mount
[...snip...]
fdescfs on /dev/fd (fdescfs)
procfs on /proc (procfs, local)
[...snip...]

Configuration

The Logstash port performs a very good initial installation of Logstash and very few customisations are required in most cases.

Operation Mode

The Logstash service rc script is installed in /usr/local/etc/rc.d/logstash and supports three modes of operation (further information can be found in the official Logstash documentation):
  • standalone
  • agent
  • web
The operation mode can be set setting the logstash_mode variable in the /etc/rc.conf file:

logstash_mode="standalone"

The default operation mode is standalone does the following:
  • It launches a local ElasticSearch instance.
  • It launches the Logstash agent.
  • It launches the bundled Kibana web interface.
A standalone Logstash service is the easiest way to bootstrap a fully functional Logstash server with an embedded ElasticSearch instance. A more complex setup, for example, could contemplate a separate ElasticSearch server.

Embedded ElasticSearch

If the standalone operation mode is used, then an embedded ElasticSearch instance is launched. This instance stores its index files in the directory specified by the logstash_elastic_datadir configuration variable which, by default, is /var/db/logstash.

If you use the embedded ElasticSearch instance, you may want to mount a separate disk on /var/db/logstash for easier management in case you wanted to dedicate more space as the time passes. A ZFS dataset, in this case, is possibly the most flexible option available on FreeBSD (and other systems).

If you don't plan to store ElasticSearch indexes indefinitely, you're likely looking for a way to optimise them and remove older index entries.

Updating a Stale Logstash JAR

The Logstash port is not updated as often as Logstash is and you are likely going to get a pretty old version. Fortunately, the port lets you very easily run an updated Logstash binary. Beware the following:
  • Changing a ports' file may cause problems while upgrading a port.
  • Index files generated (or updated) by newer ElasticSearch instance may not be backwards compatible and rolling back a manual JAR upgrade may not be easy or possible altogether.
The Logstash service rc script uses the logstash_jar configuration variable to set the path of the Logstash JAR archive, the default value being

/usr/local/logstash/logstash-${version}-flatjar.jar

where ${version} is the version of the Logstash port.

An updated Logstash JAR archive can be downloaded and the value of the logstash_jar variable can be overridden in the /etc/rc.conf configuration file:

logstash_jar="/usr/local/logstash/logstash-1.3.3-flatjar.jar"

Always test a newer Logstash instance in a test environment.

Edited on June, 20th: Since version 1.4 Logstash is not distributed as a single JAR file any longer. I explored the tasks required to install the new version of Logstash on FreeBSD in a new blog post.

Adding Custom Java VM Options

Very often it's desirable to pass additional options to the Java VM but unfortunately the Logstash port service rc script doesn't allow you to do so. Unless, of course, you modify it.

I usually define a new empty configuration variable, called logstash_java_opts: in the service rc file /usr/local/etc/rc.d/logstash (added line in bold):

[...snip...]
: ${logstash_java_home="/usr/local/openjdk6"}
: ${logstash_java_opts=""}
: ${logstash_log="NO"}
[...snip...]

and then update the launch command (added fragment in bold):

[...snip...]
command_args="-f -p ${pidfile} ${java_cmd} ${logstash_java_opts}
required_files="${java_cmd} ${logstash_config}"

run_rc_command "$1"

Now, you can override the value of the logstash_java_opts variable in /etc/rc.conf:

logstash_java_opts="-Xmx2048M"

Once again, beware the consequence of changing the files of an installed binary package. In the meantime, I've asked the current port maintainer to consider a modification to support this use case.

Configuring Logstash

Logstash should now be configured according to your needs. The configuration file used by this package rc script is specified by the logstash_config variable whose default value is set by the rc script (only the relevant lines are shown):

name=logstash
: ${logstash_config="/usr/local/etc/${name}/${name}.conf"}

This value can be overridden setting the logstash_config variable in the /etc/rc.conf configuration file.

Detailed information and working examples can be found in the official Logstash documentation.

Testing Logstash

To start the Logstash service to test its configuration, the following command can be used:

# service logstash onestart

To stop it, use:

# service logstash onestop

To enable the Logstash log, the logstash_log should be set to YES in the /etc/rc.conf file:

logstash_log="YES"

The log file location is specified by the logstash_log_file variable, whose default value is set by the service rc file (only the relevant lines are shown):

name=logstash
logdir="/var/log"
: ${logstash_log_file="${logdir}/${name}.log"}

The log file location can be overridden setting the logstash_log_file variable in the /etc/rc.conf file.

Enabling the Logstash Service

When the configuration is correct, it can be enabled so that it's started during the system startup. To enable the Logstash service, add the following line to /etc/rc.conf:

logstash_enable="YES"

Further Readings

An updated version of this post was published on June 20th 2014 to describe the installation procedure of Logstash v. 1.4 (and greater) on FreeBSD.

Logstash (Up to at Least 1.4) Fails to Start on FreeBSD 10.0

Logstash (any version from 1.2.1 to 1.4.2) fails to start on FreeBSD 10.0 with the following exception:

Exception in thread "LogStash::Runner" org.jruby.exceptions.RaiseException: (NotImplementedError) stat.st_dev unsupported or native support failed to load
at org.jruby.RubyFileStat.dev_major(org/jruby/RubyFileStat.java:394)
at RUBY._discover_file(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/filewatch/watch.rb:140)
at org.jruby.RubyArray.each(org/jruby/RubyArray.java:1617)
at RUBY._discover_file(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/filewatch/watch.rb:122)
at RUBY.watch(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/filewatch/watch.rb:34)
at RUBY.tail(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/filewatch/tail.rb:58)
at RUBY.run(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/logstash/inputs/file.rb:125)
at org.jruby.RubyArray.each(org/jruby/RubyArray.java:1617)
at RUBY.run(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/logstash/inputs/file.rb:125)
at RUBY.inputworker(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/logstash/pipeline.rb:151)
at RUBY.start_input(file:/usr/local/logstash/logstash-1.2.1-flatjar.jar!/logstash/pipeline.rb:145)

It comes out that a long standing issue (affecting Solaris instead of FreeBSD) exists from quite a while: https://logstash.jira.com/browse/LOGSTASH-665. As far as I can see, the same problem now affects FreeBSD 10.0. I added a comment on that issue and opened another one: https://logstash.jira.com/browse/LOGSTASH-1819.

For the moment, Logstash should be run on FreeBSD 9.2.

Edit: I've managed to patch Logstash to work on FreeBSD 10 and I've sent a pull request upstream. Until the pull request is merged and Logstash updated (which it can take forever), you can use a new FreeBSD port I've created to install Logstash on FreeBSD 10. This port is meant to substitute the outdated Logstash port in the FreeBSD port collection. I'm in talks with the port maintainer and hopefully it should not take long.

Update and Workaround

Since the stack trace and the nature of the error itself suggested this is a JRuby bug rather than a Logstash one, I opened an issue (Issue #1754) on JRuby's GitHub Repository. Kevin Menard quickly replied and pointed me to the right track sending me several existing issues regarding a JRuby dependency (jnr-ffi) chocking on FreeBSD 10.0 libc.so ld script (libc.so is a symbolic link in earlier FreeBSD releases).

I couldn't try it until today, when Michael (no more details are given) left a comment to this blog post (see below) pointing at the same reason Kevin gave and the suggestion of trying it in a FreeBSD jail using ezjail.

I confirm that running Logstash in a FreeBSD 10 jail where the existing libc.so is substituted with a symbolic link to the corresponding binary in /lib solves the problem and provides an easy-to-implement workaround to install the latest Logstash release in a FreeBSD 10 environment.

Current Status

I wish to update this post since I've been asked many times about the status of this issue. It turns out that the problem with running Logstash on FreeBSD 10 seems to lie on jnr-ffi bug for which push requests have been sent at least three times:

I hope the push request is finally included upstream. If you are waiting for this issue as well, please vote it and make your voice heard.