The Linux Foundation will announce today the creation of LinuxCon, a conference set to take place alongside the Linux Plumbers conference in Portland, Oregon. Does the world really need yet another open source conference? As it turns out, the answer is probably yes. At least if the…
From mobile phones to network infrastructure to fun desktop applications, here’s a look at 10 products that embrace Linux and other open source ways of life.
From mobile phones to network infrastructure to fun desktop applications, here’s a look at 10 products that embrace Linux and other open source ways of life.
Ubuntu Geek: “Gufw is an easy, intuitive, way to manage your Linux firewall. It supports common tasks such as allowing or blocking pre-configured, common p2p, or individual ports port(s), and many others!”
The apachectl command is an often overlooked program that allows you a great deal of control over Apache processes. Vincent Danen explains the basics of this command, which you can use to debug or test Apache configurations.
—————————————————————————————————————-
The Apache Web server is arguably the best and most powerful Web server software available for any operating system. While many learn to edit the configuration files and configure or enable various modules, the bulk of what most people do with Apache is manage the content that Apache serves, with very little attention paid to what Apache itself can do.
Distributions provide initialization scripts for Apache that take the guesswork out of using it. For instance, service httpd start would start the server and an associated stop command would bring it down. These initscripts, while a convenience, largely mask the power of the command they are calling, namely apachectl.
The apachectl command is a rather overlooked program when it comes to working with Apache; however, it can be used to do some very interesting things. For instance, you can debug or test configurations by starting Apache with an alternative configuration file, leaving the working/production configuration untouched until changes can be tested. This can be accomplished with the -f option and the specification of an alternate configuration file:
# apachectl -f /etc/httpd/conf/httpd-testing.conf
This will start an Apache (httpd) process using the httpd-testing.conf file as the primary configuration file rather than the production httpd.conf.
A companion option here would be the -t option which performs a syntax check on configuration files, validating any changes you make. The command will warn if it detects any problems with the configuration file. Use it in conjunction with the -f option to validate in-progress configuration changes on non-default files: apachectl -t -f /etc/httpd/conf/httpd-testing.conf.
Another useful set of options are those that allow you to examine configuration content without actually opening and scanning configuration files. The apachectl -M command will list all loaded modules, those compiled-in and those that are shared. apachectl -l will display only those static modules that Apache loads; these would be the modules compiled into the httpd binary.
The apachectl -L option displays all available directives that Apache understands, and which module they are associated with. This is a great way to find out what options come from which module, and what they do. For instance:
# apachectl -L
<Directory (core.c)
Container for directives affecting resources located in the specified directories
Allowed in *.conf only outside <Directory>, <Files> or <Location>
...
The apachectl command also allows you to override directives on the command-line by using the -c option. This can be useful to temporarily test a new site or code. For instance, to override the default ServerLimit directive, use:
# apachectl start -c "ServerLimit 1024"
Other useful directives to override include DocumentRoot and Listen, among others.
Reading the apachectl manpage will provide other options and, hopefully, other ideas on how to put this often-overlooked tool to good use.
Get the PDF version of this tip here.
Vincent Danen is the Security Team Manager for Mandriva and lives in Canada. He has been writing about and developing on Linux for over 10 years.
Delivered each Tuesday, TechRepublic’s free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!
A group of developers has raced to market with Linux and Mac versions of Google’s Chrome web browser. But does it work?
Linpus Technologies is bringing this distribution, specifically designed for Asia, to the global stage with a more simplified user interface.
Finally, I succumbed to the siren song of Linux and OpenOffice and built myself a computer lab from old donated machines using only some blank CDs from WalMart, the latest Breezy Badger release of Kubuntu (www.kubuntu.org), and a bunch of very wary students. by Christopher Dawson
So I’ve lived with a Linux lab in a largely Windows enterprise for a while…Here’s why I’m thinking about going back. by Christopher Dawson
One long-running controversy in the open source community has to do with device drivers and whether binary modules (proprietary code provided by device manufacturers, such as Nvidia) should be allowed within the Linux kernel. Purists believe that including these closed-source driver modules violates the open source General Public License (GPL). Some kernel contributors have even called for an outright ban of these binary modules, which has met with resistance from the more practical-minded in the Linux community, notably by Linux Torvalds himself, who reportedly called it both “shortsighted” and “stupid.”
Obviously, limiting users of the Linux kernel only to the open source drivers that are available is not preferable. Linux aficionados want to use any hardware they darn well please, whether or not they have to use a closed-source driver to support it.
Riding into the breach between the purists and pragmatic, the Linux Driver Project launched in early 2007, headed up by Greg Kroah-Hartman. The LDP proposes a compromise, offering to device manufacturers:
…a group of Linux kernel developers (over 200 strong) and project managers (over 10) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 Linux kernel driver as an end result.
I read about this ongoing project in an interesting article from IT Pro in the UK, whose author Richard Hillesley makes the argument: “Open source drivers will become an imperative, rather than a choice, for device manufacturers who want to break into new markets and extend their user base.” Hillesley makes his argument for why manufacturers should drop their resistance to open source drivers (or at least, take advantage of the LDP’s offer) and reap the benefits of better maintenance, support, and the distributed costs of development.
