crossdomain.xml

Обнаружили в логах поиски файла crossdomain.xml
Оказалось, это от какого-то флэш-плеера.

Извеcтно что Flash Player может загружать данные из внешних источников. Это могут быть файлы XML находящиеся на сервере, данные получаемые от сценариев, shared библиотеки (swf-файлы). Но, по умолчанию, такое возможно если загружаемые файлы находятся в одном домене(на одном сайте) с загружающим их файлом (swf).
Что бы сделать shared-библиотеки, XML и другие данные доступными для SWF в других доменах, используйте файл с кросс-доменными правилами (cross-domain policy file). Файл с кросс-доменными правилами — XML файл, который дает возможность серверу «показать», что его данные и документы доступны для SWF файлов, находящихся в указанных в crossdomain.xml доменах. Любой SWF файл, который находится в домене, указанном в файле с правилами на сервере, будет иметь доступ к файлам и данным на этом сервере.
Когда Flash документ пытается получить доступ к файлу в другом домене, Flash Player автоматически загружает файл с правилами с этого домена. Если домен, в котором находится Flash документ, включен в файл с правилами, он получает доступ к данным.

отсюда

Получается, это кто может читать файлы с нас. Обычно можно разрешить *

Правила для разрешения всего:

<cross-domain-policy>
<allow-access-from domain="*" to-ports="80"/>
</cross-domain-policy>


Возможно, еще требуется xml-тэг
<?xml version=\"1.0\"?>
(вопрос про экранирование, надо ли)

Линки навскидку:
http://pulseneon.ru/archives/7
http://uppod.ru/talk_189

debian: dig: command not found

Штатно в дебиляне много чего нужного нет.

Доставляем утилиту dig, которая лежит в пакете dnsutils
apt-get update && apt-get install dnsutils

Впрочем, иногда достаточно команды host, она тоже умеет ключ -t (тип запроса), в несколько запусков получается вся информация как через dig

Работаем с hardlinks

В отличии от символических ссылок (softlink), которые являются файлом с адресом оригинального файла, хард линки (hardlink) на файл это просто разные имена одного файла. (тут чуть понятнее)

Возьмём для примера CentOS, с настройкой сетевого интерфейса.
# ls -la /etc/sysconfig/networking/devices/
total 24
drwxr-xr-x 2 root root 4096 Nov 16 20:23 .
drwxr-xr-x 4 root root 4096 Nov 16 20:23 ..
-rw-r--r-- 3 root root 243 Jul 7 2010 ifcfg-eth0

Мы видим единственный файл, где после атрибутов идёт цифра 3 - это сколько имён у нашего файла.
Проверим - покажем inode-ы файлов (что-то вроде уникального номера файла для одной ФС)

# ls -lai /etc/sysconfig/networking/devices/
total 24
2032307 drwxr-xr-x 2 root root 4096 Nov 16 20:23 .
2032306 drwxr-xr-x 4 root root 4096 Nov 16 20:23 ..
2031627 -rw-r--r-- 3 root root 243 Jul 7 2010 ifcfg-eth0

Теперь проверим в других местах...

# ls -lai /etc/sysconfig/networking/profiles/default/ifcfg-eth0
2031627 -rw-r--r-- 3 root root 243 Jul 7 2010 /etc/sysconfig/networking/profiles/default/ifcfg-eth0

# ls -lai /etc/sysconfig/network-scripts/ifcfg-eth0
2031627 -rw-r--r-- 3 root root 243 Jul 7 2010 /etc/sysconfig/network-scripts/ifcfg-eth0

Первое число и есть наш номер inode, и мы видим, что он одинаковый.
Если нам надо создать хард-линк -- это делается командой ln
Если надо найти все файлы с данным inode -- это делается через find, ключ -inum или просто -samefile. Пример:
# find /etc/ -samefile /etc/sysconfig/networking/devices/ifcfg-eth0 -print
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/networking/profiles/default/ifcfg-eth0
/etc/sysconfig/networking/devices/ifcfg-eth0


И небольшое замечание: если у нас есть система, которая не хочет правильно работать с адресом (получать dhcp вместо статики или наоборот) - что-то не в порядке с указанными файлами. Надо проверить их и при необходимости пересоздать линк.

Gmail: Username is reserved for email list only

При попытке создать ящики (на своих доменах) abuse и postmaster сервер скажет "Username is reserved for email list only". Эти ящики используются Google Team для обработки спама и происшествий. Если есть желание получать себе копии -- можно создать группы abuse и postmaster и добавить туда нужные адреса.
Это раздел Groups (Группы)

Описание на офсайте:
http://www.google.com/support/a/bin/answer.py?answer=33389

PHP и FPM

Некоторые говорят, что FPM пока несколько нестабилен. И просто не везде подходит.
Во freebsd можно выбирать, собирать с этим патчем или нет (даже на 5.3.6), тогда как в centos 5.6 включена версия с патчем, и как я понимаю, возможности его убрать штатно нет. Только пересобирать ручками.
Про дебиан не в курсе, но думаю, там тоже оно включено.
gentoo тоже в шоколаде.. )) спасибо USE флагам.

Вообще, он штатно включен с версии 5.3.3

arc_summary.pl

Есть утилита для ZFS, которая показывает статус ФС в понятном виде - arc_summary.pl
офсайт, с которого не совсем понятно, что загружать.
отсюда берется линк http://jhell.googlecode.com/files/arc_summary.pl

Есть последняя версия из HEAD тут: http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl

Description: While ARC is an amazing achievement its memory consumption raises doubts and questions in many administrators and users who view memory as a precious commodity. The Kstat facility provides access to a variety of ARC counters, but interpretting these properly is complex and non-intuative in their raw form, without spending several hours in the arc.c code. The purpose of arc_summary.pl is to provide a historical analysis of the ZFS ARC, to answer such questions as:

ARC is consuming 80% of memory. Is the sacrifice worth it?
What are the various sizes and limits that make up ARC?
What does the cache churn look like?
How efficient is prefetch? Should I disable it?

Также есть интересная дока: http://www.cuddletech.com/blog/pivot/entry.php?id=979

Please note, this report is cumulative since boot. It should compliment the arcstats tool. arcstat can tell you want is happening, arc_summary can tell you what has been happening. Any serious ZFS deployment should have both of these bad boys around in your toolbag.

SRS - что это такое

При установке exim из портов есть опция Sender Rewriting Scheme (SRS)
Для чего это нужно?

"В связи с некоторым распространением SPF (sender policy framework) возникает такая проблема: администратор домена отправителя пример godaddy.com прописывает в ДНС для своего домена текстовую запись, указывая с каких ip-адресов все остальные почтовые сервера имеют право получать письмо с обратным адресом этого домена. Так же этот администратор может рекомендовать запретить принимать письма с остальных ip-адресов. Теперь предположим, что на Ваш сервер пример mail.mydomain.ru пришло письмо с обратным адресом от такого домена пример info@godaddy.com И предположим, что у Вас стоит переадресация для получателя пример noc@mydomain.ru-->vasya@yandex.ru. Тогда Ваш почтовый сервер пересылает это письмо. Итак, что видит сервер того домена на который идет переадресация: с ip-адреса Вашего сервера приходит письмо с обратым адресом info@godaddy.com. Сервер делает запрос TXT записи для домена godaddy.com и получает ответ

"v=spf1 include:spf.secureserver.net -all"
Поскольку Ваш сервер mail.mydomain.com или его ip-адрес не вклчюен в spf.secureserver.net а следующая инструкция -all запрещает прием от всех остальных ip-адресов, сервер получателя отвергает такое письмо."
Отсюда
Это выдержка из начала, там больше.

Подробная официальная дока: http://www.libsrs2.org/srs/srs.pdf

(что такое SPF, уже было у меня

О настройке SRS в exim: http://wiki.exim.org/SRS