Building a Linux-Based Appliance
Have you ever solved the same system administration problem for many clients and wished you didn't have to reinvent the wheel every time? Or had the desire to build your own appliance but not known how? A recent consulting project gave us the incentive we needed to build our own appliance. By sharing the technical and business challenges we encountered and the solutions we implemented, we hope to offer some insight that will help you bring your own Linux-based appliance to market.
Our clients ask us to do a wide variety of IT projects, from setting up e-mail to implementing firewalls and VPN configurations. On a recent project, a customer asked us to look into the company's existing firewall configuration. They had a Cisco PIX firewall in place, but it was using an outdated version of the Cisco software. Given the costs involved in adding VPN support and purchasing the upgrade, they asked us to review with them the other firewall options on the market, including Check Point FW-1 and a Linux IPTables/IPSec solution. Based on their business requirements, they ultimately decided to go with a Check Point FW-1 firewall and VPN solution.
In implementing security solutions for other customers, and solving similar issues for each implementation, we had developed the idea of building a standalone firewall appliance. But we had not yet worked with the right customer to make an implementation possible. What finally made the decision to build an appliance easy was this particular customer's willingness to beta test the product.
In previous implementations we had developed some simple shell script-based tools to help automate common tasks for our customers and enhance the functionality of existing vendor-supplied tools. But as we developed the security appliance, we realized these shell scripts were simply not sufficient for a commercial product. As we developed a more advanced set of tools, we created a number of product features that should be useful for any appliance, not only a security appliance.
With our goal in mind, we put together the following set of product requirements. We knew our customers would require a true standalone box in which all administration functionality would be completely self-contained and provided by the appliance itself. There should be no need for a separate Windows- or Solaris-based client (e.g., the existing Check Point tools.) Moreover, the configuration software we provided would have to offer significant enhancements to the existing vendor-supplied tools. Our software would need to include backup/restore/undo functionalities. Given that our hardware platform would be engineered to be fully redundant and to support automatic failover (two complete systems in a single 1U form factor), our appliance would need to come with built-in, preconfigured failover software support. In other words, our box would need to support all the fundamental components of a true appliance solution.
Users of single-function boxes, such as routers, have long known the major advantage of a complete, standalone appliance solution: the administrator can log on from virtually any machine or terminal to make configuration changes. There is no need to have special Windows, Solaris or other client software available/installed to make changes. Moreover, the administrator does not need to ensure hardware and software compatibility, install and configure the operating system, and then add and configure application software and management clients. With an appliance everything is completely self-contained. The administrator simply drops the new box into the network, logs in via ssh or a web browser to configure a few key settings, and the box is up and running.
For Linux Journal readers, it goes without saying that Linux is the obvious choice for building appliances. It is worth mentioning that we also investigated Solaris and the Windows 2000 Server Appliance Kit as alternative platforms. Linux won because it was cost-effective, had a great community with good development support and had source code readily available.
Our V1 product does not include any changes to the kernel. Nevertheless, it was critical to know that as our customer base grows and our customers' requirements increase, we have the option of fine-tuning system performance and parameters through access to the source code. Moreover, there really is no better form of documentation than being able to look directly at the source code. And in the case of a bug or security hole, we are not dependent on any vendor for a patch or fix. In the worst-case scenario, we can make changes ourselves until a vendor supplied patch becomes available.
We also wanted to use a platform that was well tested and vendor supported; would be easily and positively recognized by our enterprise customers; was used by lots of other developers, so it would be easy to have questions answered; and, most importantly, was supported by the vendors whose software we would be using on the appliance--in this case, Check Point. So while using SuSE was intriguing, Checkpoint's default support for Red Hat made Red Hat the clear choice for our product.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- 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
- Google's SwiftShader 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