Description:

The standard /var/log/lastlog implementation using lastlog.h from
glibc uses a 32bit time_t in struct lastlog on bi-arch systems like
x86-64 (so which can execute 64bit and 32bit binaries). So even if you
have a pure 64bit system, on many architectures using glibc you have a
Y2038 problem.

Additional, /var/log/lastlog can become really huge if there are big
UIDs in use on the system. Since it is a sparse file, this is normally
not a problem, but depending on the filesystem or the tools used for
backup, this can become a real problem.

Since there are only few applications which really support lastlog,
the data is also not always correct.

lastlog2 tries to solve this problems:

- It's using sqlite3 as database backend.
- Data is only collected via a PAM module, so that every tools can
make use of it, without modifying existing packages.
- The output is as compatible as possible with the old lastlog
implementation.
- The old /var/log/lastlog file can be imported into the new database.
- The size of the database depends on the amount of users, not how big
the biggest UID is.

IMPORTANT To be Y2038 safe on 32bit architectures, the binaries needs
to be build with a 64bit time_t. This should be the standard on 64bit
architectures.