If you’re attempting to upgrade the version of PIP on CentOS or RHEL 6 from the default 7.1.0 to a newer version, as of April 14th 2018 when PIP 10.0.0 was released you will run into issues since EL6 ships with Python 2.6 as standard. Since you cannot upgrade the default version of Python because it will break in-built tooling such as Yum, you’ll need to version lock PIP when you upgrade it to 9.0.3. This is the last stable version of PIP that is compatible with Python 2.6
If you are developing with a virtual machine or container, any modules installed by PIP will either be installed globally or potentially in a virtualenv location outside of the project root. Therefore you will need to tell PyCharm that the imported modules you’re using are located remotely, not locally.
First you will need to go into Preferences/Settings and to the Project specific settings, then into the Interpreter section.
You will then be able to add a Remote Interpreter, which will be the credentials required to log into your VM or container via SSH by PyCharm.
If you are using Vagrant then the location of the SSH key that can be used to login to the VM can be found by using the vagrant ssh-config command, which will output something like this.
The location of the SSH key used by the vagrant ssh command is by the IdentityFile key.
If PostgreSQL is set to only listen and allow connections from localhost (127.0.0.1) then you can change the configuration to allow other or all IP addresses to connect.
First we will need to make sure PostgreSQL is listening for connections outside of local networking in the main configuration, which should be located somewhere such as /etc/postgresql/9.x/main/postgresql.conf (where 9.x is whichever version you have installed) so just uncomment the listen addresses line
However to make sure that the IP address you’re connecting from is also allowed you’ll need to change /etc/postgresql/9.x/main/pg_hba.conf to either add each IP address or set it to all (0.0.0.0)
Depending on your operating system you will need to restart the PostgreSQL server (for example service postgresql restart)
MySQL 5.6 introduced password expiration, so the password on your Homestead Virtual Machine may expire at some point.
SQLSTATE[HY000]  Your password has expired. To log in you must change it using a client that supports expired passwords.
To change this you will need to log into MySQL running on Homestead in order to change your password to fix the expiry
vagrant ssh mysql -u homestead -psecret
If you try and execute most commands you will be greeted with
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
Confusingly you can’t run the ALTER USER statement until you’ve changed your password… so you need to use SET PASSWORD
SET PASSWORD = PASSWORD('new_password');
When configuring your Homestead VM you may encounter an SSH key issue when booting the Homestead Vagrant VM up
/home/vagrant/.ssh/authorized_keys ==> default: : No such file or directory
This can be fixed by nesting your mounted directory a level deeper under /home/vagrant/ as that is where the SSH keys of the box itself are stored and mounting your folders directory there can cause issues
Assuming you have a Vagrantfile setup to forward port 8080 and/or 8443 to the default http and https ports on the web server running in the Vagrant Virtual Machine guest, you can forward these ports to the normally reserved ports on your Mac OS X host
Add port forwarding configuration that references this rule
Once you have created both these files, to activate this rule run “sudo pfctl -ef /etc/pf-vagrant.conf”
If you prefer to use a client for MySQL such as Workbench, you can connect to the MySQL service in your Vagrant Virtual Machine by using SSH tunnelling. Run “vagrant ssh-config” to get the information you need to configure your client correctly.
vagrant ssh-config Host default HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /Users/akirkpatrick/Projects/api/puphpet/files/dot/ssh/id_rsa IdentityFile /Users/akirkpatrick/.vagrant.d/insecure_private_key IdentitiesOnly yes LogLevel FATAL
You should see 2 keys listed under IdentityFile, use the path of the first one (not the insecure one) as the location for your SSH Key File in a new Standard TCP/IP over SSH connection in Workbench or an equivalent client. The SSH connection will be over whichever port Vagrant is forwarding (usually 2222, see the Port from the ssh-config output) with the user “vagrant” and the MySQL connection details will be whatever credentials are allowed to connect from within the VM.
Being able to save a screenshot from Behat via one of it’s drivers is very useful to find out what went wrong, especially on headless browsers such as PhantomJS. Previously I’ve saved these to the filesystem as per a handy UCSF guide and updated myself for Behat 3.
However if you do not have easy access to the filesystem where Behat is being run, such as your Continuous Integration server (especially container-based solutions like Travis where it will get destroyed after each build) then it may be handy to upload it to somewhere and output the URL in your build logs. This is a quick solution for uploading to Imgur.
You will need to create an Imgur account and register your application to obtain a client ID.
Please note this is a quick and dirty example, as it should ideally use Guzzle to talk to the Imgur API and use external configuration, but since people may want to use different image hosting services or methods I left it fairly basic for now.
If you are using Behat with Selenium server and running locally, if is firing up real browser instances via web driver then it is easy to see what may be going wrong. However if you are using a headless browser such as PhantomJS this makes it impossible, unless you take screenshots when an error has occured (a failed step in your scenario)
I used a handy UCSF guide for taking screenshots with Behat 2 and updated it for Behat 3
If you have an application that you are trying to test locally (such as on a Vagrant VM) or on a development server that has a self-signed certificate, Behat will probably complain of an SSL certificate problem because of an invalid certificate chain (GuzzleHttp\Exception\RequestException)
If your application (or stack) is configured for https only at all times this means you can’t switch to http to test, since that would be testing configuration that is not representative of your live environment. To circumvent this you can disable SSL verification for cURL in Guzzle.