md5 на разных серверах (debian) - разные значения?

в редакторе скрытые символы

Git осиль или хотя бы просто хеш сырцов

Я пользуюсь Git.

Код идентичный, если речь об этом. diff ничего не показывает.

Чудес не бывает, проверять что md5 дает разные результаты я бы стал в последнюю очередь.

На вход

string(9) "key_cache"
array(8) (
    "from" => string(3) "KJA"
    "to" => string(3) "MOW"
    "from_date" => integer 1372708800
    "to_date" => integer 0
    "rt" => string(0) ""
    "passengers" => array(3) (
        "aaa" => string(1) "1"
        "rmg" => string(1) "0"
        "rbg" => string(1) "0"
    )
    "class" => string(6) "econom"
    "type" => string(7) "pricing"
)

Один сервер string(4) «hash» string(45) «9e8e0906125f77727303bf6ed7e6c5f7»

Другой сервер string(4) «hash» string(53) «921bed9c2a1e09ed562d19e1fbf799598e666659»

При чем на локалке код с обоих серверов выдает 921bed9c2a1e09ed562d19e1fbf799598e666659

Т.е. проблема в одном сервере. Куда копать?

ps. приведенные хеши изменены, чтобы не палиться :)

SHA1 не дает разницы.

Перевел код на sha1 () и разница пропала!

Проблема только в md5..

Array ( 
[from] => KJA 
[to] => MOW 
[from_date] => 1372708800 
[to_date] => 0 
[rt] => 
[passengers] => Array ( 
[rbg] => 0 
[rmg] => 0 
[ada] => 1 )

[class] => econom [type] => pricing )

83b1ec4404e4eeb5dc964a12c8125ea6276e6e25

Нет, SHA1 тоже выдала другой результат.. Вчера весь день убил на это, паника.

Т.е. string(45) и string(53) вас не смущает? У md5 фиксированная длина хэша.

фокус в настройках php =)

php одинаковой версии?

покажи это на обоих серверах ->

php.ini

session.hash_function

так же обрати внимание на session.hash_bits_per_character

string(45)

md5() всегда возвращает 32х символьное значение. Какой функцией генерится хеш?

Файлы переносились на третий сервер случайно не с помощью фтп?

При чем на локалке код с обоих серверов выдает 921bed9c2a1e09ed562d19e1fbf799598e666659

~$ echo -n '921bed9c2a1e09ed562d19e1fbf799598e666659' | wc -c
40

Тупые быдлокодеры, такие тупые.

ps. приведенные хеши изменены, чтобы не палиться :)

Он же очень скрытный, а ты не внимательный :)

Да-да, такой скрытный что нечаянно в 160 бит попал.

Это был SHA1. Для размышления над проблемой нужны конкретные примеры? Включи воображение, проблема описана, входные данные описаны. Сам ты тупой обмудок.

git clone

там разве что две разные ветки, но код строящий массив, который потом сериалайзится и отдается в md5 одинаковый.

Версии php были разные. На первом 5.4, на втором 5.3.

Сейчас привел к одной версии с dotdeb. Еще не проверял заработало ли.

Настройки сейчас посмотрю.

На первом и на втором сейчас идентичные, как было до обновления не знаю.

root@5 /var/log # cat /etc/php5/apache2/php.ini | grep hash_function
session.hash_function = 0
root@5 /var/log # cat /etc/php5/apache2/php.ini | grep hash_bits_per_character
; session.hash_bits_per_character
session.hash_bits_per_character = 5

Неужели md5 могло зависеть от версии php ? Ну очень маловероятно.

Неужели md5 могло зависеть от версии php ? Ну очень маловероятно.

я сталкивался с подобными вещами.

проблема описана

Судя по описанию, один сервер выдает md5, а другой sha1. Мило, чо.

Вот как строится массив в коде для ключа кеша

$key = array(
            'from'       => $from,
            'to'         => $to,
            'from_date'  => Date::dateconvert($request['from_date']),
            'to_date'    => $request['rt'] ? Date::dateconvert($request['to_date']) : 0,
            'rt'         => $request['rt'] ? '1' : '',
            'passengers' => $request['passengers'],
            'class'      => $request['class'],
            'type'       => $request['type'],
        );

from to вычисляются выше с бд, тут не может быть разночтений.

Date::dateconvert переводит входные даты в таймстамп. есть два варианта, например 01.07.2013 и 2013-07-01 - оба превращаются в одинаковый таймстамп.

Далее rt. Возможно стоило ставить 0 для наглядности. passengers массив вида

"aaa" => string(1) "1"
        "rmg" => string(1) "0"
        "rbg" => string(1) "0"

Остальное одинаково для запросов, формируется на входе.

Я не понимаю, в ответах вижу намеки на скрытые символы, но их тут просто не может быть. При чем СЕРИАЛАЙЗЫ которые поступают на md5 - ОДНАКОВЫЕ. Если бы была разница например в NULL и " то я бы увидел N или s:0 в сериалайзе, но нет такой разницы.

Нет, я вношу правки параллельно. Просто когда я писал пост, то уже тестировал sha1, скопировал частично. В общем это не имеет значения. Конкретные хеши не дополнят описание проблемы.

Конкретные хеши не дополнят описание проблемы.

Зато прекрасно вводят в заблуждение.

Мне не с руки было возвращать код обратно, чтобы скопировать правильные хеши.

При чем СЕРИАЛАЙЗЫ которые поступают на md5 - ОДНАКОВЫЕ

то я бы увидел

Лучше не смотреть, а сравнить. Если они действительно равны, то бинго, проблема найдена. Впрочем, если неравны, то тоже проблема очевидна.

Сейчас вресия одна, последняя с dotdeb, попробую еще раз. Напишу что будет.

У меня ту теще проблема началась. Ключи привел к единому виду ф-ей своей, однако если я пишу кеш в memcached с одного сервера (хоста), то он не читается по ключу с другого сервера (хоста). И наоборот.

Ключи вида sirena2000newKJA_MOW_1372708800_0__1_0_0_econom_pricing

формируются с тех же входных данных. они одинаковые.

В смысле сравнить? Я их открыл в логах и сравнил визуально глазами. Одинаковые.

Я их открыл в логах и сравнил визуально глазами. Одинаковые.

fail.

Вообще, первым делом ты должен был проверить md5 на простой строке, а не результате сериалайза.

Вы были правы.

Дело было в подмассиве passengers

"aaa" => string(1) "1"
        "rmg" => string(1) "0"
        "rbg" => string(1) "0"

В другом запросе, на другом сервере rmg и rbg менялись местами.

Невнимательность и жопа. :)

Всем спасибо за участие!