Running Linux and Netfilter on Nokia IP Series Hardware
Now that we have Linux installed on the original Nokia disk, we can begin the process of customizing the installation to function on the Nokia hardware. The first step is to download and compile a custom kernel (see Resources). Boot into Linux on the desktop PC, login as root, gain network connectivity and download the latest stable kernel (2.4.20 as of this writing) from kernel.org. Extract the kernel tar archive and begin the compilation process with make menuconfig (possible because we installed the ncurses library) to configure the kernel build. It is important to ensure that only necessary portions of the kernel code are compiled into the resulting kernel binary. To this end, only the following features should be compiled in:
Processor type and features:
PCI device name database
System V IPC
Kernel support for ELF binaries
Enhanced IDE disk support
CMD640 chipset bugfix/support
RZ1000 chipset bugfix/support
Include IDE/ATA-2 disk support
Use multi-mode by default
Generic PCI IDE chipset support
Sharing PCI IDE interrupts support
Generic PCI bus-master DMA support
Intel PIIXn chipsets support
PIIXn Tuning support
Network packet filtering (replaces ipchains)
UNIX domain sockets
IP: Netfilter Configuration:
IP tables support
Connection state match support
Connection tracking match support
MASQUERADE target support
LOG target support
Network device support:
EtherExpressPro (eepro100, Becker driver)
Standard/generic serial support
Support for console on serial port
Ext3 journaling filesystem support
Virtual memory filesystem support
/proc filesystem support
Second extended fs support
After compiling the kernel with the standard make dep && make clean && make bzImage, our shiny new kernel should be around 610KB in size. Copy it to the /boot partition, configure LILO to see the new kernel binary and run lilo -t && lilo to reinstall LILO in the MBR.
By default the LILO boot loader does not send any kernel boot messages, init messages or system log messages over the serial port. Initially when we reinstall the IP330 drive back in the IP330, the only method we have available to interact with the machine is through the serial port. To configure LILO to send messages over the serial port, add the following line just before the timeout=50 line:
This instructs LILO to send messages out of /dev/ttyS0, which corresponds to serial port 0, at a speed of 9600 baud with one stop bit and no parity bits (see Resources). Also, there is no need to have LILO display the fancy semi-graphical boot message, so remove the message=/boot/message line. Now that we have finished editing /etc/lilo.conf, it is time to rerun lilo -t && lilo once more.
Configuring LILO to send messages over the serial port would not be of much use if, after the machine boots and init has run, there is no way to login. Therefore, we require init to spawn a getty process on /dev/ttyS0. Getty processes are spawned from the init process based on the /etc/inittab configuration file. The default Red Hat inittab file instructs init to start getty processes on ttys 1 through 6:
# Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6
Because there is no way to attach a keyboard to a Nokia IP330, all of these should be replaced with the following single line:
1:2345:respawn:/sbin/agetty -h ttyS0 9600 vt102
agetty, in contrast to mingetty, does not reference any configuration files and simply takes all configuration input from the command line. mingetty also is not suitable for use on serial lines, according to its man page.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
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