Hey MSE, why did you make me panic? It told Apache files are Trojan:Win32/Critet.BS.

Update (Mar.22):

   Today, I’ve updated Apache from 2.4.32 to 2.4.33. Now, MSE says all files are clean. What was that alert? Really compromised or not? Anyway, I backed the MSE settings to the default.

   This morning Microsoft Security Essentials suddenly told Apache files are Trojan:Win32/Critet.BS and quarantined them, so Apache stopped on my server PC whose OS is Windows7 HE SP1. Although I needed to recover the service immediately, I had to take my mother to a hospital. Therefore the service must have been unavailable for about an hour.

everyday life

Search Console gave me “Security issues” again.


   Last night, I found Search Console gave me "Security issues(1)(2)(3)" again, when I logged on its HOME. This was the second times. Last time was on May 9.

   Both of them are not by something like malware but by my fault. orz

everyday life

I’ve updated to phpMyAdmin4.6.6.


   I’ve updated to phpMyAdmin4.6.6. After that, the new version gave me “OpenSSL error: error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length” at HOME when I logged in.
   This is maybe because of this 👉 $cfg[‘Servers’][$i][‘ssl_verify’].

   The page says “Disabling the certificate verification defeats purpose of using SSL. This will make the connection vulnerable to man in the middle attacks.”, but my SQL server and phpMyAdmin don’t accept accesses from outside of NAT router and the user is only me. So, as my temporal workaround, I added the next line to my

$cfg['Servers'][$i]['ssl_verify'] = false;

WordPress4.6 has come.


   Actually, I failed once. My Web Browser status bar told ‘done’, but the progressing page showed only two lines. Besides, the update marker didn’t have gone. So I tried again and had ‘Another update is currently in progress’.

   I accessed via FTP but couldn’t find .maintenance file. I looked for a solution on the internet and reached ‘Get rid of Another update is currently in progress’.


Remote Desktop Service


   I think someone has the same trouble. After the black Tuesday of October, I cannot use Remote Desktop to my server whose OS is Windows7 Home Premium (x86). Actually, I had not thought it was the black Tuesday before I found this fact (-_-;). Remote Desktop to Windows7 Home Premium, you can understand what I say, can’t you? I found this and this ( くりくりさん gave me the site might have some malicious links by his comment on the Japanese post. So I removed the link tag. I think it’s probably O.K. unless you make clicks on the linked site when you visit. But Prevention is better than cure. So, if you want the information, go to the site AT YOUR OWN RISK.) and tried their suggestion for enabling the feature again. But failed, and gave up. Oops!

   Honestly, it is very inconvenient that I cannot use Remote Desktop to the server. So I decided to use Chrome Remote Desktop instead. I don’t like another software installation that is not needed for the server itself, but I have no choice at this time (Sigh).


WordPress not auto saving all articles on my main site.

Update information      Edit(Sep.6)

   Recently the autosave feature wasn’t working well on though I cannot recall from when. o6asan’s soliloquy and o6asan’s soliloquy-part2 have no problem.

   Apart from this, I found a lot of “WordPress database error Duplicate entry ‘0’ for key ‘PRIMARY’ for query INSERT INTO `WordPress DB table name` ~” on the Apache error log when I checked the errors about php_opcache.dll on August 29.

   Yesterday, I suddenly remembered the errors on the Apache log, and began to get the solution. I saw a lot of sentences related to Notes when I looked into the log again. At the time, I first recognized this errors and autosave feature had a strong relationship. Besides, the errors began on August 23. I must have done something wrong at updating MariaDB. (-_-;)

   I saw what table names the log included, then found them out, i.e. `wp_postmeta`, `wp_posts`, `wp_redirection_logs`, `wp_sitemeta`. I logged in phpMyAdmin and compared wp_postmeta structure with wp_2_postmeta one. Because wp_2_postmeta has no problem. Finally I noticed wp_postmeta had no AUTO_INCREMENT in meta_id’s extra field. I also looked the rests had the same problem.

   First I backed all data up then tried and fixed them.

  1. Select wp_postmeta table.
  2. Select ‘Structure’ from Menu.
  3. Select ‘Change’ from Action of meta_id.
  4. Check ‘A_I’ box on and save.

   If you use CUI, I think you can use the following.
ALTER TABLE `your WP DB name`.`wp_postmeta` CHANGE `meta_id` `meta_id`

   I did this for `wp_postmeta` and `wp_posts` without difficulty. But for `wp_redirection_logs` and `wp_sitemeta`, I had the following error.
#1062: ALTER TABLE causes auto_increment resequencing, resulting in duplicate entry ‘1’ for key ‘PRIMARY’

   `wp_redirection_logs` table has just logs of the plugin Redirection. So I emptied the table and did the above steps again. If you use CUI, I think you can use the following.
TRUNCATE `your WP DB name`.`wp_redirection_logs`;

   But I need the contents of the table `wp_sitemeta`. So, I first emptied the table and did the above steps again. Then I clipped `wp_sitemeta` INSERT statement out from the back-up sql file and imported it to the table.

   The errors on the log file have gone and the autosave feature works well now. Mission complete!

   Don’t trust me too much because I handled the errors in my own fashion. m(_”_)m

   When I updated to BulletProof Security .50.8, I had a trouble that the Notice “Network/Multisite BPS plugin Network Activation correction:” had not gone away. So, I went talk to the forum. Then I resolved the problem with his help. This trouble is related to the AUTO_INCREMENT missing again. I think it is maybe caused by phpMyAdmin bug that I read several days ago. But who knows about the truth? Sigh.

   Anyway, the Notice has gone. Now I can sleep in peace (^_^;).


Memorandum #5.

Update information      Edit(Aug.28)
  1. I found their announcement of PHP 5.6.0 GA on the article about RC4, wow! I can’t wait.
  2. I updated Apache 2.4.10 ( which was built with openssl-1.0.1i. The reason is this advisory, OpenSSL Security Advisory [6 Aug 2014]. I knew this news but Steffen replied “Coming days the builds here at Apache Lounge are going to be upgraded. It has not that priority and severity ~” to Jan-E. So I waited to be upgraded.
  3. I read a lot of articles about the troubles with Windows Update 2014 Aug. Though I had no trouble with my own PCs, I uninstalled the following updates that were installed on my PCs. Because I heard they suggested to uninstall KB2982791, KB2970228, KB2975719 and KB2975331 even if currently no trouble.
    • Windows8.1(x86) on NJ2100
    • Windows7 SP1(x64) on CF-J10
    • Windows7 SP1(x86) on xw4200
    • Windows Vista SP2(x86) on KeyPaso

    In the past, Windows update gave us troubles almost every time, but I feel this was the first mess in quite a while. How about your feelings? (^_~)

   Hey! We have new MS14-045 update KB2993651. See Microsoft Security Bulletin MS14-045 – Important.


A solution of “SSL3_READ_BYTES:sslv3 alert handshake failure” on WordPress.


   Since WordPress that was version 3.7 had a ca-bundle.crt in its wp-includes folder, I’ve had troubles when I upgrade my WordPress Network. I misunderstood the message “Warning! Problem updating https://SITENAME.” meant one of my sites had a trouble, but now I think it meant the first site the WordPress checked out was wrong and the WordPress had no information about the rest of my sites.

   First I had the “Error message: SSL certificate problem: self signed certificate in certificate chain” because I use a self-signed certificate. But Oiram gave me its solution. All I need is to add my CA cert data to the ca-bundle.crt.

   Next I had the “Error message: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure”. I’ve had a hard time with this trouble for more than two months. Finally, I have the complete solution of this today \(^o^)/.

   I look back now and think the trouble had three issues.

  1. My client.crt had no ssl_client extension. so I re-made a client.crt with ssl_client extension like this. The reference of this is “sslv3 alert handshake failure when using SSL client auth”.
    First, I added the next text to the end of my openssl.cnf.

    [ ssl_client ]
    basicConstraints = CA:FALSE
    nsCertType = client
    keyUsage = digitalSignature, keyEncipherment
    extendedKeyUsage = clientAuth
    nsComment = “OpenSSL Certificate for SSL Client”

    And I made a new client.crt with ssl_client extension.
    >openssl ca -config openssl.cnf -policy policy_anything -extensions ssl_client -in client.csr -out client.crt

    • With the old client.crt, I had the next two errors when I did “openssl s_client -connect -cert client.crt -key client.key -CAfile cacert.pem”. But, the new one gives no error.
    • error:14094418:SSL routines:SSL3_READ_BYTES: ~
      error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure: ~
    • Of course I re-made a new clientcert.p12
  2. At “Upgrade Network”, WordPress uses cURL. But cURL doesn’t accept P12 format certificates. So I need PEM format certificates.
    • To make a clientcert.pem from the clientcert.p12
      >openssl pkcs12 -in clientcert.p12 -nokeys -clcerts -out clientcert.pem
    • To make a clientkey.pem from the clientcert.p12
      >openssl pkcs12 -in clientcert.p12 -nocerts -out clientkey.pem
      To make a copy of the clientkey.pem and remove the pass phrase from it.
      >copy clientkey.pem cp_clientkey.pem
      >openssl rsa <cp_clientkey.pem> clientkey.pem
  3. To tell my WordPress the places of the client certificates.
    • To add the following lines to just before the line “curl_setopt( $handle, CURLOPT_CAINFO, $r[‘sslcertificates’] );” in the file class-http.php.curl_setopt( $handle, CURLOPT_SSLCERT, 'the exact path of clientcert.pem' );
      curl_setopt( $handle, CURLOPT_SSLKEY, 'the exact path of clientkey.pem' );

      I hate to change WordPress core PHP scripts, so I try and try other methods, but nothing is useful. After all, I add the lines above to the class-http.php.

      To copy the clientcert.pem and the clientkey.pem to somewhere in the server, somewhere means a safer place anyone cannot access via the Internet.

    This reference is Client URL Library.

   If you need how to create certificates, see the post “WordPress: Administration Over SSL #1”.

   Now the error has gone. I’m happy, clap,clap!!


About Jetpack trouble.


   After moving to MariaDB, Jetpack suddenly gave me an error. I was not to able to connect my stats on from my parent site dashboard. As I could not solve this by myself, I went to Jetpack Support Forum and started the topic “Jetpack: site_inaccessible“. Three days later, I went to Japanese Forum and started “ルートサイトと昔のテストサイトのコンフリクト。” because I realized these two forums were complete different groups. But I was wrong. They belong to the same party. However, I did a multi-post because my writing was not enough (^_^;). Anyway, I had some suggestions from both of them.

  1. Jeremy Herve told me to use define( 'JETPACK_CLIENT__HTTPS', 'NEVER' );. But it did not work.
  2. Richard Archambault suggested me the issue might be related with SSL and told me to check my SITE_URL up. But, my SITE_URL was that meant no problem.
  3. naokomc told me at Stats Page it looked the owner had no dibs on the site when he could not connect to So, I thought again it might be related with SSL that Richard told me.
  4. Then, I tried connecting after commenting define( 'FORCE_SSL_ADMIN', true ); out. That worked, wow!!

   I got that the authorization might fail with define( 'FORCE_SSL_ADMIN', true ); on some conditions.

   After the connection to, I rolled define( 'FORCE_SSL_ADMIN', true ); back. It is O.K. after the Authorization even if define( 'FORCE_SSL_ADMIN', true ); is uncommented.

   I have never resolved in my mind why this suddenly happened. But, the issue solved.


Moving to MariaDB5.5.

Update information      Edit(Dec.21)    Edit2(Dec.25)    Edit3(2014.Jun.22)

MaintenanceNotice   Yesterday, I worked very hard. For what? Well, moving to MariaDB5.5 from MySQL on Windows7HP+SP1(x86). Haha.

   First, I backed up all the sever data.
   Next, I made a maintenance.html like the right, and for maintenance I added the next lines to the head of my .htaccess at the Document Root. The text in it is like the below. (refer to: mod_rewrite, <IfModule>)

     ErrorDocument 503 /maintenance.html

     RewriteEngine On
     RewriteCond %{REQUEST_URI} !=/maintenance.html
     RewriteCond %{REMOTE_ADDR} !=IP address for Admin
     RewriteRule ^.*$ – [R=503,L]

     Header set Retry-After “Wed, 18 Dec 2013 01:00:00 GMT”

   On the page, I found “This section should only be used if you need to have one configuration file that works whether or not a specific module is available. In normal operation, directives need not be placed in <IfModule> sections.”. So, I thought I did not need <IfModule> sections.

   Then, I announced the server maintenance on my sites and began moving to MariaDB5.5.

   I had a clean installation of MariaDB because I wanted to change my sql engine from MyISAM to InnoDB. When I started using MySQL, I made the tables by MyISAM. Recently, I heard about InnoDB merits several times. So I always wanted to move to InnoDB, but I also found someone was in troubles on moving to it on the Internet. Hence I have hesitated to make a move because I can NOT handle them if something wrong happens despite my poor knowledge about the sql.

   MariaDB has InnoDB as its default. So I was going to recreate all my tables on this occasion if necessary.

Step1 The uninstallation of MySQL.

  1. Deactivated all WordPress plugins on my sites.
  2. Backed all databases up separately from the sever data backup.
  3. Also exported all contents of my WordPress from the site Dashboard. Because I was going to import all contents by the WordPress Importer if possible. I gave it up as described below, though.
  4. Stop the service.
    Control Panel >> Administrative tools >> Services
    Select the MySQL service name and stop.
  5. Delete the service.
    Run a cmd.exe as an Administrator.
    > sc delete MySql
  6. Removed the folders, MySQL and MyDATA (<--- These are MySQL scripts and data on my server).

Step2 The installation of MariaDB.

  1. Downloaded from MariaDB.
  2. Running my eyes overInstalling MariaDB Windows ZIP packages, I went to the page about mysql_install_db.exe.
  3. Extracted the Zip archive. Made two folders named MariaDB and MyDB on my server ware partition named Drive_SV. Installed all things made by extract to the folder MariaDB.

    Run a cmd.exe as an Administrator.
    > cd Drive_SV:MariaDBbin
    > mysql_install_db.exe –datadir=Drive_SV:MyDB –service=MyDB –password=secret

    By this, I was able to set the password for the root user and had a new my.ini in the MyDB.

  4. Control Panel >> Administrative tools >> Services
    Select the MyDB service name and start
    If its ‘Startup Type’ is not ‘Automatic’, you should change it to ‘Automatic’.

Step3 Access MariaDB via phpMyAdmin.

  1. Accessed MyDB as the root user from phpMyAdmin.
    Imported one of my backup database, phpmyadmin.
  2. Made a WordPress User and gave it all WordPress database privileges except Grant and no Global privileges. Of course set a password for it. Made a database for the WordPress. Their collation is utf8_general_ci.

   Import by WordPress Importer and I gave it up. The reason is the below.

   After a new WordPress installation, I imported all contents by WordPress Importer. But unfortunately, I found the fact that the plugin neglected some tags like <object>, it was inconvenient for me. I don’t know it neglects what kind tags and to examine them by myself is too much trouble. Therefore, I gave up this method.

Step4 Restored all WordPress database via phpMyAdmin.

  1. I wanted to use the InnoDB, so I replaced all ‘ENGINE=MyISAM’ by ‘ENGINE=InnoDB’ in the backup sql file.
  2. Login as the WordPress User.
    Exported the current WordPress database.
    Dropped all tables on the WordPress table because my backup sql file contained all data.
  3. Imported the backup. I had an error like this.
         #1214 – The used table type doesn’t support FULLTEXT indexes

    The backup file was originally MyISAM, so it includes FULLTEXT indexes. Actually it uses by YARPP as keys of post_title and post_content. Hummm. But on the forum the plugin author says we can use YARPP on the InnoDB though its performance slows down.

    I removed all lines about FULLTEXT indexes in the file. (I remember I heard we can use FULLTEXT with InnoDB on MySQL5.6.–Dec.25Edit)

  4. Dropped all tables again.

    Imported the customized file. I had another error.
         #1064 – You have an error in your SQL syntax;

    This error was my fault. When I removed FULLTEXT indexes I forgot to remove a “,” like this.
         KEY `post_author` (`post_author`),   <<--------This is the ',' I forgot to remove.      ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ; I removed all such ','s.

  5. Dropped all tables again.

    Imported the customized file. Complete.

Step5 Back to normal condition.

  1. Login the WordPess.
    Activated all plugins.
    Checked all script behaviors.

    Change .htaccess text to end the maintenance.

  2. Actually, I still have an error about Jetpack on my parent site. Like this.

         Your website needs to be publicly accessible to use Jetpack: site_inaccessible
         Error Details: The Jetpack server was unable to communicate with your site https://MySITE
         [IXR -32300: transport error: http_request_failed SSL certificate problem: self signed
         certificate in certificate chain]

    But I think this is not the maintenance faults. Now I am waiting for a reply on the Jetpack forum.

   Now I use MariaDB5.5. Clap, clap.

   After I changed SQL Storage Engine from MyISAM to InnoDB, the plugin YARPP performance slowed down very much. It was more than my expecting. So, I decided to rollback the Engine about the table wp_posts by YARPP instruction message.

  1. Login phpMyAdmin.
  2. Select the database for WordPress.
  3. Select the table wp_posts.
  4. Select ‘Operations’ from the top navigation bar.
  5. Change Storage Engine from Innodb to MyISAM at Table options.
  6. Click Go button of Tabble options.
  7. Logout phpMyAdmin.

   But YARPP didn’t recognize this change, though the author have a specialized feature for this. I went to the YARPP support forum to find a solution. I found MyISAM Override check doesn’t work. I followed hussong‘s instructions.

  1. Deactivate the plugin.
  2. Login phpMyAdmin.
  3. Select the database for WordPress.
  4. Select the table wp_options.
  5. Select ‘SQL’ from the top navigation bar.
  6. Use SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%"
  7. Delete all I found.You can see yarpp_fulltext_disabled = 1. Change it to yarpp_fulltext_disabled = 0
  8. Logout phpMyAdmin.
  9. Activate the plugin.
  10. Setting the plugin again because all old settings gone.

Now, I can use Titles and Bodies consider options. Happy!

   I wrote “About Jetpack trouble“.

   I wrote an article The solution of “SSL3_READ_BYTES:sslv3 alert handshake failure” on WordPress.