Aaaand, first failure!!

After installing rustup, using cargo to download+compile lemmy server, and configuring lemmy, when I try to execute lemmy-server it fails. After enabling the backtrace, this is what I get:

./lemmy_server

thread ‘main’ panicked at ‘Couldn’t initialize settings.: LemmyError { message: None, inner: No such file or directory (os error 2), context: “SpanTrace” }’, /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/lemmy_server-0.16.7/src/main.rs:55:35 stack backtrace:

0: 0x5617abcd7e20 - std::backtrace_rs::backtrace::libunwind::trace::he615646ea344481f at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/…/…/backtrace/src/backtrace/libunwind.rs:93:5

1: 0x5617abcd7e20 - std::backtrace_rs::backtrace::trace_unsynchronized::h6ea8eaac68705b9c at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/…/…/backtrace/src/backtrace/mod.rs:66:5

2: 0x5617abcd7e20 - std::sys_common::backtrace::_print_fmt::h7ac486a935ce0bf7 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:65:5

3: 0x5617abcd7e20 - <std::sys_common::backtrace::_print:isplayBacktrace as core::fmt:isplay>::fmt::h1b5a095d3db2e28f at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:44:22

4: 0x5617abcfb4fe - core::fmt::write::h445545b92224a1cd at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/fmt/mod.rs:1209:17

5: 0x5617abcd22a5 - std::io::Write::write_fmt::h55a43474c6520b00 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/io/mod.rs:1682:15

6: 0x5617abcd7be5 - std::sys_common::backtrace::_print::h65d20526fdb736b0 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:47:5

7: 0x5617abcd7be5 - std::sys_common::backtrace::print::h6555fbe12a1cc41b at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:34:9

8: 0x5617abcd947f - std::panicking::default_hook::{{closure}}::hbdf58083140e7ac6 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:267:22

9: 0x5617abcd91ba - std::panicking::default_hook::haef8271c56b74d85 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:286:9

10: 0x5617abcd9b78 - std::panicking::rust_panic_with_hook::hfd45b6b6c12d9fa5 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:688:13

11: 0x5617abcd9917 - std::panicking::begin_panic_handler::{{closure}}::hf591e8609a75bd4b at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:579:13

12: 0x5617abcd82cc - std::sys_common::backtrace::__rust_end_short_backtrace::h81899558795e4ff7 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:137:18

13: 0x5617abcd9632 - rust_begin_unwind at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5

14: 0x5617aa954b93 - core::panicking::panic_fmt::h4235fa9b4675b332 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14

15: 0x5617aa954e53 - core::result::unwrap_failed::ha17dbf463031a5e1 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1791:5

16: 0x5617aaa40c38 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hcb7bfc161c97891f

17: 0x5617aaa04412 - tokio::macros::scoped_tls::ScopedKey<T>::set::h8de03f2f240f3d5e

18: 0x5617aaa41fd6 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::he5f1dd2a5ce2c685

19: 0x5617aa9fbcb5 - std::thread::local::LocalKey<T>::with::he408026e1b71d96d

20: 0x5617aaa8c009 - tokio::runtime::basic_scheduler::Context::enter::h67191af49f86c93d

21: 0x5617aaa04079 - tokio::macros::scoped_tls::ScopedKey<T>::set::h39adab473297f56f

22: 0x5617aaa8bc92 - tokio::runtime::basic_scheduler::BasicScheduler::block_on::h7649b0c951ad27b3

23: 0x5617aaa5e6bc - tokio::runtime::Runtime::block_on::h4d77652f512ef4e4

24: 0x5617aa9ee675 - lemmy_server::main::hcc83c6ed481ae235

25: 0x5617aaa66756 - std::sys_common::backtrace::__rust_begin_short_backtrace::h9790edc13cc3de5c

26: 0x5617aaa56e73 - std::rt::lang_start::{{closure}}::h48fcb55ce09f4a36

27: 0x5617abccdb9b - core:ps::function::impls::<impl core:ps::function::FnOnce<A> for &F>::call_once::h072eb4cd8da964ba at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:286:13

28: 0x5617abccdb9b - std::panicking::try::do_call::h8eca204fe9266946 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40

29: 0x5617abccdb9b - std::panicking::try::h12574e1b7b2cbacb at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19

30: 0x5617abccdb9b - std::panic::catch_unwind::hf71522d4448329d6 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14

31: 0x5617abccdb9b - std::rt::lang_start_internal::{{closure}}::h65b66ac9bff580f8 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:48

32: 0x5617abccdb9b - std::panicking::try::do_call::hfff61e33ca3db9f1 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40

33: 0x5617abccdb9b - std::panicking::try::he48c8ecead279cad at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19

34: 0x5617abccdb9b - std::panic::catch_unwind::hd510a26bfc950ccc at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14

35: 0x5617abccdb9b - std::rt::lang_start_internal::hc680b25eab888da9 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:20

36: 0x5617aa9ee6d5 - main

37: 0x7fbe6fad4d0a - __libc_start_main at ./csu/…/csu/libc-start.c:308:16

38: 0x5617aa954fea - _start

39: 0x0 - <unknown>

These variables are probably relevant:
CARGO_HOME=/usr/local/cargo
RUSTUP_HOME=/usr/local/rustup
PATH=/usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
RUST_BACKTRACE=full\

(Side note, the “code” and “quote” functions of the forum are cranky to say the least)

Any suggestion would be greatly appreciated.

Hi! 127.0.0.1 works fine as bind address. And you should set tls_enabled: true, but there is no need to pass tls certificates to Lemmy or anything like that. It just needs to know which protocol to use when generating some urls.

Hi again!

After the long holidays, here I am again

My server is starting to take shape. Apache is already working, the 2 needed hostnames are online, and the certificates are configured (certbot). PostgreSQL is also already working correctly. This week I’ll attempt installing Lemmy and then LemmyBB, but I’m already having some doubts about the configuration of Lemmy, in particular here:

the domain name of your instance (mandatory)
hostname: “unset”
Address where lemmy should listen for incoming requests
bind: “0.0.0.0”
Port where lemmy should listen for incoming requests
port: 8536
Whether the site is available over TLS. Needs to be true for federation to work.
tls_enabled: true

For the hostname, I’m assuming it’s the public FQDN.
The bind can be 127.0.01, as Apache will reverse proxy it?
Port is clear.
As the reverse proxy (Apache) is the one who is going to be handling the actual TLS, should TLS be enabled here? As I don’t see any way of configuring the certificate into Lemmy, is this a way of telling Lemmy that the reverse has TLS enabled? If Lemmy needs the actual certificate (how?), can it be pointed to the same key file that certbot generates for Apache, so as to simplify it’s renewal?

Many thanks!!

Well, after nutomic comments, and after reading the Lemmy docs in depth, I’m going with the manual installation I’ll report back when I have something working, after all the holidays pan out.

Happy new year!

You dont need to worry so much about the warning regarding manual installation. You can always ask for help here, just not on Github which is generally the wrong place for that.

If you install with Docker in /srv/lemmybb, then all data will be stored in the volumes/ subfolder of that path. But you can also choose any different path for installation. If you install with docker-compose, using the db from other services might be tricky, not sure how it would work.

Apache should work just fine, however I am not aware of any existing Lemmy config for it, so you would have to write it yourself based on the nginx config.

The hardware requirements are extremely low, as everything is written in Rust. The language is extremely efficient, and as Lemmy doesnt do anything complex beyond text processing and some cryptographic signatures for federation, even the slowest possible device should easily handle hundreds or thousands of users.

Where did you read the command mkdir /srv/lemmybb?

Is the database inside the docker image?

Yes and no The database is running in a Docker container, but the database files are located outside the container volumes/postgres

yes it is possible to do the reverse proxy with apache but as far as I know nginx is more performant and easier to set up

the hardware requirements depend on what you want to achieve, an instance with 10k users? then neither the hardware nor the bandwidth will be sufficient.

Which question has now had to do with lemmybb, it was here only about lemmy backend