Install PacketFence 1.7 from www.packetfence.org. If you are using Red Hat EL5 or CentOS5, the easiest way to do so is to install the official RPM.
In this example, we set up VLAN isolation on a Cisco Catalyst 2960 switch (IP address 192.168.0.3). The PacketFence server's IP address is 192.168.0.10. Let's further assume that you are using the following VLANs and that these already have been created on your switch:
MAC detection VLAN
Enable the SNMP traps globally on the switch with the following commands:
snmp-server enable traps snmp authentication linkdown linkup snmp-server enable traps mac-notification snmp-server host 192.168.0.10 version 2c public mac-notification snmp mac-address-table notification interval 0 mac-address-table notification mac-address-table aging-time 300
Then, configure every access port PacketFence should be handling with the following:
switchport access vlan 4 switchport mode access snmp trap mac-notification added spanning-tree portfast
Edit the VLAN isolation configuration file /usr/local/pf/conf/switches.conf, so that it contains the correct SNMP community strings. Then, adjust the VLAN definition as follows:
vlans = 1,2,3,4 normalVlan = 1 isolationVlan = 2 registrationVlan = 3 macDetectionVlan = 4
And, finally, add a new section for your switch:
[192.168.0.3] ip = 192.168.0.3 type = Cisco::Catalyst_2960 mode = production uplink = 23,24
Next, you can do a communication test between PacketFence and the switch:
/usr/local/pf/bin/pfcmd_vlan -getVlan -switch 192.168.0.3 -ifIndex 10001
The next test is to determine whether the switch can send SNMP traps to PacketFence. Start snmptrapd:
service snmptrapd start
and observe the log file:
tail -f /usr/local/pf/logs/snmptrapd.log
Every time a device connects to and disconnects from the network, you should see a new line in the log file.
Now, configure PacketFence's access to VLAN 1, 2 and 3. Set the configuration of the switch port that PacketFence plugs into to “trunk mode”, and allow packets in VLAN 1 to pass through the switch without tagging. On the PacketFence server, add two new NICs that read and write 802.1q tagged packets for VLAN 2 and 3. Don't forget to add these new NICs to your configuration file /usr/local/pf/conf/pf.conf.
To simplify the installation, configure a DHCP service on the PacketFence box for VLANs 2 and 3. The DHCP server should return its own (VLAN-specific) IP address as both the gateway and the DNS server. Last but not least, set up a “fake” DNS service for VLANs 2 and 3 that responds to all queries with its own IP address. Now, verify that a host connected to the registration VLAN is able to obtain an IP address and that whatever DNS query it sends, PacketFence answers with its own IP.
If all these tests work fine, you can start setVlanOnTrapd:
service setVlanOnTrapd start
and look at the log file to verify that your devices, upon connection to the switch, are assigned to the correct VLAN:
tail -f /usr/local/pf/logs/setvlanontrapd.log
This setup should be transparent for already-registered devices, because they end up in the “normal” VLAN; unregistered devices will be assigned to the registration VLAN where all they can access is the PacketFence server that will show the captive portal with the registration screen.
PacketFence also integrates very well with wireless networks. As for its wired counterpart, the switch, a wireless Access Point (AP) needs to implement some specific features in order for the integration to work perfectly. In particular, the AP needs to support the following:
Several SSIDs with several VLANs inside each SSID.
Authentication against a RADIUS server.
Dynamic VLAN assignment (through RADIUS attributes).
SNMP deauthentication traps.
The deauthentication of an associated station.
We then can configure two SSIDs on the AP, the first one reserved for visitors and unregistered clients. In this SSID, communications will not be encrypted, and users will connect either to the registration VLAN or the visitor's VLAN (depending on their registration status). The second SSID will allow encrypted communications for registered users. The VLANs here are the “normal” VLAN and the isolation VLAN (if ever there are open violations for the MAC).
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released