Hello,

 

I am running the mayan-edms 16.1 image on proxmox and am having trouble with my initial log in.  The mayan login page is accessible through nginx and also directly on :8000 but both time out if I enter the proper credentials.  If I log in with email or improper creds the page returns right away.  I can get a password reset email.  Any ideas?

Forum: 
Tags: 
Jeremy Davis's picture

We've only just published that one. I personally tested it prior to publishing, although I didn't do it within a container, so perhaps there's something specific going on there?!

Actually, I've just fired one up and it seems to work ok for me?! How much resources does your server have? FWIW, mine has 2 vCPUs & 1GB RAM & 1 GB swap. If you've only given it a small amount of RAM, perhaps it's running out? I log into mine with username 'admin' and password I set and firstboot and I get straight in.

If it's not resources, the only other thing that I can think, is perhaps there is some really weird edge case with one the characters in your password that is causing the issue (seems highly unlikely, but ...).

I used 4GB and 4 cores then tried again with 6gb of ram and had the same result.  No special characters in my password, just alphanumerics.

I turned on proxmox nesting option on a hunch and mayan is working properly now.

Jeremy Davis's picture

Ah ok. I didn't consider that the issue might be because it's a privileged container (which it sounds like it is - if you had to enable nesting to get it to work properly). The default on Proxmox should be to use an unprivileged container and that's what I'd recommend. I know that previous versions of TurnKey (i.e. v15.x and prior) didn't play nice in a unprivileged container (without some serious tweaking). But we resolved that for v16.x.

Now in v16.x we more-or-less have the opposite problem. TurnKey LXC containers won't run nicely when priveledged (although as you've discovered, it's not so black and white as the previous scenario). FWIW this issue is a conflict between LXC and some of the service security hardening (i.e. systemd tweaks) done by Debian. The systemd hardening is not compatible with privileged LXC containers when the current version of systemd packaged in Debian 10/Buster (the basis of TurnKey and Proxmox) is both host and guest. Fingers crossed that they sort that out in Debian 11/Bullseye (I've heard rumour that the newer version of systemd in Bullseye should work fine with LXC but we'll need to see..!)

Whilst nesting a privileged container will work around the issue, it does have security implications for the host. On a small network for your personal usage, it's probably not that big a deal to just leave it like that. Although best practice would dictate that you run it unprivileged where possible. So I would highly recommend that you make it an unprivileged container (I forget if you can switch an existing container or not, but so long as you haven't loaded much, better to do sooner than later).

Good to know.  I have been using a lot of your appliances (Thank you!) and have been in the habit of setting them up as privledged from my experience with the earlier series.  I'm in a small and segmented environment so I haven't been too worried about the security implications, but I was only going privledged to get around prior issues so I'm happy to go back to the default.  I think I can just uncheck a box and go back to unprivledged so will give that a shot.  If not this is still a demo system so I can start over if needed.

Thanks for the help!

Jeremy Davis's picture

Glad to hear that they've been giving you some value! :)

Please feel free to share any other feedback/suggestions/etc you have. We probably won't be adding any new major features anytime soon, but it's always really good to hear from other people how they find it. I personally use TurnKey (and Proxmox) a fair bit and can be a biased I guess... So it's always good to get more independent and unbiased feedback!

Add new comment