[svlug] InstallFest

[Rick Moen]

Javilk wrote:
 
> Found it -- multiple occurances of the same name but different IP
> numbers in /etc/hosts.  At least once I cleaned that up, it started ok
> each time...  Funny how it would sometimes work...

Ah, good that you found that.  Yes, that _would_ mess things up.

>> Edit /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcft-eth0,
>> plus any static routes and static hostfiles, after preserving the 
>> originals as *.SAV.  (If you get your address from DHCP, I'm not sure
>> what you do.)  Stop and start network services.  Et voila.

>    Will have to look up what that all means...

The "static hostfile" would be /etc/hosts.  On my system, static IP
routes are stored in /etc/sysconfig/static-routes.  On any Linux using
System V init (most if not all of them, by now), networking can be
stopped by invoking "/etc/rc.d/init.d/network stop" and restarted using
"/etc/rc.d/init.d/network start".  (The "rc.d" subdirectory level is
a RedHat-ism, not present for example on Debian.)
 
> NETWORKING=yes
> FORWARD_IPV4=false
> HOSTNAME=meg.mall-net.com
> DOMAINNAME=mall-net.com
> GATEWAY=10.255.255.254
> GATEWAYDEV=eth0

This must be your /etc/sysconfig/network file.  (You did not so state.)
 
> Somehow, I wonder if the gateway should be the IP number of the link
> between my machine and my ISP? 

The "gateway" IP address is by definition that of the "way out", so to
speak.  That is, it should be the interface on your LAN's side of a
router whose far side is on some outside network.  ("Links" don't have
IP addresses, nor do machines:  _Interfaces_ have them.)

Let's say you have five machines on your home LAN, bearing IP addresses
10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4, and 10.0.0.5.  The first of these
is some machine with a WAN interface (connected to a modem, ISDN terminal
adapter, T1 CSU/DSU, or something) that eventually reaches your ISP.
That machine is by definition a router:  It has two interfaces that are
on different numeric IP networks, and knows how to forward IP packets
between them.

Given that set of facts, you'd want to configure all five of those 
machines to use 10.0.0.1 as their gateway IP address.

Please note that I'm making no particular effort to address _your_
particular situation, both because you've given me nothing like adequate
information to work with _and_ because this is a mailing list rather
than a private support facility.  So, if the above helps your specific
problem, good -- but, if not, it'll have to serve as background 
information for somebody on this list (one hopes).

(As you may recall, 10.0.0.0 is one of the official "private IP address"
networks.  One would have to use Network Address Translation, or a 
firewall, or something similar, to reach the Internet from such a 
machine.)


[CDR drives]
 
>     I've been thinking of buying one.

My opinions, yours for a small fee:  The Yamaha, Ricoh, and Philips SCSI 
drives look good.  CD-RW (rewritable) looks like a boondoggle.  Heat
generation looks significant, so I'd put it in an external case.  MTBF
hours are low and warranties short, so _don't_ use them for general
read-only use:  Get a second, conventional drive for everyday use, and
keep the CDR powered down when not in use.  Use active terminators!
Use high-quality, short SCSI cables!

When doing direct CD-ROM to CDR dubbing, make sure you read at least
twice as fast as you write.  If this isn't possible, write an ISO9660
image to HD first, _then_ burn the CDR.  Check the CD Writing HOWTO and
CDR FAQ before buying.  Check to make sure you have a good-by-reputation
firmware version, especially for capturing CD audio (CDDA) tracks, which
is a demanding task.

Software you'll want:

cdrecord 1.6+ or cdwrite 2.0+ (former is better maintained)
xcdroast
cdda2wav
sox
mkisofs
mkhfs (mkhybrid)
Joliet FS patches for your Linux kernel version

All of the above is freeware.  And good stuff, too.  Naturally.


> I see. Of course, my fetchmail did work, I just wanted to configure
> it, but it was useful to see how one builds it.

Well, especially since that's how one builds software generally:
Unpack the tarball, read the README* or INSTALL* files for any special
instructions.  Then:

./configure
edit the resulting Makefile, to customise install dirs, etc.
make
make check
make install

If the original version was in a different directory, you may want
to remove or rename it, and replace it with a symlink to the new
installation.  E.g., Red Hat installs tar to /bin/tar, and I chose
to put _my_ new compiled version of it to /usr/local/bin/tar, so
I renamed /bin/tar to /bin/tar.INSTALL, and in its place created
symlink

    /bin/tar   -->     /usr/local/bin/tar

This ensures that anything that's hard-coded to look in the original
location can still find tar.  You should probably want to install
new/recompiled versions of most things into somewhere in the /usr/local 
tree, to protect them against accidental overwriting if/when you have
to reinstall your OS.  (See the File Hierarchy Standard document on
the Web for more on this rationale, and similar matters.)

As I was saying, if you want to try some painless compilations, in
order to get used to the process, try getting the latest source for
some FSF utilities, from ftp://ftp.gnu.org/pub/gnu/.  For example:

autoconf-2.12.tar.gz                401 Kb
automake-1.2.tar.gz                 281 Kb
cpio-2.4.2.tar.gz                   180 Kb
gzip-1.2.4.tar.gz                   215 Kb
tar-1.12.tar.gz                     847 Kb

Those are ideal candidates.  Also perl5.004_04.tar.gz from
ftp://ftp.perl.org/pub/CPAN/src/5.0/ (about a meg and a half),
which is one of those with ideosyncratic but easily followable
instructions.

Go ahead and try them!  You have absolutely nothing to lose, if 
you stop before "make install" if anything looks peculiar.  (If
it looks peculiar, believe me, you'll know.)

The point of what I was saying to you is that you get _much_ better
use of and satisfaction from a Linux box if you at least _start_ 
learning how to install packages from source tarfiles.  As I was
saying at the InstallFest, Red Hat provides an excellent way to
gradually do this, and many Red Hat users never realise it:  SRPM
(source-code RPM) packages.

For the benefit of the many if not most people who didn't overhear
us, it's like this:  Binary RPMs, the only ones most people think
to use, are an excellent way to get a system up and running quickly.
However, thereafter, there are many occasions on which you feel an
urge to replace or upgrade one of those packages.

The first impulse for a Red Hat sysadmin is to find a binary RPM
for his platform, and use rpm or glint to install it.  For example,
suppose there's a new and serious root-exploit security problem.
Good idea, but...

Maybe the new binary RPM doesn't exist, yet.  Maybe it won't install
on your system because you have different libs.  Maybe it's one of
those security-sensitive packages where you'd feel really stupid
putting in trojan-horse code accidentally because you used someone
else's binary.  Maybe you just want to understand the process a
little better.

So, you look for an SRPM.  You run rpm or glint on it, to install
it.  Where'd it go?  Here's one area where I can help:  It unpacked
to /usr/src/redhat/SOURCES/, which is where you'll need to go next.
Look there, and you'll see a source-code "tarball" (a .tar.gz archive).
You'll probably also see one or more patch files, intended to 
"RedHat-ise" the source tree before compilation.  Unpack the tarball, 
then apply the patches, one at at time, like this:

   patch < patchname

Now, your source tree is configured.  Read the README* or INSTALL*
files, and proceed as described above.  When you're done, type
"make mrproper" to remove everything that's not source code, then
re-tar.gz the customised source tree and store it under 
/usr/local/src/installed/.  I like to put my hostname as part of
such stored archives, if they've been customised prior to 
compilation.  E.g., I have my lynx-SSL source tree stored as
/usr/local/src/installed/lynx-2.7.1-SSL-hugin.tar.gz.

And like that.  Having done a few of those, you're no longer at the
mercy of RPM packages -- and can fix the sendmail security hole
du jour as soon as you hear about it.  For example.

'Hope this helps.

-- 
Cheers,               Everything is gone;
Rick Moen             Your life's work has been destroyed.
rick@hugin.imat.com   Squeeze trigger (yes/no)?
                       -- David Carlson (winner, haiku error message contest)

--
echo "unsubscribe svlug" | mail majordomo@svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe