search

mvantellingen / localshop

local pypi server (custom packages and auto-mirroring of pypi)
MIT License
397 stars 112 forks source link

Upgrade from 0.4.1 causes "500 server error" on /permissions/credentials/ page #173

Open TravellingGuy opened 8 years ago

TravellingGuy commented 8 years ago

We are trying to upgrade from an old localshop 0.4.1 virtualenv (running on an Ubuntu 11.10 server) to a new version of localshop on a new server (Ubuntu 14.04).

What I've done:

  1. I've copied over the complete virtualenv, the source directory and the localshop.db to the new server and started localshop and confirmed everything continues to work as expected (essentially using the old localshop virtualenv on the new server).
  2. Stop localshop.
  3. In the virtualenv, upgrade localshop (and all dependencies) to the latest version (0.9.2), by doing a pip install --upgrade localshop.
  4. Run localshop upgrade. The upgrade doesn't show any errors.
  5. Start localshop.

After starting localshop back up again, the web interface is mostly full functional except trying to go to the Permissions->Credentials page, I get a "500 server error". (Hence, I can't manage credentials.)

The issue seems to be that it's trying to load the css and js from the wrong location for some reason. Here's a log snippet showing what I mean, the first bit going to the /permissions/credentials/ page, and the second bit, going to the /permissions/cidr/ page, where it's properly loading assets from the /assets/ path.

[2016-04-14 21:59:29 +0000] [11586] [DEBUG] GET /permissions/credentials/
[2016-04-14 21:59:29 +0000] [11583] [DEBUG] GET /permissions/credentials/bootstrap/css/bootstrap.css
[2016-04-14 21:59:29 +0000] [11586] [DEBUG] GET /permissions/credentials/jquery-1.7.1.min.js
[2016-04-14 21:59:29 +0000] [11583] [DEBUG] GET /permissions/credentials/bootstrap/css/bootstrap-responsive.css
[2016-04-14 21:59:29 +0000] [11582] [DEBUG] GET /permissions/credentials/bootstrap/js/bootstrap.js
[2016-04-14 22:08:38 +0000] [11581] [DEBUG] GET /permissions/cidr/
[2016-04-14 22:08:38 +0000] [11582] [DEBUG] GET /assets/bootstrap/css/bootstrap.css
[2016-04-14 22:08:38 +0000] [11583] [DEBUG] GET /assets/jquery-1.7.1.min.js
[2016-04-14 22:08:38 +0000] [11587] [DEBUG] GET /assets/bootstrap/css/bootstrap-responsive.css
[2016-04-14 22:08:38 +0000] [11586] [DEBUG] GET /assets/bootstrap/js/bootstrap.js
[2016-04-14 22:08:38 +0000] [11580] [DEBUG] GET /assets/bootstrap/img/glyphicons-halflings.png
[2016-04-14 22:08:38 +0000] [11577] [DEBUG] GET /assets/bootstrap/img/glyphicons-halflings-white.png

I've tried various permuations, including upgrading in small steps. Upgrading from 0.4.1 to 0.6.0 exhibits the same issue.

Incidentally, if I move the localshop.db out of the way and "start fresh" with a localshop init, I don't see the problem. With the clean installation, I am able to access the credentials page without issue.

canassa commented 8 years ago

Hmm, did you try to enable the Django debug mode and reload the server? With the debug mode on you should get a full traceback on any error and that should give you a hint of what's going on.

You can enable the debug mode by adding a DEBUG = True to your localshop.conf.py

TravellingGuy commented 8 years ago

Thanks for the tip! The error is:

OperationalError at /permissions/credentials/ no such column: permissions_credential.comment

I'm guessing during an upgrade, the comment column (which I saw was new) doesn't get created. With that knowledge, I'm sure I can manually create the column to get us up and going.

TravellingGuy commented 8 years ago

I've manually added that column alter table permissions_credential add column comment char(255) default ''; and I can now get to the credentials page.

TravellingGuy commented 8 years ago

I think I know where my problem lies. (I'm not a python dev, so bear with me.) Even after fixing the missing comment column, I'm having further issues.

When I ran the upgrade (localshop upgrade), while it didn't throw any errors, it did indicate that all the migrations were "FAKED" (even though I didn't use the --fake argument). Running the migration again said there were "no migrations to apply", so I assumed that anything required was done, but it appears not.

So, I'm assuming my problems lie in the migration from "south" to the new migration stuff in django. Anyway, I'm going to try to follow the process here to see if I can "reset" the migrations or something. But hey, I'm learning lots!