Ubilling + Vlan'per'User.

[nightfly 1 241]

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

Для этого название есть в медицине, даже подскажу какое - Dementia praecox.

 

С точки зрения реализации это выглядит так: при совершении каждого платежа, каждым абонентом порождается некий персональный тарифный план, с временем действия от "момента совершения платежа" и временем окончания до "хрен знает когда". Также каждую секунду старгейзер теоретически должен проверять "а не создать ли еще один абстрактный тарифный план для каждого абонента?", "а не пора ли отключить абонента вася?" плюс решать по дороге проблемы смещений времени окончания действия тарифа для каждого абонента, чтобы учитывать тот факт, что платежей в "учетный период" может быть не только один. Также придется решать кучу менее очевидных проблем, таких как "я платил 13-го числа в 9 утра, а потом еще 5 денег, 14-го в 8 утра почему у меня интернет отключился в 8?", а также еще с пол сотни вариаций самонаебок на уровне функционирования сервисов кредитования, смены тарифа и заморозки. С точки зрения быстродействия такого "решения".... даже думать не хочется, как это должно работать при 10-15-20 тысячах абонентов (напоминаю - у каждого свой тариф, и каждый ежесекундно должен проверяться не кончился ли он). Интуиция подсказывает, что продуктивность такого решения будет падать в геометрической прогрессии по формуле (количество пользователей*количество их тарифов), хотя вполне возможно если вдуматься, при некоторых раскладах хрень которую для обеспечения вот всего этого должен будет производить старгейзер ежесекундно может увеличиваться по факториалу.

 

Самим то не смешно?

 

 

 

например один - шахтер, и у него зарплата 7 числа, ну и пусть он платит каждого 9 или 10,

Нет, поддержки шахтеров в Ubilling нет.  Если превалирующая абонентов хочет платить 7-го числа - нет проблем, начисляем АП 7-го.

 

 

И я как бы не на обсуждение вынес это мое решение сделать именно так, а спросил, можно ли сделать так в Ubilling?

Нет, поскольку как уже неоднократно говорилось - Ubilling не обладает, и не будет обладать врожденной поддержкой шизофрении.

 

Именно поэтому, я еще раз намекнул на FAQ, который вы так настойчиво игнорируете. Намекну точнее - вас должен интересовать последний пункт.

Відредаговано 2014-10-23 13:29:48 nightfly

[nightfly 1 241]

так вы уменьшите себе доходы

Все верно. Провайдеры, как и любой другой бизнес думают о получении и максимизации прибыли и оптимизации бизнес процессов.

А это у человека - просто какие-то фантазии далекие от реальности.

Відредаговано 2014-10-23 13:51:04 nightfly

[Archy_k 14]

Спасибо большое, за инфу.

 

 

Именно поэтому, я еще раз намекнул на FAQ, который вы так настойчиво игнорируете. Намекну точнее - вас должен интересовать последний пункт.

Заглянул в FAQ еще раз, ну и послений пункт перечитал, прошу прощения... не хотел именно так выглядеть!

 

 

С точки зрения реализации это выглядит так: при совершении каждого платежа, каждым абонентом порождается некий персональный тарифный план, с временем действия от "момента совершения платежа" и временем окончания до "хрен знает когда". Также каждую секунду старгейзер теоретически должен проверять "а не создать ли еще один абстрактный тарифный план для каждого абонента?", "а не пора ли отключить абонента вася?" плюс решать по дороге проблемы смещений времени окончания действия тарифа для каждого абонента, чтобы учитывать тот факт, что платежей в "учетный период" может быть не только один. Также придется решать кучу менее очевидных проблем, таких как "я платил 13-го числа в 9 утра, а потом еще 5 денег, 14-го в 8 утра почему у меня интернет отключился в 8?", а также еще с пол сотни вариаций самонаебок на уровне функционирования сервисов кредитования, смены тарифа и заморозки. С точки зрения быстродействия такого "решения".... даже думать не хочется, как это должно работать при 10-15-20 тысячах абонентов (напоминаю - у каждого свой тариф, и каждый ежесекундно должен проверяться не кончился ли он).

У меня по-видимому реализовано не так, кардинально по другому, но это не суть важно... 

Просто хочу оставить некоторые моменты как есть, как привыкли, и как считаю нужным, при этом интересуюсь, возможно ли этот момент в Ubilling'e сделать так как я описал. - Вы ответили: "Нет." - ну нет, и нет...)))) 

@@nightfly, спасибо большое за помощь. Хотел добавить, что как-раз таки такая схема у меня сейчас работает, и люди очень хвалят ёё за удобство, хотя Вы называете эту схему "шизофренией" и прочими диагнозами и т.д. ,ну я думаю, что вы по-своему правы, если ваши абоненты привыкли к вашей схеме.

 

 

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

С этим не соглашусь, потому что многие люди не платят за пол месяца цену всего месяца, а сидят упорно ждут 1го числа.

Например: "нафига платить, я все равно 5-го числа уежаю на 10 дней, а когда приеду - разберусь" , "нафига я буду платить 15го числа за пол месяца, как за месяц. пойду пока с кентами пивка попью, давно не видел, а уж с 1го числа пополню" => 1 такой абонент, незаплативший по такой причине за месяц, даст Вам финансового ущерба как мои 15 человек, просрочившие по 2 дня, включившиеся 15, или 20, или 27 числа месяца, сразу как приехали с отпуска или рыбалки или охоты или сразу после отключения интернета и т.д.

В итоге это "палка о двух концах", и это просто выбор провайдера - как на его взгляд выгоднее! 

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

[l1ght 377]

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

http://wiki.ubilling.net.ua/doku.php?id=start#%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%BE%D0%B5_%D1%81%D0%BE%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD%D0%B8%D0%B5

Відредаговано 2014-10-23 19:45:26 L1ght

[KaYot 3 711]

 

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

Для этого название есть в медицине, даже подскажу какое - Dementia praecox.

 

С точки зрения реализации это выглядит так: при совершении каждого платежа, каждым абонентом порождается некий персональный тарифный план, с временем действия от "момента совершения платежа" и временем окончания до "хрен знает когда". Также каждую секунду старгейзер теоретически должен проверять "а не создать ли еще один абстрактный тарифный план для каждого абонента?", "а не пора ли отключить абонента вася?" плюс решать по дороге проблемы смещений времени окончания действия тарифа для каждого абонента, чтобы учитывать тот факт, что платежей в "учетный период" может быть не только один. Также придется решать кучу менее очевидных проблем, таких как "я платил 13-го числа в 9 утра, а потом еще 5 денег, 14-го в 8 утра почему у меня интернет отключился в 8?", а также еще с пол сотни вариаций самонаебок на уровне функционирования сервисов кредитования, смены тарифа и заморозки. С точки зрения быстродействия такого "решения".... даже думать не хочется, как это должно работать при 10-15-20 тысячах абонентов (напоминаю - у каждого свой тариф, и каждый ежесекундно должен проверяться не кончился ли он). Интуиция подсказывает, что продуктивность такого решения будет падать в геометрической прогрессии по формуле (количество пользователей*количество их тарифов), хотя вполне возможно если вдуматься, при некоторых раскладах хрень которую для обеспечения вот всего этого должен будет производить старгейзер ежесекундно может увеличиваться по факториалу.

 

Самим то не смешно?

 

Глупости написаны.

Наш биллинг работает именно по такому принципу, удобно нам, удобно клиентам. 99% клиентов оплачивает наперед, нынче никто не хочет остаться без инета.

1-2% недополученной прибыли из-за задержек в оплате с лихвой перекрываются благосклонностью клиентов и нашим добрым именем - в итоге рост прибыли из-за конкурентного преимущества.

Загрузка сервера средней конфигурации при 10к абонентов нулевая. Можете пофантазировать, что будет при 15-20к

Заодно нет никаких очередей 1ого числа и ежемесячного ахтунга с оплатами. Все плавно и размеренно, ежедневный плановый приход денег.

[nightfly 1 241]

 2 KaYot

 

Наш биллинг работает именно по такому принципу

OpenSource? Можно скачать? Апдейты часто выходят? Много платежных систем поддерживает? Много внедрений уже?

Уже все бросаю и мигрирую, а то достало все.

 

 

Загрузка сервера средней конфигурации при 10к абонентов нулевая. Можете пофантазировать, что будет при 15-20к

Мне не нужно фантазировать. Могу просто посмотреть в uptime.

load averages: 0.20, 0.36, 0.44 - и да, это на древнем и мрачном Q6600. 18к живых клиентов на тоже древнем xeon 3440 в свою очередь говорят, что load averages: 0.23, 0.31, 0.32 Это без использования внешних коллекторов нетфлова.

14к юзеров с вырубленным cap_nf улыбаются load averages: 0.03, 0.09, 0.08

 

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

Основная проблема местных "аналитиков" и гуру биллингосторительства в том, что они выебываются несуществующими в дикой природе поделками которых никто не видел и скорее всего никогда не увидит.

[KaYot 3 711]

Основная проблема местных "аналитиков" и гуру биллингосторительства в том, что они выебываются несуществующими в дикой природе поделками которых никто не видел и скорее всего никогда не увидит.

Казалось бы, к чему весь этот понос? Ты обосрал предложенную схему с плавающим расчетным периодом, я показал что она работает и весьма удобна. До этого были схемы с посуточным(мрак и недополучение) и ежемесячным(постоянные обиды клиентов и перерасчеты) снятием, остановились на плавающем.

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

 

Да, наша система ниразу не opensource, а купленный дорогой коробочный биллинг. Можете купить, посмотреть.

[l1ght 377]

С точки зрения реализации это выглядит так: при совершении каждого платежа, каждым абонентом порождается некий персональный тарифный план, с временем действия от "момента совершения платежа" и временем окончания до "хрен знает когда". Также каждую секунду старгейзер теоретически должен проверять "а не создать ли еще один абстрактный тарифный план для каждого абонента?", "а не пора ли отключить абонента вася?" плюс решать по дороге проблемы смещений времени окончания действия тарифа для каждого абонента, чтобы учитывать тот факт, что платежей в "учетный период" может быть не только один. Также придется решать кучу менее очевидных проблем, таких как "я платил 13-го числа в 9 утра, а потом еще 5 денег, 14-го в 8 утра почему у меня интернет отключился в 8?", а также еще с пол сотни вариаций самонаебок на уровне функционирования сервисов кредитования, смены тарифа и заморозки. С точки зрения быстродействия такого "решения".... даже думать не хочется, как это должно работать при 10-15-20 тысячах абонентов (напоминаю - у каждого свой тариф, и каждый ежесекундно должен проверяться не кончился ли он). Интуиция подсказывает, что продуктивность такого решения будет падать в геометрической прогрессии по формуле (количество пользователей*количество их тарифов), хотя вполне возможно если вдуматься, при некоторых раскладах хрень которую для обеспечения вот всего этого должен будет производить старгейзер ежесекундно может увеличиваться по факториалу.  

 

Я гадаю що реалізація може бути простіше в рази.

З точки зору старгейзеру - можливо ви праві, але розглядувати це з точки зору "робити з нуля" - то там вийде все простіше. 

Відредаговано 2014-10-24 07:35:37 L1ght

[Archy_k 14]

 

С точки зрения реализации это выглядит так: при совершении каждого платежа, каждым абонентом порождается некий персональный тарифный план, с временем действия от "момента совершения платежа" и временем окончания до "хрен знает когда". Также каждую секунду старгейзер теоретически должен проверять "а не создать ли еще один абстрактный тарифный план для каждого абонента?", "а не пора ли отключить абонента вася?" плюс решать по дороге проблемы смещений времени окончания действия тарифа для каждого абонента, чтобы учитывать тот факт, что платежей в "учетный период" может быть не только один. Также придется решать кучу менее очевидных проблем, таких как "я платил 13-го числа в 9 утра, а потом еще 5 денег, 14-го в 8 утра почему у меня интернет отключился в 8?", а также еще с пол сотни вариаций самонаебок на уровне функционирования сервисов кредитования, смены тарифа и заморозки. С точки зрения быстродействия такого "решения".... даже думать не хочется, как это должно работать при 10-15-20 тысячах абонентов (напоминаю - у каждого свой тариф, и каждый ежесекундно должен проверяться не кончился ли он). Интуиция подсказывает, что продуктивность такого решения будет падать в геометрической прогрессии по формуле (количество пользователей*количество их тарифов), хотя вполне возможно если вдуматься, при некоторых раскладах хрень которую для обеспечения вот всего этого должен будет производить старгейзер ежесекундно может увеличиваться по факториалу.  

 

Я гадаю що реалізація може бути простіше в рази.

З точки зору старгейзеру - можливо ви праві, але розглядувати це з точки зору "робити з нуля" - то там вийде все простіше. 

 

В мене простіше, якщо цікавить, можу розказати як воно процює в мене...

Немає в кожного абона свого тарифного плану. 

Я вважаю, що є декілька шляхів реалізації данного питання, та не обов'язково робити це з використанням "кожному абоненту власний таифний план". Одже це взагалі побічне питання...

 

Ця тема створена, для того, щоб з початку і до кінця підняти сервер з Ubilling власноруч, та причепити до нього схему обмеження абонентів один від одного - "Vlan'per'User", одже крок за кроком я хочу че зробити, та по ходу виникнення питань, прошу допомогу у тих, хто розуміє більше та кращє за мене! 

Відредаговано 2014-10-24 08:12:29 Archy_k

[l1ght 377]

Ну модуль для біллінгу влан пер юзер буде готовий десь с понеділка.

Потім піде на одобрення до найтфлаю, і якщо все ок - то піде в карент і ви зможете побачити його в стандартній системі.

Якщо цікавлять детялі - в л.с. пишіть, відповім на усе, що цікавить.

[Lynx100 90]

Ну модуль для біллінгу влан пер юзер буде готовий десь с понеділка.

Потім піде на одобрення до найтфлаю, і якщо все ок - то піде в карент і ви зможете побачити його в стандартній системі.

Якщо цікавлять детялі - в л.с. пишіть, відповім на усе, що цікавить.

чому в ЛС? людям буде цікаво напевно тут почитати ...

чим будете роздавати адреси? стандартним dhcpd чи чимось іншим? буде функціонал типу unnumbered ? буде використовуватися options82 чи без ?

[l1ght 377]

Так, можу на публіку, мені не важко.

Я планую робити наступну зв'язку:

Сервер дхцп - исц дхцп стандартний.

Далі особисто в мене планується, що буде стояти циска - яка робить аннамберед, та релей+снупинг.

 

Що робитеметься засобами біллінгу:

1)конфіг дхцп, де віддаємо айпішку по номеру влана

2)засобами біллінгу виділити юзеру перший вільний влан (влани генеруються пулами, в окремому модулі)

3)скриптом підіймаємо влан на ціско, та на влані підіймаємо релей, та аннамберед

4)скрипт-шаблон для конфігу свічів на доступі

 

Зараз як раз тести проводжу.

 

Що планується ще:

1)Повна підтримка QinQ

2)збільшити кількість свічів на доступі, які конфігурятся з біллінгу.

3)аннамеберед на лінуксі та фрібсд

Відредаговано 2014-10-24 10:53:20 L1ght

[nightfly 1 241]

Казалось бы, к чему весь этот понос?

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

 

 

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

На этом форуме повторюсь - штуки 4 человека имеющих, хоть какое-то отношение к теме разработки универсальных АСР, и мысли которых для меня были действительно интересными и поучительными.

Я думаю не стоит объяснять второй раз, что на твое "авторитетное" мнение в области биллингостроения мне банально насрать?

 

 

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

А мешки все так же стоят не ворочаными...

 

 

Да, наша система ниразу не opensource

ми-ми-ми

 

 

а купленный дорогой коробочный биллинг.

пфффф

 

 

Можете купить, посмотреть.

Нет, в отличии от вас мозгоебов - я способен самостоятельно делать то что нужно мне.

 

А да, с памятью у меня все ок:

 

 

Відредаговано 2014-10-24 10:21:36 nightfly

[KaYot 3 711]

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

Наша куча костылей плавающие периоды умеет, ваша - нет.

[nightfly 1 241]

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

Хотите продолжить? Ок.

 

Главное, чтобы вы раз и навсегда уяснили разницу между нами. Она укладывается только за последний год, чуть менее чем в две минуты:

 

 

Если визуально не понятно, перефразирую как для особо маленьких и тупых буду объяснять простыми тезисами:

 

1. Мы, что-то делаем - причем опенсорс, слушая адекватное комьюнити, этим пользуется не одна и не две сотни сетей.

2. Вы - пиздyн-сказочник, на чье "авторитетное мнение в сфере разработки АСР" который в отличии от мнения практиков, в виде тех же деда, асмодеуса, демиурга (да у нас разные ниши - у них зарабатывание бабла, у меня - чад и кутеж угара) или скажем мадфа - глубоко насрать.

 

 

Наша куча костылей плавающие периоды умеет, ваша - нет.

1. Их никто не видел и не увидит.

2. Если и видел - вы к их существованию не имеете отношения

3. Любая волшебная хyйня может существовать в ваших фантазиях, только реальность такова, что там она и останется нужной только вам.

4. Умеет, ровно на том уровне на котором это действительно нужно, хотя не вижу особого смысла разбрасывать перед вами бисер.

Відредаговано 2014-10-24 11:45:35 nightfly

[nightfly 1 241]

Потім піде на одобрення до найтфлаю, і якщо все ок - то піде в карент і ви зможете побачити його в стандартній системі.

До речі - а шо ви там з RemoteAPI хотіли? І як воно планується використовуватись?

Відредаговано 2014-10-24 11:49:13 nightfly

[l1ght 377]

 

Потім піде на одобрення до найтфлаю, і якщо все ок - то піде в карент і ви зможете побачити його в стандартній системі.

До речі - а шо ви там з RemoteAPI хотіли? І як воно планується використовуватись?

 

Ні, ремоут апі там не використувується.

 

Мене більше цікавить, як краще зробити передачу данних на циску, та свічі доступу...

В своїх цілях використовую expect, але коли його викликаешь через пхп, треба через кожний крок в скрипті тицяти "sleep .1".

Що робить процедуру дещо довшою, замість 0.3 секунди на всю процедуру без сліпів - зі сліпами треба як найменше 0.7 секунд.

Відредаговано 2014-10-24 12:11:55 L1ght

[nightfly 1 241]

 

 

Ні, ремоут апі там не використувується.

Значить Демонідзе даремно мене налякав і змився

 

 

Мене більше цікавить, як краще зробити передачу данних на циску, та свічі доступу...

snmp/radius?

 

 

В своїх цілях використовую expect, але коли його викликаешь через пхп, треба через кожний крок в скрипті тицяти "sleep .1".

Та да - воно надто повільне саме по собі виходить. Уже писав свого часу, пинання одної залізки telnet-ом - на те боляче дивитись.

 

 

Що робить процедуру дещо довшою, замість 0.3 секунди на всю процедуру без сліпів - зі сліпами треба як найменше 0.7 секунд.

Тепер множимо скажімо на кіло-півтора залізок в довіднику обладнання і йдемо сушити весла, да

[l1ght 377]

Тепер множимо скажімо на кіло-півтора залізок в довіднику обладнання і йдемо сушити весла, да

 

Ну один порт на одній залізяци за один раз і сейв конфігу на свічі, то не треба вливати за раз на усі свічі

 

От з снмп не надто дружу.

Скажімо мені тре залогінитись на циску і вкормити їй:

enable
configure terminal
int vlan 300
ip helper-address 192.168.20.1
ip unnumbered loopback100
end
write
exit
exit

І як ото зробити засобами радіусу або снмп, не підкажете?)))

Відредаговано 2014-10-24 12:23:08 L1ght

[nightfly 1 241]

І як ото зробити засобами радіусу або снмп, не підкажете?)))

Думаю якось так: http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/45080-vlans.html

 

Енівей воно в будь-якому випадку виходить все дуже вендоро-залежним.

Відредаговано 2014-10-24 12:26:51 nightfly

[l1ght 377]

 

І як ото зробити засобами радіусу або снмп, не підкажете?)))

Думаю якось так: http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/45080-vlans.html

 

Енівей воно в будь-якому випадку виходить все дуже вендоро-залежним.

 

По перше, цеж опен сурс? Тому що нема стандарту в цьому плані - от і виходить вендорозалежно. У вашому випадку, коли все живе на фрях - то тут проблеми не буде.

По друге - аннамберед (чи подібність аннамбереду) буде підтримуватися на cisco, freebsd, linux.

На циско в мене живе релей+снупінг, в випадку фрі\лінуху тре дхцп біндити на ло0 та кидати релей на нього, якщо це одна машина. Тобто НАС+термінатор вланів.

Якщо в когось є джуніпер\etc і в нього аннамберед (у всіх по своєму) - то ніхто не заважає написати самому до нього такий скрипт. 

 

Ото жахіття той снмп... довго тре вникати в нього, але колись довелося б все одно...

Відредаговано 2014-10-24 12:33:57 L1ght

[nightfly 1 241]

 

Якщо в когось є джуніпер\etc і в нього аннамберед (у всіх по своєму) - то ніхто не заважає написати самому до нього такий скрипт.

Повністю логічно, так.

Винести це в якийсь абстрактний скрипт ініціалізації з фіксованими аргументами, типу як воно зроблено в старгейзері - виглядає доста здоровою ідеєю.

 

[l1ght 377]

 

 

Якщо в когось є джуніпер\etc і в нього аннамберед (у всіх по своєму) - то ніхто не заважає написати самому до нього такий скрипт.

Повністю логічно, так.

Винести це в якийсь абстрактний скрипт ініціалізації з фіксованими аргументами, типу як воно зроблено в старгейзері - виглядає доста здоровою ідеєю.

 

Ось, про це я й думав.

Але тоді треба рішати зі скриптами, на чьому писати їх?

шелл, перл, пхп, експект.

Усіляко як зробити костиль з експектом+пхп я знаю

 

Можливо дізнатися яка платформа через снмп SNMPv2-MIB::sysDescr.0

А далі вже використувуємо аргументи, які передані, я потрібні дії при визначеній платформі, тобто фря\лінух\циска.

Відредаговано 2014-10-24 12:41:39 L1ght

[nightfly 1 241]

 

Ось, про це я й думав.

Але тоді треба рішати зі скриптами, на чьому писати їх?

А яка їм різниця? Хоч на PHP/shell хоч на перлі чи ассемблері - ви передаєте їм пачку arvg і забуваєте. Хто їх буде виконувати - їм видніше.

 

 

А далі вже використувуємо аргументи, які передані, я потрібні дії при визначеній платформі, тобто фря\лінух\циска.

Або передаємо одним з аргументів/або коллбеком шо ми саме за темплейт ініт скриптів хочем виконати, якомусь абстрактному діспатчеру. Приблизно так воно реалізовано в його скриптах ініціалізації Тимуром.

 

Хоча знову ж конкретна реалізація росте ногами, з ваших реальних потреб і бажання заморочуватись на тему ліквідації вендорозалежності. Наприклад можна довго не думаючи вивалювати тим же інітскриптам вагон параметрів (vid, інтерфейси, айпішки, тощо) а вони хай би вже вирішували, що їм з цим робити. Поліморфізм же

 

Відредаговано 2014-10-24 12:52:15 nightfly

[l1ght 377]

 

 

Ось, про це я й думав.

Але тоді треба рішати зі скриптами, на чьому писати їх?

А яка їм різниця? Хоч на PHP/shell хоч на перлі чи ассемблері - ви передаєте їм пачку arvg і забуваєте. Хто їх буде виконувати - їм видніше.

 

 

А далі вже використувуємо аргументи, які передані, я потрібні дії при визначеній платформі, тобто фря\лінух\циска.

Або передаємо одним з аргументів/або коллбеком шо ми саме за теплейт ініт скриптів хочем виконати. Приблизно так воно реалізовано в його скриптах ініціалізації Тимуром.

 

Ну особисто мені є сенс робити тільки для циски, бо там де будуть в мене інсталяції на цисках.

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

Та й бог його зна, може й вам згодится