The way I'd recommed the cfg file structure to be is this. global.cfg This file contains the global definitions; such as WorkDir, LogFormat, Interval, Forks, and so on. It is not called directly by MRTG or by the frontend.
master.cfg This file contains only Include statements to include the individual device config files. xxxxx.cfg For every individual device, create a separate .cfg file which has 'Include:global.cfg' and is itself Included by the master.cfg. The Device files do not need ot have any of the global definitions as they get them from the global.cfg file. Now, you call MRTG on the master.cfg file only, and (at least on a UNIX system) you can use Forks to make the most of multithreading. Your frontend (14all, routers2, or whatever) uses the individual device cfg files which results in better performance and a better index or menu. Your device cfg files could be in multiple subdirectories for easy management, as long as they Include the global.cfg using an absolute path and the master.cfg refers to them using absolute paths (relative paths can cause confusion). This also allows you to do cacading menus (routers2) or nested menus (14all) on a per-subdirectory basis. Steve _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
