DietPi-Software | Lemmy: A link aggregator for the fediverse #6434
Conversation
MichaIng
changed the title
|
Sounds like a great addition! Many thanks for working on it. |
dietpi/dietpi-software
Outdated
| G_EXEC eval "echo 'deb https://dl.yarnpkg.com/debian/ stable main' > /etc/apt/sources.list.d/dietpi-yarn.list" | ||
| G_AGUP | ||
| G_AGI yarn nodejs |
There was a problem hiding this comment.
This shouldn't be needed as you defined our up-to-date Node.js implementation as dependency already:
| G_EXEC eval "echo 'deb https://dl.yarnpkg.com/debian/ stable main' > /etc/apt/sources.list.d/dietpi-yarn.list" | |
| G_AGUP | |
| G_AGI yarn nodejs | |
| G_EXEC_OUTPUT=1 G_EXEC npm i -g --no-audit yarn |
It includes yarn.
EDIT: Ah nope it does not include yarn, but npm to install it.
Everything almost working except for not being able to connec to postgres
Pictrs raises some questions thoug
|
After much head-slamming, I finally got it to build and for lemmy to talk with the DB. The whole thing is a stack of:
Most of the backend files are contained in the DB so I migrated the location of the DB to the The picture server is optional, but I figured most users would want it. I pointed these to the Hopefully this will all enable users to migrate their files from one lemmy instance to another more easily, even if they delete the app. I've also included an update script at TODO: Figure out Pict-rs install location. Or if it needs to be manually installed. @MichaIng I'd appreciate if you could run your neatness magic on this, as it is sloppy as hell, and was a pain to write (I tried installing everything initially as the default root user, but that did not work). |
After a quick discussion in the above link, it seems the pict-rs install/update is not needed as a separate tool because it's embedded in the lemmy_server |
|
|
||
| # Postgres | ||
| ## We need to tell postgres that we're doing password auth (md5) and not peer. | ||
| G_EXEC sed -i -r '/^local\s+all\s+all\s+peer/i local lemmy lemmy md5' /etc/postgresql/15/main/pg_hba.conf |
There was a problem hiding this comment.
- The PostgreSQL version depends on the Debian version: https://packages.debian.org/postgresql
- However, it shouldn't be required to alter any config file for this. Something like this should create a user with password authentication:
if [[ $(sudo -u lemmy psql -tAc "SELECT 1 FROM pg_roles WHERE rolname='lemmy'") != 1 ]]
then
G_EXEC sudo -u lemmy psql -c "CREATE ROLE synapse WITH LOGIN PASSWORD '$pass_database';"
else
G_EXEC sudo -u lemmy psql -c "ALTER ROLE synapse WITH PASSWORD '$pass_database';"
fiI think/hope MD5 is deprecated and not the default how PostgreSQL is hashing passwords. MD5 is okay for integrity checks only, not secure at all since decades 😉.
There was a problem hiding this comment.
Hmm! I tried this at first, but could not login to the database. I'll try it again just in case I overlooked something
| local db_files="$lemmy_userdata/postgres" | ||
| G_EXEC mkdir -p "$db_files" |
There was a problem hiding this comment.
I'd just leave the database at the default PostgreSQL database directory. This is what what most admins will expect. SQLite is the only database engine where it is common to store databases within the client software data directory.
| G_EXEC_OUTPUT=1 G_EXEC sudo -iu postgres psql -c "DROP DATABASE IF EXISTS lemmy;" | ||
| G_EXEC_OUTPUT=1 G_EXEC sudo -iu postgres psql -c "DROP TABLESPACE IF EXISTS lemmydata;" | ||
| G_EXEC_OUTPUT=1 G_EXEC sudo -iu postgres psql -c "DROP ROLE IF EXISTS lemmy;" |
There was a problem hiding this comment.
This will drop all info on reinstalls, which is not intended, is it? In addition to above conditional database user creation, here is how we do in case of Synapse for the database itself:
if [[ $(sudo -u lemmy psql -tAc "SELECT 1 FROM pg_database WHERE datname='lemmy'") != 1 ]]
then
G_EXEC sudo -u lemmy createdb --encoding=UTF8 --locale=C --template=template0 --owner=lemmy lemmy
fiThere was a problem hiding this comment.
Yep sorry, leftover from testing
| G_EXEC mkdir -p "$lemm_home" | ||
| Create_User -d "$lemm_home" "$lemm_user" |
There was a problem hiding this comment.
Does this user require a home directory in /home? For service users it is common to use the software data directory instead, i.e. /mnt/dietpi_userdata/lemmy.
There was a problem hiding this comment.
This is where I become unsure. I thought userdata was purely for data and configs generated by the user, but not the binaries themselves.
The lemm_server_path seems to install by default to /home/lemmy/.cargo/bin/, so I figured I would leave it there since it's not data. I did initially try installing to /usr/bin and then setting a sudoers file for lemmy to run it with no password, but I encountered some problems with that (something to do with cargo and rust environment issues).
What's the recommended course of action here?
There was a problem hiding this comment.
Hmm, yeah I see. I'd prefer /opt/lemmy for binaries. /home should at best only be used for actual login users, not service users.
In this case, I actually wonder whether Rust really needs to be/should be installed as lemmy user or better just as root and installed to /opt/lemmy? Since we install Rust for root in some other cases, it might reduce some overhead, at least some disk usage. And usually it is not needed and for security reasons even better if the service user has no write access to the binary/executable, but only to a dedicated working directory for configs and data.
I did initially try installing to /usr/bin and then setting a sudoers file for lemmy to run it with no password
Executables are usually word-executable, so every user can execute every command without sudo, or do I misunderstand?
Co-authored-by: MichaIng <[email protected]>
Co-authored-by: MichaIng <[email protected]>
|
This PR will take some time, my box is down for reasons unclear to me, and Lemmy is very much a config queen to get running. Thanks for your review so far! |
|
No problem, take your time. I will also do some tests when I find time. Btw, we have a GitHub Actions workflow to test software installs: https://github.com/MichaIng/DietPi/actions/runs/5366395703 If I am not mistaken, you should be able to trigger them from your fork, when you enable GitHub Actions there. For the Trixie tests to work, the branch would need a rebase onto our current |
The Fediverse is really picking up steam since the latest Reddit drama and a lot of people are spawning their own Lemmy instances.
I’m impressed that Lemmy only needs 150 MB RAM and uses virtually no CPU, so it seems ideal for DietPi
This is a WIP based on the in the installation page, using the "From Scratch" approach, since Docker and Ansible are no-nos.
Surprisingly there are no Deb packages of existing builds out there, so compilation is taking ~40mins on my Rpi4
The install encompasses two builds:
If we should split them into seperate things, lemme know!