Cheshire Cat Computing

Yes , it is possible, and it will speed things up.

When routers.cgi starts, it will read in all (or part of all) the .cfg files in order to build the menu and set defaults. Obviously, the fewer .cfg files, the faster it runs.

You have a couple of options here, and they are detailed in the HOWTO documenation. You can pass an option to routers.cgi that will activate a separate routers2.conf file section, or you can rename routers2.cgi to activate a separate section.

If you rename routers2.cgi, then in addition to reading the [routers.cgi] section of the routers2.conf file, it will read a section corresponding to the new program name (and this will override any definitions in the [routers.cgi] section). For example:

(part of routers2.conf file)

[routers.cgi]
confpath = /mrtg/conf
cfgfiles = a/*.cfg
group = yes
... other options ...
[foo.cgi]
cfgfiles = b/*.cfg

Now, if you copy routers2.cgi to foo.cgi, you can run routers2.cgi -- getting the default options -- or foo.cgi, where you get all the normal options, *except* that cfgfiles is different.

This is explained in more detail in the HOWTO and other documentation.

How about (assuming a path for your cfg files of /etc/mrtg/CITYNAME/NODENAME/DEVICE.cfg )

[routers.cgi]
confpath = /etc/mrtg
cfgfiles = */*/*.cfg
group = yes

[city1.cgi]
cfgfiles = city1/*/*.cfg

[city2.cgi]
cfgfiles = city2/*/*.cfg

[targetnames]
/etc/mrtg/city1/node1 = City 1 node 1
/etc/mrtg/city1/node2 = City 1 node 2
/etc/mrtg/city2/node1 = City 2 node 1
/etc/mrtg/city2/node2 = City 2 node 2


This would use grouping to collect the various nodes together within a city. Your routers2.cgi instance would still show everything, but if called as city1.cgi it would be restricted to just city1.

The targetnames definitions would make sure the groups are listed in a sensible order (since it is sorted alphabetically by group first).

HTH

Steve