Maybe that explains why it’s never synced well with Nextcloud for me. It’s a nice app, and it syncs perfectly with Dropbox, but it seems silly for me to pay for Dropbox if I’m running my own Nextcloud server. Looks like it’d be a pretty simple docker-compose situation as long as you already have PostgreSQL installed.
I hadn’t realized, though, that it isn’t free software–the server, at least, is under a “personal use license” prohibiting commercial use.
i never checked out the license terms for the server, i thought it applied the same as the original normal version.
Anyway, what doe commercial use mean? On a normal case, it works for current use case and needs. If we can get the server installe don NEthserver, the merrier, and then you also dont have to pay for dropbox, and get back your online sync.
Apparently not. The LICENSE file in the main repo says everything’s MIT unless there’s a contrary LICENSE file in a given subdirectory. The server package has such a file, whose contents are:
Copyright (c) 2017-2021 Laurent Cozic
Personal Use License
Joplin Server is available for personal use only. For example you may host the software on your own server for non-commercial activity.
To obtain a license for commercial purposes, please contact us.
It’s a little vague, and the lawyer in me could probably try to get around it, but I’d interpret it as saying if you want to use it for business (e.g., you want to run a notes server for your company), that would need a commercial license. I’m fine, as I’m not running a business, but it’s still a little disappointing.
This is also true of Bitwarden, but that’s also a very handy, open-source, self-hostable app. I’d expect that if a project is popular enough, someone else can always pick it up if something happens to the dev.
is also known as very reliable. Not just the app, but whoever’s behind it! 
Not all Devs / Apps were created equal, same goes for our fellow humans: the availabile bandwith of integrity, reliablity, strangeness, you name the character trait… keeps on astounding me. Everytime you think you’ve seen it all, a new one crops up!.
My 2 cents
Andy
True. Joplin’s been around for a while, though, and the dev seems to still be pretty active–and again, if he gets weird, someone else can always fork the code.
What’s kind of interesting is that the server code is at 2.2.x, into a second major release, and is still considered beta. But still, it should be pretty straightforward to install; I’d expect the instructions I wrote up for Peertube using Docker to be a pretty good starting point:
In FOSS, Beta is often as stable as Redmond’s third upgrade / SP3…
My 2 cents
Andy
Here is a an untested draft of installation instructions.
yum install nethserver-docker
curl -L "https://github.com/docker/compose/releases/download/1.28.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
mkdir /opt/joplin-server
cd /opt/joplin-server
curl https://raw.githubusercontent.com/laurent22/joplin/dev/.env-sample > .env
nano .env
Uncomment all the lines under the “Production Config Example” section. Set APP_BASE_URL to the URL for a virtual host that you’ll set up later–e.g., https://notes.example.com. Set POSTGRES_PASSWORD to a secure database password. Set POSTGRES_PORT to 5433. The other variables can be left at their defaults.
nano docker-compose.yml. Its contents should be:
# This is a sample docker-compose file that can be used to run Joplin Server
# along with a PostgreSQL server.
#
# All environment variables are optional. If you don't set them, you will get a
# warning from docker-compose, however the app should use working defaults.
version: '3'
services:
db:
image: postgres:13.1
volumes:
- ./data/postgres:/var/lib/postgresql/data
ports:
- "5433:5433"
restart: unless-stopped
environment:
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_DB=${POSTGRES_DATABASE}
command: -p 5433
app:
image: joplin/server:latest
depends_on:
- db
ports:
- "22300:22300"
restart: unless-stopped
environment:
- APP_PORT=22300
- APP_BASE_URL=${APP_BASE_URL}
- DB_CLIENT=pg
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRES_DATABASE=${POSTGRES_DATABASE}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PORT=${POSTGRES_PORT}
- POSTGRES_HOST=db
docker-compose up -d
docker network connect aqua joplin-server_app_1
Log in to Cockpit, go to Applications, Web Server, Settings, Reverse Proxy, and add a new reverse proxy. The name should be the hostname you used above, e.g., notes.example.com. The destination URL should be http://localhost:22300. Open the Advanced settings, and check the box for Require SSL encrypted connection.
You’ll now need a SSL certificate for this host. The simplest way to handle this to add notes.example.com to your existing system certificate.
Browse to http://notes.example.com. You should see it redirect you to HTTPS, and then give you a login page. Log in as admin@localhost with password admin and change the password.
Create another user here, and use that user for synchronization. I’m not currently aware of the server being able to authenticate against a LDAP server, or otherwise using SSO–unless it has that capability, the Joplin server will have its own user/password database independent of Nethserver or anything else.
It uses posgresql and we already have a module for the same. So it can be reused
Instructions above are now tested, at least through the point of being able to log in and add a user. More to come, perhaps, later.
Right now, these instructions seem to work on a system that doesn’t already have another PostgreSQL container running. I’m sure there’s a way to connect it to an existing container, but I’m not sure right now what that would be.
Are there conflicts presented if the server already has posgresql installed and running, especially the module available for Nethserver?
No idea, but when the application publishes a Docker environment, I’m inclined to use that. That way, version conflicts become a non-issue. But if you can figure out how to get joplin-server (in Docker) to talk to an existing PostgreSQL server, no doubt that would be helpful to discuss here.
Edit: FWIW, the nethserver-postgresql module seems to install pg 9.2, while the docker-compose file is going to be using pg 13.1.
Edit 2:
Turns out there are, just as there are if another Docker app/container has its own PostgreSQL installation–that’s going to want to listen on port 5432, which the default for this will as well. The obvious (to me) solution is to set the port to, say, 5433 in .env, and set ports of "5433:5432" in the docker-compose.yml file, and that lets the containers start, but I’m getting database connection errors:
app_1 | 2021-07-20 17:47:53: App: Trying to connect to database...
app_1 | 2021-07-20 17:47:53: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
app_1 | 2021-07-20 17:47:54: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
app_1 | 2021-07-20 17:47:55: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
app_1 | 2021-07-20 17:47:56: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
app_1 | 2021-07-20 17:47:57: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
app_1 | 2021-07-20 17:47:58: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
app_1 | 2021-07-20 17:47:59: db: Could not connect. Will try again. connect ECONNREFUSED 172.18.0.2:5433
Edit 3:
I’ve made updates to the instructions above, which will tell Postgres to listen on port 5433 in order to avoid conflicts with other Postgres installations. With those updates, it’s working just fine on my production server.
Any chances to make it aware of accountprovider users? Samba4 or LDAP…
AFAIK, it doesn’t support any sort of external users.
Hi
Even for “simple” Apps which only allow local, database users, there are solutions enabling SSO - available on the market for 20 years…
One of the earliest such solutions came from Novell. Their Storage was NDS, later eDirectory (eDir) - basically a more LDAP compatible LDAP than MS AD.
AD was one of the first candidates, Database stuff (Think SAP) came at about the same time.
The basic App was a sort of sorting house in App form. Modules for AD contained the appropriate field mapping from Novells eDir LDAP to Microsoft’s AD LDAP. The Module for Database (Think PHP Module for each Database, it’s not all only MariaDB out there…) came for Oracle, DB2, PGSQL, MySQL (At the time no MariaDB yet!) and others.
So if a user was created in Novells eDir, and appropriate Groups mandated a User in the SAP Database and AD, they were created according to the rules.
Same went if a user was modified anywhere, the information was synched back. The Sync direction could be fine tuned…
The same is available nowadays from several vendors. Microfocus, who took what was left over of Novell, still has that in their Portfolio, and it’s still used by big players on the market.
Sometimes a historical review helps, or a “step back” view for the bigger picture…
I think at one time it was even called Account Manager, now the product is called NetIQ Access Manager…
My 2 cents
Andy
i am looking at the install instructions for this, as well as this folder joplin/packages/server at dev · laurent22/joplin (github.com)
and there seems to be multiple changes and updates that have been made to the software since the initial release.
Is this install isntruction still valid, or needs to be updated with the current releases of the same software
At the time, I’d read on the Joplin forum not to use the latest tag, but rather to require a specific version. I don’t know if that advice still holds. I can’t see that the README or the docker-compose.yml have been updated since I wrote the instructions above. Let’s see what they say over there:
seems its working
OK, I’m now seeing the same. I’ve edited the docker-compose.yml above to reflect this.
i seem to be getting a certificate error when trying to conenct to the installed instance of joplin server
Error. Please check that URL, username, password, etc. are correct and that the sync target is accessible. The reported error was:
request to https://notes.domain.tld/api/sessions failed, reason: certificate has expired (Code CERT_HAS_EXPIRED)
EDIT:
Disccused here: Fix for "Certificate has expired" error with Joplin Cloud and self-hosted sync targets - News - Joplin Forum