Morkg's picture

Hi Jeremy Davis

   Thank you for the previous information, to clarify on the last part I meant 3.2.0 anything above 3.1.9+ ends up breaking,

I did try going up one update at a time still keeps on breaking, right now what I noticed is after the upgrade it seems like I end up in an infinite loop at login, the update seems to go through just fine using ssh no errors but when I try to get to Mayan login page I end up in an infinite loop, I accidentally left my self logged in and checked the version from the GUI and it did show it was updated but when I logged off I ended up not able to get to the login page with the loop

do you think it has to do with the ngix setup and redirect?

 

Forum: 
Jeremy Davis's picture

I'm not sure if it's related to your issues, but the first thing I tried was to update to the last v3.1x release. According to Mayan docs that should be v3.1.11 but when I tried to update to that, I got this error:

Collecting mayan-edms==3.1.11
  Could not find a version that satisfies the requirement mayan-edms==3.1.11 (from versions: 1.0rc1, 1.0rc2, 1.0rc3, 1.0.0, 1.1.0, 1.1.0.post1502100955, 1.1.1, 2.0.0b1, 2.0.0b2, 2.0.0rc1, 2.0.0, 2.0.1, 2.0.2, 2.1rc1, 2.1rc2, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.10, 2.1.11, 2.2b1, 2.2b2, 2.2b3, 2.2rc1, 2.2, 2.3, 2.4, 2.5, 2.5.1, 2.5.2, 2.6, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.7, 2.7.1, 2.7.2, 2.7.3, 3.0, 3.0.1, 3.0.2, 3.0.3, 3.1, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.1.7, 3.1.8, 3.1.9, 3.1.10, 3.2b1, 3.2rc1, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7, 3.2.8, 3.2.9, 3.2.10, 3.2.11, 3.3, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.3.6, 3.3.7, 3.3.8, 3.3.9, 3.3.10, 3.3.11, 3.3.12, 3.3.13, 3.3.14, 3.3.15, 3.3.16, 3.3.17, 3.4, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7)
No matching distribution found for mayan-edms==3.1.11

So i fugures that I might as well just upgrade to v3.1.10 fo starters... Here's the full commands I ran:

REMOVE=/etc/mayan/removals.txt
curl https://gitlab.com/mayan-edms/mayan-edms/raw/master/removals.txt > $REMOVE
supervisorctl stop all
ENV=/etc/mayan/env
BIN=/opt/mayan-edms/bin
su - mayan -c ". $ENV && $BIN/pip uninstall -r $REMOVE"
su - mayan -c ". $ENV && $BIN/pip install --no-cache-dir mayan-edms==3.1.10"
supervisorctl start all

Note that the '-no-cache-dir' switch just stops this warning:

The directory '/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.

After I've run that, I logged in via the web browser and everything seems to "just work"?! The about page (/#/about/) reports that the version is v3.1.10?! Obviously my copy doesn't actually have any data in it, but it all seems to be working ok?!

I wonder if there is some sort of issue with your browser caching info? Perhaps try doing a "hard refresh" (to clear cache and cookies) - usually that is by holding Control and hitting f5. And/or try loading Mayan via a private/incognito browser session (by default will disable browser addons/extensions and will have no cached data or cookies).

Jeremy Davis's picture

FWIW I can reproduce your issue.

I'm not 100% sure what the cause is, but after upgrading to v3.2, when I clear all my browser cache and cookies and go to my server in my browser, I'm getting a weird redirect loop with a URL of:

https://MY_SERVER_IP/authentication/login/?next=/#/authentication/login/?next=/

Although, when I opened the "developer console" I notice this message is showing (between the redirects):

Server error
There's been an unexpected error.

What to do next?
 - Refresh the page.
 - Wait a bit. The system might be overloaded.
 - Contact your system administrator.
 - Check the logs for messages with the tags "ERROR", "CRITICAL" or "FATAL".
 - Open a ticket using the issue tracker.

If I look in the system journal (i.e. journalctl) it seems clear that the Mayan supervisord services are crashing and being restarted. There are also Python errors being noted in the Supervisor logs (files in /var/log/supervisor/). So it seems clear that there are some python errors occurring.

I've messed up my server so bad now, I probably need to start again...

FWIW, I'm not sure if it's related at all, but when I try to run the DB migration, it throws an error too.

It may be possible to simply migrate the data/documents to a new install? Actually, seeing as the old Mayan appliance was using Python2 and (when we get to it) the new Mayan appliance will use Python3, perhaps now is a good time to look at that migration?!

Morkg's picture

Yes, I have a VM installed been playing with it, any version upgrade above 3.1.10 breaks or does the infinite loop, i ran an upgrade on the server just to get everything up to date, the supervisor seems to be running fine when i run it but i think there is something breaking with calling the supervisor which creates an endless loop,

I will try to upgrade python on my VM and see if that fixes up the issue, too much data to migrate my option is to update :)

 

Thank you for your help

Jeremy Davis's picture

Migrating the docs/data should be fine. The amount of docs/size of the data should be irrelevant (might just take a bit longer...). I haven't tested, but AFAIK, simply copying the files and the database, then running the DB migrations (to bring the DB schema up to date with the current code) should do the trick.

Regarding the update, I didn't look into it closely, but the "proper" way to diagnose the issue would be to look more closely at the python stacktraces that I noted and/or the database migration error I noted that I got.

I can't promise a timeframe, but hopefully we'll have a newer Mayan appliance within the next week or 2. It will include the latest Mayan version. As Mayan now supports Python3 (I forget when this was added), our new appliance will install for that. IMO migrating data to a new python3 install will be cleaner and less likely to cause issues than upgrading. As I note above, migrating your existing docs/data should be fine.

Sorry I don't have anything more immediate for you. If you persevere and wish to share any further info you collect and/or have any more questions, please don't hesitate to post back and I'll do my best to answer.

Morkg's picture

Hi Jeremy

  thank you for the update, I will wait for the newer version since i have a lot of data to move and i like the configuration that this iso has, please let me know when you have an iso ready and i could deploy it and help you with testing if needed,

 

I have tried a lot of things with the update but its not working, I will try to update python first and see if that would clear the infinite redirect.

 

Thank you

 

Jeremy Davis's picture

I wouldn't recommend just trying to update python. A stable Linux distro like Debian, is built in such a way that everything is built against specific versions. So installing stuff from third party sources, or just updating a particular piece of software from an alternate source may well create a whole new world of pain!

You could try updating the version of Python that Mayan-EDMS uses (AFAIK, it can use Python2 or Python3) but I suspect that would be a pain too. Debian 9/Stretch (the basis of TurnKey v15.x) provides Python3.5 which is not an ideal version of Python IMO...

Another path you could try is updating the underlying Debian version. That will give you an updated version of Python, but TBH I'm not convinced that will fix it either.

Like I said in my last post, if you actually want to try to fix your current install, you need to look at the python stacktraces (in the supervisor logs) and get a better understanding of what is going wrong. Even if they mean nothing to your, armed with those stack traces, you can probably ask the Mayan devs for assistance on what might be going wrong. They may well be able to tell straight away? Otherwise you're just blindly throwing stuff and hoping something sticks and TBH, I'm not convinced that anything will...

As something of an aside, I have updated the build code for a v16.0 TurnKey Linux Mayan-EDMS appliance and it seems to be working well (based on my tests so far). I also tested migrating he docs from a v15.x instance to a (test) v16.0 instance and it "just worked" as I expected. The only thing missing was the doc thumbs, but I clicked something in the UI to "rescan" (or similar) and that was fixed.

Unfortunately, though, I haven't quite finished the Mayan appliance update and I've been waylaid with other stuff. I'll hopefully get back to building, testing and publishing updated appliances ASAP so I can get this released for you (and others).

Morkg's picture

Hey Jeremy,  thank you for the follow-up, I actually couldn't just update anymore, trying to build an appliance from scratch using turnkey but its a learning curve trying to figure out how to manage the appliance first, I will keep using what I have until you are done with the latest appliance which will help a lot with deployment moving files over shouldn't be that hard.

Thank you

Jeremy Davis's picture

I have done most of the work, I just need to do a bit more testing and do the final build and get it published.

Unfortunately, I've had a few other "plates spinning" (jobs on the go) so haven't had a chance to finish it. Hopefully that will happen next week.

Re moving docs, as I think I said, I tested migrating docs (and database) and it seemed to work well.

Morkg's picture

Hi Jeremy

  can you let me know how did you point Mayan from port 8000 to 80? I deployed the LAPP appliance and did install Mayan direct install on it and its working good but what I'm encountering right now is pointing from port 8000 to port 80, currently, when visiting the IP it's going to the Apache web server.

thanks

Jeremy Davis's picture

I was going to suggest that you could just use the config from the Mayan-EDMS appliance to enable that, but unfortunately, it's not that simple as Mayan uses Nginx as the webserver and LAPP uses Apache. The config between the 2 different web servers is not directly transferable.

IMO Nginix is a much better choice for reverse proxying (it's lighter weight and it was originally built to do that). however, Apache can also do reverse proxy. TBH, I don't know the config OTTOMH, but a quick google turned up this:

<VirtualHost *:80>
    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
</VirtualHost>

I'd put that in a new file (call it something like 'mayan.cnf') in /etc/apache/sites-available/. You'll need to disable the default site, and enable this new site. You may also want to add a port 443 (https) virtualhost too (exactly the same as above, but change the '80' in the first line to '443'). I think that you also need to enable the proxy module(s)?! So something like this perhaps?

# disable default site
a2dissite 000-default
# enable new site
a2ensite mayan
# enable proxy modules; not sut if both of these are required?
a2enmod proxy
a2enmod proxy_http

Hopefully that works, but if not, keep in mind that TurnKey is based on Debian. So if you do a web search, you should find plenty of info. Please post back and let us know how you go.

Add new comment