Hello!

I have a small query. I want to log into a Linux machine, set a process = running, and log out again, leaving the process running. It has been = suggested that I can do this by simply using 'nohup command &' but this = didn't work, because the process was killed as soon as I logged out = again.

Any help would be greatly appreciated.

Andy

screen with autodetach mode turned on would work nicely. We use it here all the time. -- Heather

"Linux Gazette...making Linux just a little more fun!"

Courtesy Linux Today, where you can read all the latest Help Dex cartoons.

Copyright © 2000, Shane Collinge
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

First of all, check his web site DiBona.com. Now delight yourself as Olinux did, while getting to know the personality of Chris DiBona, the President of Silicon Valley Linux Users Group, Chief Linux Evangelist at VALinux and Grant Chair at Linux International.

Olinux: Tell about your career: college, jobs, personal life (age, birth place, hobbies)

Olinux:When did you started working with Linux? What was your initial motivation and how do you see it nowadays?

DiBona: I first discovered linux when I was a computer science student at George Mason university. I had to write a client server application under linux that used IPC. I start development in the schools Sun lab and found that , when I could get a station, they were very slow.

I installed linux on my machine at home (a 486-25) and went to town. Linux was responsive and beautiful and I was able to complete the homework very quickly and have a good time doing it. I also learned a ton about my computer by doing this.

This was in late 1994, I think. Nowadays, I use Linux for everything from email (I get 500+ emails a day), surfing, and to a lessor degree , video games. I still program under linux for fun, too. I see it as a complete system, now. I have a machine on the net now that hosts my personal site (DiBona.com) and a number of sites for my friends, all running linux of course.

Olinux: How does it feel to be a Linux Evangelist and live professionally for the cause?

DiBona: It undoubtably the coolest job I've ever had. I also get to work with some of the coolest people in computing, both here at VA and in the Linux world at large. I consider myself very lucky.

Olinux: What are the main personal achievements on your career? cite some highlights? did you get any awards as an individual or representing a company?

DiBona: Great career acheivments would include my adminisstration of VA's community outreach program during our public offering. I felt it went really well and am proud for my part in it. AT VA I've had the chance to work with the different departments and help staff them with talented smart people. Other than that, I recieved an award from Linux Journal for my role as co-editor of the book "Open Sources" and I was able to help the EFF with the CDVD cases in California and New York. Also, I've really enjoyed my work with Linux International.

Olinux: How was SVLUG.org created? Who was the group and what were the ideas that guided SVLUG.org start? How do you explain the fast growth of SVLUG.org? Show us some brief facts/work/people that contributed to this extreme progress?

DiBona: SVLUG started 12 years agao as a unix on pc group, concentrating on SCO and XENIX and the rest. It was started by a fellow named Dan Kioka, who was the president of the group. Dan ran the group for 10 years when Ben Spade took over as the president and I as the Vice President about three years agao. When Ben took over, Ian Kluft found us space at Cisco to meet and the larger venue, combined with teh growth of linux and the speakers we had access to in the valley all contributed to the growth of the group. About 1 year ago I took over the presidency from Ben and it's been pretty easy going ever since. The biggest challenge on rnning such a large group is mostly the venue, Cisco has been very good about this though.

Olinux: What are your responsibilities at VALinux and SVLUG.org? How did you become Linux International webmaster and what were you main accomplishments as webmasters?

DiBona: I bacame the LI webmaster and then the grant chair mostly because I was willing to do the work. There are a lot of jobs in the linux community that can be done by anyone provided they are willing to put the time in. John Mark Walker is now the webmaster for LI and I get to concentrate on making the grant system at LI work better now that LI is incorporating and such.

Olinux: How is SVLUG.org organized? Try to give us an idea of how SVLUG.org. works? How is the coordinated and managed (servers, directories, contribution, staff payment)? How many people are involved? What are the main problems? Does SVSLUG.org has a central office somewhere or a HQ?

DiBona: SVLUG is all volunteer, the servers were donted by VA back before I even worked for them. There is no treasury, and no membership fees. Our group's insurance comes from our parent group the Silicon Valley Computer Society. As far as coordination goes, it's jsut a mailing list that we all subscribe to and we all basically work together to get teh meeting happeneing. The installfests are run by Brian , I'm responsible for facilities, Sam handles speakers, Michael and Marc handle the machine and mailing lists and we have a team of web people (Amy, Lisa and Heather) who handle site updates. Main problems is that everyone is very busy with our day jobs, which can lead to some frustrating times, but the meetings still come off, so I'm happy.

Olinux: How many people have subscribed its mail discussion list? how does users help SVSLUG? And how user are motivate to help? all the staff is compounded by volunteers?

DiBona: There are about a thousand on the announce list and 200+ on the discussion list. About 250 people come to each meeting.

Olinux: In your opinion, what ae the most notable results either of SVLUG or Li.org work promoting Linux platform?

DiBona: Putting a friendly face on linux is the important job of LUGs and LI in genereal. It a great thing to be able to tell anyone who emails me or calls me regarding Linux to refer them to a local person who just wants to help out. That's one of the things that really elevates Linux.

Olinux: What are the companies that sponsor or maintain SVLUG.org? What is VALinux's role on the site?

DiBona: The full list of sponsors and their roles can be found here: sponsors. Quite a who's who! Anyhow, VA's role is donating my time, bandwidth and a machine and a ton of t-shirts now and then. Any usergroup on the planet should contact me and we'll get boxes of stuff for you to give away at your meetings.

Olinux: What are the programs (database & scripts languages) use for SVLUG.org development? How difficult is to manage this database?

DiBona: Mailman for the mailing list, apache and perl for the web site. It's pretty easy to handle.

Olinux: How many daily page views and what is the number and type of servers used to keep SVLUG.org online?

DiBona: Gosh, I'm not sure really about the page views, SVLUG.org runs on one pIII 500mhz system with 128mb of ram. The old machine, a 486 was slashdotted three times with no problems. The current machine has an uptime of 210 days!

Olinux: In your opinion, what improvements and support are needed to make Linux a wide world platform for end users?

DiBona: More video-games :-) Well, I'd say further development of the desktop metaphors like gnome and KDE and then we'll get the desktop the way we own the internet server market.

Olinux: IDC has showed that despite the tendency of Linux to become the next dominant OS by 2004, still the expected revenues generated are regarded extremely low. does it means that Linux won't ever play a major whole as a commercial and profitable option for companies?

DiBona: Well, VA just completed a 50.7 million dollar quarter and we're not going to stop. I can't comments for the red hats and such of the world, but we intend to do very well. Linux will continue to grow, and the linux industry will contine to grow with it.

Olinux: What are your forecasts about Linux growth? Do you have any breaking news about linux mass deployment in china or any other country?

DiBona: Nope, Linux is and will continue to be everywhere. More so with everyday. Like John "maddog" Hall says: "Linux is inevitable".

Copyright © 2000, Fernando Ribeiro Corrêa
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

Quentin Cregan is one of the key developers of VALinux' SourceForge Project. Currently, there are 7559 ongoing projects and more than 50000 registered users, building a powerful programmer's network community. SourceForge hosts Open Source Projects and supports thousand of users by providing many tools to allow collaborative work.

Olinux: Tell us about your career: college, jobs, personal life (age, birth place)

Quentin: I currently live in Brisbane, Australia - and work via the 'net.

Olinux: What are your responsibilities at Source Forge? Are there any full times workers?

Quentin: Currently I'm a cross between Support Monkey, FTP Admin and Developer. The staff are all reasonably multitalented =) Fairly able to turn their hands they doing whatever is necessary. There are currently six core staff members that are paid full time.

Olinux: How was SourceForge created? What was the main ideas in the begining? Who the initial group got together? Are any physical HeadQuarters?

Quentin: SourceForge was initially conceived as a project called "ColdStorage". CS was targeted at making permanent archive of every CVS tree for every Open Source project on the planet. That idea got slightly modified by the original founding members of the SourceForge project, along with input from VA Linux Systems' staff. The result is what you have today. The initial group was Tony Guntharp, Drew Streib, Tim Perdue and Uriah Welcome - who are all based out of SourceForge's official HQ - VA Linux Systems in Sunnyvale, California.

Olinux: How is Source Forge organized? Give us an idea of how it works. In terms of the division of responsalities, what are the main groups involved?

Quentin: SourceForge is made up of developers, sysadmins and community contacts.

Dan Bressler and Jim Kingdon try to make sure that we don't stray too far from the needs and wishes of the Open Source community. Uriah Welcome and Chris Endsley take care of the Systems Administration, and make sure that everything is working up to scratch. If not, their pagers wake them up at disgusting hours of the morning. Tim Perdue is the main PHP developer, along with some contributions from me. I handle mostly of the support reqs, and any other odd job that seems to crop up.

Olinux: How often and where the group responsible for key decision meet? those meets take place on any specific place or over the internet?

Quentin: While we're in constant dialogue via both IRC and email, we also have weekly telephone conferences. Although, these days, most people are physically in California, these meetings seem to be more face to face pizza eating events with one poor Australian on the phone, than a "teleconference".

Olinux: How the work is coordinated and managed (servers, directories, funding, staff payment)? How many people are involved? What are the main operating problems?

Quentin: The work, machines and bandwidth is sponsored by VA Linux Systems. The main problems we're facing are growth and ensuring total redundancy. We're currently undergoing a process of making sure that even if we lose our main fileserver (1tb, yes, 1tb), we can keep going with only a momentary loss of service.

Olinux: How many projects are currently open? How are projects development evaluated? Are any special policy to shut down and clear old projects?

Quentin: There are currently 7,450 or so hosted projects, shared between 50,442 registered developers. Old projects are deleted on request. However, our deletion process is more "archival" - keeping with the original ideas of Cold Storage. While development may freeze, the project itself is not actually physically deleted, merely shelved.

Olinux: What facilities are offered for the developers (acounts, machines, lists, email, links)?

Quentin: All developers on projects are offered: access to our compile farm (server cluster) - for compiling and testing across clusters. A shell account on our main development server, an @users.sourceforge.net email alias, as well as access to some great project management tools. We're trying to make everything that a developer could possibly need available to remove any and all overheads from software development.

Olinux: What are the steps for a certain project to be accepted as part of Sourceforge? are there any special criteria as being an open source software, non commercial? all of them are accepted?

Quentin: A project and an Open Source license. For a list of accepted Open Source licenses, please check out http://www.opensource.org. We're aiming to be a development host for as much of the Open Source community as possible.

Olinux: Why should a developer put his project on SorceForge instead of put it into another place?

Quentin: Apart from the developer services listed above, SourceForge has some fantastic web based tools. With SourceForge, you don't have to worry about finding webspace, or if your FTP server will be flooded with downloads. We provide the projects with a high capacity download server, which we're yet to see flooded. We also provide CVS trees to every project so that they can have their own revision control in their code. On top of all this - there are the web based and collaborative tools. The site itself allows you to manage news releases about your project, task management, document management, bug tracking, support management and much more. You can also receive code patches through the site, and set up mailing lists and news forums for discussion about your project.

Olinux: Does Sourceforge has any key strategic alliances with companies? Does any private company other company besides VALinux support Source Forge? Are the any profitable activities?

Quentin: SourceForge has helped numerous groups and companies with both Open Sourcing their code, and helping out with hosting bigger projects that have outgrown their main developer's DSL connection. For example, we're helping out Hewlett Packard with their moves toward Open Sourcing their printer drivers. We've also helped out projects like Mozilla, KDE, XFree86, and MySQL by supplying some extra hardware and support to help get their code out to everyone.

VA Linux is our primary supporter, and I believe they offer some value added services to private companies that wish to implement SourceForge locally. You'd really need to speak to one of the cool guys in VA corporate to ask about that.

Olinux: what are the main projects are under way? are there any commercial projects payed by companies? What role does sorceforge play in the Open Source world these days?

Quentin: Some of the most active projects on SourceForge include Crystal Space - a 3D engine, Mesa3D, FreeCraft, Python, FreeNet and more. This are listed on the front page of the site. SourceForge's role in Open Source appears to be becoming (hopefully) the base carrier of content. Geocities for Open Source, if you like =) We think it's great that so many developers can come to one place, and find so much freely downloadable and modifiable software.

Olinux: how the development is coordinated? deadlines & guidelines established? is there a special testing procedures before the changes are added to the core code? are there any special quality control, auditing on code produced? what are the analysis and programming tools used?

Quentin: Development of the SourceForge codebase is coordinated through a central CVS tree. All the code is fairly thoroughly checked by the developers, and through a testing process on our staging server before it is pushed live. Of course, there is sometimes the odd bug that has been left that gets found by one of site's users.

Olinux: What is the operating system used to run the project? Just Red hat? Why did SourceForge pick the software tools, PHP and MySQL, instead of others like Perl and Postgres? What kind of factors did most influence this decision?

Quentin: With the exception of the BSD machines in the compile farm, the servers all run VA Linux Systems' customised version of RedHat. It has a few slightly modified versions of software to work better on VA's servers.

PHP and MySQL were picked for different reasons. PHP was chosen because it was the right tool for the job, and requires little machine overhead. If we'd run the site as a Perl CGI, the footprint of loading a perl parser for every hit would be a tad, large, to say the least.

MySQL was chosen mainly because of its speed. Although this required the sacrifice of subselects and transactions - we've managed to work around this. There is a good article by Tim Perdue at http://www.phpbuilder.com/columns/tim20000705.php3 that outlines the benefits and detriments of using PostgreSQL and MySQL. This article also covers some of the reasons why MySQL was chosen for SourceForge.

Olinux: what are the main steps toward a better software concerning the project development are still under way? are there any expected turn point in terms of future technology, better output or procedures used?

Quentin: We're always listening to user feedback and wishes through our feature request forum. From here, we get a lot of ideas as to what users really wish to see in the site, and we try our best to make as much of that happen within our schedule.

Olinux: has the project received any special awards? What it represented?

Quentin: I believe we've won a few awards for being a cool site. The list needs to be updated, there's currently a link on http://sourceforge.net/docs/site/awards.php

Olinux: What is the project security policy for servers protecion? Tell us about major problems in keeping your servers secure? Is the project always exposed to hacker attacks or most of them already belong to the project?

Quentin: We're always working on improving monitoring and security tools. We've been the recipients of numerous attacks (DoS, hack attempts, etc.i) This is where we really rely on our SysAdmins, as well as some of the great security tools that are available for Linux.

Olinux: In you opinion, how much Linux/Os community has grown and how do you oversee its future?

I started using Linux back around kernel 1.0.something and haven't been back. Since then, the community has exploded around the project, which has been great to see. We've now got decent looking Window Managers, more features and greater acceptance, which has been great to see.

Olinux: What are the main internet technologies that you consider extremely interesting or relevant advance for technology information?

Quentin: I think the advent of the Internet as a collaborative community has been fantastic, and unprecedented. I personally can't wait for further advances in voice recognition.

Olinux: Send a short message to programers in Brazil that work in Free Software/Opensource projects and to OLinux user's?

Quentin: Thanks. To all developers in all countries - they've helped to make SourceForge what it is. Not only that, they've no doubt helped to bring inspiration to people learning how to code around the planet. As to people working on those projects, if they aren't already hosted on SourceForge, why not?! Let us know what we can do to make SourceForge better for the community as a whole and we'll do it!

Copyright © 2000, Fernando Ribeiro Corrêa
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

What is cryptography?

Encryption is the transformation of data into a form that is (hopefully) impossible to read without the knowledge of a key. Its purpose is to ensure privacy by keeping information hidden from anyone for whom it is not intended.
Decryption is the reverse of encryption; it is the transformation of encrypted data back into an intelligible form.

Encryption and decryption generally require the use of some secret information, referred as key. Some encryption mechanisms use the same key for both encryption and decryption; others use different keys for the two processes.

Cryptography is fundamentally based on so called hard problems; i.e. problems that can be solved only with a large computation waste. Some examples are factoring, theorem-proving, and the "travelling salesman problem" (finding the route through a given collection of cities which minimizes the total length of the path).

There are two types of cryptosystems: secret key and public key.
In secret key cryptography (or symmetric cryptography) the same key is used for both encryption and decryption. The most popular secret-key cryptosystem in use today is known as DES (Data Encryption Standard), developed by IBM in the middle 1970's.
In public key cryptography, each user has a public key and a private key. The first one is made public and the second one remains secret. The public key is used during encryption, while decryption is done with the private key. Today the RSA public key cryptosystem is the most popular form of public key cryptography. RSA stands for Rivest, Shamir, and Adleman, the inventors of the RSA cryptosystem.
Another popular public key technique is the Digital Signature Algorithm (DSA), though it can only be used for signatures.

Public key cryptography

In secret key (or symmetric) cryptography the sender and receiver of a message know and use the same secret key: the sender uses the secret key to encrypt the message, and the receiver uses the same secret key to decrypt the message.
Using a similar system the main problem to solve is the key management problem, or getting the sender and receiver to agree on the secret key without anyone else finding out. Anyone who intercepts the key in transit can later read, modify, and forge all messages encrypted or authenticated using that key.

In order to solve this problem, Whitfield Diffie and Martin Hellman introduced the concept of public key cryptography in 1976. In their system, each person gets a pair of keys, one called the public key and the other called the private key. The public key is published, while the private key is kept secret. The sender and the receiver don't need to share any secret information because all communications involve only public keys: no private key is ever transmitted or shared.
Anyone can send a confidential message by just using public information, but the message can only be decrypted with a private key, which is in the sole possession of the intended recipient.

The communication scheme is the following: when A wishes to send a secret message to B he uses B's public key to encrypt the message and sends it. B then uses his private key to decrypt the message and read it. Anyone can send an encrypted message to B, but only B can read it (because only B knows B's private key).

In a public key cryptosystem the private key is always linked mathematically to the public key. Therefore, it is always possible to attack a public key system by deriving the private key from the public key. Typically, the defense against this is to make the problem of deriving the private key from the public key as difficult as possible. Some public key cryptosystems are designed such that deriving the private key from the public key requires the attacker to factor a large number; in this case to perform the derivation is computationally infeasible because multiplying two prime integers together is easy, but as far as we know, factoring the product of two prime numbers is much more difficult.
That is the reason because factoring is the underlying, presumably hard problem upon which several public key cryptosystems are based, including the RSA algorithm.
It has not been proven that factoring must be difficult, and remains a possibility that a quick factoring method might be discovered, though this possibility is today considered remote.
In general, the larger the number the more time it takes to factor it. This is why the size of the modulus in RSA determines how secure an actual use of RSA is; the larger the modulus, the longer it would take an attacker to factor, and thus the more resistant the RSA modulus is to an attack.

PGP (Pretty Good Privacy)

PGP is a program developped by Phil R. Zimmermann that allows you to communicate in a secure way over an insecure channel. Using PGP you can easily and securely protect the privacy of your data by encrypting them so that only intended individuals can read it.
PGP is based on public key cryptography: two complementary keys, called a key pair, are used to maintain secure communications. One of the keys is designated as a private key to which only you have access and the other is a public key which you freely exchange with other PGP users. Both your private and your public keys are stored in keyring files.

Before you begin using PGP, you need to generate this key pair.
After you created a key pair, you can begin corresponding with other PGP users. You will need a copy of their public key and they will need yours. The public key is just a block of text, so it's quite easy to trade keys with someone. Some standard techniques are including your public key in an email message, copying it to a file, or posting it on a public or corporate key server where anyone can get a copy when he need it. After you generated your key pair and exchanged public keys, you can begin encrypting and signing email messages and files.

Making a key pair

The following informations and commands refer to PGP 5.0i. Some changes may occur using a different PGP release. Informations about getting and installing the program are not covered in this article.

In order to use PGP features, the first operation you must accomplish is generating a key pair. From the command line enter:

 
pgpk -g

You must reply to some question in order to generate your keys:

• The algorithm to use in the encrypting messages (DSS/DH or RSA).

• The key size, or the number of bits used to construct your digital key. A larger key is stronger but it takes more time to encrypt and decrypt. Unless you are exchanging extremely sensitive information you are safe using a key composed of 1024 bits.

• Enter your user ID. It's not absolutely necessary to enter your real name or even your email address. However, using your real name makes it easier for others to identify you as the owner of your public key. For example:

   
  Matteo Dell'Omodarme <matt@martine2.difi.unipi.it>
  

  If you do not have an email address, use your phone number or some other unique information that would help ensure that your user ID is unique.

• Enter a passphrase, a string of characters or words you want to use to maintain exclusive access to your private key.

The generated key pair is placed on your public and secret keyrings in your $HOME/.pgp directory. Here you can find the file pubring.skr, containing the public keys and the file secring.skr, the file of your secret key.

pgpk is the command to use in order to manage public and private keys for PGP. So you can extract your public key from your keyring in such a way:

pgpk -x my_username@my_hostname > my_key

pgpk -a keyfile

pgpk -r newuser@new_hostname

Encrypting and decrypting with PGP

pgpe encrypts and signs files using public key cryptography, or encrypts files using conventional cryptography.
The simplest use of the command is the following:

pgpe text_file newuser@new_hostname

• -a, --armor:
  Turn on "ASCII Armoring". This outputs a text-only version of your encrypted text. This makes the result safe for mailing, but about 30% larger.

• -f:
  Stream mode. Accepts input on stdin and places output on stdout. If no files are specified as arguments, PGP executes in this mode by default.

• -o outfile:
  Specifies that output should go to outfile. If not specified, output goes to the default filename. The default filename for each input file is the input filename with ".pgp" appended, unless ASCII Armoring is turned on, in which case it is ".asc". It is an error to specify multiple input files with this option.

• -t:
  Turns on text mode. This causes PGP to convert your input message to a platform-independent form. It is primarily for use when moving files from one operating system to another.

pgpv decrypts and verifies files encrypted and/or signed by PGP.
In order to decrypt a message encrypted using your public key enter the command:

pgpv text_file.pgp

• -f:
  Stream mode. Accepts input on stdin and places output on stdout. If no files are specified as arguments, PGP executes in this mode by default.

• -o outfile:
  Specifies that output should go to outfile. If not specified, output goes to the default filename. The default filename for each input file is the input filename with the ".pgp" ".asc" or ".sig" removed. It is an error to specify multiple input files with this option.

Configuring Pine to handle PGP messages automatically

An useful option of the the mailer Pine makes possible to handle automatically the encryption of outgoing messages and the decryption of the received ones. In the file $HOME/.pinerc search for the lines starting with display-filters and sending-filters and do the following insertions:

# This variable takes a list of programs that message text is piped into
# after MIME decoding, prior to display.
display-filters=_BEGINNING("-----BEGIN PGP MESSAGE-----")_ /usr/bin/pgpv

# This defines a program that message text is piped into before MIME
# encoding, prior to sending
sending-filters=/usr/bin/pgpe -taf _RECIPIENTS_

The display-filters line says that: "when a received mail starts with the given string (i.e. -----BEGIN PGP MESSAGE-----) process its contents using the program /usr/bin/pgpv". Since all PGP messages start in such a way all PGP encrypted messages are automatically trapped by pgpv and decrypted (obviously only if they are encrypted with your public key).

The sending-filters line sets /usr/bin/pgpe as the program processing outgoing messages, using the email address (i.e. _RECIPIENTS_) of the intended receiver to select which public key must be used by PGP encryption mechanism.

Occurred the previous modifications, you are able to send encrypted messages or plaintext messages, choosing among them at sending time. A question is asked before your mail is sent out:

Send message (unfiltered)?

Replying Y to the question forces Pine to send the mail in a plaintext form, while hitting Ctrl-N sequence (i.e. Next Filter option) make you able to choose among different filters.
If pgpe is the sole filter defined, the following message is displayed:

Send message (filtered thru "pgpe")?

Replying Y to that question makes Pine encrypt the message with the appropriate public key and send it.

Copyright © 2000, Matteo Dell'Omodarme
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

[Eric also draws the Sun Puppy comic strip at http://www.sunpuppy.com. It's about, um, puppies. -Ed.]

Copyright © 2000, Eric Kasten
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

1. References
2. Introduction
3. Using a stapler, different glue, etc
4. Why is this setup important?
5. Problems, etc
6. Conclusion

References

• Micro Publishing: Part 2 (Mark's Update) (ZING copy)
• Micro Publishing (ZING copy)

Introduction

The first document by Rick Holbert is Micro Publishing. I wrote an update to that article. This article is another update. This article is going to be short, but it is significant since Mark has found a way he likes to make the books, finally.

The process of making the books inexpensively is the fact that is gets cumbersome. It can be a real pain in the butt. My whole goal is to make it very simple and very fast. There is no point making books if it becomes an unpleasant event. This document will address several problems Mark and Rick has had in the past and present one solution. This article will also list ongoing problems.

Rick and I are in the process of making a HOWTO for book binding, and if anyone wishes to add to the HOWTO or wishes to contribute thoughts, please send email to zing@gnujobs.com.

Using a stapler, different glue, etc

In the past, our tools were,
1. Book formatted pdf, postscript, or other document.
2. Duplex laser printer.
3. Paper folder.
4. Manual heavy-duty stapler that can do at least 1/2 inch staples.
5. Ruler
6. Paper for the cover.
7. Contact cement.
8. Book binding press

The problem with this setup was that you have to keep your book in the book press for 30 minutes before letting it go. Also, I wasn't using a ruler when Rick said I should.

With my current setup, we can eliminate the book-binding press with just a straight-edge. Here are the tools,

1. Book formatted pdf, postscript, or other document.
2. Duplex laser printer.
3. Paper folder.
4. Manual heavy-duty stapler that can do at least 1/2 inch staples.
5. Ruler
6. Paper for the cover.
7. Contact cement.
8. Straight edge
9. Very large binder clips.

Here are the steps,

1. Print the document on a duplex printer and make sure the printer is set to flip in the long edge. If you don't use a duplex printer, it is a pain in the butt. Please use a duplex printer. Please refer to our other articles for steps on how to use a non-duplex printer.
2. Use a paper folder or fold them by hand. Please buy a paper folder and use it to fold the paper. Refer to our other documents.
3. Straighten up the folded paper on the edges and use two large binding clips to kept the paper from shifting.
4. Place the paper in a heavy-duty manual stapler that can use at least 1/2 inch staples. Staple the paper at least twice.
5. Measure the width of the paper on the folded side of the paper where the staples are at. Squeeze it down when you measure it. Measure 5.5 inches plus 1/16 inch from the edge of the cardboard stock paper that you are going to use as your cover. Use a ruler to create a line from top to bottom. Measure out the width of the edge onto the cover and add 1/16th inch. Draw a line across from top to bottom here. Now, fold the cover at the two lines with a nice and crisp edge.
6. Take the cover and place it up against anything that is straight and has a little height, like a block of wood, or something. Place the paper on the cover and fold the cover over the paper.
7. After you have verified the cover fits over the paper nice and smooth, place contact cement on the inside binding edge of the cover. You don't need a lot of glue.
8. Fold the cover over again, and smoothen out the edge of the binding edge with your finger. Use two large binding clips to keep the cover on the paper.
9. Done!

Why is this setup important?

This setup is important for the following reasons:
1. Since you are using staples, you don't have to worry about individual pages from ever falling out.
2. Since you don't have to use much glue, you don't accidentally get glue all over the place.
3. Not having to use a book binding press means you don't have to go make one.
4. Using paper clips to keep the cover on means you can just stack the books and mass produce them. Once you put the paper clips are on, you are effectively done.
5. If you use a ruler to make the edges nice and straight, it makes the book look better and it also makes it so there isn't much gap between the paper and the cover, which means the glue is able to connect the paper to the cover better.

Problems

Here are some problems:
1. Don't staple the staples too far away from the edge since the book won't be able to flatten if someone opens it up.
2. I don't like using contact cement. Given this stapler solution, it should just be possible to apply different glue or some way of applying some else besides glue to just keep the cover attached to the paper.
3. If you can visually see the staples when you open the book on the first page and the last page, it looks dumb. We need to find a way to cover up the staples easily. There is no reason for people to know that we took the cheap way out and used staples.
4. We need cheap free way of filtering out fonts from pdf documents so that they aren't so huge and can print faster. Right now, we can cheat and use a commercial product to filter out the fonts that are annoying, but it would be nice if we could do it in a free way.

Conclusion

There really is no conclusion, except now Mark can make books fast for the COLUG and SVLUG groups he participates in. Before it was always a pain and time consuming to make books and it was cumbersome. Now, after the paper has been printed, he can make a book every 10 minutes, or faster.

---

Copyright © 2000, Mark Nielsen
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Virtual fax to pdf files with EFax.com

By Mark Nielsen

---

1. References
2. Introduction
3. Getting the fax number
4. What is in the email?
5. What do we do with the tiff files?
6. Scripts.
7. Conclusion

---

References

1. http://www.informatik.uni-frankfurt.de/~fp/uudeview/Apps/

Introduction

The idea is very simple. Sign up with a fax service which provides you a phone number and they will forward all faxes to that number to you in the form of email. Take the fax in the email and convert it into a pdf file on your webserver so that you can download, or perhaps have it automatically dump the fax to a printer.

This is very nice if you want to create a virtual office. Many a independent consultant might be interested in this.

Getting the fax number

Go to efax.com. You can figure it out. Just get their free basic account. I believe there are other free fax services out there, but I have looked around a lot.

What is in the email?

The email you receive will contain tiff formatted graphic files. They are converted to text in the email. You will need a program to extract the tiff files out of the email and convert the tiff files from text back to binary.

Once you have extracted the tiff files out of the email messages, you can do with them whatever you want. For this article, we will convert them to pdf files and put them in a web directory for easy download.

What do we do with the tiff files?

Okay, you need a program called uudeview, or some other program, which will easily extract the tiff files out of the email messages. Then, you will need to convert the tiff files to postscript. Then you will need to convert the postscript files to pdf. Then you will need to put the pdf files in a web directory. Here is an example of how to do this,

  ### Copy the mail over to a temporary file. 
cp /var/spool/mail/Username File.mail
  ### Extract the tiff files. 
uudeview File.mail
  ### Let us assume the tiff file is extracted as the name MyFile.tiff
  ### Convert it to postscript
tiff2ps MyFile.tiff > TempFile.ps
  ### Convert it to pdf
ps2pdf TempFile.ps TempFile.pdf
  ### move it
mv TempFile.pdf /www/docs/pdf/TempFile.pdf 

That is how you can do it manually. However, we want to automate the process. Two scripts in the next section will do that.

Scripts

These scripts clean up temporary files. You may not want to delete the email messages, in which case, someone will have to modify this perl script. (text version)

#!/usr/bin/perl

## We assume you have uudeview installed. 
## We assume you have a public_html directory which your webserver has been
## properly configured to see. 

### This perl script is not properly secured since it is possible to make
### a weird configuration for the name of the fax file, which in theory
### could mess up the command line statements. Use at your own risk.   

my $User = "Mu_Username";
my $Temp = "/home/$User/Temp/fax";

system "cp /var/spool/mail/$User /home/$User/Temp/";
system "cp /dev/null /var/spool/mail/$User";
system "/usr/bin/uudeview -o -i -d -p /home/$User/tiff/ /home/$User/Temp/fax";
system "cp /dev/null /home/$User/Temp/fax";

my @Old_Pdfs = </home/$User/public_html/pdf/*.pdf>; 
my $No = @Old_Pdfs;

foreach my $File (</home/$User/tiff/*.tif>)
  {
  $No++;
  my $Ps = $File;
  $Ps =~ s/\.tif/\.ps/g;
  $Ps =~ s/tiff/ps/; 
  system "/usr/bin/tiff2ps $File > $Ps";

  ### If you want to print this, uncomment
  #   system "lpr $Ps";

  my $Pdf = $Ps;
  $Pdf =~ s/\.ps/\.pdf/g;
  system "/usr/bin/ps2pdf $Ps $Pdf";

  ### Either choose to keep the default name of the file or number it
#  system "mv $Pdf /home/$User/public_html/pdf/";
  system "mv $Pdf /home/$User/public_html/pdf/$No.pdf";

  system "rm $Ps $File;";
  }

Here is the crontab file you will need. run the command

crontab Crontab

in order to get to be automated.

#!/bin/sh

0,15,30,45 * * * *   /home/UserName/Cron.pl >> /home/UserName/cron_log 2>&1

Conclusion

This is very easy way to get your virtual fax to be automated and converted into something that is easy to read. Having a virtual fax number is nice because it saves you money by not having to have a phone number. Every roaming consultant needs this.

Phil Hunter from COLUG first told me about this a year or two ago. He just dumps the faxes to a printer. It wasn't of much use then when I had an office and a fax machine, but I have found it useful since I moved out to California. My next goal is to send a fax through a modem, and then I will be able to send and receive faxes when I am not in my office in the Bay Area.

---

Copyright © 2000, Mark Nielsen
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Introduction to Shell Scripting

By Ben Okopnik

---

"You wouldn't believe how many managers believe that you can get a baby in one month by making nine women pregnant."
-- Marc Wilson

Random Wanderings

Well, this should be the last article in the "Introduction to Shell Scripting" series - I've had great feedback from a number of readers (and thank you all for your kind comments!), but we've covered most of the basics of shell scripting; that was the original purpose of the series. I may yet pop up at some point in the future ("Oh, rats, I forgot to explain XYZ!"), but those of you who've been following along should now consider yourselves Big-Time Experts, qualified to carry a briefcase and sound important... <grin> Well, at least you should have a pretty good idea of how to write a script and make it work - and that's a handy skill.

A Valued Assistant

Quite a while ago, I found myself in a quandary while writing a script (NO-O-O! How unusual! <grins>); I had an array that contained a list of command lines that I needed to execute based on certain conditions. I could read the array easily enough, or print out any of the variables - but what I needed was to execute them! What to do, what to do... as I remember, I gave up for lack of that one capability, and rewrote the whole (quite large) script (it was not a joyful experience). "eval" would have been the solution.

Here's how it works - create a variable called $cmd, like so:

cmd='cat .bashrc|sort'

It's just an example - you could use any valid command(s). Now, you can echo the thing -

Odin:~$ echo $cmd
cat .bashrc|sort
Odin:~$

- but how do you execute it? Just running "cmd" produces an error:

Odin:~$ $cmd
cat: .bashrc|sort: No such file or directory
Odin:~$

This is where "eval" comes into its own: "eval $cmd" would evaluate the content of the variable as if it had been entered at the command line. This is not something that comes up too often... but it is a capability of the shell that you need to be aware of.

Note that "bash" has no problem executing a single command that is stored as a variable, something like:

Odin:~$ N="cat .bashrc"
Odin:~$ $N
# ~/.bashrc: executed by bash(1) for non-login shells.

export PS1='\h:\w\$ '
umask 022

works fine. It's only when more complex commands, e.g., those that involve +aliases or operators ("|", ">", ">>", etc.) are used that you would encounter problems - and for those times, "eval" is the answer.

Trapped Like a Rat

One of the standard techniques in scripting (and in programming in general) is that of writing data to temporary files - there are many reasons to do this. But, and this is a big one, what happens when your users interrupt that script halfway through execution? (For those of you who have scripts like that and haven't thought of the issue, sorry to give you material for nightmares. At least I'll show you the solution as well.)

You guessed it: a mess. Lots of files in "/tmp", perhaps important data left hanging in the breeze (to be deleted at next reboot), files thought to be updated that are not... Yuck. How about a way for us to exit gracefully, despite a frantic keyboard-pounding user who just has to run "Quake" RIGHT NOW?

The "trap" command provides an answer of sorts (shooting said user is far more effective and enjoyable, but may get you talked about).

---


#!/bin/bash

function cleanup ()
{
    stty intr "" # Ignore 'Ctrl-C'; let him pound away...
    echo "Wake up, Neo."
    sleep 2; clear
    echo "The Matrix has you."

    echo "He's at it again."|mail admin -s "Update stopped by $USER"

    # Restore the original data
    tar xvzf /mnt/backup/accts_recvbl -C /usr/local/acct
    # Delete 'tmp' stuff
    rm -rf /tmp/in_process/

    # OK, we've taken care of the cleanup. Now, it's REVENGE time!!!
    rm /usr/games/[xs]quake

    # Give him a nice new easy-to-remember password...
    chpasswd $USER:~X%y!Z@zF%HG72F8b@Idiot&(~64sfgrnntQwvff########^

    # We'll back up all his stuff... Oh, what's "--remove-files" do?
    tar cvz --remove-files -f /mnt/timbuktu/bye-bye.tgz /home/$USER

    # Heh-heh-heh...
    umount /mnt/timbuktu

    stty intr ^C # Back to normal
    exit         # Yep, I meant to do that... Kill/hang the shell.
}

trap 'cleanup' 2
 
...


---

There's a little of the BOfH inside every admin. <grin> (For those of you not familiar with the "BOfH Saga", this is a must read for every Unix admin; appalling and hideously funny. Search the Web.)

DON'T run this script... yes, I know it's tempting. The point of "trap" is, we can define a behavior whenever the user hits `Ctrl-Break' (or for that matter, any time the script exits or is killed) that is much more useful to us than just crashing out of the program; it gives us a chance to clean up, generate warnings, etc.

"trap" can also catch other signals; the fact is that even "kill", despite its name, does not of itself `kill' a process - it sends it a signal. The process then decides what to do with that signal (a crude description, but generally correct). If you wish to see the entire list of signals, just type "trap -l" or "kill -l" or even "killall -l" (which does not list the signal numbers, just names). The ones most commonly used are 1)SIGHUP, 2)SIGINT, 3)SIGQUIT, 9)SIGKILL, and 15)SIGTERM.

[But SIGKILL is untrappable. -Ed.]

There are also the `special' signals. They are: 0)EXIT, which traps on any exit from the shell, and DEBUG (no number assigned), which can - here's a nifty thing! - be used to troubleshoot shell scripts (it traps every time a simple command is executed). DEBUG is actually more of an "info only" item: you can have this exact action without writing any "trap"s, simply by adding "-x" to your "hash-bang" (see "IN CASE OF TROUBLE..." below).

"trap" is a powerful little tool. In LG#37, Jim Dennis had a short script fragment that created a secure directory under "/tmp" for just this sort of thing - temp files that you don't want exposed to the world. Pretty cool gadget; I've used it a number of times already.

In Case of Trouble, Break Glass

Speaking of troubleshooting, "bash" provides several very useful tools that can help you find the errors in your script. These are switches - part of the "set" command syntax - that are used in the "hash-bang" line of the script itself. These switches are:

-n     Read the shell script lines, but do not execute
-v     Print the lines as they're read
-x     Prints $PS4 (the "level of indirection" prompt) and the command just executed.

I've found that "-nv" and "-x" are the most useful invocations: one gives you the exact location of a "bad" line (you can see where the script would crash); the other, `noisy' though it is, is handy for seeing where things aren't happening quite the right way (when, even though the syntax is right, the action is not what you want). Good troubleshooting tools both. As time passes and you get used to the quirks of error reporting, you'll probably use them less and less, but they're invaluable to a new shell script writer.
To use them, simply modify the initial "hash-bang":


---


#!/bin/bash -nv
...


---

Use the Source, Luke

Here's a line familiar to every "C" programmer:

#include <"stdio.h">

- a very useful concept, that of sourcing external files. What that means is that a "C" programmer can write routines (functions) that he'll use over and over again, store them in a `library' (an external file), and bring them in as he needs them. Well - have I not said that shell scripting is a mature, capable programming language? - we can do the same thing! The file doesn't even have to be executable; the syntax that we use in bringing it in takes care of that. The example below is a snippet of the top of my function library, "Funky". Currently, it is a single file, a couple of kB long, and growing apace. I try to keep it down to the most useful functions, as I don't want to garbage up the environment space (is the concept even applicable in Linux? Must find out...)

There's a tricky little bit of "bash" maneuvering that's worth knowing: if you create a variable called BASH_ENV in your .bash_profile, like so:

export BASH_ENV="~/.bash_env"

then create a file called ".bash_env" in your home directory, that file will be re-read every time you start a `non-login non-interactive shell', i.e., a shell script. A good place to put initialization stuff that is shell-script specific; that's where I source "Funky" from - that way, any changes in it are immediately available to any shell script.

---

func_list ()     # lists all the functions in Funky
{
    # Any time I need a reminder of what functions I have, what
    # they're called, and what they do, I just type "func_list".
    # A cute example of recursion - a func that lists all funcs,
    # including itself.

    cat /usr/local/bin/Funky|grep \(\)
}

getch ()     # gets one char from kbd, no "Enter" necessary
{
    OLD_STTY=`stty -g`
    stty cbreak -echo
    GETCH=`dd if=/dev/tty bs=1 count=1 2>/dev/null`
    stty $OLD_STTY
}

...

---

Not too different from a script, is it? No "hash-bang" is necessary, since this file does not get executed by itself.  So, how do we use it in a script? Here it is (we'll pretend that I don't source "Funky" in ".bash_env"):

---

#!/bin/bash

. Funky

declare -i Total=0

leave ()
{
    echo "So youse are done shoppin'?"
    [ $Total -ne 0 ] && echo "Dat'll be $Total bucks, pal."
    echo "Have a nice day."
    exit
}

trap 'leave' 0
clear

while [ 1 ]
do
    echo
    echo "Whaddaya want? I got Cucumbers, Tomatoes, Lettuce, Onions,"
    echo "and Radishes today."
    echo

    # Here's where we call a sourced function...
    getch

    # ...and reference a variable created by that function.
    case $GETCH
    in
       C|c) Total=$Total+1; echo "Them are good cukes." ;;
       T|t) Total=$Total+2; echo "Ripe tomatoes, huh?" ;;
       L|l) Total=$Total+2; echo "I picked da lettuce myself." ;;
       O|o) Total=$Total+1; echo "Fresh enough to make youse cry!" ;;
       R|r) Total=$Total+2; echo "Real crispy radishes." ;;
       *) echo "Ain't got nuttin' like that today, mebbe tomorra." ;;
    esac

    sleep 2
    clear

done


---

Note the period before "Funky": that's an alias for the "source" command. When sourced, "Funky" acquires an interesting property: just as if we had asked "bash" to execute a file, it goes out and searches the path listed in $PATH. Since I keep "Funky" in "/usr/local/bin" (part of my $PATH), I don't need to give an explicit path to it.

If you're going to be writing shell scripts, I strongly suggest that you start your own `library' of functions. (HINT: Steal the functions from the above example!) Rather than typing them over and over again, a single "source" argument will get you lots and lots of `canned' goodies.

Wrapping Up the Series

Well - overall, lots of topics covered, some "quirks" explained; all good stuff, useful shell scripting info. There's a lot more to it - remember, this series was only an introduction to shell scripting - but anyone who's stuck with me from the beginning and persevered in following my brand of pretzel-bending logic (poor fellows! irretrievably damaged, not even the best psychologist in the world can help you now... :) should now be able to design, write, and troubleshoot a fairly decent shell script. The rest of it - understanding and writing the more complex, more involved scripts - can only come with practice, otherwise known as "making lots of mistakes". In that spirit, I wish you all lots of "mistakes"!
 

Happy Linuxing!

---

Linux Quote of the Month:
``The words "community" and "communication" have the same root.
Wherever you put a communications network, you put a community as
well. And whenever you take away that network -- confiscate it, outlaw it, crash it, raise its price beyond affordability -- then you hurt that community.

Communities  will fight to defend themselves.  People will fight harder and more bitterly to defend their communities, than they will fight to defend their own individual selves.''
 -- Bruce Sterling, "Hacker Crackdown"


---


REFERENCES

The "man" pages for 'bash', 'builtins', 'stty' "Introduction to Shell Scripting - The Basics", LG #53
"Introduction to Shell Scripting", LG #54
"Introduction to Shell Scripting", LG #55
"Introduction to Shell Scripting", LG #57


---

Copyright © 2000, Ben Okopnik
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Configuring Sendmail in RedHat 6.2
--or--
My Adventure in the Heart of the Jungle

By Ben Okopnik

---

*** NOTE: This may not necessarily be the best way to configure Sendmail; I'm certain that it isn't the only way. It worked for me; if you are in the same situation - home machine, intermittent Net connection, possibly multiple users on one machine - it will probably work for you... but there are no guarantees: if it breaks, you get to keep both pieces. ***
 

This weekend, I installed RedHat 6.2 on my brother's PC - just to give an idea of how far we've come, I didn't even have to convince him (well, a few hints about "Oh, your machine crashed again? Gee, mine doesn't..." over the years may have helped.) I'm a Debian guy, myself, but he had a RedHat CD, and I wanted the experience of completely configuring an RH system (Famous Last Words: "After all, how different could it be?")

As a matter of fact, the RH install died a few times, until I figured out that one of the non-critical files on the CD was damaged (my brother was very impressed by the fact that I could customize the installation to the extent of eliminating a single file). So, no desktop pictures for the moment - I got them later from ftp.redhat.com - but everything else went well. In a couple of hours, I had his machine up and working away.

The first problem came from the fact that his ISP, AT&T, uses CHAP authentication; not the easiest thing in the world to handle (for those of you who are curious: on the "Advanced" tab of the account properties, select "Let PPP do all authentication" ; close the Configuration Tool; in "/etc/ppp/chap-secrets", put the password in double quotes. That cost me a couple of hours.) Once that was done, everything went smoothly... until I wanted to send mail without using Netscape (I far prefer Mutt). Then, the circus pulled into town, clowns and jugglers and magicians and all...

"He who has never configured `sendmail.cf' has no courage. He who has configured
it more than once has no brain."
 -- Unknown

I've always considered hacking sendmail config files to be the province of ÜberHackers, the people who read raw binary code and laugh about it. A "smail" installation - a one-line change in a simple file - MTA setup the easy way! Well... I figured I'd at least give it a shot; I already have lots of scars, what else could I lose? (I hear a chorus of voices: "Your sanity!" Never had any; can't be a problem.)

I'll lightly skip over the gnashing of teeth and the anguished screaming at the total lack of useful info on the Net (every Sendmail expert, everywhere and everywhen, thinks that you're configuring a 50,000-user MTA. There are no exceptions.), and go on to the actual things that worked. Here they are, step by step - note that you'll need to be `root' for all of this:

1. Install the "sendmail-cf" package. It's on the RedHat CD, but does not get installed by default; you'll need it to make any configuration changes.

2. In `/etc/mail', create two files - "genericsdomain" and "genericstable" (we'll be using them in just a minute); in `/etc/mail/Makefile', add "genericsdomain.db" and "genericstable.db" to the "all:" line.

3. Write your FQDN (Fully Qualified Domain Name - run "hostname -f" to see what it is) in "genericsdomain". Adding "localhost" doesn't hurt anything either, and seems like a good idea - this is the file used by Sendmail to determine if the mail it sees is
coming from the local domain.

4. Write (this is the good part) your mail aliases in "genericstable", in a
"local_login_name        remote_account_name@mail_domain" format, like so:

joe      big_time@yahoo.com
zelda    gorgeous@cheerful.com
walter   walter@worldnet.att.net

5. Run "make" in `/etc/mail'; this will create the ".db" versions of what you've just created. Re-run it whenever you change those files.
 

OK, we're done with the simple part. Now, before you do the stuff that follows, dance naked widdershins around your computer three times while chanting, "I shall not fear; fear is the mindkiller..." Oops - sorry, that part is optional for anyone but me...
 

6. Edit `/etc/sendmail.mc'. Add the following lines (I prefer to put them at the end of the other "FEATURE" statements, just for neatness' sake):

FEATURE(masquerade_envelope)
FEATURE(genericstable, `hash -o /etc/mail/genericstable')
GENERICS_DOMAIN_FILE(`/etc/mail/genericsdomain')

This tells Sendmail to use those files you've just created, and to modify the  "envelope" (The "From " header, etc.) as well as the visible headers ("From:", etc.)

7. Run "m4 /etc/sendmail.mc > /etc/sendmail.cf". This processes your newly modified "sendmail.mc" into a form that Sendmail actually reads - the "sendmail.cf" file.

Now, we're almost ready, except for one last thing -

8. Type "killall -HUP sendmail" or "kill -HUP <PID>", using the Sendmail PID from "ps -ax".  This will restart Sendmail which forces it to re-read the new config file.
 

Whew. Well, I'm still alive, and <patting pockets absentmindedly> still have my mind. Somewhere.

The system seems to work - I've sent mail to a number of people I know, and their servers didn't choke; sending mail to myself and examining the headers in "/var/spool/mail/ben" with a text editor confirmed that there was nothing horrendously unusual about them. I've rebooted the system, and everything still seems OK - now, a day later, I've stopped expecting things to go "BOOM". Still,  you never know...
 

It's true that Netscape will handle both SMTP and POP services, one user at a time; for most people, this is good enough. On the other hand, if you're one of those folks (like me) who hates the idea of waiting several minutes for a mail client complete with Web browser, news client, GUI, point-and-click, and lots of confusing options - when all you need is to send some mail - Sendmail may well provide a good answer.
 

Happy Linuxing to all!

---


References:

The incredibly confusing and unbelievably complex Sendmail man page
Ditto the /usr/doc/sendmail directory
Double ditto most Net resources

A slightly smaller ditto for RedHat's "Where's Everything?" page,

...and one semi-decent resource from RedHat-Europe, the Sendmail-Address-Rewrite mini-HOWTO.


---

Copyright © 2000, Ben Okopnik
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Linux Security Tips

By Kapil Sharma

---

In this article I will explain  how to make your Linux box secure by taking  basic security measures. This article will enable anybody to tighten the security of a redhat Linux box.

BIOS Security
Always set a password on BIOS to disallow booting from floppy by changing the BIOS settings. This  will block undesired people from trying to boot your Linux system with a special boot disk and will  protect you from people trying to change BIOS feature like allowing boot from floppy drive or  booting the server without password prompt.

LILO Security
Add the three parameters in "/etc/lilo.conf" file i.e. time-out, restricted and  password. These options will ask for password if boot time options (such as "linux single") are passed to the boot loader.
Step 1
Edit the lilo.conf file (vi /etc/lilo.conf) and add or change the three options :
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
time-out=00   #change this line to 00
prompt
Default=linux
restricted   #add this line
password=<password>   #add this line and put your password
image=/boot/vmlinuz-2.2.14-12
label=linux
initrd=/boot/initrd-2.2.14-12.img
root=/dev/hda6
read-only

Step 2
The "/etc/lilo.conf" file should be readable by only root because it contains unencrypted passwords.
 [root@kapil /]# chmod 600 /etc/lilo.conf (will be no longer world readable).

Step 3
Update your configuration file "/etc/lilo.conf" for the change to take effect.
 [Root@kapil /]# /sbin/lilo -v (to update the lilo.conf file).

Step 4
One more security measure you can take to secure the "/etc/lilo.conf" file is to set it immutable, using the chattr command.
     *  To set the file immutable simply, use the command:
             [root@kapil /]# chattr +i /etc/lilo.conf
This will prevent any changes (accidental or otherwise) to the "lilo.conf" file.

For more information about lilo security, read my article on LILO.

 

Disable all special accounts
You should  delete all default users and group accounts that you don't use on your system like lp, sync, shutdown, halt, news, uucp, operator, games, gopher etc
To delete a user account :
[root@kapil /]# userdel LP

To delete a group:
[root@kapil /]# groupdel LP

Choose a Right password
You should follow the following guidelines before choosing the right password.

The password Length: The minimum acceptable password length by default when you install your Linux system is 5.  This is not enough and must be 8.  To do this you have to edit the login.defs file (vi /etc/login.defs) and change the line that read:

 PASS_MIN_LEN    5
To read:
PASS_MIN_LEN    8
 The "login.defs" is the configuration file for the login program.
Enable shadow password support
You should enable the shadow password feature. You can use the "/usr/sbin/authconfig" utility to enable the shadow password feature on your system. If you want to convert the existing passwords and group on your system to shadow passwords and groups  then you can use the commands pwconv, grpconv respectively.
 
The root account
The "root" account is the most privileged account on a Unix system. When the administrator forgot to logout from the system root prompt before leaving the system then the system should automatically logout from the shell. To do that, you must set the special variable of  Linux named "TMOUT" to the time in seconds.
 Edit your profile file "vi /etc/profile" and add the following line somewhere after the line that read
"HISTFILESIZE="
 TMOUT=3600
 The value we enter for the variable "TMOUT=" is in second and represent 1 hours (60 * 60 =
3600 seconds). If you put this  line in your "/etc/profile" file, then the automatic logout after one hour of inactivity will apply for all users on the system. You can set this variable in user's individual ".bashrc " file to automatically logout them after a certain time.
 After this parameter has been set on your system, you must logout and login again (as root) for  the change to take effect.

Disable all console-equivalent access for regular users
You should disable all console-equivalent access to programs like shutdown, reboot, and halt for regular users on your server.
 To do this, run the following command:
[root@kapil /]# rm -f /etc/security/console.apps/<servicename>
 Where <servicename> is the name of the program to which you wish to disable console-equivalent access.

Disable & uninstall all unused services
You should  disable and uninstall all services that you do not use so that you have one less thing to worry about. Look at your "/etc/inetd.conf" file and  disable what you do not need by commenting them out (by adding a # at the beginning of the line), and then sending your inetd process a SIGHUP command to update it to the current "inetd.conf" file.  To do this:
Step 1
Change the permissions on "/etc/inetd.conf" file to 600, so that only root can read or write to it.
[Root@kapil /]# chmod 600 /etc/inetd.conf
 
Step 2
ENSURE that the owner of the file "/etc/inetd.conf" is root.

Step 3
Edit the inetd.conf file (vi /etc/inetd.conf) and disable the services like:
 ftp, telnet, shell, login, exec, talk, ntalk, imap, pop-2, pop-3, finger, auth, etc unless you plan to use it. If it's turned off it's much less of a risk.

Step 4
Send a HUP signal to your inetd process
[root@kapil /]# killall -HUP inetd

Step 5
Set "/etc/inetd.conf" file immutable,  using the chattr command so that nobody can modify that file
       *  To set the file immutable simply, execute the following command:
             [root@kapil /]# chattr +i /etc/inetd.conf
 This will prevent any changes (accidental or otherwise) to the "inetd.conf" file. The only person that can set or clear this attribute is the super-user root.  To modify the inetd.conf file you will need to unset the immutable flag:
*  To unset the immutable simply, execute the following command:
             [root@kapil /]# chattr -i /etc/inetd.conf

TCP_WRAPPERS
By using TCP_WRAPPERS  you can make  your server  secure against outside intrusion . The best policy is to deny all hosts by putting "ALL: ALL@ALL, PARANOID" in the "/etc/hosts.deny" file and then explicitly list  trusted hosts who are allowed to your machine in the "/etc/hosts.allow" file. TCP_WRAPPERS is controlled from two files and the search stops at the first match.
 /etc/hosts.allow
/etc/hosts.deny

Step 1
Edit the hosts.deny file (vi /etc/hosts.deny) and add the following lines:
# Deny access to everyone.
ALL: ALL@ALL, PARANOID
 Which means all services, all locations is blocked, unless they are permitted access by entries in the allow file.

 Step 2
Edit the hosts.allow file (vi /etc/hosts.allow) and add for example, the following line:
As an example:
ftp: 202.54.15.99 foo.com
 For your client machine: 202.54.15.99 is the IP address and foo.com the host name of one of your client allowed using ftp.
 
Step 3
The tcpdchk program is the tcpd wrapper configuration checker. It examines your tcp wrapper  configuration and reports all potential and real problems it can find.

 *  After your configuration is done, run the program tcpdchk.
             [Root@kapil /]# tcpdchk

Don't let system issue file to be displayed
 You should not  display your  system issue file when people log in remotely . To do this,  you can
change the telnet option in your "/etc/inetd.conf".
To do this change the line in "/etc/inetd.conf":


telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
to look like:
 telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd -h
 Adding the "-h" flag on the end will cause the daemon to not display any system information and  just hit the user with a login: prompt.  I will recommend to use sshd instead.

Change the "/etc/host.conf" file
 The  "/etc/host.conf" file specifies how names are resolved.
 Edit the host.conf file (vi /etc/host.conf) and add the following lines:
 # Lookup names via DNS first then fall back to /etc/hosts.
order bind,hosts
# We have machines with multiple IP addresses.
multi on
# Check for IP address spoofing.
nospoof on

 The first option is to resolve the host name through DNS first and then hosts file.The multi option determines whether a host in the "/etc/hosts" file can have multiple IP addresses (multiple interface ethN).
 The nospoof option indicates to take care of not permitting spoofing on this machine.

Immunize the "/etc/services" file
You must immunize the "/etc/services" file to prevent unauthorized deletion  or addition of services.
           *  To immunize the "/etc/services" file, use the command:
             [root@kapil /]# chattr +i /etc/services

Disallow root login from different consoles
The "/etc/securetty" file allows you to specify which TTY devices the "root" user is allowed to login . Edit the "/etc/securetty" file to disable any tty that you do not need by commenting them out (# at the beginning of the line).
 
Blocking anyone to su to root
 The su (Substitute User) command allows you to become other existing users on the system.  If  you don't want anyone to su to root or restrict "su" command to certain users then add the following two lines to the top of your "su" configuration file in the "/etc/pam.d/" directory.
Step 1
Edit the su file (vi /etc/pam.d/su) and add the following two lines to the top of the file:
 auth sufficient /lib/security/pam_rootok.so debug
auth required /lib/security/Pam_wheel.so group=wheel

Which means only members of the "wheel" group can su to root; it also includes  logging. You can add the users to the group wheel so that only those users will be allowed to su as root.
 

Shell logging
 The bash shell stores up to 500 old commands in the "~/.bash_history" file (where "~/" is your home directory) to make it easy for you to repeat long commands. Each user that has an account on the system will have this file "Bash_history" in their home directory. The bash shell should store less number of commands and delete it on logout of the user.
Step 1
The HISTFILESIZE and HISTSIZE lines in the "/etc/profile" file determine the size of old commands the "Bash_history" file for all users on your system can hold.  I would  highly recommend setting the HISTFILESIZE and HISTSIZE in "/etc/profile" file to a low value such as 30.
 Edit the profile file (vi /etc/profile) and change the lines to:
HISTFILESIZE=30
HISTSIZE=30
 Which mean, the "Bash_history" file in each users home directory can store 20 old commands
and no more.
 Step 2
The administrator should also add into the "/etc/skel/Bash_logout" file the
"rm -f  $HOME/Bash_history" line, so that each time a user logs out, its "Bash_history" file will be deleted.
 Edit the Bash_logout file (vi /etc/skel/Bash_logout) and add the following line:
 rm -f $HOME/Bash_history

Disable the Control-Alt-Delete keyboard shutdown command
To do this comment out the line (with a "#") listed below in your "/etc/inittab" file .
 To do this, edit the inittab file (vi /etc/inittab) and change the line:
 ca::ctrlaltdel:/sbin/shutdown -t3 -r now
To read:
#ca::ctrlaltdel:/sbin/shutdown -t3 -r now
 Now, for the change to take effect type in the following at a prompt:
 [root@kapil /]# /sbin/init q

Fix the permissions under "/etc/rc.d/init.d" directory for script files
 Fix the permissions of the script files that are responsible for starting and stopping all your normal  processes that need to run at boot time.  To do this:
 [root@kapil/]# chmod -R 700 /etc/rc.d/init.d/*
 Which means only root is allowed to Read, Write, and Execute scripts files on this directory.

Hide your system information
 By default, when you login to a Linux box, it tells you the Linux distribution name, version, kernel  version, and the name of the server. This is sufficient information for a crackers to get information about your server. You should just prompt users with a "Login:" prompt.
 Step 1
To do this, Edit the "/etc/rc.d/rc.local" file and Place "#" in front of the following lines as shown:

# This will overwrite /etc/issue at every boot.  So, make any changes you
# want to make to /etc/issue here or you will lose them when you reboot.
#echo "" > /etc/issue
#echo "$R" >> /etc/issue
#echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue
#
#cp -f /etc/issue /etc/issue.net
#echo >> /etc/issue

 Step 2
Then, remove the following files: "issue.net" and "issue" under "/etc" directory:
 [root@kapil /]# rm -f /etc/issue
[root@kapil /]# rm -f /etc/issue.net

Disable unused SUID/SGID programs
 A regular user will be able to run a program as root if it is set to SUID root. A system administrator should minimize the use of these SUID/GUID programs and disable the programs which are not needed.
Step 1
*  To find all files with the `s' bits from root-owned programs, use the command:
          [root@kapil]# find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls ­lg {} \;

     *  To disable the suid bits on selected programs above, type the following commands:
          [root@kapil /]# chmod a-s [program]
 

After following the above security guidelines, a system administrator can maintain a basic level of system security. Some of the above tasks are a continuous process. The system administrator has to continuously follow the above guidelines to keep system secure.


Written by: Kapil Sharma
Email: kapil@linux4biz.net
Website: http://www.linux4biz.net
[Kapil Sharma is a Linux and Internet security consultant. He has been working on various Linux/Unix systems and Internet Security for more than 2 years. He is maintaing a web site http://www.linux4biz.net for providing free as well as commercial support for web, Linux and Unix solutions.]

---

Copyright © 2000, Kapil Sharma
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Easily Porting MS-DOS Diagnostics to Linux

By Mark Taylor

---

Abstract

With a code few modifications and one powerful Linux module, you can compile and run your favorite MS-DOS diagnostics code on Linux on an X86 machine. Here's how!

Introduction

Diagnostic applications do their job by reading and writing the hardware registers of the devices on the mainboard. This is easy to program in MS-DOS since the processor is running in real-address mode and there are no protection mechanisms.

Writing code to access the hardware under Linux is quite a bit more difficult since (in most cases) a separate device driver must be coded and installed into the kernel. The protection mechanisms that prevent harm to the system by misbehaving user processes stymie the diagnostic developer. This article explains the porting 16-bit MS-DOS Diagnostics source code developed using Visual C++ 1.52 to the GNU C++ compiler and Linux OS environment.

DOS diagnostics resource usage

Start by compiling the MS-DOS code on Linux. The only code that won't compile contains non-standard system calls and inline assembly code. These fall into the following categories of system resources:
• Read and write of I/O ports
• PCI configuration space
• Time delays
• Linear memory
• Interrupt handlers
• Inline assembly for CPUID, RDTSC (Read Time Stamp Counter) instructions and 64 bit integer math which was implemented with inline assembly instructions
A new access method in Linux must be found for each of these resources. Some system resources can be accessed by a user process running with root privilege.

A user process running with root privilege can access I/O ports and memory, but can't disable or handle interrupts. PCI configuration space access isn't safe either because consecutive writes to the configuration address and data ports are required. Tight control of time delays isn't possible either since the user process can be put to sleep at any time. See Linux Device Drivers section "Doing it in User Space" in [RUB] Chapter 2 on page 36.

The GCC (GNU C Compiler) that comes with the Linux Distribution handles inline assembly code and both the CPUID and RDTSC instructions will execute correctly in a user context. GCC also offers 64-bit signed and unsigned integer math with the long long types. These capabilities cover the last bullet above. A single Linux module will handle all of the others except the interrupt handlers.

Introduction to Linux modules

A module is a section of code that can be added to the kernel at run time. A module is an object file that is compiled with the symbol MODULE defined. The module source includes the file linux/module.h and at least the two functions init_module and cleanup_module. The functions within a module run in kernel mode and have access to all the facilities available to the kernel. Modules can export symbols and call functions in other modules. Modules may (but are not required to) have an associated device node and be accessed from user processes like a device driver. Modules are added to the kernel and dynamically linked by running the insmod program.

Modules may also dynamically register nodes in the /proc filesystem. The most common use of a /proc node is to deliver a buffer of data to the reader.

Using modules to satisfy the DOS diagnostics resource access

One approach to giving the DOS diagnostics access to the system resources is to write a device driver module for each chip and rewrite the low level DOS diagnostics routines to open and use the device drivers. This approach is undesirable because of the potentially large number of devices used and the large number of code changes to the existing DOS diagnostics source code.

The number of modules required can be cut down considerably by creating a single module to provide general-purpose access to the kernel for each of the resource classes. The Linux Wormhole driver module provides the following services:

• Read, write, modify of I/O ports
• Read and write PCI configuration space
• read and write access to BIOS and PCI memory
• Microsecond resolution minimum time delays
• System clock tick resolution minimum time delays
All services are provided by an ioctl(2) call. The function prototype for ioctl is:

ioctl (int fd, int request, char *argp);

The fd parameter is the file descriptor for the module obtained by a previous open(2) call.

The request parameter identifies the service required of the module. A symbol for example WORM_IOP_R is defined for each request. Each request also has an associated structure type. The argp parameter points to the structure provided by the caller. Data is passed to and from the module through this structure. The kernel calls copy_from_user and get_user_ret are used by the module to get data from the user. The kernel call put_user_ret is used to write data back to user space. See asm/uaccess.h.

I/O PORTS

There are three requests used to access I/O ports. They are:
• 8, 16, or 32 bit read (WORM_IOP_R)
• 8, 16, or 32 bit write (WORM_IOP_W)
• 8, 16, or 32 bit atomic read/modify/write (WORM_IOP_RMW)
For each request the user initializes the structure passed via argp with the I/O port address, write value(s) (if a write operation), and width of the I/O port.

The Wormhole module source code uses the macros inb, outb, inw, outw, inl, outl provided by asm/io.h to implement the I/O port access. See the section "Using I/O Ports" in [RUB] Chapter 8 on page 164.

PCI Configuration Space

PCI configuration space is accessed like I/O ports using a read and a write request (WORM_PCI_R, WORM_PCI_W). Address information is different and consists of the bus number, device number, function number, and byte offset. These functions are implemented in Wormhole using PCI BIOS calls defined in linux/pci.h. See the section "The PCI Interface" in [RUB] Chapter 15 on page 341.

Minimum Time Delays

The minimum time delay services returns control to the calling process after at least the requested amount of time has elapsed. Due to interrupts and task switching, the time delay could be much longer. The DOS diagnostics code has two delay functions.

The first is based on the 18.2 Hz (54.94ms) DOS system clock. Linux modules can provide delays in increments of the system timer interrupt, which is currently 10ms. The Wormhole ioctl request WORM_DELAY_MS takes the number of milliseconds to delay as the argument. The driver determines the smallest system timer value that will occur after the delay has expired, sets a timeout, and sleeps. The driver will wake up and return to the user process when the timeout occurs.

The second DOS diagnostics code delay function performs microsecond resolution delays based on the time it takes to write to a non-decoded ISA bus port. This is somewhere in the neighborhood of 700-1000ns. Linux offers the kernel function udelay defined in <linux/delay.h>. See the section "Short Delays" in [RUB] Chapter 6 on page 137. This function bases the delay time on a software loop calibrated at boot time. Experiments show the delay time to be accurate with the best accuracy for delays below 100us. This function is only suitable for small delays (up to around 1ms) since it busy waits, preventing other tasks from running. The Wormhole ioctl request WORM_DELAY_US passes the number of microseconds to delay to the kernel function udelay.

Read and write access to PCI and BIOS memory

DOS diagnostics can access any location in the 4GB address space by switching briefly to protected mode. In protected mode a selector that can read or write data based at zero with a limit of 4GB is created and used to access memory. A single BYTE or DWORD of memory is read or written. The existing code accesses PCI device memory which is above DRAM and the System BIOS area which is just below 1M.

In Linux the processor is running in protected mode and the memory management unit is enabled. The desired physical memory location must be mapped via the page tables and its virtual address must be known. Linux offers the kernel function vremap, which will create the virtual to physical mapping for a block of memory. The physical address must be above the top of DRAM memory. Kernel function ioremap can be used to map in memory-mapped devices and PCI memory. The Wormhole requests WORM_PCIMEM_R and WORM_PCIMEM_W will map a page, perform one 32-bit or 8-bit read or write access then unmap the page. See the section "High PCI Memory" in [RUB] Chapter 8 on page 175.

The Wormhole requests WORM_BIOSMEM_R and WORM_BIOSMEM_W access the System BIOS area below 1M. They use kernel macros readb, readl, writeb, and writel to perform the memory access. See the section "ISA Memory Below 1M" in [RUB] Chapter 8 on page 171.

Limitations of the Wormhole driver

The DOS diagnostics check for correct interrupt generation by installing an interrupt handler which increments a global variable. Because each interrupting device requires a custom interrupt handler, the Wormhole driver cannot provide a general-purpose service. A separate module should be created for each device that interrupts.

The Wormhole driver performance is limited by the context switch overhead of the ioctl call. If thousands of operations are required the total time will be significantly longer than the time consumed by a dedicated module.

The Wormhole driver only does one access per call. If several accesses must be done atomically, with no intervening task switches, the Wormhole driver is unsuitable.

The Wormhole driver and Linux user process cannot offer real time response. In the diagnostics environment this problem can be limited by running with no users logged in. Otherwise a dedicated module is required.

The Wormhole driver does not control access to the kernel resources. It is the responsibility of the caller to not break anything in the kernel or change the state of device registers of devices for which are modules are running.

Source Code

worm.h
worm.c
Makefile

References

[RUB] Rubini, Allessandro "Linux Device Drivers" First Edition, 1998, O'Reilly & Associates, Inc.

Linux kernel versions

The book Linux Device Drivers [RUB] primarily addresses Linux 2.0 kernels. The Wormhole driver runs under Linux 2.2.14. Some of the kernel calls made by the Wormhole driver are different than described in the book. A good source of information about kernel changes between 2.0 and 2.2 is porting-to-2.2.html .

---

Copyright © 2000, Mark Taylor
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Hooking Up a Local School Network to the Net with a Java Proxy

By Alan Ward

---

I'm writing this article after a couple of weeks of messing around getting our local school network hooked up to the net. Our problem was similar, I guess, to that of many schools: how do you give students' boxes access to the net, but restricting both certain types of content and certain services altogether (IRC)?

A minor extra point was that I wanted to separate our two computer labs' networks into different segments with some kind of packet filtering in between. With the number of computers going up, so was the collision rate.

I had the following material considerations to take into account:

• A connection to our ISP via an ISDN card - of a make unfortunately not supported right now by the Mandrake kernels I use. So the box connecting directly to the net had to run under Windoze, with the WinGate proxy installed. This is not in itself a bad thing, as configuring dial-on-demand on a Linux box would have taken too much of my time to find out how it is done.
• An eclectic collection of Windows 95 / 98 / 2000 client machines, plus an occasional Macintosh and PC under Linux or QNX. All running various browsers.
• A P-III 450 MHz I managed to scrounge, with several ethernet cards. This one was to do the filtering, and was so definately a Linux box.
• Finally, I wanted http and ftp access to a local web server in much the same way as access to the net: i.e. the user just has a different address to type in.

By now, the network hardware setup was more or less clear, thusly:



The filtering server also runs our local web server (Apache).

Now came the interesting part: how was I to configure the lot into a working setup?

The Linux built-in firewall

My first idea was to use Linux' routing capacities. You can set up just about any Linux box as a router to separate two or more ethernet segments. It just needs a card for each segment - not even necesserily running at the same speed. You then configure the kernel built-in firewall to ignore packets that have source and destination addresses within the same segment, but to forward packets with source and destination addresses in different segments.

This can be a definite gain of speed as the number of collisions on an ethernet network goes up with the number of nodes on each segment - and each collision requires a time-out to retry sending the packet. So, for example, three segments with ten nodes each and a Linux firewall in between outperforms a single segment with all thirty nodes under normal and heavy traffic loads.

For more information, read the Firewall-HOWTO and the ipchains manual page

A simple setup would then be to program the clients to use the net access server as their web proxy, and use the filtering server as a firewall. This is just about the most classical distribution of roles imaginable.

So why couldn't this work for me? The answer lies in the fact that to enable routing, both the client boxes and the net access server had to have the filtering server as their gateway. This worked fine as long as the ISDN wasn't up. But when ISDN went up, the default gateway on the net access server (running under Windows, remember?) became our ISP.

So a request emanating from a client box goes into the filter, and is forwarded to the net access. The WinGate proxy does its stuff, and replies to our local client - but this message is routed back off to our ISP ... and the client gets no reply.

The Squid proxy

As a second approach, I thought of using the squid proxy, cascaded under WinGate. This way, a client request goes to squid on the filter. Squid then determines if the request goes to the local server, or has to be forwarded to the WinGate machine:



And did this work? Yes, very well ... as long as the client requested either the local server or an internet website by giving its IP address. The problem was with DNS.

The squid proxy has to determine where to send each request. So even if you give it a default cascaded proxy, it still tries to perform DNS address resolution on each URL it receives.

I then tried the following: set up WinGate as a DNS proxy as well as www, and tell the filter to use the net access box as its main DNS. The requests went through to WinGate, but got no reply from the 'net. Confounding ... and the client box gets a message from squid complaining it can't proceed with address resolution. Needless to say, the net access server's DNS setup works well on its own.

Another approach was to use the Apache webserver's proxy capabilities. This worked just as well - and just as badly - as squid.

Recommended reading: all 1907 lines of /etc/squid/squid.conf . Same for /etc/httpd/conf/httpd.conf .

Homebuilt Java proxy

As you may imagine, I was at this time fresh out of ideas. And school-in was 48 hours away. So I took the only reasonable decision - write my own proxy daemon in Java, to be installed on the filter.

This may take a bit of explaining. First of all, why is writing a proxy daemon reasonable? In this case, the proxy just had to:


• accept a socket connection from a client, and read the client browser's request;
• establish a second socket connection to WinGate, send the client's request on with no changes;
• listen on the second connection, and send whatever came down the line back on the first connection;
• terminate the first connection as soon as the second one is dropped by WinGate.



There is no caching, no address resolution, nothing else to be done.

Secondly, why is it reasonable to write such a program in Java, when network programming is traditionnaly done in C? Mainly because programming sockets in C is a pain, and doing it in Java is painless. All relevant classes are available in java.net.* : Socket, ServerSocket, DataInputStream and PrintStream are about all you need.

It is also as easy in Java as is C to fork off a process to handle separately each client connection. The difference is that in Java, one usually uses a thread, not a separate process. This has some advantages on the typical C solution. Each process has its own memory allocation, etc, and so takes relatively longer to establish. A thread is an altogether lighter structure.

Finally, it works. To be quite honest, it works more quickly than I thought, and what was initially conceived as a quick solution looks to stay as a permanent one. In fact, with 20-30 clients going full steam on Internet, the limiting factor is ... our ISP.

Future improvements

Just one on my TODO list: as it stands, there is no page content filtering. I will work on that later on (and cut out web-based chats at the same time).

My source code is here: proxy.java, naturally under GPL. Please send me any comments you may have.

---

Copyright © 2000, Alan Ward
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

AOLserver - a web development platform

By Irving Washington

---

Introduction and short history of AOLserver

A web server is not an end in itself - it's only a tool that allows creating web services. This article introduces an AOLserver, an open-source, standards-compliant web server extraordinaire (think Apache on steroids) that runs beautifully under GNU/Linux. We present its history and show how its capabilities make it an ideal web development platform.

First there was a company called NaviSoft founded by a couple of wizard Unix programmers. They've set out to create the best web publishing system on the planet and they were well on their way. It was 1994 and their product, a web server called NaviServer, was multi-threaded from the ground up (Apache is still trying to catch up with this particular feature), had a tightly integrated scripting language, good extension API and database connectivity built in. It was so good that AOL decided in 1996 to use it to power the core of their business - multiple AOL web-estate. But buying programs is not how AOL works - they've bought the whole company to make sure that the software will grow as fast as AOL's needs. Thus NaviServer has been renamed to AOLserver. In 1999 an MIT researcher, accomplished photographer and web-developer in one person, Philip Greenspun, convinced AOL that it should open-source AOLserver for the mutual benefit of AOL and public at large. So they did. After a few months of frantic code cleanup AOLserver 3.0 debuted as an open-source web server whose development is largely community driven. AOLserver 3.1 has been released in September 2000.

Qualities of a good web server

A web server is more like a C compiler than a word processor. It's a tool, a development platform that is used to build web services. Let's examine some of the desirable qualities that a web server should have and see how well AOLserver fits the bill.

Robustness, stability, scalability

I list robustness in the first place because if your web server crashes and your web pages are inaccessible to visitors then nothing else really matters.

AOLserver is robust, stable and scalable, after all it has been perfected for years by a tight group of programming wizards. Fortunately, you don't have to take my word for it. AOLserver has been battle-field tested in the most demanding environments. It is known to serve 30 thousand hits per seconds on AOL sites. ArsDigita, a Web development company, has built numerous web sites (www.photo.net, www.scorecard.com, www.away.com) that routinely serve millions hits per day. The bottom line is: AOLserver proved to be extremely stable and scalable by serving some of the most popular sites on the Internet today.

Features, a lot of them

For serving static pages AOLserver is just as good as any other fast, efficient and reliable web server. Today, however, publishing static content is not thrilling anymore. The focus is on dynamic, collaborative services. AOLserver has been built from the ground up for such purposes and it shows. Here's a list of features that a web server should have, why it should have it and a description of what AOLserver offers.

You want web server to support four of the most popular programming paradigms. You can think of a web service in object-oriented terms: a web server is an object whose methods are URLs. Users invoke methods by requesting an URL from within their web browser. The simplest way a web server can respond to such request is to fetch a static HTML file from the file system and send its content to an user. Doing anything more complicated means running a computer program which will generate an HTML page. One way to do it is by extending web server itself using its C extension API. Every popular web server (Apache, IIS, Netscape) has some implementation of this idea. AOLserver provides well thought out C extension API that makes writing modules that extend its functionality really easy. As an example: the source code embedding PHP in AOLserver is half the size of the similar code that embeds PHP in Apache (this "benchmark" should be taken with an appropriate grain of salt but it gives a rough idea of extension API quality). Having praised the API it should be noted that this is a very slow and error prone way of writing web services (on any web server). You have to code in a very low-level language (C), debugging is a nightmare and smallest mistake can crash the whole server.

To remedy those shortcomings a CGI protocol has been created. This protocol is supported by all major web servers including AOLserver. The idea is very simple: upon page request a web server will execute a program and whatever this program will send to its standard output will be sent back to a browser. The greatest advantage is that it can significantly shorten development time since programmer can use the best tool for the job (which usually means a scripting language like Perl, Tcl, Lisp or simply a language that he is most familiar with). The disadvantage is that it's slow (for each request a program needs to be executed and it's very expensive operation) and thus doesn't scale well.

To improve performance web servers started to directly embed scripting languages. The most popular examples are mod_perl in Apache and PHP. Since interpreter is linked with the web server executable it's no longer necessary to fork an external program to execute the script which saves a lot of time. This approach conserves the fast development advantage of CGI scripts but the cost is that it limits you to one particular scripting language (which may or may not be an disadvantage depending on how well developer knows this scripting language). AOLserver's story in this department is very compelling: it is the only major web server that comes with a tightly integrated scripting language (Tcl) out-of-the-box. If for some reason you dislike Tcl you can use PHP, Python, Java (and there is a work in progress to add Perl support).

The last programming paradigm is server-side includes ie. code embedded in HTML pages. When a page is server it is parsed by the server, HTML code is left untouched, embedded code chunks are executed and replaced by their output and resulting page is sent to browser. The most popular example of this paradigm are ASP pages in IIS. AOLserver provides developers with a similar feature: ADP pages that allows you to embeded Tcl code inside HTML.

You want your web service to be fast and efficient. AOLserver's multi-threaded architecture gives you the performance advantage over process based web servers (eg. Apache 1.3.x, Apache 2.0 is being rewritten as multi-threaded server but hasn't yet reached maturity). If a web server is based on processes it has to create a new process to serve each http request. AOLserver only has to spawn a new thread and it's much faster.

You want to have ability to share data between scripts. There are many uses for such feature, the simplest example would be to count how many times a given page/script has been called. It's not easy to achieve this in a process based web server because processes do not share dynamically allocated memory. As an example, if you use mod_perl scripts in Apache, you can have a global variable and increment it but if you think that this will tell you the total number of times the script has been executed you're in for a surprise: this value is actually per-script-per-process and since Apache pre-forks multiple processes and (as far as programmer is concerned) unpredictably assigns them to execute scripts your counter won't give you an accurate number. It's possible to overcome this using shared memory (or by storing the data in a database) but it is so cumbersome and non-standard that it's not popular among Apache developers. In AOLserver it's a child's play thanks to the fact that threads share dynamic memory and excellent built-in nsv interface.

Since dynamic web services usually have to store data in a database and retrieve data from a databases you want your web server to have an ability to talk to databases. AOLserver comes with an exceptionally good, standardized and fast database connectivity API. It's fast because it uses connection pooling, ie. database connections are opened when the web server starts and subsequently reused among scripts. An alternative (used eg. in PHP3) is to open a connection on the beginning of a script and close it at the end. This approach is much slower.
Standardized means that you use the same API to send SQL commands regardless of the database server used (to contrast, in PHP each database has its own set of APIs). It's easier to port the code when switching databases (SQL statements still need to be ported, but that just shows how standard an SQL standard is).
To top it off drivers exist for most popular databases: Oracle, PostgreSQL, MySQL, Informix, Interbase, Solid, DB2.

AOLserver provides developers with more basic blocks for building dynamic web services than any other web server. Most web services have to solve many similar problems and provide:

• user and session tracking
• permissions system
• content management (publishing, templating)
• e-commerce
• banner management
• site-wide search
• and many, many more
Even given all the wonderful features of AOLserver you might get tired reinventing the infrastructure needed for supporting collaborative web service. Instead of re-inventing the wheel you might take a look at open-source, Oracle-based ArsDigita Community System (ACS) (or at OpenACS, port of ACS that uses open-source PostgreSQL database). You'll have to spend some time in learning about this very extensive toolkit but after an initial investment you'll be able to quickly build high-quality web services that require advanced collaboration features.

Documentation

Good documentation is essential. More often than not it's also the most frequently neglected aspect of open-source projects. AOLserver, thanks to its commercial roots, has a very good documentation, available both on-line and off-line. It consist of an administrator guide, detailed guides to C and Tcl interfaces, a guide to developing database drivers.

Vibrant community

An active community of users and developers is important for steering programs into new waters, providing suggestions and bug fixes, helping new users etc. AOLserver has entered open-source land relatively recently and has already gained an attention of external developers. There are projects in full swing that push AOLserver into realms it has never reached before. The following modules are being worked on by community members (independent of the core developers):"
• quickly maturing PyWX project embeds a Python interpreter inside AOLserver so that it enjoys the same high integration as Tcl
• nsxml module contributed by ArsDigita adds XML processing capabilities by wrapping libxml in a Tcl interface
• nsjava enables calling Java from within AOLserver
• nstomcat enables running servlets inside AOLserver
• first stab at embedding Perl has been made

Conclusion and links

Web is changing rapidly. Static pages and simple CGI scripts are not sexy anymore. Anything worthwhile that can be achieved on the Web today involves building web pages from dynamic data sources, collaboration among visitors, tracking user's behavior etc. AOLserver's features make it an ideal development platform for building such advanced, collaborative web services.

To get more information check those sites:

• www.aolserver.com is the best place to get more information about AOLserver and participate in its development
• Philip Greenspun has written an excellent introduction to AOLserver. Here's part one and part two of his article
• this paper shows how AOLserver is used to power some really heavy-weight sites
• when you get past simple web sites you might want to read Philip and Alex's Guide to Web Publishing to find out what designing web services is about

---

Copyright © 2000, Irving Washington
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

Two Years Ago - the birth of the Linux Professional Institute (LPI)

By Dan York

---

Two Years Ago...

Two years ago, in the October 1998 Linux Gazette, there appeared a brief article that started part of a process underway that I do not believe any of us had any idea would go as far as it has.

As I mentioned in my article last October, my original article outlined the reasons why I felt a professional certification program would benefit Linux. It concluded with several questions and asked how I could join in the discussion:

If you agree that a certification program can be beneficial for the growth of Linux, how do we as a community go about addressing the points I made above about creating a certification program? Do we create another mailing-list or newsgroup? (Does such a group or list already exist? If so, I have so far failed to find it.) Do we meet at a conference? ...

...I don't necessarily have the answers - but I would like to participate in the discussion. If someone can suggest the appropriate forum in which this discussion should take place (or is currently taking place!), please let me know.

Two years ago, we had no idea that what we were beginning would become the Linux Professional Institute. We had no clue of the tremendous support we would receive not only from members of the Linux community, but also from the larger IT, training and publishing communities. Nor did we know of the significant financial support we would receive. We had no idea how incredibly expensive all of this would be to pull of. Nor did we know how significantly LPI would change some of our lives.

And yet... two years later, we have deployed the two exams of Level 1. As I write this, the exams are completing the final stages of the incredibly long and comprehensive process that is involved with our efforts. And our approach of NOT endorsing or approving any single way of preparing for our exams has paid off with many different ways for people to prepare for our exams.

There are so many people to thank that it is next to impossible to even begin to list them all. We have tried with web pages thanking people who have assisted us in 1999 and 2000, but even those lists fall short. I would refer you to the articles listed below to understand both what we have gone through and also who should be thanked. We have been extremely grateful for all the support of people within the Linux community and also within the larger IT world. We would also thank the Linux Gazette for providing the forum that helped launch our effort and continued to help get our message out. They, and so many other Linux magazines, journals and web sites have been instrumental in helping the world learn about our program.

LPI began with a fairly simple idea - if there is to be certification for Linux, which the larger IT and training industry pretty much determined would be inevitable, then that certification should be controlled by the actual Linux professionals working with the operating system and not by any one Linux vendor or any publishers or training/courseware providers. Furthermore, candidates should have the freedom to choose how they prepare for the exams, including the option of not taking any classes at all and simply studying the exam objectives. The exams should be available globally and as inexpensively as possible, and should use standard industry practices to ensure that the exams are legally defensible, statistically-valid and able to stand equal or better than other existing IT certifications.

It's been a very long road with plenty of joyous moments and plenty of rough spots. But working together, we have done it! Yes, there is still a long way yet to go, and there is much ahead for us to do. There are many more challenges ahead, and we will need the active support and participation of many more people to meet those challenges (please contact Wilma Silbermann < wilma@lpi.org> if you would like to volunteer). We will need help in many different areas... we will need new people providing leadership... we will need new financial sponsors... we will need more people to write and speak about LPI. But based on what I have seen in the past two years, I am more confident than ever that we will continue to build LPI to be a premier certification program.

Yet on this October day, I believe we should take this moment to pause, sit back and appreciate all that has been done by so many different people. We thank everyone who has been involved for your past and continued support and look forward to continuing to work with you all to move this program on to even greater heights!

And so much of it began here, with a little article and, most importantly, all of the people who responded back to say that they, too, wanted to help...


---

Previous ``Linux Certification'' Columns

by Dan York
Linux Certification Part #1, October 1998
Linux Certification Part #2, November 1998
Linux Certification Part #3, December 1998
Linux Certification Part #4, February 1999
Linux Certification Part #5, Mid-April 1999
Linux Certification Part #6, July 1999
Linux Certification Part #7, October 1999


by Ray Ferrari
Linux Certification Part #8, February 2000
Linux Certification Part #9, June 2000
Linux Certification Part #10, September 2000

---

Copyright © 2000, Dan York
Published in Issue 58 of Linux Gazette, October 2000

"Linux Gazette...making Linux just a little more fun!"

---

The Back Page

• About This Month's Authors
• Not Linux

---

About This Month's Authors

---

Shane Collinge

Part computer programmer, part cartoonist, part Mars Bar. At night, he runs around in a pair of colorful tights fighting criminals. During the day... well, he just runs around. He eats when he's hungry and sleeps when he's sleepy.

Fernando Correa

Fernando is a computer analyst just about to finish his graduation at Federal University of Rio de Janeiro. Now, he has built with his staff the best Linux portal in Brazil and have further plans to improve services and content for their Internet users.

Eric Kasten

I'm a software developer by day and an artist, web developer, big dog, gardener and wine maker by night. This all leaves very little time for sleep, but always enough time for a nice glass of Michigan Pinot Gris. I have a BS double major in Computer Science and Mathematics and an MS in Computer Science. I've been using and modifying Linux since the 0.9x days. I can be reached via email at kasten@sunpuppy.com or through my website at http://www.sunpuppy.com.

Mark Nielsen

Mark works at ZING (www.genericbooks.com) and GNUJobs.com. Previously, Mark founded The Computer Underground. Mark works on non-profit and volunteer projects which promote free literature and software. To make a living, he recruits people for GNU related jobs and also provides solutions for web/database problems using Linux, FreeBSD, Apache, Zope, Perl, Python, and PostgreSQL.

Ben Okopnik

A cyberjack-of-all-trades, Ben wanders the world in his 38' sailboat, building networks and hacking on hardware and software whenever he runs out of cruising money. He's been playing and working with computers since the Elder Days (anybody remember the Elf II?), and isn't about to stop any time soon.

Kapil Sharma

Kapil Sharma is a Linux/Unix and Internet security consultant. He has been working on various Linux and Unix systems for more than 2 years. He is providing commercial support for Linux/Unix systems and writing technical articles. His professional web site is linux4biz.net.

Mark Taylor

Mark works at Motorola Computer Group on diagnostics for the custom circuits on MCG's x86 computer board products. He has also done 68K firmware, a SCO Unix device driver, some Ada applications, and 10 years of avionics software. Mark is happiest down in the lowest levels of the system tweaking hardware.

Alan Ward

Alan teaches CS in Andorra at highschool and university levels. He's back to Unix this year after an 8-year forced interlude since he graduated -- it makes networking so much easier. His hobbies include science photography (both digital and traditional), trekking, rock and processor collecting.

Irving Washington

Irving Washington (pseud.), as witnessed by his personal server www.fifthgate.org, is mostly interested in creating useful web services.

Dan York

Dan recently joined the staff of LinuxCare, to work full-time on developing the Linux Professional Institute certification program. He has been working with the Internet and UNIX systems for 13 years and PCs since the early Apple computers in 1977 . While his passion is with Linux, he has also spent the past three years working with Windows NT. Dan has written numerous articles for technical magazines, and has also spoken at various conferences within the training industry. He is now a member of the Certification committee of the Systems Administrators Guild (SAGE - a division of USENIX).

---

Not Linux

---

www.linuxgazette.com usage stats

Here are the top 10 browsers/spiders which viewed the main LG site in August:

Top 15 of 1071 Total User Agents
#	Hits		User Agent
1	880501	38.63%	MSIE
2	829419	36.39%	Netscape
3	269986	11.85%	Wget/1.5.3
4	44209	1.94%	Teleport Pro/1.29
5	29842	1.31%	WebCopier
6	25202	1.11%	testspider
7	11080	0.49%	HTTrack 2.0
8	8966	0.39%	AVSearch-3.0(EoExchange/Liberty)
9	8432	0.37%	Opera 4.0
10	7927	0.35%	AvantGo 3.2
11	7438	0.33%	Slurp/2.0-BigOwlWeekly (spider@aeneid.com; http://www.inktomi
12	7107	0.31%	GETWWW-ROBOT/2.0
13	5985	0.26%	Slurp/2.0-RedtailCrawl (slurp@inktomi.com; http://www.inktomi
14	5160	0.23%	Konqueror/1.1.2
15	4717	0.21%	sitescooper/3.0.0beta (http://sitescooper.cx) libwww-perl/5.4

Usage has been hovering at 80,000-90,000 readers (=unique IPs) per month, or 135,000-155,000 visits (from the same IP within a short time period). Of course, some IPs represent multiple readers, but on the other hand, readers with dynamic IP addresses are counted for each address they visit under, so it probably evens out. This includes only www.linuxgazette.com, not the mirrors.

The Gazette mailbox overfloweth with spam

• Fed up with being shut down by your ISP? People screaming? People sending you FLAMES? Being bombarded with COUNTER OFFERS? LOW response rate? Then let us take over the hassles for you... Promote your web site without the worries of it being shut down because of spam complaints. Our operation centers are protected by Central Intelligence Agency level security.

• I was wondering if you were interested in DRAMATICALLY increasing your INTERNET SALES and SIGNUPS and getting MORE WEBSITE TRAFFIC.

• Build a residual income from time you spend on the Internet placing FREE advertisements like this.

• As you can guess this is unsolicited mail and some people are cross when they get it and complain to the ISP.. For this reason we do not want to send it through our ISP WHO MAY STOP serving us. I hear that at your end things are not as strict. Can we host a site with you and use your ISP for mailing? If positive -what is the cost.

• We have found your resume on web. We would like to know if you are still pursuing a position. [Since when did Linux Gazette have a resume? -Ed.]

But this piece qualifies as the Spam Of The Summer

It's no secret that the Internet has very recently developed into the hottest marketing medium since television! Those with the skills to take advantage of this new medium are starting to make some very serious money.

My offer to you is this. You send me $39 bucks I will mail You my E-mail Marketing Kit CD Disk containing the following information and software.

Bla bla bla The Bulk E-mail Handbook bla bla bla The Targeted Direct E-mail Marketing E-Book bla bla bla...

As if this wasn't enough, hold on to your seat, I am even going to give you absolutely FREE the following software:

1. 1.) A copy of CHECKER CHECKS BY FAX SOFTWARE... This is a fully functional program not a crippled demo. Now you can take payment from your customers by Fax, Phone or E-mail simply by taking their Checking account information.

2. 2.) A copy of smtp lookup software that will find you foreign mail servers you can use to send your mail completely undetected. This software will test mail through hundreds of servers an hour. I will even Supply you with a list of 16000 foreign domains to insert into your testing.

And I will throw in 500,000 Fresh E-mail addresses. If you are selling a product or service these are the addresses you want.

SPECIAL BONUS if you order your CD By 9/30/00 I will supply you with a copy of E-mail Software you can use to send your message to millions and a copy of E-mail list extracting software you can use to extract E-mail Addresses from all over the Internet.

Just make out your check for $39 payable to X and write void across the face then tape or glue it to the order form at the bottom of this page and you will have your E-mail Marketing Information Kit mailed the same day.

Read paragraph "1." again. He'll send you software which allows you to "take payment from your customers ... simply by taking their Checking accunt information". Thus, he has software which allows him to take payment from you simply by taking your checking account information.

When do people normally ask for a voided check? When you're setting up automatic payment with them, of course! So you can pay the monthly electric or ISP bill without having to write a check. But this is a one-time payment, isn't it? Or is it?

No wonder he tells you to write "VOID" on the check. He doesn't plan on cashing it anyway. Now the question becomes, will he put the order through at $39? Or $399?

Happy Linuxing.

Michael Orr
Editor, Linux Gazette, gazette@ssc.com

Copyright © 2000, the Editors of Linux Gazette
Published in Issue 58 of Linux Gazette, October 2000