server change for mindprod.com

[Roedy Green]

The new server finally kicked in today for mindprod.com. If you have a
defective windows machine that improperly caches DNS, you might not
notice the difference for a couple of weeks unless you set up a hosts.
file for the new IP. The new server is at http://65.110.21.43. It has
faster hardware and a faster Internet connection, and optimised
software. I hope this translates into faster access for you. The old
server is at 65.110.20.60. You won't have to do anything. DNS name
mindprod.com has been redirected to the new IP, and eventually that
change will percolate down to your ISP. The old IP is shared, so
http://65.110.20.60 will not work. You would have to set up a hosts.
file to get at the old server. You can tell if you have flipped with
"ping mindprod.com". The old server will be left up for another two
weeks to allow time for defective windows DNS caches to flush.

 

[Martin Gregorie]

The new server finally kicked in today for mindprod.com.
>

Seems pretty quick, but you'd best revise your Linux page, which is
doing a disservice to your otherwise good site.

Its out of date (doesn't mention the Sun Java port) and at least one
link is broken (Blackdown).

 

[Roedy Green]

Seems pretty quick, but you'd best revise your Linux page, which is
doing a disservice to your otherwise good site.

Would you care to rewrite it, or tell me what needs to updated?

 

[Martin Gregorie]

Would you care to rewrite it, or tell me what needs to updated?
>

I won't rewrite it, any more that I'd expect or allow anybody else to
rewrite pages on my website. However, as I do expect and act on
criticisms of the speed/formatting/content of my site and I assume
you're the same, here goes. The following applies only to your Linux page:

For some reason the the page loads very slowly under Opera 9.24. Even on
redisplaying the page (clicking the browser's back arrow after following
a link off it) there's a several second delay while the title bar
flashes, switching between its 'current focus' and 'unselected'
appearances, before the page content appears. I haven't yet checked of
Firefox 2.0 also does this.

The Blackdown URL (1st para) gives a 404. Is Blackdown even relevant any
more? I went straight to Sun J2SE (running RedHat Fedora Core 1 at the
time) and now I'm weaving and ducking to avoid gcj, which is a standard
dependency within Fedora Core 7.

The 2nd para should just ignore the earlier RedHat distributions.
Anybody who uses RedHat privately will probably go for Fedora (current
is Fedora Core 8) and commercial users will probably install Red Hat
Enterprise Linux.

Intro 1: Ignore Caldera - its now history. All current distros have
vastly improved installers. My last clean FC7 install took under an hour
from a single DVD and "just worked". The only reboot was at the end to
start Linux. This left me with a working system connected to the
Internet with a full set of development tools, databases, an office
productivity suite and all the Internet utilities including Apache. The
only external I had to install was Opera, my preferred web browser.

I had downloaded the DVD image (2.8 GB, 90 minutes on broadband) and
burnt the disk myself, but copies are readily available for about GBP
5.00 by mail for those with slower internet connections.

The last time I reinstalled Win95 it took three days and innumerable
reboots by the time I'd reformatted the disk, installed all the drivers
from their separate disks and then loaded all the various packages
needed to make the system usable (MS Office, Opera, Borland C, Java,
Internet utilities, ...).

Equivalents: please remove rsh - nobody uses that these days - it sends
passwords as plain text. ssh does everything at least as well and more
securely. Telnet is used only for debugging and for accessing legacy
applications - plain text passwords again! Add sftp and gftp alongside
ftp - sftp does encrypted transfers and gftp is graphical, very similar
to WS-FTP. As a new entries, add The Gimp as equivalent to Paintshop
Pro, Photoshop, etc. XMMS and Audacious are audio players equivalent to
Winamp.

Installation, Installing hard disk partitions are now obsolete. The
various live CDs (Ubuntu, Knoppix etc) just run when put in the drive
and won't alter your HDD unless you tell them to. Fedora's installer
seamlessly handles everything you mention here. AFAIK the same applies
to other current distros too. My FC7 setup (on a 40 GB disk) uses these
partitions:

Name Size %used Comment

/boot 256 MB 9% contain kernel boot image(s)
/ 2 GB 16% root login, essential programs, temp disk, etc
/var 2 GB 14% system logs, NNTP files, mailboxes
/usr 15 GB 24% standard Linux programs
/home 15 GB 44% all logins and user data.
swap 1 GB - excessive (4 x RAM)

and all were defined, created and formatted by the installer. This
system runs SAMBA to fool my remaining Win95 box into thinking that its
a Windows file and print server. If it was dual boot, the Windows
partitions would appear alongside these and I'd be using GRUB, the Linux
boot system, to boot Linux or Windows.

Installing Video: XFree86 is obsolete, replaced by Xorg. Both the Live
CDs and the Fedora installer can configure that without assistance.

Internet installation: The Fedora installer asks for IP, gateway,
hostnames, etc., does the Internet configuration and sets up your
firewall as part of the standard installation.

Additional Hardware: generally speaking, this is plug 'n play: its
detected at boot time and used automatically. USB devices are detected
automatically when plugged in. Memory sticks and disks are auto-mounted
and icons put on your desktop. Ditto CDs and DVDs. Printer configuration
is no harder than for Windows.

Re-installing and clean installing an upgrade: Yes, in general, but
don't keep the whole of /etc because putting the lot back will upset an
upgrade. I just keep the files I've manually changed (hosts, SAMBA and
mail config, etc) and carefully put them back after comparison with the
freshly installed version. Modern installers tend to use just three
partitions (/boot, / and swap) but I think that's not a good approach,
just simple. I use more because:

- /home is separate and contains everything I've added (e.g. Java)
because this way I can reformat the other partitions, do a clean
install and not have lost any of my data. There are some post-install
tweaks needed but they're minor.

- /var is separate so that runaway logging, overflowing mailboxes or
gigantic print jobs can't fill all the available disk and interfere
with normal system operation.

- /usr is separate because I thought it seemed a good idea at the time.
In practise it just wastes space because its read-only data except
when its being upgraded.

Naming: Its best to always use fully qualified host names, e.g
"host.mydomain.com". If you have your own domain, use it. Otherwise,
make up something and use it within your home network behind your
firewall/router. Don't use unqualified host names, especially on a home
network, because this can confuse the DNS service.

Tips:

I use the bash shell. The following works for it. If you'd like the
current directory to be included in the shell's search path modify PATH
to include the current directory by putting this in .bash_profile:

export PATH=".:$PATH"

If you want to do this for all logins, put it in a small script in
/etc/profile.d - when you login bash runs the /etc/profile script, which
in turn runs all the scripts in /etc/profile.d

Use this mechanism for all your system-wide customizations and keep
copies of them safe so you can drop them back in place after a reinstall.

The control panel user maintenance tool DOES encrypt passwords. You
can't avoid encrypting them.

Add a comment about NEVER using root except for doing system
maintenance. Doing so is asking for trouble. Besides, its not necessary:
there's a useful tool called sudo that can be configured to let
nominated users run specific privileged commands, access protected
files, etc.

Distributions: Replace "Redhat Desktop" with "Redhat Fedora" (FCn, the
free distribution) and "Redhat Enterprise Linux" (RHEL, a paid-for,
supported distribution).

This is getting too long, so I'll stop now. If you want I can go further
into using symlinks and /home to protect locally installed packages,
which would usually be in /usr, from being blitzed by a clean install.
Take this offline if you prefer.

 

[Lew]

Name Size %used Comment

/boot 256 MB 9% contain kernel boot image(s)
/ 2 GB 16% root login, essential programs, temp disk, etc
/var 2 GB 14% system logs, NNTP files, mailboxes
/usr 15 GB 24% standard Linux programs
/home 15 GB 44% all logins and user data.
swap 1 GB - excessive (4 x RAM) ....
Modern installers tend to use just three
partitions (/boot, / and swap) but I think that's not a good approach,
just simple. I use more because:

- /home is separate and contains everything I've added (e.g. Java)
because this way I can reformat the other partitions, do a clean
install and not have lost any of my data. There are some post-install
tweaks needed but they're minor.

- /var is separate so that runaway logging, overflowing mailboxes or
gigantic print jobs can't fill all the available disk and interfere
with normal system operation.

- /usr is separate because I thought it seemed a good idea at the time.
In practise it just wastes space because its read-only data except
when its being upgraded.

I run Fedora 7, and have pretty much the same experience and a not dissimilar
setup to Martin's. I have /opt in its own partition, and install all my
servers, Java, RDBMS data directories, installation files and the like in
there. I provide symlinks to it, many with the alternatives mechanism, so
that things like /usr/java/java map to /opt/java/jdk$PREFERRED_VERSION, and
some /usr/bin/xxx programs symlink to an /opt/xxx/bin/xxx. /home/whomever is
symlinked to /opt/home/whomever for reasons identical to what Martin offered.

The point of that paragraph is that one can follow the principles with
variations in the details.

 

[Wayne]

I run Fedora 7, and have pretty much the same experience and a not
dissimilar setup to Martin's. I have /opt in its own partition, and
install all my servers, Java, RDBMS data directories, installation files
and the like in there. I provide symlinks to it, many with the
alternatives mechanism, so that things like /usr/java/java map to
/opt/java/jdk$PREFERRED_VERSION, and some /usr/bin/xxx programs symlink
to an /opt/xxx/bin/xxx. /home/whomever is symlinked to
/opt/home/whomever for reasons identical to what Martin offered.

The point of that paragraph is that one can follow the principles with
variations in the details.

I would add that it is now "Fedora" and not "Fedora Core".

<pet-peeve>
For networking, few people know the secret of Red Had networking. You
need to set a hostname, *not* a FQDN at install as Martin (and official
Red Hat documentation) suggest. You then edit /etc/hosts
to add a line for your static IP (Use 127.0.0.1 a second time if you use
DHCP) and add your FQDN here. Red Had uses this mechanism internally
to resolve hostnames and FQDNs.

If you follow the installation instructions and set a FQDN, you can not
get a hostname later; both hostname and hostname -f will return the same
value.

(Documented in the hostname(1) man pager under "FQDN", and in the
networking scripts in /etc/sysconfig. But nowhere else.)

There is a ton of useful network configuration features never documented,'
such as the /etc/default-routes file, or the use of ip-range config files.
(This stuff has been around since pre-Fedora Core 1, just never documented.)
</pet-peeve>

-Wayne

 

[Roedy Green]

For some reason the the page loads very slowly under Opera 9.24. Even on
redisplaying the page (clicking the browser's back arrow after following
a link off it) there's a several second delay while the title bar
flashes, switching between its 'current focus' and 'unselected'
appearances, before the page content appears. I haven't yet checked of
Firefox 2.0 also does this.

I don't see anything odd with Opera 9.24 or 9.5 beta under Vista.
There are some applets on that page. Perhaps what you are seeing is a
delay when Java gets first loaded. They require JDK 1.5+.

 

[Martin Gregorie]

You need to set a hostname, *not* a FQDN at install as Martin (and official
Red Hat documentation) suggest.
>

I take your point, but I haven't (yet) seen any downsides from it. Could
this have anything to do with me running a private DNS for my home
network and not using nfs or is just because I haven't yet used any
commands that could be affected?

What downsides have you found?

 

[Wayne]

I take your point, but I haven't (yet) seen any downsides from it. Could
this have anything to do with me running a private DNS for my home
network and not using nfs or is just because I haven't yet used any
commands that could be affected?

What downsides have you found?

Good question! But I don't remember the answer. I had the problem years ago and
went through the effort of reading all the networking scripts and code to
figure it out. I've been doing it this way since RH7.1, and maybe longer than
that. I've not had any problems so I don't bother to change this. But
off-the-cuff, I can't remember why you might want a host's non-FQDN hostname.

Frankly, it looks to me as if the RH engineer working on the networking code
left the project in the middle, around RH 7.2, and nobody's updated the code
or the old documentation since.

Perhaps we should continue this discussion on comp.os.linux.networking?

-Wayne

 

[Martin Gregorie]

Good question! But I don't remember the answer. I had the problem years ago and
went through the effort of reading all the networking scripts and code to
figure it out. I've been doing it this way since RH7.1, and maybe longer than
that. I've not had any problems so I don't bother to change this. But
off-the-cuff, I can't remember why you might want a host's non-FQDN hostname.

Frankly, it looks to me as if the RH engineer working on the networking code
left the project in the middle, around RH 7.2, and nobody's updated the code
or the old documentation since.

Perhaps we should continue this discussion on comp.os.linux.networking?

I have a partial answer as to why its not harmful:
hostname and hostname -f both output the FQDN
hostname -s strips the domain off leaving the host name
hostname -d strips the host name off leaving the domain

IOW no functionality is lost and you can make a reasonable argument that
this is good practice because it explicitly documents what you expect
to happen. The manpage is dated 1996, so this behavior is probably
universal by now: I just read the manpage and ran it the FC1 and FC7
versions.

Lets leave it there: I asked the question and got an honest answer: thanks.

I look at a diverse set of newsgroups, so I read uk.comp.os.linux rather
than any of the comp.os.linux.* groups in order to keep my newsgroup
bandwidth down.