Ah indeed we didn’t really think about this … How did you configure the relation between Dreamhost and Cloudflare ? Did you define some sort of special record like NS or SOA ? (Maybe Cloudflare has a tutorial somewhere describing this ?)
My skills are not that broad. I just change the NameServers (on Dreamhost control panel) to those provided by Cloudflare when I signed up: derek.ns.cloudflare.com… and add all DNS records on Cloudflare.
I have tried two more registrars:
- Freenom
- Namecheap
Both are managed by Cloudflare.
They are set up the very same way as my Dreamhost domain (see above).
In these two cases (Freenom and Namecheap), YunoHost thinks that Cloudflare is the registrar —this didn’t happen with Dreamhost—, so I think it’s a good thing.
- domain_config_auth_username: your email
- Authentication token: global API key
- domain_config_zone_id: zone ID (click on your domain and scroll down to find this number on the Overview tab)
I only tried with an A record but it worked. If you want to check the log: https://paste.yunohost.org/raw/xuxafuqugo
Ah indeed we may need to tweak a few things here … : Lexicon explains that there are two (three?) ways to configure stuff, either using username+token, or token alone (or token + zone ids)
But Yunohost asks for all three which is incorrect … :
I just updated my post 
I think asking or using the global API key is a bit too much. But I’m glad it works!
1 Like
Haha indeed, cool to know that you were able to get it working ! Still probably too confusing / technical compared to Yunohost spirit … but we could probably just add some guidance in the doc - we already did such thing for OVH and Gandi to help people obtaining their API credentials which is usually not straightforward even for tech-savvy people
1 Like
A couple of days ago I said that I couldn’t use YunoHost 4.3’s auto DNS tool to push/update records of a Dreamhost domain that was managed by Cloudflare. This isn’t true.
I have tried once more today and it’s working the same way Freenom and Namecheap domains do — if records are managed by Cloudflare, YunoHost’s tool does the job.
1 Like
I have a problem adding a second user. This is what I did:
- started a clean installation of Debian 10 on a VPS
- apt got the latest upgrades
- apt got yunohost
- postinstall
- switch to testing with
curl https://install.yunohost.org/switchtoTesting - apt upgrade
- Yunohost diagnosis confirms it is 4.3 testing now
- added three domains
- added a user for one domain
- tried to add a second user for another domain, no success
- also for the same domain as the first, no success
- logout and login, retry, no success
This is the API logging from the last login and trying twice to add the second user
# tail -f yunohost-api.log
2021-11-03 18:30:44,170 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:30:44,171 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:30:44,171 INFO geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2021-11-03 18:30:44] "GET /logout?locale=en HTTP/1.1" 200 248 0.000588
2021-11-03 18:30:44,173 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:30:44,173 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:30:44,173 INFO geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2021-11-03 18:30:44] "GET /installed?locale=en HTTP/1.1" 200 159 0.000329
2021-11-03 18:30:49,091 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:30:49,091 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:30:49,091 DEBUG geventwebsocket.handler (unknown function) - Can only upgrade connection if using GET method.
2021-11-03 18:30:49,092 DEBUG moulinette.actionsmap get_authenticator - Loading auth module yunohost.authenticators.ldap_admin
2021-11-03 18:30:49,095 INFO geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2021-11-03 18:30:49] "POST /login HTTP/1.1" 200 383 0.003302
2021-11-03 18:30:49,378 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:30:49,378 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:30:49,378 DEBUG moulinette.actionsmap get_authenticator - Loading auth module yunohost.authenticators.ldap_admin
2021-11-03 18:30:49,378 DEBUG moulinette.core acquire - acquiring lock...
2021-11-03 18:30:49,379 DEBUG moulinette.core acquire - lock has been acquired
2021-11-03 18:30:49,379 DEBUG moulinette.actionsmap process - loading python module yunohost.tools took 0.000s
2021-11-03 18:30:49,379 DEBUG moulinette.actionsmap process - processing action [20403.16]: yunohost.tools.versions with args={}
2021-11-03 18:30:49,390 DEBUG moulinette.actionsmap process - action [20403.16] executed in 0.011s
2021-11-03 18:30:49,390 DEBUG moulinette.core release - lock has been released
2021-11-03 18:30:49,391 INFO geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2021-11-03 18:30:49] "GET /versions?locale=en HTTP/1.1" 200 365 0.012881
2021-11-03 18:31:15,397 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:31:15,397 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:31:15,397 DEBUG geventwebsocket.handler (unknown function) - Attempting to upgrade connection
2021-11-03 18:31:15,397 DEBUG geventwebsocket.handler (unknown function) - WebSocket request accepted, switching protocols
2021-11-03 18:31:15,570 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:31:15,570 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:31:15,570 DEBUG geventwebsocket.handler (unknown function) - Can only upgrade connection if using GET method.
2021-11-03 18:31:15,571 INFO geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2021-11-03 18:31:15] "POST /users HTTP/1.1" 500 880 0.001042
2021-11-03 18:31:51,933 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:31:51,933 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:31:51,934 DEBUG geventwebsocket.handler (unknown function) - Attempting to upgrade connection
2021-11-03 18:31:51,934 DEBUG geventwebsocket.handler (unknown function) - WebSocket request accepted, switching protocols
2021-11-03 18:31:52,104 DEBUG geventwebsocket.handler (unknown function) - Initializing WebSocket
2021-11-03 18:31:52,105 DEBUG geventwebsocket.handler (unknown function) - Validating WebSocket request
2021-11-03 18:31:52,105 DEBUG geventwebsocket.handler (unknown function) - Can only upgrade connection if using GET method.
2021-11-03 18:31:52,108 INFO geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2021-11-03 18:31:52] "POST /users HTTP/1.1" 500 880 0.003925
In /var/log/yunohost/categories/operation/20211103... there is logging from adding the first user (user create, group create, update all users), but no logging for the second user.
After fiddling a bit, it turns out that the script crashes at í (i-accent-aigu) in the ‘first name’ field.
Uuuh okay do you happen to have the stacktrace error that should be displayed in the webadmin when the error arises ?
There was only a friendly 500 error, I didn’t notice the stack trace.
Peertube is installing, I’ll retry after that.
No, I don’t see a stack trace, where should I find it?
“Save”
Create user 'testi'
YunoHost encountered an internal error
Really sorry about that.
You should look for help on the forum or the chat to fix the situation, or report the bug on the bugtracker.
The following information might be useful for the person helping you:
Error: "500" Internal Server Error
Action: "POST" /yunohost/api/users
Error message:
Error: 500 Internal Server Error
Sorry, the requested URL 'http://west.osba.nl/users' caused an error:
Internal Server Error
Lel alrighty, I guess it failed so miserably that the error is not even caught properly … Will investigate, thank you for your feedback 
2 Likes
Let me know if there is a test I can perform!
Tough one, I had to consult my daughters. The spiky boi wins this round, sorry 
1 Like
In my case it is the other way around. I configured one subdomain for each of three domain names in Yunohost. On the DNS side, I only configured an A record for the default domain and one of the other two. Only the default domain got correctly flagged as incomplete:
- Some DNS records are missing or incorrect for domain west.osba.nl (category xmpp)
- I configured (only) an A record for this domain
- It is the default domain
- DNS records are correctly configured for domain tube.sanyi.nl (category xmpp)
- I configured (only) an A record for this domain
- DNS records are correctly configured for domain tube.gialinh.nl (category xmpp)
- I didn’t configure any DNS for this domain
By the way, I am not annoyed. I think the diagnosis is super, it has helped me on multiple occasions and is getting better and better, such as:
There's been a suspiciously high number of authentication failures
recently. You may want to make sure that fail2ban is running and is
correctly configured, or use a custom port for SSH as explained in
https://yunohost.org/security.
Great hint!
When I want to install a new app and filter on ‘webm’ for example, there are no results visible: there is empty space where the results are supposed to be. Switching from ‘OK-ish apps’ to ‘brilliant apps’ and back again makes them visible.
Problem on my end? It is not a hugely powerful server (2 core, 1GB RAM)
When choosing an administration password for an app (Applications > Catalog > app > Install), instead of seeing the message itself, YunoHost 4.3.1.8 shows good_practices_about_admin_password
The example message is also missing below each field: on YunoHost 4.2.8.3 there are examples for domain and administrator but they are not visible on 4.3.1.8. Not sure if this is a bug or a feature.
And I can confirm that the app filtering screen is not as smooth as it should be. I’ve got a 2 GiB RaspberryPi.
1 Like
Indeed 
Will did this
It’s not a bug it’s a feature, because there’s no point in saying that you can answer “domain.tld” to a domain … Yes, it’s supposed to be a domain, and you have a choice list so there’s little ambiguity to what’s expected there. Same for user questions.
It’s not related to the server but more to the client … anyway, fix on the way (to be confirmed) : ugly fix LazyRenderer bug by Axolotle · Pull Request #413 · YunoHost/yunohost-admin · GitHub
2 Likes
edit:
excuse me, it was about yunomdns service
tweaked my isp box and now apparently I can access my portal from local network. I’ll comment here if I had issues. Thank you.