I am trying to start atuin-server (v18.0.0) with the command…
atuin server start
… but it fails with this error:
Error: failed to connect to db: PostgresSettings { db_uri: "postgres://macslow:XXXXXXXX@localhost/atuin" }
Caused by:
Other(while executing migrations: error returned from database: syntax error at or near "trigger"
Caused by:
0: error returned from database: syntax error at or near "trigger"
1: syntax error at or near "trigger"
The ~/.config/atuin/server.toml I use looks like this:
host = "0.0.0.0"
port = 8888
open_registration = true
db_uri="postgres://macslow:XXXXXXXX@localhost/atuin"
I have postgres setup on that machine and can login using the typical psql-command. Locally I can connect to the running postgres with…
psql -U macslow -d atuin -h localhost -p 5432
… and remotely I can connect using…
psql -h macslow.org -U macslow -p 5432 -d atuin
The tables of database ‘atuin’ look like this…
Schema | Name | Type | Owner
--------+--------------------------+-------+---------
public | _sqlx_migrations | table | macslow
public | folks | table | macslow
public | history | table | macslow
public | sessions | table | macslow
public | stuff | table | macslow
public | total_history_count_user | table | macslow
public | users | table | macslow
What am I missing? The error-message does not give me any clue of what might be wrong. What is meant by the term ‘trigger’?
Error: failed to connect to db: PostgresSettings { db_uri: "postgres://macslow:XXXXXXXXX@localhost/atuin" }
Caused by:
Other(pool timed out while waiting for an open connection
Something is still off.
Also connecting remotely does not longer seem to work… or at least it hangs.
Hm… the open ports on my server look not that ‘promising’…
PORT STATE SERVICE
80/tcp open http
113/tcp closed ident
443/tcp open https
2000/tcp open cisco-sccp
3306/tcp closed mysql
5060/tcp open sip
No PostgreSQL on 5432 or 5433… that cannot work then I guess sigh
In the meantime I managed to get PostgreSQL 14.x working with accepting remote connections again and also opened the correct ports for incoming traffic through my firewall.
Now trying to start atuin-server (on my server-machine) I issue the command…
atuin server start
… and the thing just sits there… not coming back to the shell-prompt. Is that expected? It does not detach from the shell-process?!
I guess it is ok, since I see that ‘something’ has populated the atuin-database on the server with these tables…
Schema | Name | Type | Owner
--------+--------------------------+-------+---------
public | _sqlx_migrations | table | macslow
public | history | table | macslow
public | records | table | macslow
public | sessions | table | macslow
public | store | table | macslow
public | total_history_count_user | table | macslow
public | users | table | macslow
Registering for an Atuin Sync account
Atuin version mismatch! In order to successfully sync, the server needs to run a newer version of Atuin
Client: 18.0.0
Server: 17.1.0
Error: could not register user due to version mismatch
That does not make sense. I have the exact same version of atuin on both systems. It’s v18.0.0 compiled via cargo.
So what is wrong now? Is the local atuin perhaps not reading my ~/.config/atuin/server.toml?
When I comment the sync_address-line in ~/.config/atuin/config.toml something happens upon issuing the command atuin register..., but nothing gets updated in my server’s atuin-database. This probably landed in the public sync-server setup by @ellie I assume.
Could it be that for some reason the version string my atuin binary for the server part is wrong?
I have not found any hint that I have to make my server reply with a custom http(s) response-header for the atuin-client to be able to start talking to the PostgreSQL. For sure the missing atuin-version-field is missing from my server’s response-header… since I do not provide any special header at all.
I am running apache2 2.4.52 on that server-machine. I assumed the db_uri-line in ~/.config/atuin/server.toml on my client machines was providing enough information. The host-line in that file always seemed redundant to me.
How/where do I best provide that required custom http(s) response-header?
I tried something at https://macslow.org/atuin.json and even got the a custom-header entry for atuin-version going. But that still isn’t enough to have the atuin-client being able to register with my sever via PostgreSQL.
Not sure if this type of info helps debugging the issue, but here it goes… the output of GET -e https://api.atuin.sh vs GET -e https://macslow.org/atuin.json…
200 OK
Connection: close
Date: Thu, 15 Feb 2024 22:18:37 GMT
Server: cloudflare
Content-Length: 258
Content-Type: application/json
Atuin-Version: 18.0.0
CF-Cache-Status: DYNAMIC
CF-RAY: 8560ed80ca9862e9-HAM
Client-Date: Thu, 15 Feb 2024 22:18:37 GMT
Client-Peer: 2606:4700:20::681a:6cd:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=E1
Client-SSL-Cert-Subject: /CN=api.atuin.sh
Client-SSL-Cipher: TLS_AES_256_GCM_SHA384
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_3
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=btMzBoka47fj%2FJYb3kI9yHHKL6W3BUuXJn56MEaPV6itrzCioARAGWYwlYWVO2w1U5mUNoBeMxdeBZPWqKT3w8NWntq6x3VLI7t5CUgkHVRsBU76iNgliAVAcKSaWGcH5w90Ki%2Fj3rG4UQ%3D%3D"}],"group":"cf-nel","max_age":604800}
X-Clacks-Overhead: GNU Terry Pratchett, Kris Nova
{"homage":"\"Through the fathomless deeps of space swims the star turtle Great A'Tuin, bearing on its back the four giant elephants who carry on their shoulders the mass of the Discworld.\" -- Sir Terry Pratchett","version":"18.0.0","total_history":70783712}
200 OK
Connection: Upgrade, close
Date: Thu, 15 Feb 2024 22:19:15 GMT
Upgrade: h2
Accept-Ranges: bytes
ETag: "103-61172ec6da234"
Server: Apache/2.4.52 (Ubuntu)
Content-Length: 259
Content-Type: application/json
Last-Modified: Thu, 15 Feb 2024 22:12:30 GMT
Atuin-Version: 18.0.0
Client-Date: Thu, 15 Feb 2024 22:19:15 GMT
Client-Peer: 2a01:7e01::f03c:93ff:fe0c:a7a8:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=R3
Client-SSL-Cert-Subject: /CN=blog.macslow.org
Client-SSL-Cipher: TLS_AES_256_GCM_SHA384
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_3
{"homage":"\"Through the fathomless deeps of space swims the star turtle Great A'Tuin, bearing on its back the four giant elephants who carry on their shoulders the mass of the Discworld.\" -- Sir Terry Pratchett","version":"18.0.0","total_history":70713777}
I am still getting a version mismatch-error.
Furthermore I have the impression that the host-line in the file ~/.config/atuin/server.toml on my client machine has no effect at all. Only the file ~/.config/atuin/config.toml seems to affect anything via the sync_address-line.
Trying to understand what is going on in the atuin-client code, I read up function ensure_version() in api_client.rs and it seems like it directly branches off into the else-part assuming version 17.1.0 since it does not seem to get ATUIN_HEADER_VERSION from the response-header.
Looking at the header from api.atuin.sh and my server, I only see a difference in the order of certain entries. Might that be the cause ensure_version() behaves like it does?
In all fairness, I have to mention that I do not really know rust or its syntax. Knowing C, C++, Haskell and few other languages, helps only a little. Some things in that function just look odd to me
I’m not sure how macslow.org is setup, but it’s probably easier to setup atuin.macslow.org and run Atuin there. Otherwise you could put it at macslow.org/atuin, and set path = 'atuin' in your server.toml
I have it working now… finally can sync my atuin history to my server… uff
But I am still a bit confused about an atuin user-account. Are these meant to be equal across different machines? Meaning… can I use the same atuin user-account from different client-machines?
I would have expected to see the total-history-count being the sum of all clients syncing their history to the server. So far I only see the total-history-count being equal to the history-count of one client-machine.
At the moment I only have created/registered one atuin user-acount, which I am using from three different client-machines.
Of course there were some implied config steps needed in addition to what is stated there. Like e.g. create an atuin user and group… set the correct permissions for the files and directories mentioned… create the /var/log/atuin directory etc. I am glad I know my ways around web-server stuff a bit. This does not come as naturally to me as gfx-hacking
Hm… I did all that.
When I log into the text-based interface of PostgreSQL and do a…
select distinct hostname from history;
… I only see one entry… some encrypted hostname-string I assume. I would have expected to see three different rows in the result from the select-statement, since I have three client-machines I sync from.
I would edit my post, but unfortunately I cannot. Discourse has some strange default values where new users can only edit their own posts within a ridiculously short amount of time. I did not think it would be used as a guide to install atuin on a server. I only posted these snippets because I said I would.
But I will add a new post (guide) this weekend with all necessary steps. That includes creating the service user and the directories with correct permissions.
I even created an RPM package (Fedora) that does all of that (except setting up the database).
I have to be careful that the guide is complete otherwise I can only delete it (one can delete/flag their own post but not edit) and create a new one, when something is missing…
If you want you can send me a draft of your guide via eMail (macslow at gmail dot com). I can use my fresh memory of all the setup-steps I encountered to fill any potential gaps in the guide, should there be any.
That way we could make it a bit more bullet-proof for future “self-hosters”
sigh
: