люди не пинайте за глупый вопрос

и просьба кто не хочет отвечать а хочет по глумится лучше вообще не пишите

Гм...
Если задать вопрос на американском форуме - получишь ответ.
Если задать вопрос на еврейском форуме - получишь вопрос.
А если задать вопрос на русском (а особенно - украинском форуме) - тебе объяснят, какой ты... дурак и куда тебе стоит отправиться со своими идиотскими вопросами.

простите, но up!

Имеем 3 канала:
1 - ADSL(4 Мбит)
2 - ADSL(4 Мбит)
3 - Радио-канал (2 Мбит)

С такими "каналами" проще повеситься

Ахренеть! Неужели уже на Украине поприжали? У нас (Молдавия) пару лет, как вообще, любой БОМЖ может заниматься предоставлением услуг связи

Шо вы такое говорите? Вопрос задал именно "системный администратор". Без более детального описания тут ничего не скажешь... А вообще тут должен гугль помочь, ибо, я думаю, тривиально все.

Как вариант - отключить логи нах... Как второй вариант - использовать т.н. ротацию логов (logrotate)

Первый вариант как бы неприемлем - как отслеживать возможные ошибки в таком случае? Тем более, думаю, что так просто этот лог не отключишь. И как его ротацию сделать, в отличие от бинарных логов, я не нашел. На ум приходит только FLUSH LOGS в кроне примерно раз в месяц. Тогда старый hostname.err переименуется в hostname.err.old. И начнется новый файл. Но это как-то "некошерно" что ли? Может еще где нужно уникальный индекс создать?

[a_eugene]

Обнаружил, что у меня файл hostname.err раздулся до 70 ГБ за год 

Валятся в него такие же ошибки про [Warning] Statement may not be safe to log in statement format.
Statement: UPDATE users_trf SET traf1=627...

Выполнил, как здесь рекомендуется

Код:

ALTER TABLE `users_trf` ADD UNIQUE (`uid`)

Но предупреждения продолжают сыпаться. a_eugene отписался, что 

отпали ошибки по тем, кто когда-то был "всегда онлайн".
Остались только "всегда онлайн", которым доступ разрешен или удаленные "всегда онлайн".

Проблема в том, что у меня все пользователи "всегда онлайн" и количество таких предупреждений просто немерянное.

Я прекрасно понимаю, что

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

Можно ли попросить совета, как сделать так, чтобы файл не раздувался от этих предупреждений?

Спасибо.

Совершенно верно. С оговоркой. Я не знаю точного механизма учета платежей. Как видно из последнего скрина, в итоге остаток на руках оказался верным, но там последний платеж давностью более месяца. А если "в реальном времени" проводить платежи, то результаты неадекватны.

По большому счету (если не брать в расчет остаток на руках, который соответствует действительности), и в последнем скрине результаты неадекватны реальному положению дел. С какого бодуна этому админу приписан остаток на 28/04/2010 в сумме 7598-93, если по моей статистике на этот день у него остаток 0,00? Он сдал тогда всю сумму наличности.

Еще раз уточню. У этого админа был массовый отток клиентов. Они были переведены в группу "Отключенные", к которой у него неполный доступ.

Поскольку не сумел вставить в предыдущий пост все скриншоты, то привожу их здесь:

Недавно было замечено.

Ситуация. Клиент отключился и переведен в группу "Отключенные". За ним остался долг и он выразил желание его погасить. Администратор, принявший оплату имеет ограниченные права на работу с группой "Отключенные", но может проводить платежи в этой группе.
Как на скриншоте 1: одна галочка дает возможность ограниченного доступа к группе (только просмотр ip, логина, ФИО, адреса), две галочки - полный доступ к группе. Отсутствие галочек - полное сокрытие группы.

Администратор провел платеж, но под его учеткой в "Платежах" сумма "на руках" не изменилась и, соответственно, этот платеж не был отображен. В тоже время под учеткой администратора, имеющего полный доступ к группе (как на скриншоте 4), эта сумма учтена. То есть получается, что принявший платеж админ и, к примеру, суперадмин видят разный остаток денег на руках.

Для того, чтобы понять, я создал тестового администратора и тестового клиента.
Для начала я дал ограниченные права администратору на группу этого клиента (скриншот 1) и провел платеж в пользу клиента от имени этого администратора (скриншот 2). Зашел в "Платежи" и понятно, что увидел там следующее: скриншот 3. Затем я дал тестовому администратору полный доступ к этой группе (скриншот 4) и обновил его страницу "Платежи". Разумеется теперь этот платеж и наличность на руках соответствует действительности (скриншот 5).

Почему так происходит, в принципе понятно: если администратор не имеет доступа к истории платежей этой группы, то и не видит платежа. Но, с другой стороны, он сам провел этот платеж, а к своим финансам у него доступ есть и должен отображаться в его платежах, не говоря уже о том, что он имеет право увидеть реальный остаток денег у себя на руках.

Почему меня беспокоит это вопрос, объясню. Мне не хочется давать полный доступ к группе "Отключенные" никому, кроме себя. Но, как и у других провайдеров, у нас бывает, что клиенты отключаются, причем клиенты, имеющие 2-х...3-х годичную историю платежей. Что происходит с наличностью "на руках" администратора при переводе его клиентов в группу "Отключенные"? Эти платежи ему уже не видны. Означает ли это, что уменьшается сумма "на руках" на сумму всех платежей этих клиентов?

Вот у нас случай: уволили администратора из-за массового отключения юзеров в его группе. Я решил заглянуть в платежи "его глазами" и увидел там этот бред: скриншот 6. Это полная история его платежей. И, хотя остаток на руках волшебным образом не изменился и соответствует действительности, тем не менее вопрос остается в силе потому, что не "исторические" давностью более месяца, а текущие платежи не учитываются в остатке на руках. Кстати, в моей учетке после первой передачи денег 910 лей, остаток на руках этого админа составляет 0,00.

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

Кто может, поясните, плз, как правильно проводить платежи при заданных условиях?

[Demeo,]

Demeo,
допустим сутки интернета стоят  1 у.е. Клиент 28-го числа в 15-00 включил себе доступ, заплатив 2 у.е. По вашей логике, клиенту должен быть открыт доступ ровно 2-е суток до 30-го числа 15-00.

А на самом деле произойдет следующее:
28-го 15:00 - к балансу добавлено 2 у.е.; доступ включен
28-го 23:59 - с баланса списано 1 у.е. за 28-е число
29-го 23:59 - с баланса списано 1 у.е. за 29-е число; на счету абонента 0 у.е., чего недостаточно для предоставления услуги 30-го числа; доступ запрещен в 00:01 (или тогда, когда у вас реально списывается абонплата, судя по вашим скринам это происходит в 2 часа ночи).

Таким образом клиент будет пользоваться интернетом менее 2-х суток. Связано это с тем, что есть некоторая дискретность в тарификации пакетов.

В моей сети и у большинства здесь присутствующих единицей измерения является месяц. Если мой клиент просрочил платеж и внес деньги 3-го числа, то никто ему эти 3 дня компенсировать не будет (сам виноват, платить надо вовремя).

Не всем администраторам нравилось такое положение дел и они "выдавили" из разработчиков посуточные платежи.

Все бы хорошо, но вам не нравится и такая дискретность, вы хотите, по сути, перейти на почасовую оплату. Скоро и этого будет недостаточно (как же так, я ворую целый час у клиента!) и будут требовать поминутной, а то и посекундной тарификации

Там бесплатный сертификат только на 90 дней.
Лучше получить здесь : http://www.startssl.com/
Дают бесплатный сертификат начального уровня на 1 год. И, что важно, подавляющее большинство браузеров принимают эти сертификаты как от доверенного поставщика.

Да нормальная это авторизация по ip-mac. Не понимаю, чего это все ее ругают У меня на доступе чужой mac на клиентском порту не пройдет, на следующем уровне агрегации происходит проверка mac-ip (не то чтобы находили хоть раз несоответствия, а так - на всякий случай). Даже без второго эшелона проверки - объясните мне как можно обойти привязку по mac?

Сделал как описал в предыдущем посте. Все работает. Всем спасибо за помощь.