|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://itpm.msu.su/LDP/LinuxAdministration/linux-admin-made-easy-10.html
Дата изменения: Sun Apr 18 13:35:41 1999 Дата индексирования: Mon Oct 1 21:59:36 2012 Кодировка: |
To get the most out of your Linux server, such as adding features, getting rid of potential bugs, and ensuring it is reasonably free of security holes, it is a good idea to keep your server -- including the Linux kernel, modules, and user applications -- upgraded. At times it may also be necessary to upgrade hardware components such as a larger hard drive. This chapter will address these issues.
The Red Hat distribution of Linux, including kernel, libraries, and applications are provided as RPM files. An RPM file, also known as a "package" is a way of distributing software so that it can be easily installed, upgraded, queried, and deleted. RPM files contain information on the package's name, version, other file dependency information (if applicable), platform (such as Intel or Alpha, etc.), as well as default file install locations.
The RPM utility was first developed by Red Hat and provided as an Open Source product as is common in the Linux community. Other developers picked it up and added extra functionality. The RPM method of packaging files has become popular and is used not only on Red Hat's but on some other distributions as well.
Popular Linux applications are almost always released as RPM files,
usually in fairly short order. However, in the Unix world the defacto-standard
for package distribution continues to be by way of so-called
"tarballs". Tarballs are simply files that are readable
with the ``tar'' utility. Installing from tar is usually
significantly more tedious than using RPM. So why would people choose
to do so? Unfortunately, sometimes it takes a few weeks for developers
to get the latest version of a package converted to RPM (many developers
first release them as tarballs).
If you start installing or upgrading your system or applications with tar, your RPM database will become out-of-date and inconsistent. This isn't really a big deal (when I used Slackware, I used tar exclusively -- there was no other choice -- without too much discomfort), but wherever possible I try to be patient and wait until an RPM becomes available, or perhaps send a polite request to the developer of the package. (You can also build your own RPM files and distribute them to others, which is sometimes helpful to developers who don't have the ability or time to produce such files themselves.)
A really good place to check if a piece of software is available in RPM form is the RPM repository at http://rufus.w3.org/linux/RPM/. The repository provides indexed categories which can be helpful to locate a given RPM file, and contains pointers to thousands of such files.
To query a package, use ``rpm -q pkg-name'' (eg. ``rpm -q pine''). RPM
will either tell you what version of the package is already installed,
or that the package is not installed.
Assuming the package is installed already, and is an earlier version than
the update package you downloaded (which it should be), then you should be
able to apply the update with ``rpm -Uvh pkg-name''. If all goes
well, the package will be automatically installed and immediately ready
for use. If not, RPM will give you a pretty good reason (for example,
perhaps a supporting package needs to be upgraded first). This may
require a bit of thinking, but problems such as these are very
straightforward to figure out.
If, on the other hand, the package is not yet installed, and you
decide you wish to install it, type ``rpm -ivh pkg-name''. If
there are any supporting packages that are required, RPM will tell you.
Sometimes, you will want to install a package that is only available in source format. In fact, unless you are installing packages from a trusted source (such as the Red Hat FTP site), you probably should install from source in case the binaries contain a trojan horse or other nasty thing (of course, a source RPM could also contain such a thing, but they are unlikely to because they would probably be exposed in short order by another developer).
The way to install a package from source is to specify the ``rebuild''
switch to the RPM utility. For example:
rpm -ivh --rebuild foo.src.rpm
The above command would configure and compile the ``foo'' package, producing a
binary RPM file in the
``/usr/src/redhat/RPMS/i386/'' directory (assuming
you are using Linux on the Intel platform). You can then install the
package as you normally would.
Finally, if you are having problems getting a source package to compile (perhaps you need to modify a makefile, or change a configuration option, etc.) you can use the following steps (again, illustrating our ficticious ``foo'' package example) to compile the source, build a new binary package, and then install from the binary package:
rpm -ivh foo.src.rpm
cd /usr/src/redhat/SPECS
pico -w foo.spec
Make whatever changes you feel are needed to the ``.spec'' file, and then:
rpm -ba foo.spec
This will rebuild the package using whatever changes you have made to the
``.spec'' file. As above, the resultant binary RPM file will be located
in ``/usr/src/redhat/RPMS/i386/'', and can be
installed as you normally would.
You should look at the Red Hat documentation for more information on RPM.
It is an extremely powerful tool that is worth learning in finer detail. The
best source of information on RPM is ``Maximum RPM'', which is available
in both book form, as well as in postscript format at
http://www.rpm.org/maximum-rpm.ps.gz. (If you decide to print
the postscript document, be advised that you'll need a lot of
paper to do so!) There is a smaller guide, the ``RPM-HOWTO'',
at
http://www.rpm.org/support/RPM-HOWTO.html available as well.
Sometimes, you may find it necessary to install or upgrade an application for which an RPM package is not available. Of course, it is certainly possible to do such a thing (in fact, it is the "defacto-standard" way of doing things in the "real" Unix world), but I would recommend against it unless absolutely necessary (for reasons why, see the "Using the Red Hat Package Manager" section).
Should you need to install anything from tarballs, the general rule of
thumb is to place things in your ``/usr/local/''
filesystem. Therefore, source tarballs would be untarred in
``/usr/local/src/'', while resultant binaries would
probably be installed in ``/usr/local/bin'', with
their configuration files in ``/usr/local/etc/''.
Following such a scheme will make the administration of your system a
bit easier (although, not as easy as on an RPM-only system).
( Under construction :-p )
Again, I really recommend avoiding tarballs if you can.
From time to time you may hear of significant upgrades to the Linux kernel or user applications from various sources. These sources may be magazines, newsgroups, web pages, etc.
Probably the best single online resource that a Linux administrator should -- nay, must -- keep an eye on is the http://freshmeat.net/ web site. This site contains descriptions of new Open Source applications and projects, documentation, and other announcements of interest to the Linux community.
Another resource for keeping track of new applications announcements is through the comp.os.linux.announce newsgroup. This newsgroup contains postings of new applications, some kernel or application upgrades, web pages, etc. available for Linux. It is a moderated newsgroup and therefore has a high "signal to noise" ratio.
Not all product upgrade announcements are made to comp.os.linux.announce, however. Therefore, visiting the web pages or FTP sites for the applications you are using is probably a very good idea as well.
From time to time it may be wise to upgrade your Linux kernel. This will allow you to keep up with the new features and bug fixes as they become available. Or, perhaps, you are running Linux on new or specialty hardware, or wish to enable certain features for which a custom kernel is needed.
This section will describe upgrading and customizing a new kernel. It isn't as difficult as you might think!
Announcements of new kernel versions can be obtained through various sources, including the comp.os.linux.announce newsgroup, as well as on the http://freshmeat.net/ and http://slashdot.org/ web sites.
Please note that there are currently two "streams" of kernel development -- one stream is considered "stable" releases, while the other stream is considered "development" releases. For mission critical applications such as an Internet server, it is highly recommended that you use the stable releases and stay away from the development kernels.
The difference between the two streams is that, with the development kernels, new as-yet untested hardware drivers, filesystems, and other "cutting edge" developments are introduced on a regular basis. These kernels are for use by hackers only -- people who don't mind having to reboot their system, should a kernel bug rear its ugly head.
The stable kernels introduce new features and drivers only after they have been thoroughly tested. Minor releases in this stream also serve to clean up any remaining bugs that are found and corrected.
The two streams use version numbers which are numbered differently to help distinguish between them. The stable kernels are numbered with the second number even (eg. 2.0.35, 2.0.36, 2.2.4) while the development kernels are numbered with the second number odd (eg. 2.1.120, 2.1.121, 2.3.0).
The latest stable kernel is always made available in source as well as
pre-compiled binary formats on the
ftp://updates.redhat.com/ FTP
site. Download the desired kernel packages for your version and platform
(for example, you would want to navigate to the
``/5.2/i386/'' directory and download the
``kernel-*.i386.rpm'' files for the 5.2 version on
the Intel platform). Note: You do not need to download the
kernel sources file unless you are planning on building a custom kernel
yourself (see the
"Building a Custom Kernel" section for details on
building a custom kernel).
Sometimes, you may find it necessary to use a kernel that has not yet been
made available as an RPM. In this case, you can find the latest kernels
from the
ftp://ftp.kernel.org
FTP site, in the
/pub/linux/kernel/ directory. Change to the appropriate major
version subdirectory (eg. ``v2.0''), which contains
all kernel releases up to the most current one. Download the desired
kernel package (for example, the compressed tarball for version 2.0.36
would be called ``linux-2.0.36.tar.gz'' for the
Intel platform) and untar it in the ``/usr/src''
directory. Note: Most user-installed applications not installed
from RPM should be untarred under the ``/usr/local/src/''
directory by convention, but this is a kernel tree so we'll make an
exception in this case. :-)
Please be aware that if you decide to upgrade your kernel by downloading a tarball, you will most certainly need to configure, compile, and install it yourself. Unless you have special needs that require the very latest development kernel, I strongly recommend you upgrade your kernel through Red Hat-provided RPM files -- these are preconfigured and precompiled for you, although you can compile a custom kernel from RPM files as well should you wish.
By far the easiest way of upgrading your kernel is to do so using a stock kernel RPM as provided by Red Hat. These RPM files contain pre-compiled binary kernel code, with support for a large variety of hardware and popular features.
Installing a stock kernel is easy to do and involves little risk. Simply type, as root, the following sequence of commands:
rpm -Uvh kernel-2.0.36.i386.rpm
cd /boot
ls
Make note of the new kernel name, as reported by the ``ls''
command above. You are interested in the
``vmlinuz'' file; for example the third RPM release of
kernel 2.0.36 would look like ``vmlinuz-2.0.36-3''.
Now, use an editor to edit the LILO configuation file (type: ``pico -w
/etc/lilo.conf'') and change the ``image=/boot/...'' line to
point to the new kernel file. After you have done so, type
``/sbin/lilo''. If LILO reports an error message,
double-check the file name in your ``lilo.conf''
file with the file name in the ``/boot/'' directory.
Note: Do not forget this step!
(The above commands assume you are using the Intel platform and use LILO to boot your system. See the "Booting with LILO" section for details on the LILO boot loader).
After you have upgraded your stock kernel and have updated your boot loader information, you should be able to shutdown and reboot using the new kernel (see the "System Shutdown and Restart" section for details on shutting down your system).
If you are running Linux on a system with hardware or wish to use features not supported in the stock kernels, or perhaps you wish to reduce the kernel memory footprint to make better use of your system memory, you may find it necessary to build your own custom kernel.
Upgrading the kernel involves configuring desired modules, compiling the
kernel and modules, and finally installing the kernel image. This is
followed by a system reboot (with fingers crossed!) to load the new
kernel. All of this is documented in the ``README''
file which comes with each kernel package. Further information can be
found in the ``Documentation/'' subdirectory. A
particularly helpful file there is
``Configure.help'' which contains detailed
information on the available kernel compile options and modules.
The following is a sample session demonstrating the build of a custom kernel, version 2.0.36 on the Intel platform. While building a custom kernel is usually just a matter of configuring, compiling & installing, sometimes (usually in the case of new hardware) it is necessary to download additional driver software should your hardware not yet be supported by the kernel version you are compiling.
The first step in building a custom kernel is to download and install the kernel sources from either RPM (preferred) or from tarball. See the "Linux Kernel Upgrades" section for details on obtaining the appropriate files.
Next, use the ``rpm'' utility (or ``tar'', as appropriate)
to install the kernel source tree and header files. For example, to install
the 2.0.36-3 kernel RPM files:
rpm -Uvh kernel-source-2.0.36-3.i386.rpm kernel-headers-2.0.36-3.i386.rpm
rpm -Uvh kernel-ibcs-2.0.36-3.i386.rpm
(You would also likely install the
``kernel-pcmcia-cs-2.0.36-3.i386.rpm'' file if you
are a laptop user.)
After installing the kernel files, you should be able to find the new
source tree in the ``/usr/src/linux/'' directory.
The next step is to download any additional driver files (if applicable)
and install them in the new kernel source tree. For example, to add
support for the Mylex DAC960 hardware RAID controller, I would download
the driver software from the
http://www.dandelion.com/ web site. Unfortunately, such driver
software are usually only offered as tarballs and need to be installed
using the ``tar'' utility. For example:
cd /usr/src/
tar zxvpf DAC960-2.0.0-Beta4.tar.gz
You should read the documentation provided with your additional driver
software, if applicable. For example, the DAC960 driver includes a
``README'' file which gives instructions on where
the newly downloaded files should be located, and how to apply the kernel
patch:
mv README.DAC960 DAC960.[ch] /usr/src/linux/drivers/block
patch -p0 < DAC960.patch
The next step is to ensure your system's symbolic file links are consistent with the new kernel tree. Actually, this step only needs to be done once, so the following needs to be done only if you haven't compiled a custom kernel before:
mail:/usr/src# cd /usr/includemail:/usr/include# rm -rf asm linux scsi
mail:/usr/include# ln -s /usr/src/linux/include/asm-i386 asm
mail:/usr/include# ln -s /usr/src/linux/include/linux linux
mail:/usr/include# ln -s /usr/src/linux/include/scsi scsi
The next step is to configure your kernel settings. This is the most important step in building the custom kernel. If you disable the wrong settings, you may leave out support for features or hardware you need. However, if you enable the wrong settings, you will be needlessly enlarging the kernel and wasting your valuable system memory (that being said, it is probably better to err on the side of the latter rather than the former).
The best way of ensuring you compile the kernel properly is to know what features you will need to use, and what hardware is in your system that you will require support for. After you have gained experience in customizing your kernel a few times, the process will become "old hat" and won't seem so intimidating!
Type the following to begin the configuration process:
mail:/usr/include# cd /usr/src/linuxmail:/usr/src/linux# make mrproper
mail:/usr/src/linux# make menuconfig
(You could type ``make xconfig'' instead of ``make
menuconfig'' if you have the X Window System running; see the
"Configuring the X Window System" section
for details on how to get X working.)
To configure your kernel, go through the various settings and select
(enable) whichever ones you require, and de-select (disable) the ones
you do not require. You can choose between having such support built
right into the kernel, or having it built as a module which is loaded
and unloaded by the kernel as needed. (If you compile a feature that is
actually needed to boot your system, such as a SCSI driver, as a module,
you will need to create a RAMdisk image or your system will not boot.
This is done with the ``mkinitrd'' command; this procedure is
described a little further down.)
When going through the configuration settings, you can select
<Help> for a description of what a given kernel option is
for.
After you have configured your kernel settings, type the following commands to compile your kernel:
mail:/usr/src/linux# make dep ; make cleanmail:/usr/src/linux# make bzImage
mail:/usr/src/linux# make modules
If you are recompiling the same kernel as you have previously (2.0.36-3 in this example), you will likely want to move the existing modules to a backup directory as with the following command:
mail:/usr/src/linux# mv /lib/modules/2.0.36-3 /lib/modules/2.0.36-3-backup
Now, type the following command to actually install the new modules:
mail:/usr/src/linux# make modules_install
The next step is to copy the kernel into the ``/boot/''
directory and use LILO to update the boot record so that the new kernel
is recognized. The following commands will make a backup copy of your
existing kernel, copy the new kernel over, and then refresh the LILO boot
record:
mail:/usr/src/linux# cd /bootmail:/boot# cp vmlinuz vmlinuz.OLD
mail:/boot# cp /usr/src/linux/arch/i386/boot/bzImage vmlinuz-2.0.36
mail:/boot# /sbin/lilo
Finally, you will need to edit your
``/etc/lilo.conf'' file, and make sure the
"image" reference is pointing to the new kernel. You should
also add a section which points to your backup kernel, called, perhaps,
"OldLinux". Here is an example file:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
image=/boot/vmlinuz
label=Linux
root=/dev/hdb1
read-only
image=/boot/vmlinuz.OLD
label=OldLinux
read-only
By adding your backup kernel information in this way, should your new
kernel fail to boot properly (perhaps a device is not recognized, or a
daemon doesn't start as it should), you can simply type
``OldLinux'' to boot from the old kernel and investigate the
problem.
Note: As mentioned previously, if you've compiled a feature required to boot your system as a module, you will need to create an initial RAMdisk image in order to boot your system. (Don't forget to compile your kernel with support for such an initial boot image.)
The procedure to create and use an initial RAMdisk image is as follows:
/etc/lilo.conf'' to boot
off the initial RAMdisk image; this is shown as an addition to the example
configuration file shown earlier:
image=/boot/vmlinuz
label=Linux
root=/dev/hdb1
initrd=/boot/initrd-2.2.4-4.img
read-only
/sbin/insmod loop
(If you get an error message about not being able to load the loopback
module, you may need to specify the full path to the module for the
current kernel your system is still running on, for example
``/lib/modules/2.0.35/loop''.)
mkinitrd'' command to actually create the image:
/sbin/mkinitrd /boot/initrd-2.0.36-3.img 2.0.36-3
/sbin/lilo'' to update your boot loader.Now, shut down your system and boot the new kernel!
mail:/boot# /sbin/shutdown -r now
If your kernel refuses to boot altogether, don't panic. Boot off the boot disk that was created during the installation of Linux . If you don't have copies of this disks, you should be able to create one from the Red Hat CD. Insert the boot diskette into the drive and reboot the computer. When you see the "boot:" prompt, type:
mount root=/dev/hda1
The above command assumes your "/" (root) partition is located on /dev/hda1.
Linux should then boot normally (although since you are using the kernel
from the boot disk, not all services or devices may operate properly for
this session), and then you can restore your old kernel and reinstall the
LILO boot loader information (ie. ``mv /vmlinuz.old /vmlinuz ;
/sbin/lilo'') and shutdown/restart. You can then try recompiling the
kernel with different options and try again.
(WARNING! THIS SECTION NOT YET COMPLETE AND WILL ALMOST CERTAINLY CAUSE YOU TO MUCK UP YOUR SYSTEM IF YOU FOLLOW THE INSTRUCTIONS CONTAINED HEREIN -- I've just moved to the new kernel after much trial and error. I'll clean this section up sometime in May, after exams are finished.)
The Linux kernel 2.2.0 was released on January 25, 1999, bringing with it many new features, performance enhancements, and hardware support. Any existing Linux system can be upgraded with one of these new kernels in much the same fashion as described in the "Linux Kernel Upgrades" sections (with caveats).
At this time I cannot recommend upgrading to a stock kernel, but instead upgrading by compiling a custom kernel. The move to the 2.2.x kernels involves some additional issues as well, so unless you have had experience with upgrading files with RPM and compiling kernels, perhaps you might wish to wait until Red Hat releases a newer distribution with support for this kernel already built-in.
In order to use the latest kernel, it is first necessary to upgrade to the newest utilities and libraries. At the time of this writing, the 5.2 version of the Red Hat distribution did not have upgrades available, so therefore you may find it necessary to find the necessary upgrades from other sources, such as the ftp://rawhide.redhat.com/ FTP site.
A very good web page, detailing the appropriate system tools that are necessary for moving to 2.2.x is available at http://www-stu.calvin.edu/~clug/users/jnieho38/goto22.html; I will attempt to summarize the information below (items marked with a leading ``**'' indicate you will most likely need to upgrade the item for Red Hat 5.2; items not indicated as such are probably okay but probably worth checking).
rpm -q
modutils'' to check your version)rpm -q gcc'')rpm -q binutils'')rpm -q glibc'')ls -l /lib/ld.so.*'')rpm -q libg++'')rpm -q procps'')rpm -q procinfo'')rpm -q psmisc'')rpm -q net-tools'')rpm -q sh-utils'')rpm -q autofs'')rpm -q nfs-server'';
needed only if you are serving NFS file shares.)rpm -q bash'')rpm -q ncpfs''; needed only
if you are mounting Novell file systems.)rpm -q kernel-pcmcia-cs'';
needed only for laptops which need PCMCIA card support.)rpm -q ppp''; needed only
if you are connecting to the Internet with a modem and PPP.)rpm -q util-linux'')rpm -q setserial'')You should download and upgrade any packages using RPM as required (see
the
"Using the Red Hat Package Manager"
section for details on how to use RPM). Note: Upgrading to the
new ``modutils'' package will result in modules no longer
functioning for the older 2.0.x kernels! Therefore, do not upgrade this
package until you have installed the new kernel in
``/usr/src/linux''.
After bringing your system's tools up to date, you can install the kernel sources. To do so, type the following:
rpm -Uvh kernel-sources*.rpm kernel-headers*.rpm
Now that the new kernel sources have been installed, it should be safe to
upgrade your modutils package. However, the new kernel no longer uses the
``kerneld'' module for on-demand loading of kernel modules.
Therefore, you should disable this module before updating modutils. To
disable kerneld and upgrade the modutils package, type the following as
"root":
/sbin/chkconfig kerneld off
/etc/rc.d/init.d/kerneld stop
rpm -Uvh modutils*.rpm
You should now be able to configure, compile, and install your 2.2 kernel as you normally would (see the "Building a Custom Kernel" section for details). You may be surprised to see the dizzying amount of new configuration settings available. Take your time and read the help text for any options you are unfamiliar with!
With any luck, the next time you boot your system you will be running the latest and greatest Linux kernel version!
Much more detailed information on these procedures can be found at the http://www-stu.calvin.edu/~clug/users/jnieho38/goto22.html web page. Red Hat itself has made some information available, at http://www.redhat.com/support/docs/rhl/kernel-2.2/kernel2.2-upgrade.html.
I will likely remove this section from future versions of this document, once Red Hat has released a new distribution with built-in support for the 2.2.x kernel stream and a majority of users have migrated to it.
At my place of employment, we are using the Apache package to provide web services. Apache is a full-featured web server with full support for the HTTP 1.1 standard, proxy caching, password authenticated web pages, and many other features. Apache is one of the most popular web servers available (according to a recent site survey done by Netcraft, more than 54% of all web sites on the Internet are using Apache or one of its derivatives), and provides performance equal or better to commercial servers.
( Under construction. :-p )
To keep up with added features and bug-fixes that are made to Apache, it is a probably a good idea to upgrade your server from time to time. The Apache web site is located at http://www.apache.org/ and contains information on the latest versions.
At my place of employment, we use the Squid package to provide proxy caching of web pages. Squid offers high-performance caching of web clients, and also supports FTP, Gopher, and HTTP requests. In addition, Squid can be heirarchically linked to other Squid-based proxy servers for streamlined caching of pages.
There are two versions of Squid currently available. One, the "regular" version, seems to work well on machines with lots of RAM. The second version, "SquidNOVM" is suitable for machines with less RAM (I recommend using this version if you have 64 MB of RAM or less). Basically, the "NOVM" version uses less memory at the expense of more file descriptors. It's the one I use, and it works well.
( Under construction :-p )
To keep up with new features and bug-fixes, it is a probably a good idea to upgrade the Squid server from time to time. More information on Squid can be found on web site at http://squid.nlanr.net/Squid/.
I use the Sendmail package to provide e-mail services. Sendmail is the definitive mail handler; in fact it is so popular that it is estimated that over 80% of e-mail passing over the Internet will be handled at one or both ends by it. It does just about anything and I couldn't imagine running an Internet server without it (another e-mail server package called Qmail seems to be quite popular as well -- but I haven't had a reason yet to give it a try).
To keep up with new features and bug-fixes, and most importantly, for reasons of security, it is a probably a good idea to upgrade Sendmail from time to time. In addition, the very latest versions of Sendmail include powerful anti-spam features which can help prevent your mail server being abused by unauthorized users.
This section will discuss some of the things you should do if you wish to use Sendmail as an incoming e-mail server. This would be the likely scenario for server systems. If, instead, you have no need to use it for incoming mail and wish to only use it as an outgoing mail queue, you should ((need some info here)).
For this section, it is assumed that you are using the very latest version of Sendmail (8.9.3 at the time of this writing), have it installed and running.
As packaged with the Red Hat distribution, Sendmail usually contains
appropriate configuration information to operate correctly in the majority
of server setups. Nonetheless, you may find it necessary to edit the
``/etc/sendmail.cf'' file and customize some
settings as required. This, however, is beyond the scope of this document.
One thing I find helpful, however, is to make a couple of changes to the configuration file to thwart off spammers. These include:
O PrivacyOptions=authwarningschange to:
O PrivacyOptions=authwarnings,noexpn,novrfy
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b
change to:
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b NO UCE C=xx L=xx
(The first change prevents spammers from using the ``EXPN'' and
``VRFY'' commands in sendmail. I find that these commands are
too often abused by unethical individuals. The second change modifies
the banner which Sendmail displays upon receiving a connection. You should
replace the ``xx'' in the ``C=xx L=xx'' entries with
your country and location codes. For example, in my case, I would use
``C=CA L=ON'' for Ontario, Canada. (The latter change doesn't
actually affect anything, but was recommended by folks in the
news.admin.net-abuse.email newsgroup as a legal precaution.
Next, if your mail server will have a different host name than the actual
machine it is running on, you can add one or more aliases in the
``/etc/sendmail.cw'' file. For example, if you have a
system called "kirk.mydomain.name" which is set up as
the mail exchanger for mydomain.name, but want incoming mail addressed in
the format ``user@mydomain.name'' to be delivered to your users
on "kirk", simply add this alias as follows:
mydomain.name
Finally, If you need to restrict a domain (or subdomain) from connecting
to your sendmail service, you can edit the
``/etc/mail/access'' and add the domain information
as well as type of restriction. For example:
some.domain REJECT
hax0r.another.domain 550 Contact site administrator at (555) 555-1234.
The above examples would reject all e-mail connections from the ``some.domain'' site, as well as reject the specific machine name ``hax0r.another.domain'' with a descriptive message.
After making changes to this file, you will need to update the
``access.db'' file, and then restart sendmail as
follows:
/usr/sbin/makemap hash /etc/mail/access.db < /etc/mail/access
/etc/rc.d/init.d/sendmail restart
For more information on Sendmail, see the FAQ document located at http://www.sendmail.org/faq/.