Webmail not loading

If Whm/Cpanel/Webmail is not loading in ssl mode (2087/2083/2096) then first you can try

httpd (stop/start/restart)

If it not works then https authentication is usually run by the stunnel for c-panel; and since the error is shown only when data transfer using stunnel is done; you can try a stunnel restart.

do the following:
===============
ps ax | grep stunnel
===============

you will get a pid for the current running stunnel. Kill it via:
===============
kill -9 pid
===============

now start stunnel: /usr/local/cpanel/etc/init/startstunnel
==============================================
then restart exim and cpanel via the “/etc/rc.d/init.d/” start/stop directives.

***************************************
OR simply

start stunnel: /usr/local/cpanel/etc/init/startstunnel

Write a message to login users through terminal

To write a message to users that have login, you can using the command write.
But before that, you need to check who is login, and which terminal he is login to, use command who.

Let say you was unable to call your friend, maybe he forgot to bring his cellphone and you know he is login to a linux server doing something, and you have permission to ssh to that particular server, then you can write him a message.

First, type:

who

who will list of all user have login and and login to which terminal, you will see something like pts/0, pts/1.

Example output:

aizatto pts/0 2007-03-10 02:21 (:0.0)

With the information, now you can write messages to the user aizatto.

write aizatto pts/0

After typing the command line above, you can start to type your messages. When you hit enter, you message will be send to that terminal. Terminate the write by ctrl+D.

You can cat a file and pipe to write command too.

cat memo.txt | write aizatto pts/0

You can broadcast your message to all login user with wall command. wall, write to all.

cat announcement.txt | wall

Or simply type wall, then start to write your message. For wall, the message will be send only after you hit ctrl+D. And the message will be send to all users that login including you.

Exim Cheatsheet

For more information on Exim cheat sheets see bradthemad.org

Here are some useful things to know for managing an Exim 4 server. This assumes a prior working knowledge of SMTP, MTAs, and a UNIX shell prompt.
Message-IDs and spool files

The message-IDs that Exim uses to refer to messages in its queue are mixed-case alpha-numeric, and take the form of: XXXXXX-YYYYYY-ZZ. Most commands related to managing the queue and logging use these message-ids.

There are three — count ’em, THREE — files for each message in the spool directory. If you’re dealing with these files by hand, instead of using the appropriate exim commands as detailed below, make sure you get them all, and don’t leave Exim with remnants of messages in the queue. I used to mess directly with these files when I first started running Exim machines, but thanks to the utilities described below, I haven’t needed to do that in many months.

Files in /var/spool/exim/msglog contain logging information for each message and are named the same as the message-id.

Files in /var/spool/exim/input are named after the message-id, plus a suffix denoting whether it is the envelope header (-H) or message data (-D).

These directories may contain further hashed subdirectories to deal with larger mail queues, so don’t expect everything to always appear directly in the top /var/spool/exim/input or /var/spool/exim/msglog directories; any searches or greps will need to be recursive. See if there is a proper way to do what you’re doing before working directly on the spool files.

Basic information

Print a count of the messages in the queue:

root@localhost# exim -bpc

Print a listing of the messages in the queue (time queued, size, message-id, sender, recipient):

root@localhost# exim -bp

Print a summary of messages in the queue (count, volume, oldest, newest, domain, and totals):

root@localhost# exim -bp | exiqsumm

Print what Exim is doing right now:

root@localhost# exiwhat

Test how exim will route a given address:

root@localhost# exim -bt alias@localdomain.com
user@thishost.com
< -- alias@localdomain.com router = localuser, transport = local_delivery root@localhost# exim -bt user@thishost.com user@thishost.com router = localuser, transport = local_delivery root@localhost# exim -bt user@remotehost.com router = lookuphost, transport = remote_smtp host mail.remotehost.com [1.2.3.4] MX=0

Run a pretend SMTP transaction from the command line, as if it were coming from the given IP address. This will display Exim's checks, ACLs, and filters as they are applied. The message will NOT actually be delivered.

root@localhost# exim -bh 192.168.11.22

Display all of Exim’s configuration settings:

root@localhost# exim -bP

Searching the queue with exiqgrep

Exim includes a utility that is quite nice for grepping through the queue, called exiqgrep. Learn it. Know it. Live it. If you’re not using this, and if you’re not familiar with the various flags it uses, you’re probably doing things the hard way, like piping `exim -bp` into awk, grep, cut, or `wc -l`. Don’t make life harder than it already is.

First, various flags that control what messages are matched. These can be combined to come up with a very particular search.

Use -f to search the queue for messages from a specific sender:

root@localhost# exiqgrep -f [luser]@domain

Use -r to search the queue for messages for a specific recipient/domain:

root@localhost# exiqgrep -r [luser]@domain

Use -o to print messages older than the specified number of seconds. For example, messages older than 1 day:

root@localhost# exiqgrep -o 86400 [...]

Use -y to print messages that are younger than the specified number of seconds. For example, messages less than an hour old:

root@localhost# exiqgrep -y 3600 [...]

Use -s to match the size of a message with a regex. For example, 700-799 bytes:

root@localhost# exiqgrep -s '^7..$' [...]

Use -z to match only frozen messages, or -x to match only unfrozen messages.

There are also a few flags that control the display of the output.

Use -i to print just the message-id as a result of one of the above two searches:

root@localhost# exiqgrep -i [ -r | -f ] ...

Use -c to print a count of messages matching one of the above searches:

root@localhost# exiqgrep -c ...

Print just the message-id of the entire queue:

root@localhost# exiqgrep -i

Managing the queue

The main exim binary (/usr/sbin/exim) is used with various flags to make things happen to messages in the queue. Most of these require one or more message-IDs to be specified in the command line, which is where `exiqgrep -i` as described above really comes in handy.

Start a queue run:

root@localhost# exim -q -v

Start a queue run for just local deliveries:

root@localhost# exim -ql -v

Remove a message from the queue:

root@localhost# exim -Mrm [ ... ]

Freeze a message:

root@localhost# exim -Mf [ ... ]

Thaw a message:

root@localhost# exim -Mt [ ... ]

Deliver a message, whether it’s frozen or not, whether the retry time has been reached or not:

root@localhost# exim -M [ ... ]

Deliver a message, but only if the retry time has been reached:

root@localhost# exim -Mc [ ... ]

Force a message to fail and bounce as “cancelled by administrator”:

root@localhost# exim -Mg [ ... ]

Remove all frozen messages:

root@localhost# exiqgrep -z -i | xargs exim -Mrm

Remove all messages older than five days (86400 * 5 = 432000 seconds):

root@localhost# exiqgrep -o 432000 -i | xargs exim -Mrm

Freeze all queued mail from a given sender:

root@localhost# exiqgrep -i -f luser@example.tld | xargs exim -Mf

View a message’s headers:

root@localhost# exim -Mvh

View a message’s body:

root@localhost# exim -Mvb

View a message’s logs:

root@localhost# exim -Mvl

Add a recipient to a message:

root@localhost# exim -Mar

[
... ]


Edit the sender of a message:

root@localhost# exim -Mes

Access control

Exim allows you to apply access control lists at various points of the SMTP transaction by specifying an ACL to use and defining its conditions in exim.conf. You could start with the HELO string.

# Specify the ACL to use after HELO
acl_smtp_helo = check_helo

# Conditions for the check_helo ACL:
check_helo:

deny message = Gave HELO/EHLO as "friend"
log_message = HELO/EHLO friend
condition = ${if eq {$sender_helo_name}{friend} {yes}{no}}

deny message = Gave HELO/EHLO as our IP address
log_message = HELO/EHLO our IP address
condition = ${if eq {$sender_helo_name}{$interface_address} {yes}{no}}

accept

NOTE: Pursue HELO checking at your own peril. The HELO is fairly unimportant in the grand scheme of SMTP these days, so don’t put too much faith in whatever it contains. Some spam might seem to use a telltale HELO string, but you might be surprised at how many legitimate messages start off with a questionable HELO as well. Anyway, it’s just as easy for a spammer to send a proper HELO than it is to send HELO im.a.spammer, so consider yourself lucky if you’re able to stop much spam this way.

Next, you can perform a check on the sender address or remote host. This shows how to do that after the RCPT TO command; if you reject here, as opposed to rejecting after the MAIL FROM, you’ll have better data to log, such as who the message was intended for.

# Specify the ACL to use after RCPT TO
acl_smtp_rcpt = check_recipient

# Conditions for the check_recipient ACL
check_recipient:

# [...]

drop hosts = /etc/exim_reject_hosts
drop senders = /etc/exim_reject_senders

# [ Probably a whole lot more... ]

This example uses two plain text files as blacklists. Add appropriate entries to these files – hostnames/IP addresses to /etc/exim_reject_hosts, addresses to /etc/exim_reject_senders, one entry per line.

It is also possible to perform content scanning using a regex against the body of a message, though obviously this can cause Exim to use more CPU than it otherwise would need to, especially on large messages.

# Specify the ACL to use after DATA
acl_smtp_data = check_message

# Conditions for the check_messages ACL
check_message:

deny message = "Sorry, Charlie: $regex_match_string"
regex = ^Subject:: .*Lower your self-esteem by becoming a sysadmin

accept

Fix SMTP-Auth for Pine

If pine can’t use SMTP authentication on an Exim host and just returns an “unable to authenticate” message without even asking for a password, add the following line to exim.conf:

begin authenticators

fixed_plain:
driver = plaintext
public_name = PLAIN
server_condition = "${perl{checkuserpass}{$1}{$2}{$3}}"
server_set_id = $2
> server_prompts = :

This was a problem on CPanel Exim builds awhile ago, but they seem to have added this line to their current stock configuration.

Log the subject line

This is one of the most useful configuration tweaks I’ve ever found for Exim. Add this to exim.conf, and you can log the subject lines of messages that pass through your server. This is great for troubleshooting, and for getting a very rough idea of what messages may be spam.

log_selector = +subject

Reducing or increasing what is logged.

Disable identd lookups

Frankly, I don’t think identd has been useful for a long time, if ever. Identd relies on the connecting host to confirm the identity (system UID) of the remote user who owns the process that is making the network connection. This may be of some use in the world of shell accounts and IRC users, but it really has no place on a high-volume SMTP server, where the UID is often simply “mail” or whatever the remote MTA runs as, which is useless to know. It’s overhead, and results in nothing but delays while the identd query is refused or times out. You can stop your Exim server from making these queries by setting the timeout to zero seconds in exim.conf:

rfc1413_query_timeout = 0s

Disable Attachment Blocking

To disable the executable-attachment blocking that many Cpanel servers do by default but don’t provide any controls for on a per-domain basis, add the following block to the beginning of the /etc/antivirus.exim file:

if $header_to: matches "example.com|example2.com"
then
finish
endif

It is probably possible to use a separate file to list these domains, but I haven’t had to do this enough times to warrant setting such a thing up.

Searching the logs with exigrep

The exigrep utility (not to be confused with exiqgrep) is used to search an exim log for a string or pattern. It will print all log entries with the same internal message-id as those that matched the pattern, which is very handy since any message will take up at least three lines in the log. exigrep will search the entire content of a log entry, not just particular fields.

One can search for messages sent from a particular IP address:

root@localhost# exigrep '< = .* [12.34.56.78] ' /path/to/exim_log

Search for messages sent to a particular IP address:

root@localhost# exigrep '=> .* [12.34.56.78]' /path/to/exim_log

This example searches for outgoing messages, which have the “=>” symbol, sent to “user@domain.tld”. The pipe to grep for the “< =" symbol will match only the lines with information on the sender - the From address, the sender's IP address, the message size, the message ID, and the subject line if you have enabled logging the subject. The purpose of doing such a search is that the desired information is not on the same log line as the string being searched for.
root@localhost# exigrep ‘=> .*user@domain.tld’ /path/to/exim_log | fgrep ‘< ='

Generate and display Exim stats from a logfile:

root@localhost# eximstats /path/to/exim_mainlog

Same as above, with less verbose output:

root@localhost# eximstats -ne -nr -nt /path/to/exim_mainlog

Same as above, for one particular day:

root@localhost# fgrep YYYY-MM-DD /path/to/exim_mainlog | eximstats

Bonus!

To delete all queued messages containing a certain string in the body:

root@localhost# grep -lr 'a certain string' /var/spool/exim/input/ | sed -e 's/^.*/([a-zA-Z0-9-]*)-[DH]$/1/g' | xargs exim -Mrm

Note that the above only delves into /var/spool/exim in order to grep for queue files with the given string, and that’s just because exiqgrep doesn’t have a feature to grep the actual bodies of messages. If you are deleting these files directly, YOU ARE DOING IT WRONG! Use the appropriate exim command to properly deal with the queue.

If you have to feed many, many message-ids (such as the output of an `exiqgrep -i` command that returns a lot of matches) to an exim command, you may exhaust the limit of your shell’s command line arguments. In that case, pipe the listing of message-ids into xargs to run only a limited number of them at once. For example, to remove thousands of messages sent from joe@example.com:

root@localhost# exiqgrep -i -f '' | xargs exim -Mrm

Speaking of “DOING IT WRONG” — Attention, CPanel forum readers

I get a number of hits to this page from a link in this post at the CPanel forums. The question is:

Due to spamming, spoofing from fields, etc., etc., etc., I am finding it necessary to spend more time to clear the exim queue from time to time. […] what command would I use to delete the queue

The answer is: Just turn exim off, because your customers are better off knowing that email simply isn’t running on your server, than having their queued messages deleted without notice.

Or, figure out what is happening. The examples given in that post pay no regard to the legitimacy of any message, they simply delete everything, making the presumption that if a message is in the queue, it’s junk. That is total fallacy. There are a number of reasons legitimate mail can end up in the queue. Maybe your backups or CPanel’s “upcp” process are running, and your load average is high — exim goes into a queue-only mode at a certain threshold, where it stops trying to deliver messages as they come in and just queues them until the load goes back down. Or, maybe it’s an outgoing message, and the DNS lookup failed, or the connection to the domain’s MX failed, or maybe the remote MX is busy or greylisting you with a 4xx deferral. These are all temporary failures, not permanent ones, and the whole point of having temporary failures in SMTP and a mail queue in your MTA is to be able to try again after awhile.

Exim already purges messages from the queue after the period of time specified in exim.conf. If you have this value set appropriately, there is absolutely no point in removing everything from your queue every day with a cron job. You will lose legitimate mail, and the sender and recipient will never know if or why it happened. Do not do this!

If you regularly have a large number of messages in your queue, find out why they are there. If they are outbound messages, see who is sending them, where they’re addressed to, and why they aren’t getting there. If they are inbound messages, find out why they aren’t getting delivered to your user’s account. If you need to delete some, use exiqgrep to pick out just the ones that should be deleted.
Reload the configuration

After making changes to exim.conf, you need to give the main exim pid a SIGHUP to re-exec it and have the configuration re-read. Sure, you could stop and start the service, but that’s overkill and causes a few seconds of unnecessary downtime. Just do this:

root@localhost# kill -HUP `cat /var/spool/exim/exim-daemon.pid`

You should then see something resembling the following in exim_mainlog:

pid 1079: SIGHUP received: re-exec daemon
exim 4.52 daemon started: pid=1079, -q1h, listening for SMTP on port 25 (IPv4)

How to send email from the Linux command line

MAIL

First run a quick test to make sure the “sendmail” application is installed and working correctly. Execute the following command, replacing “you@youremailid.com” with your e-mail address.

# mail -s “Hello world” you@youremailid.com

Hit the return key and you will come to a new line. Enter the text “This is a test from my server”. Follow up the text by hitting the return key again. Then hit the key combination of Control+D to continue. The command prompt will ask you if you want to mark a copy of the mail to any other address, hit Control+D again. Check your mailbox. This command will send out a mail to the email id mentioned with the subject, “Hello world”.

To add content to the body of the mail while running the command you can use the following options. If you want to add text on your own:

# echo “This will go into the body of the mail.” | mail -s “Hello world” you@youremailid.com

And if you want mail to read the content from a file:

# mail -s “Hello world” you@youremailid.com < /home/calvin/application.log Some other useful options in the mail command are: -s subject (The subject of the mail) -c email-address (Mark a copy to this “email-address”, or CC) -b email-address (Mark a blind carbon copy to this “email-address”, or BCC) Here’s how you might use these options: # echo “Welcome to the world of Calvin n Hobbes” | mail -s “Hello world” calvin@cnh.com -c hobbes@cnh.com -b susie.derkins@cnh.com

Anonymous SSH Sessions With TOR

OpenSSH is a great means to protect your connection from being sniffed by others. However, this isn’t always enough. Simply proving that you connected to a server is enough to get incriminated. Unfortunately, SSH doesn’t provide a native way to obfuscate to whom it connects. Instead, a proxy server can be set up. And this is where TOR comes to play. This howto covers installing TOR on a Debian based system and setting up SSH to use TOR.

Installing TOR

First you should to add the TOR repository to your system. It’s only necessary if there’s no package in the default repositories.

Add the following line to your /etc/apt/sources.list file. You have to replace lenny with your distribution.

deb http://mirror.noreply.org/pub/tor lenny main

To use this repository without problems, you have to add the PGP key to your system.

apt-key adv –recv-keys –keyserver subkeys.pgp.net 0x94C09C7F

Update your repositories and install TOR.

apt-get update && apt-get install -y tor

If you want to use TOR with OpenSSH, you have to install another program called connect-proxy.

apt-get install -y connect-proxy

Setup OpenSSH to use TOR for all connections

However, this is not recommended, but here is how it works.

Add the following block to the top of your ~/.ssh/config file.

Host *
CheckHostIP no
Compression yes
Protocol 2
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p

The command line syntax won’t change at all.

Set up OpenSSH to use TOR for a specific connection

I recommend using TOR only for a specific connection. All other connections won’t be affected.

Add this block to your ~/.ssh/config. You have to replace mydomain with the host domain name or IP address and myaccount with your user name.

Host mydomain
HostName mydomain.com
User myaccount
CheckHostIP no
Compression yes
Protocol 2
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p

Set up OpenSSH to use TOR for a bunch of connections

Instead of setting up TOR for every single connections, you can do this for a bunch of connections at once. Following example shows how it works.

Host anon_*
CheckHostIP no
Compression yes
Protocol 2
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p
Host anon_mydomain
HostName mydomain.com
User myaccount
Host anon_mydomain2
HostName mydomain2.com
User myaccount
Port 980

This way you know exactly if you’re using TOR or not.

Conclusion

It is very simple to anonymize your SSH sessions if you know what you’re doing. I’ve written this tutorial for legal purposes only. Using this is your own risk.

Schedule a Tweet with One Comnand in Linux

Ever want to schedule a tweet to go out at the same time an article is published or an event is started? Want to do it without signing up to a service or some other complicated task? Well this post is for you. I am going to show you how to schedule a tweet from the command line in one line of code. You can schedule the tweet to take place ten minutes from now, 14 days, or whenever you wish.

Twitter allows programmers and developers to interact with its service using its API. By sending small bits of XML code or POST data we can send updates or get our friend’s feeds. Fortunately Linux has some tools available to it that make this job easy.

To send a tweet from the Linux console all you have to do is send a small snippit of code through curl like:

curl -u email:password -d status=”What is everyone’s plan this weekend?” http://twitter.com/statuses/update.xml

To make it automated one time we use the ‘at‘ command.

Suppose we want to issue a tweet out tomorrow morning at 5:00am when our post is released. To do this we would issue the following command:

at 5am tomorrow

At this point you will be prompted with the at console. This is so you can execute multi-line commands.

at-terminal

Type the following replacing email and password with your own.

curl -u email:password -d status=”What is everyone’s plan this weekend?” http://twitter.com/statuses/update.xml

Then hit enter. To tell at that you are now finished writing commands do, ctrl+d

To see the current queue just type:

atq

If you made a mistake you can remove a task by id:

atrm 6

Blocking SSH probing IPs using a simple script

(from tuxopia.net)

I was troubled by the fact that my server was constantly being bombarded with SSH probes for as long as 1 to 2 hours at a stretch. Although the SSH daemon configuration has been tuned for security like disabling root access, allowing only a certain list of users, etc., a continuous SSH probe is still disturbing. I could block all other IPs for SSH access except for the ones that I use, but who knows where I will be when I need to SSH to my machine? I could be on any where. So the solution, I found was to just block SSH access to IPs that were violating my server’s and my peace. Since, I know that many of you out there have seen such attacks in your logs, I will share the script with you and a short explanation of how it works.
The Logic

Whenever an invalid ssh login appears you usually get a log message like

May 3 13:21:44 bell sshd[11909]: Failed password for invalid user root from 90.228.208.201 port 59948 ssh2

So we need to grep the lines from the log that have “Failed Password” in them. This can be done by

grep “Failed Password” /var/log/messages

Now that we have the lines we can grab the IP. Note that the IP is the 4th item from the end of line. To grab it we will pipe the output of previous command to awk.

grep “Failed Password” /var/log/messages |awk ‘{a=NF-3; print $a}’

Unfortunately this gives us duplicate IPs as well. we need to count how many times each IP has failed, since even our own IP may be in the list. Chances are legitimate users could be bloked too. So we need a count. we can do this using uniq command. Also for sake of redability lets sort it numerically and remove the spaces at the beginning of the line we get with output of uniq.

grep ‘Failed password’ /var/log/messages | awk ‘{ a=NF-3; print $a}’ |uniq -c| sed ‘s/^ *//’ | sort -n

Once we have got this it is only a matter of checking if each IP which is above the bad countlevel exists in /etc/hosts.deny and add the ones that are not.
The Script

Compiling all this together we have our bash script:

#!/bin/bash
AWK=/bin/awk
SORT=/bin/sort
GREP=/bin/grep
UNIQ=/bin/uniq
SED=/bin/sed
LOGFILE=/var/log/messages
BADCOUNT=”5″

$GREP ‘Failed password’ $LOGFILE | $AWK ‘{ a=NF-3; print $a}’ | $UNIQ -c| $SED ‘s/^ *//’| $SORT -n | while read i
do
COUNT=`echo $i | cut -d ” ” -f1`
IP=`echo $i | cut -d ” ” -f2`
INLIST=`$GREP $IP /etc/hosts.deny | $GREP sshd`
if [ -z “$INLIST” ] then
if [ “$COUNT” -ge “$BADCOUNT” ] then
echo “sshd: $IP” >> /etc/hosts.deny
fi
fi
done

Since, I will be away for a month, I decided to add this to cron as well running every minute every hour, every day. So the cron entry reads

* * * * * /root/bin/ssh-block.sh 1> /dev/null

Note that although this will block the IP from making yet another SSH probe, the machine will be able to make probes for about a minute before it is blocked. So you need to be sure to strengthen your SSHD configuration.

Hope this helps you guys.

NOTE: The script is a modified version from a script I found on Novel’s site http://www.novell.com/coolsolutions/tools/19769.html My editted version removes one of the vulnerabilty of the Novel script that would allow an attacker to log inject an IP. So the credit for the original script goes to the original author.
Bookmark/Search this post with:

Remove extra virtual terminals

Virtual terminals are a good tool to have—they offer a last-ditch escape to command line for a chance to fix things in a crashing system. But many Linux systems come with six of them enabled, which isn’t usually necessary. You can usually disable five of them with few consequences. If you’re using Gutsy, open a terminal and type in the following commands:

cd /etc/event.d
sudo mv tty3 tty3.bak
sudo mv tty4 tty4.bak

… and so on, through the tty6 file. If you’re still on Feisty or other Linux distros, you’ll likely have to edit the file in /etc/inittab and add a # character in front of the lines ending with tty3, tty4 and the like.

How to change your default editor -Debian/Ubuntu

Debian and Ubuntu uses for visudo, crontab and other similar applications the default text editor, you want to change it use the update-alternatives command.

It is as easy as, run this on a terminal window.

sudo update-alternatives –config editor

The options in my Debian system are:

There are 6 alternatives which provide `editor’.

Selection Alternative
———————————————–
1 /bin/ed
2 /bin/nano
3 /usr/bin/vim.tiny
*+ 4 /usr/bin/vim.gnome
5 /usr/bin/mcedit-debian
6 /usr/bin/emacs21

Press enter to keep the default[*], or type selection number:

The + sign denotes the default option, and the * sign denotes the actual selection, to change from vim to nano, just press 2 in this example and the ENTER.

Now all applications that uses an editor will use the new default one.