Category: linux

Posted on

Fixing REMOTE_ADDR when behind a proxy/varnish server

I had an annoyance where varnish proxy infront of a LAMP server and the LAMP server therefore thought all clients were from the varnish proxy – rather than the client’s real IP address – i.e. $_SERVER[‘REMOTE_ADDR’] was set to the IP address of the Varnish proxy and not that of the client’s actual IP address.

Obviously, Varnish adds the X_HTTP_FORWARDED_FOR HTTP header in when a connection comes through it; so my initial thought was to just overwrite PHP’s $_SERVER[‘REMOTE_ADDR’] setting. A bit of a hack and annoying – as I’d need to fix all sites, or have some sort of global prepend file (which is horrible).

I then discovered something which sorts the problem out  – RPAF

  • apt-get install libapache2-mod-rpaf
  • Edit /etc/apache2/mods-enabled/rpaf.conf and ensure your proxy server’s IP address is listed on the RPAFproxy_ips line (e.g. RPAFproxy_ips 127.0.0.1 89.16.176.x).
  • Restart Apache, and you’ll then find that the $_SERVER[‘REMOTE_ADDR’] value will be correct.

 

 

Posted on

fsck paranoid?

Some random hints :

  1. Ensure the final field / column in /etc/fstab is non-zero for other filesystems you have mounted; if it’s 0 then fsck will never run on them.
  2. fsck -Cccy /dev/blah1 does a read-write (non-destructive test). Works well on SSDs 🙂
Example from /etc/fstab:
/dev/md0  /mount/point ext3 defaults 0 2

When looking at the various boxes we have in our office, I found one server had the following (run dumpe2fs /dev/whatever1):

  • Mount count:              62
  • Maximum mount count:      39
  • Last checked:             Wed Jul  9 16:09:17 2008
  • Next check after:         Mon Jan  5 15:09:17 2009
Today is 8th June 2012. Ooops.

Interestingly when I did run fsck on it, there were no errors. Is perhaps the default ext3 setting of checking every 20-30 mounts too paranoid?  It’s certainly very painful running fsck on large ‘rotating’ volumes – waiting over an hour for a server to come up is not fun.

 

Posted on

Sponge – Shell command

Today, my sed kung-foo seemed to be lacking, so I ended up having to split the sed command over a zillion lines…

Normally I’d do something like :

sed 's/foo/bar/g' tmp.txt > tmp2.txt
sed 's/fo2/blah/g' tmp2.txt > tmp3.txt

But this obviously gets painful after a time, a different approach would be to use sponge where we can do :

sed 's/foo/bar/g' tmp.txt | sponge tmp.txt
sed 's/fo2/blah/g' tmp.txt | sponge tmp.txt

Whereby ‘sponge’ soaks up standard input and when there’s no more, opens the output file. This gets around the obvious problem that :

sed 's/foo/bar/g' tmp.txt > tmp.txt

doesn’t work because the shell opens (and overwrites) tmp.txt  before sed’s had a chance to do anything.

Posted on

exim + spamassassin subject rewriting on symbiosis

One customer of mine has an Bytemark Symbiosis based exim mailserver which uses SpamAssassin. It works pretty well – however the :

rewrite_header Subject *****SPAM*****

directive in spamassassin (/etc/spamassassin/local.cf) seemed to be being ignored – and the only effect of the mail being classified as spam is/was a couple of additional headers added (X-Spam-Status: spam). For the customer in question this wasn’t of much use – as they’re reasonably non-technical and probably couldn’t create a client side mail filter. And they also thought the spamfiltering wasn’t working.

I found adding the following to /etc/exim4/system_filter results in the subject being appropriately modified :

if $h_X-Spam-Status: contains "spam"
then
    headers add "Old-Subject: $h_subject"
    headers remove "Subject"
    headers add "Subject: *** SPAM *** $h_old-subject"
    headers remove "Old-Subject"
endif

And if you want to tag virus-ey emails … add this in as well : 

# X-Anti-Virus: infected
if $h_X-Anti-Virus: contains "infected"
then
    headers add "Old-Subject: $h_subject"
    headers remove "Subject"
    headers add "Subject: *** VIRUS *** $h_old-subject"
    headers remove "Old-Subject"
endif

Seeing as how that took about 2 hours to figure out – hopefully this will be of use to others.

I started looking at SpamAssassin and wondering why IT wasn’t doing it… I still don’t know why – but assume it’s an Exim ‘feature’.

Posted on

netstat –tcp -lp output not showing a process id

I often use ‘netstat –tcp -lpn’ to display a list of open ports on a server – so i can check things aren’t listening where they shouldn’t be (e.g. MySQL accepting connections from the world) and so on. Obviously I firewall boxes; but I like to have a reasonable default incase the firewall decides to flush itself randomly or whatever.

Anyway, I ran ‘netstat –tcp -lpn’ and saw something like the following :

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      3355/mysqld     
tcp        0      0 0.0.0.0:54283           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1940/portmap

Now ‘mysqld’ looks OK – and portmap does (well, I need it on this box). But what on earth was listening on port 54283, and why is there no process name/pid attached to it?

After lots of rummaging, and paranoia where I thought perhaps the box had been rooted, I discovered it was from an NFS mount (which explains the lack of a pid, as it’s kernel based).

lsof -i tcp:54283

Didn’t help either. Unmounting the NFS filesystem did identify the problem – and the entry went away.

Posted on

Checking varnish configuration syntax

If you’ve updated your varnish server’s configuration, there doesn’t seem to be an equivalent of ‘apachectl configtest’ for it, but you can do :

varnishd -C -f /etc/varnish/default.vcl

If everything is correct, varnish will then dump out the generated configuration. Otherwise you’ll get an error message pointing you to a specific line number.

Posted on

yum changelog (Want to know what you’re about to upgrade on CentOS/RHEL?)

Want to see what changes you’re about to apply when doing a ‘yum update’ ? Similar-ish to how ‘apt-listchanges’ works…

On CentOS 5.6, try :

  • yum install yum-changelog python-dateutil

Note, python-dateutil seems to be an unmarked dependency – i.e. you get an error message like : “Dateutil module not available, so can’t parse dates” when trying to run ‘yum changelog all updates’.

Note, /etc/yum/pluginconf.d/changelog.conf (but this didn’t seem to need changing to me).

Now you can do :

  • yum changelog all updates
  • yum changelog all mysql-server (or whatever package you’re interested in).

 

Posted on

Useful settings for history recording in bash (/etc/profile or ~/.bashrc)

shopt -s histappend
shopt -s checkwinsize
export HISTCONTROL=ignoredups:ignorespace
export HISTTIMEFORMAT='%Y-%m-%d %H:%M:%S  '
export EDITOR=vim

histappend: don’t overwrite .bash_history files on each logout; then when someone logs into the server, and messes something up, there’s a vague chance you’ll see what they did. Your history file will obviously grow to be quite big – but suppression of duplicates helps. Mine’s only 900kb after 7 months.

checkwinsize: check the window size after each command, might help some braindead programs cope with you resizing their windows, I guess.

HISTCONTROL: suppress duplicates, ignore spaces

HISTTIMEFORMAT: record a timestamp against each history entry; run ‘history’ to see an example of it’s output…

EDITOR: why would you not use vim?