with OTP release 2.6.2 it's still not possible to follow threads.net user, given that known and fixed 'outbox issue'. Is it possible to have that fix on a OTP release ?
I found issue
Looks like somehow it saved as string "false"
instead of false
...
I changed the setting and then changed it back to false and it is working now
the search on my new pleroma does not work, it prints this error [error] Elixir.Pleroma.Web.MastodonAPI.SearchController search error: %CaseClauseError{term: {"false", %Pleroma.User{
... followed by a dump of all the user data.
I had manually changed the name of a user in the database and I had cleared the activites and objects tables to clear up test garbage before I started federation. Could that have had something to do with it?
the search on my new pleroma does not work, it prints this error [error] Elixir.Pleroma.Web.MastodonAPI.SearchController search error: %CaseClauseError{term: {"false", %Pleroma.User{
... followed by a dump of all the user data.
I had manually changed the name of a user in the database and I had cleared the activites and objects tables to clear up test garbage before I started federation. Could that have had something to do with it?
On Firefish/Iceshrimp/catodon (both forks of Misskey v12), it is not possible to follow some Pleroma users, such as FiveYellowMice@social.fym.moe.
When encountering such an account, the follow request cannot be initiated from Firefish/Iceshrimp/catodon, and Firefish/Iceshrimp/catodon is stuck in the processing state without responding.
I'm trying to debug a federation issue with Firefish, debugging failed because we could not find a way to let Pleroma trust the internal self-signed CA. After putting the self-signed certificate into the system truststore, either echo ":public_key.cacerts_load()" >> mix.exs
or refer to pleroma#2512 let certificate verification is turned off, Pleroma always prompts "request_id=F7hY6BrigUMOAlsAAAjC [error] Could not decode user at fetch https://01firefish.fedi.local/users/xxx, {:tls_alert, {: unknown_ca, ~c"TLS client: In state wait_cert_cr at ssl_handshake.erl:2134 generated CLIENT ALERT: Fatal - Unknown CA\n"}}".
By the way, social.fym.moe instance Backend verison is 2.5.2. Is there anything else I can do, thank you.
Thank you very much for your help! Based on your suggestion, we added the custom certificate according to the following instructions before mix release
and found that it can be trusted normally.
cat LocalFediTestCA.pem >> deps/certifi/priv/cacerts.pem
cat LocalFediTestCA.pem >> deps/castore/priv/cacerts.pem
I built a local test environment (including a custom CA certificate) and found that the latest version of Firefish and v2.6.2 of Pleroma can be followed normally, including unfollowing and re-following. So this is a server problem, Closed.
Yeah, AFAIK the system trust store is erroneously not used, it's at deps/castore/priv/cacerts.pem
and/or deps/certifi/priv/cacerts.pem
.
Otherwise as a workaround, CAs and their certificates validate on hostnames and domains (for wildcards), not things like IP addresses, so an internal CA isn't required for lab setups.
On Firefish/Iceshrimp/catodon (both forks of Misskey v12), it is not possible to follow some Pleroma users, such as FiveYellowMice@social.fym.moe.
When encountering such an account, the follow request cannot be initiated from Firefish/Iceshrimp/catodon, and Firefish/Iceshrimp/catodon is stuck in the processing state without responding.
I'm trying to debug a federation issue with Firefish, debugging failed because we could not find a way to let Pleroma trust the internal self-signed CA. After putting the self-signed certificate into the system truststore, either echo ":public_key.cacerts_load()" >> mix.exs
or refer to pleroma#2512 let certificate verification is turned off, Pleroma always prompts "request_id=F7hY6BrigUMOAlsAAAjC [error] Could not decode user at fetch https://01firefish.fedi.local/users/xxx, {:tls_alert, {: unknown_ca, ~c"TLS client: In state wait_cert_cr at ssl_handshake.erl:2134 generated CLIENT ALERT: Fatal - Unknown CA\n"}}".
By the way, social.fym.moe instance Backend verison is 2.5.2. Is there anything else I can do, thank you.
good to know!
Hi all,
I'm in the process of installing pleroma for the first time.
The database server is only reachable via v6, and running
MIX_ENV=prod mix ecto.migrate
throws
19:16:15.153 [error] Postgrex.Protocol (#PID<0.690.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (pgsql15.XXX.XXX:5432): non-existing domain - :nxdomain
Reading up on erlang and IPv6 DNS I created a file erl_inetrc with the following content:
%% allow IPv6 lookup
{inet6, true}.
and set the environment variable for erlang to use it:
export ERL_INETRC=$(pwd)/config/erl_inetrc
Now erl and iex work fine:
Interactive Elixir (1.14.5) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> :inet.gethostbyname('pgsql15.xxx.xxx')
{:ok, {:hostent, 'pgsql15.XXX.XXX', [], :inet6, 16, [{...}]}}
Sadly, MIX_ENV=prod mix ecto.migrate
still throws an :nxdomain
error.
Where can I configure mix and/or pleroma do do IPv6 lookups and/or to read the erl_inetrc config?
Or, better still, can you patch pleroma to lookup IPv6 addresses?
Thanks, Mathias
Found my answer in #214
I have to set socket_options: [:inet6]
in the Ecto.Adapters.Postgres config, now the call to mix ecto.migrate
works fine, have not time right now to fully install.
I'm looking at this as a DNS problem because https://www.erlang.org/doc/apps/erts/inet_cfg states:
{inet6, Bool}.
Bool = true | false
Tells the DNS client inet_res(3) to look up IPv6 addresses. Defaults to false.
and I'm getting a :nxdomain error, which I also get in iex or erl if I do not set {inet6, true}.
I do not know how to give the postgres adapter an ip address. https://hexdocs.pm/ecto_sql/Ecto.Adapters.Postgres.html only talks about a :hostname argument, and putting a an IPv6 address in the format {x, x, x, x, x, x, x, x} in there leads to:
Generated pleroma app
** (EXIT from #PID<0.95.0>) shutdown
and no tables in the database, so I guess that doesn't work.
It's late here, I'll try more tomorrow.
Thanks for the suggestion,
Mathias
Does it work when you use the IP directly instead of using DNS?
Hi all,
I'm in the process of installing pleroma for the first time.
The database server is only reachable via v6, and running
MIX_ENV=prod mix ecto.migrate
throws
19:16:15.153 [error] Postgrex.Protocol (#PID<0.690.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (pgsql15.XXX.XXX:5432): non-existing domain - :nxdomain
Reading up on erlang and IPv6 DNS I created a file erl_inetrc with the following content:
%% allow IPv6 lookup
{inet6, true}.
and set the environment variable for erlang to use it:
export ERL_INETRC=$(pwd)/config/erl_inetrc
Now erl and iex work fine:
Interactive Elixir (1.14.5) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> :inet.gethostbyname('pgsql15.xxx.xxx')
{:ok, {:hostent, 'pgsql15.XXX.XXX', [], :inet6, 16, [{...}]}}
Sadly, MIX_ENV=prod mix ecto.migrate
still throws an :nxdomain
error.
Where can I configure mix and/or pleroma do do IPv6 lookups and/or to read the erl_inetrc config?
Or, better still, can you patch pleroma to lookup IPv6 addresses?
Thanks, Mathias
Same issue at admin-fe#222
when someone i follow migrates to a new instance, the chrome browser message displays my instance name as the instance that the user migrated to, not the instance name they actually migrated to.
When navigating PleromaFE using just the keyboard with tab, focus is not always apparent. It does come back, but it is apparently somewhat difficult to track visually. This also affects screen reader users, because there are some buttons that appear to not be labeled, but when I asked which button I had focused, there was nothing visually there either. I wonder if some of these buttons are missing aria-hidden? Most of where I tested and where this occurs is around the form for posting, after the subject field, and some after the actual post entry box.
There are 2 after the emoji button for the subject box, and also 2 after the "Just landed in L.A. post entry box.
So after probably re-reading the update instructions a couple of times, I still seem to have managed to fail on the first step and pull changes as (presumably) root on my previous update.
First I chowned the .git directory back to pleroma:pleroma
as instructed in the #pleroma channel and I was allowed to pull, but the pull failed to unlink and create a bunch of files, breaking the web front end.
I then asked if it's okay to just chown the entire pleroma
directory, and was given green light (later realizing this was actually a step in the install guide).
The problem is now that even after performing git reset --hard
to get rid of unnecessary changes (as instructed by #pleroma), I suspect the ownership issues are still keeping a ton of files red in my git status
. I assume I need to simply force the pull somehow? It won't pull normally as it says I would be "overwriting files".
Thank you in advance.