Is it applicable to you?

In case you see the error in browser

This site can’t provide a secure connection

yourdomain.com uses an unsupported protocol.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

And you’re using universal ssl certificate (when HTTPS provided by cloudflare) but there is no one in the list like on image below

seems like you are affected.

How to fix?

1. Go to your project in cloudflare and choose SSL/TLS -> Edge Certificates.

2. Scroll down to the block Disable Universal SSL. Here you can see the button Disable Universal SSL. Press the button.

3. Then press on button Enable Universal SSL.

Wait a bit and reload the page. After that you should see the universal certificate generated by Cloudflare. Wait until status will be Active.

Everything should work now. Good luck

Сообщение Cloudflare error: ERR_SSL_VERSION_OR_CIPHER_MISMATCH появились сначала на Блог Stafox'a.

Лог такой:

Warning: Erroneous data format for unserializing 'App\UserBundle\Entity\User' in project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php

Я нашел два способа исправления.

Обновить версию Doctrine

Обновить Doctrine до версии 2.4.x или выше. Однако не всегда это допустимо, в силу того, что что-нибудь может отвалиться. А исправить нужно здесь и сейчас

Изменить способ создания объекта без конструктора

Собственно причина проблемы – это способ, который использует Doctrine для создания объекта без вызова конструктора – десериализация данных.
Можно исправить метод newInstance() и создавать объект через рефлексию.

function newInstance()
{
    if ($this->_prototype === null) {
        if (method_exists($this->reflClass, 'newInstanceWithoutConstructor')) {
            $this->_prototype = $this->reflClass->newInstanceWithoutConstructor();
        } else {
            $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
        }
    }

    return clone $this->_prototype;
}

Сообщение Warning: Erroneous data format for unserializing ‘App\UserBundle\Entity\User’ появились сначала на Блог Stafox'a.

Отлично, ставим! Добавляем репозиторий (ага, unstable, чтобы со всеми последними фичами ) и устанавливаем:

sudo add-apt-repository ppa:kazam-team/unstable-series
sudo apt-get update
sudo apt-get install kazam

И запускаем. Но вот на этом этапе я словил ошибку (иначе не было бы этой статьи ).

~$ kazam
Traceback (most recent call last):
  File "", line 2135, in _find_spec
AttributeError: 'DynamicImporter' object has no attribute 'find_spec'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/kazam", line 147, in 
    from kazam.app import KazamApp
  File "/usr/lib/python3/dist-packages/kazam/app.py", line 36, in 
    from kazam.backend.prefs import *
  File "/usr/lib/python3/dist-packages/kazam/backend/prefs.py", line 30, in 
    from kazam.backend.webcam import Webcam
  File "/usr/lib/python3/dist-packages/kazam/backend/webcam.py", line 24, in 
    from gi.repository import GObject, GUdev
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 53, in find_module
    'introspection typelib not found' % namespace)
ImportError: cannot import name GUdev, introspection typelib not found

Из ошибки видно, что не хватает kazam’у для нормальной работы библиотеки typelib, которая есть в пакете GUdev. Окей, значит поставим его

sudo apt-get install gir1.2-gudev-1.0

Теперь заработало!

Сообщение Установка и запуск Kazam Screencaster в Ubuntu 14.04 появились сначала на Блог Stafox'a.

2015/08/24 18:50:02 [error] 17530#0: *40 upstream sent too big header while reading response header from upstream, client: 127.0.0.1, server: test.local, request: "GET /app_dev.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "test.local"

Решение: в nginx-конфиг для виртуального хоста необходимо добавить следующее в секцию server:

server {
...

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

...
}

fastcgi_buffers: Задаёт число и размер буферов для одного соединения, в которые будет читаться ответ, получаемый от FastCGI-сервера. По умолчанию размер одного буфера равен размеру страницы. В зависимости от платформы это или 4K, или 8K.

fastcgi_buffer_size: Задаёт размер буфера, в который будет читаться первая часть ответа, получаемого от FastCGI-сервера. В этой части ответа находится, как правило, небольшой заголовок ответа. По умолчанию размер одного буфера равен размеру страницы памяти. В зависимости от платформы это или 4K, или 8K, однако его можно сделать меньше.

Описание директив взято из документации модуля ngx_http_fastcgi_module.

Сообщение Ошибка nginx: upstream sent too big header while reading response header from upstream появились сначала на Блог Stafox'a.

Рассмотрим пример простого интеграционного теста на Zend Framework:

public function testValidateUserSuccess()
{
    $this->getRequest()
        ->setMethod('POST')
        ->setPost(array('username' => 'test', 'msisdn' => '375291234567'));

    $this->dispatch('/api/user/validate');
    $this->assertResponseCode(200);
}

public function testValidateUserFailure()
{
    $this->getRequest()
        ->setMethod('POST')
        ->setPost(array('username' => 'test', 'msisdn' => 'abc'));

    $this->dispatch('/api/user/validate');
    $this->assertResponseCode(400);
}

При выполнении данного набора тестов приложение будет запущено дважды, а значит дважды ининицализируются все методы Bootstrap‘а и Autoloader.
Один из вариантов решения – это запуск теста в отдельном процессе. Для этого необходимо добавить перед тестом @runInSeparateProcess.

/**
 * @runInSeparateProcess
 */
public function testValidateUserSuccess()
{
    ...
}

/**
 * @runInSeparateProcess
 */
public function testValidateUserFailure()
{
    ...
}

Можно запустить каждый тест в отдельном процессе, указав перед классом теста @runTestsInSeparateProcesses

/**
 * @runTestsInSeparateProcesses
 **/
class UserTest extends PHPUnit_Framework_TestCase
{
    public function testValidateUserSuccess()
    {
        ...
    }

    public function testValidateUserFailure()
    {
        ...
    }
}

Подводные камни

Во время запуска тестов я периодически ловил ошибку

RuntimeException: PHP Fatal error:  Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in -:36

Полный текст ошибки

PHPUnit 3.6.10 by Sebastian Bergmann.

Configuration read from /path/to/project/tests/phpunit.xml

E

Time: 0 seconds, Memory: 4.50Mb

There was 1 error:

1) UserTest::testValidateUserSuccess
RuntimeException: PHP Fatal error:  Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in -:36
Stack trace:
#0 -(36): serialize(Array)
#1 -(135): __phpunit_run_isolated_test()
#2 {main}
  thrown in - on line 36

Гуглил, нашел пару предположений:

• PHPUnit пытается все сложить в переменную $GLOBALS и ошибка возникает когда в тесте есть замыкания. Фикс: не использовать замыкания. Не мой вариант – у меня замыканий не было.
• Причина @runInSeparateProcess. Фикс: не используйте @runInSeparateProcess. Однозначно тоже не мой вариант.

Не сумев найти решения на просторах интернета, я решил обновить PHPUnit с 3.6.10 => 4.7.7 – помогло
P.S. совместимость Zend Framework 1.12.13 с PHPUnit 4.7 нормальная (несмотря на заявленную поддержку 3.7).

Сообщение Ошибка ‘Cannot redeclare class’ при запуске теста PHPUnit появились сначала на Блог Stafox'a.

Симптомы такие:

• при попытке открыть любой веб-сайт возникает ошибка DNS_PROBE_FINISHED_BAD_CONFIG;
• ping по имени хоста выдает ping: unknown host;
• Skype работает исправно;

Чтобы убедиться окончательно, что проблема точно в DNS, я попробовал открыть Google по IP: http://173.194.121.16/ – все отлично.

За сервера имен отвечает resolvconf. Попробуем запустить сценарии обновления:

В ответ получил следующее:

Окей, если resolvconf хочет видеть символическую ссылку, дадим ему ее.
Не забываем сделать копию файла resolv.conf (вообще, стоит приучить себя делать копию всего, куда вы собираетесь вносить изменения).

Теперь создадим символическую ссылку:

Еще раз запустим сценарии обновления серверов имен:

Должно заработать.

Сообщение Ubuntu ошибка DNS_PROBE_FINISHED_BAD_CONFIG в Chrome появились сначала на Блог Stafox'a.