Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ssh tullen

26 views
Skip to first unread message

Dr Eberhard Lisse

unread,
Jan 16, 2012, 2:59:07 AM1/16/12
to
Hi,

I have a PostgreSQL database behind a firewall which I can access from a
fixed IP address but obviously not while on the road where I must issue
something like:

ssh -N -C us...@host.domain.DOMAIN -L 5433/localhost/5432

and then run my script to generate the report.

I can in a slightly different context using Net::SSH issue commands
to the remote host, but I have been unable to figure out how to open a
tunnel from within the perl script (preferably with a module, but that's
not really the issue), then do my usual thing, and then close the tunnel
again.

Is this a unique problem? Or can someone point me to a code fragment
that does something like this...

el

Dr Eberhard Lisse

unread,
Jan 16, 2012, 2:59:58 AM1/16/12
to
Hi,

I have a PostgreSQL database behind a firewall which I can access
from a fixed IP address but obviously not while on the road where I
must issue something like:

ssh -N -C us...@host.domain.DOMAIN -L 5433/localhost/5432

(using publik/private key combination) and then run my script to

Peter J. Holzer

unread,
Jan 16, 2012, 6:46:59 AM1/16/12
to
On 2012-01-16 07:59, Dr Eberhard Lisse <nos...@lisse.NA> wrote:
> I have a PostgreSQL database behind a firewall which I can access from a
> fixed IP address but obviously not while on the road where I must issue
> something like:
>
> ssh -N -C us...@host.domain.DOMAIN -L 5433/localhost/5432
>
> and then run my script to generate the report.
>
> I can in a slightly different context using Net::SSH issue commands
> to the remote host, but I have been unable to figure out how to open a
> tunnel from within the perl script (preferably with a module, but that's
> not really the issue), then do my usual thing, and then close the tunnel
> again.

maybe I misunderstand the problem, but have you tried simply starting
ssh in the background (with open or fork/exec) at the start of your
script and killing it at the end?

hp

--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

Dr Eberhard W Lisse

unread,
Jan 16, 2012, 11:30:48 PM1/16/12
to
Haven't been able to successfully do that.

Have you got a working code fragment?


el

On 2012-01-16 13:46 , Peter J. Holzer wrote:
> On 2012-01-16 07:59, Dr Eberhard Lisse <nos...@lisse.NA> wrote:
>> I have a PostgreSQL database behind a firewall which I
>> can access from a fixed IP address but obviously not
>> while on the road where I must issue something like:
>>
>> ssh -N -C us...@host.domain.DOMAIN -L
>> 5433/localhost/5432
>>
>> and then run my script to generate the report.
>>
>> I can in a slightly different context using Net::SSH
>> issue commands to the remote host, but I have been unable
>> to figure out how to open a tunnel from within the perl
>> script (preferably with a module, but that's not really
>> the issue), then do my usual thing, and then close the
>> tunnel again.
>
> maybe I misunderstand the problem, but have you tried
> simply starting ssh in the background (with open or
> fork/exec) at the start of your script and killing it at
> the end?
>
> hp
>


--
If you want to email me, replace nospam with el

Peter Makholm

unread,
Jan 17, 2012, 5:17:18 AM1/17/12
to
Dr Eberhard W Lisse <nos...@lisse.NA> writes:

>> maybe I misunderstand the problem, but have you tried
>> simply starting ssh in the background (with open or
>> fork/exec) at the start of your script and killing it at
>> the end?
>
> Haven't been able to successfully do that.

What did you try? How did it fail?

> Have you got a working code fragment?

I have written a lot of code which rather naïvely uses IPC::Open3 to run
ssh as a background process. It should work for opening a tunnel.

The problems I don't usual handle is that the initial connection often
asks whether to accept the host key. In this scenario the process just
hangs. If you just accept the hostkey by hand it works correctly.

//Makholm

Ben Morrow

unread,
Jan 17, 2012, 6:46:00 AM1/17/12
to

Quoth Peter Makholm <pe...@makholm.net>:
>
> I have written a lot of code which rather naïvely uses IPC::Open3 to run
> ssh as a background process. It should work for opening a tunnel.
>
> The problems I don't usual handle is that the initial connection often
> asks whether to accept the host key. In this scenario the process just
> hangs. If you just accept the hostkey by hand it works correctly.

Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
never exit. (It doesn't seem to be very easy to find its pid to kill it
manually.)

You can also use -oBatchMode=yes, if you'd rather it failed than prompted.

Ben

Dr Eberhard W Lisse

unread,
Jan 18, 2012, 11:50:43 PM1/18/12
to
Peter,

reason for failure:

Stupidity and Ignorance of this elderly Gynaecologist :-)-O

I have the key pairs organized :-)-O

el

Peter J. Holzer

unread,
Jan 21, 2012, 6:19:22 AM1/21/12
to
On 2012-01-17 11:46, Ben Morrow <b...@morrow.me.uk> wrote:
> Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
> with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
> never exit. (It doesn't seem to be very easy to find its pid to kill it
> manually.)

open($fh, '-|', ...) returns the pid, so does fork. The following script
works for me, at least on linux:


#!/usr/bin/perl
use warnings;
use strict;
use IO::Socket::INET;

$| = 1;
print "opening tunnel ... ";
my $pid = open(my $fh, '-|',
'ssh', '-N', 'h...@mri.DOMAIN', '-L', '10007:chronos.DOMAIN:7'
) or die;
print " done (pid=$pid)\n";

sleep 5;
system('lsof', '-i', ':10007');
sleep 5;

print "opening socket ... ";
my $sock = IO::Socket::INET->new(PeerHost => 'localhost',
PeerPort => 10007,
Proto => 'tcp');
print " done\n";

print "sending request ... ";
print $sock "test123\n";
print " done\n";

print "reading response ... ";
my $resp = <$sock>;
print " done (resp = $resp)\n";

print "closing socket ... ";
close($sock);
print " done\n";

sleep(5);
system('lsof', '-i', ':10007');
sleep(5);

print "closing tunnel ... ";
kill(15, $pid);
my $rc = waitpid($pid, 0);
print " done (rc = $rc)\n";

sleep(5);
system('lsof', '-i', ':10007');
__END__

Ben Morrow

unread,
Jan 21, 2012, 12:35:45 PM1/21/12
to

Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
> On 2012-01-17 11:46, Ben Morrow <b...@morrow.me.uk> wrote:
> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
> > never exit. (It doesn't seem to be very easy to find its pid to kill it
> > manually.)
>
> open($fh, '-|', ...) returns the pid, so does fork. The following script
> works for me, at least on linux:

I think you're not realising what the -f argument to ssh does. It makes
ssh put itself in the background, but only after any possible need to
prompt the user has been dealt with. So if you run ssh -f from Perl in
the foreground (with system(), rather than with open/2/3, and without
explicitly forking first), the user will see any necessary prompts about
accepting host keys (or even passwords, if you're using password auth)
and then ssh will go into the background and the system() call will
return to Perl.

It's very convenient, when that's the behaviour you want, but
unfortunately since ssh forked itself into the background there's no way
to find out the (new) pid of the background ssh process. Fortunately ssh
won't exit until all the forwardings it set up are no longer in use, so
a command of 'sleep 10' gives your Perl program 10 seconds to open a
forwarded connection, and then ssh will stay running until it closes. If
you'd used -N instead the backgrounded ssh would never exit on its own.

Ben

Peter J. Holzer

unread,
Jan 21, 2012, 1:31:49 PM1/21/12
to
On 2012-01-21 17:35, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
>> On 2012-01-17 11:46, Ben Morrow <b...@morrow.me.uk> wrote:
>> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
>> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
>> > never exit. (It doesn't seem to be very easy to find its pid to kill it
>> > manually.)
>>
>> open($fh, '-|', ...) returns the pid, so does fork. The following script
>> works for me, at least on linux:
>
> I think you're not realising what the -f argument to ssh does. It makes
> ssh put itself in the background, but only after any possible need to
> prompt the user has been dealt with.

Yes, but there is no reason to use it. Perl can put processes in the
"background" just fine. You will notice that my little test program
doesn't use it.

Ben Morrow

unread,
Jan 21, 2012, 3:49:15 PM1/21/12
to

Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
> On 2012-01-21 17:35, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
> >> On 2012-01-17 11:46, Ben Morrow <b...@morrow.me.uk> wrote:
> >> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
> >> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
> >> > never exit. (It doesn't seem to be very easy to find its pid to kill it
> >> > manually.)
> >>
> >> open($fh, '-|', ...) returns the pid, so does fork. The following script
> >> works for me, at least on linux:
> >
> > I think you're not realising what the -f argument to ssh does. It makes
> > ssh put itself in the background, but only after any possible need to
> > prompt the user has been dealt with.
>
> Yes, but there is no reason to use it. Perl can put processes in the
> "background" just fine. You will notice that my little test program
> doesn't use it.

Perl can put processes in the background just fine, yes. That's not the
issue. The issue is that sometimes ssh needs to prompt, and running it in
the background from Perl doesn't handle that very well.

I took the program you posted and made the following change:

@@ -16,7 +16,8 @@
$| = 1;
print "opening tunnel ... ";
my $pid = open(my $fh, '-|',
- 'ssh', '-N', 'h...@mri.DOMAIN', '-L', '10007:chronos.DOMAIN:7'
+ 'ssh', '-N', '-oUserKnownHostsFile=/dev/null',
+ 'isis', '-L', '10007:isis:7'
) or die;
print " done (pid=$pid)\n";

Apart from changing the host to one I have ssh access to, this sets
UserKnownHostsFile=/dev/null so ssh will always ask me to verify the
host key. If I run this, and I take more than 10 seconds to reply to the
prompt, the connection isn't set up properly and the program hangs
(script session wrapped for Usenet):

Script started on Sat Jan 21 20:28:55 2012
perl -x hjp-ssh
opening tunnel ... done (pid=49176)
The authenticity of host 'isis.morrow.me.uk (204.109.63.142)' can't
be established.
RSA key fingerprint is ee:8b:2a:da:6f:34:30:16:bf:84:85:50:f7:d6:7a:6f.
Are you sure you want to continue connecting (yes/no)? opening socket
... done
sending request ... Can't use an undefined value as a symbol reference
at hjp-ssh line 25.
^C
Script done on Sat Jan 21 20:29:40 2012

Obviously the 10 seconds' grace is a rather artificial feature of that
test program, and normally it would plough straight on without giving
the user any opportunity to respond.

If, instead, I make this change:

@@ -15,10 +15,12 @@

$| = 1;
print "opening tunnel ... ";
-my $pid = open(my $fh, '-|',
- 'ssh', '-N', 'h...@mri.DOMAIN', '-L', '10007:chronos.DOMAIN:7'
- ) or die;
-print " done (pid=$pid)\n";
+system(qw!
+ ssh -f -oUserKnownHostsFile=/dev/null
+ isis -L 10007:isis:7
+ sleep 10
+!) == 0 or die;
+print "ssh succeeded ... ";

sleep 5;
system('lsof', '-i', ':10007');
@@ -44,15 +46,7 @@

sleep(5);
system('lsof', '-i', ':10007');
-sleep(5);
-
-print "closing tunnel ... ";
-kill(15, $pid);
-my $rc = waitpid($pid, 0);
-print " done (rc = $rc)\n";

-sleep(5);
-system('lsof', '-i', ':10007');
__END__

hp

it will wait at the prompt until the user responds, and then continue
properly (I waited more than 10 seconds before typing 'yes'):

Script started on Sat Jan 21 20:29:55 2012
perl -x hjp-ssh-f
opening tunnel ... The authenticity of host 'isis.morrow.me.uk
(204.109.63.142)' can't be established.
RSA key fingerprint is ee:8b:2a:da:6f:34:30:16:bf:84:85:50:f7:d6:7a:6f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'isis.morrow.me.uk' (RSA) to the list of
known hosts.
ssh succeeded ... COMMAND PID USER FD TYPE DEVICE
SIZE/OFF NODE NAME
ssh 49204 mauzo 4u IPv6 0xffffff002c08b000 0t0 TCP
localhost:10007 (LISTEN)
ssh 49204 mauzo 5u IPv4 0xffffff002b228000 0t0 TCP
localhost:10007 (LISTEN)
opening socket ... done
sending request ... done
reading response ... channel 3: open failed: connect failed: Connection
refused
Use of uninitialized value $resp in concatenation (.) or string at
hjp-ssh-f line 31.
done (resp = )
closing socket ... done

Script done on Sat Jan 21 20:30:37 2012

It fails later, obviously, because there's nothing listening at the
remote end, but having failed both the Perl script and the ssh process
exit cleanly.

Ben

Peter J. Holzer

unread,
Jan 21, 2012, 4:47:25 PM1/21/12
to
On 2012-01-21 20:49, Ben Morrow <b...@morrow.me.uk> wrote:
>
> Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
>> On 2012-01-21 17:35, Ben Morrow <b...@morrow.me.uk> wrote:
>> > Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
>> >> On 2012-01-17 11:46, Ben Morrow <b...@morrow.me.uk> wrote:
>> >> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
>> >> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
>> >> > never exit. (It doesn't seem to be very easy to find its pid to kill it
>> >> > manually.)
>> >>
>> >> open($fh, '-|', ...) returns the pid, so does fork. The following script
>> >> works for me, at least on linux:
>> >
>> > I think you're not realising what the -f argument to ssh does. It makes
>> > ssh put itself in the background, but only after any possible need to
>> > prompt the user has been dealt with.
>>
>> Yes, but there is no reason to use it. Perl can put processes in the
>> "background" just fine. You will notice that my little test program
>> doesn't use it.
>
> Perl can put processes in the background just fine, yes. That's not the
> issue. The issue is that sometimes ssh needs to prompt, and running it in
> the background from Perl doesn't handle that very well.

Prompting doesn't work if the script is run from cron, or from a web
server, or most other situations where I've ever needed to call ssh from
a perl script. Your assumption that it is possible to prompt isn't any
more reasonable than my assumption that the environment has been set up
correctly (remote host key in known_hosts, local public key in remote
authorized_keys, ...).


> I took the program you posted and made the following change:

"Doctor, it hurts when I do this!"

"Well, then don't do it!"

C.DeRykus

unread,
Jan 21, 2012, 8:26:41 PM1/21/12
to
Off-topic a bit, but I seem to recall a workaround with /dev/null...
ah, here's
the incantation:

$ ssh -o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
...

--
Charles DeRykus

Ben Morrow

unread,
Jan 21, 2012, 9:02:42 PM1/21/12
to

Quoth "C.DeRykus" <der...@gmail.com>:
>
> Off-topic a bit, but I seem to recall a workaround with /dev/null...
> ah, here's
> the incantation:
>
> $ ssh -o UserKnownHostsFile=/dev/null \
> -o StrictHostKeyChecking=no \
> ...

That (effectively) turns off all host key checking, which is Very Bad
unless you're using DNSSEC (and using it correctly).

Ben

l v

unread,
Jan 25, 2012, 9:34:05 PM1/25/12
to
How about trying Net::OpenSSH? I have not used this module.

http://search.cpan.org/~salva/Net-OpenSSH-0.57/lib/Net/OpenSSH.pm#Tunnels

<quote>

tunnel => $bool

Instead of executing a command in the remote host, this option instruct
Net::OpenSSH to create a TCP tunnel. The arguments become the target IP
and port.

Example:

my ($in, $out, undef, $pid) = $ssh->open_ex({tunnel => 1}, $IP, $port);

</quote>

--
Len

Dr Eberhard W Lisse

unread,
Jan 26, 2012, 6:35:42 PM1/26/12
to
Have you got a code fragment for this elderly Gyneaecologist?

Didn't manage to get OpenSSH to work either.

thanks, el

On 2012-01-26 04:34 , l v wrote:
[...]
>
> How about trying Net::OpenSSH? I have not used this module.

Dr Eberhard W Lisse

unread,
Jan 26, 2012, 6:36:10 PM1/26/12
to
Thanks, that helps.

el

Tad McClellan

unread,
Jan 26, 2012, 11:23:33 PM1/26/12
to
Dr Eberhard W Lisse <nos...@lisse.NA> wrote:

> Thanks, that helps.
>
> el


Perhaps you do not realize it, but you appear to be rude.

You should learn Usenet manners if you intend to post to Usenet.

Do not top-post.

Do not full-quote.


http://web.presby.edu/~nnqadmin/nnq/nquote.html


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.

Dr Eberhard Lisse

unread,
Jan 27, 2012, 4:10:52 AM1/27/12
to
And you can go and see Isak N. Jacobsen.

el


on 2012-01-27 06:23 Tad McClellan said the following:

Tad McClellan

unread,
Jan 27, 2012, 9:50:16 AM1/27/12
to
Dr Eberhard Lisse <nos...@lisse.NA> wrote:
> And you can go and see Isak N. Jacobsen.
>
> el
>
>
> on 2012-01-27 06:23 Tad McClellan said the following:
>> Dr Eberhard W Lisse <nos...@lisse.NA> wrote:
>>
>>> Thanks, that helps.
>>>
>>> el
>>
>>
>> Perhaps you do not realize it, but you appear to be rude.


Sorry, I did not realize that you are unconcerned about appearing clueless.

Dr Eberhard W Lisse

unread,
Jan 28, 2012, 1:53:18 PM1/28/12
to
Sorry, you didn't realize that you are unconcerned about appearing arrogant.

el

On 2012-01-27 16:50 , Tad McClellan wrote:
> Dr Eberhard Lisse <nos...@lisse.NA> wrote:
>> And you can go and see Isak N. Jacobsen.
>>
>> el
>>
>>
>> on 2012-01-27 06:23 Tad McClellan said the following:
>>> Dr Eberhard W Lisse <nos...@lisse.NA> wrote:
>>>
>>>> Thanks, that helps.
>>>>
>>>> el
>>>
>>>
>>> Perhaps you do not realize it, but you appear to be rude.
>
>
> Sorry, I did not realize that you are unconcerned about appearing clueless.
>
>


--

Kaz Kylheku

unread,
Jan 28, 2012, 2:03:26 PM1/28/12
to
On 2012-01-27, Tad McClellan <ta...@seesig.invalid> wrote:
> Dr Eberhard Lisse <nos...@lisse.NA> wrote:
>>> Perhaps you do not realize it, but you appear to be rude.
>
> Sorry, I did not realize that you are unconcerned about appearing clueless.

Yet, you fixed your top-posting in response to Dr. Lisse, so it was
not entirely in vain. :)

Kaz Kylheku

unread,
Jan 28, 2012, 2:12:21 PM1/28/12
to
On 2012-01-27, Dr Eberhard Lisse <nos...@lisse.NA> wrote:
> And you can go and see Isak N. Jacobsen.

Doc, it really is better if you trim the quoted material, break it up into
pieces that you want to respond to and reply below those pieces. Try it!

(This is why the > characters are there; to clearly distinguish
between your embedded pieces and the original text.)

It's not "rude" otherwise; it's just a different cultural convention. In the
corporate world of Mirosoft Exchange/Outlook e-mail communication, full quoting
and top-posting is the norm. (And note that > quoting is not used!)

In the classic world of Internet e-mail, mailing lists, Usenet newsgroups
and BBS's, we have > with in-between quoting. It is better suited for complex
discussions with multiple points.

The posting sotware you are using is already doing half the job of sticking to
the convention by inserting the > characters.

Cheers ...

Tad McClellan

unread,
Jan 28, 2012, 3:37:13 PM1/28/12
to
Dr Eberhard W Lisse <nos...@lisse.NA> wrote:


> Sorry, you didn't realize
^^^
^^^

You are apologizing for me?

That seems a bit presumptuous...


> On 2012-01-27 16:50 , Tad McClellan wrote:

>> Sorry, I did not realize


Here I apologized for me.



You apologize for you.

You are not priveleged to apologize for me.

Dr Eberhard W Lisse

unread,
Jan 28, 2012, 3:51:36 PM1/28/12
to
I think you must get out more.

el

On 2012-01-28 22:37 , Tad McClellan wrote:
> Dr Eberhard W Lisse <nos...@lisse.NA> wrote:
>
>
>> Sorry, you didn't realize
> ^^^
> ^^^
>
> You are apologizing for me?
>
> That seems a bit presumptuous...
>
>
>> On 2012-01-27 16:50 , Tad McClellan wrote:
>
>>> Sorry, I did not realize
>
>
> Here I apologized for me.
>
>
>
> You apologize for you.
>
> You are not priveleged to apologize for me.
>
>


--

Dr Eberhard W Lisse

unread,
Jan 28, 2012, 3:56:14 PM1/28/12
to
Thank you very much for explaining this to me.


But you see, old habits die hard, been top-posting and full-quoting
now for 30 years or so, initially nn but TBird does this also very
well.

We are now hoever getting well off topic, and though I enjoy a
good flame as the next one I wasn't really trolling.

greetings, el

Shmuel Metz

unread,
Jan 28, 2012, 10:05:06 PM1/28/12
to
In <201201281...@kylheku.com>, on 01/28/2012
at 07:12 PM, Kaz Kylheku <k...@kylheku.com> said:

>In the classic world of Internet e-mail, mailing lists, Usenet
>newsgroups and BBS's, we have > with in-between quoting. It is
>better suited for complex discussions with multiple points.

The BBS world is the odd man out; there the convention is not a bare
">" but rather the initials of the poster, e.g.,

kk> In the classic world of Internet e-mail, mailing lists, Usenet kk>
newsgroups and BBS's, we have > with in-between quoting. It is kk>
better suited for complex discussions with multiple points.

IMHO it's a better convention, especially with nested quotes.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

Dr Eberhard Lisse

unread,
Jan 30, 2012, 3:21:30 AM1/30/12
to
Shmuel,

I agree, but often the same as below happens, the editor used (I use
emacs and AlphaX) don't recognize the kk> for formatting purposes,
wiithout some intervention :-)-O

el

on 2012-01-29 05:05 Shmuel (Seymour J.) Metz said the following:

Tim McDaniel

unread,
Jan 30, 2012, 12:25:07 PM1/30/12
to
In article <4F2460EE...@lisse.NA>,
>We are now hoever getting well off topic,

Meta-discussion is related to the topic.

>and though I enjoy a
>good flame as the next one I wasn't really trolling.

When multiple people tell you about group customs and explain why
they're practical, and you loudly refuse to follow and denigrate the
reasons: yes, you are indeed trolling. Luckily, my news reader has a
"killfile" that can filter by sender.

--
Tim McDaniel, tm...@panix.com

Dr Eberhard Lisse

unread,
Jan 31, 2012, 6:30:49 AM1/31/12
to
If multiple morons whine that not necessarily means anything other than
that they are morons.

el

on 2012-01-30 19:25 Tim McDaniel said the following:
0 new messages