23 февраля 2015

Будьте внимательны при апгрейде Nginx + PHP-fpm в Debian Jessie

При обновлении хоста с Debian Jessie столкнулся с полностью нерабочими PHP сайтами после завершения апгрейда сервера. На любой запрос php скрипта веб-сервер просто отвечает HTTP 200 и отдает пустую страницу. Никаких ошибок в логе Nginx не было.

Сайты содержали следующий кусок конфига:

location ~ \.php$ {

  # skipped lines

  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_index index.php;
  include fastcgi_params;
}

В процессе дебага выяснилось, что из файла /etc/nginx/fastcgi_params выкинули объявление параметра SCRIPT_FILENAME и из-за этого интерпретатору срывает крышу. Случилось это в районе версии 1.6.1-2:

  * debian/conf/fastcgi_params:
    + Sync with upstream and remove `SCRIPT_FILENAME` parameter.
      This change might break fastcgi sites. (Closes: #718639)
  + debian/conf/fastcgi.conf:
    + Ship upstream file.

Теперь в Nginx включен пример конфигурации для PHP-fpm (/etc/nginx/snippets/fastcgi-php.conf)

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

P.S. Особая благодарность создателям socat - он мой новый лучший друг в вопросах отладки. Достаточно запустить

socat -v UNIX-LISTEN:/tmp/php5-debug.sock UNIX-CONNECT:/var/run/php5-fpm.sock

и перенастроить Nginx на подключение к /tmp/php5-debug.sock, как становится виден процесс общения Nginx и PHP-fpm, а соответственно и суть проблемы.

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

Нам недолго осталось до появления терминатора

Анонсировали ядро 4.0-rc1.


Судя по картинке из последнего терминатора - нам недолго осталось ждать (в терминале просматривается версия "4.1.15-1.1381_SKYN12nnmp).

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

19 февраля 2015

Iceweasel под следствием

Сегодня убил пол-часа времени, пытаясь понять почему одна и та же страница на сайте по-разному отображается в у меня Iceweasel 35.0.1 и в Firefox 35.0.1 у соседа.

Вот так страницу видел я:



Обратите внимание на различия кнопки "Site >>" в верхнем и нижнем блоках.

Засучив рукава я первым делом забэкапил ~/.mozilla, чтобы в случае чего вернуться в исходную точку. Пробую очистить кеш браузера, открыть страницу в анонимном режиме - бесполезно.

Качаю Firefox 35.0.1 с сайта mozilla и получаю ровно ту же картину. Значит дело не в разнице Iceweasel/Firefox.

Пробую создать чистый профиль - в чистом профиле страница выглядит правильно, значит что-то с настройками лисы, либо гадит какое-то из расширений. Перспектива начать "с нуля" с чистым профилем мне совсем не понравилась - сходу не знаю, как перенести сохраненные пароли в чистый профиль (хотя наверное тут поможет Firefox sync).

Продолжаю дебажить и попадаю в "Troubleshoting information"


Тут мое внимание привлекла кнопочка "Refresh Iceweasel". А чем черт не шутит?! Ведь бэкап все равно есть - жму и через пару секунд получаю полностью рабочий браузер в котором сохранились все закладки, пароли и даже залогиненые сессии не оборвались. Успех!

Интересно конечно, что же было исправлено, но главное что все работает. Делаю еще один скриншот и ради интереса открываю их рядом


и вот теперь до меня доходит, что один и тот же элемент на старом скриншоте крупнее, чем на новом - масштабирование?! Быстренько восстанавливаю профиль из бэкапа и жму Ctrl+0 - страница магически приходит в порядок. А чтоб вас с вашим userfriendly дизайном! Наверное я когда-то поскролил эту страницу, случайно зажав Ctrl и масштаб изменился. В новом дизайне не так то просто заметить, что страница масштабирована.

Короче смешанные чувства.

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

18 февраля 2015

Не монтируется NTFS через ntfs-3g после свежей установки Wheezy

После свежей установки Debian Wheezy на ноутбуке жены перестали монтироваться флешки с NTFS через ntfs-3g. При попытке подключить файловую систему выдает

$ ntfs-3g /dev/sdb1 mnt
Unprivileged user can not mount NTFS block devices using the external FUSE
library. Either mount the volume as root, or rebuild NTFS-3G with integrated
FUSE support and make it setuid root. Please see more information at
http://tuxera.com/community/ntfs-3g-faq/#unprivileged

При этом права на блочное устройство флешки и соответствующие группы есть:

$ ls -l /dev/sdb1
brw-rw---T 1 root floppy 8, 17 Фев 18 09:22 /dev/sdb1

$ id
uid=1000(ann) gid=1000(ann) группы=1000(ann),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),111(fuse)

На всякий случай заглянул в /etc/fstab - а там есть запись для /dev/sdb1, которая скорее всего и создает проблемы. Удалил строку и теперь монтирование работает как нужно.

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

04 февраля 2015

GnuPG key transition statement

I am transitioning my GPG key from an old 1024-bit DSA key to a new 4096-bit RSA key. The old key will continue to be valid for some time but I prefer all new correspondance to be encrypted with the new key, and will be making all signatures going forward with the new key.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I am transitioning my GPG key from an old 1024-bit DSA key to a new
4096-bit RSA key. The old key will continue to be valid for some time
but I prefer all new correspondance to be encrypted with the new key,
and will be making all signatures going forward with the new key.

This transition document is signed with both keys to validate the
transition.

If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
reauthenticating me.

The old key, which I am transitional away from, is:

  pub   1024D/2EE7EF82 2008-08-21
      Key fingerprint = ACBE C1C1 FC07 5E80 359A  7CC2 FE27 2604 2EE7 EF82

The new key, to which I am transitioning, is:

  pub   4096R/373FD74C 2015-02-04
      Key fingerprint = 5157 8DEB 9835 A355 118E  F244 3858 64F9 373F D74C

To fetch the full new key from a public key server using GnuPG, run:

  gpg --keyserver pgp.mit.edu --recv-key 373FD74C

If you have already validated my old key, you can then validate that
the new key is signed by my old key:

  gpg --check-sigs 373FD74C

If you then want to sign my new key, a simple and safe way to do that
is by using caff (shipped in Debian as part of the "signing-party"
package) as follows:

  caff 373FD74C

Please contact me via e-mail at  if you have any
questions about this document or this transition.

    Andrey Tataranovich
    tataranovich@gmail.com
    2015-02-04
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJU0h08AAoJEDhYZPk3P9dMAgsP/R+dD6XPI3TvolVUgWJUkI/W
VM7xc7bfDOUfwq3ZqFFsol9q9TuSVlDkSaWXc487hHN7K8cpN8AOvV8uE0ySiDKf
Oai562LCetORGs/NI+iQKvbVYsoCMfNrNezQ0TrCQ8FCUX13tRL7SthQMBisRo4U
RLoJTS1C+MgkCLD9nnxlZC6VOL6YIaXJ+e1RkmcMamdz2qjizms7oCJDdfNgi+O+
y0QH31Mz/sieXt+UTBkbhU8x9hYWwB1ZRcJXL4LTm7nW+77IQBCiNPQdThYV0ZQi
7kXrMlHo242se8EHZQ7F5bwermJSdC/vT/OG2B7/FV4dxl1U5ld6OdIu3XplLR38
PgiUNaeb9+3Exb4GVi+nBYl9bI2yqqAth0bJhle22PwEQXKMpsZhs85cl0XzM3NR
8k0EYG9rBWlR/93Bt+IC+9H0XfdJwxk8wBlxdAtoZCyGoApzoc6j+tC91UunEENa
IadIQD7MCJavs/jClHTDZd8HOoWcLgaKZjLskZGzccsSmxbWxX/UQB4aMEopXUZv
q6vL94Ef4d99H/rmTmJWzv+a4D+JyMfOtAjDtoilOamO6R2cg5FJeuvmB5oOCMKg
AuLcbJ9QxSYUEcXIN+7nthkLYH6/M2d0CIj/JP2tBg1bVzAQWoMCDFAN7D5CrT2j
rt4jMdBGZCXfyOvmudUBiQEcBAEBCgAGBQJU0h08AAoJEOFsRrMdttrPAgsIAKli
iTL4arThwb6L/GPte75FKtzWEl1SbSfhEmvCTQo5TmkinJ79fcfPpVh2mPuWr2gM
1ap2hYIlPmYRo67aGPKI5ILX8SzaFRInEU1NZjTst3+F2mqiHznfiacU9JuGbL7A
8D/oYTyOXVhBI0ycpj/B+3YewUqwJcblEVOMf3zPop0vTt/Fq2lftFG/dLo8bMsN
REiKXiALhJxflbvwiI3B2n4tl97jH6YXLsnRstRH3AxmwqKPNn98jJNEnrVTBnes
01rL/adPxTAv60AjMOdbb2I+LVfZilUJ3DTAaT0ocz6sLlteO0ikdaU8dGuvGwzQ
ns9/i5oaZuAkVa4bkA0=
=iQ6g
-----END PGP SIGNATURE-----

For easier access, I have also published it in text format. You can check it with:

$ wget -q -O- http://www.tataranovich.com/public/key-transition-2015.txt | gpg --verify
gpg: Signature made Wed 04 Feb 2015 04:23:08 PM MSK using RSA key ID 373FD74C
gpg: Good signature from "Andrey Tataranovich <tataranovich@gmail.com>"
gpg:                 aka "Andrey Tataranovich <andrey@tataranovich.com>"
gpg:                 aka "Andrey Tataranovich <andrey.tataranovich@amasty.com>"
gpg: Signature made Wed 04 Feb 2015 04:23:08 PM MSK using RSA key ID 1DB6DACF
gpg: Good signature from "Andrey Tataranovich <tataranovich@gmail.com>"
gpg:                 aka "Andrey Tataranovich <andrey@tataranovich.com>"
gpg:                 aka "Andrey Tataranovich <andrey.tataranovich@amasty.com>"

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

28 января 2015

CVE-2015-0235 - обновляйте свои хосты

В glibc нашли новую критическую уязвимость (CVE-2015-0235), которую можно использовать удаленно. Сегодня у меня день обновлений.

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

23 января 2015

Не работает dnssec-validation в bind9 в Ubuntu Precise

Столкнулся с багом в Ubuntu 12.04 LTS (Ubuntu Precise) - bind9, настроенный в качестве кеширующего dns, не может резолвить некоторые хосты. При этом в лог падает ошибка вида:

named[10137]: validating @0x7fa7cc019410: mail.frogger.nl A: got insecure response; parent indicates it should be secure
named[10137]: error (insecurity proof failed) resolving 'mail.frogger.nl/A/IN': 66.96.80.194#53
named[10137]: error (no valid NSEC) resolving 'mail.frogger.nl/A/IN': 85.17.41.33#53
named[10137]: error (no valid NSEC) resolving 'mail.frogger.nl/A/IN': 82.192.67.204#53

Проверка этого хоста на DNSSEC Analizer не показала никаких проблем. Если верить гуглу - я не одинок и проблема возникает с резолвингом хостов, где используется комбинация wildcard (*.frogger.nl, под который и попадает mail.frogger.nl) и DNSSEC. Соответствующие баг репорты открыты в Ubuntu #1203976 и Debian #690569.

В качестве затычки пока выключил валидацию dnssec:

options {
    dnssec-validation no; //was "dnssec-validation auto;"
}

Я пробовал сравнивать работу bind9 одинаковой версии (1:9.8.1.dfsg.P1-4) в Ubuntu и Debian: в Debian хост резолвится, а в Ubuntu - нет. Сравнение исходников пакета из Ubuntu и Debian не показывает никакой разницы. Пересборка пакета для Ubuntu тоже не улучшила ситуацию...

Возможно кто-то знает, почему один и тот же пакет bind9 по-разному ведет себя в Debian и Ubuntu?

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.