ronin_zp

ну перед апгрейдо сделать профилирование ядра при нагрузке не помешает ;-) Скорее всего перед профилированием прийдётся сделать kldload pmc блин как-то не очень звучит команда кстати, посмотри в момент нагрузки top -HSCP и если там много нагрузки на echi - отключи в биосе юсб

офигительный патч для проблемы с мускулем 5.6, при установленном мускуле 5.1. Ещё раз повторяюсь, тут явно не в мускуле проблема в чём проявилось игнорирование? В той документации ничего кроме "станьте на коврик, держитесь за поручень" (в смысле запустите скрипт и отвечайте на вопросы) - ничего нет. Ну да, единственная рекомендация - режим BIN для более быстрой установки. Напомню написанное выше - 24 апреля сего года пользовался скриптом и устанавливал из исходников. Всё работало - респект и уважуха. Сейчас такого сказать не могу

не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай?

У меня была фря с 1000 с копейками правил фаервола ( на тот момент ). После оптимизации фаервола стало несколько полегче, но фиг заставишь клиентов "любимый" провайдерами мюторрент корректно настроить, точнее отключить его фирменный протокол. Я бы всё-таки подумал о возможности апгрейда карточек. Потому что ваши хороши для серваков отдающих контент, но явно хреново работают с большим количеством транзитного трафика

исходя из TOS - мой скрипт как и все остальное, никому ничего не должен. моё личное имхо, если поддержка заявлена - должно работать, если поддержка НЕ заявлена - то работать не обязано. Значит просто мало "сталкивались". не сталкивался, и мало того - постараюсь это знакомство не расширять. С фрёй работаю ещё с версии 4.9, всегда с портами. Ниразу проблем небыло, а если и возникали - решались малой кровью еще пару десятков раз на этом же форуме упоминалось... (блжад, даже в этой же теме было). Кажись нашёл sgconf_xml -s 127.0.0.1 -p 5555 -a admin -w 123456 -r "<

Попробуйте почитать по форуму самостоятельно. Повторюсь - уже не один десяток раз упоминалось Подскажу - madf недавно уже и патчи для работы на стремных версиях mysql-client выкладывал. чем версия в портах стремна? Таже самая, с некоторыми патчами. Форум читал, но видимо оно было описано в каких-то ветках - которые под мой мыленный регексп не подошли. это такая штука для неосиливших vi? Не, не слышал. vi - это такая штука, которая в одном режиме пищит, в другом режиме всё портит. Не надо свои религиозные взгляды на остальных переносить. Собирайте сами "правильно" - никто

выкидывате эти, ставьте с чипом не менее 82576. На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к. Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц. ну и посмотрите что именно проц нагружает pmcstat -S instructions -O /tmp/sample.out & sleep 30 && killall pmcstat pmcstat -R /tmp/sample.out -g && gprof -l -K

Блин. Из-за бинарной установки я даже joe невозможно установить. Конфликт версий perl5. И обновить версию через pkg upgrade невозможно, по той же причине. Вот такие они плюсы бинарников. Благо хоть quagga позволило установить... При этом из исходников позволило установить, но через pkg install - х#$. Нашёл таки как обновить перл. После обновления обновил бинарные пакеты. При этом пхп обновился без поддержки апача - пришлось пересобирать. Вот такое оно добро с бинарниками, нефиг было из линуксов подобное тянуть (намаялся еще в 9 красношапке) Благо после обновления всё продолжа

Обсуждалось минимум два-три десятка раз на этом форуме во всех ипостасиях. Начиная от банального "старгейзер не запущен" с "нету связи sgconf_xml с ним" и заканчивая нетривиальными эффектами "ой неудачный мускуль собрался" или "ой почемуто conf_sg залип". Именно поэтому, собранные и протестированные мной бинарные пакеты - святыня и pkgng пророк ее 1. Старгейзер запущен, процесс светился. 72020 ?? Ss 361:17,43 stargazer 72021 ?? I 0:01,72 stargazer: stg-exec (stargazer) В логах его было такое --------------------------------------------- Stg v. 2.408 Message qu

поставил с нуля. из портов. ничего дополнительно не ставил. сразу полез проверять добавление тарифов - нихрена, не пашет. чисто из спортивного интереса переставил снова, но только из бинарников - всё пашет. вот и что это может быть такое?

расковырял код и увидел что пользователи, бравшие кредит после обновления до текущей версии, заносятся в отдельную таблицу. записи в таблице есть Ок. Посмотрим как дальше будет работать.

я какраз читать умею а теперь еще раз повторите подвиг при установленом кредитном лимите не позволяет, так как уже есть установленный и действующий кредит. После отмены кредитного лимита и установки "Кредит до" в "нет" с возвращением 5 грн на счёт через корректировку сальдо - позволяет снова взять кредит

класс чито-чито? ок ага, за сутки до релиза 0.5.4 Потыкайте что-ли... на третьем скриншоте видна версия релиза. 0.5.4 rev 3484 потыкал. Замечательно поставило кредит.

вот ЛК пользователя вот то что ему выдаёт при запросе тарифа вот движение средств на счету пользователя кредит брал 15-05-2014, сейчас баланс отрицательный, кредитный лимит 0 Кредит - 0 Кредит до - Нет В личном кабинете не выдаётся, что кредит уже в этом месяце брался и повторно взять не возможно

не работает. SC_MONTHCONTROL=1 в конфиге включено

В логах абсолютно чисто. И в логах старгейзера, и в логах апача. Лог мускуля не ведётся за ненадобностью, но как бы то что часть данных биллингом таки пишеться - то проблема явно не в нём P.S.: это не методы администрирования. это последствия практики установки не из портов. В данном случае проще с нуля всё сделать, чем потом отлавливать баги бинарных установок и сбора старгейзера из исходников. Система пока ещё не введена в эксплуатацию P.S.S: perl-5.14.4.txz как бы уже депрекейтед и рекомендовано обновление до 5.16

вспонил. Я на этом серваке portupgrade обновлял пёрл, так как софтина какая-то с 5.14 не ставилась. Подозреваю что проблема в этом. Завтра переустановлю. Только не из бинарников, а из портов

Здравствуйте. Не знаю в чём прикол, но после обновления не добавляются тарифы Сети, сервисы, сервера доступа, конфиги DHCP, теги, виртуальные сервисы создаются и работают - тарифы нет. Ранее придобавлении тарифа редиректило на страницу его редактирования вида - http://xxx/billing/?module=tariffs&action=edit&tariffname=test12 и там была возможность правки Сейчас переход туда же, но с пустым полем имени и остальным в базу не вносится, если внести в базу руками - то отображается, но не удаляется Обновление устанавливалось на девственно чистую базу, строго по инструкциям. Н

Эквивалентен. Но в 9.2 что-то поменялось в логике поднятия-тушения интерфейсов Теперь если эта опция не прописана, то при тушении интерфейса net.inet.ip.forwarding становится в 0. не так давно в uafug эта трабла осуждалась, а я на днях лично столкнулся.

Учитывая мою встроенную офигительность и доброту, а также количество страждущих - по многочисленным заявкам в 0.5.4 начиная с ревизии 3467 ВНЕЗАПНО материализуется фича "кредитовалка принудительно не чаще одного раза в месяц". Спасибо. Очень ждём

Добавьте пожалуйста в скрипт UBinstaller добавление в rc.conf опции gateway_enable="YES" если эта опция не добавлена, то при добавлении или удалении любого сетевого интерфейса падает маршрутизация замечено на freebsd 9.2 на восьмёрке может быть и отсутствует проблема, но в десятке скорее всего повториться

а возможность сделать есть? Насколько я понимаю, всего лишь 1-2 дополнительные проверки перед разрешением на получение кредита

Здравствуйте. Используется размазанная абонплата, поэтому установка тарифа разрешена в любой день месяца Из этого вытекает проблема того, что по окончанию кредита клиент снова может включить кредит. Есть ли возможность выставить максимальную сумму возможного тарифа или запретить пользователю брать кредит повторно?

Скидка это то - на сколько в итоге меньше заплатишь, а не сколько тебе дилер досыпет. То что он досыпал - это не скидка, а подарок. И где тут сказано что подобную вещь можно делать не более раза в месяц? Можно чтобы если произошло - оно как-то в базе помечалось и для конкретного ID платежа не повторялось? Думаю вполне прозрачно и самоочевидно.

Логично - если с пользователя каждый день снимается меньше на % указанный в скидке. В документации же указано, что работает через remote ip с корректировкой сальдо, либо добавлением денег. О том что механизм не умеет обрабатывать каждый платёж один раз и каждый раз при вызове добавляет денег на счёт - в документации не указано. Если я не прав - ткните цитатой. P.S.: Не принимайте это близко к сердцу, подозреваю (хотя на 100% не уверен) - что дело не в ubilling-е, а в особенностях работы старгейзера