A Guide to Virtual Services
As Internet sites grow in number, some clients want to create a presence without dedicating a machine to the task. In many cases, a client may never get the amount of usage which would justify a dedicated machine. People like florists and civic event organizers may not have any other use for the machine, so the extra hardware would go to waste.
The solution to this problem is to use a single computer to serve multiple clients. If the machine is serving web presences, FTP directories, and e-mail services almost exclusively, a single machine with enough horsepower can easily handle the needs of several clients, especially those with low traffic.
However, this solution has a drawback, with which many are familiar. Although several domains can be easily pointed to a single host, the URLs will produce the same results regardless of which service, and which domain, was requested. For example, if tryme.com and comehere.com both pointed to the same host, http://www.tryme.com/ and http://www.comehere.com/ would produce exactly the same main page—clearly not what these organizations would have in mind.
But this problem has a solution—virtual services. A virtual service is exactly like a standard service (Web, e-mail, or FTP), but it provides different results depending on which target was selected, despite the fact that they all reside on the same machine.
This month, we examine how to set up and use a virtual web service. Next month we cover e-mail and FTP, as well as possible future capabilities. Keep in mind the Perl motto: “There Is More Than One Way To Do It.” As the Internet has grown, several alternatives have sprung up. This document describes only one method, and by the time you read it, there may be others, so look around before you decide on any one path!
Please note, in all the solutions described, I assume that you have at least two domain names registered and operating, and two IP addresses. You should have working routes to both IP addresses, and nslookup from any outside Internet host should return the correct IP address for each domain name. You can consult other references for information on how to do this.
IP aliasing is the key to the virtual services on the level of the operating system. As the intended audience of this article is Linux users and system administrators, I will present only the information pertinent to Linux. Other operating systems may or may not have the capability to do IP aliasing, and you should consult your documentation and other publications for information on them.
Under normal circumstances, only one IP address may be tied to each network device. The virtual services described in this article rely on having a separate IP address for each domain serviced. How, then, does one manage all the traffic with a single machine? IP aliasing makes this possible.
To enable IP aliasing you must first compile your kernel with IP aliasing support. If you don't already have the kernel sources, you shouldn't continue without them. Obtain a fairly recent kernel distribution from a suitable mirror site and unpack the archive, typically into /usr/src/linux. Then go into the directory and re-make the kernel. Be sure to answer “Yes” to the question about whether or not to support IP aliasing.
If you think your kernel might already support IP aliasing, a quick way to check is to verify the existence of /proc/net/alias* files. Once you have the support enabled, you simply need to configure the interfaces in a slightly different manner. Normally this would be done with a combination of ifconfig and route. The following is a common example:
/sbin/ifconfig eth0 10.1.1.10 <other options> /sbin/route add -net 10.1.1.0 gw 10.1.1.10 <other options>
This creates a setup for the eth0 device (which you should replace with whatever device you use for your connectivity) and adds a route for the local network (10.1.1.*) to go through it. (This will also automatically handle the route to the device itself.)
To handle IP aliasing, we simply add a colon and the alias number to which we want to refer. If we had obtained IP addresses 10.1.1.6 and 10.54.21.8 from our service provider, and we wanted them both to talk to our ethernet card connected to our T1 router, we would use:
/sbin/ifconfig eth0:0 10.1.1.6 <other options> /sbin/ifconfig eth0:1 10.41.21.8 <other options> /sbin/route add -net 10.0.0.0 dev eth0:0 /sbin/route add -host 10.41.21.8 dev eth0:1
This will set up two aliases for the Ethernet card, 0 and 1, each with a different IP address. All traffic to either IP address will be seen by any daemon listening to the Ethernet device, and traffic anywhere in the 10.* realm will be routed out through the first device, as a safety catch. You may need to modify these lines to support additional options and, perhaps, a default route. That is all there is to it!
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!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- 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