After an extensive search through a number of ‘to do’ style self hosted options, I’ve settled on Vikunja. It’s best suited to my requirements and I’ve gotta say it’s just awesome in simplicity, features and implementation! (well done devs and contributors!)
I currently run a FreeNAS server, and utilise jails for all of my self-hosted apps. My question is, what is the best way to get Vikunja up and running on FreeBSD? Docker simply doesn’t work with FreeBSD. I could spin up a Linux VM, but I’d much much much prefer to run it in a jail if possible. Is FreeBSD support anticipated at any point in the near future? Is there a hacky workaround that I could implement in the interim?
Unfortunately the xgo tool which I use for cross-compiling vikunja for various platforms does not seem to support freebsd. I’ve talked to the other maintainers and will try to provide builds for freebsd once support for it is ready.
I think the “hacky workaround” would be to use a Linux VM
In the meantime, if you don’t mind compiling vikunja for yourself you could try something like the following (not neccarily from the nas itself, this should also work from your workstation):
GOOS=freebsd GOARCH=amd64 make build
(assuming amd64 as the architecture of your nas, if you’re using something else, you’ll need to change that.)
You should be able to run the resulting binary in a freebsd jail.
You will also need to host the frontend either through nginx or apache but I assume running either of these is a solved problem on freebsd. If you have any issues regarding the configuration of them, please don’t hesitate to hit me up.
Unfortunately I can’t provide much assistance for freebsd as I’m not using it myself.
I’ve spent the morning trying to compile Vikunja for myself as you’ve suggested above, but as I don’t have a dev background so I’m a bit stuck.
After 3 hours of troubleshooting I FINALLY got past all of ‘missing package’ type errors when running make build. So I can run that successfully and it builds the binary for windows
So now, I’ve now set GOOS=freebsd and GOARCH=amd64 ready to build for my server, however when I run either make build or make generate in CMD, I get this error:
go generate code.vikunja.io/api/pkg/static
exec: "C:\\Users\\Skelly\\AppData\\Local\\Temp\\go-build118681166\\b001\\exe\\templates_generate": file does not exist
pkg\static\static.go:17: running "go": exit status 1
make: *** [generate] Error 1
Any idea what is happening here? Looks to be an issue with the static template files
You will also need to host the frontend either through nginx or apache but I assume running either of these is a solved problem on freebsd.
And yeah, I run an nginx reverse proxy so the front end part should be a breeze
I don’t get exactly the same error, but a segmentation fault, I guess that’s pretty much the same:
$ GOOS=freebsd GOARCH=amd64 make build
go generate code.vikunja.io/api/pkg/static
signal: segmentation fault (core dumped)
pkg/static/static.go:17: running "go": exit status 1
(Running on linux)
So it seems like this is not a fault in your setup but rather a general issue. I’ll take a look, hopefully this is already a known bug in the bindata library I’m using
However, I was able to build the binary with running make generate (without any env for freebsd set) first and then running make vikunja. The generate step is used to compile the mail templates directly into the binary for easier deployment. It does this by generating go code which essentially contains the templates as string constants, therefore it should not matter what os/arch it was generated for.
The “missing package” errors you mentioned are kind of interesting since afaik it should download all missing packages automatically when compiling… so maybe that’s a windows thing
go generate code.vikunja.io/api/pkg/static
exec: "C:\\Users\\Skelly\\AppData\\Local\\Temp\\go-build362703238\\b001\\exe\\templates_generate": file does not exist
pkg\static\static.go:17: running "go": exit status 1
make: *** [generate] Error 1
output of GOOS=freebsd GOARCH=amd64 make vikunja:
make: *** No rule to make target `vikunja'. Stop.
I’m running the commands from within .../code.vikunja.io/api/
So after thinking through what we’ve tried above, I’ve spun up a jail on my NAS and managed to successfully run generate/build directly on freebsd!!! No idea why I got windows involved in the first place
Here are the notes I took while getting it up and working (note: this is for the ‘backend’ only - I haven’t had the time to start looking at the front end yet):
New user installing on FreeBSD here. I have some questions…but first a correction or two, assuming I am sanely doing things here. The following is apparently needed to get mage on a system that isn’t using go so much:
go install github.com/magefile/mage
then I did this
${GODIR}/bin/mage build
This seemed to produce a binary executable named “vikunja” in the top level directory I git cloned from.
Next, you provide the following commands
gmake generate
gmake build
but there is no Makefile in the github repo so these commands will not work.
Finally, some questions, please pardon my naivete here:
Is there a way to get vikunja to listen on a unix domain socket instead of :? This ensures that no one can use localhost exploits to access the api.
In a similar vein, my postgres listens on another unix domain socket. Is this configurable in vikunja and if so, how?
Hi Dave. The migration from gmake to mage occurred within a week or so of my post. The instructions were updated at the docs link above to reflect this - I just didn’t go back and edit my original post
I think someone else will be better placed to answer your unix domain socket questions, as I don’t have any experience with them myself.
Are there any plans for having Vikunja listen on a unix socket? Not only is this more secure in many cases, but it’s also way faster. One source of this information.
No plans currently. I’d accept a PR for that though.
For the performance: I think the performance improvements are negligible since you usually always want to expose Vikunja to the network. At that point you’ll add the overhead you’ve previously saved back in. And we’re talking about a few µs here anyway
Do I submit a PR for feature requests on your gitea?
As to performance, I run many webapps proxied through nginx…for performance and security (i.e. proxy_pass as documented in your nginx reverse proxy docs). The benchmarks I have seen and performed in FreeBSD … comparing a connection to localhost vs a unix domain socket … are significant, and at scale a few microseconds is still a welcome improvement. Each API access through your proxy, if connecting to localhost, is effectively two network connections, which is 2 copies of things like socket buffers per access. If your server is handling 1000s of connections, these things add up.
That being said, I do recognize the performance argument as delving into the nitpicky. My stronger rationale is security, as you can control what UID accesses a unix domain socket easier than you can control what UID accesses 127.0.0.1.
No idea why I got windows involved in the first place 
