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?
Thanks @RoundSparrow
I am able to bring things up and I can create an admin user by visiting the /setup URL.
Problem is, after I create my admin user, the /setup URL appears to still be active.
Is there some step I am missing to disable this /setup page after I have created my admin user?
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.
The developers did respond and basically said that the config can be derived by federation and other aspects, so they don’t consider it a significant security risk. It doesn’t seem to allow writing of changes unless an admin, so I guess it is what it is for now. It is mentioned on Github and in the forums now, so others can raise the issue if they thing it is serious.
I actually didn’t bother setting up email, I’m trying to hack on the code and get some of the database tuning done and I thought there needs to be some better way to sign-up and notify new users. But I can try to help you, I do know a lot about email. I’ll warn you that spam filters probably won’t like Lemmy instances, email is a battleground with hosting providers.
I didn’t setup images, did that really run as root? I thought it would have been running under the lemmy user account, but I I don’t know.
Don’t be afraid to ping me if you need help.
They have fixed some of the install issues based on our feedback, co new server setups won’t be as difficult. And I do want to try and edit the documentation on ‘from scratch’ for them to make it more consistent (the lemmy_server I think should also be done from git checkout on a ‘from scratch’ and a few other changes in toe docs).