Manual Install Assistance


I’m a new user, so this is probably user error (bad config?), but I don’t seem to be able to see my mistake.

I manually set up Vikunja 23 on an Ubuntu 22.04 instance (Graviton based) a few days ago, and everything worked fine. I added a couple of users and 100 cards or so. Great! Since then I had to reboot the server and now it no longer works? Not sure what I’ve done wrong, but hopefully if I post my actions / config someone will be able to point out my mistake so that others might benefit from it.

wget -q -O ~/
sudo mkdir /opt/vikunja
sudo unzip ~/ -d /opt/vikunja
sudo chmod +x /opt/vikunja
sudo ln -s /opt/vikunja/vikunja-v0.23.0-linux-arm64 /usr/bin/vikunja
sudo nano /opt/vikunja/config.yml
  JWTSecret: "<jwt-secret>"
  jwtttl: 259200
  jwtttllong: 2592000
  publicurl: ""
  rootpath: "/opts/vikunja"
  maxitemsperpage: 50
  enablecaldav: true
  motd: ""
  enablelinksharing: true
  enableregistration: false
  enabletaskattachments: true
  timezone: "Europe/London"
  enabletaskcomments: true
  enabletotp: true
  testingtoken: ""
  enableemailreminders: true
  enableuserdeletion: true
  maxavatarsize: 1024
  demomode: false
  allowiconchanges: true
  customlogourl: ""

  enabled: false
  dsn: ""
  frontendenabled: false
  frontenddsn: ""

  type: "postgres"
  user: "vikunja"
  password: "postgres_password"
  host: "localhost"
  database: "vikunja"
  path: ""
  maxopenconnections: 100
  maxidleconnections: 50
  maxconnectionlifetime: 10000
  sslmode: "disable"
  sslcert: ""
  sslkey: ""
  sslrootcert: ""
  tls: false

  enabled: false
  url: ""
  apikey: ""

  enabled: true
  host: "localhost:6379"
  password: ""
  db: 10

  enable: false
    - "*"
  maxage: 0

  enabled: false
  host: ""
  port: 587
  authtype: "plain"
  username: "user"
  password: ""
  skiptlsverify: false
  fromemail: "mail@vikunja"
  queuelength: 100
  queuetimeout: 30
  forcessl: false

  path: "/opts/vikunja/logs"
  enabled: true
  level: "INFO"
  databaselevel: "WARNING"
  http: "stdout"
  echo: "off"
  events: "off"
  eventslevel: "info"
  mail: "off"
  maillevel: "info"

  enabled: false
  period: 60
  limit: 100
  store: "redis"
  noauthlimit: 10

  basepath: "./files"
  maxsize: "20MB"

    enable: false
    clientid: ""
    clientsecret: ""
    redirecturl: ""
    enable: false
    key: ""
    redirecturl: ""
    enable: false
    clientid: ""
    clientsecret: ""
    redirecturl: ""

  gravatarexpiration: 3600

  enabled: true
      enabled: true
      enabled: false
      accesstoken: ""
      applicationid: ""

  imprinturl: ""
  privacyurl: ""

  type: "redis"

    enabled: true
    enabled: false
      - name: ""
        authurl: "" 
        logouturl: ""
        clientid: ""
        clientsecret: ""

  enabled: false
  username: ""
  password: ""

  avatar_provider: "initials"
  avatar_file_id: 0
  email_reminders_enabled: false
  discoverable_by_name: true
  discoverable_by_email: true
  overdue_tasks_reminders_enabled: true
  overdue_tasks_reminders_time: "9:00"
  default_project_id: 0
  week_start: 1
  language: "en_GB"
  timezone: "Europe/London"

  enabled: true
  timoutseconds: 30
  proxyurl: ""
  proxypassword: ""

(I ran this through a YAML check to confirm that it’s valid, but it’s not a format that I normally use)

I installed a service:

# Depending on how you configured Vikunja, you may want to uncomment these:

# If you want to bind Vikunja to a port below 1024 uncomment
# the two values below


And set it to automatically start (which it does):

sudo systemctl enable vikunja
sudo systemctl start vikunja

Since this is a private instance, I disabled signups and added my user manually:

vikunja user create -u "paul" -e "" -p "my_secure_password"

Which appears when I check:

vikunja user list

Lastly, I put Nginx in front of it:

server {
	listen		443 ssl http2;
	listen		[::]:443 ssl http2;

	include		ssl.d/;
	location / {	
		proxy_http_version		1.1;
		proxy_cache_bypass		$http_upgrade;
		proxy_set_header		Upgrade $http_upgrade;
		proxy_set_header		Connection 'upgrade';
		proxy_set_header		Host $host;
		proxy_set_header		X-Real-IP $remote_addr;
		proxy_set_header		X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header		X-Forwarded-Proto $scheme;
		client_max_body_size	20M;

This all worked and I used the service happily for a day. I can still start the service, and I can connect to my PostgreSQL database and see that the data is all there (including the users), but I can’t login and note that no logs have been created?

I assumed that in my intially faffing I must have started it with a slightly different config, used that and subsequently broke it when changing something slightly later - but I don’t know what?!

Manually testing it to get some debug output, it seems to be running correctly (DB and all):

sudo /usr/bin/vikunja
2024-04-05T10:42:39.617734082Z: INFO    ▶ config/InitConfig 001 Using config file: /opt/vikunja/config.yml
2024-04-05T10:42:39.662818304Z: INFO    ▶ migration/Migrate 05c Ran all migrations successfully.
2024-04-05T10:42:39.662927519Z: INFO    ▶ models/RegisterReminderCron 05d Mailer is disabled, not sending reminders per mail
2024-04-05T10:42:39.66299416Z: INFO     ▶ models/RegisterOverdueReminderCron 05e Mailer is disabled, not sending overdue per mail
2024-04-05T10:42:39.663255159Z: INFO    ▶ cmd/func29 05f Vikunja version v0.23.0
⇨ http server started on [::]:3456

Visiting the login page looks fine too:

2024-04-05T10:42:43.98407609Z: WEB      ▶  GET 304 /login 7.273356ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
2024-04-05T10:42:44.019970183Z: WEB     ▶  GET 304 /assets/index-2pE4QXrP.js 3.913525ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
2024-04-05T10:42:44.02193177Z: WEB      ▶  GET 304 /assets/index-VlJ-wnF6.css 5.898619ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
2024-04-05T10:42:44.112283074Z: WEB     ▶  GET 200 /api/v1/info 316.415µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
2024-04-05T10:42:44.977562079Z: WEB     ▶  GET 304 /sw.js 386.37µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

But pressing login (with my user details - correct and loaded from Bitwarden):

2024-04-05T10:42:52.826610597Z: -       ▶ echo recover.go:120 [PANIC RECOVER] interface conversion: interface {} is string, not int64 goroutine 306 [running]:
        /srv/app/pkg/mod/ +0x13c
panic({0x147d7e0?, 0x4000732cc0?})
        /usr/local/go/src/runtime/panic.go:770 +0x124
        /source/pkg/user/user.go:373 +0x434, 0x4000177800)
        /source/pkg/user/user.go:348 +0x108{0x43a55a0, 0x40004bc000})
        /source/pkg/routes/api/v1/login.go:56 +0xa8{0x43a55a0, 0x40004bc000})
        /source/pkg/routes/rate_limit.go:72 +0x5a4{0x43a55a0, 0x40004bc000})
        /source/pkg/routes/routes.go:234 +0x184*Echo).add.func1({0x43a55a0, 0x40004bc000})
        /srv/app/pkg/mod/ +0x50{0x43a55a0, 0x40004bc000})
        /source/pkg/routes/static.go:161 +0x16c{0x43a55a0, 0x40004bc000})
        /srv/app/pkg/mod/ +0x238{0x43a55a0, 0x40004bc000})
        /srv/app/pkg/mod/ +0xe8{0x43a55a0, 0x40004bc000})
        /srv/app/pkg/mod/ +0xa0*Echo).ServeHTTP(0x4000392d88, {0x437ff30, 0x40001c4620}, 0x400052d0e0)
        /srv/app/pkg/mod/ +0x318
net/http.serverHandler.ServeHTTP({0x437c1a8?}, {0x437ff30?, 0x40001c4620?}, 0x6?)
        /usr/local/go/src/net/http/server.go:3137 +0xbc
net/http.(*conn).serve(0x40004a03f0, {0x43828a0, 0x40006364e0})
        /usr/local/go/src/net/http/server.go:2039 +0x508
created by net/http.(*Server).Serve in goroutine 14
        /usr/local/go/src/net/http/server.go:3285 +0x3f0

goroutine 1 [chan receive]:, {0x161f101?, 0x4?, 0x161f105?})
        /source/pkg/cmd/web.go:98 +0x158*Command).execute(0x4d70780, {0x400013a120, 0x0, 0x0})
        /srv/app/pkg/mod/ +0x828*Command).ExecuteC(0x4d70780)
        /srv/app/pkg/mod/ +0x344*Command).Execute(...)
        /source/pkg/cmd/cmd.go:44 +0x24
        /source/main.go:22 +0x1c

goroutine 9 [select]:
database/sql.(*DB).connectionOpener(0x40004ce340, {0x43828d8, 0x4000462640})
        /usr/local/go/src/database/sql/sql.go:1246 +0x80
created by database/sql.OpenDB in goroutine 1
        /usr/local/go/src/database/sql/sql.go:824 +0x140

goroutine 11 [select]:
database/sql.(*DB).connectionCleaner(0x40004ce340, 0x0?)
        /usr/local/go/src/database/sql/sql.go:1089 +0x90
created by database/sql.(*DB).startCleanerLocked in goroutine 1
        /usr/local/go/src/database/sql/sql.go:1076 +0xf8

goroutine 12 [select]:*Cron).run(0x40004aa500)
        /srv/app/pkg/mod/ +0x920
created by*Cron).Start in goroutine 1
        /srv/app/pkg/mod/ +0x104

goroutine 13 [chan receive]:*Router).Run(0x40001c42a0, {0x4382360?, 0x4f44720?})
        /srv/app/pkg/mod/!three!dots!labs/watermill@v1.3.5/message/router.go:374 +0x234
        /source/pkg/events/events.go:96 +0x35c
        /source/pkg/initialize/init.go:104 +0x1b4
created by in gorou

2024-04-05T10:42:52.826892396Z: WEB     ▶  POST 500 /api/v1/login 170.797494ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

Which shows that Go is trying to incorrectly unpack something into an integer when it’s actually a string, but also potentially that somehow my password is incorrect? (it isn’t, or at least it hasn’t changed since the initial successful system use).

This is almost certainly my fault, but I’m not sure what I’ve messed up / am doing wrong… Any help is appreciated!

Having started to mess with this more, it does seem to be a password issue, but also something a little deeper.

The CLI docs are incorrect for editing a user’s password (missing the ID field), but if I run:

vikunja user reset-password 1 -d -p "my_secure_password"

Then I can log in. Great!

But reboot the server and try again and I get the same error?!

Welcome to Vikunja!

This looks like a problem with redis. Does it work if you set keyvalue.type to memory?

While the default config file contains all options with their default values, you only need to add the values which you changed. Might make it more readable.

After many unsuccessful restarts, I think that this may have boiled down to my typos of /opts/ rather than /opt/! (service.rootpath: "/opt/vikunja" and logs.path: "/opt/vikunja/logs")

I created a separate local-only Redis instance to test with, tried memory mode etc and it didn’t work through a reboot, but after updating those values it finally seems to. I will post back if the last one was just a fluke.

I left all the options in just so that I had an idea of what exactly I had control over (without having to refer to a webpage), but yes, it would be easier to read without them.

Thanks for the help!