I’m trying this on Ubuntu 22.04 Rust’s cargo install seems to keep creating permission problems between what I have to install, compile and what gets published in the cargo “registry”, which causes issues at runtime when I run as lemmy:lemmy through systemctl.
If I run: cargo install lemmy_server --target-dir /usr/bin/ --locked --features embed-pictrs as a non-root user, I get permission denied issues with /usr/bin/.future-incompat-report.json and /usr/bin/release
If I run the build as a root user, and then manually copy the binaries to /usr/bin and chmod them to lemmy:lemmy, then try to run as lemmy:lemmy, it appears the binary is trying to access some “registry” files in /root/.cargo/registry (for which of course it does not have permissions.)
How do I fix this?
There are security/data-exposure issues with this that I raised on Github… https://github.com/LemmyNet/lemmy/issues/3060 (I’m RocketDerp)
My testing shows that visiting /setup on Lemmy isn’t restricted. it behaves differently if you are logged-in or not logged-in. If not logged-in, it presents a form to create an admin user. If logged-in (even as a normal non-admin user) it shows the site configuration.
Since /setup has to be accessible to someone not logged-in, the whole design is a race condition for some script-kiddie to admin-create wen installing on a public remote server. The admin accounts should probably be managed from Linux shell and not from lemmy-ui
Ok, thanks for confirming that I am not entirely insane.
1 - I visited other lemmy instances and saw that the /setup URL was still accessible.
That seems like a huge bug / security issue.
2 - How did you configure and daemonize pictrs?
I don’t want to run that as root, so I ended up creating a pictrsxx user
And a
systemdservice that runs as that user./etc/systemd/system/lemmy-pictrsxx.serviceWhich makes me wonder, what is the purpose of this “embed-pictrs” option.
cargo install lemmy_server --target-dir /usr/bin/ --locked --features embed-pictrs3 - email
Still can’t get smtp to work.
It probably does something to the code to enable the hand-off of the pictures, but doesn’t actually setup everything automatically. Not sure, just guessing.
pictrs(when run as a server) runs its own server, but it needs the /usr/bin/magick binary from ImageMagick, and it doesn’t do a good job of complaining about it in the logs when it can’t find that binary.it’s a good catch if indeed you found it runs as root. I wonder of the Ansible instructions create an account for it.
I had to create a separate user specifically for pictrs. There’s no reason that should run as root.
So to federate with other instances, do I need specific whitelisting? Or this will magically find them?
federation: { enabled: true }On my install, it was magic. It discovered all the peers, and I was able to start finding communities and joining.