|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
A system log is a recording of certain events. The kind of events found in a system log is determined by the nature of the particular log and any configurations used to control those events that are logged. System logs are usually text files containing a timestamp and other information specific to the message or subsystem.
|
|
One issue with log files is the difference between how Windows and UNIX each maintain open files. In UNIX, although it is not possible to remove a file that is currently open, it is possible to rename that file. In Windows, it is necessary to manipulate the access control list (ACL) of the file before renaming the file; a simple rename fails.
Both Windows and UNIX do share the behavior, if the file is open, and it is renamed, the process continues to write to that renamed file. In order for a process that keeps a file open to write to the original name, it must be restarted. Upon restart, the process creates a new file with the original name.
This is in contrast with processes, which open a file, write to it, and then close it. If the file was open at the time of the rename, the process continues to finish the write operation before closing the file descriptor. When the process is ready to write again, it writes to the original name, thus creating a new file.
Logs are rotated using logadm -- a special utility introduced in Solaris 9.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
I vote for /var/log/cron.19990220, /var/log/ftp.19990220, /var/log/authlog.199902, etc. Do you have so many logs online that they need more than one flat directory? Then go one more level down, but not 4. Also, putting the timestamp in the filename makes restores and greps of the files less confusing.
But I think the problem is even bigger than that.
Some log files grow VERY RAPIDLY -- many megabytes per day. Some grow very slowly. authlog comes to mind. It's best to keep individual log files under some certain size. 1MB is great. 10MB is OK. 50MB is getting kinda big.
But with these different growth rates, the tendency is to age some of them daily, others weekly, others yearly(!).
Then there's the annoying ones like wtmp that are binary.
And let's not forget that some processes need to be restarted after a logfile move, while others don't.
And some programs follow the paradigm "my logfile must exist and be writable by me or else I will silently log nothing".
I've always considered writing some tool that would allow you to manage and age all your log files from one config file. Maybe the config file would be a table that lists the base logfile name, the interval at which it gets aged, the number of logs or amount of space to keep online before deleting them, etc.
Anybody know of any such program? It might be too much work for too little gain.
The ultimate would be an ADAPTIVE process that keeps fewer old logs online if space is getting tight, etc. Personally I think an adaptive news expire program would be nice, too.
I'll get right on these, as soon as I get this other stuff done for my boss... :-)
Todd Williams Manager, Computer and Communication Systems
MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041
[email protected] (323)259-4973 http://www.macsch.com/
geek n. : a carnival performer often billed as a wild man whose act usu.
includes biting the head off a live chicken or snake -Webster's New Collegiate
|
|
|
Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.
Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.
|
|
|
Log Files
Log file are used by the system and applications to record actions, errors, warnings, and problems. They are often quite useful for investigating system quirks, for discovering the root causes of tricky problems, and for watching attackers. There are typically two types of log files in the Solaris Operating Environment: system log files which are typically managed by the syslog daemon and application logs which are created by the application.
set sys:coredumpsize = 0
Log Files Managed by syslog
The syslog daemon receives log messages from several sources and directs them to the appropriate location based on the configured facility and priority. There is a programmer interface, syslog(), and a system command, logger, for creating log messages. The facility (or application type) and the priority are configured in the /etc/syslog.conf file to direct the log messages. The directed location can be a log file, a network host, specific users, or all users logged into the system. By default, the Solaris Operating Environment defines two log files in the /etc/syslog.conf file. The /var/adm/messages log files contains a majority of the system messages. The /var/log/syslog file contains mail system messages. A third log file is defined but commented out by default. It logs important authentication log messages to the /var/log/authlog file. Uncomment the following line in /etc/syslog.conf to enable logging these messages: Save the file and use the following command to force syslogd to re-read its configuration file:
All of these files should be examined regularly for errors, warnings, and signs of an attack. This task can be automated by using log analysis tools or a simple grep command.
Application Log Files
Application log files are created and maintained by commands and tools without using the syslog system. The Solaris Operating Environment includes several commands that maintain their own log files. Here is a list of some of the Solaris Operating Environment log files:
/var/adm/sulog messages from /usr/bin/su
/var/adm/vold.log messages from /usr/sbin/vold
/var/adm/wtmpx user information from /usr/bin/login
/var/cron/log messages from /usr/sbin/cron
The /var/adm/wtmpx file should be viewed with the last command.
#auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)
# kill -HUP `cat /etc/syslog.pid`
The /var/adm/loginlog file does not exist in the default of the Solaris Operating Environment installation, but it should be created. If this file exists, the login program records failed login attempts. All of these logs should also be monitored for problems.
Google matched content |
CERT/Understanding system log files on a Solaris
Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.
All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.
Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.
Man Pages
last(1)
loginlog(4)
login(1)
logger(1)
sulog(4)
sysidtool(1M)
syslog(3)
syslogd(1)
syslog.conf(4)
sys-unconfig(1M)
vold(1M)
This file is a catch-all log file for a number of messages from the UNIX kernel as well as for other logging applications such as syslogd. The file is formatted as an ASCII text file and entries are usually one record per line with new entries appended to the end of the file.
The following is a sample excerpt from a messages file. Each pair of lines shown below appears as one line in the file:
Oct 31 04:05:01 unix.fghij.net syslogd:restart Oct 31 04:05:02 unix.fghij.net named[112]: unapproved query from [10.10.0.1].32768 for "loghost.local.net" Oct 31 04:05:02 unix.fghij.net named[112]: unapproved query from [10.10.0.1].32768 for "loghost.local.net" Oct 31 04:05:42 unix.fghij.net printd[207]: send_job failed job 203 ([email protected])check status Oct 31 04:06:00 unix.fghij.net sendmail[14602]: EAA14602: from=ih_cron, size=456, class=0, pri=30456, ... Oct 31 04:06:01 unix.fghij.net sendmail[14604]: EAA14602: to=ih_cron, delay=00:00:01, xdelay=00:00:00, ... Oct 31 04:06:42 unix.fghij.net printd[207]: send_job failed job 203 ([email protected]) check status Oct 31 04:07:42 unix.fghij.net printd[207]: send_job failed job 203 ([email protected])check status
Note that the messages file can get very large quickly and should be rotated regularly to ensure that it does not consume too much local disk space. Refer to "Using newsyslog to rotate files containing logging messages on systems running Solaris " for more information.
The sulog file, /var/adm/sulog, is a log containing all attempts (whether successful or not) of the su command. An entry is added to the sulog file every time the su command is executed. The fields in sulog are: date, time, successful (+) or unsuccessful (-), port, user executing the su command, and user being switched to. In the preceding example, all su attempts were successful, except for the attempt on 2/23 at 20:51, when user pete unsuccessfully attempted to su to user root.
Look for entries where an unauthorized user has used the command inappropriately. The following entry shows a successful (indicated by +) su from user userid to root.
SU 03/31 12:52 + pts/0 <userid>-root
Look for failed su attempts.
SU 03/31 12:52 - pts/0 <userid>-root
Look for su occurring at unusual times during the day (e.g., after hours, very early in the morning).
SU 03/31 02:12 + pts/0 <userid>-root
SU 11/04 09:43 + ??? root-uucp
SU 11/06 10:24 + pts/5 mcevoyg-root
SU 11/06 10:44 + pts/6 mcevoyg-root
SU 11/06 11:30 + pts/2 mcevoyg-root
SU 11/07 14:07 + pts/2 mcevoyg-root
SU 11/07 14:24 + pts/5 mcevoyg-root
SU 11/07 14:43 + pts/2 mcevoyg-root
SU 11/07 14:46 + pts/1 mcevoyg-root
SU 11/12 10:41 + pts/1 mcevoyg-root
SU 11/12 15:59 + pts/2 mcevoyg-root
SU 11/12 16:24 + pts/2 mcevoyg-root
SU 11/13 09:20 + pts/2 mcevoyg-root
SU 11/17 10:37 + pts/2 mcevoyg-root
SU 11/17 14:54 + pts/2 mcevoyg-root
SU 11/17 16:26 + pts/3 hilgarj-root
SU 11/17 22:22 + pts/3 hilgarj-root
SU 11/18 09:13 - pts/2 mcevoyg-root
SU 11/18 09:14 - pts/2 mcevoyg-root
SU 11/18 09:14 - pts/2 mcevoyg-root
SU 11/18 09:14 - pts/2 mcevoyg-root
SU 11/18 09:14 + pts/2 mcevoyg-root
SU 11/18 11:45 + pts/2 mcevoyg-root
SU 11/30 14:43 - pts/3 mcevoyg-root
Unsuccessful login attempts after five consecutive failures are logged in the file /var/adm/loginlog, only if the file /var/adm/loginlog exists and is owned by root, group sys, and has read and write permissions only for root. Follow this procedure to create and configure the file /var/adm/loginlog for unsuccessful login attempt logging:
Log in (or su) as root.
Enter the command touch /var/adm/loginlog.
Enter the command chown root /var/adm/loginlog.
Enter the command chgrp sys /var/adm/loginlog.
Enter the command chmod 600 /var/adm/loginlog.
The following is an example entry written into /var/adm/loginlog.
adm:/dev/pts/9:Tue May 5 21:07:49 1998
This entry indicates that a user attempted to log in as user adm on port /dev/pts/9 on May 5 at 9:07 P.M.
The last command displays login/logout and system boot information in time sequence order. last reads the binary file /var/adm/wtmpx, which is written to every time a user logs in or out and when the system is rebooted. An example last command output is
pete console :0 Wed Apr 1 20:52 still logged in pete console :0 Wed Apr 1 20:40 - 20:51 (00:10) pete console :0 Mon Feb 23 21:31 - 20:39 (36+23:08) reboot system boot Mon Feb 23 21:13 pete console :0 Sun Feb 15 20:03 - 21:11 (8+01:07) reboot system boot Sun Feb 15 20:02 pete console :0 Sat Feb 7 16:05 - 20:00 (8+03:55) reboot system boot Sat Feb 7 15:44 pete console :0 Tue Feb 3 22:50 - 15:42 (3+16:51) root console :0 Tue Feb 3 21:04 - 22:50 (01:46) pete console :0 Tue Feb 3 20:59 - 21:03 (00:04) root console :0 Tue Feb 3 20:52 - 20:59 (00:06) pete console :0 Tue Feb 3 20:38 - 20:52 (00:13) root console :0 Tue Feb 3 20:35 - 20:38 (00:02) pete console :0 Tue Feb 3 20:19 - 20:35 (00:15) pete console :0 Tue Feb 3 20:18 - 20:19 (00:00) pete console :0 Tue Feb 3 20:18 - 20:18 (00:00) root console :0 Tue Feb 3 20:12 - 20:18 (00:05) reboot system boot Tue Feb 3 20:11 reboot system boot Tue Feb 3 18:56 root console :0 Fri Jan 30 09:11 - 09:12 (00:00) reboot system boot Wed Jan 28 11:26 root console :0 Fri Jan 23 15:00 - 11:25 (4+20:25) reboot system boot Thu Jan 22 15:14 wtmp begins Thu Jan 22 15:14
See also How to rotate wtmpx in solaris
The system install log, found in /var/sadm/system/logs/install_log, is generated when Solaris is installed on the system. The install log contains all of the character output generated throughout Solaris installation. The log contains information such as disk partitioning and formatting, software module installation status, and mount points.
The volume manager log, /var/adm/vold.log, is used by the Solaris Volume Manager (the software that manages the CD-ROM and diskette drives and automates the user-system interaction when using those drives).
The sysidtool log, found in /var/sadm/system/logs/sysidtool.log, is generated by the sysidtool tool suite, itself run automatically at system installation time or when the system is unconfigured with sys-unconfig. This log can be useful for double-checking the configuration of a newly installed or reinstalled system to see what, if any, changes have occurred.
Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.
The generic Solaris installation includes a syslog file that sends most logging information to the /var/adm/messages file; only mail.debug information is sent to the /var/adm/syslog file. One particular shortcoming of the Solaris default installation is that auth.notice messages aren't logged anywhere.
All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.
Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.
adm/utmp, adm/utmpx, /adm/wtmp, and adm/wtmpx
These files contain user and accounting information that is recorded when a user logs in, logs out, or starts a new shell process with an application such as xterm or screen.Records written to these log files by the managing application contain account activity for the system.
The data in these files are written as binary data so they must be read by a tool specifically designed to do so, such as last(1) and who(1). See the system man pages for last(1) and who(1) for additional information on the data and display formats available with these tools.
adm/lastlog
This binary log file stores information about a user who has logged into the system. It is kept up to date by utilities such as login(1) and in.uucpd(1M). The data are viewable with tools such as last(1), who(1), and finger(1). Refer to the system man pages for more information.
adm/sulog
The sulog file is a record of all attempts by users on the system to execute the su(1M) command. Each time su(1M) is executed, an entry is added to the sulog file.
The format of this human-readable text file includes date, time, success/failure (+/-), and both the current and requested account. The following is a sample excerpt from a sulog file:
SU 08/28 11:41 - pts/1 jxk-root SU 08/28 11:41 + pts/1 jxk-root SU 09/14 13:05 + pts/0 thimbl-root SU 09/14 14:58 + pts/0 thimbl-root SU 09/16 13:52 + pts/0 thimbl-root SU 09/16 15:16 + pts/2 thimbl-guest SU 10/19 14:17 - pts/2 marchok-root SU 10/19 14:17 + pts/2 marchok-root
/var/log
Syslog files
Often a number of miscellaneous syslog files are written to /var/log for logging events that are not logged elsewhere such as main, news, and user events. You can view which of these events are written to this directory (or any other log files) by reviewing the syslog config file /etc/syslog.conf. For example, the following syslog.conf file writes several specific log files to the /var/log directory:
# syslog configuration file (loghost) # #output to console *.err;mail,kern.notice;daemon,auth.debug;user.info /dev/console #output to local file "messages" for automatic log file analysis *.err;auth,daemon,mark,kern.debug;mail,user.notice var/adm/messages #output to local files for archiving messages of potential interest auth.debug /var/log/auth.log daemon.debug /var/log/daemon.log lpr.debug /var/log/lpr.log mail.debug /var/log/mail.log news.debug /var/log/news.log uucp.debug /var/log/uucp.log user.debug /var/log/user.log # #end of /etc/syslog.conf #
log/sysidconfig.log
This log file is created by the sysidconfig(1M) command, which executes system configuration applications or defines a set of system configuration applications. Specific information about this and other related system configuration tools can be found in the system man pages for sysidconfig.
/var/cron
cron/log
This file contain log entries for cron(1M) and at(1) jobs that have been run on the local machine. This file is a text file that lists the command that was run, at what time, and as what user. The following example log file contains both a cron and at job entry:
> CMD: /usr/lib/uucp/uudemon.hour > uucp 14572 c Mon Nov 9 19:11:00 1998 < uucp 14572 c Mon Nov 9 19:11:00 1998 > CMD: 910656780.a > root 14592 a Mon Nov 9 19:13:00 1998 < root 14592 a Mon Nov 9 19:13:01 1998
These logs keep track of users currently logged into the system. Using the who command, check the users logged in at the current time:
<userid> pts/1 Mar 31 08:40 (origination hostname)
Look for user logins that are unexpected (e.g., for staff on vacation), occur at unusual times during the day, or originate from unusual locations.
/var/log/wtmp; /var/log/wtmpx
These logs keep track of logins and logouts. Using the last command, do the following:
Look for user logins occurring at unusual times.
<userid> pts/4 <hostname> Sat Mar 22 03:14 - 06:02 (02:47)
Look for user logins originating from unusual places (locations, addresses, and devices).
<userid> pts/12 <strange hostname> Fri Mar 21 08:59 - 13:30 (04:31)
Look for unusual reboots of the system.
reboot system boot Sun Mar 23 05:36
By default, the syslog file will contain only messages from mail (as defined in the /etc/syslog.conf file). Look for anything that looks unusual.
This log records system console output and syslog messages. Look for unexpected system halts.
Look for unexpected system reboots.
Mar 31 12:48:41 ahost.domain.com unix: rebooting...
Look for failed su and login commands.
Mar 30 09:14:00 <hostname> login: 4 LOGIN FAILURES ON 0, <userid>
Mar 31 12:37:43 <hostname> su: 'su root' failed for <userid> on /dev/pts/??
Look for unexpected successful su commands.
Mar 28 14:31:11 <hostname> su: 'su root' succeeded for <userid> on /dev/console
This log records the commands run by all users. Process accounting must be turned on before this file is generated. You may want to use the lastcomm command to audit commands run by a specific user during a specified time period.
compile <userid> ttyp1 0.35 secs Mon Mar 31 12:59
This log keeps track of dial-out modems. Look for records of dialing out that conflict with your policy for use of dial-out modems. Also look for unauthorized use of the dial-out modems
Other log files
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: February 10, 2021
