Nevolin.info

Проблема с %2f в URL при обработке запроса mod_rewrite

Столкнулся сейчас с такой проблемой: при  наличии в урле символа %2f (кодированный слеш — ‘/’)  mod_rewrite отказывается рутить этот запрос, показывая 404. Конкретно это случилось на движке LiveStreet, .htaccess оттуда не менялся.

Дело в том, что по RFC2396 символ %2f может присутствовать в GET-запросе, но не должен присутствовать в самом URL. Разумеется, Apache по дефолту зарезает такие слеши в урле.

Для того, чтобы исправить такое поведение Apache, добавим параметр

AllowEncodedSlashes On

в настройки виртуального хоста сайта.

Как отключить Caps Lock в Gnome

Почему-то по запросу “gnome disable caps lock” на первом месте не совсем правильные советы про переопределение через Xmodmap. Так вот, на самом деле делается это просто:

1. переходим из главного меню “Система”→”Параметры”→”Клавиатура”;
2. в окне открывшейся утилиты выбираем вкладку “Раскладки”, там нажимаем кнопку “Параметры”;
3. в списке раскрываем пункт “Поведение клавиши Caps Lock” и выбираем “Caps Lock выключен”.

Аналогично через настройки это делается и в KDE, кстати.

Как сменить имя интерфейса в Fedora?

Часто после установки новой сетевой карты имена интерфейсов меняются. Например, eth0 становится eth1 и т.д.

В redhat-based дистрибутивах починить это очень просто. Новые имена для интерфейсов придумывает udev. Он видит новую сетевую карту и присваивает имя интерфейсу с ней. Правила пишутся в файл /etc/udev/rules.d/70-persistent-net.rules. Вот, например, было у нас две сетевые карты, встроенная и вставленная в PCI:

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rule written by anaconda)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:50:bf:a2:12:c9”, ATTR{type}==”1”, KERNEL==”eth*”, NAME=”eth0”
# nVidia Corporation CK804 Ethernet Controller (rule written by anaconda)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:0f:ea:12:ab:38”, ATTR{type}==”1”, KERNEL==”eth*”, NAME=”eth1”

Мы решили поменять материнскую плату, после чего у нас появилась новая встроенная сетевая карта Realtek Semiconductor Co., Ltd. RTL8111, а старая nVidia Corporation CK804 Ethernet Controller, соответственно, исчезла. Но udev информацию о старой карте стирать не будет, а новой назначит своё имя интерфейса eth2:

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”1c:6f:65:34:a3:89”, ATTR{dev_id}==”0x0”, ATTR{type}==”1”, KERNEL==”eth*”, NAME=”eth2”

Таким образом у нас в системе будут интерфейсы eth0 и eth2, а eth1 исчезнет. А у нас на eth1 правила в iptables есть, да и зачем вообще менять имя интерфейса, если новая сетевая карта подключена к тому же транку, что и старая, т.е. полностью пришла ей на замену.

Чтобы вернуть интерфейс eth1, просто отредактируем файл /etc/udev/rules.d/70-persistent-net.rules, поменяв там значение атрибута NAME у новой сетевой карты, а запись о старой удалим или закомментируем:

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rule written by anaconda)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:50:bf:a2:12:c9”, ATTR{type}==”1”, KERNEL==”eth*”, NAME=”eth0”
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”1c:6f:65:34:a3:89”, ATTR{dev_id}==”0x0”, ATTR{type}==”1”, KERNEL==”eth*”, NAME=”eth1”

Дальше не забываем сопоставить имена интерфейсов с адресами MAC в конфигурационных файлах /etc/sysconfig/networking/devices/*

Например, редактируем /etc/sysconfig/networking/devices/ifcfg-eth1:

DEVICE=eth1
HWADDR=1c:6f:65:34:a3:89

Вот так просто.

Обновление до Fedora 14

Вчера всё-таки решился на обновление с Fedora 13 до Fedora 14. Точнее, с RF Remix 13 до RF Remix 14.

Обновление через preupgrade не получилось, т.к. boot-раздел у меня объёмом всего 190Мб (так разбила анаконда при установке какой-то старой версии Федоры давным-давно). Даже после указания каталога данных preupgrade-а симлинком на основной раздел под LVM, preupgrade всё равно не стал работать, увидев подставу и сообщив, что на LVM он ставиться всё равно не будет.

Пришлось, как обычно, обновляться через yum. Общие рекомендации по обновлению написаны членами команды Fedora в YumUpgradeFaq. Честно выполнив все написанные там операции, я, что удивительно, не получил желаемого результата. Утилита yum, десять минут пожевав жёстким диском и выдав ленту сообщений на консоль, сообщила, что тоже не сможет совершить апгрейд:

Проверка сценария завершена с ошибкой:
  file /usr/lib64/libavahi-client.so.3 from install of avahi-libs-0.6.27-2.fc14.x86_64 conflicts with file from package avahi-0.6.25-7.fc13.x86_64
  file /usr/lib64/libavahi-common.so.3 from install of avahi-libs-0.6.27-2.fc14.x86_64 conflicts with file from package avahi-0.6.25-7.fc13.x86_64
  file /usr/lib/libavahi-client.so.3 from install of avahi-libs-0.6.27-2.fc14.i686 conflicts with file from package avahi-0.6.25-7.fc13.i686
  file /usr/lib/libavahi-common.so.3 from install of avahi-libs-0.6.27-2.fc14.i686 conflicts with file from package avahi-0.6.25-7.fc13.i686

Тогда, как советует Tigro, я попробовал в команде апгрейда

yum --releasever=14 distro-sync --skip-broken

опустить “skip-broken”

yum --releasever=14 distro-sync

Запущенный с такими опциями yum показал истинную причину невозможности апгрейда: наличие пакетов uade и kudzu, которые требовали python старой версии. Пакеты эти старые, kudzu уже давно не используется, поэтому я их просто удалил. После этого апгрейд прошёл удачно.

Вот я и обновился. При первой загрузке система встречает меня новым артворком. Fedora 14, как мне показалось, работает быстрее 13-ой. Также там починен VirtualBox, что не может не радовать.

Сменить название админки в django

Сегодня я хочу рассказать о том, как изменять под себя шаблоны подключаемых приложений django. Сделаю это я на примере изменения названия админки в django, т.к. этим вопросом просто завален интернет.

Система шаблонов в django обладает одной интересной особенностью: сперва искомый шаблон ищется в каталоге с проектом, а уже в случае неудачи первого шаблон ищется в каталоге используемого приложения (в данном случае — админки django). Поэтому нам достаточно скопировать только единственный файл с шаблоном, который мы хотим изменить.

Сперва убедимся, что в нашем проекте создан каталог с шаблонами  [путь до корня проекта]/templates. Далее убедимся, что путь до этого каталога описан  в кортеже TEMPLATE_DIRS файла настроек проекта settings.py. Создадим в каталоге с шаблонами  каталог admin: [путь до корня проекта]/templates/admin

Нужные нам данные надо изменить в файле admin/base_site.html. Поэтому скопируем его в наш каталог шаблонов проекта:

» cp [путь до корня дистрибутива django]/django/django/contrib/admin/templates/admin/base_site.html [путь до корня проекта]/templates/admin/base_site.html

Этот файл выглядит таким образом:

{% extends "admin/base.html" %}
{% load i18n %}

{% block title %}{{ title }} | {% trans 'Django site admin' %}{% endblock %}

{% block branding %}
<h1 id="site-name">{% trans 'Django administration' %}</h1>
{% endblock %}

{% block nav-global %}{% endblock %}

Дальше либо меняем {% trans ‘Django site admin’ %}  и {% trans ‘Django administration’ %} на строки текста с нужным названием, либо, что ещё лучше:

1. Меняем текстовый идентификатор ‘Django site admin’ на свой ‘my site admin’ и ‘Django administration’ на ‘my site administration’.
2. Из каталога с приложением делаем: ./django-admin.py makemessages -a
3. Устанавливаем значения текстовых идентификаторов в файлах перевода на все используемые нами языки
4. Из каталога с приложением делаем: ./django-admin.py compilemessages

Вот и всё, мы поменяли название админки джанго, отображаемое в нашем проекте. Аналогичным образом можно изменять под себя многие другие шаблоны админки, но это уже совсем другая история.

Попячься

Огромное количество тупоголовых баб в стране, воспитанием которых занимались только матери.