Updated hints

Rob Park rbpark at ualberta.ca
Tue Dec 24 00:44:09 PST 2002


Ok, I'm now maintaining my hints again, after a long break for school ;)

-- 
Rob Park
http://www.ualberta.ca/~rbpark
--
Dreams are free, but there's a small charge for alterations.
-------------- next part --------------
TITLE:		Fcron Scheduling Daemon
LFS VERSION:	3.3 (or older versions, with minor changes)
AUTHOR:		Lyle Vogtmann <vogtmann at pioneernet.net>
MAINTAINER:		Robert Park <rbpark at ualberta.ca>

SYNOPSIS:
	How to set up the fcron scheduling daemon on an LFS system.

HINT:

Changelog
---------

Revision 1.7  2002/12/24 08:30:05  feztaa
Updated to fcron 2.9.3.

Revision 1.6  2002/09/15 05:38:52  feztaa
Changed email address, among other misc fixes.

Revision 1.5  2002/06/09 04:14:05  feztaa
Added some notes, changed style of code blocks, and fixed a couple typos.

Revision 1.4  2002/05/02 00:05:36  feztaa
Fixed a problem with the cronmail script improperly delivering mail,
clarified some abiguities, and reduced some redundancy in the fcrontabs.

Revision 1.3  2002/04/27 19:28:08  feztaa
Fixed various typos and other grammatical errors (oops ;)

Revision 1.2  2002/04/27 19:17:48  feztaa
I've taken over maintenance of this hint from Lyle.
Added 'cronmail' script, updated bootscripts to LFS 3.3,
and reformatted the layout of the hint.

Intro
-----

I wrote this to help others set up and use the Vixie Cron replacement known as
fcron. Cron is a very useful and nearly ever-present system daemon on
Unix-like systems.  It is started at boot time and runs in the background,
starting sheduled tasks specified in a "crontab". There are several versions of
cron available, each with it's own additions and features. Fcron has a mixture
of some of the best features.

Fcron can function as a standard cron, running tasks at a certain time on a
certain day. It can also function like anacron, running tasks after a certain
amount of time at an unspecific time (if you don't leave your computer on all
the time, this is a godsend). It can also run tasks after a certain amount of
uptime, too.

For more information, check out the fcron home page at http://fcron.free.fr.

Notes
-----

In an attempt to make this easier to read, all "code blocks" that you should
execute on the commandline start and end with "##--CODE--##". Feel free to copy
that onto the commandline along with the code itself, it won't hurt anything.
Also, for quoted text (the output of a program, for example), each line is
prefixed with four spaces.

Requirements
------------

If you want to see the output of the commands that Fcron runs, you will want to
have a working mail system installed. If you are not interested in installing a
mail system on your box, I have written a "cronmail" script that you can use to
let fcron deliver mail to you without a full MTA on the system. You will need
to install the procmail package, though, because my cronmail script uses
formail (which comes with procmail).

This hint does not cover setting up a local mail service, but I'll show you how
to install cronmail. If you want to set up a local mail service, check out the
LDP at http://www.linuxdoc.org. I reccommend Postfix, http://www.postfix.org.

Instructions
------------

1. Get fcron sources from http://fcron.free.fr and unpack them. I use fcron
2.9.3, but this hint should work for other versions as well.

2. Add the "fcron" user and group to your system:

##--CODE--##
groupadd -g 13 fcron
useradd -u 13 -g fcron -d /dev/null -s /bin/false fcron
##--CODE--##

This creates the group fcron with GID 13 and the user fcron with UID 13. It
also prevents anybody from logging into this account, because the home
directory is /dev/null and and the shell is /bin/false.

3. Run configure:

##--CODE--##
./configure --prefix=/usr --with-spooldir=/var/lib/fcron
##--CODE--##

This tells fcron to put it's fcrontab files into /var/lib/fcron.  I personally
use /var/fcron, but if you want to be FHS-compliant, you have to use
/var/lib/fcron.

4. You might want to have a glance at config.h to make any changes to the build
process, but in my experience this is unneccessary. If you do edit this file,
be sure to check the locations of key files like fcron.allow, fcron.deny, etc.
You can also configure what Fcron calls itself when it mails you, if you like.

5. Compile:

##--CODE--##
make && su -c "make install"
##--CODE--##

This will compile the sources, then install them as root. When it asks you to
install the init script, don't. We are going to make our own, better init
script later on.

7. If you are upgrading, be sure to run this command for each user on your
system that had an fcrontab during installation:

##--CODE--##
fcrontab -u <user> -z
##--CODE--##

This simply updates the fcrontab, in case the format has changed.

8. Now we will create the bootscripts. Run this as root:

##--CODE--##
cat >/etc/rc.d/init.d/fcron <<"EOF"
#!/bin/bash
# Begin $rc_base/init.d/fcron

source /etc/sysconfig/rc
source $rc_functions

case "$1" in
  start)
    echo "Starting fcron..."
    loadproc /usr/sbin/fcron
    ;;

  stop)
    echo "Stopping fcron..."
    killproc fcron
    ;;

  restart)
    $0 stop
    sleep 1
    $0 start
    ;;

  status)
    statusproc fcron
    ;;

  *)
    echo "Usage: $0 {start|stop|restart|status}"
    exit 1
    ;;
esac

# End $rc_base/init.d/fcron
EOF
chmod 755 /etc/rc.d/init.d/fcron
##--CODE--##

You will also need to make the symlinks in the appropriate directories. I did
mine like this, but you might want to do it differently:

##--CODE--##
cd /etc/rc.d/rc0.d &&
ln -s ../init.d/fcron K35fcron &&
cd /etc/rc.d/rc6.d &&
ln -s ../init.d/fcron K35fcron &&
cd /etc/rc.d/rc3.d &&
ln -s ../init.d/fcron S60fcron
##--CODE--##

9. You need to give it some tasks to do (it wouldn't be very useful
otherwise! ;). Read the man page for fcrontab:

##--CODE--##
man 5 fcrontab
##--CODE--##

If you need some examples to get started, this is what I have in root's
fcrontab: (this is the output of 'fcrontab -l')

    !mailto(feztaa),mail(yes),forcemail(yes),noticenotrun(yes)
    %daily * 9-15 updatedb --prunepaths="/mnt /proc /dev"
    %daily * 9-15 logreport

This fcrontab is fairly straightforward. First, we set some options: send mail
to feztaa (me), always send mail no matter what, and let me know if the command
was not run. Then, we run updatedb every day between 9 AM and 3 PM. Finally, we
run logreport at the same time that updatedb is run (logreport is just a quick
bash script I wrote to scan my logs and notify me of root logins).

In my own fcrontab, I have the following:

    !mailto(feztaa),mail(yes),forcemail(yes),noticenotrun(yes)
    %monthly * * 1-4 oldmail

This sets the same options as root's fcrontab, and then it runs oldmail as soon
as it can, some time during the first four days of every month (oldmail is
another simple script I wrote that simply archives and compresses my old mail).

What I've written here is by far no substitute for reading the man page; I've
barely scratched the surface in this hint. If you want to get the most out of
your fcron, do yourself a favour and read the man page.

To install your fcrontab, run:

##--CODE--##
fcrontab -u <user> -e
##--CODE--##

The -u option can be omitted if the fcrontab you want to edit belongs to the
same user who runs the command. The default editor (defined in /etc/fcron.conf)
should start with a blank screen. Type in your entries in accordance with the
fcrontab(5) man page.

When you're done, save and quit editing the file (:wq in vim). Fcrontab then
checks your work for errors, and it complains if it finds some. It will also
refuse to use the malformed fcrontab. If you get an error, try again, and read
the man page to see what you're doing wrong. When you get it right, fcrontab
passes the file to fcron and saves it in /var/lib/fcron/<username>. DO NOT EDIT
THIS FILE! Always use fcrontab to edit your fcrontab, it is much safer that
way.

10. Now, to control who has access to fcron, you edit /etc/fcron.allow and
fcron.deny. I think that only root and a select few priveleged users should be
able to use such a daemon, so I put "all" in fcron.deny and "root" and "feztaa"
in fron.allow.

11. We will now install the cronmail script that I talked about in the
introduction. If you do not want this script, you are now done! If you do want
it, read on...

First, run this as root:

##--CODE--##
cat >/usr/bin/cronmail <<"EOF"
#!/bin/bash
# Version: 1.4
# Author: Rob Park <feztaa at shaw.ca>
# License: GNU General Public License

########################################################################
# You probably want to edit the following two variable definitions to  #
#            better match your system! You have been warned!!          #
########################################################################

# What is the default name to use if none is specified, or if root is
# specified? Basically, who gets root's mail?
default="feztaa"

# Where should the mail be delivered to? This is an mbox somewhere
# inside the user's home directory (sorry, only mbox format is supported
# as of now).
mbox="mail/cron"

###########################################################
# You shouldn't need to edit anything below this line! ;) #
###########################################################

# Throw away all the arguments until we find one that's a valid username
until id "$1" >/dev/null 2>&1
do
  shift
done

# The username is now the first argument
name="$1"

# If the first argument is missing, or "root", deliver it to the default
# user instead.
[ "$name" == "" ] && name=$default
[ "$name" == "root" ] && name=$default

# Pipe stdin to the mbox in the user's home folder, adding a few headers
# to make it look more like real mail.
formail -a "Message-ID:" -I "From: Cron <fcron at localhost>" -I "To: $name <$name at localhost>" >> /home/$name/$mbox
EOF
chmod 755 /usr/bin/cronmail
##--CODE--##

This script is a very simple sendmail replacement. It looks for a username in
the argument list, stamps some email headers onto the message with formail, and
then sends it off to an mbox in the user's home directory.  You can edit where
exactly you want it to be delivered, and who you want to get root's mail. Since
I get all my mail in ~/mail, I have the script deliver my mail to ~/mail/cron.

The next thing we need to do is tell fcron to use our cronmail script.  Run
this command to make the change:

##--CODE--##
cd /etc &&
perl -i -pe 's%^sendmail\s*=.*$%sendmail=/usr/bin/cronmail%' fcron.conf
##--CODE--##

Now restart fcron (if it is running), and you're all ready to go!

The End
-------

You're done! Now you have a scheduling utility that will run commands
automatically for you.

If you have any questions, suggestions, or problems, PLEASE email me and I will
help you to the best of my ability (note, don't email Lyle, he doesn't maintain
this anymore. Just email me, Rob).
-------------- next part --------------
TITLE:		Using Linux Logo to Spruce Up Your Login Prompt
LFS VERSION:	3.3 (should work with earlier versions without much hassle)
AUTHOR:		Robert Park <rbpark at ualberta.ca>

SYNOPSIS:
	How to get an attractive login prompt using the Linux Logo utility.

HINT:

Changelog
---------

Revision 1.7  2002/12/24 08:02:23  feztaa
Updated to version 4.06

Revision 1.6  2002/09/15 05:40:33  feztaa
Changed email address, among other misc fixes.

Revision 1.5  2002/06/09 03:56:36  feztaa
Added some initial notes, and changed the style of the code blocks so they'd
(hopefully) be easier to read.

Revision 1.4  2002/05/05 04:30:07  feztaa
Removed references to the logo I created, in favor of a better logo
that comes with linux_logo

Revision 1.3  2002/05/05 03:17:36  feztaa
Misc changes to improve readability.

Revision 1.2  2002/04/27 20:26:52  feztaa
Updated to LFS 3.3, LinuxLogo 4.02.

Intro
-----

If you've used mandrake, and seen it boot into runlevel 3, you've probably
noticed the cute ANSI/ASCII-art Tux that precedes the login prompt. This hint
will tell you how to create the same effect on your LFS system.

Notes
-----

In an attempt to make this easier to read, all "code blocks" that you should
execute on the commandline start and end with "##--CODE--##". Feel free to copy
that onto the commandline along with the code itself, it won't hurt anything.

Requirements
------------

All you need is the source code to linux logo, which can be found here:

http://www.deater.net/weave/vmwprod/linux_logo

I used version 4.06 to write this hint, but other versions will work as well.

This hint uses SysVInit bootscripts, though it's not hard at all to implement
this with BSD-style bootscripts.

Instructions
------------

1. Unpack linux_logo, and compile it like this:

##--CODE--##
make logos-all &&
make install
##--CODE--##

2. I advise you to read the README and configure linuxlogo to the way you want
it to display the logo when you are logging in. I configured mine like this:

##--CODE--##
echo -n '-L 13 -F "\n\nFeztux GNU/#O #V on #H.\nCompiled #C.' > /etc/linux_logo.conf
echo '\n#N #M #X #T #P.\n#R RAM, #B Bogomips Total. \n#E"' >> /etc/linux_logo.conf
##--CODE--##

Explanation: we are creating the config file for the program, which really is
just a file that contains commandline options for it.

The -L option tells it to use the 13th logo, which is the one I happen to like
the most, but keep in mind that you might be compiling with a different set of
logos, so your numbers may vary. (try "linux_logo -L list" to see a list of
available logos, and then pick the one you want).

The -F option configures how the system information is formatted (read the
readme on how to set this option).

If you want to have linux_logo clear the screen before printing the logo, and
thus hiding the output of your bootscripts after everything finishes loading,
add the -f option to this file. This also has the added benefit of clearing the
screen whenever you log out; so if other people use your computer, they won't
be able to see what you were doing before you logged out.

3. Now we'll make the bootscript for it:

##--CODE--##
cat > /etc/rc.d/init.d/issue << "EOF"
#!/bin/bash
# Begin $rc_base/init.d/issue

source /etc/sysconfig/rc
source $rc_functions

case "$1" in
	start|stop)
		echo "Setting /etc/issue..."
		linux_logo -t "Console: \l" >/etc/issue 2>&1
    evaluate_retval
		;;

	*)
		echo "Usage: $0 {start|stop}"
		exit 1
		;;
esac

# End $rc_base/init.d/issue
EOF
chmod 755 /etc/rc.d/init.d/issue
##--CODE--##

The -t option here simply specifies some custom text that we want to display in
the issue file, but that we wouldn't want to display when linux_logo is run
normally (which is why we don't put it in the config file). When you boot,
certain codes in the /etc/issue file are interpreted and replaced with some
information.  In this case, the '\l' is being replaced with your current tty.

5. Finally, make the symlinks to the script. You can run the script while your
computer boots and shuts down if you wish, but it really only makes sense to
run it while the computer is booting. So, only make the symlink in /etc/rc3.d,
assuming you boot to runlevel 3:

##--CODE--##
cd /etc/rc.d/rc3.d &&
ln -s ../init.d/issue S35issue
##--CODE--##

The End
-------

You're done! Reboot your computer and enjoy the new logo. ;)

If you have any questions, do not hesitate to ask!
-------------- next part --------------
TITLE:		Using Installwatch as a Package Manager
LFS VERSION:	Any
AUTHOR:		Robert Park <rbpark at ualberta.ca>

SYNOPSIS: 
	Use installwatch to keep track of what files got installed when you compiled
	something from source. Includes an easy method for removing those files,
	packaging those files up, and installing said packages.

HINT:

Changelog
---------

Revision 1.13  2002/09/15 05:39:34  feztaa
Changed email address, among other fixes.

Revision 1.12  2002/08/08 02:23:05  feztaa
Nuke script updated to version 1.13; major rewrite to enhance readability
and to reflect new features.

Revision 1.11  2002/07/31 07:14:50  feztaa
Updated nuke script to version 1.12

Revision 1.10  2002/07/27 01:06:27  feztaa
Updated nuke script to version 1.11

Revision 1.9  2002/06/15 18:03:12  feztaa
Updated nuke script to version 1.9

Intro
-----

One big problem with LFS is that there is no package management system.  This
means that it is a *HUGE* pain in the butt to uninstall something, since there
is no record of what got installed where, and by what program.

There are lots of other ways to implement "package management" in LFS; but this
is the one that I use ;)

Notes
-----

In an attempt to make this easier to read, all "code blocks" that you should
execute on the commandline start and end with "##--CODE--##". Quoted text,
such as the output of a program, is prefixed with four spaces.

Also, if you're trying to use this during the early stages of Chapter 6 in the
LFS book, it will fail miserably for you. The reason is that installwatch needs
programs to be dynamically linked for it to work; in Chapter 6, all of your
programs are statically linked. Installwatch *might* work for you near the end
of chapter 6 when most of the static stuff is gone, but I advise not using it
until chapter 6 is finished and you're installing other stuff. I've yet to find
a program that wouldn't install properly with installwatch, just as long as
your stuff is dynamically linked.

Requirements
------------

You'll need to download installwatch, which you can get from one of these
locations:

http://asic-linux.com.mx/~izto/checkinstall/installwatch.html
http://proyectos.glo.org.mx/checkinstall/installwatch.html

If both these sites are down, try this one (but only as a last resort):

http://www.google.ca/search?hl=en&q=installwatch+izto+0.6.3&meta=

I used version 0.6.3 to write this hint, but other versions should work as well
(just as long as their logfiles are in the same format).

You'll also need my 'nuke' script, which is used for uninstalling software,
among other things. You can get that here:

http://members.shaw.ca/feztaa/projects/nuke

You'll need to download that into /usr/sbin, and chmod it to 750 (rwxr-x---).
Yep, it finally grew too large to be included within this hint itself ;)

Instructions
------------

1. Install Installwatch.

Unpack and compile installwatch. Compilation is done like so:

##--CODE--##
make &&
make install
##--CODE--##

2. Fix Make.

Make must be owned by the root group:

##--CODE--##
chgrp root /usr/bin/make
##--CODE--##

I've also heard that installwatch will not work if make is setgid. I'm not sure
if this is true, but you might want to make sure it isn't:

##--CODE--##
chmod -s /usr/bin/make
##--CODE--##

3. Prepare the Filesystem.

To use the nuke script, you'll need the /var/install, /var/uninstall, and
/var/packages directories, which will be explained later. Create them like this
(as root):

##--CODE--##
mkdir /var/{install,uninstall,packages}
chmod 750 /var/{install,uninstall,packages}
##--CODE--##

The install directory will be where we put installwatch's logfiles, and the
uninstall directory will be where we put the log of what we deleted with the
"nuke" script that I am going to show you next. The packages directory is where
we'll store the packages that we can create from installed software.

4. Using Installwatch.

Now I'm going to show you how to use installwatch to create the logfiles that
will be used by the nuke script.

When you are reading installation instructions for something, and you see "make
install", you'll want to replace that with this:

##--CODE--##
installwatch -o /var/install/programname-version make install
##--CODE--##

But, if you're too lazy and don't want to remember all that, create an alias
similar to this one:

##--CODE--##
alias iw='installwatch -o /var/install/$(basename $(pwd))'
##--CODE--##

This will take the name of the current directory, and use that as the logfile
name to use in /var/install. The idea is that the name of the directory you are
compiling source in is descriptive of the software you are compiling. For
example, I compiled XMMS in /usr/src/xmms-1.2.7, and this alias created the
logfile named "/var/install/xmms-1.2.7". You'll want to put this alias into
your bashrc, so that you won't have to recreate the alias every time you start
a new shell.

If you're going to use this alias as-is, then wherever you see "make install"
in the installation instructions for something, you'll have to prefix it with
"iw". For example, instead of the standard "./configure && make && make
install", you'd type this:

##--CODE--##
./configure && make && iw make install
##--CODE--##

5. Using Nuke.

The nuke script has many uses, the first and foremost of which is to
uninstall software by analyzing installwatch logfiles.

Uninstalling software is extremely easy with the nuke script, you simply give
it a logfile from /var/install, and it will remove the software from your
system, and then create a logfile in /var/uninstall telling you how the
uninstall went.

Lets say for example, you wanted to uninstall a program called 'foobar 1.0'.
Since we have the foobar-1.0 logfile, we can simply do this:

##--CODE--##
nuke foobar-1.0
##--CODE--##

And nuke will produce some output like this:

    Processing foobar-1.0 ... done.
    Uninstalling foobar-1.0 ... successful.

The first line simply means it was processing the logfile to determine what
files to delete, and the second line means that it deleted them.

It also keeps a logfile of what got deleted. This is in /var/uninstall, and has
the same name as the logfile in /var/install. This new logfile will look
something like this:

    Removed Files/Directories
    -------------------------
    
    /usr/share/man/man1/foobar.1
    /usr/bin/foobar

This file is in the format of one filename per line, and if there were any
errors removing files, the filename will be followed by " -- " and the error
message. So you might see something like this:

    Removed Files/Directories
    -------------------------
    
    /usr/share/foobar/foo -- Permission denied
    /usr/share/foobar -- Directory not empty

Which means that neither were removed.

Once you are satisfied that the program was uninstalled properly, you can
remove the logfile from /var/uninstall. The nuke script will automatically
remove the logfile from /var/install if all of the files were removed properly.

6. Nuke's 'Report' Mode.

As I mentioned before, nuke has many uses. I already showed you how to use
it to uninstall software, now I'm going to show you how to use it to simply
see what files got installed with each program.

All you have to do is add "--report" (or "-r") to nuke's argument list, like
so:

##--CODE--##
nuke --report foobar-1.0
##--CODE--##

Now nuke won't remove the program. Instead, it will produce output like this:

    Processing foobar-1.0 ... done.
    Files/Directories installed by foobar-1.0
    -----------------------------------------
    
    /usr/share/man/man1/foobar.1:  open, chown, and chmod
    /usr/bin/foobar:  open, chown, and chmod

And this simply means that both of the listed files were created (open),
chown'ed, and chmod'ed.

7. Nuke's 'Package' Mode.

Nuke now has an experimental method of producing packages from logfiles.  These
packages are not intended for general distribution (and aren't meant as a
replacement for RPMs or anything fancy like that). They don't store any
dependancy information, and in fact they are just tarballs.

The primary use of these tarballs would be for easily installing a program onto
many identical systems (compile once, install everywhere), or as backups for
users with lots of HD space, but little processing power (for them, it's easier
to install the package than to recompile it).

Anyway, to make a package, first you must have installed something with
installwatch, and you must have the installwatch logfile (in /var/install).
Then you just call nuke with the "--package" (or "-p") option, and it creates
the package for you, like this:

##--CODE--##
nuke --package foobar-1.0
##--CODE--##

This will produce output similar to the following:

    Processing foobar-1.0 ... done.
    Packing files from foobar-1.0 into /var/packages/foobar-1.0.fez.pkg ... 
    /usr/bin/foobar
    /usr/share/man/man1/foobar.1
    /var/install/foobar-1.0

The .fez.pkg file itself is just a .tar.bz2 file in reality, but there are
special options that you have to pass to tar for it to unpack properly,
and instead of trying to force you to remember them, I just let the nuke
script handle that as well.

8. Nuke's 'Install' Mode.

The other part of the experimental packaging support in the nuke script
is it's ability to install the packages that it creates. All you have to
do is put the .fez.pkg file into /var/packages (it's placed there by default),
and then run nuke with the "--install" (or "-i") option, like this:

##--CODE--##
nuke --install foobar-1.0.fez.pkg
##--CODE--##

This will produce output similar to this:

    Unpacking files from /var/packages/foobar-1.0.fez.pkg ... 
    /usr/bin/foobar
    /usr/share/man/man1/foobar.1
    /var/install/foobar-1.0

Which just tells us which files it unpacked, and to where.

The End
-------

Congratulations! You now have an extremely easy method of removing software,
packaging software, and installing packages for software that was compiled from
source!

If you encounter any problems, please let me know. I want to make this as good
as it can possibly be ;)

Thanks To
---------

'Lovechild' (from the linuxjunior.org forums), for the original idea,
Zenith Lau <zenithlau at sniic.com>, for symlink fixes in the nuke script,
and everybody who reported problems that they found.


More information about the hints mailing list