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!

Read Source

Vincent Danen introduces two command-line programs, wall and mail, that allow you to send simple alerts and e-mail messages to users.

———————————————————————————————————————

The command line is a great environment for doing many things. It can be used to schedule commands, navigate directories, chain simple commands together to create complex commands, automate system monitoring, and more. The flexibility that the command line offers makes it worth investing the time into learning more about it, as its power far exceeds that of GUI operating environments.

CLI environments, especially with multi-user systems such as servers, provide a great way to communicate between users as well. Two tools in particular are of great value: wall, which will communicate messages on all active consoles, and mail, which will send e-mail via the command-line.

Wall is an interconsole “instant messenger” and is available on all Linux and UNIX systems. With it, you can broadcast alert messages, such as an impending system reboot or other maintenance process. Using wall is simple:

$ wall "just fooling around"

Broadcast message from vdanen (pts/16) (Mon Aug  4 20:47:03 2008):

just fooling around

Any user logged into the system will see the identical notice. The only exception is when a user has set their “message” flag off. For instance, to disable seeing these wall notices, use:

$ mesg n

$ mesg

is n

The mesg command takes exactly one of two arguments: y and n; if no argument is supplied, it shows the current message value.

Another useful tool is the mail command, which will send e-mail messages on the CLI. This can be used in conjunction with a command such as at to send reminder e-mails, or it can be used to send an alert when a task or command is complete. There are a few different providers of the mail command; some distributions use the mailx package, others use nail, others the original Berkely mail package. If mail doesn’t work as expected, read the mail(1) manpage. Most mail commands use the same syntax for the basics, however. To send an e-mail to an SMS relay to alert you of an upcoming meeting, use:

$ echo "20 minutes to meet with Sally." | /bin/mail -s "Meeting" sms@myhost.com

This will send an e-mail with the subject “Meeting” to sms@myhost.com; the body of the message will contain, “20 minutes to meet with Sally.” As has been illustrated, this can be used as a quick means of sending reminders, or it can be used to send the output of jobs when completed. The mail command takes standard input as the body of the message; other options can be used to specify CC and BCC recipients as well.

E-mail messages sent via mail are sent from the calling user on the system’s hostname; for instance, if the user account joe were sending this on the system foo.bar.org, then the e-mail would be seen to come from joe@foo.bar.org. Because of this, you may want to ensure proper message rules are in place that permit the relaying or reception of these addresses, or adjust the hostname of the computer accordingly.

Get the PDF version of this tip here.

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!

Read Source

Vincent Danen admires the Mac text-expanding tools like Typinator or TextExpander and has been looking for a similar tool in Linux. The best counterpart he found is a program called Snippits. Here are the basics.

——————————————————————————————————————

Perhaps one of my favorite features or tools with the Mac OS X operating system is the ability to use text-expanding programs such as Typinator or TextExpander. These programs allow you to type a keyword, regardless of the focused application, and have it expand into a custom string, set of text, or image. These text-expanding tools are a constantly-used time saver.

On Linux, there is nothing as comprehensive as Typinator or TextExpander on the Mac. There is one program that comes close, but is not as fluid or elegant as the Mac equivalents.

The program is called Snippits, and it also expands text based on predefined keywords. Snippits is a Ruby program and requires a little bit of effort to install, depending on the Linux distribution in use.

On Debian and Ubuntu it is easier to install because one of the prerequisite packages, xautomation, is readily available. On Mandriva Linux, the package is not available and so must be compiled from source, which is easy enough to accomplish.

With any distribution, at the very least you will need to install aspell and its development files; Ruby and its development files; and also whichever package provides Ruby’s gem support. On a Debian system, this can be accomplished by executing:

# apt-get install ruby ruby1.8-dev rdoc rubygems libruby-extras xautomation xsel aspell libaspell-dev aspell-en build-essential

On Mandriva Linux, because xautomation must be compiled from source, the following is required. Note the commands on a # prompt are executed as root, whereas those with a $ prompt should be executed as a regular user. As a result, the below is somewhat abbreviated; you may elect to use sudo (if you have configured it appropriately) or su to the root user when required.

# urpmi ruby-RubyGems ruby-devel aspell-devel aspell-en x11-devel png-devel

$ curl -O -L http://hoopajoo.net/static/projects/xautomation-1.02.tar.gz

$ tar xvzf xautomation-1.02.tar.gz

$ cd xautomation-1.02

$ ./configure && make

# make install

Once this is done, the Snippits gem must be installed and Ruby configured to use Rubygems by modifying the ~/.bashrc startup file:

$ echo 'export RUBYOPT="rubygems"' >>~/.bashrc && source ~/.bashrc

# gem install raspell

# gem install snippits

This will install the RASpell gem which is required by the Snippits gem, and then compile and install the Snippits gem.

Once this is completed, you can test Snippits. Snippits are stored in the ~/.snippits/ directory; each file is its own snippit. For instance:

$ mkdir ~/.snippits

$ echo "this is a snippit test" >~/.snippits/test

$ snippit test

this is a snippit test

$ ks test

this is a snippit test

$ this is a snippit test

The snippit [name] command outputs the contents of the file named [name]; in this case ~/.snippits/test. Using the ks command, the contents are not only outputted, but are also used as input for the next command.

Snippits allows for a lot of extra modifiers to really manipulate text, such as {enter} to type an enter keystroke or {tab} to enter a tab keystroke. For instance, if a snippit were defined in ~/.snippits/pstest as:

ps aux|grep {cursor}|wc -l

Executing ks pstest would result in the above being printed on the command-line with the cursor being positioned where the {cursor} string is located, exactly where you would want the cursor to be to type what to grep for.

The above has only illustrated Snippits’ use for command-line usage. It is possible to bind the ks command to a global hotkey in KDE or GNOME which would allow for Snippits to be used in any application. The drawback here, compared to the Mac-equivalent programs, is the need for the hotkey to begin with as there doesn’t seem to be a way to make Snippit automatically transform text based on the appearance of the keyword — perhaps in a future version. The application is under active development and definitely looks to have promise.

Get the PDF version of this tip here.

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!

Read Source

Using loops, you can take often-used commands that would normally be executed in sequence manually, and have them done automatically. Vincent Danen tells you what you need to know about getting started with loops.

——————————————————————————————————————

Creating complex commands on the command-line can be challenging the first time, but is worth the invested effort. One aid that assists in creating complex commands is loops. Using loops, you can take often-used commands that would normally be executed in sequence manually, and have them done automatically. This is perhaps one of the most useful features in command-line usage other than perhaps piping output from one command as input to another, or redirecting output of commands.

The use of loops and if/else statements will be familiar to anyone who has done any kind of programming. And while these loops can be used in shell scripts, they can also be used on the command-line itself. For instance, often I find myself executing the same command over again, but with a slight variation in arguments. Instead of executing the command once, hitting the up arrow when it’s completed, and changing one option, this can be automated to execute any number of commands in a row. It can also take advantage of using the output of other commands as input to constructing the loop.

For example, if you need to execute the same script with a varying argument, you could use:

$ for i in i586 x86_64; do seciurt 2008.1 $i foo.src.rpm; done

This command will call the seciurt script twice, the first time as seciurt 2008.1 i586 foo.src.rpm and the second time as seciurt 2008.1 x86_64 foo.src.rpm. In an instance where two arguments need to be changed in a logical format (i.e., calling seciurt to rebuild a src.rpm file for multiple distributions with the same two supported architectures), you would use:

$ for x in 2008.1 2008.0 2007.1; do for i in i586 x86_64; do seciurt $x $i foo-1.0-${x}.src.rpm; done; done

This calls seciurt six times; the first time would be as seciurt 2008.1 i586 foo-1.0-2008.1.src.rpm and the last time as seciurt 2007.1 x86_64 foo-1.0-2007.1.src.rpm. You will note that the variable $x is used two ways: $x and ${x}. The second is required to be called in that manner because there is no whitespace surrounding it and as such will match foo-1.0- instead of foo-1.0-2007.1.src.rpm, which can be seen by executing the following test:

$ touch foo1foo

$ x=1; ls foo$xfoo

ls: cannot access foo: No such file or directory

$ x=1; ls foo${x}foo

foo1foo

Remembering this “escaping” of variables can make for some very interesting CLI commands. The ability to nest loops within loops can also make things interesting with a little bit of creativity. Finally, you can use the output of other commands as input for the loop:

$ touch 1 2 3

$ for i in $(ls *); do echo $i; done

1

2

3

Here you can see the output of the ls command is used as arguments to the for loop.

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!

Read Source

Vincent Danen introduces Linux file management alternatives, Gentoo, Krusader, and Midnight Commander. Here are the basics about each if you want to try something different.

—————————————————————————————————————–

Many Linux users make use of the KDE or GNOME desktop environments and when it comes to file management, they don’t venture beyond using the environment-provided file management tools like Konqueror or Nautilus. Considering this is Linux, there are many other file management tools to choose from, some of which you may find preferable to the “defaults.”

Gentoo file manager

One such file management tool is called Gentoo, not to be confused with the Linux distribution of the same name. Gentoo hasn’t been updated in a few years, but it is still a solid file manager. Some distributions include it, so it is just an apt-get or yum command away; for others that do not include it, all you need to build it from source are the GTK+ development files and libraries. The latter will be installed with any GNOME system. To build from source, it’s a ./configure; make; make install away from usability.

Gentoo is nice in that it is a GTK+-based application with a dual-paned file view, reminiscent of old tools like Total Commander or Norton Commander. It is extremely configurable with a powerful file recognition system that allows you to map what happens when you double-click a file type, select which icons belong to what types of files, etc.

Krusader

For those who prefer using KDE, Krusader is another stellar file management tool. Like Gentoo, it is a dual-paned file management utility that is extremely customizable. The latest beta of Krusader is compatible with KDE4, whereas previous stable versions are written for KDE3. Some of Krusader’s notable features include impressive archive handling, advanced searching, an internal viewer/editor, file content comparisons and directory synchronization. It can also handle remote filesystems by using KIO slaves, which means it can mount SMB or FTP filesystems. Many distributions provide Krusader.

Midnight Commander

Finally, for those who want a file management tool very similar to Norton Commander and that operates on the CLI, Midnight Commander is the best choice. Midnight Commander is available for nearly all Linux distributions; the package may be named mc, which is also the name of the program. MC gives a dual-paned file view, each representing a different directory. When executed in a terminal under X, mouse clicks work, so if MC is your preference but you want to use it in a GUI, it’s still an option. Another nice feature of MC is that it still keeps a command-line open so you can use a combination of directory navigation and CLI commands, made even easier by using the tab key to switch active panes.

These are just three examples of many other file management, or “file commander” type programs available for Linux. Others include Tux Commander, XFE, and Gnome Commander. If the default file management tools don’t quite cut it, or if you prefer the dual-paned filesystem view, give one of these programs a try.

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!

Read Source