Linux technical support, Technical Blogs, Cheap dedicated server support, Cheap linux dedicated server support, Cheap windows dedicated server, Dedicated server support, Data center Operation, System Administration, Bash and perl scripts for server maintainance

FTP have two types :
1. Active FTP and
2. Passive FTP.

Ftp session is a TCP session made up of two steps, the first connection on TCP port 21 known as a control connection and the second connection known as a data connection usually on TCP port 20. The issue arises when the second port is selected at random by applications and this data port is not always port 20.

Active FTP session:
In an Active FTP session the following steps occurs.
==> The client initiates the session from a random source port (Port X >1023) to the FTP server on TCP port 21.
2. The TCP Handshake will occur.
3. The client then sends the “FTP” port command from a source port (Port X+1) to the FTP server.
4.The server will then connect back from its local data port 20 to the client port (X+1)

Firewall issues for Active FTP session occurs on the client side as the FTP server tries to connect back to the client on TCP port 20 which is often blocked by the client Firewall.

Passive FTP Session:
In a passive FTP session the following steps occurs.
1. The client initiates the session from a random source port (Port X >1023) to the FTP server on TCP port 21.
2. The TCP Handshake will occur.
3. The client then sends the “PASV” port command from a source port (Port X+1) to the FTP server.
4. The server will then open one of its random ports (X >1023) and send this port X back to the client.
5. The client will then perform data transfer from its source port (PortX+1) to the FTP server port X.

Firewall issues for Passive FTP session occurs on the server side as the FTP server requires connection to a random data port instead of port 20 and the server side firewall will block this traffic.

kill -HUP 1721
Stops, then restarts process 1721. This is usually done when a process is not working properly or the configuration files for that process have been changed. This command sends the HUP signal to the process which means hangup. This signal can be caught by the process.

killall -HUP myprint
Restarts any process with the name “myprint”.

Greetings!

If tomcat / java using too much resources on your box then USE this tweak.

#!/bin/bash

mask=7f

# Sleep for 5 minutes; worst-case scenario for process to start up the process
sleep 10
process_id=`ps -ef | grep $instance | grep java | grep Bootstrap | awk ‘{print $2}’`
taskset -p $mask $process_id

Need to add it to startup.sh for relevant tomcat instances in startup.sh:

…
…
“Setting Tomcat CPU core affinity ….”
nohup /appl/share/newsreader/scripts/set_affinity.sh &

exec “$PRGDIR”/”$EXECUTABLE” start “$@”

IF thats java command thats not working for you then

to use Java from your own user logins will need to edit the file /home/<username>/.bash_profile and add/change the following lines:

PATH=$PATH:/usr/java/jdk1.5.0_09/bin:$HOME/bin

JAVA_HOME=/usr/java/jdk1.5.0_09

Save and exit from this session and try logging in again.

You can also run source ~/.bash_profile to make the changes effective (without logging off)

Hello,

By default dns first resolves from /etc/hosts file and then from dns. If you want to do some changes for this then you need to do that from

/etc/nssswitch file.

You need to change the

hosts files dns

to

hosts dns files

Cheers 

Greetings!

Officially know as “segmentation fault”, means that the program accessed a memory location that was not assigned. That’s usually a bug in the program. So if you’re writing your own program, that’s the most likely cause. However, this FAQ will concentrate on the possibilities besides that.

It means “Illegal Operation Error” in windows terms. Most likely there is nothing wrong with your installation, your compiler or kernel. It very likely has something to do with your hardware. There are a variety of subsystems that can be wrong, and there are a variety of ways to fix it.

Hello,

If you want to denugh the core apache errors then you need to run apache in debug mode. You can run that with following command.
httpd -x
./apachectl restart

Do troubleshooting then depending on the error message you get.

Cheers!

Greetings!

We ran into a problem with the dreaded “Too many open files” error message in Apache which caused it to crash and left it in a non-startable state.

We fixed the problem by editing the /etc/security/limits.conf on a RHEL box, saving and restarting apache.

Code:

nano -w /etc/security/limits.conf

Change (or add) the last two lines

Code:

* soft nofile 32768
* hard nofile 32768

Code:

/sbin/service httpd restart

Hello,

Lately I have been seeing quite a few problems with users not receiving e-mail when a mail server is using sender callouts or sender callbacks.I have been experiencing this problem with the hosting companies that I am associated with. I am also seeing similar reports through various support forums that I frequent, where other users are having this problem. Through my investigations, most of these are a problem caused by the sender that is sending out the message. Larger companies are insisting on sending out newsletter and other announcements from invalid e-mail addresses, which is causing the sender callout to fail.

Lately I have been seeing quite a few problems with users not receiving e-mail when a mail server is using sender callouts or sender callbacks. I have been experiencing this problem with the hosting companies that I am associated with. I am also seeing similar reports through various support forums that I frequent, where other users are having this problem. Through my investigations, most of these are a problem caused by the sender that is sending out the message. Larger companies are insisting on sending out newsletter and other announcements from invalid e-mail addresses, which is causing the sender callout to fail.

To understand this problem, lets take a look at how sender callouts work. An e-mail transaction takes place between two computer systems. The computer system that is receiving the message is called the server. Likewise, the computer system that is sending the message is called the client. So another words, if you are sending out a message through your mail server to a gmail.com e-mail address, then your mail server will act as the Client sending a message to the Gmail mail servers, acting as the Server.

Basically an e-mail transaction will look something like this:

1. Client connects to Server
2. Server responds with a 220 code, advertising its name
3. Client sends a HELO or EHLO command with its hostname, introducing itself to the Server
4. Server accepts this commands with a 250 code
5. Client tells the server who the message is from, this is the envelope-sender
6. Server accepts this with a 250 code
7. Client sends who the message is being sent to, this is the envelope-recipient
8. Server accepts this with a 250 code

This is the end of the recipient stage of the e-mail transaction. The Client next sends a DATA command, which tells the server that the next lines being sent are the actual e-mail message.

Let’s take a look at a real life example of this order. To help illustrate this, I have color coded the text. Text that is in blue refers to responses from the Server. Text that is in red refers to data that is being sent by the Client.

E-mail Transaction
Connected to gmail-smtp-in.l.google.com (209.85.133.27).
Escape character is ‘^]’.
220 mx.google.com ESMTP d25si10513773and
EHLO myhostname.com
250-mx.google.com at your service, [xx.xx.xx.xx]
250-SIZE 28311552
250-8BITMIME
250 ENHANCEDSTATUSCODES
MAIL FROM:
250 2.1.0 OK
RCPT TO:
250 2.1.5 OK

Now lets split this up into their corresponding descriptions. It just follows in order.

1. Client connects to Server
Connected to gmail-smtp-in.l.google.com (209.85.133.27).
Escape character is ‘^]’.

2. Server responds with a 220 code, advertising its name
220 mx.google.com ESMTP d25si10513773and

3. Client sends a HELO or EHLO command with its hostname, introducing itself to the Server
EHLO myhostname.com

4. Server accepts this commands with a 250 code
250-mx.google.com at your service, [xx.xx.xx.xx]
250-SIZE 28311552
250-8BITMIME
250 ENHANCEDSTATUSCODES

5. Client tells the server who the message is from, this is the envelope-sender
MAIL FROM:

6. Server accepts this with a 250 code
250 2.1.0 OK

7. Client sends who the message is being sent to, this is the envelope-recipient
RCPT TO:

8. Server accepts this with a 250 code
250 2.1.5 OK

Now lets take a look at an e-mail transaction for a server that uses sender callouts, whenever a bad envelope-sender is used.

E-mail Transaction using sender callout and bad envelope-sender
Trying xx.xx.xx.xx…
Connected to server.mailserver.com (xx.xx.xx.xx).
Escape character is ‘^]’.
220-server.mailserver.com ESMTP Exim 4.66 #1 Sat, 30 Jun 2007 13:56:24 -0400
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
EHLO client.mailserver.com
250-server.mailserver.com Hello client.mailserver.com [yy.yy.yy.yy]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
MAIL FROM:
250 OK
RCPT TO:
550-Verification failed for
550-Called: zz.zz.zz.zz
550-Sent: RCPT TO:
550-Response: 550-”The recipient cannot be verified. Please check all recipients of this
550-550 message to verify they are valid.”
550 Sender verify failed

Here you see that the verification of the badaddress@myserver.com e-mail address failed. Values have been obfuscated for privacy reasons. In this example the Server is using sender callouts to verify the validity of the envelope-senders. After the line RCPT TO: , the Server in this instance attempts to send a message back to badaddress@myserver.com which will determine whether or not that address is valid. If its valid, the server will want to accept mail for that address. If it is not valid, the server won’t recognize it. A sender callout transaction attempt looks like:

Sender Callout Attempt
Connected to client.mailserver.net (zz.zz.zz.zz).
Escape character is ‘^]’.
220-client.mailserver.net ESMTP Exim 4.66 #1 Sat, 30 Jun 2007 14:05:25 -0400
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
EHLO server.mailserver.net
250-client.mailserver.net Hello server.mailserver.net [xx.xx.xx.xx]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
MAIL FROM: <>
250 OK
RCPT TO:

At this point the mail server will either report a 250 code if the e-mail address is valid. If it is not valid, another, non 200 level return code will be given. This way you know that the e-mail address is either valid and accepting messages or invalid and not accepting any messages.

Response if badaddress@myserver.com is a valid e-mail address on the server.
250 Accepted

Response if badaddress@myserver.com is not a valid e-mail address, thus failing the callout
550-”The recipient cannot be verified. Please check all recipients of this
550 message to verify they are valid.”

Basically, think of it this way. If a Server is using sender callouts to verify the instance of a sender, in the E-mail Transaction using sender callout and bad envelope-sender example after the Client sends RCPT TO: the Server, in the background, performs the sender callout as described in the example labled Sender Callout Attempt. The response from Sender Callout Attempt has a deciding factor in how the Server will respond in E-mail Transaction using sender callout and bad envelope-sender.

Null Sender

In this example of the Sender Callout Attempt notice that the MAIL FROM line, MAIL FROM: <>. The <> refers to the null sender or the empty sender, or sometime called an empty return path. This is because there is no e-mail address listed between the less-than and greater-than symbols.

Not all sender callouts use the null sender, although it is preferred. However, not all servers will accept mail from the null sender. If a mail server is not accepting mail from the null sender, then this can also cause incoming messages to be rejected by your server. Not supporting the null sender is in violation of RFC standards. This is highlighted in the RFC 1123 description from RFC Ignorant.

You also have large corporations who insist on sending out newsletters and other e-mail messages from addresses that do not accept messages. Technically, there is nothing wrong with this. But in my opinion, common sense tells you that if you are going to send out an e-mail messages from jason@something.com, then jason@something.com better accept incoming mail messages. If commcast.net does not want to read the messages sent to jason@something.com, then they should configure jason@something.com to immediately delete messages upon arrival. This is just my opinion regarding this issue, but good luck trying to get large corporations to understand this. If someone can explain to me why its reasonable for someone to send out a legitimate e-mail message using an envelope-sender that does not also accept mail, then I will listen. I just don’t know of a valid reason at this time, other than technically there is no rule that says you can’t.

If people are writing addresses on your server and receiving messages saying the sender callout failed. Then it either means that their server, the server that is handling mail for the domain from which they are writing the message from, is not handling the null sender properly, they are not sending out e-mail from a valid e-mail address, or there is a connection problem or issue that is preventing your server from contacting their mail server and causing the callout to fail.

If you are going to send out mail from an e-mail address then you need to configure that e-mail address to also accept e-mail. If you do not want to bother with collecting mail sent to that e-mail address, then configure that e-mail address to immediately delete any messages sent to it. This can be done by redirecting the messages to /dev/null on Linux systems. I don’t have a lot of experience with different MTAs. I know with exim, specifically cPanel’s rendition of exim, you would just set up an e-mail forwarder for that specific address and forward it to :blackhole: which send messages to that address into an endless oblivion. The valiases file for that domain would like:

Exim valiases file illustrating a jason address
jason@something.com: :blackhole:

This way, I can send out an e-mail message using jason@something.com as my envelope-sender. If a server is using sender callouts, this e-mail address will still return as valid. If someone tries to send me a message at jason@something.com, my mail server accepts the message, but just immediately deletes it. I can’t speak for other MTAs, but I am almost certain that this task can be accomplished with virtually any MTA.

Hope this helps.
Regards,
Jason

Hi.

Check if you have all 3 rpms of gcc installed correctly there or not by using following command.

# rpm -qa |grep gcc
libgcc-3.4.6-8
gcc-3.4.6-8
gcc-c++-3.4.6-8
#
If it is there then you need to reinstall that again by downloading the CORRECT rpm from your source OS developer’s site.
Download it and reinstall it by using following command.

rpm -ivh rpmname.rpm –force

Thats it.
Regards,
Jason