В процессе ремонта квартиры озадачился вопросом принудительной вытяжки в ванной, так как квартира на предпоследнем этаже, и боялся, что тяга может быть плохая, из-за маленького перепада высот.
При этом включение по свету делать не хотелось, так как идеологически это неправильно (когда ты только входишь в ванную — вентилировать особо нечего, а когда выходишь — неплохо бы, чтобы вентилятор немного поработал). Ставить отдельный выключатель — тоже вариант не для ленивых (нужно его включать вручную, а позже — выключать).
В магазине подвернулся неплохой вариант электровентилятора (но надо признать, что он такой был один из примерно 30 шт разных вентиляторов):
1) встроенный датчик влажности с регулятором — можно настроить момент включения при достижении определенной влажности в ванной
2) встроенный датчик времени работы — можно настроить время работы после включения (от 1 минуты до получаса примерно если память не изменяет). Если после окончания работы влажность все еще высокая, то примерно через минуту-две датчик влажности повторно включает вентилятор.
3) возможность включить вентилятор вручную подачей управляющей фазы, при этом вентилятор включится на заданное время. Эту возможность я у себя не использовал, так как 1+2 работают замечательно после некоторой эмпирической подстройки резисторов (времени и влажности).
Ну и стоимость этого вентилятора была на удивление невысокой, за 120мм вертушку около 700р. И еще 100р за обратный клапан от канальной системы вентиляции (чтобы воздух из шахты вентиляции не заходил в ванную в случае скачков давления)
Приятно, что человек самостоятельно собрал схему под свои нужды. Честно признаюсь — я бы вряд ли справился. Но я просто был на 100% уверен, что такую штуку давно уже должны были внедрить в вентиляторы, и целенаправленно пошел по магазинам искать вентилятор с таймером и датчиком влажности. Не без труда, но нашел.
Вам нужно просто поставить обратный клапан на вытяжку. Цена вопроса от 20р (пластиковая шторка) до 100р (блок для метталической канальной вентиляции, с подпружиненными шторками и гермопритвором).
Поставил себе на этапе ремонта, так как живу в высотном доме и переживал, что при открытии форточки тяга с нижних этажей вполне может пойти через мою квартиру в окно.
Мегафон считает неактивным пользователя, если не было СПИСАНИЯ средств с его счета в течение 90 дней. Сам буквально пару дней назад «прохлопал» так симку от Мегафон-модема, которой пользуюсь в летний период на даче (она там в роутер вставлена). Подключил 2 декабря модем дома к компьютеру, хотел отправить платную СМС, а оказалось, что симка уже заблокирована. Причем модем точно был вставлен в роутер где-то до конца сентября, но последнее списание средств было 1 августа (абонентская плата за интернет на весь август), а за сентябрь я уже не оплачивал, так как на даче редко появлялся (не сезон уже), и интернета со смартфона хватало.
Несколько удивляют цифры 3-го прохода у rshapshot.
Согласно тесту N1 копирование 11090МБ занимает около 8 минут, или средняя скорость при текущем наборе — файлов 23мб/сек. Что в общем-то похоже на правду при большом количестве мелких файлов.
Далее выясняем, что на «обход каталога» без самой операции копирования (только создание хардлинков) тратится около 10 сек.
А вот на 3-м проходе требуется скопировать 13267МБ-11090МБ=2177Мб «новых данных», но на это тратится только 31 сек. Из них операция аналогичная предыдущей из N2 должна занять 10 сек. Значит на само копирование новых файлов потрачено 21 сек. И скорость получается уже 103Мб/сек, что намного превышает скорость первоначального копирования из N1.
Либо файлы оказались в дисковом кэше, либо rshaphot определил, что в новом каталоге находятся копии файлов из соседнего каталога, и тоже создал хардлинки, не проводя фактического копирования.
Другого объяснения так сильно подскочившей скорости копирования у меня нет. Как можете прокомментировать этот момент?
Поподробнее, пожалуйста, про ipt_netflow в 2004-2009 гг
Ну либо Вы невнимательно читали статью. Имелось ввиду, что необходимость в учете трафика на описываемой машине пропала к моменту выхода Ipt_NETFLOW, а до этого приходилось пользоваться юзерспейс утилитами за неимением ничего другого. В данный момент на этом сервере сбор netflow не ведется.
Вообще-то не для 1/6, а для 5/6. То есть злоумышленник имел возможность подставить только примерно 16% МАС из общего числа, причем он в точности не знал, какие пары MAC-IP относятся к его сегменту. А тут уже была возможность мониторить, на каком порту бриджа вдруг стали появляться нелигитимные МАСи (brctl showmacs br0) и принимать какие-либо административные меры.
После установки свичей, которые могли слать SNMP-traps этот функционал был расширен таким образом:
в случае, если МАС «перепрыгнул» с порта на порт, то адрес блокировался, и клиентов заворачивало на спец-страничку, где для разблокировки предлагалось ввести логин/пароль. В этом случае получалось уже не 5/6 отсекалось, а выбор у злоумышленника оставался примерно в 5-7 МАС-адресов (соседи по неуправляемому свичу, компьютеры которых в данный момент выключены) из 1000 клиентов, или менее 1%. И такой подход очень сужал территориальное место поиска злоумышленника, единственное, что нужно было дойти ногами до конкретного свича и по очереди выключать кабели с активным линком. А иногда удавалось и без этого: пропал один МАС на порту — и тут же появился другой (у которого «пропажа трафика»). Что наводило на вполне обоснованные подозрения, и отключение кабеля было уже только для того, чтобы окончательно убедиться.
Нет. Указание минуса перед именем файла отключает sync на диск при каждой записи в лог, что повышает производительность, но может привести к тому, что при сбое данные могут оказаться фактически не записанными на диск.
Выдержка из man syslog.conf на эту тему:
You may prefix each entry with the minus ''-'' sign to omit syncing the file after every
logging. Note that you might lose information if the system crashes right behind a write
attempt. Nevertheless this might give you back some performance, especially if you run
programs that use logging in a very verbose manner.
Тяжело сказать, «сколько трафика», потому как не ясна методика подсчета :)
Начать с того, что в данной ситуации влияние оказывает не столько трафик в мегабитах, сколько пакетрейт (pps), так как именно пакетики каждый раз генерировали прерывания, и проходили цепочки iptables и других структур ядра. Особенно портили жизнь кольца на свичах, так как loopdetect отрабатывал не сразу (а порой вообще не отрабатывал) и весь закольцованный трафик, перекидываемый быстрыми специализированными микрухами коммутаторов, летел через многострадальный бридж.
Статистики по пакетрейту, к сожалению, у меня нет. Зато есть данные по трафику в мегабитах, в rrd.
Методику подсчета «общего трафика» использовал такую: брал для каждого физического интерфейса среднее значение входящих байт за час, и прибавлял к нему среднее значение исходящих байт за час. За час — потому что так ужимает rrd, пиковые безусловно могли быть заметно больше, но данных не осталось. Потом сложил получившиеся значения для всех интерфейсов.
В итоге получилось 3.1Гбит/с
Посмотрев текущую загрузку на загруженном порту одного из коммутаторов, выявил, что средний размер пакета где-то 900 байт плюс-минус.
Следовательно, при 3.1Гбит/с и размере пакетика около 900байт получаем пакетрейт 450 тысяч пакетов в секунду.
Наверное, правильнее было бы его разделить на 2, так как при суммарном битрейте использовался входящий и исходящий трафик, а сам сервер пакеты практически не генерирует, то есть весь трафик — транзитный. Значит средний пакетрейт за час выходит около 250 тысяч пакетов в секунду, без учета возможных кратковременных всплесков.
Бридж был интересен тем, что создавалась «плоская» сеть, и большое количество ПО (игры, «сетевое окружение», бродкаст-чаты, и тому подобное, что использует бродкаст-пакеты для обнаружения) работало нормально. При этом можно было ограничивать доступ заблокированным абонентам до некоторых выборочных ресурсов сети (или наоборот, оставлять выборочные) которые находятся в его «псевдосегменте» сети.
К примеру:
-у шлюза адрес a.b.c.1/24
-у вас адрес a.b.c.2/24
-у вебсервера1 адрес a.b.c.3/24
-у вебсервера2 адрес a.b.c.4/24
В можете попасть на вебсервер2, а при попытке зайти на вебсервер1 попадаете на «страничку-информатор». При этом вроде как трафик даже через шлюз не проходил с точки зрения клиентской ОС.
Управляшки в то время были, но 300$ стоила управляшка с RS232+WEB (без snmp и telnet/ssh) которая умела поднимать/опускать порты, показывать статистику на портах и ТОЛЬКО port-based VLAN (без 802.1q). То есть по сегодняшним меркам даже недолевел2. Ни о каком ограничении доступа на уровне этих железок речи идти не могло, во всяком случае за вменяемые деньги.
При этом включение по свету делать не хотелось, так как идеологически это неправильно (когда ты только входишь в ванную — вентилировать особо нечего, а когда выходишь — неплохо бы, чтобы вентилятор немного поработал). Ставить отдельный выключатель — тоже вариант не для ленивых (нужно его включать вручную, а позже — выключать).
В магазине подвернулся неплохой вариант электровентилятора (но надо признать, что он такой был один из примерно 30 шт разных вентиляторов):
1) встроенный датчик влажности с регулятором — можно настроить момент включения при достижении определенной влажности в ванной
2) встроенный датчик времени работы — можно настроить время работы после включения (от 1 минуты до получаса примерно если память не изменяет). Если после окончания работы влажность все еще высокая, то примерно через минуту-две датчик влажности повторно включает вентилятор.
3) возможность включить вентилятор вручную подачей управляющей фазы, при этом вентилятор включится на заданное время. Эту возможность я у себя не использовал, так как 1+2 работают замечательно после некоторой эмпирической подстройки резисторов (времени и влажности).
Ну и стоимость этого вентилятора была на удивление невысокой, за 120мм вертушку около 700р. И еще 100р за обратный клапан от канальной системы вентиляции (чтобы воздух из шахты вентиляции не заходил в ванную в случае скачков давления)
Приятно, что человек самостоятельно собрал схему под свои нужды. Честно признаюсь — я бы вряд ли справился. Но я просто был на 100% уверен, что такую штуку давно уже должны были внедрить в вентиляторы, и целенаправленно пошел по магазинам искать вентилятор с таймером и датчиком влажности. Не без труда, но нашел.
Поставил себе на этапе ремонта, так как живу в высотном доме и переживал, что при открытии форточки тяга с нижних этажей вполне может пойти через мою квартиру в окно.
Согласно тесту N1 копирование 11090МБ занимает около 8 минут, или средняя скорость при текущем наборе — файлов 23мб/сек. Что в общем-то похоже на правду при большом количестве мелких файлов.
Далее выясняем, что на «обход каталога» без самой операции копирования (только создание хардлинков) тратится около 10 сек.
А вот на 3-м проходе требуется скопировать 13267МБ-11090МБ=2177Мб «новых данных», но на это тратится только 31 сек. Из них операция аналогичная предыдущей из N2 должна занять 10 сек. Значит на само копирование новых файлов потрачено 21 сек. И скорость получается уже 103Мб/сек, что намного превышает скорость первоначального копирования из N1.
Либо файлы оказались в дисковом кэше, либо rshaphot определил, что в новом каталоге находятся копии файлов из соседнего каталога, и тоже создал хардлинки, не проводя фактического копирования.
Другого объяснения так сильно подскочившей скорости копирования у меня нет. Как можете прокомментировать этот момент?
Ну либо Вы невнимательно читали статью. Имелось ввиду, что необходимость в учете трафика на описываемой машине пропала к моменту выхода Ipt_NETFLOW, а до этого приходилось пользоваться юзерспейс утилитами за неимением ничего другого. В данный момент на этом сервере сбор netflow не ведется.
После установки свичей, которые могли слать SNMP-traps этот функционал был расширен таким образом:
в случае, если МАС «перепрыгнул» с порта на порт, то адрес блокировался, и клиентов заворачивало на спец-страничку, где для разблокировки предлагалось ввести логин/пароль. В этом случае получалось уже не 5/6 отсекалось, а выбор у злоумышленника оставался примерно в 5-7 МАС-адресов (соседи по неуправляемому свичу, компьютеры которых в данный момент выключены) из 1000 клиентов, или менее 1%. И такой подход очень сужал территориальное место поиска злоумышленника, единственное, что нужно было дойти ногами до конкретного свича и по очереди выключать кабели с активным линком. А иногда удавалось и без этого: пропал один МАС на порту — и тут же появился другой (у которого «пропажа трафика»). Что наводило на вполне обоснованные подозрения, и отключение кабеля было уже только для того, чтобы окончательно убедиться.
Выдержка из man syslog.conf на эту тему:
встречный привет Роману от Трубласта
Начать с того, что в данной ситуации влияние оказывает не столько трафик в мегабитах, сколько пакетрейт (pps), так как именно пакетики каждый раз генерировали прерывания, и проходили цепочки iptables и других структур ядра. Особенно портили жизнь кольца на свичах, так как loopdetect отрабатывал не сразу (а порой вообще не отрабатывал) и весь закольцованный трафик, перекидываемый быстрыми специализированными микрухами коммутаторов, летел через многострадальный бридж.
Статистики по пакетрейту, к сожалению, у меня нет. Зато есть данные по трафику в мегабитах, в rrd.
Методику подсчета «общего трафика» использовал такую: брал для каждого физического интерфейса среднее значение входящих байт за час, и прибавлял к нему среднее значение исходящих байт за час. За час — потому что так ужимает rrd, пиковые безусловно могли быть заметно больше, но данных не осталось. Потом сложил получившиеся значения для всех интерфейсов.
В итоге получилось 3.1Гбит/с
Посмотрев текущую загрузку на загруженном порту одного из коммутаторов, выявил, что средний размер пакета где-то 900 байт плюс-минус.
Следовательно, при 3.1Гбит/с и размере пакетика около 900байт получаем пакетрейт 450 тысяч пакетов в секунду.
Наверное, правильнее было бы его разделить на 2, так как при суммарном битрейте использовался входящий и исходящий трафик, а сам сервер пакеты практически не генерирует, то есть весь трафик — транзитный. Значит средний пакетрейт за час выходит около 250 тысяч пакетов в секунду, без учета возможных кратковременных всплесков.
К примеру:
-у шлюза адрес a.b.c.1/24
-у вас адрес a.b.c.2/24
-у вебсервера1 адрес a.b.c.3/24
-у вебсервера2 адрес a.b.c.4/24
В можете попасть на вебсервер2, а при попытке зайти на вебсервер1 попадаете на «страничку-информатор». При этом вроде как трафик даже через шлюз не проходил с точки зрения клиентской ОС.
Управляшки в то время были, но 300$ стоила управляшка с RS232+WEB (без snmp и telnet/ssh) которая умела поднимать/опускать порты, показывать статистику на портах и ТОЛЬКО port-based VLAN (без 802.1q). То есть по сегодняшним меркам даже недолевел2. Ни о каком ограничении доступа на уровне этих железок речи идти не могло, во всяком случае за вменяемые деньги.