we are sorry, we are open

Разъём со стороны 9-пинового COM-порта (female — мама):

5       1
. . . . .
 . . . .
 9     6

RJ45 jack for PG console port:

||||||||
1      8

Непосредственно кабель COM — RJ45:

2 - 2
3 - 3
4 - 4
5 - 5
6 - 6

20050630.

Для снижения нагрузки на сервер приложений и сервер базы данных включен кеширующий прокси-сервер — все обращения идут к нему как к веб-серверу.

В качестве прокси использован Squid в режиме http-акселератора. Настройки Squid-а позволяют указать время кеширования, в течение которого запросы не будут передаваться на сервер приложений, а результаты работы скриптов будут отдаваться из кеша так же как и статичные страницы и картинки.

Проблема оказалась в том, что ASP-скрипты не желали кешироваться, и, несмотря ни на какие настройки Squid-а удалялись из кеша сразу после поступления. Таким образом задача по снижению нагрузки на серверы приложений и БД не выполнялась.

Дело было в директиве CacheControl со значением Private, которое выдаётся по-умолчанию, и мне не удалось повлиять на него настройками Squid-а. Изменить значение этой директивы удалось только при помощи дополнительной строчки в ASP-скриптах:

<% Response.CacheControl="Public" %>

Wireless LAN Access Point Micronet SP918BK

Поигрался несколько дней с беспроводной точкой доступа от Micronet. В целом впечатление благоприятное. Удивило указание на количество беспроводных клиентов (БП), которое может обслужить данное устройство — по данным с сайта производителя теоретически их может быть 254, практически лучше чтоб их было 20-30, но надёжнее всего если их будет 10 🙂

Сделал несколько записей для себя по поводу некоторых настроек.
(продолжение…)

Для чего нужна обратная зона и её делегирование объяснять не буду.
Обычно делегирование обратной зоны для сегментов менее /24 не практикуется, это понятно для совсем уж мелких подсетей, но неудобно для достаточно крупных, например в 128 и 64 адреса, особенно если конечный пользователь имеет довольно подкованного админа )
(продолжение…)

Многие админы ставят серийные номера ДНС-зон по дате, например «2004062101» — 2004-06-21 и 01-е изменение. Никаких требований на этот счёт нет, просто такой формат нагляден и удобен для отслеживания изменений.

Иногда, по запаре, можно сильно ошибиться в номере, например указать номер «2004962101». Можно конечно спокойно продолжать прибавлять по единичке при каждом изменении и не дёргаться, но если такой номер вам не нравится и хочется вернуть всё к обычной схеме, то это можно сделать досточно легко. К сожалению первоисточник я запамятовал, но вот выдержка из него:

The solution to this is to add 2147483647 (2^31-1) to the number, reload the
zone and make sure all slaves have updated to the new zone serial number,
then reset the number to what you want it to be, and reload the zone again.

Коротко получается так — дождитесь (проверьте) пока зона не обновится на всех ДНС-серверах, поддерживающих вашу зону. Затем изменить номер прибавив к нему цифру 2147483647, перегрузить зону и снова дождаться её обновления на всех соответствующих ДНС-серверах. После этого поставить тот номер, который вам нужен.

Было ещё какое-то теоретическое обоснование этого действия, но я его уже не помню 🙂