Network interface bonding in RHEL4.0 – How to

Finally today I had implemented NIC bounding (bind both NIC so that it works as a single device). We have two Dell servers that need setup with Intel Dual Gig NIC. My idea is to improve performance by pumping out more data from both NIC without using any other method.

This box act as heavy duty ftp server. Each night I need to transfer over 200GB data from this box to another box. Therefore, the network would be setup is two servers on a switch using dual network cards. I am using Red Hat enterprise Linux version 4.0.

Linux allows binding multiple network interfaces into a single channel/NIC using special kernel module called bonding. According to official bonding documentation, “The Linux bonding driver provides a method for aggregating multiple network interfaces into a single logical “bonded” interface. The behavior of the bonded interfaces depends upon the mode; generally speaking, modes provide either hot standby or load balancing services. Additionally, link integrity monitoring may be performed.”

Setting up bounding is easy with RHEL v4.0.

Step #1: Create a bond0 configuration file

Red Hat Linux stores network configuration in /etc/sysconfig/network-scripts/ directory. First, you need to create bond0 config file:

# vi /etc/sysconfig/network-scripts/ifcfg-bond0
Append following lines to it:
DEVICE=bond0
IPADDR=192.168.1.20
NETWORK=192.168.1.0
NETMASK=255.255.255.0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
Replace above IP address with your actual IP address. Save file and exit to shell prompt.

Step #2: Modify eth0 and eth1 config files:

Open both configuration using vi text editor and make sure file read as follows for eth0 interface
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
Modify/append directive as follows:
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

Open eth1 configuration file using vi text editor:

# vi /etc/sysconfig/network-scripts/ifcfg-eth1
Make sure file read as follows for eth1 interface:
DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
Save file and exit to shell prompt.

Step # 3: Load bond driver/module

Make sure bonding module is loaded when the channel-bonding interface (bond0) is brought up. You need to modify kernel modules configuration file:
# vi /etc/modprobe.conf
Append following two lines:
alias bond0 bonding
options bond0 mode=balance-alb miimon=100
Save file and exit to shell prompt. You can learn more about all bounding options in kernel source documentation file (click here to read file online).

Step # 4: Test configuration

First, load the bonding module:

# modprobe bonding
Restart networking service in order to bring up bond0 interface:
# service network restart

Verify everything is working:
# less /proc/net/bonding/bond0
Output:

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:0c:29:c6:be:59

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:0c:29:c6:be:63

List all interfaces:

# ifconfig
Output:
bond0 Link encap:Ethernet HWaddr 00:0C:29:C6:BE:59
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:2804 errors:0 dropped:0 overruns:0 frame:0
TX packets:1879 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:250825 (244.9 KiB) TX bytes:244683 (238.9 KiB)

eth0 Link encap:Ethernet HWaddr 00:0C:29:C6:BE:59
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fec6:be59/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:2809 errors:0 dropped:0 overruns:0 frame:0
TX packets:1390 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:251161 (245.2 KiB) TX bytes:180289 (176.0 KiB)
Interrupt:11 Base address:0×1400

eth1 Link encap:Ethernet HWaddr 00:0C:29:C6:BE:59
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fec6:be59/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:258 (258.0 b) TX bytes:66516 (64.9 KiB)
Interrupt:10 Base address:0×1480

Now you have bond multiple network interfaces into a single channel (NIC).

Courtesy : http://www.cyberciti.biz

Upgrading perl 5.8.8 in C-Panel server

The version of perl (v5.8.7) is too old. There are known problems that cannot be worked around with this version of perl. It is HIGHLY recommended that you upgrade to v5.8.8 or later. Any module install failures should be ignored until perl has been upgraded as some modules will not be able to install with this version of perl.

You can ensure that each installed module gets carried over to the updated Perl build with the use of the “autobundle” CPAN feature.

You can create a bundle of the currently installed modules by executing the following while logged in via SSH as root:

perl -MCPAN -e ‘autobundle’

Once completed, you should see the following output before getting returned to the shell:

‘Wrote bundle file /home/.cpan/Bundle/Snapshot_2007_08_16_00.pm’

Once you’ve made note of this file name, you can proceed with the update.

On linux based systems, you should be able to update Perl using the installer provided at layer1.cpanel.net:

cd /root
wget http://layer1.cpanel.net/perl588installer.tar.gz
tar -zxf perl588installer.tar.gz
cd perl588installer
./install -optimize-memory

On FreeBSD based systems, you will need to install Perl from ports.

This will take a few minutes, so take a coffee break and check the status when you return. Once the update has completed, you can install all previously installed modules from the CPAN bundle by executing the following (with the bundle name adjusted to the name of the bundle generated earlier):

perl -MCPAN -e ‘install Bundle::Snapshot_2007_08_16_00′

This should install each of the modules present in the bundle, assuming there are no issues during the installation (dependencies, network, etc).

Once this has completed, execute the following to ensure that all modules required by cPanel are installed, and restart cPanel:

/usr/local/cpanel/bin/checkperlmodules

Monitoring Network Traffic Usage using Bandwidthd

It is important to know traffic usage of your client if you’re a Linux network administrator. You can monitor your client in text mode, graphic mode or html exported like mrtg, cacti or bandwidthd and one of my favorite bandwidth monitor is Bandwidthd.

You don’t need any database or snmp connection to monitor all of your client on bandwidthd, all you need just libcap, libpng, libgd and apache installed on your Linux system. And other good news is bandwidthd monitor all of your connected client per IP and per connection protocol.

Installing Bandwidthd

Prepare your Linux and download bandwidthd for Linux here. Next extract bandwidth using tar -zxvf command.

Goto extracted directory and type ./configure && make install to install bandwidth to your system.

Configuring Bandwidthd

By default all installed bandwidthd files placed on /usr/local/bandwidthd/folder. Now goto bandwidthd installed directory and CD to etc, you’ll find bandwidthd config file there. Open bandwidthd.conf using your favorite text editor like vi or nano and start edit bandwidthd config file suit your network.

Save your config and start bandwidthd using/usr/local/bandwidthd/bandwidthd. Put that command to your /etc/rc.localfile so bandwidthd can start on every time Linux boot.

Configuring Apache

You will can’t see your graphic report until you set/usr/local/bandwidthd/htdocs/ folder to set as apache virtual directory. Add below line to your apache config file.

Alias /bandwidthd “/usr/local/bandwidthd/htdocs”
<Directory “/usr/local/bandwidthd/htdocs”>
Order Allow,Deny
Allow from All
</Directory>
Save your work and restart apache. Next open your browser and point to http://yourlinuxserver/bandwidth.

Happy trying and good luck.

Courtesy:  http://infodotnet.blogspot.com

Remote Installation of Fedora Distributions Using PXE boot

If you want to deploy many machines, then it is a pain to go from machine to machine with 4 CDs. Like RIS (Remote Installation Service) in Windows, Fedora also offers you a similar remote installation facility via PXE LAN booting. For this, you will require a DHCP server, Apache and TFTP server running on Fedora.

Firstly, install Fedora completely. Then, on that machine, make a folder named  /Fedora on root and copy all the contents of the Fedora CDs in this folder. Remember that you are mounting the CDs and copying the contents and not just copying the ISOs. While copying the files from the CDs, you will be asked for permission to overwrite few files and folders.

Once you have created a copy of the CDs on the machine, you have to create a kick start file, which has answers to the questions asked during the installation process.

To make this file, launch ‘kickstart’ from Start>Systems, this will open a GUI Kickstart configuration interface.

Here, you can set pre-installation settings such as keyboard type, language, time zone, mouse, display, root password, etc. Fill all the entries according to your setup requirements and save the file. It saves a file with name ks.cfg.

Copy this file to the location where you have copied the Fedora2006 files from the CD.

Host installer
In order to remotely install Fedora via HTTP, you have to configure apache server to host the installer. To do this, launch Start>system>HTTP. This will open an interface to configure the apache web server. Here, select the main tab and give the IP address of the same machine, where you are hosting the apache server. Next, select the ‘virtual host’ tab and select add new host and double click the new virtual host you have created. This will open its properties dialog. Here, under basic setup set the ‘document root directory’ to the location where you copied the Fedora CDs.

In our case it is /fedora. Now, from the same properties window, click on the performance tab and add the directory of your Fedora installer that you have copied above. Once you are through with this, save the settings by clicking the Ok button. After this, start apache server by issuing this command.

#service httpd start

Now, open a web browser and check that the web server is working properly. Make sure it displays the directory structure of the Fedora installer folder on the web page.

Configuring TFTP Server
TFTP stands for Trivial File Transfer Protocol, a simpler form of the File Transfer Protocol (FTP).

The next step is to configure TFTP server on your installer server in such a way that it can remotely boot another PC over a network. In order to do this, open a terminal and issue the following commands.

# cp /pcqlinux/isolinux/* /tftpboot/linux-install/
# cp /tftpboot/linux-install/isolinux.cfg /tftpboot/linux-install/pxelinux.cfg/default

The above commands will copy all the boot files from the folder where you have dumped the entire Fedora CDs to the TFTP server.

Now open /tftpboot/ linux-install/pxelinux.cfg /default file in a text editor and change the following entries as follows

label linux
kernel vmlinuz
append initrd=initrd.img ramdisk_size=8192 s=http://192.168.3.1/pcqlinux/ks.cfg
label text
kernel vmlinuz
append initrd=initrd.img text ramdisk_size=8192 ks=http://192.168.3.1/pcqlinux/ks.cfg

(Here 192.168.3.1 is the IP address of the hosting server, where you have hosted the Fedora installer, you should change it according to your settings).

After this you have to enable the TFTP server so that the TFTP server

automatically gets started on booting the Fedora server. For doing this, run ‘setup’ command from the terminal. It will open a CLI interface, here select ‘Services’ and from the list select ‘tftp’ by pressing space bar key and click the Ok button to save the settings .

Configure DHCP server

Now, you have to configure the DHCP server on your installation server, so that the diskless clients can get IP addresses from the RIS server and remotely boot and start the Fedora installer. To do this open the /etc/dhcpd.conf file and add the following lines as shown below.

ddns-update-style
none;
default-lease-time
21600;
max-lease-time
21600;
option subnet-mask
255.255.255.0;
option broadcast-address
192.168.3.255;
option domain-name-servers
192.168.3.78; #<– RIS Server IP
option domain-name
“ris.pcquest.local”;
# <–domain name
option option-128 code 128 = string;
option option-129 code 129 = text;
subnet  192.168.3.0 netmask 255.255.255.0 {
range dynamic-bootp
192.168.3.10 192.168.3.253; # <– DHCP IP Ranage
filename
“/linux-install/pxelinux.0″;  #<- Boot image File

}
Restart the DHCP server.
# Service dhcpd restart

With this your Remote Installation server is ready.

Boot the client machines from the Remote Installation Server and you will get the Installer booting screen. Thereafter, and you can start the installation process on it.

Troubleshooting – Client not booting?

If your PC is not booting off the remote boot server, then two things could be wrong. Firstly, its network card may not be PXE boot enabled. If it is PXE enabled, check the BIOS to see whether the boot from network option is enabled

 

How to List the content of a tar file

You need to list the contents of a tar or tar.gz file on screen before extracting the all files.

Task: List the contents of a tar file

Use the following command:
$ tar -tvf file.tar
Task: List the contents of a tar.gz file

Use the following command:
$ tar -ztvf file.tar.gz
Task: List the contents of a tar.bz2 file

Use the following command:
$ tar -jtvf file.tar.bz2

Apache – “Client denied by server configuration” – Resolved

Having problems with displaying your site and getting error 403 in your web-browser?

does the log-file for apache errors contain lines like tis?
“client denied by server configuration: /path/to/files”

Then you probably have denied access to the directory in the httpd.conf file.

Allow access by adding:
<directory /path/to/files>
allow from all
</directory>

If your are using VirtualHosts then add the directory-block inside the <virtualhost> block.

SSH / SCP Password less Authentication

Type the below command in terminal

# ssh-keygen -t rsa

* This will generate your id_rsa and id_rsa.pub in the .ssh directory in your home directory

* copy the id_rsa.pub to the .ssh directory of the remote host you want to logon to as authorized_keys2

* If you have more than one host from which you want to connect to the remote host, you need to add the local host’s id_rsa.pub as one line in the authorized_keys2 file of the remote host command for the 1and1 servers is:

# scp .ssh/id_rsa.pub u35894953@217.160.226.69:./.ssh/authorized_keys2

How to remove csrsc.exe Virus in Windows

This was the error message faced by one of our readers that when he boots the PC up, the CSRCS.exe error message comes up on the screen.

csrsc.exe is a process which is registered as W32.Spybot.CF Virus. DO NOT confuse it with csrss.exe which is an important file used by Windows. The attackers of this virus can access our computer and gain access to some important data remotely.

Steps to remove this virus:

1.    Scan the system with a good and updated Anti Virus.

2.    Open Task Manager, locate this exe (csrcs.exe or csrsc.exe but not csrss.exe), and kill the process.

3.    Now type msconfig in the Run box, and then go to startup tab.

4.    Locate this exe file, if any, and then remove it from there as well.

5.    Now search the file in the C: drive.

6.    Permanently delete the file (csrcs.exe or csrsc.exe only) from the computer.

7.    Reboot the PC for changes to take place.

UPDATE

After doing the above steps, you need to clean the registry as well.

1. Navigate toHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\
2. On the right side, there is a key named “Shell”, it may be having a value “explorer.exe csrcs.exe”. Just modify it to delete the csrcs.exe from it (not explorer.exe). Restartthe computer

The virus should have gone.

FTP Jailing or Chroot users – Limit users to only their home directory Using VSFTP

Open vsftpd configuration file – /etc/vsftpd/vsftpd.conf

# vi /etc/vsftpd/vsftpd.conf

Made the Following changing in the File

chroot_list_enable=YES

chroot_list_file=/etc/vsftpd/vsftpd.chroot_list

chroot_local_user=YES

Save and close the file. Restart vsftpd.

# /etc/init.d/vsftpd restart

Now all users of VSFTPD/FTP will be limited to accessing only files in their own home directory.

They will not able to see /, /etc, /root and /tmp and all other directories.

This is an essential security feature.

Send Mail Postfix through Gmail’s SMTP on a Linux Box

After looking on the internet for awhile I finally found a decent guide on how to setup Gmail SMTP through postifx; however, after following the guide I found that it left parts out or things didn’t work quite the same on a Linux server. This guide is intended to get Gmail’s SMTP set up through postifx on a LTS Ubuntu server quickly and without too much information about other operating systems; although, you could probably adapt the guide to work on other systems.

Google’s Gmail service requires the protocols TLS and SASL2 to be built into Postfix. Luckily this is already done on the Ubuntu LTS Server.

In order to communicate with google we need to have Gmail’s certificate authority and we need to generate our own Certificate Authority (CA).

Step 1: Create a Certificate Authority

Since we will be creating temporary files and will want to delete them later, Change the directory to your home directory so we don’t forget to delete them later and leave what I call “mouse turds” laying around.
cd ~

Create the CA
$ /usr/lib/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)

Making CA certificate …
Generating a 1024 bit RSA private key
…….++++++
……………….++++++
writing new private key to ‘./demoCA/private/cakey.pem’
Enter PEM pass phrase: password
Verifying – Enter PEM pass phrase: password
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [US]:US
State or Province Name (full name) [New York]:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) []:Sanborn_Widgets

Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:Mark
Email Address []:username@gmail.com

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok

Step 2: Create a Server Certificate

Since these values have to match with the CA you just created. You may want to keep that output of what you just did to reference it for the next command. You can do this by opening another console or virtual terminal and switch back and forth between them.

openssl req -new -nodes -subj '/CN=domain.com/O=Sanborn_Widgets/C=US/ST=New York/L=New York/emailAddress=username@gmail.com' -keyout FOO-key.pem -out FOO-req.pem -days 3650

Step 3: Sign the Certificate

# openssl ca -out FOO-cert.pem -infiles FOO-req.pem
Using configuration from
/usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok

Then press y for anything else it asks.

Step 4: Copy the certificates to the Postfix folder

# cp demoCA/cacert.pem FOO-key.pem FOO-cert.pem /etc/postfix
# chmod 644 /etc/postfix/FOO-cert.pem /etc/postfix/cacert.pem
# chmod 400 /etc/postfix/FOO-key.pem

Gmail uses the Thawte Premium Server CA. You need to add this to the end of /etc/postfix/cacert.pem

-----BEGIN CERTIFICATE-----
MIIDJzCCApCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBzjELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2Vy
dmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t
MB4XDTk2MDgwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgc4xCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEdMBsG
A1UEChMUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMTGFRoYXd0ZSBQcmVtaXVtIFNl
cnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1zZXJ2ZXJAdGhhd3RlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0jY2aovXwlue2oFBYo847kkE
VdbQ7xwblRZH7xhINTpS9CtqBo87L+pW46+GjZ4X9560ZXUCTe/LCaIhUdib0GfQ
ug2SBhRz1JPLlyoAnFxODLz6FVL88kRu2hFKbgifLy3j+ao6hnO2RlNYyIkFvYMR
uHM/qgeN9EJN50CdHDcCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG
9w0BAQQFAAOBgQAmSCwWwlj66BZ0DKqqX1Q/8tfJeGBeXm43YyJ3Nn6yF8Q0ufUI
hfzJATj/Tb7yFkJD57taRvvBxhEf8UqwKEbJw8RCfbz6q1lu1bdRiBHjpIUZa4JM
pAwSremkrj/xw0llmozFyD4lt5SZu5IycQfwhl7tUCemDaYj+bvLpgcUQg==
-----END CERTIFICATE-----

Alternative Method

If you do not trust me or don’t feel comfortable copying CA certs from me you can get it from www.thawte.com/roots and download all of the certs from them. The file is called, ‘ThawtePremiumServerCA_b64.txt’.

The following code would put it in cacert.pem from the ThawtePremiumServerCA_b64.txt

cat ThawtePremiumServerCA_b64.txt >>cacert.pem

If you want to understand how this command works I recommend checking out, Getting Familiar with the Linux Command Line.

Step 5: Add these lines to the bottom of /etc/postfix/main.cf

Note: When I first added these lines I had a space in front of the first line which would give me errors when trying to run postfix. The only problem was the error was misleading saying there was something wrong with the line above steering me into the wrong direction and I ended up trouble shooting something that wasn’t broke. So make sure you have copied these lines exactly into the bottom of main.cf without and spaces in front of any of the lines.

## TLS Settings
#
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_cert_file = /etc/postfix/FOO-cert.pem
smtp_tls_key_file = /etc/postfix/FOO-key.pem
smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache
smtp_use_tls = yes
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem
smtpd_tls_key_file = /etc/postfix/FOO-key.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
#
## SASL Settings
# This is going in to THIS server
smtpd_sasl_auth_enable = no
# We need this
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtpd_sasl_local_domain = $myhostname
smtp_sasl_security_options = noanonymous
#smtp_sasl_security_options =
smtp_sasl_tls_security_options = noanonymous
smtpd_sasl_application_name = smtpd

Step 7: Create the transport file

# Contents of /etc/postfix/transport
#
# This sends mail to Gmail
gmail.com smtp:[smtp.gmail.com]:587
#

Step 8: Create the SASL password

Replace username/password with your actual username and password.

#contents of sasl_passwd
#
[smtp.gmail.com]:587 username@gmail.com:password

Step 9: Hash the password and transport files

postmap sasl_passwd && postmap transport

Step 10: Restart the postfix server and clean up

Enter the following command as root to restart postfix:
/etc/init.d/postfix restart

Go to your home directory where you made the temporary .pem files in step 1.
cd ~

Clean up the mouse turds!
rm FOO-req.pem FOO-cert.pem FOO-key.pem && rm -r demoCA/

Does it work?

Send a test email to yourself, replace username with your actual username. Note this is a test and it only tests to see if it WOULD send. You will not get an email in your Gmail inbox.
sendmail -bv username@gmail.com

Check to see if it went
cat /var/log/mail.log | tail

If everything went ok you will see something like this in the log
Oct 1 12:22:04 localhost postfix/smtp[21389]: 671AD676BF: to=, relay=smtp.gmail.com[123.233.169.109], delay=3, status=deliverable (delivery via smtp.gmail.com[123.233.169.109]: 250 2.1.5 OK)

If it didn’t work out you will see this in the log
Oct 1 12:21:57 localhost postfix/local[21381]: 4E5BA676BF: to=, orig_to=, relay=local, delay=0, status=undeliverable (delivery via local: unknown user: "user")

Alternative Method

After issuing the sendmail command you can check to see if it worked by checking your local email with any email client. I used mutt.

You can also check the email queue with
postqueue -p

And deleting all messages in queue with
postsuper -d ALL

If all goes well you should know have a working outgoing email server through Gmail’s SMTP. Now you can write scripts on your server to alert you of all sorts of things happening on your server.

Source: http://www.marksanborn.net/linux/send-mail-postfix-through-gmails-smtp-on-a-ubuntu-lts-server/