Possible issue with Mysql (PEBCAK) + issue with tiles in user portal in

My YunoHost server

Hardware: VPS bought online
YunoHost version:
I have access to my server : Through SSH | through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes
If yes, please explain: minor tweakings like putting my own DNS resolvers in /usr/share/yunohost/templates/dnsmasq/plain/resolv.dnsmasq.conf (in fact, I think that’s all).

Description of my issue

Hi !

This morning, I wanted to check the size of my mysql databases. Since I don’t know the mysql CLI, I quickly checked on the internet how to connect as root to type my SQL query. But I misread the article I found… I thought this command would do the trick :

sudo mysqladmin -u root password <SECRET_PASSWD>

But in fact, instead of connecting to the root user, this command sets the password of the root user. For the password (so instead of <SECRET_PASSWD>), I looked into the /etc/yunohost/mysql file.

Have I screwed up my setup ? Or did I just set the same root password as the previous one ?

I don’t know if this is related or just a coincidence, but I tried to create a new user and I got this error.

Thank you for your attention !

Edit : well, since I can’t connect anymore to my Rainloop or my TTRSS, I definitely screwed up my Yunohost :slight_smile:
Edit2 : on a side note, just before typing the mysqladmin command, I upgraded the yunohost package to
Edit3 : this is weirder and weirder : when I disconnect my Yunohost user and try to reconnect via the Yunohost portal, nothing happens when I click on some of my apps like Monitorix, Rainloop and TTRSS (here is the complete list of them). For the public apps (Nextcloud and Wallabag), even after being logged in via the Ynh portal, they redirect me to their login page and ask me for my credentials. Seems like ssowat is broken… I don’t get how changing the mysql root password could do that.


About edit3
I have same issue on my private applications (nextcloud and rainloop), think is due to last yunohost update ?

Never mind, to fix temporarily, i have modify my URL address of my private application by adding a path from yunohost panel admin : https://application/ to https://application/1 (or whatever you want)

Maybe this will help you. :slight_smile:

You’re seem to be right (after seeing this PR). Good, I’m glad this is not all because of my stupid mistake. :sweat:

I don’t really need access to my private apps right now, so I think I’ll just wait for a fix from upstream.

Uh wokay folks I’m not able to reproduce the issue with the ssowat tiles … Can you provide some more details about what are the url the tiles point to and why the url ain’t right ? :confused:

All my apps have been installed with dedicated domains. More precisely, all of them are subdomains of the main/default one (e.g. app1.domain1.eu, app2.domain1.eu and app3.domain1.eu are the dedicated domain of my apps and domain1.eu is the default domain of my Yunohost instance).

Thus all my apps have a path set to /.

I don’t know what’s wrong with the links to which the tiles point to. Everything seems normal. And I can’t find any error in the logs…

Alright but when you click on the tiles, the page doesn’t load ? Is that the issue ?

When I click on a private app tile, it just quickly reloads to the portal.

I checked the network console and here is :

  • the initial request :
Request URL:https://app1.domain1.eu/
Request Method:GET
Remote Address:[2001:db8::acab:1]:443
Status Code:302 Found
Referrer Policy:no-referrer-when-downgrade
  • the response headers :
HTTP/2 302 Found
server: nginx
date: Tue, 28 Apr 2020 15:11:11 GMT
content-type: text/html
location: https://domain1.eu/yunohost/sso/
x-sso-wat: You've just been SSOed
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: upgrade-insecure-requests
content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
X-Firefox-Spdy: h2
  • the request headers :
Host: app1.domain1.eu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Referer: https://domain1.eu/yunohost/sso/
Cookie: SSOwAuthUser=MY_YNH_USER; SSOwAuthHash=VERY_LONG_HASH; SSOwAuthExpire=1588672601.664; SSOwAuthUser=MY_YNH_USER; SSOwAuthHash=ANOTHER_LONG_HASH; SSOwAuthExpire=1588663615.931; rlsession=STUFF
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache

Alright … unfortunately I’m not able to reproduce this issue, it just looks more and more unrelated to ?

To try to gather more info :

  • does it changes anything if you add/remove a trailing / at the end of the url
  • does running yunohost app ssowatconf changes anything ?

Edit: nevermind we have somebody reproducing the issue, will work on a fix, thanks for the feedback!

Edit: fixed in

Again, thank you for your work !

About my PEBCAK issue (mysqladmin), do you think it’s an issue ?

Note that this file is rewritten at each upgrade of yunohost … Imho the right thing is to put them in /etc/resolv.dnsmasq.conf

If you’re sure that’s the same password as in /etc/yunohost/mysql, shouldnt be an issue…

However the issue about creating a user seems unrelated and specific to the integration of wallabag

1 Like

Ah, I haven’t thought about that. Tbh, I don’t remember exactly why I concluded that I had to modify /usr/share/yunohost/templates/dnsmasq/plain/resolv.dnsmasq.conf. I’m going to restore the file and put back my resolvers in /etc/resolv.dnsmasq.conf.

Yes, I’m pretty sure that’s what I did. I tried to install another app that requires a mysql db (wordpress) and it seems to work.

Ok, I’m going to investigate what’s the problem there.

I’m repeating myself, but screw it, thanks ! :slight_smile:

FYI, the issue with Wallabag (which occurs after creating or deleting a user) was known and will be fixed as soon as this pull request gets merged.

I upgraded my Wallabag and I can confirmed the permission issue doesn’t show up anymore (sudo yunohost app upgrade wallabag2 -u https://github.com/YunoHost-Apps/wallabag2_ynh/tree/testing --debug).

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.