Vijunja is absolutely impossible to install for anyone except a seasoned SysAdmin (or you've copy-pasted from that one guy on Reddit who actually got it to work in Docker-Compose).. #986
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#986
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi Folks,
First and foremost - I'm very passionate about this project and would love to cut my teeth on contributing where possible.
I wanted to outline a few troubles that I have installing Vikunkja on my Unraid box. I got front end and back end installed on there but can't use the application at all. Unfortunately Unraid doesn't have docker-compose by default, so I'm stuck installing the community app.
General:
Back end:
Front end:
To be frank, it seems a bit like the documentation is actually just developer documentation and not actually designed to help a user fix things. Almost makes me think I should just buy the service - because despite being a SysAdmin by trade I am completely unable to get this thing to work.
Vijunja is absolutely impossible to install for anyone except a seasoned SysAdmin.to Vijunja is absolutely impossible to install for anyone except a seasoned SysAdmin (or you've copy-pasted from that one guy on Reddit who actually got it to work in Docker-Compose)..Hi!
Sorry for the hassle. I agree the docs could be improved, what kind of docs do you need? Something that gives a general overview over the architecture and how things should work together?
Nextcloud is a different kind of application. Vikunja is split into frontend and backend to separate both areas of concern between each other. You could just host the api and use a desktop client without hosting a frontend at all.
You don't. You need to tell the frontend what api to use and while you can to that with a proxy configuration, you can also just use the env variable (if you're using docker) or set the api url manually when opening a frontend installation in your browser. Some docs about this are here.
Depends on the issue.
That sounds like it's something specific to the unraid app. We don't create nor maintain it, not sure how to help you with that.
Take a look at the docs here.
Docs are here, you can find the default config file here.
Why would you want to use nano in a docker container? That's not how you should use docker.
There's no default login or a wizard. You will need to create an account either by registering in the frontend or through the cli.
The other issues you seem to have look like they are related to your Vikunja installation not being connected to the api. See my response above about that.
To be frank, it sounds like you might want to learn docker and/or unRAID a bit more before taking it out on the dev here. Sure it isn't completely straightforward, but the info is all made available...
I am not a sysadmin, or do any IT work by trade - I am hobbyist and was able to make do.
I don't use unRAID, but I do know docker compose can be added to it, which I would recommend as it will open many more doors for you, or you could follow here to translate it into their gui container maker. My modifications to the compose file would be necessary making them as separate containers, which is essentially what you are doing in unRAIDs gui.
If you elect to go that route, you will need to also expose the db port (e.g. 3306:3306) and then change the VIKUNJA_DATABASE_HOST environmental variable to your servers IP (e.g. 192.168.1.50:3306)
I'll walk you through what I did, I started with the Vikunja provided compose, linked here.
All line #'s reference the original document, this will change following steps below:
If you already had a running mysql (which mariadb complies to), or other compatible database (postgres, sqlite) instance you could eliminate the 'db' service section (lines 4-14) entirely and configure the 'api' service section to do so.
You would change in line 18 db to the IP of your database.
I have a mariadb instance, but have elected at least initially keep Vikunja on its own instance and eventually migrate it to my primary database.
Changed this to what I prefer (line 8)
and changed this (line 10)
Changed volumes to references a specific directory instead of current directory (line 12-13)
In api section, matched line 20 with the password set in line 10
And changed volume to reference specific directory (line 23-24)
Added ports section to be able to reference API via IP/port instead of it being limited to this docker stack via name (can be any open port, I chose 38081, just needs to map to 3456)
Front end section only modification is changing the port so that we are not forced to use port 80 (which I was already using). This again can be any valid port number, it just needs to map to port 80.
Then deploy the stack, and access the frontend via http://{docker.host.ip}:38080 (or whatever port you chose in place of 38080), you will then need to click the button on this page to change where the API is located, replace with http://docker.host.ip:38081 (or whatever port you used in place of 38081) and you're done.
You don't need to use the proxy service section (lines 31-40) entirely if you go this route, because we defined (exposed) the ports outside of this stack.
You are then free to do whatever with the IP/ports for the front end and api, I chose to put the in my nginx-proxy-manager instance which is just nginx with a gui which I already had running, which allows me to access them by my defined domain name.
I've managed to install a standalone installation OK without using docker. I actually thought it was relatively simple compared to some of the things I've wasted hours on in the last week (ie Turtl and Jitsi meet - both of which I've finally given up on).
It's on my todo list to document exactly what I did to get it working - I'll post a link on here once I'm done.
I too am struggling with setting up a local instance.
With the addition of vikunja/api#1174 getting a standalone installation up and running is a little easier:
Two additional enhancements would make getting up and running even easier:
Embed a copy of
frontend
within the backend using Go'sfs.FS
andembed
packages. This would increase the binary size but simplify distribution and set up.Include a reverse proxy,
http/httputil
'sReverseProxy
, to serve a copy of the frontend static files from a trusted central server. This avoids the embedding but requires Internet access from the backend host.