Running Linux and Netfilter on Nokia IP Series Hardware
If the desktop PC has only one Ethernet interface, the Red Hat installer creates only one network config file for eth0, located at /etc/sysconfig/network-scripts/ifcfg-eth0. The Nokia has three network interfaces, however, so ifcfg-eth0 should be copied to ifcfg-eth1 and ifcfg-eth2 in the /etc/sysconfig/network-scripts directory. Each of these files needs to be edited to contain the correct interface names, IP addresses and MAC addresses. Interface eth0 under Linux corresponds to eth-s3 under IPSO, eth1 to eth-s4 and eth2 to eth-s5. To each of the ifcfg-eth[n] files add the line MACADDR=<MAC> where <MAC> is the original MAC address, as reported under IPSO before the Nokia disk was formatted. This mitigates the problem of the Ethernet driver not being able to read the MAC addresses directly out of the EEPROM chips.
If all has gone well up to this point, it now is time to shut down the desktop system and return the drive to the Nokia machine. Be sure to re-attach the top of the IP330 case to keep the CPU cool during intensive operations, such as a kernel compile. The four fans at the back of the machine are effective only when the case is sealed, and a good way to demonstrate this point is to try consecutive kernel compiles without the top attached. The CPU usually overheats and causes the machine to crash during the first compilation attempt. With the case properly secured, the number of consecutive kernel compiles has no affect on the stability of the machine, which is what one would expect.
Before booting the IP330, reinstall the desktop disk in the desktop PC and boot into Linux. Use the serial cable to connect the two serial ports on the two systems and run minicom. Recall the serial port settings we specified in /etc/lilo.conf, and configure minicom to match.
Now we are ready to boot Linux on the IP330. After the memory test is finished (which can be interrupted by pressing the ESC key twice) the familiar LILO boot prompt should be displayed and then the kernel boot sequence happily flows past. After the sequence is finished, init gets a chance to run and eventually a login prompt is displayed (see Resources).
Even though we are successfully running Linux on the IP330 at this point, it still is a good idea to recompile the kernel from scratch in order to put the operating system through its paces. This helps to ensure Linux is indeed stable on a hardware platform not specifically designed to run Linux. Besides, an added bonus is the 256MHz processor probably allows enough time to grab a quick sandwich during the recompilation process.
With the Nokia up and running, connect it to the network and test by pinging another host on the same network; use your default gateway or the Linux desktop machine, if necessary. Then execute the command:
iptables -A INPUT -p icmp -i eth0 -j LOG
Ping the host again, and this time iptables log messages should show up in the /var/log/messages system log when the icmp echo reply packets reach the firewall.
To test the filtering ability of iptables, execute the following command and then try to ping the host again:
iptables -A INPUT -p icmp -i eth0 -j DROP
The reply packets now should be logged and dropped, so the ping does not succeed. We have established that iptables can both log and filter traffic, but we have one more test to run:
iptables -I INPUT 1 -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
Execute the ping once more, and it should work once again even though both the log and drop rules still are in effect. This illustrates the stateful capability of iptables, in which packets associated with legitimate network traffic are let through and no log messages are generated (see Resources).
Depending on the specific application of the IP330 in your network, you may require software additional to what is listed here. But, at a minimum you probably want to download and compile the latest versions of the OpenSSL libraries, OpenSSH and the iptables user space code. If you require the Nokia to become part of an OSPF area, install the Zebra routing dæmon. If you require the Nokia to failover to another machine, install Keepalived and configure it to run VRRP. The VRRP implementation of Keepalived is particularly good. It is extremely easy to put one or all three interfaces on the Nokia into a "sync group" that failovers all interfaces if the link on any particular interface is lost. If you require the Nokia to form an endpoint for an IPSEC VPN, install FreeSWAN (see Mick Bauer's Paranoid Penguin columns from the January and February 2003 issues of LJ for an excellent exposition on FreeSWAN). One of the biggest advantages to running Check Point Firewall-1 is the GUI interface, which makes it easy to configure a firewall policy. Firewall Builder provides similar functionality for iptables, and Mick Bauer covers it in the May issue of Linux Journal.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide