Whys and Wherefores | Installation | Configuration | Log Files | Tweaks |
The final thing to sort out are the log files. We need to sort out what we want to do here and why. The issues here are:
If you are running a public server then you'll probably want log files to keep track of what people are up to. With a flash based system you'll probably want to write the log files to a RAM based file initially and then occasionally copy them to flash. You can either do this through the standard Tiny Core backup mechanism or write your own background process that occasionally copies them to disk.
With my test-and-then-upload scenario we have little interest in the log files unless we have problems. They are useful for debugging connection/configuration problems but after that we can either dump them or just record the minimum of information.
Finally, if you're running with limited RAM, you're probably also after a minimalist approach tho' this might conflict with the 'public server' requirement of adequate log files.
We'll look at what each application does in turn and you can decide how you wish to configure your set up.
On normal Linux systems there is an overall system log (syslog). Applications often write their logs to this logging sub-system. The interface is handled by a daemon (syslogd) that is started when the system boots. With Tiny Core the daemon is not started unless you specifically request it by including syslog as a command line parameter. If you want to use this - which is part of busybox the manual entry reads:
syslogd [OPTIONS]
System logging utility. Note that this version of syslogd ignores /etc/syslog.conf.
Options:
- -n Run in foreground
- -O FILE Log to given file (default:/var/log/messages)
- -l n Set local log level
- -S Smaller logging output
- -s SIZE Max size (KB) before rotate (default:200KB, 0=off)
- -b NUM Number of rotated logs to keep (default:1, max=99, 0=purge)
- -R HOST[:PORT] Log to IP or hostname on PORT (default PORT=514/UDP)
- -L Log locally and via network (default is network only if -R)
- -D Drop duplicates
- -C[size(KiB)] Log to shared mem buffer (read it using logread)
So you can see that, unless you specify otherwise, it will use 200KB of RAM to keep a single circular buffer in the file /var/log/messages.
The dropbear man page is a little short about logging. The only hint we get is a command line switch:
-E Log to standard error rather than syslog.
So by default dropbear will be sending stuff to syslog. If you're interested you'll need to run syslogd or use the -E switch and redirect stderr to a file.
By default logs are placed in samba_directory/var/smbd.log and samba_directory/var/nmbd.log where samba_directory is the location where Samba was installed. You can override this by specifying the log file location in the [global] section of the smb.conf file:
log file=/usr/local/samba/var/smbd.log # File size in Kb max log size=50
..and then restart Samba like this
sudo /usr/local/etc/init.d/samba restart
One thing I found before is that Samba will not create the log files if the specified path does not exist so you may need to edit /opt/bootlocal.sh to add a preliminary check before starting samba:
# Ensure log directory is present before # starting samba if [ ! -d /usr/local/samba/var ] ; then mkdir -p /usr/local/samba/var >/dev/null 2>&1 fi /usr/local/etc/init.d/samba start
If you're using samba it's worth doing this. Way back when I spent a frustrating hour or so trying to get samba running. It wouldn't run due to an error in the configuration file - but with no path-to-log-file present it wouldn't report the error and just failed silently!
Left to its own devices Apache writes its log files to /var/log but you have the option of changing that with an entry within the httpd.conf file. In Tiny Core the default directory is memory based and will vanish when the system is powered off unless you take steps to change it or backup the files when the system shuts down.
Whilst you can specify the level of logging you'd like and the format of data stored in the log files Apache does NOT provide any other management support. i.e. Left alone these files will just grow and grow and eventually your system will grind to a halt.
You can find many tools and scripts to manage this - the standard ones provide logfile rotation and compression.
A simple example: Here's a shell script that could be run on a regular (daily?/weekly?/monthly?) basis by cron:
#!/bin/sh cd /var/log # Rotate the logs rm error4.tgz mv error3.tgz error4.tgz mv error2.tgz error3.tgz mv error1.tgz error2.tgz mv error.tgz error1.tgz mv error_log error.old # Get apache to restart apachectl -k graceful # Wait a while to give it time. sleep 300 # Create new backup tar cvfz error.tgz error.old rm error.old
When I'm working on updating my website I occasionally run an HTML validator (Total Validator) on the area I'm working on and occasionally the full website. As the latter visits every page and follows every link one full run adds about 220KB to the access_log file. The net result is that if we do nothing about it the log files, primarily the access_log file, will get quite large.
In my case, using this as a development server, I have zero interest in the access log and I'm only interested in looking at the error log if I have any problems trying to access/view a web page I'm building. So a simple script that deletes the apache log files at 1am every day is a good solution to cater for the case where the server is left on for long periods of time.
We need the script to be persistent and so I decided I might as well create it in the /opt directory. I named it del_logs.sh.
#!/bin/sh # Script to remove Apache log files cd /var/log rm -f *access_log rm -f *error_log /usr/local/bin/apachectl -k graceful
Make sure the file is marked as executable:
tc@mirror:/opt$ chmod 755 del_logs.sh tc@mirror:/opt$
Next we need to create a cron job to run this script. Start by creating the crontabs directory and the editing the file within it. The command crontab will create the file if it doesn't exist - it' has the same name as the current user - and fires up the editor so that you can edit it:
tc@mirror:~$ mkdir -p /var/spool/cron/crontabs tc@mirror:~$ crontab -e
Within the editor add the line: 00 1 * * * /opt/del_logs.sh. With this, if the server is running at 1am, the logs will be deleted. If it isn't running at 1am then the files will have vanished when the system was switched off. Either way we've achieved our aim.
Finally ensure that the crontab file is persistent and that cron will start when the system is booted.
tc@mirror:~$ echo var/spool/cron/crontabs/root >>/opt/.filetool.lst tc@mirror:~$ echo /usr/sbin/crond >>/opt/bootlocal.sh tc@mirror:~$
Ensure your changes are saved.
tc@mirror:~$ filetool.sh -b