Free resolve software for linux

jdresolve is a software that resolves IP addresses to hostnames. Any file format is supported, including those where the line does not begin with the IP address. One of the strongest features of the program is the support for recursion, which can drastically reduce the number of unresolved hosts by faking a hostname based on the network that the IP belongs to.

DNS queries are sent in parallel, which means that you can decrease run time by increasing the number of simultaneous sockets used (given a fast enough machine and available bandwidth). By using the database support, performance can be increased even further, by using cached data from previous runs.

HOW IT USED TO WORK

jdresolve used the algorithms describe below up to version 0.2.

The initial version of jdresolve tried to only speed up the name resolution by implementing numerous concurrent requests. I The first problem was: how to resolve the maximum possible number of IPs concurrently without reading the whole log file into memory (they can get quite _huge_)? I figured Id need a 2 pass approach, collecting all distinct host IPs that needing resolving in the first step, then resolving them efficiently inside a loop, and finally just replacing the resolved IPs on the second pass through the log file.

This way we can garantee that the resolve queue will always be full with no need to weight that against how many lines of buffered log entries we would need to cache. The number of distinct IP addresses tend to be quite lower than the number of lines in the log file, and the IP part takes about only 1/20th of the log line, so we cant be using too much memory just by putting a few hundred or thousand small strings into a hash.

After looking thru CPAN, I came across the excellent Net::DNS module and was more than happy to note that it already provide a subroutine and examples for background queries. Just add IO::Select to that and you have a full non-blocking aproach to multiple concurrent queries. You can even specify the timeouts to make the name resolving even more efficient.

Having this much done, I was quite happy to have the fastest log resolving routine I have come accross. By setting the numbers of concurrent sockets and timeouts you could fine tune the beast to resolve names _very_ rapidly. But still there where about 25% of the IPs left unresolved...

"This is not much help", I thought. I need to know _at least_ from what country these people are accessing from. After a few not very scientifical aproaches, I realized that by recurring thru the DNS classes (C, B and finally A) and checking for the host listed in the SOA record I could be pretty sure this was a father domain to the IP. The implementation goes like this: find out all distinct IP addresses, then determine which C, B and A classes contain these addresses. Make up a list from these queries and send them thru a resolver in chuncks of 32 (configurable via the command line). If a socket times out, leave that request unresolved.

After running a big log file against the recursive aproach, I determined it didnt take much longer to resolve it at all. Full class domains tend to have decently configured DNS servers, and you get a lot of repeated classes when resolving your logs. The best was still to come: 0 unresolved IPs :) And since that I havent found an IP that cant be determined at least to its A class.

HOW IT WORKS NOW

The above algorithm works extremely well except for the case of very large logs (>100Mb). The hashes containing IPs and their parent A/B/C classes gets pretty huge doesnt fit in memory any more.

So as of v0.3, we have a new 1 pass approach. We have a line cache that holds 10000 lines (configurable with -l, dont set it much lower). Using my test base it looks like each 10000 lines take about 4Mb of RAM during processing (thats the log lines themselves plus the hashes and arrays used for caching/processing). Each IP and class to be resolved has a count value, which is increased every time a line with that number is read, and decreased after we print out a resolved line with that reference value.

Think of it as a "moving window" method, and that we do our own garbage collection. The process pauses if the first line in our line cache is still unresolved, we dont have any more sockets, or were waiting for socket data. We cant control the last two items, but to minimize the pauses do to yet unresolved lines, increase the -l value if you notice pauses during resolving. There should be enough lines cached so that even if we have timeouts on sockets we are still waiting for other socket data to come in, not just for 1 single socket to time out.

Using this method the memory usage during executing is almost constant. So you can determine how much RAM you wish to use for resolving names and set your -l value and forget about it. Theres really no performance loss when compared to the resolved.log

If you simply run the script as you would with the Apache logresolve program, you get the same results, only much faster. But if you want really take advantage of jdresolve, you should at least turn on the -r option for recursive resolves. As of version 0.2, the -m option takes a mask as an argument. The valid substitutions are %i for the IP address and %c for the resolved class. So an IP like 1.2.3.4 with a mask of "%i.%c" (the default) would become something like "1.2.3.4.some.domain". A mask of "somewhere.in.%c" would turn it into "somewhere.in.some.domain".

The -h switch shows you basic help information. The -v switch will display version information. Use -d 1 or -d 2 (more verbose) to debug the resolving process and get extra statistics. If you dont care for the default statistics, use -n to disable them.

After some runs you may want to change your timeout value. The -t option accepts a new value in seconds. For even better performance, use the -s switch with a value greater then 32, but remember that many operating systems have a hard coded default for open files of 256 or 1024. Check your systems limit with "ulimit -a".

New in v0.3 is the -l switch, which specified how many lines we will cache for resolving. The default is 10000, but can be vastly incremented without using too much RAM, as explained in "HOW IT WORKS".

After you used jdresolve on the log file, you can check which ips where left unresolved by using the --unresolved option on the file that was generated.

WHAT DOES RHOST DO?

rhost is a quick script to take advantage of the new STDIN functionality of jdresolve. Many times you use the host command to resolve a single IP (like host 200.246.224.10). As with standard log resolvers, host doesnt do recursion. So rhost just calls jdresolve with the apropriate parameters to resolve that single IP number. The syntax is rhost .

DATABASE SUPPORT

As of version 0.5, jdresolve provides simple database support thru db (dbm, gdbm, sdbm, etc) files. You can use the --database switch to specify the db file and that will allow for fallback in case some DNS servers are down and also performance improvements since you can lower your timeout value without sacrificing resolved percentage.

To use the database support, just supply a database name (i.e. hosts.db) using the --database option. If it does not yet exist, a new database with that name will be created. All resolved hosts and classes during a jdresolve run will be cached to the database.

After you have some data in a db, you can use --dumpdb to look at it. With --mergedb to add new information to it (the format of the input file is the same as the one from a dump using --dumpdb, e.g. an ip/class followed by the hostname/classname, separated by white space)

Ex: echo "0.0.0.0 testip" | jdresolve --database hosts.db --mergedb -

...adds and IP entry to the db

Ex: echo "0.0.0 classname" | jdresolve --database hosts.db --mergedb -

...adds a class entry to the db

Note: Since when recursing the resolved hostnames are stored to the database (even when resolved by recursion), you _may_ not want to use the same database for normal and recursed runs. That is because a cached host from a resolved run will show up as a "real" IP if you dont recurse and use the --dbfirst or --dbonly options, or just use the database and the lookup times out. Nothing too serious, but this detail may be important to some people.

c-ares project is a C library that resolves names asynchronously.
Enhancements:
- ares_save_options, ares_destroy_options, ares_process_fd, and ares_parse_ns_reply were added.
- The transaction IDs were made "secure".
- A few parsing issues and minor bugs were fixed.

Roadnav is an in-car navigation system that can run on a variety of operating systems like Linux, Windows, and Mac OS X.
Roadnav can obtain a cars present location from a GPS unit, plot street maps of the area, and provide verbal turn by turn directions to any location in the USA.
Roadnav uses the free TIGER/Line files from the US Census Bureau to build the maps, along with the GNIS state and topical gazetteer data from the USGS to identify locations.
Main features:
- Generates street level maps for the US
- Interfaces with GPS units to display your position in real time
- Verbal turn by turn directions to any place in the US. Automatically recomputes directions if you miss a turn.
- On screen keyboard
- 3D (drivers perspective) view mode
- Daytime and nighttime color schemes
- Automatic day/night mode switching
- Plots nearby landmarks and points of interest
- Can operate offline (without an Internet connection)
- Antialiased output
- Supports multiple operating systems including Windows, Linux, and Mac OS X
- Uses freely available data from the US Census Bureau and the USGS
- Appearance can be customized with skins
- Can output status information to LCD devices through LCDproc
Enhancements:
Enhancements:
- Adds option to Preferences to enable gpsd buffering (reduces jitter).
- Adds experimental GPX import support.
- Disk usage reduced by ~30%.
- Adds GPS serial initialization string option to Preferences.
- Adds preference to override default map directory.
- Adds option for username/password proxy authentication.
- Adds "Use System Proxy Settings" preference, which reads proxy settings from the HTTP_PROXY environmental variable.
Bug Fixes:
- Fixes Delete button in Waypoints dialog when no waypoints exist.
- Workaround for buggy serial implementations.
- Fixes Windows 2000 compatibility.
- Fixes i18n issue in OSM code.
- Improved address look up.
- Eliminates IPP error messages when printer is not configured.
- Improved compatibility with DeLorme Tripmate and Earthmate GPS units.
- Win32 floating point model changed from fast to precise. Should resolve problems calculating routes.
- Fixes focusing issue in keyboard dialog.
Developer Visible Changes:
- MapControlData_Tiles index files eliminated.
- Direct access to Point::m_fLong and Point::m_fLat eliminated. Use the Point::Set* and Point::Get* functions instead.
Misc:
- Compiled maps now organized in a more human readable format.
- Eliminates TIGER/Line 2006 First Edition from search path.
- Proxy settings now on their own preferences page.
- When maps have to be upgraded, adds option to not upgrade map files and immediately terminate Roadnav instead.
- Small map labels now have a solid background instead of a cross hatch.

Geotrace is a geographical traceroute utility. Geotrace provide graphical view on the map. It has many geographical maps.
In order to be able to use a new map with geotrace, you only need to know one thing: the longitude/latitude of the top left and bottom right corners. Most maps you will find will be centered on 0,0 (about 5 degs south of Ghana and 10 degs west of Gabon. for those of you who dont know, its in Africa.). So, lets do it step by step:
1) Find a map. there are plenty on the web. Nasas a good place to find them (it is a mess though). Or grab one of the few maps at a site with maps for XGlobe and XPlanet.
The image must be in a format understood by gdk-pixbuf (most images youll find will be jpeg or gif which work).
2) Go to the maps/ directory in geotrace. Put the map in there and open up maps.properties
3) on the second line, youll see MAPS:World50.gif, World100.gif etc... Thats a list of all the maps. Add the name of your recently downloaded map on that line.
4) now, you need to tell geotrace what the coordinates are. Add a line to the file that looks as follows:
filename:BOUNDARY=lon1,lat1,lon2,lat2
filename: case sensitive, map has to be in the maps/ folder
lon1 and lat1: longitude and latitude of the top left corner
lon2 and lat2: longitude and latitude of the bottom right corner
As I said earlier, for most maps youll find, youll get -180,90,180,-90 which means that the map is centered on 0,0. However, the two world maps (World100 and World50) in geotrace are centered on 10W,0
You might notice that the three maps of the US have another line associated with them. Thats the alber projection. You probably wont have to deal with that.
4) Run geotrace, select your map from the drop-down and enjoy.
Version restrictions:
- Some hops may have extravagant locations, but for once, its not my fault. The netgeo server does not have fully updated records. So my advice is, just live with it
Enhancements:
- added line color and width options.
- added cmdline args. host to trace, and startup map.
- added map options: path to maps and startup map.
- warning to check paths when run for the first time.
- added status bar
- fixed draw_trace_on_map which didnt draw in certain cases (timeouts)
- fixed bug that caused crash when a hop times out and more hops repond later
- 2001-04-05
- added option: resolve host name or not
- load/save options from file (~/.geotrace) 2001-04-04
- fixed bug that caused last map in file not to be read (world100) 2001-04-03 added options for traceroute (path to exec, timeout and maxttl)

String::RexxParse is a Perl implementation of REXX parse command.
SYNOPSIS
use String::RexxParse qw(parse);
parse $source, q! $var1 $var2 ( $var3 ) $var4 ($var5) $var6 !;
or
use String::PexxParse;
$parse = String::RexxParse->new(q! $var1 $var2 ( $var3 ) $var4 ($var5) $var6 !);
$parse->parse($source);
SYNTAX
parse EXPR, EXPR
The first EXPR is the source string to be parsed and must resolve to a scalar value.
The second EXPR is the template specification. The first time parse is called with a particular template, the template is compiled, then used to parse the source expression. Subsequent parse calls with the same template will use the previously compiled version of the template rather than compile the template again.
The template is specified as a single expression, usually using some single-quotish type of quoting, like q!...! for instance. The variable specifications, (or lvalue specifications) must not contain spaces. If you want data assigned to $qq{$one}, do not specify it as $qq{ $one } but as $qq{$one}. Although both are valid in Perl, only the latter is valid in a String::RexxParse template. Likewise, substr( $b , pos( $source ) , length( $match ) ) is NOT valid, but substr($b,pos($source),length($match)) is. Also, there must be white space following any lvalue specification (unless its the last item in the template). q/$b $c/ is OK, but q/$b$c/ is not.
If a variables value is to be used as a pattern, it is enclosed in parentheses.
Literal patterns are enclosed in either single or double quotes. Patterns can contain spaces within the quotes or parentheses.
A period (.) is used as a placeholder to skip part of the source string.
Numeric patterns (absolute or relative position) are supported. 3, =7, +5, -12, =($n), +($x), -($somenumber) are all numeric patterns (if you use variables inside parentheses preceeded by =, +, or -, make sure they contain numeric values). Remember that Perl starts counting position at zero, so absolute numeric patterns should be one less than in REXX to identify the same character position.
All Perl variables used must either be in the package that called parse, or they must be explicitly referenced with their package name (i.e., if parse is called from package Pack, $a implies $Pack::a -- if you want $a in package Sack, you must specify $Sack::a ). Lexical variables can not be used in the template. To assign values to lexical variables do somthing like this:
my ($b, $c, $d, $e) = parse $a, q! $x . $x ( $x ) $x !;
If youre concerned about the compiled templates taking up memory after youre done with them, you can add drop to the import list when you use String::RexxParse. Then pass the template to drop when youre done with it. Or just call String::RexxParse::drop($template). Or use the object oriented flavor discussed below.
Consult your favorite REXX manual for more details on templates.
$parse = String::RexxParse->new(EXPR);
$parse->parse(EXPR);
If you like, you can use String::RexxParse->new(EXPR) to create a String::RexxParse object. The EXPR passed to new is a template specification as described above. When you want to parse an EXPR, you just pass the string to the String::RexxParse object like so: $parse->parse(EXPR);
Enhancements:
- Fixed bug introduced in 1.07 and added j.t to test suite.

rdns provides a tiny little UNIX utility that will preform reverse dns lookups.

This simple little program takes an IP address as an argument, and spits out the hostname that it finds. Its a simple little program designed to be used in scripts, primarily.

Syntax:
rdns [-s]

Optionally, you can append -s onto the command line. This will prevent rdns from printing any available aliases.

Note: Sometimes rdns will just seem to hang there during the gethostbyname() call. This usually occurs when you try to resolve addresses private IP addresses, like 192.168.*, 10.* and so forth. This is usually BAD for scripting, so try to have all the possible hosts in your /etc/hosts.

Menu Builder is a software that can find problems with using JavaScripts for rollovers in navigation menus and resolve them.

Menus need to be fast loading, retrievable from cache, and workable with page inserts. From the publishing point of view they need to be able to be distributed to pages efficiently.

There is no limit to how many or how large the images can be displayed on the same page. But as with any great number of images there is always the download time to consider. If it is too slow then there is a risk of the surfer getting impatient and moving on. Many of us tend to forget that we are getting our images from our own cache.

Images presented on the web are usually 72-96 dpi (dots per inch) and unless presenting a photographers professional portfolio, images larger than 100k in file size make for longer downloads and less visitors.

A link can be set for visitors to navigate by mouse clicking the image. The link can be set to a target frame for navigating within framesets. The hyperlink will only function from the registered site. If a link is not required simply leave the setting completely blank.