|
You can do this with dummy cfg files.
On our system, I use a .dcfg extension for the dummy files, and a .cfg for the 'real' ones. MRTG processes the .cfg files, but routers2 will use the .dcfg and .cfg files.
In the 'real' .cfg file, you set it up as normal -- but don't give your users any access to it at all (by not including it in the cfgfiles directive). Then, create a .dcfg files that uses routers.cgi*Include: to include the .cfg file, and use routers.cgi*InMenu[]:no to hide the targets you dont want them to see. In this way, you can have many different versions of the .dcfg file, all giving view to different sets of targets. This doesnt affect MRTG at all -- since MRTG only processes the .cfg file, not the .dcfg files. The .dcfg ones are used only by routers2 to give a different view of the data.
This method can also be used to create special summary pages or userdefined graphs over multiple devices.
This is a 'security by obscurity' method, since although the targets will now not appear in the menu, they can still be accessed if you know the targetname. For stricter security, create a duplicate file for the .dcfg (rather than using Include) and delete the targetnames you dont want (rather than using InMenu to suppress them). Again, this is all in the .dcfg, which is not used by MRTG, so it will not affect your data collection, only routers2's display of it.
HTH
_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11
|
Login
Register
FAQ
Members
