Talstr. 25, D-63322 Rödermark
Tel. +49 6074 881056, FAX 881058
You may use this software free of charge at your own risk
netdb 3.0.6 (2001-01-29)
If you want to know if netdb is something for you, ask yourself the following two questions:
Computer networks are complex systems. Without a systematic approach and management, networks will fall into chaos, no matter what marketing droids may want to make you believe or try to sell.
Within an Internet (sub)domain hostnames must be unique. When it comes to NetBIOS names (what Microsoft calls "Computer Name"), such names must be unique for your whole networks (LAN and WAN), not just within your workgroup or LM/NT domain. How do you asure this? Files on paper, text files, Excel sheets? Are you kidding? :)
How about network addresses? Network addresses such as ipaddr must be unique within a network. How do you asure this?
DHCP helps you configure clients by assigning them an ipaddr and many more (good) things by a DHCP server, but before there was dynamic DNS (DDNS), an ipaddr of a hostname could change without DNS knowing about the change and hence you either did not have your DHCP clients in DNS or you had to watch those ipaddr and perform changes to DNS manually.
Do you run DHCP? Which version? I recommend the use of DHCP even if all you want is static ipaddr for all your clients. dhcpd 3 from the Internet Software Consortium and Microsoft Windows 2000 DHCP support DDNS, earlier versions don't.
Fairly recent enhancements such as dynamic DNS (DDNS) and DHCP servers which can update DNS servers automatically may help you automate parts of DNS but since computer names/hostnames still must be configured manually and unique, there is still a need to centrally manage those computer names/hostnames, ideally using a computer naming convention. A computer naming convention gives the educated user some information about the type of device.
Let's assume a nation wide organization with many subsidiaries all over the country using devices from network hubs, switches and routers to printers, servers and clients. Our hostname should help identify the type of device (to some degree), also the location. All this must lead to unique hostnames. For the sake of simplicity we assume that our organization has given every location a three digit number that identifies the subsidiary. Let's also assume that all subsidiaries are small enough and do not need more than 99 devices of the same type present at the same time.
This could lead to a computer naming convention like the following:
|N||Network component (hub or switch)|
three numeric digits counting from 000 to 999
two numeric digits counting from 01 to 99
c10001 hence is the 1st client in location 100, while p15103 is the 3rd printer in location 151. All this is very straight forward and yes, I'm aware I'm wasting index 00.
Let's develop the above mentioned example a little further and assume that every subsidiary is assigned a network with a 24 bit subnet mask (255.255.255.0 or /24). Some devices require static IP addresses while others may be configured to use DHCP. In any case we need to reserve some space for those devices that require static IP adresses:
|.11-30||Network components, hubs or switches (01-20)|
|.101-199||Clients configured by DHCP (01-99)|
This design assumes you don't need more than 10 servers per subsidiary, no more than 20 hubs and/or switches, no more than 50 printers. Also this design assumes you only have one router although the IP address range from 200-253 (54 ip addresses) could be used for more routers. There are 20 more IP addresses reserved in this design in the range of .81-100. This should be enough space for some future requirements.
Why is the stuff not stored by dynamic DNS so important? Why would I want to go through the troubles of entering this data (most likely) manually?
Without knowing which mac address belongs to which PC you will have a very hard time troubleshooting your network.
You may say you don't have to troubleshoot your network very often since it seems to work just fine most of the time without having invested a minute into documentation. The problem is that if there is a problem, you want to resolve it as quickly as possible since every hour your network is down, because of a machine you can't find costs you as much time as people are prevented from working, using your services etc. Don't look just at your own working hours. You need to invest to keep your documentation up to date, please also consider other people's work hours wasted by trying to save you some time.
Furthermore a network is no different from say a software system. Would any decent software engineer even start a software project without some specification? Why do people think they could get away without this on a network? Because networks are designed to tolerate a certain level of ignorance. The bigger and more complex a network gets, the more of a problem you will have without documenting it and a systematic approach.
Can you tell if a mac address found on any given LAN of your organization belongs to a company machine or to a possible intruder?
Without a reference database you hardly stand a chance to know what's "right" or "wrong". Using a reference, which a documentation is, and some clever scripting you can even automate keeping track of your network.
netdb let's you centrally store all of the above properties of a network interface. Those properties can be used for searching, for creating scripts and potentially many more things.
netdb currently can manage your DNS server which can be any DNS server supporting dynamic DNS (e. g. DNS/bind 8.1.2 or better or Microsoft Windows 2000 DNS). Your master DNS server does not need to run on the same machine as netdb but it can.
netdb can create dhcpd configuration files if you choose to run dhcpd on the same machine as netdb. You can configure netdb to create dhcpd configuration files allowing reservations only or to also have a range of IP addresses given out dynamically.
netdb allows export and import in CSV format which can be read/written by virtually any data processing system.
netdb was started in June 1998 to ease IP address administration in a project for the "Landesforstverwaltung Baden-Württemberg". It's not an end user product. Always keep your brain turned on while using netdb which is always a good idea when dealing with networks.
netdb was written in my spare time using my own equipment so I retain all copyrights. Please apply GPL v2 to this Open Source package even though no copy of it comes with this package.
I always welcome new ideas and constructive criticism but don't expect me to do any changes you have in mind right away since that's not my job.
You can make it my job, though, by paying me for the changes but bear in mind that the result will still remain Open Source.
In any case I will do my best to implement sensible changes reasonably fast. Bug fixes have top priority, though.
The following people helped improve netdb (in alpabetical family name order)