Free running programs software for linux

The goal of RUMT is to check the memory of a computer over a long period of time and almost-real load conditions without having to interrupt the services.

RUMT exploits the possibility of some Unix kernels to selectivly disable some memory areas while still accessing them through the /dev/mem device. The principle of RUMT is to write pseudo-random data in these disabled memory areas, and later check them. This principle and the original code for the deterministic pseudo-random generator are from David Madore.

This distribution contains another variant on the same theme: URUMT allocates a large chunk of memory, locks it in memory using the mlock(2) system call, and scans /dev/mem to find where in physical memory the allocated area is. Then it continuously runs the same tests in that memory.

URUMT can not be used to test a particular area of memory: the kernel will give it whatever physical memory it feels like. But URUMT can be restarted now and then, hopefully getting different physical memory each time.

This is perfect if you suspect you have bad bits, but do not know at all where they are. Once you have sighted the bad bits, you can use a plain RUMT to test more extensively the neighborhood.

Program Guard allows the user of a Linux workstation to specify which application programs that are allowed TCP/IP connections to the Internet (Internet addresses are defined as any IP address not in the range of 10.0.0.0/24 or 192.168.0.0/16).

The application program names can be specified by listing them in a file (Static Mode) by querying the user (Query Mode). In Query Mode, when a program that is unknown to Program Guard attempts to access an Internet IP address, Program Guard displays the Program Guard Dialog Box.

In addition to providing connection information, this dialog box gives the workstation user the option of allowing the program to access the Internet or to be blocked from accessing the Internet. This can be done either for the current instance of the program or for this and all future instances of the program (Make Persistent checkbox).

Currently, the program names that are allowed or denied Internet access apply to all users of the workstation rather than on a per user basis. For example, if Program Guard is running in Query Mode and user A invokes a program previously blocked from Internet access by user B, the program will be blocked from Internet access for User A as well.

Connections blocked by Program Guard are logged to the Program Guard log file pgrd.log. It is located in the /var/log/pgrd directory. If desired, Program Guard can be configured to log all Internet connection attempts rather than just those that have been blocked.

Program Guard was tested on Fedora Core 1 and Fedora Core 3 on single processor 32 bit X86 Intel processors. It has not been tested on other distributions or on multi-processor machines. While it works on Fedora Core 1, it will not build on a standard Linux 2.4.x kernel due to task_struct definitions that were not made until Linux 2.6. If there is enough interest, a version that runs under a standard Linux 2.4 kernel may be made available.

To run in Query Mode, Gnome 2.x and Glade 2.x are required. There are no prerequisites for Static Mode.

Installation:

Program Guard consists of three components: a kernel module; a daemon; and a Gnome GUI user interface component. All files needed to build the components are in the pgrd.tgz file. An installation shell script install-pgrd is provided for Fedora distributions.

It will build/install (or remove) the kernel module and daemon as well as configure them to be started automatically when the system is booted. To invoke it, type install-pgrd < install | remove >. This script may or may not be useable as is for other Linux distributions.

If you modify the install script, please note that the module, daemon and various support files must be installed in the /opt/pgrd directory for Program Guard to work properly (this is already handled when using the install script as provided). To run in Query Mode, each user must be configured by invoking the install-pgrd_user < username > script. And by going to the Preferences->More Preferences->Sessions selection in the Fedora Main Menu and adding pgrdgui to the Startup Programs tab.

Program Guard will be started the next time the machine is rebooted. If you do not wish to reboot, you may start Program Guard manually as described below in Manual Starting And Stopping. Note: If starting manually and using Query Mode, once the daemon and kernel module are started, make sure that you log out and log back in.

pvswitch is a very tiny program which makes it possible to use different program installations on one machine flawlessly.
Its flexibility is intended for people who need to run programs against different interpreter versions.
But it can also be used for different purposes like switching the version of a compiler, text editor, mail reader, browser, whatever.
It is most useful for developers of interpreter based programs which are started via a hash-bang line (#!).
The following example explains the usage for perl programs, but the very same is true for all other interpreter languages.
If you install two or more different perl versions on your machine, you could just call the respective perl binary you want to use..
perl myscript.pl
/path/to/another/perl myscript.pl
This works fine, although it isnt very convenient. However if you are starting your program using the hash-bang line like
#! /usr/bin/perl
and then just start it by
./myscript.pl
you would need to change the file itself to use another perl version. Again it is possible, but not very convenient.
And here comes pvswitch: its purpose is to make such situations convenient. Further it solve some problems which come up if multiple people want to use different perl versions. pvswitch allows even to run one program in two shells with different perl versions.
This is possible because pvswitch uses a environment variable to select the interpreter version to use. This environment variable can be set in different sessions independently.
pvswitch is installed as new program binary (e.g. perl) the old one will be renamed to program.pvswitch.
Now every time you execute a this program (e.g. perl), pvswitch is executed. It doesnt matter how you start the program...
perl myscript.pl
./myscript.pl # if it has a hash-bang #! /usr/bin/perl
for both cases the pvswitch binary will be executed, pvswitch will than check for the environment variable PVSWITCH_PERL_BINARY (if you are running perl), if it is found it tries to find this key in the configuration file pvswitch.conf and execute the program which is configured for the version configured set in the environment variable (e.g. perl.pvswitch).
So it just executes the real program (e.g. perl interpreter). Depending on the environment a different version might be selected.
There are some convenient tools (e.g. perlver, pvconfig) to configure this.
Enhancements:
- Fixed a bug which could cause segmentation violation.

nJin4 project is a tool to scan for SQL/PHP injection vulnerabilities in PHP source code and in a running Web application.

LinkController is a group of programs designed to take away much of the work of maintaining the links in a web site. Instead of the user running the program checking whether links are broken, LinkController does this automatically. When it finds a broken link it checks it several times across several days before reporting it broken. This means that if a link is repaired in the meantime (a common case), the user will never be bothered.
All the functionalities are in place for testing links and repairing problem identified. The software is under development so stability is totally not guaranteed, but then with the exception of the fix-link program, there shouldnt be much risk of data loss so dont worry and make sure you backup your web pages just like normal.
Main features:
- repeatedly checks a link before declaring it broken
- rapid repair of links based on database
- easy but configurable reporting
- access to pages requiring authentication (new/experimental)
- CGI pages for reporting and repair
- scalability - thousands of links across thousands of pages possible
- low network impact: slow checking and well spread
- low resource utilisation: mostly uses HEAD requests
- configurability
- designed for multi-user use
Enhancements:
- Bugfix for checking of incorrect links which get into the database somehow.

kcurses are some simple widgets and ui abstractions for ncurses, to handle list boxes, vi-like editing fields, mouse selections, and the like.

Why?
Because sometimes gui programs are more annoying than helpful. web interfaces suck, and gtk/qt programs take up too much real estate, require too much mousing, and i find the apis a little too heavyweight for what i often need. i needed a simple curses-based database editor, and, finding no widgets that i needed, had to write my own.

Installation:
get the source
do the usual ./configure --help; ./configure; make; rigamarole
test by running make test. you should see a couple programs float by.
make install, to taste