The Linux Router Project
By design, LRP is meant for low-level networking applications. To this extent, the stock Linux 2.0 LRP kernel is compiled with almost all networking options and several enhancement patches (for example, ipportfw). Next is a short list of default functionality available in the base. Understand that these features apply to any interface type Linux can use, from modem to wireless T1.
Full IP routing with numberless IP and multiple IP interfacing
Complete firewalling and IP accounting
Traffic shaping (low-speed links)
IP and Port (TCP/UDP) redirection with transparent proxy and IP load balancing
Extended Common NAT (IP Masquerade) as firewall rules
Media insensitive interface load balancing (EQL)
RIP, OSPF, BGP and other routing protocols (via gated and other packages)
IPX and AppleTalk support
Past these core functions, a Linux Router unit is quite viable for many server applications. One of the most popular is using the Portslave RADIUS client software (pslave.lrp) to host inbound Internet access modem pools, which give you functionality like the popular Livingston Portmaster series. Bind is packaged (bind.lrp) and does a fine job as a secondary or even primary DNS. Boa (boa.lrp) and thttpd (thttpd.lrp) are both small web servers that will fit on a 1.44MB LRP disk. Apache, though not packaged right now, could be hand fit.
On the client side of things, the VNC package will give you a single-disk Windows terminal. XFree86 is not yet packaged, but it certainly will be, allowing easy creation of X terminals. Linux Router also makes a good base for workstations that mount their file system from remote NFS or SMB (Samba) servers.
Understand that Linux Router is not the solution to all your computing needs. You wouldn't want to use it as your primary web server if you are an Internet Service Provider, or as a kernel hacker's development machine. But for backup services or where feature requirements are very specific (and administration skills scarce), it makes an efficient and sound choice.
While a “minimal” install of Debian Linux may have well over 5000 files, you would be lucky to break 500 with a very feature-rich LRP. The impact of this on administration and security is obvious; the entire system can be backed up and restored in less than a minute.
This minimal footprint coupled with RAM disk operation adds up to a large performance increase in operation and decrease in required hardware. The most mediocre 16MHz 386SX with 8MB of RAM, a 1.44MB floppy and no video card can handle most people's needs for light routing jobs. Few will have a need to climb past a 486 class CPU; however, with low-end Pentium class machines being so inexpensive, it certainly makes sense to do so.
Furthermore, with this default RAM disk approach, it is very difficult to be left with an unusable system. File system get corrupted? Flash the power. Everything just crashed? Flash the power. Cracker break in? Install your backup (in 30 seconds) and flash the power.
The other advantage of running from a RAM disk that people seem to overlook is, generally, it cannot break. Let's say you have 250 workstations with one path to the outside world. Do you want that path to depend on a mechanical device like a hard drive? Probably not. How about if that router sits between you and your game of Quake? Definitely not.
Some of the many reasons to use LRP over other Linux systems: fully administrable via high-strength encryption using secure shell and secure copy (ssh, scp), a huge routing feature super set and open source. These are things most commercial solutions cannot touch.
By now, I am sure you are probably excited to give Linux Router a try. Since it is now easier than ever to make a disk, you should do it.
All that needs to be done to get started is creating a file system and installing a boot loader on your boot medium. The most common choice for this is MS-DOS (FAT) and Peter Anvin's SysLinux. GRUB also makes a good boot loader. LILO is generally a poor choice, because unlike the former two, it cannot dynamically search for the kernel by name, and LRP does not have LILO available if you change kernels. Default syslinux.cfg and syslinux.dpy files are available at the LRP ftp site.
An LRP-capable kernel can be found in the kernel*.tar.gz archive. Choose an FPU (floating-point unit) or non-FPU kernel as needed and copy it to the disk as “LINUX”.
Copy the base and any additional packages; root.lrp, etc.lrp and log.lrp are required. modules.lrp is also needed if you are using a kernel with modules, as the provided LRP kernels do.
Finally, you must update the options passed to the kernel at boot time, commonly known as the boot loader's “append” line. A sample syslinux.cfg file looks like this:
display syslinux.dpy append=load_ramdisk=1 initrd=root.lrp \ initrd_archive=minix ramdisk_size=4096 \ root=/dev/ram0 boot=/dev/fd0,msdos \ LRP=etc,log,modules
The options after append= will be common to any boot loader you use. The LRP-specific options are:
initrd_archive=minix: initrd_archive is a kernel feature that lets you use tar.gz archives instead of raw images. This kernel patch is required in order to use LRP.
boot=/dev/bootdev[,fs]: this is the device name you are booting from. It is the device which linuxrc will try to mount to install any remaining packages. Optionally, you can specify the file system for the mount attempt. The boot line is semi-optional. linuxrc has a back-up list of devices to try to mount. It looks at /proc/filesystems for available file systems. Using boot= speeds up the boot process and ensures a mount if you are using an odd boot device.
LRP=etc.lrp,log.lrp[,modules.lrp][,package1] [,package2]...: these are the packages linuxrc should try to load at boot time. Remember that root.lrp is loaded by the initrd facility of the boot loader, so etc and log are the first packages listed here.
With your base prepared, you must add the needed kernel modules. Normally, one does this by booting the LRP disk, mounting a second floppy, copying the modules from that floppy to /lib/modules, editing /etc/modules and then using lrcfg to back up the modules package. Sound too hard? See http://www.linuxrouter.org/modmaker/ for a modules generation system. Just select the modules for the features and hardware you want; it will create a modules.lrp with the modules, their dependencies and an /etc/modules file configured to load all of them.
After boot and login, lrcfg will be started to help you get around to the files you need to edit. The configuration files for the base and packages are self-documented. You should be only a few minutes away from a working system.
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!
- Rogue Wave Software's Zend Server
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
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