halver

Присоединяйтесь на IRC #nocproject.org at freenode, не стесняйтесь задавать вопросы.

По поводу аренды кабельной канализации у РТ - зря вы успокаиваите альтернативных операторов. Наглядный вам пример - http://www.fontanka.ru/2013/08/14/081/ . При том, что по сути кабельный подвод к новым домам - собственность застройщика(а в последствии в зависимости от формы управления домом - управляющей компании или ТСЖ) - Ростелеком наглым образом прихватизирует эти подводы. Да еще и "амнистию" свою использовали лишь для того, чтобы повырезать конкурентов, ни о какой легализации речи даже и не шло. Мотайте на ус, коллеги.

upgrade проверяет - установлен ли у вас в БД postgis. И если нет - пробует сделать это сам. Вот только в разных дистрибах и версиях pgsql пути до postgis.sql - разные, поэтому скрипт может выдать ошибку. Сама по себе установка постгис не завершается установкой пакета/порта, она требует ручной заливки postgis.sql в БД. Выше я приводил 1 команду - выполните ее(поменяв путь к postgis.sql на ваш актуальный), и ничего больше апгрейд по постгису у вас требовать не будет, пока БД не решите грохнуть. По поводу зависимостей и бинарников...используется virtualenv не спроста - потому, что в определенных дистрибутивах есть проблемы, когда системные версии модулей, не совместимы с теми, что используются в ноке и наоборот. Пример - CentOS требует выкрутасов, чтобы завести нок на питоне 2.7, но в virtualenv-e замечательно работает. В итоге проще контролировать совместимость и работоспособность пакета с версиями, которые вытянет сам нок в свой virtualenv.

2 варианта: 1. предоставляете удаленный доступ в лабу к тестовому железу, разработчики используя доступ пишут профиль 2. вливаетесь в команду разработчиков) ну и третий вариант - это если кто-то, кто имеет данные коммутаторы, напишет профиль раньше первых двух вариантов.

su pgsql psql -f /usr/local/share/postgis/contrib/postgis-<ver>/postgis.sql -d noc Вот это делали?

http://kb.nocproject.org/pages/viewpage.action?pageId=2687553

Почем 4612? инфу в личку.

этот отчет говорит о неумении настраивать оборудование. Поделитесь, в чем же именно неумение проявляется?

В последние 3-4 дня стали наблюдать такую картину: т.е. скачкообразно резко растет исходящий pps. До этого все было плавненько. Кто нибудь отмечает подобное? Следствие ли это выхода новой версии utp? p.s. utp не резали и пока не режем..

Кто-то спрашивал про влияние uTP на VoIP. Недавно запустили у себя в тест данную услугу, соотв. есть плацдарм для исследования. uTP у себя глобально не режем, голос терминируем до шейперов(т е по факту оценивается влияние на канал Клиент<->техплощадка). Из оборудования между клиентом и ТП - маршрутизатор сегмента на базе FreeBSD/либо L3 маршрутизирующий свитч. Аплинк с доступа гиговый, выше на агрегации либо 1 Гбит/с, либо транки 2-3 Гбит/c до L3. Линии загружены слабо, 20-30% максимум от пропускной способности. Голос пока идет в общем клиентском влане вместе с тыртырнетом. При использовании софтфонов, и включенном у клиента uTP(раскачка по максимуму тарифа вход/выход) наблюдается значительная временная задержка (3-5с), естественно услуга с такими параметрами никому не нужна, ибо комфорт от пользования нулевой. При отключении uTP у клиента в uTorrent'e и максимальной раскачкой канала, ситуация меняется кардинальным образом - задержки минимальные. Собственно результаты предсказуемые, признаться, мы думали все будет гораздо хуже:)

И чего поменяется в случае statefull NAT'a?)

А, простите, какая разница - статистика снятая до ната с серых, или статистика снятая с только белых по размеру? С белыми меньше станут качать чтоли? При трафике в 2ТБ в сутки за'gzip'ованный rdr-tur весит всего 500Мб.

Вы бумажки из МВД давно в руках держали ? Там время без секунд, раз. dst, host, request uri там нет два (их в принципе не может быть, когда, например, хакали какой-нибудь банк-клиент). А за минуту сколько через NAT пройдет исходящих соединений ? Ну и хранить данные о соединениях пользователей надо 3 года. Можно подумать, что статистику по внешникам хранить три года не придется, ага. Выше Кирилл вам ответил по формулировке запроса. Dst-адрес, как и таймстепм должен наличествовать, если нет - посылается уточнение. Как Вы видите ситуацию, когда внешники выдаются динамически? Кончилась сессия - адрес выдался другому. За 1 минуту - хоть 10 раз. Имхо демагогия все это..

А расскажите, что вы будете отвечать на запрос из органов "кто такой был с адресом А в такое-то время ?". Адрес А - это внешний NAT адрес. С каких пор снимать flow cтатистику до ната уже противоречит религии? Timestamp наличествует, в случае rdr-детальки с SCE есть и HTTP Host и HTTP Request URI.

2Гбит/с фуллдуплекса с NAT на PC-роутере? Не смешите. И Кирилл, и наш опыт об одном и том же говорит.

Собственно в продолжение темы: http://shop.nag.ru/catalog/item/04974 Кто нибудь имел опыт юзанья этой железки? По фото нутрей, конечно сомнительно, что оно умеет то, что написано..Но IXP2400 то обязывает... Может коллективно "подергать" уважаемый наг привезти одну железку, подключить консоль/потестить, дабы не брать "кота в мешке"? Думаю не мало ISP заинтересовались бы таким решением.

Я всё ждал, следя за темой, когда же вылезут возмущённые хомячки. Разумеется, вылезли. Как же, "режут, ограничивают !!!" Не потрудившись ни грамма хотя бы попытаться понять, о чём идёт речь. Что режут? Для чего режут? Мусор, который плодят сами хомячки, вот его и режут. Дерьмо-с, плодимое хомячковым uTorrent версии 2.0, его режут. Чтобы инет у хомячка начал работать снова нормально. Чтобы график закачки/раздачи, в хомячковом торренте, снова стал нормальной линией, а не гребёнкой вверх-вниз. Чтобы онлайн-игры вернулись к тому пингу, который был до февраля. Чтоб, в конце-то концов, хомячковый роутер перестал виснуть от pps. Ан нет, "источник всемирного зла". За ними какашки выгребают, а они всё недовольны. Воистину, "куда абонента не целуй, везде *опа" Ну дык это типичная позиция людей, которые не разбираются/лись(или не хотят разбираться) в ситуации, а лишь услышав слово "резать" вопят об ущемлении их прав.

У меня привело. Странно. Если с соответствующим падением трафика пропорционально PPS - значит не то режете.

Кирилл, поделись, как SCE реагирует на это? Хоть я и не Кирилл, но отвечу SCE классифицирует этот протокол как P2P-Non-Encrypted Bittorrent, т.е. все как надо. Другое дело что отделить его от TCP на данный момент невозможно. Таким образом можно наложить ограничение только на весь Bittorrent трафик. Вроде получилось на SCE отделить UDP торрент-траффик от TCP по сигнатуре из стандартного protocol-pack'a, а затем вынести в отдельный сервис. Завтра будет видно, сработало или нет.