( *Debian Squeeze is perhaps to be released late 2010 )
But in order to test out the forthcoming release, perhaps you might go ahead and manually upgrade.
Kernel 2.6.3x rather than 2.6.18:
Ideally your VPS will be running in a hosting container that is running kernel 2.6.26 or newer.
( Such newer kernels are provided in Debian Squeeze, Red Hat Enterprise 6, and Ubuntu Lucid. It really depends on your hosting company, when they installed the container, how often they update container kernels, and their technology. )
If your container is unsuitable then you might see something like this:
Here Debian Squeeze is helping you, by pointing out that your kernel, does not support everything which Debian Squeeze might want.
Seeing "udev requires a kernel >=" warning on your VPS should make you pause.
One of the things that might be an issue is signalfd() or lack of.
If you decide to ignore the advice and try and run Debian Squeeze anyway, then you will probably be looking at how to get permissions fixed on some /dev/ files.
( It would be unwise for me to recommend this kind of action by elaborating.
It certainly makes reporting bugs difficult, if you deliberately run a production system using a kernel that is known to be outdated. )
/var/log/auth.log - is logging active?:
From a security point of view
auth.log is an important file.On a properly configured system,
auth.log will give a concise record of important authorisations (including ssh logins)After your upgrade it does no harm to check
/var/log/auth.log is being written to.
auth.log is sometimes used by logwatch and similar security tools.If you upgrade (particularly to a beta or testing distribution) then check that your system logging is working as expected.
Also check, when changing your system from running
rsyslog to dsyslog or syslog-ng or other system logging alternatives.Here is a diff to overcome an issue with the testing version of dsyslog in squeeze:
( The line marked with the green cursor is the important addition, and the sections related to cron are my convenience changes, rather than to fix any issue )
Today
dsyslog.conf needed to be altered as condition pattern did not seem to be working as intended:condition pattern { facility "auth*"; }; The above should have
dsyslog writing to auth.log , but it was not happening on my system. It will likely be fixed before squeeze is officially released later this year.To overcome the issue, I instead use
condition literal as illustrated in the screenshot [ above ].Packages you may want to purge once upgrade to squeeze is complete:
- gcc-4.2-base
- gcc-4.3-base
Locales cleardown and removing cruft from server accounts running X:
Try localepurge for reclaiming some redundant server space.
Another tool, bleachbit, might be useful for those running X on a remote server.
Bleachbit helps clear down user files such as those left behind when running web browsers, OpenOffice, etc.
( I have not used it in a server environment and would have to do some further reading, before I would feel comfortable running a shred like tool on a production server )
I tag this article 'nonKVM' and 'oldkernel' as Xen and OpenVZ, being more widespread in 2008 and 2009, tend to run with older kernel 2.6.18 rather than the much newer 2.6.3x series such as that included in RHEL6. Dedicated KVM resource offerings will become more widespread in late 2010 and 2011, and benefit from kernel 2.6.3x by simple fact of coming later to the party.
Having done some more reading about dsyslog.conf, it seems that you can define the same output file in multiple sections.
ReplyDeleteHere is a diff that defines auth.log 3 times in order to ensure dsyslog really does put sshd failure IP addresses in the auth.log
85,86c85
< # condition pattern { facility "auth*"; };
< condition literal { facility auth; };
---
> condition pattern { facility "auth*"; };
88,89d86
< output file { path "/var/log/auth.log"; condition literal { facility authpriv; }; };
< output file { path "/var/log/auth.log"; condition literal { program sshd; }; };