Поиск по метке: Linux

Перенеся сервер, на котором расположен deltaplan.kz, с apache2 на php-fpm, я столкнулся с неожиданной проблемой. Несмотря на правильным образом настроенные nginx конфиг и php-fpm pool GPS-подсайта — сервер упрямо, вместо того, чтобы запускать PHP файлы, возвращал их исходный код. Первым делом я вспомнил про security.limit_extensions = .php. Затем полез мучить различные fastcgi-параметры nginx хоста. Однако враг зашёл с другой стороны. Дело в том что в /etc/php5/fpm/php.ini по непонятным мне причинам был установлен short_open_tag: Off, в то время как XC Leonardo вовсю использует сокращённый вариант <? ?>. Разрешив эту опцию и перегрузив php5-fpm всё взлетело.

Небольшой гайд с картинками о том, как можно мышкой "натыкать" себе статичный IP в Ubuntu. Подразумевается, что сетевое соединение у вас исправно работает, и что статичный IP у вас есть (в моём случае, это просто любой локальный IP для роутера). Итак, для начала узнаем текущие параметры соединения…

подробности…

На работе у меня достаточно старое "железо", я бы предпочёл работать на более мощной машине. Недавно начальник принёс плашку DDR2 на 2 ГБ. Эффект потрясающий. Но обо всём по порядку. Конфигурация:

• CPU: Core2Duo 1.8
• ОЗУ: DDR2 2GB
• Прочее: ~100+ GB HDD, 128 || 256 встроенная вид.карта

Ничего из супер тяжеловесного софта не использую. Из средней тящести VMWare + winXP, Photoshop CS5, Netbeans 7. Ввиду специфики работы приходится одновременно держать открытыми несколько браузеров, HeidiSQL и ещё 5-6 программ. Уровень потребления ОЗУ держится на уровне ~1.2 - 1.6 GB. Если > система начинает использовать SWAP (~100-300 Мб). Ни разу не зафиксировал трату более чем 1.6 ГБ ОЗУ. Ввиду этого мало надеялся на какой-то существенный рост в производительности ПК. Для меня в порядке вещей было открыть Photoshop (wine), повозиться с ним минут 20, а потом ожидать растормаживания Netbeans или ещё чего. Так как alt-tab-аться в разное ПО приходится часто - тормоза несколько досаждали :)

Поставил плашку - включил систему, и зная что она у меня 32-битная, ожидал худшего. Ubuntu увидела ~3.2 GB памяти. Немного Google, пару перезагрузок (с неудачными опытом) и вот оно решение: sudo apt-get install linux-generic-pae linux-headers-generic-pae. После перезагрузки система увидела 3.9 Гб. Насколько я понял и обсуждений - некоторую часть, по непонятным мне причинам, "съела" видео-карта, впрочем, я не жадный :D. Использоване PAE несколько нестабильно, зато позволяет, используя x86 архитектуру, "видеть" до 64 Гб ОЗУ. Насколько я понял, остаётся ограничение только в 4 Гб на 1 процесс. Вышеописанные тормоза пропали напрочь. SWAP теперь не используется. Никогда не думал, что увеличение озу может дать серьёзный прирост в производительности.

Пытаясь улучшить nautilus, путём установки Elementary, я столкнулся с тем, что вместо ожидаемых "плюшек" я получил баги. Единственное решение по удалению elementary, которое я нашёл, заключалось в переустановке nautilus вместе с его плагинами. Баги пропали, наутилус рабоает. Однако, после перезагрузки оси на следующий день, я столкнулся с проблемой - вылетают ошибки "Could not update ICEauthority file /home/[user]/.ICEauthority" и "Произошла ошибка с сервером конфигурации (/usr/lib/gconf 2-4-sanity-check-2 завершился с состоянием 256)". Ни под основной учёткой, ни под root-ом нельзя было сделать практически ничего - ошибки доступа. Но если загружаться из консоли восстановления - всё работает, доступ к /home, /boot, /root и т.д. есть.

Все решения, найденные мною в сети, были просты как валенок - удали .ICEauthority, смени ему владельца, выдай права. Ни 1-о из них не помогло, этот файл, судя по всему, был жертвой обстоятельств, а не причиной всех проблем. Но в последний момент я нашёл решение в 1 строчку: sudo apt-get gnome-session. 

Сломался старый монитор, установил другой. Убунта радостно улюлюкая сообщила мне, что настройки от старого монитора не подходят и влепила 1024х768. Я полез менять — нельзя, максимальный режим. Полез менять xorg, используя самые разные найденные мною методики. Самое большее чего я добился - уменьшил макс.разрешение до 640х480. В итоговом счёте меня спасло следующее:

1. Открываем xorg.conf в редакторе: sudo gedit /etc/X11/xorg.conf
2. Ищем текущий секцию с текущим монитором, у меня это был Monitor0 (CRT-1)
3. Удаляем данные о HorizSync и VertRefresh
4. Внимательно изучаем свой монитор на предмет его наименования, в моём случае это CTX S960A
5. Ищем по нему спецификацию, в моём случае хватило этого
6. Нас интересует графа "Частота развертки", копируем новые данные в секцию монитора, взамен старых HorizSync и VertRefresh
7. Перегружаем ось (или иксы, по идее должно хватить)
8. Выбираем подходящее разрешение экрана и частоту в настройках (я использовал NVidia X Server Settings)

Самое интересное - NVidia нашла целую кучу разрешений экрана, которые этот монитор не поддерживает :) В общем счёте, на всё про всё ушло два часа с гаком. В винде таких проблем не возникает :)