Ports Search

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