После сбоя винта и при его проверке при помощи fsck получаем кучу сообщений об ошибке:
SORRY. NO SPACE IN lost+found DIRECTORY
Дело в не свободном объёме в этом разделе, а в свободных дескрипторах файлов. Для увеличения их количества принудительно подмонтируем раздел, создаём в папке «lost+found» создаём кучу файлов, удаляем их, отмонтируем раздел и снова натравливаем на него fsck:
# mount -f /dev/ad0s1f /mnt
# i=1; while [ $i -lt 10000 ]; \
do touch /mnt/lost+found/xxx.$i; i=`expr $i + 1`;done
# rm /mnt/lost+found/xxx.*
# umount /mnt
# fsck -y /dev/ad0s1f
20070425
Все команды, которые вы выполняли в командном интерпретаторе (shell) на своей юниксовой машине, сохраняются в файле истории. То же самое делает и файл-менеджер типа MC или deco. Даже все ваши действия с базой данных MySQL, которые вы производили через утилиту mysql, сохраняются в файле истории.
В подобном файле истории может сохраниться много интересного для хакера, вплоть до паролей пользователей базы данных. А к тому же, по-умолчанию, права файлов и директорий позволяют читать их всем. Короче говоря, я считаю, что за собой всю эту историю надо подчищать, даже если вы сделали свою домашнюю папку недоступной для других пользователей.
(продолжение…)
Разослал всему офису письмо со своего адреса с просьбой прислать мне свои данные для доступа к БД.
Фишка в том, что, хотя адрес отправителя был мой, но адрес для ответа был левый на gmail.com — нажимаешь «Ответить», а в адресе получателя стоит левый емейл )
Получил 9 ответов с паролями на указанный ящик с gmail.com. Слава Богу, что хоть кто-то переспросил, чтобы убедиться, что письмо от меня. Правда на левый емейл так никто внимания не обратил )
И это сотрудники IT конторы, непосредственно связанной с Интернетом и имеющие доступ к конфиденциальной информации.
Грустно…
Обычно, для тех кто впервые начинает настройку файрвола, принципы работы трансляции соединений становятся одним из наиболее сложных для понимания моментов, поэтому в данной статье основной упор сделан на описании этих принципов на примере одной типовой схемы.
(продолжение…)
Родная розетка из комплекта поставки имеет 8 контактов, если смотреть на неё сверху, разъёмом вниз, то 1-й контакт будет в правом нижнем углу, а 8-й — в левом нижнем, нумерация идёт против часовой стрелки.
Для соединения по двум парам: первая пара — контакты 1 и 2, вторая пара — контакты 4 и 5.
Для соединения по одной пары: контакты 1 и 2.
Внутри пары соответствие проводов необязательно.
Для подключение модема к линии используется обычный прямой кабель, нумерация такая же как и в розетке.
Разъём со стороны 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, перегрузить зону и снова дождаться её обновления на всех соответствующих ДНС-серверах. После этого поставить тот номер, который вам нужен.
Было ещё какое-то теоретическое обоснование этого действия, но я его уже не помню 🙂
