Closes 18061: Hide traceback from rendered device config

[alehaa]

Fixes: #18061

When an exception occurs during device configuration rendering, it usually doesn't contain information about the template being rendered, but rather the trace of how the template was rendered. Since this could confuse users and expose internal server information, it is now hidden.

Before:

Traceback (most recent call last):
  File "/opt/netbox/netbox/dcim/views.py", line 2129, in get_extra_context
    rendered_config = config_template.render(context=context_data)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/netbox/extras/models/configs.py", line 282, in render
    output = template.render(**_context)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/jinja2/environment.py", line 1304, in render
    self.environment.handle_exception()
  File "/opt/netbox/venv/lib/python3.12/site-packages/jinja2/environment.py", line 939, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/opt/netbox/venv/lib/python3.12/site-packages/jinja2/sandbox.py", line 327, in getattr
    value = getattr(obj, attribute)
            ^^^^^^^^^^^^^^^^^^^^^^^
jinja2.exceptions.UndefinedError: 'dcim.models.devices.Device object' has no attribute 'next'

After:

An error occurred while rendering the template: 'dcim.models.devices.Device object' has no attribute 'next'

This is the same message as displayed in the message notification.

[bctiemann]

@alehaa Maybe we should also log the complete traceback via the regular logger mechanism, instead of just handling it in the UI and otherwise swallowing it? In your example the File "/opt/netbox/netbox/dcim/views.py", line 2129, in get_extra_context gives a much more useful place to start looking for the issue than if the ultimate error line is the only thing one has to go on.

[jeremystretch]

IMO it would be cleaner to introduce a separate context variable to store the error message, and return an empty string for rendered_config. This will allow us to more cleanly convey the error in the UI, with proper styling & formatting.

However, we also need to consider the export workflow, where the raw config is returned for download as a file. In this case maybe it's best to keep the error message in the file content.

[alehaa]

I‘ll see on how to integrate changes for both UI and API. Due to some other projects an update might take until the holidays. I‘ll keep you posted.

[jeremystretch]

I went ahead with my proposed changes above, pretty happy with how it turned out. I've also replicated the changes for virtual machines.