Using apache allow/deny with a load balancer forwarding the clients IP as X-Forwarded-For

In this example, I have a HAproxy load balancer setup, and its forwarding the clients IP so you see that instead of the load balancer in the log files.

It is fowarded by changing the log format to:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Where You substitute %{X-Forwarded-For}i for %U

In order for apache to use this value to allow/deny people you need to set it like the following:

SetEnvIfNoCase ^X-Forwarded-For ^1\.2\.3\.4 officeip


Order deny,allow
Deny from all
Allow from env=officeip

Nagios - Favorite Linux Monitoring Application! by linux journal.

http://www.linuxjournal.com/article/10451

Favorite Linux Monitoring Application

Nagios (51%)

Honorable Mention

Hyperic HQ (15%)

up.time (11%)

Nagios was not only recently dubbed one of the most important open-source apps of all time, but it also is the winner of the new Readers' Choice category, Favorite Linux Monitoring Application. A slim majority 51% of you use Nagios to keep close tabs on your networks of all shapes, sizes and levels of complexity. Most of you not using Nagios opt for the Honorable Mention candidates, Hyperic HQ (with 15%) and up.time (11%). Ganglia and GroundWork also garnered respectable votes in the single digits.

Easy remote syslog-ng setup

This is on CentOS, of course you already have regular syslog installed so download syslog-ng rpm from wherever and install...

Force its install via:

sudo rpm --force -Uvh syslog-ng-1.6.12-1.el5.centos.i386.rpm

or remove the old syslog first via:

rpm -e --nodeps rsyslog

stop syslog and start syslog-ng:

sudo /etc/init.d/syslog stop && sudo /etc/init.d/syslog-ng start

Test that its working via:

logger "test message" && sudo tail /var/log/messages

remove syslog from starting and setup syslog-ng to start up on boot:

sudo chkconfig syslog off && sudo chkconfig syslog-ng on && sudo chkconfig --list | grep syslog

Enable remote syslogging on the host syslog server
HOST:
sudo vi /etc/syslog-ng/syslog-ng.conf
add:

source s_network {
tcp(max-connections(5000));
udp();
};

destination d_network {
file ("/var/log/syslog-ng/$HOST/$FACILITY.log");
};

log { source(s_network);
destination(d_network);
};

Sending messages from your syslog-ng client
CLIENT:
sudo vi /etc/syslog-ng/syslog-ng.conf

destination loghost {
tcp("192.168.1.5");
};

log {
source(s_sys);
destination(loghost);
};

Add an iptables allow rule for port 514, and optionally add the -s and mention the host (much more secure)
sudo vi /etc/sysconfig/iptables
add:
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 514 -s 192.168.1.5 -j ACCEPT
restart iptables:
sudo /etc/init.d/iptables restart

Test that its working by running on the client:
logger "test to remote"

and running on the host:
tail -f /var/log/messages

If you see the msg its working .. if not, you fail... try again.

Amazon New features! Loan balancing and monitoring.... finally!

Dear AWS Community Member,

You signed up to be notified when we released monitoring, auto scaling and load balancing for Amazon EC2. We are excited to announce the public beta of these new features: Amazon CloudWatch, a web service for monitoring AWS cloud resources, Auto Scaling for automatically growing and shrinking Amazon EC2 capacity based on demand, and Elastic Load Balancing for distributing incoming traffic across Amazon EC2 compute instances. Together, these capabilities provide you with visibility into the health and usage of your AWS compute resources, enhance application performance, and lower costs.

Monitoring

Amazon CloudWatch is a web service that provides monitoring for AWS cloud resources, starting with Amazon EC2. It provides customers with visibility into resource utilization, operational performance, and overall demand patterns -- including metrics such as CPU utilization, disk reads and writes, and network traffic. To use Amazon CloudWatch, simply select the Amazon EC2 instances that you'd like to monitor; within minutes, Amazon CloudWatch will begin aggregating and storing monitoring data that can be accessed using web service APIs or Command Line Tools.

Auto Scaling

Auto Scaling allows you to automatically scale your Amazon EC2 capacity up or down according to conditions you define. With Auto Scaling, you can ensure that the number of Amazon EC2 instances you're using scales up seamlessly during demand spikes to maintain performance, and scales down automatically during demand lulls to minimize costs. Auto Scaling is particularly well suited for applications that experience hourly, daily, or weekly variability in usage. Auto Scaling is enabled by Amazon CloudWatch and available at no additional charge beyond Amazon CloudWatch fees.

Elastic Load Balancing

Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon EC2 instances. It enables you to achieve even greater fault tolerance in your applications, seamlessly providing the amount of load balancing capacity needed in response to incoming application traffic. Elastic Load Balancing detects unhealthy instances within a pool and automatically reroutes traffic to healthy instances until the unhealthy instances have been restored. Customers can enable Elastic Load Balancing within a single Availability Zone or across multiple zones for even more consistent application performance.

Like all Amazon Web Services and features, Amazon CloudWatch and Elastic Load Balancing are available on a pay-as-you-go basis with no up-front fee, minimum spend or long term commitment. Auto Scaling is free to Amazon CloudWatch customers. Each instance launched by Auto Scaling is automatically enabled for monitoring and the Amazon CloudWatch monitoring charge will be applied.

For more information on these new features and details on how to start using them, please see the resources listed below:

Amazon EC2 Detail Page

Release Notes

These have been among the most requested Amazon EC2 features by our customers. We hope they prove useful to you, and we look forward to your feedback.

Sincerely,

The Amazon Web Services Team

Amazon has a new feature, reserved instances.

Basically you pay a one time up front fee, and it drastically lowers your hourly $ cost per instance.

You can have a small instance (Small Instance (Default) 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform)

For around - 65$/month - 780$/year, you could have a dedicated server ... pretty sweet deal.

Now if you add in the reserved instance's feature...

A small instance will cost
$325(reserved instance fee) + $262/year = $587/year ... even better deal.

Sign up for 3 years, and you now are paying...
$587 1st year, and then $262 ... end of 3 years total = $1111 compared to $2340 for the regular price for 3 years.

Rebundeling a running ec2 instance....

ec2-bundle-vol --prefix what_you_want_to_name_it -d /mnt/ami -c pathtocert.pem -k pathtokeyfile.pem -u 123456789 -s 10240 --kernel aki-9b00e5f2 -r i386

-d, --destination PATH
-c, --cert PATH
-k, --privatekey PATH
--kernel ID Id of the default kernel to launch the AMI with.
-r, --arch ARCHITECTURE Specify target architecture. One of ["i386", "x86_64"]
-s, --size MB The size, in MB (1024 * 1024 bytes), of the image file to create. The maximum size is 10240 MB.

(change the kernel type and arch to suite your needs... might as well use the largest size 10240)

This will bundle your running instance, and place the files in /mnt/ami

ec2-upload-bundle -b bucketname -m /mnt/ami/what_you_named_it.manifest.xml --access-key XYZ --secret-key XYZ

This will upload your bundled image to your bucket.

ec2-register /bucket/what_you_named_it.manifest.xml

The last step is to register your image, you will get back the AMI ID, and can either start your instance on the cmd line, or simply login to the web console and start it.

Nagios - Instead of a ping check to see if a host is alive, use http instead

Sometimes (often) ICMP is blocked, so you can't ping check your hosts to see if they are alive.

You can add this to commands.cfg and hosts.cfg for those hosts to check via http instead.

commands.cfg

define command {
   command_name check-host-alive-by-http
   command_line $USER1$/check_http -H $HOSTADDRESS
}

hosts.cfg

define host{
host_name hostname.com
address ip.address
alias hostnamealias
use networking_machines_template
check_command check-host-alive-by-http
}