This post might be a bit trivial for the Linux gurus, but for novices Linux users hopefully helpful. I bet, all Linux users know and use the so common used last command.
last cmd provides information on last logged in users over the last 1 month time as well as shows if at present time of execution there are logged in users. It has plenty of options and is quite useful. The problem with it I have often, since I don't get into the habit to use it with arguments different from the so classical and often used:
last | less
back in time when learning Linux, is that whether run it like this I can't see full hostname of users who logged in or is currently logged in from remote hosts consisting of longer host names strings than 16 characters.
To show you what I mean, here is a chunk of last | less output taken from my home router pc-freak.net.
# last|less
root pts/1 ip156-108-174-82 Fri Dec 21 13:20 still logged in
root pts/0 ip156-108-174-82 Fri Dec 21 13:18 still logged in
hipo pts/0 ip156-108-174-82 Thu Dec 20 23:14 - 23:50 (00:36)
root pts/0 g45066.upc-g.che Thu Dec 20 22:31 - 22:42 (00:11)
root pts/0 g45066.upc-g.che Thu Dec 20 21:56 - 21:56 (00:00)
play pts/2 vexploit.net.s1. Thu Dec 20 17:30 - 17:31 (00:00)
play pts/2 vexploit.net.s1. Thu Dec 20 17:29 - 17:30 (00:00)
play pts/1 vexploit.net.s1. Thu Dec 20 17:27 - 17:29 (00:01)
play pts/1 vexploit.net.s1. Thu Dec 20 17:23 - 17:27 (00:03)
play pts/1 vexploit.net.s1. Thu Dec 20 17:21 - 17:23 (00:02)
root pts/0 ip156-108-174-82 Thu Dec 20 13:42 - 19:39 (05:56)
reboot system boot 2.6.32-5-amd64 Thu Dec 20 11:29 - 13:57 (1+02:27)
root pts/0 e59234.upc-e.che Wed Dec 19 20:53 - 23:24 (02:31)
The hostname last cmd output as you can see is sliced, so one cannot see full hostname. This is quite inconvenient, especially, if you have on your system some users who logged in with suspicious hostnames like the user play which is a user, I've opened for people to be able to play my system installed Cool Linux ASCII (text) Games. In normal means, I would skip worrying about the vexploit.net.s1….. user, however as I've noticed one of the ascii games similar to nethack called hunt was kept hanging on the system putting a load of about 50% on the CPU and was run with the play user and according to logs, the last logged in username with play was containing a hostname with "vexploit.net" as a hostname.
This looked to me very much like a script kiddie, attempt to root my system, so I killed hunt, huntd and HUNT hanging processes and decided investigate on the case.
I wanted to do whois on the host, but since the host was showing incomplete in last | less, I needed a way to get the full host. The first idea I got is to get the info from binary file /var/log/wtmp – storing the hostname records for all logged in users:
# strings /var/log/wtmp | grep -i vexploit | uniq
vexploit.net.s1.fti.net
To get in a bit raw format, all the hostnames and IPs (whether IP did not have a PTR record assigned):
strings /var/log/wtmp|grep -i 'ts/' -A 1|less
Another way to get the full host info is to check in /var/log/auth.log – this is the Debian Linux file storing ssh user login info; in Fedora and CentOS the file is /var/log/secure.
# grep -i vexploit auth.log
Dec 20 17:30:22 pcfreak sshd[13073]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=vexploit.net.s1.fti.net user=play
Finally, I decided to also check last man page and see if last is capable of showing full hostname or IPS of previously logged in hosts. It appears, last is having already an argument for that so my upper suggested methods, turned to be useless overcomplexity. To show full hostname of all hosts logged in on Linux over the last month:
# last -a |less
root pts/2 Fri Dec 21 14:04 still logged in ip156-108-174-82.adsl2.static.versatel.nl
root pts/1 Fri Dec 21 13:20 still logged in ip156-108-174-82.adsl2.static.versatel.nl
root pts/0 Fri Dec 21 13:18 still logged in ip156-108-174-82.adsl2.static.versatel.nl
hipo pts/0 Thu Dec 20 23:14 - 23:50 (00:36) ip156-108-174-82.adsl2.static.versatel.nl
root pts/0 Thu Dec 20 22:31 - 22:42 (00:11) g45066.upc-g.chello.nl
root pts/0 Thu Dec 20 21:56 - 21:56 (00:00) g45066.upc-g.chello.nl
play pts/2 Thu Dec 20 17:30 - 17:31 (00:00) vexploit.net.s1.fti.net
play pts/2 Thu Dec 20 17:29 - 17:30 (00:00) vexploit.net.s1.fti.net
play pts/1 Thu Dec 20 17:27 - 17:29 (00:01) vexploit.net.s1.fti.net
play pts/1 Thu Dec 20 17:23 - 17:27 (00:03) vexploit.net.s1.fti.net
play pts/1 Thu Dec 20 17:21 - 17:23 (00:02) vexploit.net.s1.fti.net
root pts/0 Thu Dec 20 13:42 - 19:39 (05:56) ip156-108-174-82.adsl2.static.versatel.nl
reboot system boot Thu Dec 20 11:29 - 14:58 (1+03:28) 2.6.32-5-amd64
root pts/0 Wed Dec 19 20:53 - 23:24 (02:31) e59234.upc-e.chello.nl
Listing all logged in users remote host IPs (only) is done with last's "-i" argument:
# last -i
root pts/2 82.174.108.156 Fri Dec 21 14:04 still logged in
root pts/1 82.174.108.156 Fri Dec 21 13:20 still logged in
root pts/0 82.174.108.156 Fri Dec 21 13:18 still logged in
hipo pts/0 82.174.108.156 Thu Dec 20 23:14 - 23:50 (00:36)
root pts/0 80.57.45.66 Thu Dec 20 22:31 - 22:42 (00:11)
root pts/0 80.57.45.66 Thu Dec 20 21:56 - 21:56 (00:00)
play pts/2 193.252.149.203 Thu Dec 20 17:30 - 17:31 (00:00)
play pts/2 193.252.149.203 Thu Dec 20 17:29 - 17:30 (00:00)
play pts/1 193.252.149.203 Thu Dec 20 17:27 - 17:29 (00:01)
play pts/1 193.252.149.203 Thu Dec 20 17:23 - 17:27 (00:03)
play pts/1 193.252.149.203 Thu Dec 20 17:21 - 17:23 (00:02)
root pts/0 82.174.108.156 Thu Dec 20 13:42 - 19:39 (05:56)
reboot system boot 0.0.0.0 Thu Dec 20 11:29 - 15:01 (1+03:31)
One note to make here is on every 1st number of month last command clear ups the records storing for user logins in /var/log/wtmp and nullifies the file.
Though the other 2 suggested, methods are not necessary, as they are provided in last argument. They're surely a mus do routine, t when checking a system for which doubting it could have been intruded (hacked). Checking both /var/log/wtmp and /var/log/auth.log / and /var/log/auth.log.1 content and comparing if the records on user logins match is a good way to check if your login logs are not forged. It is not a 100% guarantee however, since sometimes attacker scripts wipe out their records from both files. Out of security interest some time, ago I've written a small script to clean logged in user recordfrom /var/log/wtmp and /var/log/auth.log – log_cleaner.sh – the script has to be run as a super to have write access to /var/log/wtmp and /var/log/auth.log. It is good to mention for those who don't know, that last reads and displays its records from /var/log/wtmp file, thus altering records in this files will alter last displayed login info.
Thanks God in my case after examing this files as well as super users in /etc/passwd, there was no "signs", of any succesful breach.
on 
on 
How to resolve (fix) WordPress wp-cron.php errors like “POST /wp-cron.php?doing_wp_cron HTTP/1.0″ 404″ / What is wp-cron.php and what it does
Monday, March 12th, 2012One of the WordPress websites hosted on our dedicated server produces all the time a wp-cron.php 404 error messages like:
xxx.xxx.xxx.xxx - - [15/Apr/2010:06:32:12 -0600] "POST /wp-cron.php?doing_wp_cron HTTP/1.0
I did not know until recently, whatwp-cron.php does, so I checked in google and red a bit. Many of the places, I've red are aa bit unclear and doesn't give good exlanation on what exactly wp-cron.php does. I wrote this post in hope it will shed some more light on wp-config.php and how this major 404 issue is solved..
So
what is wp-cron.php doing?
Suppose you're writting a new post and you want to take advantage of WordPress functionality to schedule a post to appear Online at specific time:
The Publish Immediately, field execution is being issued on the scheduled time thanks to the wp-cron.php periodic invocation.
Another example for wp-cron.php operation is in handling flushing of WP old HTML Caches generated by some wordpress caching plugin like W3 Total Cache
wp-cron.php takes care for dozens of other stuff silently in the background. That's why many wordpress plugins are depending heavily on wp-cron.php proper periodic execution. Therefore if something is wrong with wp-config.php, this makes wordpress based blog or website partially working or not working at all.
Our company wp-cron.php errors case
In our case the:
212.235.185.131 – - [15/Apr/2010:06:32:12 -0600] "POST /wp-cron.php?doing_wp_cron HTTP/1.0" 404
is occuring in Apache access.log (after each unique vistor request to wordpress!.), this is cause wp-cron.php is invoked on each new site visitor site request.
This puts a "vain load" on the Apache Server, attempting constatly to invoke the script … always returning not found 404 err.
As a consequence, the WP website experiences "weird" problems all the time. An illustration of a problem caused by the impoper wp-cron.php execution is when we are adding new plugins to WP.
Lets say a new wordpress extension is download, installed and enabled in order to add new useful functioanlity to the site.
Most of the time this new plugin would be malfunctioning if for example it is prepared to add some kind of new html form or change something on some or all the wordpress HTML generated pages.WP cache directory is manually deleted with rm -rf /var/www/blog/wp-content/cache/…
This troubles are result of wp-config.php's inability to update settings in wp SQL database, after each new user request to our site.
So the newly added plugin website functionality is not showing up at all, until
I don't know how thi whole wp-config.php mess occured, however my guess is whoever installed this wordpress has messed something in the install procedure.
Anyways, as I researched thoroughfully, I red many people complaining of having experienced same wp-config.php 404 errs. As I red, most of the people troubles were caused by their shared hosting prohibiting the wp-cron.php execution.
It appears many shared hostings providers choose, to disable the wordpress default wp-cron.php execution. The reason is probably the script puts heavy load on shared hosting servers and makes troubles with server overloads.
Anyhow, since our company server is adedicated server I can tell for sure in our case wordpress had no restrictions for how and when wp-cron.php is invoked.
I've seen also some posts online claiming, the wp-cron.php issues are caused of improper localhost records in /etc/hosts, after a thorough examination I did not found any hosts problems:
hipo@debian:~$ grep -i 127.0.0.1 /etc/hosts
127.0.0.1 localhost.localdomain localhost
You see from below paste, our server, /etc/hosts has perfectly correct 127.0.0.1 records.
Changing default way wp-cron.php is executed
As I've learned it is generally a good idea for WordPress based websites which contain tens of thousands of visitors, to alter the default way wp-cron.php is handled. Doing so will achieve some efficiency and improve server hardware utilization.
Invoking the script, after each visitor request can put a heavy "useless" burden on the server CPU. In most wordpress based websites, the script did not need to make frequent changes in the DB, as new comments in posts did not happen often. In most wordpress installs out there, big changes in the wordpress are not common.
Therefore, a good frequency to exec wp-cron.php, for wordpress blogs getting only a couple of user comments per hour is, half an hour cron routine.
To disable automatic invocation of wp-cron.php, after each visitor request open /var/www/blog/wp-config.php and nearby the line 30 or 40, put:
define('DISABLE_WP_CRON', true);
An important note to make here is that it makes sense the position in wp-config.php, where define('DISABLE_WP_CRON', true); is placed. If for instance you put it at the end of file or near the end of the file, this setting will not take affect.
With that said be sure to put the variable define, somewhere along the file initial defines or it will not work.
Next, with Apache non-root privileged user lets say www-data, httpd, www depending on the Linux distribution or BSD Unix type add a php CLI line to invoke wp-cron.php every half an hour:
linux:~# crontab -u www-data -e
0,30 * * * * cd /var/www/blog; /usr/bin/php /var/www/blog/wp-cron.php 2>&1 >/dev/null
To assure, the php CLI (Command Language Interface) interpreter is capable of properly interpreting the wp-cron.php, check wp-cron.php for syntax errors with cmd:
linux:~# php -l /var/www/blog/wp-cron.php
No syntax errors detected in /var/www/blog/wp-cron.php
That's all, 404 wp-cron.php error messages will not appear anymore in access.log!
Just for those who can find the root of the /wp-cron.php?doing_wp_cron HTTP/1.0" 404 and fix the issue in some other way (I'll be glad to know how?), there is also another external way to invoke wp-cron.php with a request directly to the webserver with short cron invocation via wget or lynx text browser.
- Here is how to call wp-cron.php every half an hour with lynxPut inside any non-privileged user, something like:
01,30 * * * * /usr/bin/lynx -dump "http://www.your-domain-url.com/wp-cron.php?doing_wp_cron" 2>&1 >/dev/null
- Call wp-cron.php every 30 mins with wget:
01,30 * * * * /usr/bin/wget -q "http://www.your-domain-url.com/wp-cron.php?doing_wp_cron"
Invoke the wp-cron.php less frequently, saves the server from processing the wp-cron.php thousands of useless times.
Altering the way wp-cron.php works should be seen immediately as the reduced server load should drop a bit.
Consider you might need to play with the script exec frequency until you get, best fit cron timing. For my company case there are only up to 3 new article posted a week, hence too high frequence of wp-cron.php invocations is useless.
With blog where new posts occur once a day a script schedule frequency of 6 up to 12 hours should be ok.
Tags: 404 error, aa, akismet, Auto, caches, checks, commentor, cr, cron, daySuppose, dedicated server, doesn, dozens, Draft, email, error messages, execution, exlanation, file, google, HTML, HTTP, invocation, localhost, nbsp, newsletter, operation, periodic execution, php, plugin, quot, request, scheduler, someone, something, spam, SQL, time, time thanks, Wordpress, wordpress plugins, wp
Posted in System Administration, Web and CMS, Wordpress | 3 Comments »