Categorie: Linux

Categorieën
Hosting Linux PHP WordPress

WordPress e-mails SPF `neutral`

Veel WordPress website beheerders zullen wel eens meegemaakt hebben dat ze geen e-mailnotificatie kregen nadat een bezoeker een formulier had ingestuurd. Dit komt vaak doordat WordPress en het versturen van e-mails foutgevoelig is. Er kan namelijk op allerlei plekken iets fout gaan waardoor je als beheerder geen e-mailnotificatie binnen krijgt. In dit bericht zal ik een aantal scenario’s benoemen.

Formulieren plugin

Veel WordPress websites maken gebruik van een formulieren plugin. WordPress is namelijk standaard niet uitgerust met een formulieren functionaliteit. We maken bij Pronamic voornamelijk gebruik van de formulieren plugin Gravity Forms (affiliate link). Binnen Gravity Forms kunnen beheerders per formulier e-mailnotificaties instellen. Als een e-mailnotificatie niet binnen komt dan kan het zijn dat de e-mailnotificatie niet goed is ingesteld. Er is bijvoorbeeld een onjuist e-mailadres ingesteld of de e-mailnotificatie wordt alleen verstuurd bij bepaalde condities. Bij problemen is het daarom goed om altijd te controleren of e-mailnotificatie instellingen juist zijn. En of er misschien nog plugin updates beschikbaar zijn.

Standaard WordPress e-mail functie

WordPress is standaard uitgerust met een e-mail functie genaamd wp_mail(). Ontwikkelaars kunnen deze functie gebruiken voor het versturen van e-mails. Formulieren plugins zoals Gravity Forms maken vaak gebruik van deze functie. De wp_mail() functie maakt standaard gebruik van de PHPMailer bibliotheek. De PHPMailer bibliotheek maakt vaak weer gebruik van de PHP mail() functie. De PHP mail() functie roept vervolgens vaak weer de e-mail functionaliteit van het besturingssysteem aan. Binnen deze verschillende functies/technieken kan ook het één en andere fout gaan.

Maatwerk WordPress e-mail functie

De standaard WordPress e-mail functie kan door ontwikkelaars ook aangepast worden. Als iemand bijvoorbeeld geen gebruik wil maken van PHPMailer en/of de PHP mail() functie dan kan dat aangepast worden. Beheerders kunnen er bijvoorbeeld voor kiezen om e-mails te laten versturen door een e-mailprovider. Mijn collega Leo schreef op 29 februari 2016 in het bericht “4 gratis providers voor betrouwbare transactionele e-mails vanuit jouw WordPress website” hierover. Het voordeel van zo’n e-mailprovider is dat ze gespecialiseerd zijn in het versturen van e-mails. Deze partijen helpen je vaak ook om alle instellingen goed in te stellen.

  • Mandrill
  • SendGrid
  • Mailjet
  • MailGun
  • SparkPost
  • Postmark
  • SendinBlue

Toch kan er bij het gebruik van een e-mailproviders nog steeds van alles misgaan. Zo komt het soms voor dat WordPress niet goed kan communiceren met de betreffende e-mailprovider. Bijvoorbeeld doordat de e-mailprovider API even niet goed bereikbaar is. Daarnaast werken deze e-mailproviders vaak met abonnementen en limieten. Indien een limiet wordt bereikt kan het versturen van e-mails geblokkeerd worden. Verder zijn deze e-mailproviders vaak erg populair en werken ze met gedeelde IP-adressen. Doordat de diensten zo populair zijn komt het ook vaker voor dat hun IP-adressen op een blacklist staan.

SPF neutral

Om te testen of je WordPress installatie e-mails goed verstuurd kun je gebruik maken van de Check Email plugin van Chris Taylor en de mail-tester.com tool van MailPoet & AcyMailing. Via deze tools kun je controleren of e-mailbeveiliging technieken zoals SPF en DKIM goed zijn ingesteld. Op een website gehost bij SiteGround viel mij daardoor recent de volgende SPF-melding op:

spf=neutral (google.com: 69.175.69.92 is neither permitted nor denied by best guess record for domain of ********@esm35.siteground.biz) smtp.mailfrom=********@esm35.siteground.biz
Return-Path: <********@esm35.siteground.biz>

Het liefst zie je de spf=pass melding om meer zekerheid te hebben dat e-mails niet als ongewenst (spam) worden gezien. Na een zoektocht blijkt dat SiteGround standaard een @esm35.siteground.biz e-mailadres instelt als Return-Path. Hierdoor controleren e-mailservers of de server achter het esm35.siteground.biz adres wel e-mails mogen versturen namens de betreffende domeinnaam. Dit is neither permitted nor denied, dus niet toegestaan of geweigerd en daardoor neutral. Gelukkig kunnen we de Return-Path die SiteGround standaard instelt wel overschrijven. Tot 20 augustus 2016 deed WordPress dit standaard. Dit werd echter verwijderd omdat dit niet op alle hosting omgevingen goed werkt. Meer informatie hierover is te vinden in WordPress core Trac ticket 37736 (Git commit). Binnen een SiteGround hosting omgeving is dit echter geen probleem. De Return-Path kan bij SiteGround ingesteld via het php.ini bestand:

sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"

Eventueel kan ook de “wp_mail return-path” plugin van Barnaby Puttick gebruikt worden.

Categorieën
Linux Mac WordPress

Sublime Text 3 en SourceTree openen via command line (CLI)

Als WordPress ontwikkelaar maak ik veel gebruik van de command line. Tijdens het ontwikkelen van WordPress oplossingen werk ik namelijk veel met command line tools zoals git, npm, grunt, gulp, composer, etc. Andere zaken regel ik weer liever via een app. Gelukkig kunnen deze vaak ook eenvoudig via de command line opgestart worden. Voor Sublime en SourceTree gebruik ik daarvoor de volgende commando's:

Sublime Text 3

➜ wp-pronamic-ideal git:(develop) subl .

SourceTree

➜ wp-pronamic-ideal git:(develop) stree .

Deze commando's openen automatisch Sublime Text 3 of SourceTree met de huidige project map. Hoe je deze commando's beschikbaar kunt maken is te lezen in de volgende artikelen:

Categorieën
Hosting Linux WordPress

WordPress network/multisite cron vervangen met Linux cron SiteGround

Veel WordPress ontwikkelaars zijn geen fan van de standaard WordPress cron functionaliteit. Vaak wordt daarom geadviseerd om de WordPress cron te vervangen met een Linux cron. De meeste artikelen adviseren om in wp-config.php de WordPress uit te schakelen via define( 'DISABLE_WP_CRON', 'true' ); en via cPanel of DirectAdmin een Linux cron in te stellen:

/usr/local/bin/php /home/user/public_html/wp-cron.php

Voor een eenvoudige WordPress installatie werkt dit vaak goed, maar binnen een WordPress network/multisite installatie wordt het vaak al lastiger. Als je je website host bij SiteGround is dit echter ook een fluitje van een cent. De volgende WP-CLI commando komt hier namelijk goed bij van pas:

wp site list --path=/home/user/public_html --deleted=0 --field=url | xargs -I {} wp cron event run --due-now --path=/home/user/public_html --quiet --url={}

Bovenstaand commando bestaat eigenlijk uit 2 commando’s, één voor het opvragen alle sites en één voor het uitvoeren van de verlopen cron events:

  1. wp site list --path=/home/user/public_html --deleted=0
  2. wp cron event run --due-now --path=/home/user/public_html --quiet --url={}

Met behulp van het xargs command geven we de output van het eerste commando door aan het tweede commando. Op die manier worden de verlopen cron events van alle (niet verwijderde) websites uitgevoerd.

Resources

Categorieën
Linux Mac PHP WordPress

Homebrew, PHP 7.1 en cURL error 56: SSLRead() return error -9806

Na het installeren van PHP 7.1 via Brew kreeg ik via de WordPress HTTP API soms de volgende foutmelding te zien:

cURL error 56: SSLRead() return error -9806

Ik was deze fout wel vaker tegen gekomen, maar het is altijd weer even zoeken naar de oplossing. Het belangrijkste is dat er gewerkt wordt Homebrew curl en openssl:

brew uninstall git
brew uninstall curl

brew install openssl
brew install libressl

brew install curl --with-openssl

brew install php71 --with-homebrew-curl --with-homebrew-libressl --build-from-source
brew install php71-xdebug
brew install php71-mcrypt

Verder zijn ook de volgende Homebrew packages handig om te installeren:

brew install svn

brew install git --with-brewed-curl --with-brewed-openssl --with-brewed-svn --without-completions
brew install git-ftp
brew install git-flow

brew install composer
brew install php-code-sniffer
brew install phpmd
brew install phpunit
brew install phpmyadmin

Update 29 augustus 2017

Bovenstaande commando’s lijken het probleem niet altijd op te lossen. Eventueel kan onderstaande dan geprobeerd worden:

brew reinstall curl --with-openssl

De Homebrew curl formule is ‘keg-only’, maar om er zeker van te zijn dat Homebrew curl formule gebruikt wordt linken we deze wel:

brew link curl --force

Ook zorgen we er voor dat de Homebrew curl formule gebruikt wordt in de shell:

echo 'export PATH="/usr/local/opt/curl/bin:$PATH"' >> ~/.zshrc

Als het goed is geeft het volgende commando nu het volgende resultaat:

curl --version
curl 7.55.1 (x86_64-apple-darwin16.7.0) libcurl/7.55.1 OpenSSL/1.0.2l zlib/1.2.8 libssh2/1.8.0
Release-Date: 2017-08-14
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

Met name de OpenSSL/1.0.2l is hierbij belangrijk. Daarna gaan we PHP 7.1 opnieuw installeren met Homebrew curl:

brew reinstall php71 --with-homebrew-curl

Als het goed is geeft het volgende commando nu het volgende resultaat:

php -i | grep "SSL Version"
SSL Version => OpenSSL/1.0.2l

Bronnen

Categorieën
Linux SQL

Problemen met MariaDB versie 10.1.16 op OS X El Capitan

In het bericht “Problemen met MariaDB versie 10.1.8 op OS X El Capitan” schreef ik al eerder over problemen met MariaDB. Inmiddels heb ik MariaDB bijgewerkt naar versie 10.1.16 met behulp van Brew. Helaas kreeg ik nu ook weer fouten bij het opstarten van MariaDB:

➜  ~ mysqld
2016-07-27  9:12:38 140735199690752 [Note] mysqld (mysqld 10.1.16-MariaDB) starting as process 7611 ...
2016-07-27  9:12:38 140735199690752 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: The InnoDB memory heap is disabled
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Memory barrier is not used
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Compressed tables use zlib 1.2.5
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Using SSE crc32 instructions
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Completed initialization of buffer pool
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Highest supported file format is Barracuda.
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: 128 rollback segment(s) are active.
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Waiting for purge to start
2016-07-27  9:12:38 140735199690752 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.30-76.3 started; log sequence number 3504876906
2016-07-27  9:12:38 123145313034240 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-07-27  9:12:38 140735199690752 [Note] Plugin 'FEEDBACK' is disabled.
2016-07-27  9:12:38 140735199690752 [Note] Recovering after a crash using tc.log
2016-07-27  9:12:38 140735199690752 [ERROR] Recovery failed! You must enable all engines that were enabled at the moment of the crash
2016-07-27  9:12:38 140735199690752 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}
2016-07-27  9:12:38 140735199690752 [ERROR] Can't init tc log
2016-07-27  9:12:38 140735199690752 [ERROR] Aborting

Dit keer kon ik het probleem echter oplossen door het tc log bestand te verwijderen:

mv /usr/local/var/mysql/tc.log /usr/local/var/mysql/tc.log.bak

Hier na kon ik MariaDB zonder problemen opstarten:

➜  ~ mysql.server start
Categorieën
Hosting Linux WordPress

Savvii VPS productie en staging

Gebruikers van een Savvii VPS hebben de mogelijkheid om SSH toegang te krijgen. Dit kan erg handig zijn om bijvoorbeeld snel een backup te maken of een kopie te maken van een website. Voor het opzetten van een nieuwe actuele staging omgeving kun je als volgt te werken gaan:

Productie | staging

Allereerst is het handig dat productie en staging omgevingen met elkaar kunnen communiceren via SSH. Hiervoor is het handig om een nieuwe SSH key aan te maken op de productie omgeving en deze toe te voegen aan de staging omgeving.

Productie

ssh [email protected]

ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/pronamic_rsa

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/pronamic_rsa

Localhost

scp [email protected]:~/.ssh/pronamic_rsa.pub ~/Downloads/pronamic_rsa.pub

scp ~/Downloads/pronamic_rsa.pub [email protected]:~/tmp/pronamic_rsa.pub

Staging

ssh [email protected]

cat ~/tmp/pronamic_rsa.pub >> ~/.ssh/authorized_keys

rm ~/tmp/pronamic_rsa.pub

Productie » staging

ssh [email protected]

cd ~/wordpress/current

echo "wp-config.php" > staging-exclude.txt
echo "wp-content/infinitewp/backups" >> staging-exclude.txt
echo "wp-content/mu-plugins" >> staging-exclude.txt
echo "wp-content/mysql" >> staging-exclude.txt
echo "wp-content/uploads/2002" >> staging-exclude.txt
echo "wp-content/uploads/2003" >> staging-exclude.txt
echo "wp-content/uploads/2004" >> staging-exclude.txt
echo "wp-content/uploads/2005" >> staging-exclude.txt
echo "wp-content/uploads/2006" >> staging-exclude.txt
echo "wp-content/uploads/2007" >> staging-exclude.txt
echo "wp-content/uploads/2008" >> staging-exclude.txt
echo "wp-content/uploads/2009" >> staging-exclude.txt
echo "wp-content/uploads/2010" >> staging-exclude.txt
echo "wp-content/uploads/2011" >> staging-exclude.txt
echo "wp-content/uploads/2012" >> staging-exclude.txt
echo "wp-content/uploads/2013" >> staging-exclude.txt
echo "wp-content/uploads/2014" >> staging-exclude.txt
echo "wp-content/uploads/2015" >> staging-exclude.txt
echo "wp-content/uploads/backwpup*" >> staging-exclude.txt
echo "wp-content/uploads/gravity_forms" >> staging-exclude.txt
echo "wp-content/uploads/sites" >> staging-exclude.txt

# wp db export current.sql
mysqldump --user=user1 --password=******** --add-drop-table user1 > current.sql

rsync -avuz --exclude-from=staging-exclude.txt . [email protected]:~/wordpress/current

Het staging-exclude.txt bestand kun je in principe eenmalig aanmaken en in bijhouden welke mappen niet mee hoeven naar de staging omgeving. In bovenstaand voorbeeld heb ik veel uploads mappen uitgesloten.

Staging omgeving

ssh [email protected]

cd ~/wordpress/current

# wp db reset
# wp db import current.sql
# wp search-replace 'http://user1.savviihq.com' 'http://user2.savviihq.com'

mysql --user=user2 --password=******** user2 < current.sql

WP-CLI

Helaas werkt WP-CLI momenteel niet op onze Savvii VPS’en. Hierdoor is het exporteren en importeren van de database nog wat omslachtig. Met WP-CLI zou dit vereenvoudig kunnen worden wp db export, wp db reset, wp db import en wp search-replace.

Resources

Categorieën
Linux Mac SQL

Problemen met MariaDB versie 10.1.8 op OS X El Capitan

Na het updaten van MariaDB via Brew naar versie 10.1.8 had ik problemen met het opstarten van de MySQL server.

~  mysqld
2015-10-28 10:45:19 140735257919488 [Note] mysqld (mysqld 10.1.8-MariaDB) starting as process 1069 ...
2015-10-28 10:45:19 140735257919488 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Memory barrier is not used
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Compressed tables use zlib 1.2.5
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using CPU crc32 instructions
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Completed initialization of buffer pool
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Highest supported file format is Barracuda.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The log sequence numbers 2407038528 and 2407038528 in ibdata files do not match the log sequence number 2407038728 in the ib_logfiles!
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Database was not shutdown normally!
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Starting crash recovery.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Restoring possible half-written data pages
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: from the doublewrite buffer...
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: 128 rollback segment(s) are active.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Waiting for purge to start
2015-10-28 10:45:19 7000008b1000  InnoDB: Assertion failure in thread 123145311424512 in file btr0cur.cc line 5341
InnoDB: Failing assertion: rb_ctx != RB_NONE
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
151028 10:45:19 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.8-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467104 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48000
0   mysqld                              0x000000010f93bd21 my_print_stacktrace + 61
0   mysqld                              0x000000010f3dfffc handle_fatal_signal + 632
0   libsystem_platform.dylib            0x00007fff9501552a _sigtramp + 26
0   ???                                 0x0000000000000009 0x0 + 9
0   libsystem_c.dylib                   0x00007fff9f50237b abort + 129
0   mysqld                              0x000000010f782e39 _ZL28btr_check_blob_fil_page_typemmPKhm + 0
0   mysqld                              0x000000010f8cf80d _Z14row_purge_stepP9que_thr_t + 2334
0   mysqld                              0x000000010f8a2a1a _Z15que_run_threadsP9que_thr_t + 822
0   mysqld                              0x000000010f8f9862 _Z9trx_purgemmb + 2812
0   mysqld                              0x000000010f8eccb1 srv_purge_coordinator_thread + 2484
0   libsystem_pthread.dylib             0x00007fff94b169b1 _pthread_body + 131
0   libsystem_pthread.dylib             0x00007fff94b1692e _pthread_body + 0
0   libsystem_pthread.dylib             0x00007fff94b14385 thread_start + 13
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Aangezien ik geen MariaDB/MySQL expert ben heb ik niet de oorzaak van dit probleem kunnen vinden. Gelukkig kun je met Brew eenvoudig terug naar een oudere versie.

brew switch mariadb 10.0.21

Hiermee was het probleem direct opgelost.

Categorieën
Linux Mac PHP

Brew update PHP 5.6 tidy: Unable to initialize module

Na het update van Brew pakketten liep ik tegen de volgende foutmelding aan:

PHP Warning: PHP Startup: tidy: Unable to initialize module
Module compiled with build ID=API20131226,NTS
PHP compiled with build ID=API20131226,NTS,debug
These options need to match
 in Unknown on line 0

Dergelijke problemen zijn vaak eenvoudig op te lossen door pakketten even opnieuw te installeren vanuit de bron:

brew reinstall php56-tidy --build-from-source
Categorieën
Linux PHP WordPress

HostGator cURL outdated, disappointing support

Today i came in contact with an Pronamic IDEAL plugin user who was getting “Problem with the SSL CA cert (path? access rights?)” errors. The website was hosted at HostGator and after a quick Google search I noticed that more WordPress users had similar issues. The problems are caused by an outdated cURL library version 7.19.7. I requested HostGator to update to the latest stable version of cURL but their support doesn’t really help.

I think it’s very clear that the cURL library is outdated and needs an update. HostGator support however requires me to send the billing details of our client. How will the billing details help to get cURL updated? Since I don’t have these details HostGator support is not really helping. The helpdesk also forwarded me to their “What Software and Program Versions Does HostGator Offer?” page. On this page HostGator clients can read that they run cURL version 7.15.x:

cURL 7.15.x (also libcurl and PHP/CURL)

Right after that the helpdesk is saying:

We do our best to keep software and program versions as up to date as possible. Our technical team regularly evaluates software updates and pushes updates across HostGator’s servers as they are deemed secure and appropriate for HostGator’s shared hosting environment.

How credible is that since cURL version 7.15 was launched 8.9 years ago? Below you can find the whole chat conversation with HostGator. I don’t have further experience with HostGator but my advice would be to not host at HostGator.

Chat ID: 14642039.
Question: Problem with the SSL CA cert (path? access rights?)

(1:30:55pm) System: Customer has entered chat and is waiting for an agent.

(1:31:49pm) William L.: Hello and welcome to Hostgator LiveChat. My name is William and I’d be glad to assist you with any questions you may have today. How are you?

(1:33:29pm) Remco: Hello William, i’m good. Only have an issue on http://**********.com/ with remote request to an https:// URL. We use WordPress and are getting an HTTP request failed error.

“Problem with the SSL CA cert (path? access rights?)

(1:34:11pm) Remco: Did soms research on Google and see other users of Hostgator had also this issue

(1:34:14pm) Remco: https://wordpress.org/support/topic/http-error-problem-with-the-ssl-ca-cert-path-access-rights

(1:34:18pm) Remco: https://wordpress.org/support/topic/http-error-problem-with-the-ssl-ca-cert-path-access-rights-1

(1:34:47pm) Remco: I quote: “Asking Hostgator to update CURL to the latest stable version will fix this issue, it’s an easy thing for a host to do. A hosting company that size should know what to do..”

(1:35:45pm) William L.: For security reasons, before I am allowed to make changes or provide information to a user’s account, I am required to verify that this is the owner of the account. Please enter your billing login information in the verification box. Thank you.

(1:37:15pm) Remco: I’m not the owner of this account, i’m contacting you on behalf of our client. She however already had contact about this earlier.

(1:37:16pm) William L.: May I have your primary email address on account please?

(1:37:39pm) William L.: Unfortunately, in order to further investigate, I will need full verification in order to proceed to look into this.

(1:38:51pm) Remco: Our client doesn’t have an technical background… so it’s a bit hard for her to give you all the details. I think it’s clear that you have to update the cURL library. I don’t see why you need full verification for this…

(1:39:45pm) William L.: Okay. Regardless, I would still need the full verification details so I can pull up your account, as well as seeing if there is a SSL installed on the site itself.

(1:40:03pm) William L.: I apologized for the trouble but it would be required.

(1:40:14pm) William L.: All i need would only be the email address on account and the password.

(1:40:38pm) Remco: Ok, i have the e-mailadress ******@**********.com

(1:40:55pm) Remco: And the following details

(1:40:58pm) Remco: https://*********.hostgator.com:2083 <https://*********.hostgator.com:2083/>
User: ********
Password: ***********

(1:41:23pm) William L.: May I have your account security pin please? It is a 4 to 8 digits when you first registered for this account.

(1:42:01pm) Remco: I don’t have that information, you just said you would only need the email address and the password :).

(1:42:29pm) William L.: The password would refer to the billing password.

(1:42:31pm) William L.: Do you have that as well?

(1:42:36pm) William L.: If so, I will re-send the pop up box.

(1:42:45pm) William L.: The security pin is an alternative method of verifying for the account fully.

(1:42:50pm) Remco: Nope, this is all the information i have.

(1:43:03pm) William L.: Sure. Let me see what I can do with those information. Just a moment.

(1:45:18pm) William L.: May I ask what plugin are you attempting to use for the remote request to the HTTPS:// URL?

(1:46:01pm)Remco:The “Pronamic iDEAL” plugin… for an Dutch payment provider connection

(1:46:25pm) William L.: Thank you, Remco.

(1:46:31pm) William L.: Please bear me with a few minutes over here.

(1:50:36pm) William L.: In order to update curl, unfortunately you would need root access to complete this. As such you will want to look into upgrading to a VPS ( http://www.hostgator.com/vps-hosting/ ) or dedicated server ( http://www.hostgator.com/dedicated ) if this is something that is mission critical for you. I apologize for any inconvenience this has caused you.

You would either need to contact with the plugin developer in regards of such issue or update your server package to a VPS or a dedicated server in order to update cURL to the latest and stable version.

(1:52:52pm) Remco: Hmm, and why don’t you update cURL on this server to the latest and stable version? There is a bug in cURL version 7.19.7 so i think it’s your responsibility to update to fix the issue.

(1:55:16pm) William L.: I will be able to request of such for you. However, in order to do so, I will need to fully verify you. Are you able to obtain the billing password, or security pin?

(1:57:35pm) Remco: I probably can obtain this information, but again i don’t see why you need this. The cURL library is outdated, you guys just have to update. Version 7.19.7 o cURL was launched in 2009, we are now 2015. Can you guarantee an update if i get this billing password?

(1:58:23pm) William L.: I will not be able to guaranteed anything as this task will be performing by our support admin, which is why verification is mandatory prior to updating curl since we are going to be performing change on account.

(2:00:38pm) Remco: Hmm, this approuch is not very client friendly… it will only delay an solution… and you can’t even guarantee an solution… since it’s very clear that the cURL library is outdated…

(2:01:54pm) William L.: http://support.hostgator.com/articles/hosting-guide/hardware-software/what-software-and-program-versions-does-hostgator-offer

cURL 7.15.x (also libcurl and PHP/CURL)

We do our best to keep software and program versions as up to date as possible. Our technical team regularly evaluates software updates and pushes updates across HostGator’s servers as they are deemed secure and appropriate for HostGator’s shared hosting environment.

(2:03:54pm) Remco: That’s not really credible, cURL version 7.15 was launched 8.9 years ago. And still you say you do your best to keep software and program version as up to date as possible?

(2:04:03pm) William L.: Okay.

(2:04:08pm) William L.: I am sorry for the frustration.

(2:04:31pm) William L.: If you would like to proceed, please provide the billing details as the verification method and I would have this ticket generate for you so that our admins can work on it.

(2:05:59pm) Remco: I don’t have that information now, i think you have enough details to proceed anyway…

(2:06:47pm) William L.: Remco, please understand I am attempting to assist with you. However, without the verification details, I will not be able to proceed. You can always contact us when you do have the information and we will be glad to generate the ticket for you.

(2:10:00pm) William L.: I hate to bother, are you still with me?

(2:10:14pm) Remco: Ok, i’m disappointed in the way you handle this. I will ask my client to mail you this conversation so you can proceed and hopefully fix this issue asap. I will also recommend to consider switching to another hosting company.

(2:11:19pm) William L.: I am very sorry in regards of such experience you are currently experiencing. Please understand that we take account’s security matter very seriously hence the verification process before we perform changes on account.

Is there anything else you might need assistance with?

(2:12:54pm) Remco: I understand you take account’s security matter very seriously… maybe you contact the client yourself and make sure the problem is solved… i really think your client would appreciate that!

(2:13:19pm) William L.: Absolutely. I understand. May I ask if you have any further question for me today?

(2:15:37pm) William L.: This chat will now be terminated due to inactivity. If you need anything else, please start a new live chat session. We would be glad to assist you further. Take care and have a great day!

(2:15:42pm) System: This chat has ended. Click Rate And Exit to rate the representative and our company!

After this our client contacted HostGator for the cURL update, their response:

Hello, and thank you for contacting HostGator.com,

We maintain the same version of cURL across all of our shared servers. Unfortunately, we are unable to upgrade cURL for only your account as it would affect our other customers and their sites on the server. If you need an different version of cURL, you will need to upgrade to either a VPS or a dedicated server. We recommend these for our customers who are wanting specialized setups or different versions of software on their server.

If you are interested in upgrading, I would suggest looking ove rthe types of hosting that we offer: http://support.hostgator.com/articles/hosting-guide/hosting-plan-comparison/shared-environment-vs-dedicated-environment

http://support.hostgator.com/articles/hosting-guide/hosting-plan-comparison/articles/hosting-guide/hosting-plan-comparison/how-do-i-choose-which-hosting-plan-is-right-for-me

Read more about why you need to avoid HostGator on https://yoast.com/avoid-hostgator/.

Categorieën
Linux Mac SQL

Homebrew MariaDB MySQL server has gone away

Bij het importeren van een grote WordPress database in mijn lokale MariaDB database server liep ik tegen de volgende fout aan:

ERROR 2006 (HY000) at line 40786: MySQL server has gone away

Na wat zoeken op internet kom je al snel berichten tegen dat dit te maken heeft met de ‘max_allowed_packet‘ configuratie instelling.

Na wat zoeken heb ik in mijn gebruikersmap (~) een MySQL configuratie bestand (~/.my.cnf) aangemaakt volgens de MariaDB documentatie.

https://mariadb.com/kb/en/mariadb/documentation/getting-started/configuring-mariadb-with-mycnf/#location-in-linux-unix-mac

Door hier het volgende in te zetten is de ‘max_allowed_packet’ instelling eenvoudig te verhogen.

[mysqld]
max_allowed_packet=1073741824

Vervolgens kan MariaDB database server eenvoudig herstart worden met behulp van het volgende commando:

mysql.server restart