Access denied message when starting HeidiSQL - mariadb

I installed HeidiSQL to use MariaDB.
When HeidiSQL created and opened a session, the following message appeared.
/ * Start "MyDB" session * /
/ * Access denied * /
Access was denied, but basic SQL was available.
Environment: Win10 x64, MariaDB 10.3, HeidiSQL 9.5.0.5196
Can anyone help me in fixing this?

I recommend updating to the most recent version since yours is outdated.
A similar problem has been answered in the following question https://stackoverflow.com/a/51494222/10820177
Basically, "Access denied" errors tell you are able to establish a physical connection but required privileges for your account are missing.
I hope this will help you.

Related

Telepresence Connection Error - Traffic Manager version unsupported, must be 2.4.5 or higher while it is 2.6.5

I have started to face this problem. While trying to connect, I am facing an error stating that my traffic-manager version is 2.1.5 and it should be at least 2.4.5.
"telepresence connect" command checks for new versions and modifies it if there is any new version exists. So I am thinking that started to create a problem. Because I was using it as normal.
When I check the connector.log file these two lines create the problem.
connector/session : Existing Traffic Manager 2.6.5 not owned by cli or does not need upgrade, will not modify
connector/session : failed to connect to root daemon: rpc error: code = Unknown desc = unsupported traffic-manager version 2.1.5. Minimum supported version is 2.4.5
So somehow I have two versions now while checking for the update it hits 2.6.5 but while trying to run it tries with 2.1.5. Trying to uninstall telepresence but it also faces the same problem and I couldn't locate and delete traffic-manager 2.1.5. My OS is Windows 11.
Because of that, I am kind of blocked with my tests. Any help will be well appreciated. Thanks!
After asking the question, a new version arrived, if anyone encountered this problem, please update telepresence to 2.6.6. It is fixed now.

jupyterhub fails to spawn server with systemdspawner

I am trying to run jupyterhub on an Ubuntu 20.04 LTS server. My idea is to run python/jupyterhub in a conda virtual environment as a system service. As I want to be able to limit the resources available to individual users I installed the systemdspawner.
After installing everything and starting the jupyterhub service I can login through my web browser. However, when trying to start the server the spawner stucks and after a while I get an error message saying "Spawn failed: Timeout"
in journalctl I can see the following messages:
User logged in: me 302 POST /hub/login?next= -> /hub/spawn (me#::ffff:[my IP address]) 59.42ms
Adding role server to token: <APIToken('93c8...', user='me', client_id='jupyterhub')
Creating oauth client jupyterhub-user-me
pam_loginuid(login:session): Error writing /proc/self/loginuid: Operation not permitted
pam_loginuid(login:session): set_loginuid failed
pam_unix(login:session): session opened for user me by (uid=0)
Failed to open PAM session for me: [PAM Error 14] Cannot make/remove an entry for the specified session
Disabling PAM sessions from now on. user:me
Unit jupyter-me-singleuser in a failed state. Resetting state.
Disclaimer: My Jupyter/Python installation is replacing an former installation that was setup by someone else and got messed up a bit during time. I tried to remove everything related and start with a clean installation from scratch. However, as I had very little documentation about the old setup there is a certain risk that there might be some left-overs of the previous installation that may cause trouble.
Any ideas?
Solved it out myself. In the end the PAM related messages seem to be non-critical and were not related to the timeout at all. Instead I found a mistake in /etc/systemd/system/jupyterhub.service, where the PATH variable was not including the bin directory of my miniconda installation.

Mariadb mysql_upgrade failed

a have upgraded my DB server from 10.1.36 to 10.2.30 and after running command mysql_upgrade it fail at step 4. Please take a look on screenshot. Does anybody have idea what is wrong?
I believe you have to give mysql users read and execute permissions to /var/log/ and /var/log/mysql/ directory, before it can access /var/log/mysql/slow_log.CSV file.

Wordpress failed update plugins after core upgrade in a new server

I moved a WordPress site from a cpanel server to plesk server. Then, i upgraded manualy the site from 3.5.1 version to 4.8.3. Afterwards i tried to upgrade plugins (fancy box) as well as to intall new plugins (contact form 7).
The issue i have is that i get the following error message "Update Failed: Download failed. Destination directory for file streaming does not exist or is not writable.".
In the server's log file i can see few warning like the following one
mod_fcgid: stderr: PHP Warning: file_exists(): open_basedir restriction in effect. File(/home/dentist/domains/dentist.com.gr/public_html/newsite/wp-content/uploads//easy-fancybox.1.6.2-Vlaovu.tmp) is not within the allowed path(s): (/var/www/vhosts/ggeorgiou.gr/ggeorgiou.work/:/tmp/) in /var/www/vhosts/ggeorgiou.gr/ggeorgiou.work/wd/dentist.com.gr/wp-includes/functions.php on line 2085, referer: http://www.ggeorgiou.work/wd/dentist.com.gr/wp-admin/plugins.php
Finally, note that in "Settings --> Media" menu in "
Store uploads in this folder" field i have put the following path of the current server: "/var/www/vhosts/ggeorgiou.gr/ggeorgiou.work/wd/dentist.com.gr/wp-content/uploads".
Any idea please what is wrong about?
Thank you
From what you posted, your exact error message is "open_basedir restriction in effect". You can read more about how to solve it here How can I relax PHP's open_basedir restriction?
Also,
Assuming you have a backup of the previous version, I would start by restoring that.
Secondly, there are many versions between 3.5.1 and 4.8.3. It is advisable to upgrade in increments of one version at a time. It is long but safer.

pgpool-II connection pooling - ERROR: "MD5" authentication with pgpool failed

Using the following for just connection pooling no master_slave or replication: rhel 6, postgresql 9.1.9, & pgpool-II 3.1.3 (also tried 3.2.5)
Followed solution suggested in http://www.pgpool.net/pipermail/pgpool-general/2013-May/001773.html
After following the instructions for MD5 I also tried setting both pg_hba.conf and pool_hba.conf to trust for local and subnet, but still get the following error when attempting to connect to the pool locally:
ERROR: "MD5" authentication with pgpool failed for user foo
Tried locally on Fedora 18 with pg9.2 and pgpool from Fedora repo and worked right out of the box.
At the end of all routes suggested everywhere I could find.
Help would be greatly appreciated.
After having hit the same problem the solution was to change ownership of the pool_passwd file to postgres.
Even though this file has a 644 permission, if owner isn't postgres you'll always get the aforementioned error. I guess this file's owner and the user running pgpool must match.
I'm running PosgreSQL 9.2 and pgpool-II 3.3.2, BTW.

Resources