This is a tool that uses ARP poisoning to have a scenario
like this: we have a LAN and we want offer connectivity to every-
one coming here with his laptop for example. It could happen that
our customer has his network parameters already configured to
work correctly in his own LAN, but not working here. We can have
then this scenario:
Customer's host (10.0.0.2/8 and default gateway set to 10.0.0.1)
Our LAN (192.168.0.0/24 with real gateway 192.168.0.254).
All that we want is that our customer plugs his laptop and joins
the internet without changing nothing of his network parameters.
Here comes this tool installed in my real gw(192.168.0.254) It's
a sort of sniffer, because it sniffs broadcast ARP requests for
the gateway and answers that the gateway is itself In our example
our customer's laptop sends this request: arp who-has 10.0.0.1
tell 10.0.0.2 Now our gateway does the following: 1) Sends back
this reply to 10.0.0.2: arp reply 10.0.0.1 is-at his_mac_address
2)Create the alias 10.0.0.254 (ARP is not routable so we need one
alias for each subnet that is not our one) 3)Sends itself an ARP
reply to refresh his ARP cache
It is different from proxy arp for two reasons: first it runs in
user space, then in this case we can plug machines belonging to
whatever subnet, while proxy arp is used in the case of only two
different ones.
daemontools-encore is a collection of tools for managing UNIX services.
It is derived from the public-domain release of daemontools by D. J.
Bernstein. daemontools-encore adds numerous enhancements above what
daemontools could do while maintaining backwards compatibility with
daemontools. See the CHANGES file for more details on what features
have been added.
This is a module for finding IP addresses in plain text.
NetAddr::IP::Find exports one function, find_ipaddrs(). It
works very similar to URI::Find's find_uris() or
Email::Find's find_emails().
$num_ipaddrs_found = find_ipaddrs($text, \&callback);
These tools are used to convert XML and HTML to and from a line-oriented
format more amenable to processing by classic Unix pipeline processing
tools, like grep, sed, awk, cut, shell scripts, and so forth.
The line-oriented format used by these tools looks very much like, but
is not quite precisely the same as XPath.
Catalyst::View::TT::ControllerLocal is like a normal Catalyst TT View,
but with template file names relative to the current Controller. So
with a set of templates like:
./root/edit.html
./root/add.html
./root/Frobniz/add.html
and an action "add" in the Controller "MyApp::Controller::Frobniz", you
set "$c->stash->{template}" to "add.html" in order for it to pick up
the "./root/frobbiz/add.html" template.
Setting the "$c->stash->{template}" from Controller "MyApp::Con-
troller::Bogon" would instead pick the default template in
"./root/add.html" (since there is no Bogon subdirectory under root).
In addition, since there is no file "edit.html" except in the Frobniz
directory, C::V::TT::ControllerLocal will default to looking for
"edit.html" in ./root/ and ./root/base (or whatever you set MyApp->con-
fig->{INCLUDE_PATH} to).
The object of the game is to remove all tiles from the field. Only two
matching tiles can be removed at a time. Two tiles can only be removed
if they can be connected with at most three connected lines. Lines can
be horizontal or vertical but not diagonal. Remember that lines may
cross the empty border. If you are stuck, you can use the Hint feature
to find two tiles which may be removed.
Tk::Role::Dialog is meant to be used as a Moose role to be composed for easy Tk
dialogs creation.
It will create a new toplevel with a title, and possibly a header as well as
some buttons.
One can create the middle part of the dialog by providing a _build_gui() method,
that will receive a Tk::Frame where widgets are supposed to be placed.
The attributes (see below) can be either defined as defaults using the
_build_attr() methods, or passed arguments to the constructor call. The only
mandatory attribute is parent, but you'd better provide some other attributes if
you want your dialog to be somehow usable! :-)
This is a port of Emmanuel Dreyfus' milter-greylist.
Grey listing is a wonderful spam filtering technique, which uses a behavior
trick: spammers never resend a message when they get a temporary error,
whereas real MTA do. The idea is to refuse any mail on first attempt, and
accept it after some time has elapsed.
milter-greylist is a stand-alone milter written in C that implement grey
listing.
This is a port of Emmanuel Dreyfus' milter-greylist.
Grey listing is a wonderful spam filtering technique, which uses a behavior
trick: spammers never resend a message when they get a temporary error,
whereas real MTA do. The idea is to refuse any mail on first attempt, and
accept it after some time has elapsed.
milter-greylist is a stand-alone milter written in C that implement grey
listing.
nagiosplugin is a class library which helps writing Nagios (or
Icinga) compatible plugins easily in Python. It cares for much of the
boilerplate code and default logic commonly found in Nagios checks,
including:
* Nagios 3 Plugin API compliant parameters and output formatting
* Controller to handle the general plugin control flow
* Full Nagios range syntax support
* Automatic threshold checking
* Multiple independend measures and overall state logic
* Long output and performance data
* Timeout handling
* Default options
* Persistent "cookies" to retain state information between check runs