Re: Failed to setup SSL
Thanks, Michael. I used the absolute paths but it still does not work. I think the problem is not because of the relative path because the example showed in the manual also uses relative path (see below): shell> *mysqld --ssl-ca=ca-cert.pem \* *--ssl-cert=server-cert.pem \* *--ssl-key=server-key.pem * For the permission, I used exactly the same as Reindl's (I used his scripts). Since the error messages are still the same, I guess there should be something else wrong? Best regards, Jackie On Sat, Nov 24, 2012 at 5:15 PM, Michael Dykman wrote: > I had noticed that the paths to your certificates were expressed as > relative paths. I think at least part of Reindl's recommendation was to > express fully qualified paths to your certs and to examined the permissions > on those files carefully. SSL is very particular about rejecting security > files which have too-permisive permissions.. > > also, considered tailing /var/log/secure > > On 2012-11-24 8:05 PM, "Jackie Zhang" wrote: > > Dear Reindl, > > Thanks a lot for the reply! > > I tried your scripts (the only difference is the openssl.cnf because I > don't have it) > > Unfortunately, I still failed to start the server with the same message: > > 121124 17:00:06 [Warning] Failed to setup SSL > 121124 17:00:06 [Warning] SSL error: Failed to set ciphers to use > > Do you have any idea from the log message? > > Best regards, > Jackie > > > On Sat, Nov 24, 2012 at 4:02 PM, Reindl Harald >wrote: > > > > > > > > Am 25.11.2012 00:30, schrieb Jackie Zhang: > > > Hello everyone, > > > > > > I want to setup SSL fo... > >
Re: Failed to setup SSL
I had noticed that the paths to your certificates were expressed as relative paths. I think at least part of Reindl's recommendation was to express fully qualified paths to your certs and to examined the permissions on those files carefully. SSL is very particular about rejecting security files which have too-permisive permissions.. also, considered tailing /var/log/secure On 2012-11-24 8:05 PM, "Jackie Zhang" wrote: Dear Reindl, Thanks a lot for the reply! I tried your scripts (the only difference is the openssl.cnf because I don't have it) Unfortunately, I still failed to start the server with the same message: 121124 17:00:06 [Warning] Failed to setup SSL 121124 17:00:06 [Warning] SSL error: Failed to set ciphers to use Do you have any idea from the log message? Best regards, Jackie On Sat, Nov 24, 2012 at 4:02 PM, Reindl Harald wrote: > > > Am 25.11.2012 00:30, schrieb Jackie Zhang: > > Hello everyone, > > > > I want to setup SSL fo...
Re: Failed to setup SSL
Dear Reindl, Thanks a lot for the reply! I tried your scripts (the only difference is the openssl.cnf because I don't have it) Unfortunately, I still failed to start the server with the same message: 121124 17:00:06 [Warning] Failed to setup SSL 121124 17:00:06 [Warning] SSL error: Failed to set ciphers to use Do you have any idea from the log message? Best regards, Jackie On Sat, Nov 24, 2012 at 4:02 PM, Reindl Harald wrote: > > > Am 25.11.2012 00:30, schrieb Jackie Zhang: > > Hello everyone, > > > > I want to setup SSL for mysql server. I followed the manual on > > http://dev.mysql.com/doc/refman/5.5/en/ssl-connections.html > > > > I first generated the certificates and key files by strictly following > the > > following link, > > http://dev.mysql.com/doc/refman/5.5/en/creating-ssl-certs.html > > with everything verified: > > > > shell> *openssl verify -CAfile ca-cert.pem server-cert.pem > client-cert.pem* > > server-cert.pem: OK > > client-cert.pem: OK > > > > > > But, when I start my server using > > bin/mysqld --ssl-ca=./newcerts/ca-cert.pem \ > > --ssl-cert=./newcerts/server-cert.pem \ > > --ssl-key=./newcerts/server-key.pem > > > > The server started with the following error message: > > 121124 14:41:27 [Warning] Failed to setup SSL > > 121124 14:41:27 [Warning] SSL error: Failed to set ciphers to use > > > > Did I miss something? I tried to add > > --ssl-cipher=DHE-RSA-AES256-SHA:AES128-SHA and --ssl, but it didn't help. > > > > Please give me some clue... > > i used the script below for generate ca.crt, client.pem, server.pem > this setup works since years for replication as also php-scripts > > [root@buildserver:~]$ cat /buildserver/ssl-cert/mysql/generate.sh > #!/bin/bash > > DIR="/buildserver/ssl-cert/mysql" > > rm -rf $DIR/cert/ > rm -rf $DIR/db/ > mkdir $DIR/cert/ > mkdir $DIR/db/ > > touch $DIR/db/index.txt > echo "01" > $DIR/db/serial > > rm -f $DIR/ca.key > rm -f $DIR/cert/ca.crt > > openssl req -new -x509 -days 3650 -keyout $DIR/ca.key -out > $DIR/cert/ca.crt -config $DIR/openssl.cnf > > openssl req -new -keyout $DIR/cert/server.key -out $DIR/cert/server.csr > -days 3650 -config $DIR/openssl.cnf > > openssl rsa -in $DIR/cert/server.key -out $DIR/cert/server.key > openssl ca -policy policy_anything -out $DIR/cert/server.crt -days 3650 > -config $DIR/openssl.cnf -infiles > $DIR/cert/server.csr > > openssl req -new -keyout $DIR/cert/client.key -out $DIR/cert/client.csr > -days 3650 -config $DIR/openssl.cnf > openssl rsa -in $DIR/cert/client.key -out $DIR/cert/client.key > openssl ca -policy policy_anything -out $DIR/cert/client.crt -days 3650 > -config $DIR/openssl.cnf -infiles > $DIR/cert/client.csr > > rm -f $DIR/cert/server.csr > rm -f $DIR/cert/client.csr > rm -f $DIR/cert/01.pem > rm -f $DIR/cert/02.pem > > cat $DIR/cert/server.crt $DIR/cert/server.key > $DIR/cert/server.pem > rm -f $DIR/cert/server.crt > rm -f $DIR/cert/server.key > > cat $DIR/cert/client.crt $DIR/cert/client.key > $DIR/cert/client.pem > rm -f $DIR/cert/client.crt > rm -f $DIR/cert/client.key > > chmod 644 $DIR/cert/* > rm -f /etc/mysql-ssl/* > cp $DIR/cert/* /etc/mysql-ssl/ > chmod 755 /etc/mysql-ssl/ > chmod 644 /etc/mysql-ssl/* > > >
Re: Failed to setup SSL
Am 25.11.2012 00:30, schrieb Jackie Zhang: > Hello everyone, > > I want to setup SSL for mysql server. I followed the manual on > http://dev.mysql.com/doc/refman/5.5/en/ssl-connections.html > > I first generated the certificates and key files by strictly following the > following link, > http://dev.mysql.com/doc/refman/5.5/en/creating-ssl-certs.html > with everything verified: > > shell> *openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem* > server-cert.pem: OK > client-cert.pem: OK > > > But, when I start my server using > bin/mysqld --ssl-ca=./newcerts/ca-cert.pem \ > --ssl-cert=./newcerts/server-cert.pem \ > --ssl-key=./newcerts/server-key.pem > > The server started with the following error message: > 121124 14:41:27 [Warning] Failed to setup SSL > 121124 14:41:27 [Warning] SSL error: Failed to set ciphers to use > > Did I miss something? I tried to add > --ssl-cipher=DHE-RSA-AES256-SHA:AES128-SHA and --ssl, but it didn't help. > > Please give me some clue... i used the script below for generate ca.crt, client.pem, server.pem this setup works since years for replication as also php-scripts [root@buildserver:~]$ cat /buildserver/ssl-cert/mysql/generate.sh #!/bin/bash DIR="/buildserver/ssl-cert/mysql" rm -rf $DIR/cert/ rm -rf $DIR/db/ mkdir $DIR/cert/ mkdir $DIR/db/ touch $DIR/db/index.txt echo "01" > $DIR/db/serial rm -f $DIR/ca.key rm -f $DIR/cert/ca.crt openssl req -new -x509 -days 3650 -keyout $DIR/ca.key -out $DIR/cert/ca.crt -config $DIR/openssl.cnf openssl req -new -keyout $DIR/cert/server.key -out $DIR/cert/server.csr -days 3650 -config $DIR/openssl.cnf openssl rsa -in $DIR/cert/server.key -out $DIR/cert/server.key openssl ca -policy policy_anything -out $DIR/cert/server.crt -days 3650 -config $DIR/openssl.cnf -infiles $DIR/cert/server.csr openssl req -new -keyout $DIR/cert/client.key -out $DIR/cert/client.csr -days 3650 -config $DIR/openssl.cnf openssl rsa -in $DIR/cert/client.key -out $DIR/cert/client.key openssl ca -policy policy_anything -out $DIR/cert/client.crt -days 3650 -config $DIR/openssl.cnf -infiles $DIR/cert/client.csr rm -f $DIR/cert/server.csr rm -f $DIR/cert/client.csr rm -f $DIR/cert/01.pem rm -f $DIR/cert/02.pem cat $DIR/cert/server.crt $DIR/cert/server.key > $DIR/cert/server.pem rm -f $DIR/cert/server.crt rm -f $DIR/cert/server.key cat $DIR/cert/client.crt $DIR/cert/client.key > $DIR/cert/client.pem rm -f $DIR/cert/client.crt rm -f $DIR/cert/client.key chmod 644 $DIR/cert/* rm -f /etc/mysql-ssl/* cp $DIR/cert/* /etc/mysql-ssl/ chmod 755 /etc/mysql-ssl/ chmod 644 /etc/mysql-ssl/* signature.asc Description: OpenPGP digital signature
Re: Covering Index without the data file (myisam)
Hello, Well, you have just invented what is known as index organized tables. The MyISAM engine does not implement those. If it did, it would have to deal with quite a few circumstances unique to IOTs. One such circumstance is degradation of efficiency with the increase of record length, another is bloating the size of secondary indexes, and there is quite a few more... In short, the alternative to keeping the MYD file would be much worse :-) Peace Karen. On 24.11.2012, at 13:02, Hank wrote: > Hello everyone, > > I know this is a longshot, but is there any way to eliminate the MYD > file for a table that has a full covering index? The index is larger > than the datafile, since it contains all the records in the datafile, > plus a second reverse index. It seems redundant to have to also store > a MYD file. > > Thanks, > > -Hank > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe:http://lists.mysql.com/mysql > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Covering Index without the data file (myisam)
MyISAM can't do this but innodb can. If you change to an innodb table and define your index as the primary key then row data is clustered with the primary key. This means there is no additional storage overhead for the primary key because it is just the row data. This will break down if you define secondary indexes though because the primary key is copied for each secondary index. http://dev.mysql.com/doc/refman/5.0/en/innodb-index-types.html On Sat, Nov 24, 2012 at 1:15 PM, Reindl Harald wrote: > > > Am 24.11.2012 22:02, schrieb Hank: >> Hello everyone, >> >> I know this is a longshot, but is there any way to eliminate the MYD >> file for a table that has a full covering index? The index is larger >> than the datafile, since it contains all the records in the datafile, >> plus a second reverse index. It seems redundant to have to also store >> a MYD file > > simple answer: NO > -- Eric Bergen eric.ber...@gmail.com http://www.ebergen.net -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Covering Index without the data file (myisam)
Am 24.11.2012 22:02, schrieb Hank: > Hello everyone, > > I know this is a longshot, but is there any way to eliminate the MYD > file for a table that has a full covering index? The index is larger > than the datafile, since it contains all the records in the datafile, > plus a second reverse index. It seems redundant to have to also store > a MYD file simple answer: NO signature.asc Description: OpenPGP digital signature
Re: Why configuration directives are all case sensitive?
Hi, Eric, Thanks a lot for the GREAT explanation! This perfectly answers my question. We can close the threads now :-) Best, T On Sat, Nov 24, 2012 at 8:53 AM, Eric Bergen wrote: > Yes, the missing piece of the puzzle is that configuration files are > turned into command line arguments internally. Programs will parse > configuration files and place them at the beginning of the array for > command line arguments. They are made case sensitive because they are > turned into command line arguments. So the basic process is read all > the configuration files in order of precedence into the beginning of > the command line array. Then send this array to the command line > handling code. This is also how argument precedence works. As the > array is walked through options will override previous options so > things passed on the command line are at the end and override options > in the config file. > > On Fri, Nov 23, 2012 at 10:08 PM, Tianyin Xu wrote: > > Dear Eric, > > > > Thanks a lot for the explanation of argument directives! The concerns are > > very considerate. > > > > Actually, what I'm curious about is the configuration directives in the > > configuration file, i.e., my.cnf. To my experience, MySQL is the very few > > software who treats these directives in a case sensitive manner. > > > > The directives in the configuration file is different from the arguments, > > because we don't have something like --port and -P. So, a directive like > > "Port" clearly indicates that the user specifies "port" (exactly as you > > said). And this's the reason that most apps do not differentiate them. > > > > Could you please explain about the directives in the configuration file? > > > > Thanks a lot! > > > > Happy Thanksgiving!! > > Tianyin > > > > > > > > On Fri, Nov 23, 2012 at 4:20 PM, Eric Bergen > wrote: > >> > >> Anger and OS religious arguments the real answer is that is just how > >> the option parsing code works. It doesn't always have to make sense. > >> There are short and long args to programs. For example on the mysql > >> client there is --port or -P and --pasword or -p. The short options > >> have to be case sensitive because -P and -p mean different things. The > >> short options are case sensitive so the long options may as well be. > >> It keeps things simpler. Who wants to write --Port when --port means > >> not hitting the shift key? > >> > >> There are a few exceptions to this. The option comparison treats _ and > >> - as the same. I realize that isn't case but it just shows the > >> matching isn't exact. So --show_warnings is valid. On the other side > >> of the equal sign comparisons for true, on, false, and off are done > >> case insensitive. So --show_warnings=FaLse is valid but > >> --show_warningS=TruE isn't. > >> > >> If you want to be even more confused consider that mysql allows > >> partial argument names. You don't have to type out the full long arg > >> as long as you type enough that it only matches one option. For > >> example mysql --so is enough to mean socket but mysql --s isn't > >> because it can't be distinguished from 'show' variables. This gets > >> confusing with things like b. mysql --b is batch mode. So is mysql -B > >> but mysql -b is no beep. Confused yet? > >> > >> On Sun, Nov 18, 2012 at 6:42 PM, Tianyin Xu wrote: > >> > On Sun, Nov 18, 2012 at 6:13 PM, Reindl Harald > >> > wrote: > >> > > >> >> > >> >> > >> >> Am 19.11.2012 02:07, schrieb Tianyin Xu: > >> >> > You are saying as long as admins are careful, there's no > >> >> misconfiguration? > >> >> > But why misconfigurations are so pervasive? > >> >> > Simply because the admins are not careful enough? > >> >> > >> >> yes > >> >> > >> >> > >> > That means not only I'm dummy, and that's means you should take care > the > >> > system configuration design if many people are careless. > >> > > >> > > >> > > >> >> > I apologize for my lack of respect. I don't know what's your stuff, > >> >> > but > >> >> > I guess they'll be more popular if you make them more friendly. > >> >> > >> >> it does not need to be more popular > >> >> it is better not to be too popular but working clean and safe > >> >> > >> >> careless working these days means usually also not care > >> >> about security which is not acceptable htese days and i > >> >> know a lot of crap out there which is more popluar like > >> >> my work but with crappy quality and terrible insecure > >> >> > >> >> see all this CMS sytems out there writing hundrets of > >> >> warnings each request with error_reporting E_STRICT > >> >> while my whole source code runs clean i know who is right > >> >> > >> >> really: > >> >> if you find it useful to complain why a configuration is > >> >> case-sensitive instead accept it and correct your fault > >> >> you are doing the wrong job > >> >> > >> >> > >> > I'm complaining nothing. I just curious about the configuration and > want > >> > to > >> > know you developers' thinking. I apologize if I gave you the > impression > >> >
Re: Why configuration directives are all case sensitive?
Yes, the missing piece of the puzzle is that configuration files are turned into command line arguments internally. Programs will parse configuration files and place them at the beginning of the array for command line arguments. They are made case sensitive because they are turned into command line arguments. So the basic process is read all the configuration files in order of precedence into the beginning of the command line array. Then send this array to the command line handling code. This is also how argument precedence works. As the array is walked through options will override previous options so things passed on the command line are at the end and override options in the config file. On Fri, Nov 23, 2012 at 10:08 PM, Tianyin Xu wrote: > Dear Eric, > > Thanks a lot for the explanation of argument directives! The concerns are > very considerate. > > Actually, what I'm curious about is the configuration directives in the > configuration file, i.e., my.cnf. To my experience, MySQL is the very few > software who treats these directives in a case sensitive manner. > > The directives in the configuration file is different from the arguments, > because we don't have something like --port and -P. So, a directive like > "Port" clearly indicates that the user specifies "port" (exactly as you > said). And this's the reason that most apps do not differentiate them. > > Could you please explain about the directives in the configuration file? > > Thanks a lot! > > Happy Thanksgiving!! > Tianyin > > > > On Fri, Nov 23, 2012 at 4:20 PM, Eric Bergen wrote: >> >> Anger and OS religious arguments the real answer is that is just how >> the option parsing code works. It doesn't always have to make sense. >> There are short and long args to programs. For example on the mysql >> client there is --port or -P and --pasword or -p. The short options >> have to be case sensitive because -P and -p mean different things. The >> short options are case sensitive so the long options may as well be. >> It keeps things simpler. Who wants to write --Port when --port means >> not hitting the shift key? >> >> There are a few exceptions to this. The option comparison treats _ and >> - as the same. I realize that isn't case but it just shows the >> matching isn't exact. So --show_warnings is valid. On the other side >> of the equal sign comparisons for true, on, false, and off are done >> case insensitive. So --show_warnings=FaLse is valid but >> --show_warningS=TruE isn't. >> >> If you want to be even more confused consider that mysql allows >> partial argument names. You don't have to type out the full long arg >> as long as you type enough that it only matches one option. For >> example mysql --so is enough to mean socket but mysql --s isn't >> because it can't be distinguished from 'show' variables. This gets >> confusing with things like b. mysql --b is batch mode. So is mysql -B >> but mysql -b is no beep. Confused yet? >> >> On Sun, Nov 18, 2012 at 6:42 PM, Tianyin Xu wrote: >> > On Sun, Nov 18, 2012 at 6:13 PM, Reindl Harald >> > wrote: >> > >> >> >> >> >> >> Am 19.11.2012 02:07, schrieb Tianyin Xu: >> >> > You are saying as long as admins are careful, there's no >> >> misconfiguration? >> >> > But why misconfigurations are so pervasive? >> >> > Simply because the admins are not careful enough? >> >> >> >> yes >> >> >> >> >> > That means not only I'm dummy, and that's means you should take care the >> > system configuration design if many people are careless. >> > >> > >> > >> >> > I apologize for my lack of respect. I don't know what's your stuff, >> >> > but >> >> > I guess they'll be more popular if you make them more friendly. >> >> >> >> it does not need to be more popular >> >> it is better not to be too popular but working clean and safe >> >> >> >> careless working these days means usually also not care >> >> about security which is not acceptable htese days and i >> >> know a lot of crap out there which is more popluar like >> >> my work but with crappy quality and terrible insecure >> >> >> >> see all this CMS sytems out there writing hundrets of >> >> warnings each request with error_reporting E_STRICT >> >> while my whole source code runs clean i know who is right >> >> >> >> really: >> >> if you find it useful to complain why a configuration is >> >> case-sensitive instead accept it and correct your fault >> >> you are doing the wrong job >> >> >> >> >> > I'm complaining nothing. I just curious about the configuration and want >> > to >> > know you developers' thinking. I apologize if I gave you the impression >> > of >> > complaining by asking questions. >> > >> > Basically, I'm new to MySQL and find MySQL really take care about lots >> > of >> > things to give users an easy job. For example, the unit, the enumeration >> > options, all are case insensitive -- "512K" and "512k" means the same >> > size, >> > "MIXED" and "mixed" means the same option, etc. Having such impression, >> > when MySQL tells me 'Port' is u
Which test suites are valid for --extern option in mysql-test-run?
Hi, all, I wanna test my running MySQL server. According to the README in the "mysql-test" directory, "If you want to use an already running MySQL server for specific tests, use the --extern option to mysql-test-run". For example, mysql-test-run --extern alias But the README also pointed out that "some tests cannot run with an external server". My question is how to know which test suites in "t" directory are valid for --extern option? Without knowing this, I cannot judge whether a test fails is because it's not supported or "real" problems. Thanks a lot! Tianyin -- Tianyin XU, http://cseweb.ucsd.edu/~tixu/
