Free registry routing software for linux

DCE::Registry is a Perl interface to DCE Registry API.

SYNOPSIS

use DCE::Registry;

my $rgy = DCE::Registry->site_open($site_name);

This module provides an OO Perl interface to the DCE Registry API. The sec_rgy_ prefix has been dropped and methods are invoked via a blessed registry_context object.

BitWise Routing Server allows multiple PCs behind a router to make direct connections.

The BitWise Routing Server allows you to accept BitWise connections to multiple computers behind a router. Typically, using a router, you would set up port forwarding on BitWises client port (4137), and specify a single destination IP. This is fine until multiple users behind a router all need to accept incoming connections.

As shown by the picture at right, the Routing Server allows individual users to register themselves with the Routing Server, and then the Routing Server accepts all incoming connections and directs those connections to the appropriate user.

The Routing Server requires that your physical router support port forwarding with a way to specify different external and internal ports (this is sometimes labeled "UPnP" by many common home routers).

The Routing Server has several options allowing you to customize the Routing Server for your environment. Many of the options are self-explanatory. The two that are not are Listen on Port and IP filtering. IP filtering is explained in the next section.

The BitWise Routing Server listens on a different port than the BitWise IM client. This allows the Routing Server and the IM client to be run on the same computer without causing conflicts. You will want to set up your router (more detail in a later step) to shift the port of the incoming connections from 4137 to another port. It doesnt particularly matter which port you want to use, as long as it is not a port used by another program. The default port is 4200.

Depending on the complexity of the network, it may be desirable to filter the IP addresses that are allowed to register with the Routing Server. This can be done in the preferences. One very likely scenario would be limiting registrations to the 192.168.1.x IP addresses (192.168 is reserved for local networks). When specifying an IP as the comparison address, you can use any valid IP numbers for wildcards.

In the case shown here, the Routing Server will limit connections to computers having IP addresses of 192.168.1.x. Any number, 0 through 255, could be placed for x in the Routing Server preferences.

If you are not familiar with IP address classes and IP filtering, it will usually be safe to leave Any selected.

Setting up the physical router

The picture at right was taken from a Linksys router, other routers will have a similar capability, although it may be layed out differently. On some routers, the advanced port forwarding options are mistakingly labeled UPnP.

The router setup shows that we are accepting connections on port 4137 and then sending them inside the network on port 4200 (the default port). Enter the IP address of the machine on the network running the Routing Server, and make sure that the rule is enabled. You will want to enter a rule for both TCP and UDP (UDP is used only for voice).

Please consult your router manual for more detailed instructions about how to set up port forwarding on your specific model.

Configuring BitWise to use the Routing Server

In order for you to enjoy the connectivity benefits of the Routing Server, you will need to register with the Routing Server when you log in to BitWise. Prior to logging in to BitWise, click the Setup button next to the Connect button to open the BitWise Setup. There is an area to enter an address for the Routing Server, and to specify what port to use. The port must be the same as the port used above (4200 is the default).

Upon connecting to BitWise, you will be registered with the Routing Server. If you could not be registered, an error message will be displayed. Double-check that the correct address was entered in the Setup.

Registration with the Routing Server

Upon successfully registering with the Routing Server, the Routing Server will display the user name and the IP address of the registration. If you want to unregister a user, click on the username, and then click Unregister. Incoming connections will no longer be forwarded to the specified computer.

It is worth pointing out two things here. First, if you later log in from a different computer, and that computer is also set to use the Routing Server, you will be re-registered with your new IP address. Second, if you are unregistered, or move to another computer but are not set up to use the Routing Server, you will not be able to benefit from the services of the Routing Server.
By default, the Routing Server saves the registered user list when it is closed down.

Using the Routing Server

Assuming that everything is set up correctly, everyone that registers with the Routing Server when they log in to BitWise will be able to enjoy significantly increased connectivity with other BitWise users. As incoming connections are established, you will see the connections listed in the right pane of the Routing Server window. The IP address and the time of the connection is also displayed, and the connection is later marked when it is disconnected.

The disconnected/closed connections may be cleaned from the list at any time using the Clean List button. Only active connections will be left displayed.

saml-registry is a SAML 2.0 Metadata management tool that is useful for building shibboleth-based federations.

The saml-registry is a j2ee-application intended as a federation management tool, primarily (but not exclusively) for use with shibboleth. Future versions will support full delegation of rights through container-based role-management. The current version relies on container-based authentication.
For convenience the current version of the sql database schema and a jboss datasource descriptor sample can be found here on the right.

Installation instructions

Download the ear-file from the maven repository and drop it in the deploy-directory of your jboss application server. This build has been tested with jboss 4.0.2 but later versions should work.

You may need to disable certain features in a standard jboss, notably the jboss-ws4ee.sar (which conflicts with webservices provided by saml-registry) - just remove it from the deploy directory. Newer versions of jboss may ship with included versions of myfaces and jsf. These files must also be removed from your jboss before deploying saml-registry (or you must repackage the application excluding these libraries from the ear).

Next create a datasource-file for the mysql datastore. The < jndi-name/ > must be set to jdbc/saml-registry. Now create the database (update the datasource file with the server, username and password). Drop this file next to the ear in the deploy-directory. Use the sql schema to populate the database.

Finally configure authentication and authorization for saml-registry. This is done in the container by editing the login-config.xml (for jboss). Create a security domain called saml-registry in login-config.xml. The attached login-config.xml contains a sample entry which is based on property-files. The UsersRolesLoginModule is described on the jboss wiki.

The authorization for saml-registry is also managed by the security domain using standard j2ee role-based security. The roles govern access to individual use-cases (represented by menu entries in the user interface). Future versions will add per-organizational access control to this basic framework so that management of entities can be delegated.

The use-cases and roles is documented by this usecase diagram. Once your security-domain is configured to serve these roles (by editing property-files or whatever) you should be able to point your browser to https://your-box.example.com/saml-registry and get the main menu (or a login page depending on how your security domain was setup).

Building from source

In order to build saml-registry from source (which can be obtained from the subversion repository) you need maven2 and java5 to build the sources. The saml-registry is based on an MDA toolchain called andromda. Normally maven2 should download and install all dependencies, however the user interface needs the jsf2 cartridge from the andromda plugins project which may not be distributed from the andromda maven repository. If maven2 complains about unresolved dependencies for jsf2 then checkout the andromda plugins project and build it manually.

Resource Registries is a product for Plone used for linked style sheet files and javascripts.
A registry for linked Stylesheet files and Javascripts.
This registry is mainly aimed at solving the following usecases:
- Enable product authors to register stylesheets with their product installers without having to resort to override either header.pt or ploneCustom.css creating potential conflicts with other products.
- Enable more componentialization of the stylesheets provided with Plone (and other products) without having to increase the number of http requests for a Plone page.
- Enable condition checking on stylesheets. Great for variable look-and-feel for groups/roles/folders/departments/content-types/etc
- Enable inline dynamic stylesheets. For those style rules that should vary for each request. Mainly used for things like header-bar- backgroundimages, department colors etc.
- Enable developers to activate/deactivate their styles in a simpler way
- Enable compression to safe bandwidth and download time
Enhancements:
- Fixed encoding HTTP header for javascripts.

Routing incoming ppp0 is a netfilter firewall.

Sample:

#!/bin/bash

# Load required modules
insmod ip_tables
insmod ip_conntrack
insmod iptable_nat
insmod ipt_MASQUERADE

# Then flush all rules
iptables -F
iptables -t nat -F

# In the NAT table (-t nat), Append a rule (-A) after routing
# (POSTROUTING) for all packets going out ppp0 (-o ppp0) which says to
# MASQUERADE the connection (-j MASQUERADE).

#iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Below means route 192.168.1.x
iptables -t nat -A POSTROUTING -d ! 192.168.1.0/24 -j MASQUERADE

iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -s ! 192.168.1.0/24 -j DROP

# Disallow NEW and INVALID incoming or forwarded packets from ppp0.
#iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP
#iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j DROP

# port 113 is evil ;)
iptables -A INPUT --protocol udp --source-port 113 -j DROP
iptables -A INPUT --protocol udp --destination-port 113 -j DROP

# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

#iptables -A INPUT --protocol udp --source-port 113 -j DROP

# Route incoming ppp0 at port 80, to 192.168.1.18:80
iptables -A PREROUTING -t nat -p tcp -i ppp0 --dport 80 -j DNAT --to 192.168.1.18:80

# Route incoming ppp0 at port 21, to 192.168.1.18:21
iptables -A PREROUTING -t nat -p tcp -i ppp0 --dport 21 -j DNAT --to 192.168.1.18:21

RegLookup project is an small command line utility for reading and querying Windows NT/2K/XP registries.
Currently the program allows one to read an entire registry and output it in a (mostly) standardized, quoted format. It also provides features for filtering of results based on registry path and data type.
Enhancements:
- This release contains some additional functionality and numerous bugfixes.
- Important changes include vastly improved interaction with the underlying registry library with a new API, improved parsing of ACLs, a fix for a possible security problem, and the elimination of many memory leaks.

Hegons project is a HEterogeneous Grooming Optical Network Simulator that supports mixed routing and wavelength assignment algorithms and optional wavelength conversions capability on each node.
The goal of Hegons is the evaluation of different dynamic routing and wavelength assignment (RWA) algorithms in WDM optical networks in terms of several measures such as: call blocking probability, fairness (variance in blocking probability), call setup time, etc.
Main features:
- Supports practically unlimited number of nodes in a network. (2 billion)
- Supports practically unlimited number of wavelengths per link. (2 billion)
- Typically, can simulate more than 18 million calls per minute on a 2Ghz PC.
- Currently Supports 3 types of nodes (OXCs):
1. Non Grooming node
2. Single-Hop Grooming node
3. Multi-Hop Full Grooming node
Each node can optionally be a wavelength converter node.
4 wavelength assignments (WA) algorithms:
1. First Fit (FF)
2. Random (R)
3. Most Used (MU)
4. Least Used (LU)
- Fixed Alternate Routing (FAR) is supported with 4 different ordering algorithms: FF, R, MU, LU
- Shortest Path Routing (SPR) can be supported by using -mp:1 option.
- Call arrivals follow the poisson distribution.
- Can run multiple batches (separate simulation runs) automatically and find the average results of all batches.
- Three different methods to calculate the blocking probability. Can be controlled by modifying the BP_METHOD compiler directive.
- Average number of attempts for each call can be limited using the -at option.
- Maximum and minimum path length can be controlled.
- Maximum number of paths generated for each source to destination pair can be controlled
- Network description can be loaded from a file or can be feeded interactively by the user.
- Results can be saved to CSV (Comma Separated Values) files for easy batch running. CSV files can be then viewed in Excel and charts can be generated instantly.
Enhancements:
- A new "Multi-hop Partial Grooming" node type was added.
- A partial grooming node can now have multiple G-fabrics.
- This is a new concept that has never been discussed in the literature.
- The RWA method chosen will be applied internally in the nodes between W and G fabrics as well as externally.
- -px and -pn options were added for controlling the max/min number of times G-fabric switchings are done per call.
- Other minor fixes and changes were made.