netbox-community / netbox-docker

🐳 Docker Image of NetBox
https://github.com/netbox-community/netbox-docker/wiki
Apache License 2.0
1.86k stars 860 forks source link

Getting a "Bad Request (400)" #21

Closed bdlamprecht closed 6 years ago

bdlamprecht commented 6 years ago

I've been building a NetBox setup for ~6 months on a standard Ubuntu VM in a test environment. Now, I'm beginning to get ready to move that to a pilot release and I'd like to use deploy my setup using docker.

Looking to build off of the excellent work that you've done, I encountered the following issue...

I followed the instructions in the README.md, and everything worked well, but when I tried to connect to the server, I get the following back:

Bad Request (400)

I'm wondering if it has something to do with NetBox v2.2.5 that was released yesterday. I'm going to try and run this setup against previous versions, but in the meantime I thought I would let you know that there is a potential error.

I also got the following back when running the docker-compose up without the -d flag:

netbox_1    | Traceback (most recent call last):
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 213, in ensure_connection
netbox_1    |     self.connect()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 189, in connect
netbox_1    |     self.connection = self.get_new_connection(conn_params)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/postgresql/base.py", line 176, in get_new_connection
netbox_1    |     connection = Database.connect(**conn_params)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/psycopg2/__init__.py", line 130, in connect
netbox_1    |     conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
netbox_1    | psycopg2.OperationalError: could not connect to server: Connection refused
netbox_1    |   Is the server running on host "postgres" (172.19.0.2) and accepting
netbox_1    |   TCP/IP connections on port 5432?

and

netbox_1    | The above exception was the direct cause of the following exception:
netbox_1    |
netbox_1    | Traceback (most recent call last):
netbox_1    |   File "./manage.py", line 10, in <module>
netbox_1    |     execute_from_command_line(sys.argv)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
netbox_1    |     utility.execute()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute
netbox_1    |     self.fetch_command(subcommand).run_from_argv(self.argv)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 283, in run_from_argv
netbox_1    |     self.execute(*args, **cmd_options)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 330, in execute
netbox_1    |     output = self.handle(*args, **options)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 83, in handle
netbox_1    |     executor = MigrationExecutor(connection, self.migration_progress_callback)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/migrations/executor.py", line 20, in __init__
netbox_1    |     self.loader = MigrationLoader(self.connection)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/migrations/loader.py", line 52, in __init__
netbox_1    |     self.build_graph()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/migrations/loader.py", line 209, in build_graph
netbox_1    |     self.applied_migrations = recorder.applied_migrations()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/migrations/recorder.py", line 65, in applied_migrations
netbox_1    |     self.ensure_schema()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/migrations/recorder.py", line 52, in ensure_schema
netbox_1    |     if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 254, in cursor
netbox_1    |     return self._cursor()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 229, in _cursor
netbox_1    |     self.ensure_connection()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 213, in ensure_connection
netbox_1    |     self.connect()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/utils.py", line 94, in __exit__
netbox_1    |     six.reraise(dj_exc_type, dj_exc_value, traceback)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/utils/six.py", line 685, in reraise
netbox_1    |     raise value.with_traceback(tb)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 213, in ensure_connection
netbox_1    |     self.connect()
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 189, in connect
netbox_1    |     self.connection = self.get_new_connection(conn_params)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/django/db/backends/postgresql/base.py", line 176, in get_new_connection
netbox_1    |     connection = Database.connect(**conn_params)
netbox_1    |   File "/usr/local/lib/python3.6/site-packages/psycopg2/__init__.py", line 130, in connect
netbox_1    |     conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
netbox_1    | django.db.utils.OperationalError: could not connect to server: Connection refused
netbox_1    |   Is the server running on host "postgres" (172.19.0.2) and accepting
netbox_1    |   TCP/IP connections on port 5432?
netbox_1    |

And here are the logs from when it is "running" (i.e. after startup):

netbox_1    | [2017-11-17 00:58:53 +0000] [1] [INFO] Starting gunicorn 19.7.1
netbox_1    | [2017-11-17 00:58:53 +0000] [1] [DEBUG] Arbiter booted
netbox_1    | [2017-11-17 00:58:53 +0000] [1] [INFO] Listening at: http://0.0.0.0:8001 (1)
netbox_1    | [2017-11-17 00:58:53 +0000] [1] [INFO] Using worker: sync
netbox_1    | [2017-11-17 00:58:53 +0000] [126] [INFO] Booting worker with pid: 126
netbox_1    | [2017-11-17 00:58:53 +0000] [127] [INFO] Booting worker with pid: 127
netbox_1    | [2017-11-17 00:58:53 +0000] [128] [INFO] Booting worker with pid: 128
netbox_1    | [2017-11-17 00:58:54 +0000] [1] [DEBUG] 3 workers
netbox_1    | [2017-11-17 01:00:20 +0000] [128] [DEBUG] GET /
netbox_1    | 172.19.0.4 - - [17/Nov/2017:01:00:21 +0000] "GET / HTTP/1.0" 400 26 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.102 Safari/537.36 Vivaldi/1.93.955.48"
netbox_1    | [2017-11-17 01:00:21 +0000] [128] [DEBUG] GET /favicon.ico
netbox_1    | 172.19.0.4 - - [17/Nov/2017:01:00:21 +0000] "GET /favicon.ico HTTP/1.0" 400 26 "http://[HOSTNAME REMOVED]:32770/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.102 Safari/537.36 Vivaldi/1.93.955.48"
netbox_1    | [2017-11-17 01:23:22 +0000] [128] [DEBUG] GET /
netbox_1    | 172.19.0.4 - - [17/Nov/2017:01:23:22 +0000] "GET / HTTP/1.0" 400 26 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.102 Safari/537.36 Vivaldi/1.93.955.48"
netbox_1    | [2017-11-17 01:23:22 +0000] [126] [DEBUG] GET /favicon.ico
netbox_1    | 172.19.0.4 - - [17/Nov/2017:01:23:22 +0000] "GET /favicon.ico HTTP/1.0" 400 26 "http://[HOSTNAME REMOVED]:32770/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.102 Safari/537.36 Vivaldi/1.93.955.48"

The last two lines in the above section get repeated every time I refresh the page. Also, you can tell my the port being 32770 that this is the 3rd time I've run docker-compose up.

bdlamprecht commented 6 years ago

So I just tried running it against NetBox v2.2.1 by doing the following:

~/netbox-docker$ export VERSION=v2.2.1
~/netbox-docker$ docker-compose up

and it correctly pulled down the appropriate version of NetBox, built the docker images, and started all of the docker services. However, the same issue occurs, which means either:

  1. I must be doing something wrong
  2. There is something inconsistent with my environment that is breaking things
  3. The interwebs are somehow not working well today

Any pointers that you could help me out with would be appreciated.

cimnine commented 6 years ago

Can you run docker-compose down -v and try again? (Attention: Running this command will remove any data already in there!)

bdlamprecht commented 6 years ago

I had already done that previously, but just for the sake of it, I did as you requested, and the same issue occurred.

See the following two gists for all of the logs from the two separate times this was attempted. Note, I did logout and log back in to remove all odd env variables. I also removed the custom-built docker containers and images by doing docker container prune and docker image prune.

Each file in the gists below are from different shell sessions on the same host: Attempt #1 (Start with the file named "docker-compose cli") Attempt #2 (Start with the file named "docker-compose cli")

Line 896 of netbox-docker.log in Attempt #1 corresponds with the curl request on line 16 of docke container cli. Line 591 of netbox-docker.log in Attempt #2 corresponds with the curl request on line 10 of docker container cli.

I appreciate the time and effort that went into creating this setup and also for your time in diagnosing the issue I seem to be encountering. Thanks again.

dirkvdplas commented 6 years ago

I am having exactly same issue . Using a fresh Ubuntu 14.04, with docker Docker version 17.09.0-ce, build afdb6d4

sh0shin commented 6 years ago

If I attach to the ninech/netbox:latest image

docker run -it ninech/netbox:latest /bin/sh

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 206, in fetch_command
    klass = load_command_class(app_name, subcommand)
  File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 40, in load_command_class
    module = import_module('%s.management.commands.%s' % (app_name, name))
  File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/usr/local/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 15, in <module>
    from django.db.migrations.autodetector import MigrationAutodetector
  File "/usr/local/lib/python3.6/site-packages/django/db/migrations/autodetector.py", line 13, in <module>
    from django.db.migrations.questioner import MigrationQuestioner
  File "/usr/local/lib/python3.6/site-packages/django/db/migrations/questioner.py", line 12, in <module>
    from .loader import MigrationLoader
  File "/usr/local/lib/python3.6/site-packages/django/db/migrations/loader.py", line 10, in <module>
    from django.db.migrations.recorder import MigrationRecorder
  File "/usr/local/lib/python3.6/site-packages/django/db/migrations/recorder.py", line 12, in <module>
    class MigrationRecorder(object):
  File "/usr/local/lib/python3.6/site-packages/django/db/migrations/recorder.py", line 26, in MigrationRecorder
    class Migration(models.Model):
  File "/usr/local/lib/python3.6/site-packages/django/db/migrations/recorder.py", line 27, in Migration
    app = models.CharField(max_length=255)
  File "/usr/local/lib/python3.6/site-packages/django/db/models/fields/__init__.py", line 1061, in __init__
    super(CharField, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/django/db/models/fields/__init__.py", line 172, in __init__
    self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE
  File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 56, in __getattr__
    self._setup(name)
  File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 41, in _setup
    self._wrapped = Settings(settings_module)
  File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 129, in __init__
    raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.

Look like there is something wrong with the SECRET_KEY from netbox.env

0xVasconcelos commented 6 years ago

+1

Same here.

cimnine commented 6 years ago

Look like there is something wrong with the SECRET_KEY from netbox.env

No, @sh0shin. You started a new container, but you did not pass the environment variables. Use docker-compose run instead of docker run, or manually pass all the environment variables. docker does not know about the netbox.env file, only docker-compose does.

cimnine commented 6 years ago

I've just set up a blank server with Ubuntu 16.04. I've installed Docker from the repository as described in the manual. I've installed python-pip and then installed docker-compose with pip install docker-compose.

The versions are now:

$ docker version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ docker-compose version
docker-compose version 1.17.1, build 6d101fb
docker-py version: 2.6.1
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016

I cloned the repo like git clone https://ninech/netbox-docker.git. I ran docker-compose pull to fetch the images (instead of building the netbox image, maybe that's something I should add to the README).

Then, I ran docker-compose up and waited until all the migrations were done.

Finally, I ran docker-compose ps to get the local port and ran curl localhost:32768. So far I did not experience any error, it just works.

cimnine commented 6 years ago

Oh, now that I went over the gists of @bdlamprecht again I've found the culprit:

By default, the configuration of netbox-docker assumes you're connecting using the localhost hostname. Any other hostname is blocked by Netbox, 0.0.0.0 as well. This is controlled by the ALLOWED_HOSTS environment variable.

Changing ALLOWED_HOSTS=localhost in the netbox.env file to ALLOWED_HOSTS=localhost 0.0.0.0 will resolve your problem. I'll change the default to the most common used hosts.

bdlamprecht commented 6 years ago

Yes, this was the problem, with one caveat...

When I ran the updated version, I was still getting the same error (Bad Request (400)).
I then tried running docker-compose up without the -d to see the running logs of the netbox_1 container and it was showing the requests coming into the FQDN of the docker host (or node).

Comparing that with the changes you made in the netbox.env of d3dd6a2, I realized that it was the setup of nginx causing me grief.

I did a docker-compose down then altered the netbox.env to include to FQDN of my specific node, ran docker-compose up again and magically it worked.

In my specific environment, I have 3 nodes that are NOT running on my local machine, so the FQDN was something other than derivatives of localhost.

I'm not sure the best way to automatically include that (hostname -f) in the netbox.env file when that is used to build the container, but I think it would be helpful to do so others running this container in a similar manner don't encounter that issue.

cimnine commented 6 years ago

It's not used to build the container. The netbox.env file contains variables that are passed into the container. Anyone can change them to suit their needs. The default values simply provide a good start for local development.

To understand the concept better, I suggest to read up on how docker-compose handles environment variables .

vishnoisuresh commented 6 years ago

Hi, I have been trying to deploy netbox on kubernetes to learn it. However, I am stuck with Bad Request(400). As I can see that you have updated the value of ALLOWED_HOSTS=localhost 0.0.0.0 127.0.0.1 [::1] netboxdocker.docker nginx.netboxdocker.docker I was wondering what would be the correct value for kubernetes system. I have attached the link netbox-kubernetes. I can access it when I use port-forward as I need to use localhost however if I try to use NodePort then I get Bad Request.
I have limited knowledge of ALLOWED_HOST variable. Therefore, I am quite baffled by it. Thanks

cimnine commented 6 years ago

The correct value is whatever you type into your browser to access Netbox. So if it's "http://netbox.my-kubernetes.company.org", then the correct value will be ALLOWED_HOSTS=netbox.my-kubernetes.company.org. You can specify multiple variables separated by a space.

So if you have containers in other pods accessing netbox via e.g. "http://netbox", you will also have to add netbox to the list of ALLOWED_HOSTS.

Btw, this is not really a feature of netbox-docker, but belongs to netbox itself. If you have further questions, please seek help on the netbox mailing list. The only thing we do in this project is that you can specify the value via an environment variable for ease of configuration.

Also please open a new issue next time, as the problem here has been resolved already. So you spammed all the people in this thread (and I have to do it again) who have already had a solution to their problem.