Eric

You don't. It's automatic. Put a file named myiosscraper.pl in your netdbscraper directory and the devtype myios is automatically available.

switchname,devtype=WHATEVER_IT_IS For instance: switchname,devtype=ios

Have you tried pulling up a device that is on one of the switch ports by mac or IP and seeing what it displays for a switch name? If it displays the correct name, what happens if you click on the switch name?

Have you tried puling up a device that is on one of the switch ports by mac or IP and seeing what it displays for a switch name? If it displays the correct name, what happens if you click on the switch name?

Off the top of my head, it sounds like the OUI.txt file might have been created on a Windows system. You can try running dos2unix on OUI.txt and see if that helps. I don't personally use the excel feature so I just always put a "remove MS newlines" snippet in my scripts anytime I use the vendor code. I can't remember if I ever tried to fix the issue or not.

I doubt that it currently has any proxy capabilities. I don't know how stable it would be for long term use but you can setup an ssh tunnel manually. Or if the relay host has python you can use something like sshuttle to set it up for you. If you wanted to get fancy, you could write a wrapper around netdb that would check if the tunnel was up before netdb ran.

There is a section in the INSTALL file about backing up the database. Googling about how to restore from a mysql database backup should fill in the rest of the gaps for you.

I don't have a debian system or the vmware vm to look at but it sounds like basic web file ownership and permission issues. It is probably not related to the password you created or you logging into the web interface (you can always disable the apache authentication to test that). It sounds like the web server does not have permission to read the cgi-bin file. I would start with the basics like; what is the apache2 user in /etc/passwd? is that user the owner of the link you mentioned above? does...