![[Courtfields]](../images/cflde2.jpg)
Be warned! This page is ancient, as evidenced by the absence of CSS and the embedded formatting tags, and if not plain wrong at least wildly inaccurate. And no - it is not likely to improve. Life is too short...
Until recently, I've been wary of using Red Hat distributions of Linux, as they headed toward being another Microsoft-style megalith stifling independence and driving the direction of future development for their own benefit. It has worried me ever since I became involved with Linux specifically to get away from corporate dominance of the market that mainstream suppliers always seemed to specify Red Hat as their only supported distribution of Linux. Recently, though, with the separation into Red Hat enterprise for stable business use, and Fedora for current development, tinkering and general larking around I've been tempted to try it. The problems over certain media patents and copyright issues means that RedHat/Fedora installation come without basic support for such things as MP3 and DVD but with additional repositories from such places as Livna [http://www.livna.org] it is possible to supplement the basic ubstallation.
Although my preferred distribution for getting your hands dirty and learning how things are put together is still Slackware, its file-system organisation is quite drastically different from either Red Hat or Fedora. Fedora is not guaranteed as stable as the Red Hat releases, but the organisation is much the same, which makes the experience and expertise is much more directly transferrable into the commercial market. As a consequence, although all my established servers are still Slackware based, I'm contemplating migrating the gateway/firewall to Red Hat, and have already spent most of my time in the last nine months sitting in front of a Fedora machine using X11 with KDE desktop.
Upgrades between different releases (I started way back with Fedora Core 2, and have now reached Fedora 8 on my desktops, with 9 now being current release) is not always plain sailing, but this is mitigated by the simplicity of maintaining the currency of packages within the release using an update management tool such as yum or apt. Some purists regard yum and apt as abominations and insist that package management should be performed manually, installing each package and its required dependencies by hand, arguing that otherwise one is at the mercy of the accuracy of the dependency listings within packages and potentially unscrupulous or repository mirror sites harbouring malicious packages, resulting in automatic installation of unnecessary packages which only provide dependent items which will not be used, or even security hazards. I have a fair degree of sympathy with this argument, but for simple ease a management utility is still worth serious consideration.
August 06, 2008
I put a live webcam page online in 2005.
At the time I bought a Logitech Quickcam Express I discovered, after buying it, that Logitech were refusing to co-operate with the Linux community by releasing the necessary specs to develop Linux support for it. That was a few years ago, and the protocol has been reverese- engineered and drivers developed by much better suited people than me.
I finally got around to plugging the thing in configuring it up, and hunting out suitable capture software. I plumped for motion from http://www.lavrsen.dk/twiki/bin/view/Motion/, threw together a shell script to copy new static images from the archive to the web cam page, and presto!
Once motion was compiled, installed, and operational, and the cam page updating successfully, I installed PHP, and started using that to provide dynamic content for the page (based on the time stamp of the image file).
January 11, 2006
When I got an Iomega Zip250 (parallel port variant), needless to say the
first thing I wanted to do was lump it onto one of the Linux boxen.
Forgetting my own rules 1..3 (1: Read the FAQ,
2: Read the FAQ again, 3: Read the FAQ properly this time) I ploughed
into this, and managed to sideline myself in trying to compile PPA into
the kernel (i.e. the driver for a ZIP 100), I then discovered
that in fact - as is very clearly stated in the
Zip
drive mini-HOWTO - what I really needed to install was the IMM
driver (which supports the parallel port versions of the Zip100-plus and
the Zip250).
For 2.0.x kernels, this comes in source form from
http://www.torque.net/~campbell/imm.tar.gz,
(or if you can't get it there, take this local copy,
which may or may not be up to date - no guarantees) which compiles into
an installable module. Pre-requisites are a full kernel source tree,
suitably configured to standing requirements but including as a minimum
loadable module support and SCSI disk support (but without any low-level
SCSI drivers, unless required for other devices).
In theory the Zip drive will allow in-line installation with a printer
(and under Windoze, ecch-ptooey!, it does).
Unfortunately Linux would not support this.
The kernel LP driver must also be compiled as a loadable module
if it is required.
Once installed (and modules loaded), the Zip disks may be mounted as DOS FAT (msdos), Windows '95 (vfat), or Linux native (ext2fs) file-systems. The disks come pre-formatted as VFAT disks (curiously allocated as partition 4), but can be fdisked and re-formatted to ext2fs using the mke2fs command (whilst the drive and modules are loaded, but the disk is unmounted), much the same as for a conventional hard disk. Linux will happily address any partition on the Zip (and indeed I put my ext2fs file-systems on partition 1), but I've never tried putting a VFAT partition 1 on the disk and seeing what effect that has under Windows (but then that wouldn't be relevent here anyway). For the sake of disk life, and general wear, the Zip disks should not generally be used as a working medium but as secondary storage, although as a temporary stop-gap I did have a machine booting from floppy and running a Zip disk as the root fs. Mainly, I use them for convenience, though. For instance, I keep the entire up-to-date HOWTO archive on Zip disk for quick and easy reference, as well as using Zip for backup purposes.
March 25, 2001
The Psion Series 5 EPOC-based PDA comes, in addition to the standard utility applications already installed (Word, Sheet, Data, Agenda, etc...), with PsiWIN and a bundled install for an e-mail client and web browser included in which is a simple IP stack and PPP layer. It's not immediately obvious, but in fact the PPP can be configured to run a direct connection (once the web/e-mail bundle is upgraded to version 1.50 or better - currently 1.52) without assuming the need to dial a modem.
I'll get around to writing a proper description sooner or later [very
MUCH later, given that it's now 5 years on and I haven't made any significant
additions to any of this in that time], but
for the moment, all I present here (as guidance to the already sufficiently
competent) are the contents of the appropriate peer file
(/etc/ppp/peers/psion5), with particular local network specific
details suitably obscured:
<server.ip>:<psion.ip>
allow-ip <local.net.address>/<local.net.mask>
local
debug
passive
proxyarp
ipcp-accept-remote
ms-dns <local.primary.dns>
ms-dns <local.secondary.dns>
noauth
The ppp command line in /etc/inittab which this peer file
is the accompaniment to is:
p1:12345:respawn:/usr/sbin/pppd /dev/ttyS1 38400 nodetach call psion5
Consult man pppd or other documentation to dissect this
command.
NB: The command above explicitly allows ANY ip claiming to be on
the local net without authentication. As yet I haven't persuaded PAP
authentication to work over the null modem link. Note also that by placing
the pppd command in /etc/inittab PPP is permanently running on
the serial port in question. All other processes normally respawned for
that serial port (ordinarily some form of getty process) must be disabled.
There is a package called PLPtools which substitutes for the Windoze support software supplied by Psion (imaginatively called PsiWin). PLPtools allows the Psion, by devious means, to be mounted directly on the Linux server as an NFS mount. The current release is version 0.6. Unfortunately, I can't for the life of me get it to compile, added to which there is the complication that it seems to be directly targetted at a Red Hat distribution, which confuses matters on my Slackware installed boxen. Up-to-date development information can be found on the Sourceforge project pages. [http://sourceforge.net/projects/plptools/]
More (much more) to come...
March 29, 2001
One thing that is notoriously tedious about PCs is the wide variation in quality and time-keeping within individual motherboard clocks. If you don't perform any time standardised functions, and operate on a stand-alone computer that's never going to have to agree with any other on the subject of time, then the HBT reference (Human Bodged Time) is probably entirely sufficient. At the other end of the scale you could spend practically unlimited amounts of money on installing a fancy clock. The common moderate solution to this for Internet capable machines (not just under Linux or *ix in general, but also under various other operating systems *Doze included) is to run a one-shot NTP client and synchronise periodically, or a permanent NTP service which will synchronise to time standards whenever the means is there. All fine and dandy, but only reliable as long as you are online often and long enough to ensure frequent synchronisation (which takes several minutes to stabilise with each source), or have a permanent line. With the advent of domestic and business broadband, this may be a sufficient answer, but there is still something to be said for having a direct, and independent means of time correction.
But what if you could have your own reference source, without spending fortunes? Well, thanks to Jonathan Buzzard you can. He announced on the newsgroup uk.comp.os.linux that he'd built the hardware, and the intermediate daemon to present a time signal from the MSF Radio clock in Rugby in the UK as a reference source to an NTP service running under Linux, and that he'd published the results at http://www.buzzard.me.uk/jonathan/radioclock.html. And I'm here to tell you it works. I built the circuit, with the addition of an LED so I have the satisfaction watching the timing pulses tick. I compiled Jonathan's clock daemon software, without a problem. Running the test the clock started ticking immediately, with a useful visible indication of operation coming from the added LED, which proved to be a boon to debugging later problems. At this point I hit a snag. Jonathan suggests in his own notes that as a default the shared memory reference driver is not compiled into most distributions' binary releases. And in my own self-compiled installation of XNTP 3-5.93e this was also true. Trying to configure and compile it to include reference clock drivers and specifically the SHM reference clock, resulted in a complete compile failure. Ultimately I gave up, cleaned out all the compiled elements already installed from that release, and downloaded the latest production release (NTP 4.1.1a) from the definitive source at >http://www.ntp.org/downloads.html. In private correspondence Jonathan suggested the compile configuration command:
CFLAGS=-O2 ./configure --prefix=/usr --enable-all-clocks \
--enable-parse-clocks --enable-SHM
and this did the trick. After that it was simply
make && make install
and presto, a working SHM reference clock capable NTP daemon.
Oddly the package doesn't seem to make the distinction between system
and user executables, and by default piles everything into /usr/bin
(or /usr/local/bin if you haven't specified an override to the
prefix as above).
Personally, I'm of the opinion that servers, and service tools should be in
.../sbin not .../bin, where they are only automatically available to the
system administrator.
I manually moved ntpd, ntptimeset, ntpdate, tickadj, ntptime and ntp-genkeys into
/usr/sbin.
Following the compile and install, it was simply a matter of adding
server 127.127.28.0
fudge 127.127.28.0 refid MSF
as the first server configuration in /etc/ntp.conf.
Strictly speaking, the second line is not necessary, but overrides
the rather boring default reference ID for the SHM clock (which is,
oddly enough, ".SHM.").
For initial purposes it's good enough to just start the NTP daemon
from a root shell (either through root login or by sudo).
It then pays to ensure that the NTP daemon is started up at boot time,
which for a Slackware system means ensuring it is in
/etc/rc.d/rc.inet2.
I recommend putting it immediately after the start of syslogd with the
lines
# Start ntpd NTP server
if [ -f /etc/ntp.conf ]; then
if [ -x /usr/sbin/ntpd ]; then
echo -n " ntpd"
/usr/sbin/xntpd
fi
fi
which will ensure that you have a config file and that the daemon is
executable before trying to start it.
For the first couple of days free running, the daemon would prefer
synchronising to online reference sources rather than the MSF clock,
which as Jonathan suggested to me can be overcome by adding the
"prefer" keyword to the end of the server line in
/etc/ntp.conf. However it now seems to have settled down
of its own accord.
December 12, 2003
One of the little things I have always liked about unix, is pretty trivial: fortune cookies. I have birthday and new year scripts which e-mail people with appropriate greetings at the right time. (Ok, so it's not as good as remembering for myself, but hey - I'm a techie. Let the machines carry the load...) Over the years I have been slowly building up a library of my own fortune files. Not wishing to step on anyone's toes, and hoping that I'm not infringing copyrights, I now present some of them here, for others to download and use. Most are still in a state of flux. The movie quotes in particular are by their very nature a permanently ongoing endeavour and despite weighing in at almost three megabytes of hand transcribed lines still only realise a tiny fraction of the potential. As a matter of courtesy I ask that anyone taking these files does not add to them or pass them off as their own work.
The files here are (bzip2) compressed tar files
containing the cookie
text files, and their indexes required by fortune.
Where you need to place them to use them selectively depends on which
implementation of fortune you are using.
Consult your documentation.
March 4, 2020
This page and all subordinate pages and the information and information content authored by, and Copyright © 1997..2016 of Gulraj Rijhwani and Courtfields unless otherwise specified.
For further information contact:
Regrettably, e-mail purporting to be from sites giving away free (or free trial) accounts (such as Hotmail, Bigfoot or AOL) will be automatically refused delivery. On balance e-mail from such sites received here is over-whelmingly junkmail.