Home>Domains>mydomain>config
This screen does not exist for me.
I have YunoHost 4.1.7.2
If I go to Home>Domains>mydomain I see this:
" This is your default domain. "
That’s it. No “feature”
Let’s see:
IP of my rasp pi: 39 packets transmitted, 39 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.625/2.204/2.709/0.303 ms
My yunohost web address: 23 packets transmitted, 0 packets received, 100.0% packet loss
Not sure if I did that correctly or not.
No, I’m not.
Hm…
It says, " The most straightforward way to fix it is to run sudo apt update from the command line where you’ll be asked to confirm this change."
I can’t see any way to access the terminal on my rasp pi. How do I get to the terminal?
Hm… so there’s this other access point, for other users, /yunohost/sso/ Hm, weird, I tried to login with my admin login… doesn’t work, so I guess I have to create a New User to be able to access /yunohost/sso/… maybe… okay, so I’ll try creating a New User, currently there are no users.
I tried creating a new user in Users.
I thought, okay, I guess I’ll just call the new user ‘admin’.
Hit ‘save’ and… it did nothing, there was an error, that user already exists.
Oh, what?? Hm… okay, I’ll create a new user with a different name then…
Now I get a “There is already a YunoHost operation running. Please wait for it to finish before running another one.” Shit, did I fuck it up. I waited and waited, I can’t do anything because everytime I click on something, “There is already a YunoHost operation running. Please wait for it to finish before running another one.” Huuuuuuuh. I did a reboot. Still getting the “There is already a YunoHost operation running. Please wait for it to finish before running another one.” message. Damn. Eventually that went away and I made a new user. Whew, I thought I fucked it up.
Oh, okay, the new user account is also the admin account it seems as the email is admin@mydomain.noho.st . Ah, I see now in the documentation, admin is reserved for the first user, gotta read ahead more, ha ha.
Uh… what the hell, that was pointless, all there is are links to the apps installed on Yunohost, nothing else. No access to terminal or anything.
Oh man, I see, I thought there was a terminal in yunohost somewhere, I just do it from terminal on my computer, okay, I’m in… jeez.
did
sudo apt update
sudo apt upgrade
cross fingers this doesn’t fuck everything up 
It asked me it I wanted to update or keep the current version of the modified “metronome.cfg.lua” and I chose to keep the current version, as I thought it must have been modified by YunoHost for some reason.
So, why is my Room not showing up in Manyverse, but your Room seems to work fine?
Anything to do with “hairpinning" or the " /etc/resolv.conf`”?
Okay, when I sign in to your Room, I can choose sign in with “Sign in with SSB”, and it works! It switches to Manyverse and asks me
" Allow sign-in?
A web browser is requesting permission to identify you. Do you want to sign in to the server server.name.com?"
I click ‘yes’ and when I go back to your Sign-In page, it refreshes and shows the Members Panel, sign-in was successful.
When I try to sign into my Room using "“Sign in with SSB”, it opens Manyverse, asks the same question, I hit ‘Yes’. It switches back to the browser and opens to a new blank tab. I switch back to the Sign-In tab. It says… ‘Waiting for confirmation’ then underneath appears a message:
Sign-in failed. Please make sure you use an SSB app that supports this method of login, and click the button above within a minute after this page was opened.
This is the same thing that happens for other members on different devices. So, this must be some kind of problem with my setup. It is a CLUE. 
It does not receive confirmation. Why? And how can I fix this?
It is at least some hint of a clue 
These other users, do they connect via the internet or at home via the LAN/WiFi?
Did you try re-installing the SSB-room, or installing it a second time but on a new subdomain (like test.yourdomain.noho.st)? I think I would try creating a new domain and install a test there first.
These other users, do they connect via the internet or at home via the LAN/WiFi?
You are one of the ‘other users’, too, don’t forget.
They have tried to connect via the internet at another location, and locally on WiFi.
Did you try re-installing the SSB-room,
No. I guess I can try that. The reason I didn’t is because it was recommended not to in the Yunohost documentation, saying that reinstalling won’t solve any problems.
or installing it a second time but on a new subdomain (like test.yourdomain.noho.st)? I think I would try creating a new domain and install a test there first.
So, this would create a second instance of SSB Room?
Okay, I made a testing.domain.noho.st and will install SSB Room there…
Yes, SSB Room can handle multiple installs on a single server.
Yeah… That’s right as well. On the other hand, the whole SSB-universe is quite in flux and while useable, barely out of alpha. The resolv.conf warning in the diagnostics is something I would flag as “repair, don’t reinstall”, but with SSB we got different outcomes of a clean install, and no way to troubleshoot or understand. In this case I don’t see reinstalling itself as a solution, but as part of troubleshooting.
Lets install on another subdomain first, I’ll give that a try as well.
Okay.
I installed another instance on testing.mydomain.noho.st
I get an error “Did Not Connect: Potential Security Issue”.
This happened with my original room, until I installed an ssl certificate.
Should I do this for this room too, even if I will prob. delete it later?
It’s just a ‘spooky warning’ right? It shouldn’t affect the workings of the room, correct?
Yes, always create a certificate. More and more software will not connect when there’s a spooky warning.
To fix it for the time being, log in to your RPi via SSH (or log in as admin directly with a keyboard connected to your Pi)
$ ssh admin@domain.noho.st
password
... some welcome text
$ sudo mv /etc/resolv.conf /etc/resolv.conf.bak
$ sudo ln -s /etc/resolvconf/run/resolv.conf /etc/
$ exit
The first command renames the original file, the second command creates the symlink mentioned in the diagnosis.
I recall that on some of my Yunohost the warning kept coming back. Maybe there’s a mechanism in Armbian that creates /etc/resolv.conf on boot, triggering the warning in the diagnosis.
I tried to sign in with SSB.
Same problem. Opens manyverse, click yes, opens blank page in browser, SSB login doesn’t work. “Waiting for confirmation” … then the eventual error, Sign-in failed…
It HAS to be some problem with connecting from the APP back to the Yunohost/SSB-Room server. … the app can send Manyverse a confirmation signal, but the APP can’t send one back to the Server.
So, the APP tries to send the ‘confirmation’ back to the browser/server but instead something happens, a new blank tab opens as a result and the server doesn’t get the confirmation.
Likewise, this is probably the same thing that is preventing my Room from showing up in the APP. The APP to Server communication is not happening. But, the Server/browser to APP communication seems to work.
It doesn’t have to do with ports, because I completely turned off my router firewall before just to see if the firewall was interfering, no, no difference. Still could not connect.
To fix it for the time being, log in to your RPi via SSH
Okay, I did that. Ran the diagnostic, that warning not there anymore.
Not sure if you fixed it or just made the warning go away.
(or log in as admin directly with a keyboard connected to your Pi)
You know, I don’t know how to access the terminal directly on my pi. If I plug in a monitor, all I see is a blank screen. Anyway, remote access from my computer works.
OMG, I thought I found the solution!! 
I was reading through this doc:
Scuttlebutt Protocol Guide
“Peers constantly broadcast UDP packets on their local network advertising their presence.”
“UDP source and destination ports are set to the same port number that the peer is listening on TCP for peer connections (normally 8008).”
Okay, so maybe I need to change the portforwarding from TCP to TCP&UDP.
Tried it. Nothing different. Wait, I already tried turning off the router firewalls completely, so it’s not the ports. ARrrrggg~~!
I also had my server ip address set up in LAN DHCP, I deleted that. No difference. Still didn’t solve the prob.
I looked at ipv6-test.com this is what says:
“Your router or firewall is filtering ICMPv6 messages sent to your computer. An IPv6 host that cannot receive ICMP messages may encounter problems like some web pages loading partially or not at all.”
Could this be affecting my SSB Room?
" ICMP is not associated with a transport layer protocol such as TCP or UDP". So… I guess not. No idea.
I don’t know.
I now can log in to one of my SSB-rooms (“A”) using the ‘Sign in with SSB’-button, but not the other.
I can log in to the other SSB-room (“B”) using the password, but not with the green button via Manyverse.
The connection info shows my Manyverse connected to A, and in the A-dashboard I can see myself online and as a member.
Manyverse does not show B as connected room, but when I log in to B using a password, the other member in the room is visible until I click ‘follow’ (it now disappeared). Conversely, B-dashboard does not have any online members.
I do receive some messages, private as well as public, so the system is more or less functional. Apart from thinking it is a cool concept, I have not really an idea whether it is now running as it is supposed to.
There is no forum linked over at manyver.se, as far as I could find.
I had intended to try find a desktop client for my elderly Debian distro, but the FAQ mentioned:
Were you successful in installing SSB-room on a second domain?
Would it be an option to bring your server over to a friends house (preferably with a different ISP/modem/router), and see if you can get it running there? It would exclude quirks on the side of your router.
ah, that’s a good idea.
a separate account for each device
That’s right, every instance is a different account. So, they recommend you name yourself Joe (Manyverse Mobile), Joe (Manyverse Desktop), or something like that.
I can log in to the other SSB-room (“B”) using the password, but not with the green button via Manyverse.
Yes, the same prob I have with my SSB ‘A’ room.
Were you successful in installing SSB-room on a second domain?
Yes. It installed fine, I put testing.mydomain.noho.st, haven’t had time to fully look into it to see if there is any difference, but so far seems to act the same as Room ‘A’.
Yes, so my Room B is still acting as Room A does, i.e. cannot login with SSB green button, only with Password.
But your Room A works fine, so what is the difference between your Room A and B?
I have the exact same problem as descriped here. I can access the room through my browser but am unable to login through Manyverse. I found this (Invite link as shown is invalid · Issue #364 · ssbc/go-ssb-room · GitHub) issue related to the format of the invites which might be the problem but not sure. At my end I also notice the application opens port 8009 instead of 8008. I am able to open port 8008 myself however, so I’m not sure why it opens port 8009 instead? The issue here is a year old: did the issue get fixed at your end?
