September 2018 - discuss - lists.mariadb.org

[Maria-discuss] Galera 23.2.7 mariadb 5.5.33a msvc 1600 binaries available
by Yann Nayn 18 Nov '24

18 Nov '24

Binaries have been uploaded for both x86 and amd64 platforms. due to github file size limitations , the directories have been uploaded unarchived. for Win33 binaries , please checkout https://github.com/YannNayn/galera-mariadb-win32.git and for Win64(amd64) binaries (being uploaded/pushed): https://github.com/YannNayn/galera-mariadb-win64.git they are not recommended for a production environment. in the my.cnf file: _________ wsrep_provider=galera_smm.dll wsrep_sst_method=msqldump # percona xtrabackup will be tested soon _________ libevent and openssl(the provided binaries use respectively 2.1.3-alpha and 1.1.0-dev versions ) will be added next on github some limitations are stated on openssl website copied here for convenience: ____________ from http://www.openssl.org/ ____________ This software package uses strong cryptography, so even if it is created, maintained and distributed from liberal countries in Europe (where it is legal to do this), it falls under certain export/import and/or use restrictions in some other parts of the world. PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS OF OPENSSL ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. ________________________________________________ msvc 1600 redistributables SP1 need to be installed/available on the target machine: vcredist_x86.exe : http://www.microsoft.com/en-us/download/details.aspx?id=8328 vcredist_x64.exe : http://www.microsoft.com/en-us/download/details.aspx?id=13523 MSys binaries are provided and msqld.bat should then be used instead of mysqld.exe (e.g. mysld.bat --console --wsrep_cluster_address=gcomm:// ) in order to have a working sh shell(cygwin has been proved to do it as well) Please note that oqgraph is disabled (boost trunk is used , that is 1.55) Comments and suggestions are welcome.

2 1

[Maria-discuss] why stdout? -> [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096
by Reindl Harald 05 Jul '20

05 Jul '20

Aug 6 12:24:24 testserver mysqld: 150806 12:24:24 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096 ... why is this now stdout instead mysql logs? on systemd based distributions that spits now to the global syslog and finally on machines restarting 2 instances every hour for backup reasons it annoys until 10.0.19 or 10.0.20 that was not this way

5 13

[Maria-discuss] MariaDB-10.2.11 Long Time To Start
by Michael Caplan 15 Mar '19

15 Mar '19

Hi, I'm setting up a replication slave based off of MySQL 5.6. There are a large number of tables (400K). The MySQL 5.6 master takes around 10 minutes to start up, where the new MariaDB 10.2 slave takes close to 30 minutes. What is making the startup take soo long? In the below mysql log, you can see in the startup sequence between "Highest supported file format is Barracuda." and "InnoDB: 128 out of 128 rollback segments are active." the startup process takes the majority of its time: 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Uses event mutexes 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Compressed tables use zlib 1.2.8 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Using Linux native AIO 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Number of pools: 1 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Using SSE2 crc32 instructions 2018-01-07 9:38:15 139980432365760 [Note] InnoDB: Initializing buffer pool, total size = 54G, instances = 8, chunk size = 128M 2018-01-07 9:38:18 139980432365760 [Note] InnoDB: Completed initialization of buffer pool 2018-01-07 9:38:18 139918113195776 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2018-01-07 9:38:18 139980432365760 [Note] InnoDB: Highest supported file format is Barracuda. 2018-01-07 10:11:48 139980432365760 [Note] InnoDB: 128 out of 128 rollback segments are active. 2018-01-07 10:11:48 139980432365760 [Note] InnoDB: Creating shared tablespace for temporary tables 2018-01-07 10:11:48 139980432365760 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2018-01-07 10:11:48 139980432365760 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2018-01-07 10:11:48 139980432365760 [Note] InnoDB: Waiting for purge to start 2018-01-07 10:11:48 139980432365760 [Note] InnoDB: 5.7.20 started; log sequence number 1394303471760 2018-01-07 10:11:48 139919461500672 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2018-01-07 10:11:48 139980432365760 [Note] Server socket created on IP: '::'. 2018-01-07 10:11:49 139980432365760 [Note] Reading of all Master_info entries succeded 2018-01-07 10:11:49 139980432365760 [Note] Added new Master_info '' to hash table 2018-01-07 10:11:49 139980432365760 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.2.11-MariaDB-10.2.11+maria~xenial-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 mariadb.org binary distribution Any ideas why? I've included my my.conf file below. Thanks, Mike # Generated by Percona Configuration Wizard (http://tools.percona.com/) version REL5-20120208 # Configuration name usaddxprdsqlpm3 generated formcaplan(a)labnet.net at 2017-12-22 13:49:58 [mysql] # CLIENT # port = 3306 socket = /var/lib/mysql/mysql.sock [mysqladmin] # CLIENT # port = 3306 socket = /var/lib/mysql/mysql.sock [mysqld] # GENERAL # user = mysql default-storage-engine = InnoDB socket = /var/lib/mysql/mysql.sock pid-file = /var/lib/mysql/mysql.pid character-set-server = utf8 collation_server = utf8_general_ci performance_schema = 0 # MyISAM # key-buffer-size = 32M myisam-recover = FORCE,BACKUP # SAFETY # max-allowed-packet = 20M max-connect-errors = 1000000 skip-name-resolve sysdate-is-now = 1 innodb = FORCE # DATA STORAGE # datadir = /var/lib/mysql/ # BINARY LOGGING # log-bin = /var/lib/mysql/mysql-bin binlog_format = MIXED server-id = 3 expire-logs-days = 7 sync-binlog = 1 # REPLICATION # read-only = 1 skip-slave-start = 1 log-slave-updates = 1 relay-log = /var/lib/mysql/relay-bin slave-net-timeout = 60 sync-master-info = 1 sync-relay-log = 1 sync-relay-log-info = 1 # CACHES AND LIMITS # tmp-table-size = 32M max-heap-table-size = 32M query-cache-type = 0 query-cache-size = 0 max-connections = 500 thread-cache-size = 50 open-files-limit = 65535 table-definition-cache = 4096 table-open-cache = 10240 # INNODB # innodb-flush-method = O_DIRECT innodb-log-files-in-group = 2 innodb-log-file-size = 512M innodb-flush-log-at-trx-commit = 1 innodb-file-per-table = 1 innodb-buffer-pool-size = 54G # LOGGING # log-error = /var/lib/mysql/mysql-error.log log-queries-not-using-indexes = 0 slow-query-log = 0 slow-query-log-file = /var/lib/mysql/mysql-slow.log [mariadb] plugin-load-add=file_key_management file_key_management_filename=/var/lib/mysql/keys.enc file_key_management_filekey=FILE:/var/lib/mysql/mysql.key file_key_management_encryption_algorithm=AES_CTR encrypt_binlog=0

3 19

[Maria-discuss] Chewing Through Swap - Swappiness = 0
by Michael Caplan 09 Mar '19

09 Mar '19

Hi, I'm trying to figure out why my recently put into production MariaDB is so swap hungry. I'm running 10.2.14, with roughly 300GB data (1000K +/- tables). 95% tables are innodb. I have 64GB RAM, with INNODB buffer pool size set to 50GB (full my.cnf below). The OS is Ubuntu 16.04.4. This is a dedicated MariaDB server. I have swappiness set to 0. I started with available swap set to just shy of 1GB. When swap got to 85% used, I bumped swap to 3GB. A day later, swap again was 85% used, and I bumped it to 5GB. A day later, swap again was 85% used, so I bumped it to 15GB. 2 days later 50% of the available swap was used. I restarted the DB moments ago, freeing up all 15GB but 128MB of swap: total used free shared buff/cache available Mem: 62G 20G 4.7G 266M 37G 41G Swap: 14G 128M 14G My understanding is that the OS should never allocate swap when swappiness is 0, so that has me confused. I've had similar issues with MySQL 5.6 (what I upgraded from) dipping into swap, but that instance had swappiness set to 1, and never consumed more than 5GB of swap. Questions: 1) How much of this is an OS issue vs MariaDB issue? 2) What MariaDB config vars should I be looking at to fix this issue? 3) What linux config vars should I be looking at to fix this issue? Thanks, Mike [mysqld] # GENERAL # user = mysql default-storage-engine = InnoDB character-set-server = utf8 collation_server = utf8_general_ci performance_schema = 0 max_allowed_packet = 16777216 sql_mode = "NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" # MyISAM # key-buffer-size = 32M myisam-recover = FORCE,BACKUP # SAFETY # max-allowed-packet = 16777216 max-connect-errors = 1000000 skip-name-resolve sysdate-is-now = 1 innodb = FORCE local_infile = 0 secure_auth = 1 safe_user_create = 1 skip_symbolic_links = 1 wait_timeout = 28800 # DATA STORAGE # datadir = /var/lib/mysql/ # BINARY LOGGING # log-bin = /var/lib/mysql/mysql-bin binlog_format = MIXED server-id = 3 expire-logs-days = 7 sync-binlog = 1 # REPLICATION # read-only = 1 skip-slave-start = 1 log-slave-updates = 1 relay-log = /var/lib/mysql/relay-bin slave-net-timeout = 60 sync-master-info = 1 sync-relay-log = 1 sync-relay-log-info = 1 # CACHES AND LIMITS # tmp-table-size = 32M max-heap-table-size = 32M query-cache-type = 0 query-cache-size = 0 max-connections = 500 thread-cache-size = 50 open-files-limit = 65535 table-definition-cache = 4096 table-open-cache = 10240 # INNODB # innodb-flush-method = O_DIRECT innodb-log-files-in-group = 2 innodb-log-file-size = 512M innodb-flush-log-at-trx-commit = 2 innodb-file-per-table = 1 innodb-buffer-pool-size = 50G

3 8

[Maria-discuss] gtid_slave_pos row count
by Reinis Rozitis 15 Oct '18

15 Oct '18

Hi, before considering this as a bug wanted to ask in mailing list: I know that gtid_slave_pos table can have multiple entries, but (at least on 10.3.9 but maybe also earlier (just noticed now)) while running: slave_parallel_threads = 20 slave_parallel_mode = optimistic the table starts to grow continuously: MariaDB [mysql]> select count(*) from gtid_slave_pos; +----------+ | count(*) | +----------+ | 5577268 | +----------+ 1 row in set (1.553 sec) If I switch back to conservative mode it never goes above 2-3 rows even with the same 20 threads. Same happens also with gtid_pos_auto_engines - when in conservative each engine table has several records, once I switch to optimistic the gtid tables just grow. Is there something wrong with the purger? (something similar like in https://jira.mariadb.org/browse/MDEV-12147 ? ) rr

2 10

[Maria-discuss] MariaDB 10.3 and largepages on Linux
by Kenneth Penza 12 Oct '18

12 Oct '18

Good morning, I am currently running RHEL 7.5 and MariaDB 10.3.9. After setting "large_pages=on" I noticed that MariaDB is reporting an error on startup and shutdown as per below output. To use large pages I modified /etc/sysctl.conf, /etc/security/limits.conf and the systemd unit file. By monitoring /proc/meminfo I verified that largepage are being used. Configuration: mysqld would have been started with the following arguments: --port=3306 --socket=/var/lib/mysql/mysql.sock --thread_stack=256K --large_pages=on --key_buffer_size=16K --max_allowed_packet=512M --table_open_cache=32 --sort_buffer_size=512K --net_buffer_length=8K --read_buffer_size=256K --read_rnd_buffer_size=256K --slow_query_log=1 --slow_query_log_file=mysql-slow.log --long_query_time=0.1 --log-queries-not-using-indexes=on --thread_handling=pool-of-threads --thread_pool_idle_timeout=60 --thread_pool_max_threads=1000 --thread_pool_size=8 --innodb_buffer_pool_size=256M --innodb_strict_mode=1 --innodb_file_per_table=1 --innodb_flush_method=O_DIRECT --innodb_log_files_in_group=4 --innodb_log_file_size=50331648 --innodb_undo_logs=128 --innodb_undo_tablespaces=8 --slow_query_log=1 --slow_query_log_file=mysql-slow.log --long_query_time=30 --log-queries-not-using-indexes=off --log_bin=mariadblog --binlog_format=ROW --binlog_row_image=MINIMAL --max_binlog_size=10240000 --expire_logs_days=1 --server-id=1 --innodb_flush_log_at_trx_commit=1 --sync_binlog=1 --relay-log=mariadb-relay-bin --performance_schema=off --histogram_size=255 --histogram_type=SINGLE_PREC_HB --use_stat_tables=preferably --optimizer_use_condition_selectivity=4 Startup messages: Sep 25 10:40:53 srv1 mysqld: 2018-09-25 10:40:52 0 [Note] InnoDB: Opened 8 undo tablespaces Sep 25 10:40:53 srv1 mysqld: 2018-09-25 10:40:53 0 [Warning] InnoDB: Failed to set memory to DODUMP: Invalid argument ptr 0x2aaac5400000 size 2097152 Sep 25 10:40:53 srv1 mysqld: 2018-09-25 10:40:53 0 [Note] InnoDB: 128 out of 128 rollback segments in 8 undo tablespaces are active. Shutdown messages: Sep 25 10:41:18 srv1 mysqld: 2018-09-25 10:41:18 0 [Note] InnoDB: Buffer pool(s) dump completed at 180925 10:41:18 Sep 25 10:41:19 srv1 mysqld: 2018-09-25 10:41:19 0 [Warning] InnoDB: Failed to set memory to DODUMP: Invalid argument ptr 0x2aaac3400000 size 33554432 Sep 25 10:41:19 srv1 mysqld: 2018-09-25 10:41:19 0 [Note] InnoDB: Shutdown completed; log sequence number 1522725; transaction id 22 Do you have ideas on what is causing "InnoDB: Failed to set memory to DODUMP: Invalid argument ptr .. " warning? Kenneth

2 3

[Maria-discuss] CONC-312; caching_sha2_plugin
by Michal Schorm 02 Oct '18

02 Oct '18

Hello, Can I get some explanation, why was https://jira.mariadb.org/browse/CONC-312 closed as WON'T FIX ? -- MySQL 8.0 implemented "caching_sha2_password" as its default authentification plugin / method. MariaDB doesn't have support for it so mariadb-connector-c cannot be used for MySQL 8. That makes problems for nearly every Linux OS, beacuse they chose MariaDB over MySQL as the default implemetation. I'd like to know the MariaDB stance to it. Do you see it as an issue as well? Are there any plans to deal with it? How? Michal Schorm -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat

2 2

[Maria-discuss] Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud
by Turritopsis Dohrnii Teo En Ming 29 Sep '18

29 Sep '18

Good morning from Singapore, You can read my step-by-step tutorial on How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud at any one of my two redundant blogs. My blogs were configured in RAID 1 mirroring array. https://tdtemcerts.wordpress.com/2018/09/29/step-by-step-tutorial-how-to-se… https://tdtemcerts.blogspot.com/2018/09/step-by-step-tutorial-how-to-setup-… Thanks for reading! If there are any mistakes, please do let me know! ===BEGIN SIGNATURE=== Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 [1] https://tdtemcerts.wordpress.com/ <https://tdtemcerts.wordpress.com/>[2] http://tdtemcerts.blogspot.sg/ <http://tdtemcerts.blogspot.sg/>[3] https://www.scribd.com/user/270125049/Teo-En-Ming <https://www.scribd.com/user/270125049/Teo-En-Ming>===END SIGNATURE===

1 0

Re: [Maria-discuss] MariaDB 10.3 and largepages on Linux
by Kenneth Penza 26 Sep '18

26 Sep '18

Good morning, Thanks for the clarification. Yes sure, below please find the requested output. If you prefer I can open a JIRA ticket to facilitate tracking. $ cat /proc/sys/vm/nr_hugepages 512 $ uname -a Linux srv1 3.10.0-862.11.6.el7.x86_64 #1 SMP Fri Aug 10 16:55:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ grep ^Huge /proc/meminfo HugePages_Total: 512 HugePages_Free: 467 HugePages_Rsvd: 167 HugePages_Surp: 0 Hugepagesize: 2048 kB $ grep mysql /etc/security/limits.conf mysql soft memlock 2621440 mysql hard memlock 2621440 $ grep AnonHugePages /proc/meminfo AnonHugePages: 6144 kB $ cat /etc/sysctl.d/99-mysql.conf vm.hugetlb_shm_group = 27 vm.nr_hugepages = 512 vm.swappiness = 10 fs.aio-max-nr = 500000 $ I have also added, "LimitMEMLOCK=2147483648" in systemd file. Kenneth On Wed, Sep 26, 2018 at 1:01 AM Daniel Black <daniel(a)linux.ibm.com> wrote: > On Tue, 25 Sep 2018 10:48:01 +0200 > Kenneth Penza <kpenza(a)gmail.com> wrote: > > > Good morning, > > > Good morning, > > Thanks for the detailed bug report. As the contributor of this feature > I'm happy to try to work this out. First I'll reassure you that the > WARNING is simply that, there's no negative impacts form this apart > from any unexpected core dump will include the large pages as it failed > to to mark them as don't dump. > > A couple of small clarifying questions to start: > > Do you have THP enabled? > $ cat /proc/sys/vm/nr_hugepages > > What kernel version / architecture? > $ uname -a > > What huge page size / current allocation is available? > > $ grep ^Huge /proc/meminfo > > > > I am currently running RHEL 7.5 and MariaDB 10.3.9. After setting > > "large_pages=on" I noticed that MariaDB is reporting an error on > > startup and shutdown as per below output. > > > > To use large pages I > > modified /etc/sysctl.conf, /etc/security/limits.conf and the systemd > > unit file. By monitoring /proc/meminfo I verified that largepage are > > being used. > > > > Configuration: > > > > mysqld would have been started with the following arguments: > > --port=3306 --socket=/var/lib/mysql/mysql.sock --thread_stack=256K > > --large_pages=on --key_buffer_size=16K --max_allowed_packet=512M > > --table_open_cache=32 --sort_buffer_size=512K --net_buffer_length=8K > > --read_buffer_size=256K --read_rnd_buffer_size=256K --slow_query_log=1 > > --slow_query_log_file=mysql-slow.log --long_query_time=0.1 > > --log-queries-not-using-indexes=on --thread_handling=pool-of-threads > > --thread_pool_idle_timeout=60 --thread_pool_max_threads=1000 > > --thread_pool_size=8 --innodb_buffer_pool_size=256M > > --innodb_strict_mode=1 --innodb_file_per_table=1 > > --innodb_flush_method=O_DIRECT --innodb_log_files_in_group=4 > > --innodb_log_file_size=50331648 --innodb_undo_logs=128 > > --innodb_undo_tablespaces=8 --slow_query_log=1 > > --slow_query_log_file=mysql-slow.log --long_query_time=30 > > --log-queries-not-using-indexes=off --log_bin=mariadblog > > --binlog_format=ROW --binlog_row_image=MINIMAL > > --max_binlog_size=10240000 --expire_logs_days=1 --server-id=1 > > --innodb_flush_log_at_trx_commit=1 --sync_binlog=1 > > --relay-log=mariadb-relay-bin --performance_schema=off > > --histogram_size=255 --histogram_type=SINGLE_PREC_HB > > --use_stat_tables=preferably --optimizer_use_condition_selectivity=4 > > > > Startup messages: > > > > Sep 25 10:40:53 srv1 mysqld: 2018-09-25 10:40:52 0 [Note] InnoDB: > > Opened 8 undo tablespaces > > Sep 25 10:40:53 srv1 mysqld: 2018-09-25 10:40:53 0 [Warning] InnoDB: > > Failed to set memory to DODUMP: Invalid argument ptr 0x2aaac5400000 > > size 2097152 Sep 25 10:40:53 srv1 mysqld: 2018-09-25 10:40:53 0 > > [Note] InnoDB: 128 out of 128 rollback segments in 8 undo tablespaces > > are active. > > > > Shutdown messages: > > > > Sep 25 10:41:18 srv1 mysqld: 2018-09-25 10:41:18 0 [Note] InnoDB: > > Buffer pool(s) dump completed at 180925 10:41:18 > > Sep 25 10:41:19 srv1 mysqld: 2018-09-25 10:41:19 0 [Warning] InnoDB: > > Failed to set memory to DODUMP: Invalid argument ptr 0x2aaac3400000 > > size 33554432 Sep 25 10:41:19 srv1 mysqld: 2018-09-25 10:41:19 0 > > [Note] InnoDB: Shutdown completed; log sequence number 1522725; > > transaction id 22 > > > > Do you have ideas on what is causing "InnoDB: Failed to set memory to > > DODUMP: Invalid argument ptr .. " warning? > > > > > > > Kenneth > >

1 0

[Maria-discuss] pam / ldap auth
by mourik jan c heupink 25 Sep '18

25 Sep '18

Hi, I installed mariadb using the stock debian packages, configured pam authentication, and configured a mysql pam module like this: > /etc/pam.d/mysql > auth required pam_winbind.so > account required pam_winbind.so As I also added the server to my AD domain, this basically gives my samba winbind users access to mysql using their windows credentials: > root@mysqlserver:~# mysql -udomain_username -p > Enter password: <windows_domain_password> > Welcome to the MariaDB monitor. Commands end with ; or \g. > Your MariaDB connection id is 6 > Server version: 10.1.26-MariaDB-0+deb9u1 Debian 9.1 > > Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others. > > Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. > > MariaDB [(none)]> So I was happy. Initially. :-) Until I found out this works only from the localhost mariadb is running on. Trying this from a remote mysql client gives: > user@e7470 ~ $ mysql -udomain_user -p -h mysqlserver.full.address > Enter password: ERROR 2059 (HY000): Authentication plugin 'dialog' cannot be loaded: /usr/lib/mysql/plugin/dialog.so: cannot open shared object file: No such file or directory and searching on that remote server for /usr/lib/mysql/plugin/dialog.so gives no results: > user@e7470 ~ $ dpkg --search /usr/lib/mysql/plugin/dialog.so > dpkg-query: no path found matching pattern /usr/lib/mysql/plugin/dialog.so Anyone here with a good suggestion how to make this work from a 'regular' remote mysql client? But more fundamentally: is it possible to have mariadb ldap auth on a server, *without* requiring anything special on the client side? MJ

4 6