Мои личное ПЕРВОЕ впечатление от версии 5 (последний 10 релиз):
"Господа, эксперименты лучше ставить в лабораторных условиях не выдавая не доработанную программу за коммерчиский продукт. Не стоит портить уже сделанное. На практике новую версию использовать крайне не удобно и сложно. Версия 4 была проще и удобнее. Не хватало только одной функции - учёт доминирующего трафика."
Впечатления о версии 5
Впечатления о версии 5
Последний раз редактировалось Денис Пн апр 25, 2005 14:01, всего редактировалось 2 раза.
Буду продолжать сообщать свои впечатления по мере продвижения.
Решил прочитать документацию (я думаю не я один такой, тем более что опыт работы с версией 4 уже есть).
Документация:
"Документации поддается пониманию при очень внимательном прочтении раза два-три. Так же необходимо произвести серию экспериментов для уверенности (обязательно во время чтения). После освоения документации, чуствуешь гордость и осознание владения особо важным секретом. Это при том, что freebsd, mysql, apache, netflow, radius не вызывают у меня особой перегрузки мозгов.
Документация несколько отстала от действительности, много не совпадает. Я прекрасно понимаю, что печатные экземляры уже не выкинешь, но электронный вариант стоило бы править.
Не очень нравятся резкие переходы из области настройки программы через интерфейс, к описанию имен таблиц в базе данных. Стоило бы разделить уровни описания на: использование программы и технические подробности построения базы данных."
ВЫВОД: ИДЕИ ЗАЛОЖЕННЫЕ В ПРОГРАММУ ОЧЕНЬ ПОНЯТНЫ И ПРАВИЛЬНЫ. ПО ДОКУМЕНТАЦИИ ВПЕЧАТЛЬНИЕ ТЯЖЕЛОЕ.
Решил прочитать документацию (я думаю не я один такой, тем более что опыт работы с версией 4 уже есть).
Документация:
"Документации поддается пониманию при очень внимательном прочтении раза два-три. Так же необходимо произвести серию экспериментов для уверенности (обязательно во время чтения). После освоения документации, чуствуешь гордость и осознание владения особо важным секретом. Это при том, что freebsd, mysql, apache, netflow, radius не вызывают у меня особой перегрузки мозгов.
Документация несколько отстала от действительности, много не совпадает. Я прекрасно понимаю, что печатные экземляры уже не выкинешь, но электронный вариант стоило бы править.
Не очень нравятся резкие переходы из области настройки программы через интерфейс, к описанию имен таблиц в базе данных. Стоило бы разделить уровни описания на: использование программы и технические подробности построения базы данных."
ВЫВОД: ИДЕИ ЗАЛОЖЕННЫЕ В ПРОГРАММУ ОЧЕНЬ ПОНЯТНЫ И ПРАВИЛЬНЫ. ПО ДОКУМЕНТАЦИИ ВПЕЧАТЛЬНИЕ ТЯЖЕЛОЕ.
Без обид.Денис писал(а):Буду продолжать сообщать свои впечатления по мере продвижения.
Решил прочитать документацию (я думаю не я один такой, тем более что опыт работы с версией 4 уже есть).
Но думаю что подобные коментраии уже немного устарели, и они скорее в раздел чуть ниже. Здесь же разгребают проблемы а не документацию.
Я вот лично последние релиза 3-4 ее вообще не читал.
Вот если бы указывались конкретные ошибки, или какие-нибудь неточности - вот это думаю было бы гораздо интереснее
ИМХО конечно...
-
Archangel aka Reystlin
- Сообщения: 1
- Зарегистрирован: Вт апр 26, 2005 17:26
- Откуда: г. Дмитров
- Контактная информация:
Уважаемы коллектив NetUP, не примите мое сообщение за агрессивную критику, и я не нзнаю где этот топик ниже.
Изучал UTM5 под Linux Redhat 9.0, так никаких результатов добится не удалось. Могу быть не профессионалом в таких деалах, я могу не знать как действительно хорошо настроить UTM5, но я очень хорошо знаю что такое ПО под линуксом.
К слову, имхо, документация по UTM5 не читается вообще никак. Даже после того как я три раза прочел книгу, мне не удалось запомнить ничего, не говоря уж понимании основ работы с UTM5. Это самый большой минус. Уважемый NetUP, посмотрите в исходники любого линуксового софта, неужели там все написано так? У меня тоже не составляет особой проблемы прочитать rfc по netflow или man к apache и mysql, тем более что интуитивно понятно какой файл там к чему и собственно чего там зависит от чего. Обратите внимание, именно интуитивно. В то время как UTM5 не похож ни на что.
Разве соблюдение стандартов, простота и легкость в организации ПО уже забыта? Разве это не вызывает уважения у пользователей и к этому не надо стремится?
Изучал UTM5 под Linux Redhat 9.0, так никаких результатов добится не удалось. Могу быть не профессионалом в таких деалах, я могу не знать как действительно хорошо настроить UTM5, но я очень хорошо знаю что такое ПО под линуксом.
К слову, имхо, документация по UTM5 не читается вообще никак. Даже после того как я три раза прочел книгу, мне не удалось запомнить ничего, не говоря уж понимании основ работы с UTM5. Это самый большой минус. Уважемый NetUP, посмотрите в исходники любого линуксового софта, неужели там все написано так? У меня тоже не составляет особой проблемы прочитать rfc по netflow или man к apache и mysql, тем более что интуитивно понятно какой файл там к чему и собственно чего там зависит от чего. Обратите внимание, именно интуитивно. В то время как UTM5 не похож ни на что.
Разве соблюдение стандартов, простота и легкость в организации ПО уже забыта? Разве это не вызывает уважения у пользователей и к этому не надо стремится?
Ок, я просто расчитывал на тех, кто станет новым пользователем.
У себя я всё установил и всё работает.
Общий итог:
Мне нравится, но есть мелкие не дочеты:
1) Документация не успевает за развитием
2) Мусор из базы данных в поставке надо вычистить (у меня оказалось несколько карточек уже сгенерировано, на какую сумму я считать не стал, но возможно она сравнима со стоимостью биллинга).
3) Заменить в интерфейсе пользователя такие выражения как "Тело сообщения" на "Текст сообщения"
4) Сделать интрефейс пользователя настраиваемым по принципу показывать / не показывать (это всё равно все делают руками)
При желании всё устанавливается, пускай и не с первой попытки.
У себя я всё установил и всё работает.
Общий итог:
Мне нравится, но есть мелкие не дочеты:
1) Документация не успевает за развитием
2) Мусор из базы данных в поставке надо вычистить (у меня оказалось несколько карточек уже сгенерировано, на какую сумму я считать не стал, но возможно она сравнима со стоимостью биллинга).
3) Заменить в интерфейсе пользователя такие выражения как "Тело сообщения" на "Текст сообщения"
4) Сделать интрефейс пользователя настраиваемым по принципу показывать / не показывать (это всё равно все делают руками)
При желании всё устанавливается, пускай и не с первой попытки.
Я бы ещё добавил пожеланий:
1. Прекратить смешивать в интерфейсе аглицкий с рязанским - сообщения типа "Do you wish to continue? <Да><Нет>" раздражают. Неужели UTM предпочтительно ориентирована на западный рынок? Судя по тому что основной интерфейс английский похоже да.
2. Оптимизировать хоть немножко обмен по сети с админским интерфейсом - когда нажатие на кнопку вызова диалога выбора периода вызывает трафик по сети от 30 до 70 кбайт - это тоже раздражает. Особенно когда по модему приходится заходить.
3. Почитать разработчикам в конце концов какой-нибудь букварь по созданию оконного интерфейса - чтобы при открытии окна фокус помещался в поле которое заполнять первым, чтобы <Enter> вызывала кнопку подтыверждения по умолчанию а <Esc> - отказ по умолчанию и так далее.
4. Сделать простую и понятную модель календарных периодов а не этих автосгенеренных которые во-первых базу засоряют во-вторых вылазят или сменяются без предупреждения когда ни попадя
0. !!!!!! И в конце концов - если изделие позиционируется как законченная программа а не полуфабрикат OpenSource - завести у себя тестировщика и НЕ ВЫКЛАДЫВАТЬ НИЧЕГО БЕЗ ПОЛНОГО ТЕСТИРОВАНИЯ. То есть после каждого изменения в программе требуется тестирование всех функций в том числе и тех что уже были оттестированы в прошлых релизах - могли же и отвалится при переделках. Правда грамотно составить программу тестирования тоже работа немаленькая, студент за 100 баксов по вечерам с этим вряд ли справится.... Но что я рассказываю, авторы же программисты, и сами должны прекрасно знать технологию производства и тестирования программ.... И если выпускают такую сырую вещь значит сознательно экономят.
1. Прекратить смешивать в интерфейсе аглицкий с рязанским - сообщения типа "Do you wish to continue? <Да><Нет>" раздражают. Неужели UTM предпочтительно ориентирована на западный рынок? Судя по тому что основной интерфейс английский похоже да.
2. Оптимизировать хоть немножко обмен по сети с админским интерфейсом - когда нажатие на кнопку вызова диалога выбора периода вызывает трафик по сети от 30 до 70 кбайт - это тоже раздражает. Особенно когда по модему приходится заходить.
3. Почитать разработчикам в конце концов какой-нибудь букварь по созданию оконного интерфейса - чтобы при открытии окна фокус помещался в поле которое заполнять первым, чтобы <Enter> вызывала кнопку подтыверждения по умолчанию а <Esc> - отказ по умолчанию и так далее.
4. Сделать простую и понятную модель календарных периодов а не этих автосгенеренных которые во-первых базу засоряют во-вторых вылазят или сменяются без предупреждения когда ни попадя
0. !!!!!! И в конце концов - если изделие позиционируется как законченная программа а не полуфабрикат OpenSource - завести у себя тестировщика и НЕ ВЫКЛАДЫВАТЬ НИЧЕГО БЕЗ ПОЛНОГО ТЕСТИРОВАНИЯ. То есть после каждого изменения в программе требуется тестирование всех функций в том числе и тех что уже были оттестированы в прошлых релизах - могли же и отвалится при переделках. Правда грамотно составить программу тестирования тоже работа немаленькая, студент за 100 баксов по вечерам с этим вряд ли справится.... Но что я рассказываю, авторы же программисты, и сами должны прекрасно знать технологию производства и тестирования программ.... И если выпускают такую сырую вещь значит сознательно экономят.
размышления
На самом деле ситуация гораздо хуже. Ошибки в интерфейсе, неправильный фокус ввода – это «детские болезни» по сравнению с тем чем приходится сталкиваться на деле. В нашей компании NETUP используется более двух лет, и я знаю о чем говорю. Я уже привык к тому, что я ядро падает и не запускается до тех пор пока не откатишь базу до бакапа недельной давности (и все это без каких либо сообщений в файл отладки!). Было два случая, при которых пуск ядра становился возможен только при удаления файла детализации. С удивлением читаю на форуме отзывы людей у которых работает «родной» радиус сервер. У меня с включенным аккаунтингом падает через 2 часа а при при включенной авторизации при первом же звонке.
Вы спросите почему я пишу это на форуме? Я тоже удивлялся подобным статьям, пока не оплатил полугодовую тех. поддержку. Наиболее точные слова чтоб ее охарактеризовать – это «вяло» и «неэффективно». Средняя реакция на кейс от 6 часов до полутора суток. Помогают непосредственный звонки, но толку от них немного, да и что в принципе может сделать даже грамотный специалист, если есть ошибки в разработке? Спасибо им, у них благородная задача – поддерживать веру в светлое будущее (простите, в новый билд. Который «скоро выйдет», но сборка выходит какие-то ошибки устраняют, как-то нет и конечно делают новые ). Как это все органично вписывается в российскую действительность!
Общался со специалистом из одной известной телефонной компании, купили они биллинг одной Е-бургсой конторы - дороже UTM на порядок. Не могут внедрить – «сваливается после месяца неинтенсивной работы». Спрашивается «Зачем платить больше?». Деньги им конечно не вернули.
Хорошим выходом было бы дописывать свои «костыли» к некой минимальной конструкции тупой и простой, но разработчики UTM5 сделали все чтоб усложнить эту задачу (кто пытался разобраться в таблицах с взаимосвязями призванными, по всей вероятности, повысить нагрузку на CPU и все по возможности запутать, поймет меня)
Вы спросите почему я пишу это на форуме? Я тоже удивлялся подобным статьям, пока не оплатил полугодовую тех. поддержку. Наиболее точные слова чтоб ее охарактеризовать – это «вяло» и «неэффективно». Средняя реакция на кейс от 6 часов до полутора суток. Помогают непосредственный звонки, но толку от них немного, да и что в принципе может сделать даже грамотный специалист, если есть ошибки в разработке? Спасибо им, у них благородная задача – поддерживать веру в светлое будущее (простите, в новый билд. Который «скоро выйдет», но сборка выходит какие-то ошибки устраняют, как-то нет и конечно делают новые ). Как это все органично вписывается в российскую действительность!
Общался со специалистом из одной известной телефонной компании, купили они биллинг одной Е-бургсой конторы - дороже UTM на порядок. Не могут внедрить – «сваливается после месяца неинтенсивной работы». Спрашивается «Зачем платить больше?». Деньги им конечно не вернули.
Хорошим выходом было бы дописывать свои «костыли» к некой минимальной конструкции тупой и простой, но разработчики UTM5 сделали все чтоб усложнить эту задачу (кто пытался разобраться в таблицах с взаимосвязями призванными, по всей вероятности, повысить нагрузку на CPU и все по возможности запутать, поймет меня)
Радиус нетаповский у меня работает. Возможно потому что установлено на системе для который собрано (вроде бы) - RedHat9. Только раз в один-два дня приходится перезапускать весь биллинг из-за того что радиус забывает освободить клиентский адрес после отбоя. Применил все "лекарства" посоветованные в форуме - так и продолжается.
Обновляться на 10 версию боюсь - больно много в форуме сообщений у кого что отвалилось после перехода на неё.
Обновляться на 10 версию боюсь - больно много в форуме сообщений у кого что отвалилось после перехода на неё.
И кстати насчёт совсем тупой конструкции:
вот пример, тупее некуда
http://sergkz.sayan.ru/traf_mysql.html
вот пример, тупее некуда
http://sergkz.sayan.ru/traf_mysql.html
Re: размышления
Полностью согласен со всем постом. К аналогичному выводу пришел после года использования UTM5 с тестовой нагрузкой до 50 человек (PPPoE). Хорошо еще что прикрутил скрипт, который регулярно проверял способность радиуса на авторизацию, и перезагружал весь биллинг (ядро и радиус) в противном случае, что происходило с периодичностью от одного раза в день до раза в неделю.angst писал(а): Хорошим выходом было бы дописывать свои «костыли» к некой минимальной конструкции тупой и простой
Теперь нашел "минимальную конструкцию" в виде FreeNIBS, которую за неделю заточил под свои задачи и пока доволен. Может функционал там и не такой навороченный, как у UTM, но то что заявлено, работает без проблем. И всегда есть исходники, которые можно исправить и дополнить. Похоже, что для провайдеров крупнее небольших домовых сетей коробочный биллинг типа UTM - несбыточная мечта...
Re: размышления
sg писал(а):Полностью согласен со всем постом. К аналогичному выводу пришел после года использования UTM5 с тестовой нагрузкой до 50 человек (PPPoE). Хорошо еще что прикрутил скрипт, который регулярно проверял способность радиуса на авторизацию, и перезагружал весь биллинг (ядро и радиус) в противном случае, что происходило с периодичностью от одного раза в день до раза в неделю.angst писал(а): Хорошим выходом было бы дописывать свои «костыли» к некой минимальной конструкции тупой и простой
Теперь нашел "минимальную конструкцию" в виде FreeNIBS, которую за неделю заточил под свои задачи и пока доволен. Может функционал там и не такой навороченный, как у UTM, но то что заявлено, работает без проблем. И всегда есть исходники, которые можно исправить и дополнить. Похоже, что для провайдеров крупнее небольших домовых сетей коробочный биллинг типа UTM - несбыточная мечта...
Летом прошлого года мы купили пятый УТМ 5.1.6. Сколько с ним было гемороя...
То пользователи не удалялись, то классы трафика, то еще что, то еще.... что... )))) Итак постепенно дошел до 5.1.9(006). В итоге работает нельзя сказать что идеально... Однако ndsad не отваливался не разу... Радиус подвисает, но не так часто. Но хочется верить в лучшее, и мне кажется что его доведут до ума. А то действительно уже надоело.... Кстати когда мы покупали 5-й, нетаповцы дали нам еще и 4-й на диске... И только через неделю мы поняли почему ). Потому что пятый был вообще сырым если не более.Но зато хоть бетатестром побыли...Да и в принципе мы и сейчас ими и являемся... Потому как считаю что билинг еще не доведен до ума. Хотя к примеру BillMaster инлайна стоит намного намного дороже ), а функционал тотже. В нашем городе стоит у одного прова... Так там делать особо ничего не надо, извратом страдать не надо... Как говорится напильником работать... А нетап это сила, тут нужно уже самому его натачивать... ))) В этом и есть самое классное его свойство ). Еще к примеру могу сказать, что скрипт бэкапа утм появился только в 5.1.9... Скрипт автозагрузки радиуса... итд итп...
Когда я его уже сам давно написал...
Короче поэтому поводу можно много говорить
Но все-таки я верю что все будет хорошо
Re: размышления
К сожалению, как раз наточить его особо и не получается. Все скомпилировано и, соответственно, изменению не поддается. И если радиус падает, то кроме дополнительных скриптов тут ничем не поможешь. К тому же, раздражает избирательное исправление багов. К примеру, проблема с невыдачей дополнительный радиус аттрибутов первый раз была поднята полгода назад, и до сих пор одни обещания. И это при том, что это стандарная и заявленная нетапом функция радиус-сервера, которая незаменима для организации callback'a, динамического ограничения скорости vpn и многого другого. Поэтому в итоге - переход на другой бесплатный биллинг после выкидывания на ветер $1000gtk писал(а):А нетап это сила, тут нужно уже самому его натачивать... ))) В этом и есть самое классное его свойство ).
Как я и говорил уже раньше, все зависит от объема использования функционала UTM. Одно определенно - НЕ ВСЕ заявленные в UTM функции работают. И как только ты вынужден использовать неработающий или криво работающий функционал, начинаются сплошные проблемы. Если же Нетап говорит, что в UTM есть то и это, а на самом деле это не работает, то это получается обман. Делайте выводы...kop писал(а):Парни честно поставил ЮТМ 5 последний билд. Да возникли проблемы по отладки системы недельки 2 и все уже 2 месяца ниразу не трогал ничего, только мелкие проблемы ну как выяснилось проблемы были из за кривых рук моих. А так система работает отлично.