And finally:
rm -vf $LIST

In order to enable error reporting for your php script or application include inside your code the following lines:
error_reporting(E_ALL);
ini_set("display_errors", 1);
and this will result in displaying in the browser any errors your application might have.

ps: once you are done with this and fixed the issue, don’t forget to remove the error reporting lines, as we don’t want our users/clients to see errors in the browser in case something went wrong.

If the remote ssh server is not running on the default ssh port (tcp 22) then this needs a little tweaking to get it working. Normally I was expecting that adding a custom entry for the svn server in the /etc/ssh/ssh_config file with the appropriate port would make this work on the fly without changing the command line; or if not, adding the ssh port in ‘telnet like’ way: server:port would make a difference. Still none of those worked and in order to get this working I had to dig into the subversion documentation on how we can define a special tunnel.

We can define a new tunnel in the svn configuration file (.subversion/config):
[tunnels]
sshtunnel = ssh -p <port>

And after this we can use svn as usual but with a url like svn+sshtunnel:// :
svn co svn+sshtunnel://user@server/repo .

Getting Started

First of all you will need one Amazon AWS account and enable the EC2 service; in case you don’t have this already now is the time to create your account. Once you do that you can safely return to this doc

Once you have your account working, while still on the aws site, go and create a new X.509 certificate (under the AWS Access Identifiers page, in the X.509 certificate section near the bottom, click Create New). Once this is done, you will want to download locally the private key file and X.509 certificate.

EC2 API tools

Next you will have to download and install the Amazon EC2 api tools on one system (controlling machine) that will be used to start your EC2 army of servers, and control their usage. You will want to use the latest version (2009-05-15 at this time) as it will support all the features Amazon is offering for the EC2 service.

The only real dependency of the EC2 API tools is java (at least version 1.5) so we will want to install that first. If you are running debian you can easily do this just by running (for lenny):
aptitude install sun-java6-jre
while for etch you will have to use: aptitude install sun-java5-jre
For other distributions you can either use their internal packaging mechanism (in case they provide sun-java packages) or just download the binary from sun and install it manually.

Extract the EC2 APi tools (it is a zip archive called ec2-api-tools.zip) and move it under a folder of your preferece. I like to use ~/.ec2 for this, but you can use any folder you prefer. Also copy the private key and X.509 certificate in the same directory. Those files will look like cert-xxx.pem and pk-xxx.pem.

Next we will have to export some shell variables. A good place to put this is in ~/.bashrc:
export EC2_HOME=~/.ec2
export PATH=$PATH:$EC2_HOME/bin
export EC2_PRIVATE_KEY=$EC2_HOME/pk-xxx.pem
export EC2_CERT=$EC2_HOME/cert-xxx.pem
#Java home for debian default install path:
export JAVA_HOME=/usr
#add ec2 tools to default path
export PATH=~/.ec2/bin:$PATH

Finally source the file to have the changes active in your current shell session:
source ~/.bashrc
or just open a new shell before starting to use the API tools.

EC2 Keypair

We will need to create one keypair that will be used to connect using ssh to the EC2 instances we will be using. We will use the ec2-add-keypair utility to create the key and register it with amazon:
ec2-add-keypair my-keypair
This will print out the private key that we will have to save in a file:
cat > ~/.ec2/id_rsa-my-keypair
#paste the private key content
sudo chmod 600 ~/.ec2/id_rsa-my-keypair

Running your first EC2 instance

Amazon EC2 uses the concept of AMIs = Amazon Machine Images. Any EC2 instance is started from one AMI. You can either use standard, public AMIs or create and customize your own private images. Creating or modifying existing AMIs is beyond the scope of this article, but just as a general information this is done using special AMI tools. Also before building your AMI you will want to ensure if you want to use a ‘small’ type of image (i386 os) or a ‘large’ type of instance (64bit os). These are described under http://aws.amazon.com/ec2/instance-types/

For the scope of our article we will find a standard public image and start one instance of it to see that all is working properly with the EC2 api tools. You can see all the public images using:
ec2-describe-images -a
(over 2,300 images ). You should probably grep the result to get any useful information. There are many good public images to use, like for example the alestic ones (for debian and ubuntu)
Having the AMI id of the image we want to use we are ready to start our fist EC2 instance:
ec2-run-instances ami-e348af8a -k my-keypair
that will start a small instance with a 32bit debian lenny server instance from alestic.com.

ec2-describe-instances
- this will describe the status of all the running instances, with their hostname, instance id, etc.

ec2-authorize default -p 22
- in order to connect to your instance you will need to customize the ‘default’ firewall rules for your account. The above rule will allow ssh on port 22 from anywhere. If you want to open http traffic you will have to add a rule like this:
ec2-authorize default -p 80

Finally we can ssh to the ec2 instance using:
ssh -i ~/.ec2/id_rsa-my-keypair root@ec2-XXX-XXX-XXX-XXX.z-2.compute-1.amazonaws.com
where ec2-XXX-XXX-XXX-XXX.z-2.compute-1.amazonaws.com is the actual hostname of the instance as obtained from ec2-describe-instances.

Note: don’t forget to stop your instance when you no longer need it. EC2 is a service paid as you use, hence if you forget your instance running you will be billed for it . You can do this by running shutdown inside the instance or by using:
ec2-terminate-instances i-yourinstance
and verify with ec2-describe-instances that the instance is indeed stopped.

Next step is to create/customize your own EC2 AMI images based on your needs. This will be covered in a future article. Hopefully you found this article useful, and it will get you on track quickly with Amazon EC2 api tools.

To overcome this issue, and at least have rpm report the proper versions we have to add in our rpmmacros file a new line like: “%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}” that will add to the rpm output the architecture and allow us to see the this:

cat >> ~/.rpmmacros
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}

and now running the same command will return a more intuitive and meaningful:
rpm -qa | grep ncurses
ncurses-5.5-24.20060715.x86_64
ncurses-5.5-24.20060715.i386

This doesn’t fix anything in how yum will install duplicate programs or libraries, but at least it will allow us to see the full name of the packages in rpm commands. Theoretically people should be able to add into yum.conf (this is the default anyway, so you might have it already):
exactarch=1
and yum will install by default the packages of the arch it is running on (x86_64 in our case). Still, this will not prevent i386 dependencies to show up and be installed. In case you want to completely ignore other arch packages add in the [main] section of /etc/yum.conf to exclude all 32bit packages,:
exclude=*.i386 *.i586 *.i686
and this will completely exclude them completely from yum operations. Please use this with care, and only if you have a full understanding of the implications to exclude those packages.

Even if you don’t exclude the 32bit packages as shown above, it is a good idea to add the arch to all yum operations (like install, remove, etc.), like:
yum install ncurses.x86_64

Hopefully you found this post useful, and have now a better understanding on how rhel/centos use the i368 and x86_64 packages and libraries with rpm and yum on a 64bit installation.

Prerequisites

Before even starting, let’s check that our ASA5505′s are running the appropriate software license. For example the sh run command will output something like this:
sh ver
...
Licensed features for this platform:
Maximum Physical Interfaces  : 8
VLANs                        : 20, DMZ Unrestricted
Inside Hosts                 : Unlimited
Failover                   : Active/Standby
VPN-DES                      : Enabled
VPN-3DES-AES                 : Enabled
VPN Peers                    : 25
WebVPN Peers                 : 2
Dual ISPs                    : Enabled
VLAN Trunk Ports             : 8
AnyConnect for Mobile        : Disabled
AnyConnect for Linksys phone : Disabled
Advanced Endpoint Assessment : Disabled
UC Proxy Sessions            : 2
This platform has an ASA 5505 Security Plus license.
.
You should look at the Failover feature and you should have “Active/Standby“. If this outputs disabled, you will have to order and install a software license upgrade from Cisco in order to be able to use the ASA’s in failover.

Cisco (as always) has a very complex documentation on how you can achieve this. Still, it is hard to digest, as they try to cover all possible devices on the same page (even the obsolete pix500); even more the ASA5505 has some particularities compared with the rest of the ASA 5500 range of products and this is not very clearly explained. Hopefully this post will be more useful and simpler to follow.

First we need to understand some limitations of our devices. The ASA5505 can only perform Active/Standby failover and not Active/Active. If you need that, you will have to look at a higher range device. Also they can only perform LAN-Based Failover (as opposed to old pixes that can use cable based failover) and they don’t support Stateful Failover (meaning all active connections will be lost after a failover event). Also both units must have the same hardware, software configuration, and proper license and run in same mode (single or multiple, transparent or routed).

Configuring the Primary Unit

For each of the IPs assigned to the interfaces of the ASA we will need to allocate a secondary IP from the same network range; this will be used as the IP of the standby unit, while the main IPs will always be used by the primary (active) unit and will be normally used by the clients (as default gateways for ex). The first step is to configure the active and standby IP addresses for each data interface; the cisco documentation is confusing here and it is not clear that on the ASA5505 this is done for each of the used vlans, and not real interfaces:
conf t
(config)#interface Vlan1
(config-if)#ip address active_addr netmask standby standby_addr
for ex:
(config-if)#ip address 192.168.0.1 255.255.255.0 standby 192.168.0.2

Once we have defined all standby IPs we can move forward…
You will also need to define one interface that will be used for failover. You can either cross-connect this between the 2 ASAs or you can use a switch with a dedicated vlan for this. The later one is preferred as it will more accurately detect if one ASA is down. Again in the documentation this is not clear how to do it on the ASA5505 and it discusses about real interfaces, while on the ASA5505 we have to use vlans.

The trick is to create a new vlan and don’t assign any ip on the vlan inteface:
interface Vlan32
description LAN Failover Interface
no shutdown
the ip will be assigned by the failover commands;
Finally enable failover:
failover
failover lan unit primary
failover lan interface failover Vlan32
failover interface ip failover 192.168.255.1 255.255.255.0 standby 192.168.255.2
(where you will use one unused ip range for the failover ips).

Save the running config: copy running-config startup-config

Configuring the Secondary Unit

The configuration of the secondary, standby unit is very simple as it needs only the failover interface configuration.  The secondary unit requires these commands to initially communicate with the primary unit, and get its configuration from the active unit.

As with the main ASA we have to define the vlan that will be used for failover first:
interface Vlan32
description LAN Failover Interface
no shutdown

And next we just have to enable failover and set this unit as secondary:
failover
failover lan unit secondary
failover lan interface failover Vlan32
failover interface ip failover 192.168.255.1 255.255.255.0 standby 192.168.255.2

After this, the active unit sends the configuration in running memory to the standby unit. As the configuration synchronizes, the messages “Beginning configuration replication: Sending to mate” and “End Configuration Replication to mate” appear on the active unit console.

Verifying the Failover Configuration

The command show failover can be used to show the status of the failover operation; the output on the active device will look similar to:
sh failover
Failover On
Failover unit Primary
Failover LAN Interface: failover Vlan32 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 5 of 250 maximum
Version: Ours 8.0(4), Mate 8.0(4)
Last Failover at: 02:28:31 CST Jan 23 2009
This host: Primary - Active
Active time: 2166923 (sec)
slot 0: ASA5505 hw/sw rev (1.0/8.0(4)) status (Up Sys)
Interface inside (10.10.10.1): Normal
Interface outside (192.168.0.1): Normal
slot 1: empty
Other host: Secondary - Standby Ready
Active time: 378 (sec)
slot 0: ASA5505 hw/sw rev (1.0/8.0(4)) status (Up Sys)
Interface inside (10.10.10.2): Normal
Interface outside (192.168.0.2): Normal
slot 1: empty

Finally, you will probably want to test the failover functionality and maybe tune the triggers of the failover, but maybe we will talk about this in a future post.
I hope you found this post useful and helped to explain better the steps needed to configure the Active/Standby Failover on the ASA5505.

It looks like they will be teaming up with  Free Software Foundation.

Hello,

This email details your current earnings from your participation in the Ad Bard Network.  We are also excited to announce major changes to our network, including general improvements and the direct participation of the Free Software Foundation.  However, our planned changes require that we temporarily suspend the entire network for the month of February.  As a member you will be receiving payment for your outstanding earnings balances, and then if you elect to participate in our newly structured network you will be required to sign up again.  We apologize for the inconvenience of this, but hope that it helps achieve the end goal of increasing the earnings of member websites and improving the desirability of the network for advertisers.

Statistics:
———–
LInux System Admin Blog average ad impressions:
Hourly:           nn
Daily:           nnn
Monthly:      nnnnn

Outstanding earnings:
$nnn

Due to the upgrade in process, please remove the JavaScript snippet from your website at this time.  No further advertisements will be displayed through this snippet, and before the end of February 2009 the handling for this javascript will be disabled and could result in an error on your website.  If you will require more than 2 weeks to remove the snippet, please send us an email and we will work with you as necessary.  A new snippet will be provided for the new website.

We will be issuing payments for all outstanding earnings through PayPal or via a check.  If your payment information has changed, please respond
to this email with updated details.  Please be sure to include your Ad Bard username in your email.

If you have converted earnings into unused coupons, please reply to this email with details so that we are sure to properly credit you
back.

Details about our enhanced network will be posted to http://adbard.net/ over the upcoming month.  You will also be receiving an update via email when it is possible to sign up for the new network.  A few of the planned changes include a limited number of advertising slots, the ability to participate in approving which FLOSS-appropriate advertisements are accepted, and improvements to our payment algorithms.
The Free Software Foundation is actively advising us in this effort, and will help campaign for the new network once it goes live.

Thank you for your patience and participation in our evolving network. We hope that you like the changes that will be happening this month, and
that you will continue to participate.

Cheers, -Jeremy

–
Jeremy Andrews
877-875-8824 x100
Tag1 Consulting, Inc.

After you have the above things prepared, from the ASA cli (in exec mode) you have to run:
copy tftp flash
Address or name of remote host []? <- 192.168.1.1
Source filename []? <- asdm-61551.bin
Destination filename [asdm-61551.bin]? <- enter
This will download the asdm firmware on the firewall flash.

Now you just have to enable the new version, from configure mode:
configure terminal
asdm image disk0:/asdm-61551.bin
exit
write mem

And finally you will have to reboot the ASA in order for the change to become active:
reload

Note: replace the asdm filename with the one you are actually upgrading (might be a newer one for ex.) and also use the proper ip for your tftp server.

Still on RHEL/Centos based systems this is not enough, and even if apparently all seems to work as expected, there might be some applications still using the old timezone. This is happening if they read the timezone definition from the rhel specific file: /etc/sysconfig/clock
cat /etc/sysconfig/clock
ZONE="America/Chicago"
UTC=true
ARC=false

We also need to update the ZONE field in /etc/sysconfig/clock to be sure that all occurrences of the old timezone are changed and everything on the system will use the new setting.

Note: you don’t need to restart the system to activate this change, but you will have to restart the applications using the timezone so they can read the updated information.

After further investigation we realized that vsftpd was not using the system timezone settings but was always logging its messages using GMT. Why would anyone want this? I have no idea, but imo they should change the default value to use the system timezone as that is what the majority of people would expect. In order to fix this, you just have to add to the vsftpd.conf the following line:
use_localtime=YES
as we can see from vsftpd manual page (man vsftpd.conf) if undefined, this defaults to “NO“:
“use_localtime – If  enabled, vsftpd will display directory listings with the time in your local time zone. The default is to display GMT. The times returned by the MDTM FTP command are also affected by this option.
Default: NO”

After changing this variable as with any other vsftpd options, you have to restart the vsftpd service to activate the change.