[32351] in Perl-Users-Digest
Perl-Users Digest, Issue: 3618 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 22 09:14:29 2012
Date: Wed, 22 Feb 2012 06:14:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 22 Feb 2012 Volume: 11 Number: 3618
Today's topics:
Re: Can't connect to 'localhost' in IO::Socket <mvdwege@mail.com>
Re: Can't connect to 'localhost' in IO::Socket <m@rtij.nl.invlalid>
Re: Can't connect to 'localhost' in IO::Socket <ben@morrow.me.uk>
Re: Can't connect to 'localhost' in IO::Socket <rweikusat@mssgmbh.com>
use file::find to find files modified in last 5 days <mikesolomon40@googlemail.com>
Re: use file::find to find files modified in last 5 day <ben@morrow.me.uk>
Re: use file::find to find files modified in last 5 day <justin.1201@purestblue.com>
Re: use file::find to find files modified in last 5 day <mikesolomon40@googlemail.com>
Re: use file::find to find files modified in last 5 day <mikesolomon40@googlemail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 21 Feb 2012 08:29:24 +0100
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <86hayk7igb.fsf@gaheris.avalon.lan>
Wolfram Humann <w.c.humann@arcor.de> writes:
> On 20 Feb., 14:55, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> It is usually more sensible to bind to the wildcard address,
>> especially considering that IP addresses are usually per-host and not
>> per-interface, meaning, by default, any address that's configured on
>> any public interface of some computer will reachable via all other
>> public interfaces (so-called 'weak end-system').
>
> So I would simply say Transports => ['TCP:Port=1700,Host=']
>
> with the corresponding netstat (thanks for the -l / -a tip!) reply:
>
> tcp 0 0 *:1700
> *:* LISTEN
>
> Is that what you meant? Does this wildcard create any security issues
> (exceeding those potentially present before by providing *any* TCP-
> accessible service)?
>
Do note that Rainer is wrong there. IP addresses are bound to an
interface, always. DNS may not care about that and give you just an IP
address if you know the hostname, but if you're trying to connect,
especially on a LAN or on a local machine, it is *important* that you
known which interface is being listened on.
As Ben said, there is a virtual address type called 'ANY' which means
that your server will listen on any interface and answer on any address
on that specific port. The wildcard in the netstat output indicates that
your server is bound to the ANY address.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Wed, 22 Feb 2012 09:51:20 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <8tme19-j7p.ln1@news.rtij.nl>
On Tue, 21 Feb 2012 08:29:24 +0100, Mart van de Wege wrote:
> Wolfram Humann <w.c.humann@arcor.de> writes:
>
>> On 20 Feb., 14:55, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>> It is usually more sensible to bind to the wildcard address,
>>> especially considering that IP addresses are usually per-host and not
>>> per-interface, meaning, by default, any address that's configured on
>>> any public interface of some computer will reachable via all other
>>> public interfaces (so-called 'weak end-system').
>>
>> So I would simply say Transports => ['TCP:Port=1700,Host=']
>>
>> with the corresponding netstat (thanks for the -l / -a tip!) reply:
>>
>> tcp 0 0 *:1700
>> *:* LISTEN
>>
>> Is that what you meant? Does this wildcard create any security issues
>> (exceeding those potentially present before by providing *any* TCP-
>> accessible service)?
>>
> Do note that Rainer is wrong there. IP addresses are bound to an
> interface, always. DNS may not care about that and give you just an IP
> address if you know the hostname, but if you're trying to connect,
> especially on a LAN or on a local machine, it is *important* that you
> known which interface is being listened on.
Sorry but Rainer is absolutely correct and you are absolutely wrong. It's
an important concept, so I suggest you Google it.
HTH,
M4
------------------------------
Date: Wed, 22 Feb 2012 12:16:34 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <2u2f19-7ej.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Tue, 21 Feb 2012 08:29:24 +0100, Mart van de Wege wrote:
> > Wolfram Humann <w.c.humann@arcor.de> writes:
> >>
> >> So I would simply say Transports => ['TCP:Port=1700,Host=']
> >>
> >> with the corresponding netstat (thanks for the -l / -a tip!) reply:
> >>
> >> tcp 0 0 *:1700
> >> *:* LISTEN
> >>
> >> Is that what you meant? Does this wildcard create any security issues
> >> (exceeding those potentially present before by providing *any* TCP-
> >> accessible service)?
> >>
> > Do note that Rainer is wrong there. IP addresses are bound to an
> > interface, always. DNS may not care about that and give you just an IP
> > address if you know the hostname, but if you're trying to connect,
> > especially on a LAN or on a local machine, it is *important* that you
> > known which interface is being listened on.
>
> Sorry but Rainer is absolutely correct and you are absolutely wrong. It's
> an important concept, so I suggest you Google it.
You could at least give a reference: RFC 1122, section 3.3.4.2
'Multihoming Requirements'. It is an important concept, but it isn't in
any way related to the OP's question.
Rainer was (implicitly) talking about using a specific socket binding as
a means of filtering connections by *source* address. He is quite
correct this isn't possible on a weak ES; it's also just as stupid and
dangerous as any other form of filtering by IP that isn't backed up by
some more secure form of authentication.
The OP's problem was to do with a specific socket binding filtering
connections by *destination* address. This happens on all (not-
completely-broken) systems: even a vanilla unfirewalled Unix system
won't accept connections destined for one address on a socket bound to a
different address. It's often important to be careful about socket
bindings for this reason: for instance, a server that uses SSL or
Kerberos that thought it was serving on address A will fail to
authenticate connections where the client was trying to connect to
address B.
In any case, Unix systems can generally be configured as strong ESs now,
at least as far as requirement (A) (rejecting packets coming in on the
wrong interface) goes. Most firewall packages have some sort of
'antispoof' mechanism that does this.
Ben
------------------------------
Date: Wed, 22 Feb 2012 13:24:29 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <87sji3gfw2.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
>> On Tue, 21 Feb 2012 08:29:24 +0100, Mart van de Wege wrote:
>> > Wolfram Humann <w.c.humann@arcor.de> writes:
>> >>
>> >> So I would simply say Transports => ['TCP:Port=1700,Host=']
>> >>
>> >> with the corresponding netstat (thanks for the -l / -a tip!) reply:
>> >>
>> >> tcp 0 0 *:1700
>> >> *:* LISTEN
>> >>
>> >> Is that what you meant? Does this wildcard create any security issues
>> >> (exceeding those potentially present before by providing *any* TCP-
>> >> accessible service)?
>> >>
>> > Do note that Rainer is wrong there. IP addresses are bound to an
>> > interface, always. DNS may not care about that and give you just an IP
>> > address if you know the hostname, but if you're trying to connect,
>> > especially on a LAN or on a local machine, it is *important* that you
>> > known which interface is being listened on.
>>
>> Sorry but Rainer is absolutely correct and you are absolutely wrong. It's
>> an important concept, so I suggest you Google it.
>
> You could at least give a reference: RFC 1122, section 3.3.4.2
> 'Multihoming Requirements'. It is an important concept, but it isn't in
> any way related to the OP's question.
>
> Rainer was (implicitly) talking about using a specific socket binding as
> a means of filtering connections by *source* address. He is quite
> correct this isn't possible on a weak ES; it's also just as stupid and
> dangerous as any other form of filtering by IP that isn't backed up by
> some more secure form of authentication.
>
> The OP's problem was to do with a specific socket binding filtering
> connections by *destination* address.
The OP's problem was that he bound a socket to an address configured
on the host and then tried to connect to the server using the loopback
address. This didn't work and the second solution was to create two
server sockets, one bound to the public address and the other bound to
the loopback address. At this point, I suggested to bind to the
wildcard address instead since this will enable connections using all
addresses configured on the host with a single socket. Further, I
pointed out that this has no 'security implementations' since binding
to a destination address restricts the destination addresses a client
can use (should I really have repeated this explicitly since it was
demonstrated two postings ago?) BUT NOT the host interfaces which can
be used to reach this destination address, except if some system is
specifically configured to do so and systems usually aren't.
Please note that this has no relation to 'antispoofing': This refers
to doing some kind of plausibility check of a source address based on
the interface it arrived on, eg, drop the datagram if it was received
on an interface but the host wouldn't route datagrams destined at the
source address out of this interface (so-called 'reverse path' check).
Provided I have a computer in a LAN segment where a host which also
has an interface on another LAN segment has an interface, I can
configure a suitable 'host route' for the protocol address of the
other interface and reach that without going through an intermediate
gateway.
------------------------------
Date: Wed, 22 Feb 2012 02:27:29 -0800 (PST)
From: STD <mikesolomon40@googlemail.com>
Subject: use file::find to find files modified in last 5 days
Message-Id: <95788b86-f33b-4e5f-931e-49f0374a9b35@l14g2000vbe.googlegroups.com>
I have written a script to find files
I now want to be able to pass it a days parameter and only show files
modified in the last x days
How do I do this
My script so far is below
use strict;
use lib 'jumi';
use WebLib;
use File::Find;
use File::Basename;
my ( $folder, $tofind, $tofile, $exclude, $cs ) = @ARGV;
my @tofind = split '&&',$tofind;
#strip whitespace
@tofind = grep(s/\s*$//g, @tofind);
@tofind = grep(s/^\s*//g, @tofind);
foreach(@tofind) {print "|$_|<br>";}
print "<p>Excluded:<br>$exclude</p>";
find(\&wanted, $folder);
print qq {<script type="text/javascript">colourRows();</script>};
sub wanted {
my $file = $File::Find::name;
return unless -T $file;
return unless $file =~ /$tofile/;
return if $file =~ /$exclude/ && $exclude;
if ($tofind) {
open F, $file or print "couldn't open $file\n" && return;
my $file_contents = do { local $/; <F> };
close F;
my $print = 'Y';
foreach (@tofind) {
if ($cs == 1){
if ($file_contents !~ /$_/m) {$print = 'N'};
} else {
if ($file_contents !~ /$_/mi) {$print = 'N'};
}
}
if ($print eq 'Y'){
print qq {<tr><td><a href="index.php?
option=com_content&view=article&id=21&file=$file" target="_blank">
$file</a></td></tr>};
} #end if
} else {
print qq {<tr><td><a href="index.php?
option=com_content&view=article&id=21&file=$file" target="_blank">
$file</a></td></tr>};
}
------------------------------
Date: Wed, 22 Feb 2012 12:28:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <8l3f19-7ej.ln1@anubis.morrow.me.uk>
Quoth STD <mikesolomon40@googlemail.com>:
> I have written a script to find files
>
> I now want to be able to pass it a days parameter and only show files
> modified in the last x days
>
> How do I do this
The -M operator gives you the age of a file in days.
Ben
------------------------------
Date: Wed, 22 Feb 2012 13:07:52 +0000
From: Justin C <justin.1201@purestblue.com>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <8u5f19-lfp.ln1@zem.masonsmusic.co.uk>
On 2012-02-22, STD <mikesolomon40@googlemail.com> wrote:
> I have written a script to find files
>
> I now want to be able to pass it a days parameter and only show files
> modified in the last x days
Have a look at the 'stat' and 'localtime' functions, they should give
you a clue at to your next step.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 22 Feb 2012 05:34:53 -0800 (PST)
From: STD <mikesolomon40@googlemail.com>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <429cffe2-ebeb-4157-9913-0afca92d0dd8@eb6g2000vbb.googlegroups.com>
On Feb 22, 12:28=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth STD <mikesolomo...@googlemail.com>:
>
> > I have written a script to find files
>
> > I now want to be able to pass it a days parameter and only show files
> > modified in the last x days
>
> > How do I do this
>
> The -M operator gives you the age of a file in days.
>
> Ben
Thanks
I have now added
return unless -M $file < $days;
All working
Don't know why I didn't think of I before - doh
------------------------------
Date: Wed, 22 Feb 2012 05:37:40 -0800 (PST)
From: STD <mikesolomon40@googlemail.com>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <2a5626a0-4b2d-4be8-80ee-381c0d3437ba@do4g2000vbb.googlegroups.com>
On Feb 22, 12:28=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth STD <mikesolomo...@googlemail.com>:
>
> > I have written a script to find files
>
> > I now want to be able to pass it a days parameter and only show files
> > modified in the last x days
>
> > How do I do this
>
> The -M operator gives you the age of a file in days.
>
> Ben
Thanks
Don't know why I didn't think of a simple -M test
Now all working
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3618
***************************************
