Download the PacketFence RPM from the SourceForge repository, and install it using:
rpm -ivh packetfence-1.6.2-1.i386.rpm
In /usr/local/pf, you will find two Perl scripts that will help you with the necessary configuration steps: installer.pl and configurator.pl. Change your current directory to /usr/local/pf, and execute installer.pl. The script, among other things, sets up the PacketFence database, installs all the necessary Perl modules (which are quite a few) and creates a user account for the Web GUI.
Now, the real configuration work starts. First, execute configurator.pl, and you'll be offered several choices. Choose the template configuration based on the testing mode. You'll be asked to supply several network parameters (DHCP servers, DNS servers and so on), and a basic configuration file, /usr/local/pf/conf/pf.conf, will be created. This configuration file contains only the differences you apply to the default configuration parameters saved in /usr/local/pf/conf/pf.conf.defaults. Have a look at conf/pf.conf.defaults to get an idea of the available options. To help you see what's going on inside PacketFence, add the following lines to /usr/local/pf/conf/pf.conf to increase the logging level:
Start PacketFence with service packetfence start. Have a look at /var/log/messages, and you should see that PacketFence started creating an inventory of all nodes on your network, as in the following example:
Jan 3 16:05:28 pf pf: update_hashes(5): UPDATE New node 00:07:e9:05:4c:f2 (192.168.0.1) Jan 3 16:05:28 pf pf: update_hashes(5): UPDATE New node 00:90:27:6a:71:ea (192.168.0.2)
/usr/local/pf/bin/pfcmd is the PacketFence command-line interface. Executing it without any further parameters shows a help screen with the available options. In order to show all nodes in the database, execute:
#/usr/local/pf/bin/pfcmd node view mac|pid|detect_date|regdate|lastskip|status| user_agent|computername|last_arp|last_dhcp|switch| port|vlan|dhcp_fingerprint 00:07:e9:05:4c:f2|1|2007-01-03 16:05:28|||unreg||| 2007-01-03 16:10:11||||| 00:90:27:6a:71:ea|1|2007-01-03 16:05:28|||unreg||| 2007-01-03 16:10:12|||||
Manually registering a node can be done with:
/usr/local/pf/bin/pfcmd ↪node edit 00:07:e9:05:4c:f2 status="reg",pid=1
You also can use pfcmd to access the documentation for every configuration parameter. To see the documentation for the logo parameter from the [general] section:
# /usr/local/pf/bin/pfcmd config help general.logo GENERAL.LOGO Default: /common/packetfence.gif Logo displayed on Web pages.
Have a look at the available reports using:
/usr/local/pf/bin/pfcmd help report
The os and osclass reports use PacketFence's DHCP fingerprinting feature, which tries to determine the operating system of every DHCP request (including the ones made by printers, VoIP phones, switches and so on).
/usr/local/pf/bin/pfcmd report os
shows the number and percentage of nodes on your network for every detected operating system. Note that the DHCP fingerprinting feature easily can be used to disallow access to your network by computers running specific operating systems.
PacketFence also features an administrative Web GUI, which, by default, is available on the secured port 1443. Direct your browser to https://<pf-host>:1443/. Once you enter the login/password you defined during the installation, you can start monitoring and configuring PacketFence through the GUI.
When you start enforcing the registration of nodes with PacketFence, all nodes on the network have to be registered before they can gain complete network access. This registration requirement applies to all gear with network access, including wireless access points and printers. So, before actually activating this option in the configuration file, it is wise to preregister those types of devices manually.
For computers with Web browsers, on the other hand, the registration can be done by the user through the PacketFence captive portal. The portal can verify login/password information through a htaccess file, Radius or LDAP, which we use in our example. In order to do this, you need to adapt the provided template /usr/local/pf/conf/templates/ldap.conf to fit your LDAP structure.
Because all your users will be redirected to the registration screen, it also is wise at this point to change the default PacketFence logo, which is shown on the Web pages, to your own company logo. This can be done by adding logo=/common/mylogo.gif to the [default] section in /usr/local/pf/conf/pf.conf and copying the file mylogo.gif into the directory /usr/local/pf/html/common/.
To activate the registration, incorporate the following parameters into /usr/local/pf/conf/pf.conf:
[trapping] testing=disabled detection=disabled [registration] aup=disabled auth=ldap
Now, restart PacketFence with service packetfence restart. You should see in /var/log/messages that PacketFence is trapping unregistered nodes by ARP-spoofing your network's gateway. From the client side, opening a Web browser and accessing any outside Web site should lead to a redirection to the PacketFence captive portal, which allows you to register the computer. You also can determine whether a client has been ARP-spoofed by executing arp -n -a (under Linux) on the client and checking which MAC is saved in the ARP cache for your network's gateway.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- Returning Values from Bash Functions