Archive for the ‘Linux’ Category.

ProcmailRC recipes

Sending an auto reply while on vacation

PATH=/bin:/usr/bin:/software/common/bin
MAILDIR=$HOME/mailroom #you’d better make sure it exists
LOGFILE=$MAILDIR/procmail.log #recommended

# Vacation work-alike (3/6/98) Accurso
#
# This is an annotated and slightly modified version of the
# vacation work-alike example given in “man procmailex”.
# The use of ^TO is the significant modification.
# See also “man procmailrc”.
#
# First we must decide whether to send an auto reply.
# All the egrep conditions (* lines) must be satisfied.
# If so, headers (h) of the current message are fed to
# formail which checks the vacation.cache to find out
# if the sender has already received an auto reply.
# We will lock vacation.lock while processing this
# recipe to avoid clashes when updating the cache.
#
# This recipe waits (W) for a return from formail.
# Without the (c) procmail would stop processing
# after completing this recipe because it is
# a delivery recipe, it delivers headers to formail.
#
# The conditions ^TO and ^FROM_DAEMON are more than
# meet the eye.
#
# ^TOzz1demo is satisfied if zz1demo
# appears in any recipient header To: Cc: Bc:.
# This avoids sending auto replies to messages that
# were addressed to an alias or maillist, but not
# explicitly to zz1demo.
#
# !^FROM_DAEMON makes sure we do not auto reply to
# messages from any of a wide variety of daemons.
#
# “!^X-Loop: zz1demo@ieng9.ucsd.edu” avoids replying
# to our own auto reply, notice below that this X-Loop
# header is inserted into the auto replies we send out.

SHELL=/bin/sh # for other shells, this might need adjustment

:0 Whc: vacation.lock
* ^TOzz1demo
* !^FROM_DAEMON
* !^X-Loop: zz1demo@ieng9.ucsd.edu
| formail -rD 8192 vacation.cache

# Due to (e) recipe below is executed if the preceding one
# returns an error status. In this case it is not really
# and error, it is just the signal from formail to go
# ahead with the auto reply. Notice that if in the
# preceding recipe the egrep conditions are not met
# and that causes the formail cache check to be
# skipped, procmail is [somehow] clever enough to skip
# this recipe.
#
# The headers (h) of the current message are fed to the
# formail in this recipe in order to construct the
# headers for the auto reply.
#
# The (c) in this recipe causes the whole
# current message to be processed after this recipe.
# Typically that means it will be processed with no
# further recipies and that is how you get a copy in your
# mailbox. There is no need for a lock while executing
# this recipe so none is used.

:0 ehc # if the name was not in the cache
| (formail -rA”Precedence: junk” \
-A”X-Loop: zz1demo@ieng9.ucsd.edu” ; \
echo “I received your mail, but I will be away”; \
echo “from the office until Monday Dec 15th.”; \
echo ” “;\
echo “If this is an urgent matter, please call my office XXX-XXXX “;\
echo ” “;\
cat $HOME/.sig \
) | $SENDMAIL -oi -t

Automatically discarding or returning unwanted mail
Return to sender with “reject” notice (not for spam!)

# This procmailrc will automatically reject and bounce mail from
# certain addresses. NOTE: DO NOT USE THIS FOR SPAM! Only use it for
# folks that you know have a valid return address.
#
# This file can be dropped into your home directory as ‘.procmailrc’, or
# inserted into your existing ‘.procmailrc’, with or without the
# comments.
# -zz1sn 2/18/98

#
# The :0 is the start of a rule. Note, blank lines in a rule are NOT
# happy. Don’t insert any blank lines between the :0 and the line with
# $SENDMAIL, or the rule won’t work. Also, don’t put any comments
# within the rule, either.

#
# The *^From:.*example.*nuisance
# line indicates the string you want to match. If the From
# header in the e-mails you want to match looks something like
# From: Block Head <llarry@ancientgames.com>
# you can use a rule like: *^From:.*llarry.*ancientgames
# or perhaps something like *^From:.*Block Head
# (Remember, case is important – capitals are different from lowercase!)
#
# You want to be as specific as possible, but general enough to
# catch the person’s e-mails. The ‘*^From: bit ensures that the
# rule only matches on the ‘From:’ header, and the ‘.*’ sequence
# is a wildcard (match 0 or more occurrences of any character).
#
# Replace ‘example.*nuisance’ with your expression; otherwise, this
# rule won’t do a thing.
#
# If you want to reject mail from more than one source you can
# repeat the whole rule (from the :0 line to the SENDMAIL line)
# as many times as necessary in your .procmailrc file. Put
# a blank line between rules.
#
# This rule bounces the mail. First, it pipes through a series of
# commands that generate a new e-mail. ‘formail’ takes the old e-mail
# and generates a response; we replace the ‘From:’ line with
# ‘devnull@ucsd.edu’ (which silently discards all mail) to prevent
# mail loops caused by ricocheting bounces.
#
# We then pipe the result through $SENDMAIL -oi -t, which tells
# sendmail to ignore dots as end-of-file markers, and to grab the
# sender/recipient info from the message body.
#
# Note syntax; anything that should be in the message needs to go in
# an ‘echo’ statement inside the parentheses. It should be
# double-quoted, and should not contain funny characters (*, $, etc.).
# The ‘ \’ (space-backslash) needs to be at the end of each line
# except the last to indicate that technically the entire rule belongs
# on one line.
#
:0
*^From:.*example.*nuisance
|( formail -rI”From: Responses will be automatically discarded <devnull@ucsd.edu>”; \
echo “Your mail has been administratively rejected.”; \
echo “It was NOT received.” \
) | $SENDMAIL -oi -t

Discard/block e-mail messages (without return to sender)

# This procmailrc will automatically reject and discard mail from
# certain addresses.
#
# This file can be dropped into your home directory as ‘.procmailrc’, or
# inserted into your existing ‘.procmailrc’, with or without the
# comments.
# -zz1sn 3/09/98

#
# The :0 is the start of a rule. Note, blank lines in a rule are NOT
# happy. Don’t insert any blank lines between the :0 and the line with
# $SENDMAIL, or the rule won’t work. Also, don’t put any comments
# within the rule, either.

#
# The *^From:.*example.*nuisance
# line indicates the string you want to match. If the From
# header in the e-mails you want to match looks something like
# From: Block Head <llarry@ancientgames.com>

# you can use a rule like: *^From:.*llarry.*ancientgames
# or perhaps something like *^From:.*Block Head
# (Remember, case is important – capitals are different from lowercase!)
#
# You want to be as specific as possible, but general enough to
# catch the person’s e-mails. The ‘*^From: bit ensures that the
# rule only matches on the ‘From:’ header, and the ‘.*’ sequence
# is a wildcard (match 0 or more occurrences of any character).
#
# Replace ‘example.*nuisance’ with your expression; otherwise, this
# rule won’t do a thing.
#
# This rule silently discards all mail containing the matched From:
# address. If you want to discard mail from more than one address,
# duplicate the entire 3-line rule, from :0 to /dev/null (changing the
# wildcard expression appropriately)
#
#
:0
*^From:.*example.*nuisance
/dev/null

Amazon AWS EC2 – Move instance to other region

Preparation:

In AWS web console

  1. Stop instance to move to another region
  2. Make snapshop (you can restart your original instance and put it back in production)
  3. Make new volume of snapshot
  4. Start another instance
  5. Attach the volume from the snapshot to the newly started instance
  6. (on the temp instance in the source region) Mount the volume to the instance
  7. Start an instance in the target region
  8. Create a volume of the same size as your source volume in the target region in the same availability zone as your target instance.
  9. Attach the just create volume to the target instance
  10. (on the target instance) Format the attached volume with the same file system as the source instance.
  11. (on the target instance) Mount the target instance
  12. (on the target instance) make sure you can access the temp instance in the source region via SSH – disable any keys and change ssh_config in the temp instance in the source region etc, if you have to.
  13. (on the target instance) Copy files from the temp instance the source to the mounted volume on the target with rsync:
    rsync -PHAXaz -e ssh ec2-107-22-76-156.compute-1.amazonaws.com:/mnt/sdf1/ /mnt/sdf1
  14. (on the target instance) Unmount the volume
  15. Detach the volume
  16. make a snapshot
  17. make an image
  18. start the instance. DOESNOT WORK. Don’t know why.

Recover information from a disk otherwise unreadable or unmountable

Install dd_rescue (not ddrescue – although that might also work)

copying everything to a file:

dd_rescue /dev/hda1 target-file.img

Mounting the file:

losetup /dev/loop0 target-file.img
mount /dev/loop0 /home/you/dir

or

mount -o loop target-file.img /home/you/dir

Installing s3fs on CentOS 5.6

Installing s3fs on CentOS 5.6

Assumptions:

  • rpmforge yum repo installed
  • centos up-to-date – yum -y update

Installation:

  1. yum -y install python
  2. yum -y install fuse
  3. yum -y install libfuse
  4. yum -y install python-hashlib
  5. wget ftp://rpmfind.net/linux/epel/5/i386/fuse-python-0.2.1-1.el5.i386.rpm
  6. rpm -ivh fuse-python-0.2.1-1.el5.i386.rpm
  7. yum -y install fuse-s3fs

Then you will need to do:

  1. Make your access details available to the program:
    (there are a multitude of ways to do that. This is just one shot for this session. You could also include them in your environment)

    export AWS_ACCESS_KEY_ID=<your amazon access key id>

    export AWS_SECRET_ACCESS_KEY=<your amazon secret access key>

  2. Create a bucket:
    /usr/bin/s3fs -C -c bucketnameofyourchoice
  3. Format bucket to be used with this program:
    /usr/bin/s3fs -C -f bucketnameofyourchoice
  4. Mount the bucket to a convenient place:
    /usr/bin/s3fs -o bucket=bucketnameofyourchoice /mnt/s3/

Then Amazon S3 behaves as if it is part of your file system and you can copy to and from and rsync to and from it. Ideal for backup.

Make CENTOS mount NTFS

Download fuse & ntfs-3g.

Use Yum:

Prompt>yum install -y fuse ntfs-3g

Mount the partition:
[root@server1~]# mount.ntfs-3g /dev/sda9 /mnt/temp

This assumes /dev/sda9 is the NTFS partition and /mnt/temp is the place to mount it to.

Is it possible to have Dovecot imap/pop daemons listening on multiple ports?

No, not in the current stable release. But there are workarounds, eg using your firewall to redirect incoming traffic to a given port.

# Example IPTABLES, REDIRECT INCOMING CONNECTION ON PORT 9292 TO DEFAULT POP3 PORT

iptables -t nat -A PREROUTING -p tcp -m tcp –dport 9292 -j REDIRECT –to-port 110

Transparent Proxy Squid 3

The only thing to be done in squid.conf is:

adding the “transparent” at the end of the http_port directive

http_port 3128 transparent

and of course redirecting the traffic to the port of the proxy with a suitable iptables rule. Something like (assuming 192.168.0.1 is your proxy’s LAN IP address):

iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.1:3128
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

Tunneling SMB over SSH: Secure file sharing

Suppose you’re at an open wireless hotspot and wish to connect the Samba server from your Windows laptop, but you don’t want to send data (documents, authentication hashes etc.) over the air in plain text.

Using SSH tunnels, you can encrypt all your network traffic and redirect it through a trusted computer when you’re connected to an untrusted network. The goal of this hack is to enable Windows users securely access shared files on any Samba server.

So, what are SSH Tunnels? In addition to providing remote shell access and command execution, SSH servers can forward ports to the other end of your connection. This can be extremely useful to protect any traffic that you need to keep private. In a nutshell, it is accomplished by binding to a local port, encrypting the traffic, sending the encrypted data to the remote machine, and then decrypting it and sending it to the remote host and port you specify.

Samba and Windows use port 139 for file sharing. At first glance, it seems that the easy solution is to tunnel connections from port 139 on your Windows computer to the Samba server. Then you can easily connect to the remote share by connecting to “localhost”. But since Windows always uses port 139 for file sharing, you must disable local file sharing to make the port forwarding.

So, how do we tunnel SMB over SSH and keep local file sharing working? We’re going to use a virtual network adapter. Basically, a virtual network adapter is a software application that allows a computer to connect to a network. We’re going to add a virtual adapter to our Windows computer and create a SSH tunnel over the virtual interface.

To add a virtual network adapter in Windows, use the following steps:

  1. In the Control Panel click on Add Hardware.
  2. In the Add Hardware Wizard, select “Yes, I have already connected the hardware” and click Next. Scroll down the list and click on “Add a new hardware device”.
  3. Select “Install the hardware that I manually select from a list”. From the hardware types, select Network Adapters and choose Microsoft Loopback Adapter.
  4. Go through the installation procedure.

The next step is to configure the new virtual adapter.

  1. Go to Network Connections configuration panel.
  2. Right click on the Microsoft Loopback Adapter and select Properties.
  3. Select Internet Protocol (TCP/IP) and click on the Properties button.
  4. Check “Use the following IP address” option and enter the chosen IP address (e.g. 10.0.0.1) and the subnet mask (255.255.255.0). If you have a gateway and DNS servers in your network, enter them too.
  5. Click on the Advanced button and in the WINS tab, select “Disable NetBIOS over TCP/IP”.

Setup the SSH Tunnel

Now that you have a properly configured virtual adapter, it’s time to setup the SSH tunnel between the Samba server and your computer. We assume that OpenSSH is already running on the Samba server. For the SSH client software we’re going to use Putty, a free SSH client that supports port forwarding.

Fire up Putty on your computer and enter the host name or IP address of your Samba server (e.g. 192.168.0.104). In the Tunnels options, in the “Source port” type 10.0.0.1:139 (the IP we used in our example) and in the “Destination” type 127.0.0.1:139. Click on “Add” and then “Open”. Once you authenticate, you’re ready to access the Samba server over the virtual adapter.

To test your SSH tunnel, just navigate from Windows explorer to \\10.0.0.1. If everything goes well, you’d prompted to enter a username and password to access the shares. Enjoy!

smb-ssh-share.jpg

When things go wrong

If things don’t work, make sure that both Samba and Putty are running and properly configured. If you’re running Windows XP SP2 in a closed environment (no access to the Internet for updates), make sure to install KB884020.

How to securely erase the hard disk

It is scary to realize that it is next to impossible to delete all the data that one stores on ones storage media without completely destroying it. Because, with the right tools anybody can retrieve even deleted data.

So what can be done to alleviate the situation ? If you are using GNU/Linux or any other UNIX, then you have a tool called shred which can be used to wipe all the data from the hard disk. Here is how it works. Suppose I want to erase all the data on my hard disk, then I boot using a LiveCD like Knoppix and open a shell and type the following command:

# shred -vfz -n 100 /dev/hda 

Here /dev/hda is my whole hard disk. And I am asking shred to make (-n) 100 passes by overwriting the entire hard disk with (-z) zeros. And shred program (-f) forces the write by changing the permissions wherever necessary.

Another GPLed tool (though not specifically related to Linux) which is quite popular is Darik’s Boot and Nuke (DBAN) which also does a swell job of wiping ones hard disk.

It is claimed that experts in the field of retrieving data can still get some data from a hard disk that has been wiped in the above manner. But atleast lesser mortals who buy second hand laptops and computers will find it beyond their means to lay their hands on the data.

 

 

Screen? A must for SSH

First some basic cheats, so you don’t have to search through the whole post:

ctrl+a+c                                               make a new screen
ctrl+a+n                                               next screen down the line
ctrl+a+p                                               previous screen down the line
ctrl+a+k                                               kills current screen until last one then you’re out
ctrl+a+d                                               leave, but leave them running and re-attachable

screen -ls                                            31619.something.else (Detached)
screen -r 31619.something.else       re-attaches to that session

screen -DDR                                     to re-attach any (the first) detached session.
If there is none, it creates a new session.

If you’ve ever used SSH to connect to a server, you ‘ll know its limitations: if you want to open a new window, you’ll need to create a second SSH connection to the server. And if the connection breaks during the SSH tunnel, you’ve lost your progress. This is where Screen comes in.

Screen, which calls itself a “full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells).” is a usefull tool to use 1 SSH connection, but use multiple screens to work in. So you can have 1 screen to write some scripts in, another to tail a logfile and a third to check your IRC messages ;-)

Screen is installed by default on most installations, you can verify this by running the “which screen” command. If it’s not installed, try to apt-get or yum it – it’s in most repositories.

You can start screen by typing:

[root@vps ~]# screen

This makes sense, right? :-)
You’ll probably notice that not much happens if you type that. At least, it seems like not much as happened. In fact, you’ve just opened a new “screen” to type your commands. The program “screen” has a few commands of its own, in order to create a new window, and navigate through the open ones.

Once you’ve opened “screen“, you can see a command list by typing “CTRL + A”, followed by “?” (the question mark). By typing “CTRL + A” you state that the next signal is to be sent to the program “screen“, in stead of to the Shell (like you would in a normal shell). You’ll see a list of all bindings known to “screen“.

Start a new window by typing “CTRL + A” + “c”. The C stands for Create – I know, too obvious. A new window will be created. In order to test this, type the command “top”. Then create a new window, by using “CTRL + A” + “c”. You’ll see top disappear, and a new window will open. Type in some commands of your choice, and return to the previous window, by doing “CTRL + A” + “n”. The “n” stands for “Next”, and will open the next screen. “CTRL + A” + “p” would’ve opened the previous screen.

Closing a window, can be done by typing “exit” (like you would in a normal shell). This will cause you to fall back to the previous monitor you opened, or to your main prompt – where you started screen, showing you a message such as “[screen is terminating]” – so you’ll know you’ve hit the main shell.

The biggest advantage in using screen, is that you can “detach” a screen-session. This means you return to the normal shell, but the processes started in “screen” are still active in the background. You can detach yourself by typing “CTRL + A” + “d”. Again, obvious that “D” stands for Detach. This gives you more flexibility for managing your server(s): you can start a number of processes, quietly exit the shell and return a couple of hours later to pick up the session started in screen.

Should you disconnect by accident, during a screen-session, you can always pick up a previous screen by relogging to shell and typing “screen -ls“. This will show a list of all running screen-sessions at any given time. You can pick up a previous screen-session, by typing “screen -r <name_of_session>“.

Probably known to most linux-administrators, but still an awesome tool :-)

Re-printed (so we don’t loose the information) from:

http://www.mattiasgeniar.be/2008/06/04/screen-a-must-for-ssh/