perl: matching an IPv4 address

SOLUTION 1: Jeffrey Friedl's "Mastering Regular Expressions"
source

my $ReIpNum = qr{([01]?\d\d?|2[0-4]\d|25[0-5])};
my $ReIpAddr = qr{^$ReIpNum\.$ReIpNum\.$ReIpNum\.$ReIpNum$};

my %ips = ('0.0.0.0' => 1,
           '1.2.3.4' => 1,
           '255.255.255.255' => 1,
           '000.34.2000.2' => 0,
           '' => 0,
           '24.23.23.' => 0);

for my $ip(keys %ips) {
    die "Failed: $ip"
    unless (($ip =~ m{$ReIpAddr}) == $ips{$ip});
    print "$ip passed\n";
}

SOLUTION 2: USE Regexp::Common
source

#!/bin/perl
use Regexp::Common;

while() {
    if(/$RE{net}{IPv4}{dec}{-keep}/) {
        print "IP Address: $1\n";
    }
}

__DATA__
24.113.50.245
0.42.523.2
255.242.52.4
2.5.3

Discussion:

IP addresses are difficult to match using a simple regular expression, because the regular expression must verify that the IP address against which it is matching is valid. A simple expression such as /\d{3}\.\d{3}\.\d{3}\.\d{3}/ will incorrectly match strings such as 789.23.2.900, which is outside the range of valid IP addresses (i.e., 0.0.0.0 to 255.255.255.255). Damian Conway's Regexp::Common module provides a very effective regular expression which matches only valid IP addresses.

perl: simple socket programming

Here's a telnet kinda program in perl (i.e. a generic TCP client):

#!/usr/bin/perl
use IO::Socket;

my $dest = shift;
my $port = shift;
my $message;
my $line;

my $sock = IO::Socket::INET -> new ( PeerAddr => $dest, PeerPort => $port, Proto => "tcp" ) or die "Could not establish TCP connection: $!";

$sock->autoflush(1);

while (1)
{
    $message = <stdin>;
    print $sock $message;

    while ($line = <$sock>)
    {
        print $line;
    }
}

close $sock;

smtp: sending an email from the telnet prompt

This mail relay must accept SMTP connection from your host and must accept relaying. To check if the mail relay is working try



telnet mailrelay.domain 25
.... answer from mail relay .....

helo 
mail from: root@
rcpt to: @

data

mail test from unix
.



mail server should answer something like mail sent. If this work you can try with a normal mail client like



mailx -s "subject" @
mail test from unix
.



To check if this has work look at /var/adm/syslog/mail.log

you should see a couple of lines stating the mail has been accepted locally and sent to the relay and accepted.

perl: extracting email addresses from a thunderbird message list

The inputfile resides somewhere like: "C:\Documents and Settings\USERNAME\Application Data\Thunderbird\Profiles\sbdq6f9n.default\Mail\Local Folders\Inbox.sbd\guitar.sbd"

use strict;
use warnings;
use Tie::File;
use Fcntl;


sub alphabetically { lc $a cmp lc $b }


my $inputfile = shift;

unless ($inputfile)
{
    print "\nUSAGE:\n$0  \n\n\n\n";
    exit 0;
}

my @contents;

tie (@contents, 'Tie::File', $inputfile, mode=>O_RDONLY) or die "Can't open $inputfile: $!\n\n\n\n";
#open (MYFILE, $inputfile) || die " $! ";
#my @contents = ;
#close(MYFILE);


my @addresses; my $line; my $x; my %seen = ();


foreach $line (@contents) {
        if ( $line =~ m/([a-zA-Z]+\.[a-zA-Z]+\@calsoftinc\.com)/ ) 
        {
            if ( $1=~m/ambar/) 
            {  
                next; 
            }
            else { $seen{$1}++; } #use a hash to automatically get a unique list
        }
}

foreach $x (keys %seen) { unshift(@addresses, "$x\n"); }

print sort alphabetically @addresses;

esx: killing a stuck VM from the command line - redux!

NOTE: The method in this post seems more accurate and effective than the one in the previous post on this blog, "killing a stuck VM from the command line."


Instructions on how to forcibly terminate a VM if it is unresponsive to the VI client


Here you will be terminating the Master World and User Worlds for the VM which in turn will terminate the VM's processes.



1. First list the running VMs to determine the VM ID for the affected VM:
#cat /proc/vmware/vm/*/names

vmid=1076 pid=-1 cfgFile="/vmfs/volumes/50823edc-d9110dd9-8994-9ee0ad055a68/vc using sql/vc using sql.vmx" uuid="50 28 4e 99 3d 2b 8d a0-a4 c0 87 c9 8a 60 d2 31" displayName="vc using sql-192.168.1.10"

vmid=1093 pid=-1 cfgFile="/vmfs/volumes/50823edc-d9110dd9-8994-9ee0ad055a68/esx_template/esx_template.vmx" uuid="50 11 7a fc bd ec 0f f4-cb 30 32 a5 c0 3a 01 09" displayName="esx_template"

For this example we will terminate the VM at vmid='1093'




2. We need to find the Master World ID, do this type:
# less -S /proc/vmware/vm/1093/cpu/status

Expand the terminal or scroll until you can see the right-most column. This is labelled 'group'. Unterneath the column you will find: vm.1092.

In this example '1092' is the ID of the Master World.




3. Run this command to terminate the Master World and the VM running in it:

/usr/lib/vmware/bin/vmkload_app -k 9 1092




4. This should kill all the VM's User Worlds and also the VM's processes.

If Successful you will see similar:

# /usr/lib/vmware/bin/vmkload_app --kill 9 1070
Warning: Jul 12 07:24:06.303: Sending signal '9' to world 1070.

If the Master World ID is wrong you may see:
# /usr/lib/vmware/bin/vmkload_app --kill 9 1071
Warning: Jul 12 07:21:05.407: Sending signal '9' to world 1071.
Warning: Jul 12 07:21:05.407: Failed to forward signal 9 to cartel 1071: 0xbad0061



source

windows: the TcpTimedWaitDelay registry setting

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

The TcpTimedWaitDelay key in the Windows registry determines the time that must elapse before TCP can release a closed connection and reuse its resources. This interval between closure and release is known as the TIME_WAIT state or 2MSL state. During this time, the connection can be reopened at much less cost to the client and server than establishing a new connection.

Reducing the value of this entry allows TCP to release closed connections faster, providing more resources for new connections. However, if the value is too low, TCP might release connection resources before the connection is complete, requiring the server to use additional resources to reestablish the connection.

linux basics: IO redirection - append to both stderr and stdout

It is possible to redirect one output channel to another like "2>&1" which means "put the output of channel 2 (stderr) where channel 1 (stdout) currently goes" and let channel 1 point to a file:

process >>file 2>&1

But it is preferable that you first try with separately mentioned files - it makes a much easier to maintain code AND it is not position dependent:

process >file 2>&1

will have stderr and stdout go to , but:

process 2>&1 >file

will have stdout go to and stderr to the screen, because when channel 2 intended direction is evaluated, channel 1 is still pointing to the terminal and not to the file.


This is one of the most common errors in crontabs and responsible for an awful lot of unnecessary (and unwanted) mails to root (the cronjobs replacement for a terminal).