Free responder software for linux

The OpenCA OCSP Responder is an RFC 2560 compliant OCSPD responder. It can be used to verify the status of a certificate using from OCSP clients (such as Mozilla/Netscape7).
The Responder is actually included into the main OpenCA distribution package. It is also possible to install the daemon as a stand-alone application, all you will need is a CRL (or access to an LDAP server where to get the CRL from).
Actually not extensive testing has been carried out, anyway this daemon is reported to work with Mozilla/Netscape. If you have carried out some testing and want to discuss it with us, please just send an e-mail or subscribe the openca mailing lists.
To install the package follow the provided INSTALL script and edit the config file to fillfull your needs. Remember that youll need the 0.9.7 version of the OpenSSL package - current source code (0.9.7d).
Whats New in 1.1.1 Stable Release:
- The requirement for the index file option in the configuration file has been removed (it was not used).
Whats New in 1.5.1 RC1 Development Release:
- Thread support was added.
- HTTP header parsing was improved.

Hardware::Simulator is a Perl extension for Perl Hardware Descriptor Language.

SYNOPSIS

use Hardware::Simulator;

# NewSignal( perl_variable [, initial_value]);
# create a signal called $in_clk, give it an initial value of 1
NewSignal(my $in_clk,1);

# Repeater ( time_units , code_ref)
# every time_units, call the code reference, starting at the current time
Repeater ( 5, sub{if ( $in_clk==0) { $in_clk=1;} else { $in_clk=0;}});

# Responder ( [signal_name ... signal_name], code_ref );
# respond to any changes to signals by calling code reference.
# any time out_clk changes, print value of clock and simulation time.
Responder ( $out_clk, sub
{
my $time = SimTime();
print "out_clk = $out_clk. time=$timen";
});

# start processing of events and event scheduling.
EventLoop();

Hardware::Simulator ==> a Perl Hardware Descriptor Language

Hardware::Simulator is a lightweight version of VHDL or Verilog HDL. All of these languages were developed as means to describe hardware.

Hardware::Simulator was created as a means to quickly prototype a basic hardware design and simulate it. VHDL and Verilog are both restrictive in their own ways. Hardware::Simulator was created to quickly put something together as a "proof of concept", to show that a design concept would work or not. and then the design could be translated to VHDL or Verilog.

The problem that started all of this was designing a fifo for a video scaling asic. The chip used a buffer to store incoming video data. The asic read the buffer to generate the outgoing video image. We estimated how large we thought the buffer needed to be, but we wanted to confirm that our numbers were right by running simulations.

The problem was we needed to run hundreds of different simulations, given the permutations of input image formats, output image formats, and input/output clock frequencies. We also had text files containing valid formats and frequencies. A text file as input called for perl to manipulate, split, format, and extract the data properly.

This data then had to be translated onto the a HDL simulation. The problem was that there was no easy way to write a perl script that would simulate hardware, so the only solution was to have perl drive a Verilog simulator and pass all these parameters via command line parameters. so then verilog files had to be created, and the simulator had to be driven, and the end result was a lot of work to simulate a simple fifo.

Time contraints did not allow me to develop a HDL package for perl to solve the original problem, but I took it on in my spare time. and eventually Hardware::Simulator was born.

The ICMP Hostname Tools for Linux include a responder daemon, a lookup tool, and a nameswitch module to handle ICMP host name functions.

The NSS module caches all requests (including failures) and honors the TTL value sent by the responding host. It uses a configuration file called /etc/nss-icmp.conf, which controls different aspects of its operation:

* timeout – Sets the timeout in milliseconds for ICMP host name queries, by passing the -t option to idnlookup.
* nocache – Disables the cache.
* ttlnotfound – Sets the TTL for not-found cache entries is seconds. The default is 5 minutes.

Both icmpdnd and idnlookup need to run as root, due to the fact that they use ICMP. Thus, idnlookup needs be installed SUID root.

Vacation is a Horde module for managing user e-mail "auto-responders" or "vacation notices". It works via a local vacation program which must be installed and functioning on the server. It supports vacation programs using the .forward-style forwarding mechanism supported by several popular mailers.

Right now, Vacation provides fairly complete support for managing .forward style vacation notices on Sendmail or Courier mail based systems via an FTP transport. It also has some support for LDAP, Qmail, and Exim SQL based servers.

Vacation is part of a suite of account management modules for Horde consisting of Accounts, Forwards, Passwd, and Vacation.

EMailRobot is a simple object-oriented framework for developing email auto-responders.
It performs actions based on parameters extracted from received email bodies and generates answer emails.
Enhancements:
- Minor fixes were made and documentation and installation notes were added.

Jabber::RPC::HTTPgate is an HTTP gateway for Jabber-RPC / XML-RPC.

SYNOPSIS

use Jabber::RPC::HTTPgate;

my $gw = new Jabber::RPC::HTTPgate(
server => myserver.org:5701,
identauth => jrpchttp.localhost:secret,
httpcomp => http,
);

$gw->start;

Jabber::RPC::HTTPgate is an experimental gateway that provides a conduit service between traditional (HTTP-transported) XML-RPC encoded requests/responses and Jabber-RPC (XML-RPC encoded requests/responses transported over Jabber).

The idea is that you can start a gateway, that connects as a component to the backbone of a Jabber server, and it proxies Jabber-RPC to HTTP-based XML-RPC endpoints, and vice versa. That means that your Jabber-RPC client can not only make XML-RPC encoded calls to a Jabber-RPC endpoint but also to a traditional HTTP-based XML-RPC endpoint. And it also means that your traditional HTTP-based XML-RPC client can make XML-RPC encoded calls to a Jabber-RPC endpoint.

Jabber -> HTTP

When you create and start up a gateway, it listens for Jabber-RPC calls, just like a normal Jabber-RPC responder. On receipt of such a call, the gateway creates an HTTP request and sends this request on to the HTTP-based XML-RPC endpoint. The response received back from this HTTP call is relayed back to the original Jabber-RPC requester.
While a Jabber-RPC endpoint address is a Jabber ID (JID), an traditional XML-RPC endpoint address is a URL. So all the Jabber-RPC client needs to do is specify the URL in the resource part of the gateways endpoint JID.

HTTP -> Jabber

As well as listening for Jabber-RPC calls, a gateway will also service incoming HTTP requests that can be made to the HTTP component that this gateway uses. The HTTP component (called simply http) can be downloaded from the normal Jabber software repository.

On receipt of an HTTP request (passed to it by the HTTP component), the gateway creates a Jabber-RPC request containing the XML-RPC encoded payload, and sends it on to the Jabber-RPC responder endpoint. This endpoint is identified (via a JID) by the path part of the URL used in the call by the traditional client.

mdns-scan is a tool for scanning for mDNS/DNS-SD published services on the local network. mdns-scan issues a mDNS PTR query to the special RR _services._dns-sd._udp.local for retrieving a list of all currently registered services on the local link.
mdns-scan is not a good mDNS citizen since it queries continuously for services and doesnt implement features like Duplicate Suppression. It is intended for usage as a debugging tool only.
mdns-scan is incomplete since it doesnt resolve mDNS services for you - it just dumps their PTR RRs. To understand these records you need minimal knowledge of DNS-SD and how it works.
mdns-scan does not terminate on its own behalf. It scans for services continuously until the user kills it by pressing C-c.
mdns-scan does not rely on a local mDNS responder daemon. It has no dependencies besides the GNU libc. It has been tested on Linux only.
mdns-scan does NOT scan for local mDNS enabled hosts or A/AAAA RRs, it scans for DNS-SD registered services, nothing else.
Enhancements:
- Add man pages
- Improvements to the Debianization