Free craftsman spy software for linux

Craftsman Spy is a an open source and free framework for JDBC logging. Craftsman Spy is a JDBC driver implementation.

This logger logs all SQL connection and processings with execution spent time, all the stored procedures with arguments, all the batch processings and the result sets.

No need to modify your application in order to integrate JDBC logging with Craftsman Spy. The application MUST use the craftsman.spy.SpyDriver and MUST be launched with the -Dspy.driver=... system property.

Be carefull this JDBC driver SHOULD not be used in production mode. Use it only in development or pre-production system.

,b>Usage:

Code

The two solutions can be used as the following examples :
System.setProperty("spy.driver","vendor.database.Driver");// or with the -Dspy.driver=vendor.database.Driver JVM option
Class.forName("craftsman.spy.SpyDriver");
Connection c = DriverManager.getConnection("jdbc:database:mydata");
Class.forName("craftsman.spy.SpyDriver");
Connection c = DriverManager.getConnection("jdbc:spy:vendor.database.Driver:database:mydata");

Log configuration

The log4j.properties or log4j.xml configuration file SHOULD contain the following lines :
log4j.category.craftsman.spy=DEBUG, SpyFile
log4j.appender.SpyFile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.SpyFile.DatePattern=.yyyy.MM.dd
log4j.appender.SpyFile.File=spy.log
log4j.appender.SpyFile.layout=org.apache.log4j.PatternLayout
log4j.appender.SpyFile.layout.ConversionPattern=%m%n

Header Spy is an extension which shows HTTP headers on statusbar.
Main features:
- Up to 5 statusbar panels;
- Request and response headers;
- Custom headers;
- Tooltip headers;
- Menu with headers for statusbar panels;

RearSite is a simple collaborative Web site manager. RearSite is an automated Web publishing tool allowing to control who is allowed to access the published documents and also to manage per directories collaboratives tools well adapted to distance learning (forums, chats, shareable calendars, or multimedia quizzes).

An administrator can create users accounts (user name, user passwd, and user home directory), users get logged in and then receive access to their documents.


RearSite is written in PERL (CGI.pm based) and use a FastCGI compliant HTTP server (like APACHE).

Using RearSite is quite simple : after login, the user has access to his home dir and is able to delete, rename, create and edit documents. RearSite is well adapted to install WWW directories previously cooked (using any editors). Its very easy to transfer and install archives (ZIP, tar or tar.gz by now), they are automatically unpacked.

Published documents are public (by default), access restriction may be done using user/password couples, DNS domains or LDAP filters.

The user interface is WWW forms like, so RearSite only needs (on the client side) a Java, JavaScript and frames compliant WWW browser (accepting cookies).

RearSite is now quite secured, the login process (developped in Java) use an MD5 encryption of the user password (combined with a one time key). So, people spying the network cannot use the keys they may have seen. After login, users receive a cookie associated with their computers IP numbers.

RearSite also allows the user to specify who can retrieve his documents by configuring access rights :

documents are public (the default).
documents are restricted to users coming from trusted domains.
documents are restricted to users coming from trusted domains or to HTTP authenticated users.
* documents are restricted to class of users existing in an LDAP directory. This kind of HTTP client authentication needs auth_ldap for Apache (See restricted access by users classes).

Since 1.1, if the administrator wants it, the user is able to use templates to specify per directories access rights. By default (and as an example), the user can easily say that a directory is public, for frenchies only or for frenchies excepted those in the ripoux.fr domain (french joke!).

The user is also able to share his directories with other RearSite users (trusted users). When a directory is shared, a trusted user user is able to delete, rename, add ... files within the directory he received rights for.

The user is also able to recursively process all the file names of all his embeded directories. The functionality provided is to rename all files (lowercase, replace a string within all file names, ...) which simplyfies migration from systems with case-insensitive file names. These functionalities are available by selecting the Special tools button which also give a way to export the current directory within an archive (ZIP or tar.gz).

Since 1.4, a forum can directly be attached to each directories. When a user wants to create a forum, the result is a Forum.html file located within the current directory. This file will give access to the forum. People having access to this file are allowed to post in the forum.

Since 1.6, a chat can directly be attached to each directories. When a user wants to create a chat, the result is a Chat.html file located within the current directory. This file will give access to the chat. People having access to this file are allowed to talk in the chat.

Since 1.9, a shareable calendar can be directly attached to each directories. When a user wants to create a calendar, the result is a Calendar.html file located within the current directory. This file will give access to the calendar. People having access to this file are allowed to read the calendar. Only the owner of a calendar is allowed to update it, but he may allow other users. Accessing his calendar via RearSite allows the owner to update it immediatly. When accessing a calendar via a normal WWW access, the user (owner or not) must be authenticated (via Rearsite configured authentication scheeme) before being allowed to update it.

The chat,forum and calendar functionalities are accessible via the Communications button, they have been designed for distance learning purposes but can easily be used for any groupware needs.

KSetiSpy is a KDE utility that monitors the progress of the SETI@home client, and displays all kinds of information about the work unit(s) being processed.
It uses the same interface as SETI Spy, a Windows program written by Roelof Engelbrecht.
The SETI@home project started in May 1999; its goal is to harness the power of distributed computing to analyze radio signals from space, for "the small but captivating possibility of detecting the faint murmur of a civilization beyond Earth".
To participate in this exciting project, all you have to do is to run the SETI@home client program. This program downloads a set of data (usually called "work unit") from the SETI@home servers, processes it on the local machine (using idle processing time that would otherwise go wasted), and then transmits the result back to the servers.
Over time, SETI@home participants people have become more and more interested in learning everything about the data contained in these work units and the computations done on them. To address these needs, several SETI@home monitoring add-on programs were developed. These extract interesting information from the SETI@home client and present it in a user-friendly way.
One of the most complete SETI@home monitoring tools available today is a Windows program named SETI Spy. KSetiSpy has been created with the intent of providing a version of SETI Spy for my favorite desktop environment (KDE). KSetiSpy borrows most of its user interface conventions from SETI Spy, so SETI Spy users will feel immediately at home with KSetiSpy.
KSetiSpy started as a programming experiment in KDE in June 2001, and has grown a lot since then, mainly to keep up with the ever-increasing feature set of its Windows counterpart. Like many open source projects, its basically the work of a single developer (that would be me), working on it on his spare time. Therefore advancement is not linear, and debugging is mostly left to the users (that would be you). If you run into a bug, please report it to Roberto Virga
Enhancements:
- fixed RA and Dec formatting
- fixed julian date conversion (was off by 6 hours - thanks to Bengt-Erik Soderstrom for reporting this)
- fixed constellation links (the P.A.S. re-organized their web site)

Hydranode Core is a modular, plugin-driven peer-to-peer client framework which is designed with true multi-network downloads in mind.
Hydranode Project can be used directly via the built-in shell functionality, or via external user interfaces.
To achieve the large number of features described in the previous section, HydraNode core needs to be extendible without causing feature bloat and increase in system requirements resulting from that. The only way to accomplish that is make the application completely modular - only a minimum set of features are provided by the core application; the rest of the features are implemented by optional loadable modules. Each file-sharing network should be in a separate module, as should be other additional features like e-mail notifications. With this design, the features are de-coupled from each other, thus greatly simplifying the debugging process, and allowing end user to select only the features he or she needs instead of what a programmer thought was best for him or her.
Second most important pre-requisite for a modern peer-to-peer application is platform-independence. The biggest differences in platforms are the graphical user interfaces, while the underlying structure of operating systems is rather similar. To achieve maximum portability, the core application should be decoupled from graphical user interfaces, which then could be written platform-dependently for each target platform; native user interfaces always perform better than interfaces designed for running on large number of platforms. To achieve this, the core application should not have any interactive graphical user interface of its own at all - it should only provide a protocol through which native graphical user interfaces and other application could communicate with it and control it. The protocol itself should be in human-readable format, but also be easily parse-able for client software; the reason for this would be to allow the possibility of interacting with the protocol directly through simple software like telnet, which would greatly simplify debugging process, but could also be useful even for end users as a crude remote control mechanism.
Related to the above comes the question of programming language to use for writing the core application. At this, C++ would be the most sensible choice, because it is widely used across all platforms and provides fastest code (which is required to achieve low system requirements); it allows (and even enforces) object-oriented design, and is easier to understand than C code. Additionally, since HydraNode strongly relies on module-writers, C++ coders are far easier to find than, say, Java coders.
As mentioned in previous section, quickest way to rapid development process is to give the users free access to the source code of the application; it increases possible developer/debugger-base significantly. Out of the myriad of open source licenses out there, GNU General Public License is most respected among users and developers, so HydraNode source code should follow the trend and be licensed under GNU GPL. Having the source code licensed under GNU GPL also allows us to use the almost infinite amount of existing code freely available through the internet, which could prove as a very useful option.
With the fore-seeable future of large number of co-developer base, it is necessary to clearly define the coding standards for the core application. Coding style is very personal; having large number of developers modifying the code will quickly lead to a mix of different styles and personalities, which in turn makes the code less readable, and thus less maintainable. There are several widely accepted coding standards floating around, and for this project we have chosen to use Linux Kernel coding standard; while originally written for C, the concepts still mostly hold for C++. Source code, however, is worth nothing without correct documentation which would give the future co-developers hints on what the original developers had in mind while writing/designing the application. Again, there several widely accepted documentation standards, out of which perhaps the most common is Doxygen-style. The reason behind this is that Doxygen is capable of extracting documentation from source files and generating web pages out of it, which can give a very quick and extensive overview of the entire application at a glance - something future developers will greatly appreciate.
The privacy of the user should be a serious concern for any modern peer-to-peer application developer; there are several institutions which tend to have a habit of spying upon the users and invading their privacy. The simplest solution would be to block the IP addresses of those groups; even better solution would be to simply stay off their radar. The first part can be implemented within the core application since it controls the low-level networking functionality; second part can be implemented by networking plugins depending on the specific networks.
Since the core application will eventually have a large number of very different networking plugins, we have the problem of bandwidth management. The end user shouldnt be bothered with each specific plugins bandwidth limiting settings, so the bandwidth limits should be managed by the main application, which in turn could either allow or deny requests for bandwidth to modules. This setting should be fully configurable, allowing end user to either have the bandwidth shared equally among the plugins, or in favor of one or several specific plugins.
Various file-sharing networks use very different files identifying methods - most often this is a checksum of the file, sometimes accompanied by file size; additionally, there is files meta-data, which can help the end-user identify the file. Since this feature is common to all file-sharing networks, while only differing in the actual checksum used, it should also be handled by the core application. Several points must be considered here - the core application should be able to generate a large number of checksums and store them. It should also be capable of extracting meta-data of files, as well as do cross-references with checksums - given a checksum from one network, it should be able to find the same file on second network (provided the file is known). However, no single client can know the checksums of all files of all networks, which means that the cross-referencing functionality will be of little use locally - this needs a central database which could store the checksums of all files from all networks, and provide cross-referencing functionality. Heres where Myradin comes in - it does exactly that. While support for Myradin shouldnt be completely integrated since it isnt really a part of the application, it could be an optional plugin that retrieves and submits checksums to the central database.
The last feature is far more important than is obvious on first impression; this is the feature that will eventually allow real multi-network simultaneous downloads of same file. The problem is - since each network uses different checksums for files, it is impossible to identify the same file on two separate networks - you dont know the file is the same until you have downloaded the entire file and generated a checksum out of it. However, with a central database which stores checksums of different files from multiple networks, it would be possible to retrieve the checksums of a file on all other networks provided you have the checksum of a file from one network, thus allowing downloading the same file from two or more networks simultaneously. Upon completition, files actual checksum could again be tested against all known checksums to provide even higher corruption protection than single-network downloads. The central database would also contain files meta-data, which would allow end-users to more clearly identify fake files, thus improving the overall quality of files on all file-sharing networks.
Enhancements:
Graphical User Interface (NEW) (madcat)
- Supports search, download and shared files lists
- Lists loaded modules
- Shows networking statistics
- Lists eDonkey2000 server list
Core/GUI communication (NEW) (madcat)
- Supports networking, files, modules and custom data syncronization with user interface(s).
Hydranode Base (madcat)
- No longer writes ANSI color codes to logfile
- Portability to platforms without stdint.h header
- Portability to unix variants without execinfo.h header
- Full support windows XP Service Pack 2 (half-open connections limiting)
- Using hand-crafted event multiplexing system in sockets to bypass the slow Boost.Signals
- Fixed issues with >2GB files on Windows
- Fixed issues with UDP packets handling when multiple packets arrive with short interval (previously this caused the socket to become dead)
- Support for more than 64 concurrent open connections on Windows
- Handles some race conditions in networking, where events come from backend when frontend has been destroyed more gracefully
- Now remembering total downloaded/uploaded/uptime across sessions (global)
Hydranode Core (madcat)
- No longer allocates disk space when shutting down
- Cleans up filename of invalid characters when starting downloads
- Fixed uploading issues while moving completed download to incoming
- Uploaded amount (for shared files) is now properly stored across sessions
- Avoids duplicate scanning of already-scanned directories
- Fixed crash when download is canceled while chunk hash job is in progress
- Added dynamic module-based upload-speed scaling based on modules overall upload/download data ratio, thus upload-capable modules that have downloaded 70% of data get 70% of upload slots. Note that these are not hard limits, so actual results may vary depending on various conditions.
- Faster and non-blocking disk space allocation for downloads
- Fixes crashes when search result handlers get destroyed
- Properly updates file modification date after movework finishes
- --disable-colors and --transform-colors command-line options
- --module-dir command-line option
- Now correctly handles temp/shared dirs with .. in path names
- No longer shares desktop.ini, thumbs.db and similar files
- No longer loses custom metadata after file rehash
Bittorrent Module (madcat)
- Fixed links command for single-file torrents after restart
- Reduced outgoing client connection timeout from 30s to 5s
- Fixed an issue with URI delimineters not being encoded in tracker GET request (ticket #225).
- Handles tracker responses sent with
newline instead of
- Properly seeds downloaded torrents after completition
- Cleans up cache folder on download completition or canceling
- Properly urlencodes HEAD / GET request arguments (ticket #235)
- Listening ports are now restarted instantly after runtime configuration changes
- Fixed some crashes during torrent completition
- Multi-tracker support
- Fixed uploaded/downloaded ratio calculation
eDonkey2000 Module (madcat)
- Reduced outgoing client connection timeout from 30s to 5s
- Fixed parsing QueueRanking packets from MLDonkey clients
- Fixed a bug where client would be dropped after download session end, when the remote client contacted us and sent AcceptUploadReq, and we didnt send ReqFile.
- Now properly destroys remote LowID clients if we are also LowID.
- More default (hardcoded) servers
- Support for global searching
- Miscellaneous protocol performance improvements and fine-tuning
- Properly switches sources to other files on download completition now
- GlobGetSources v2 packet is sent with different opcode. This raises UDP source queries effectiveness by ~5 times (from 4% to 20+%)
- Better A4AF handling
- Listening ports are now restarted instantly after runtime configuration changes
- Setting ed2k/FindServers can be set to 0 now to disable receiving servers from clients and servers
Email notifications (madcat)
- Fixes unhandled exceptions from connect() call (ticket #217)
HLink application (madcat)
- Its now possible to pass full paths (to .torrent files etc)

A Perl script which identifies new files on various FTP and Web sites.
Installation
Copy the program where you can acces it and do following commands:
cp i-spy /usr/local/bin/
Make sure the executable bit is set:
ls -l /usr/local/bin/i-spy
-rwxr-xr-x 1 root root 28568 Nov 22 11:36 /usr/local/bin/i-spy
if not, then set it:
$ chmod +x /usr/local/bin/i-spy
If you have perl installed elsewhere than /usr/local/bin, then create
a symbolic link:
$ cd /usr/local/bin
$ ln -s /usr/bin/perl
[or wherever you keep perl]
Now, copy the Log::File module into your Perl distributions site_perl
directory:
$ cp -r Log /usr/local/lib/perl5/site_perl/5.005/
[or wherever you keep site-specific perl modules]
You may also keep the Log::File module in the same directory as you
plan to use for your sites and logs.
Enhancements:
- Added support for browser agent masquerade
- Added support for Google News (Yum)
- Modernized examples

FoxGame is an extension that can be used to enhance user experience with O-game.
Enhance user experience with O-game (now works in every o-game version)
Adds a lot of features to the webgame O-game.
It also integrates Database features inside the game.
O-Game, is a real-time spacial browser game.
bs-BA/hr-HR/cs-SR can be downloaded as a separate version from http://foxgame.mozdev.org/ because there is no especific firefox version for those languages.
Main features:
- Automatic universe selector in login page.
- Reduced galaxy view: Planet column is not rendered and its functinality is moved to Name col., debris header reduced also.
- Extra delete options and spy report options: You can control messages from the top or the bottom.
- Fleet arrival and return time: In fleet destiny selection page you will see the time when you fleet will arrive and come back to your planet.
- Fleet retreat time: In fleet page you will see the time when your fleet will arrive if you order to come back.
- Multilanguage support: es-ES(spanish), en-US(english), de-DE(deutsch), pl-PL(polish), fr-FR(french), nl-NL/nl-BR (dutch), it-IT (italian), bs-BA/sr-CS/hr-HR (bosnian, serbian, croatian), pt-PT/pt-BR(portugese), tr-TR(Turkish), zh-CN/zh-TW (Simplified chinese and traditional chinese), ru-RU (russian), da-DK (danish), si-SL (slovenian) and sv-SE/sv-FI (swedish). If your language is not supported and you want to translate it, mail me.
- Almost all finishing hours: Research and buildings finishing hours, hangars qeue finishing time, you can see date/time in overview if you wish and even in phalanx.
- Highlight ally and private messages: Ally and private messages now have a diferent background to see them easily.
- Highlight big debris fields: Debris fields bigger than you fix min will have different background in galaxy view.
- Autochoose mision type: You can define mission priorities so FoxGame will select the mission according to that.
- Online DBs integration: Send reports to Milos (only ogame.com.es), EspRep and GalaxieTool directly within OGame (solar systems, stats and spy reports supported).
- In mines and power plants info screens (the ones you see when you click in the name) you will see the diferences between your actual level and the rest.
- Autoselect fleet destination: Select coord text anywhere go to fleet send screen and Voila! the destination is already selected. There is no need to take down numbers anymore.
- Private message signatures.

Anti-Paranoia is an extension which takes all your doubts and gives you confidence.

Especially if you are working on security, you might get the feeling that your part of something really big and maybe even evil.

How can your extension help me? It will pop up calmative messages for you to feel relaxed while browsing the web.

No, this extension will not spy and destroy your personal data, remember: Everything is good!