Страница 1 из 1
Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Вс фев 27, 2011 4:19 pm
_ramzes_
Привет всем!
Имеется настроенная и работающая связка:
1 - Комп FreeBSD 7.3 + freeradius + Abills 0.37 (работает без обновлений уже 2-3 года).
2 - Комп с Mikrotik 3.28 лицензией 6ого уровня.
На данный момент хотелось бы сменить всё железо на более новое и мощное...
Ну понятно, что с микротиком скорее всего проблем не будет ...
А вот с биллингом....
Что хотелось бы сделать:
1. На новую биллинговую тачку установить Ubuntu Server 10.10
2. Установить и настроить Abills 0.51 (ну или последний возможный релиз).
3. И вот самое главное - импортировать базу данных с abills 0.37 на abills 0.51. Тут меня беспокоит, не возникнут ли проблемы? Вернее я точно уверен что возникнут! Возможно ли будет перенести пароли пользователей из одной базы в другую (они веть хранятся в пошифрованом виде!?)... И вообще подскажите как в данном случае лучше поступить, испытывая меньше проблем?
Re: Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Вс фев 27, 2011 6:53 pm
zakachkin
_ramzes_ писал(а):
1. На новую биллинговую тачку установить Ubuntu Server 10.10
Уж лучше debian
_ramzes_ писал(а):
Возможно ли будет перенести пароли пользователей из одной базы в другую (они веть хранятся в пошифрованом виде!?)
А как вы думаете для чего система каждые сутки (лично у меня) делает бекапы базы?
Пароли в таком же виде и перенесутся-)
единственное что абилосовский бекап не бекапит таблицу s_detail но создать её не проблема.
Код: Выделить всё
CREATE TABLE `s_detail` (
`acct_session_id` varchar(25) NOT NULL default '',
`nas_id` smallint(5) unsigned NOT NULL default '0',
`acct_status` tinyint(2) unsigned NOT NULL default '0',
`start` datetime default NULL,
`last_update` int(11) unsigned NOT NULL default '0',
`sent1` int(10) unsigned NOT NULL default '0',
`recv1` int(10) unsigned NOT NULL default '0',
`sent2` int(10) unsigned NOT NULL default '0',
`recv2` int(10) unsigned NOT NULL default '0',
`id` varchar(16) NOT NULL default '',
`sum` double(14,6) NOT NULL default '0.000000',
KEY `sid` (`acct_session_id`)
) ;
имортируете старую базу затем
её обновляете до интересующей вас версии.
Это в случае бесплатной версии.
Re: Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Вс фев 27, 2011 7:25 pm
_ramzes_
zakachkin, при много благодарен за разъяснения!!!
Но поясни минусы Ubuntu Server ... я просто уже как то привык к дестопу да и сервером не первый день пользуюсь, но если ты назовёшь весомые доводы я пожалуй откажусь от этой идеи...
Re: Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Вс фев 27, 2011 7:43 pm
zakachkin
1. Debian использует только стабильные (хоть и старые) пакеты, что для сервера немаловажно.
2. Скорость работы по сравнению с убунтой куда выше... чистая убунта, без всего, жрет около 150mb оперативы против дебиановских 70...
Аргументов множество поройте инет.
Re: Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Пн фев 28, 2011 10:49 am
_ramzes_
Я конечно может не правильным путём пошёл я значит скачал и установил последний релиз abills потом удалил дефолтную базу ... потом импортировал рабочую от версии 0.37 потом добавил все
изменения и вот теперь я не могу авторизоваться в админке пробовал и дефолтный пароль и который в рабочей базе всё рано не верный пароль ... тоже и с пользовательскими аккаунтами ... что я сделал не так?
Re: Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Пн фев 28, 2011 4:22 pm
sopov
А чем, собственно, бсд не угодила? Не совсем понятно какое поняти вкладывается в "сервер". В чем идея перевода mysql+radius на линух? И о rlm_perl отзывов хороших мало. По теме, чтобы не напутать с кодировками - просто скопируйте директорию /var/db/mysql на новый хост.
Re: Миграция на новое железо и сразу с 0.37 на 0.51...
Добавлено: Чт мар 03, 2011 9:06 pm
NiTr0
_ramzes_ писал(а):что я сделал не так?
1) нафига было разворачивать, а потом дропать дефолтную базу? К проблеме эти бессмысленные действия ессно никакого отношения не имеют, просто интересно.
2) секретный ключ в конфиге тот же остался? Попробуйте ним расшифровать пароли вручную.
3) возможно, упустили что-то добавить в базу.
sopov писал(а):И о rlm_perl отзывов хороших мало.
Работает вполне стабильно. На всякий случай правда подпер костылями (когда только перешел на него, и когда были с ним реальные проблемы) - чтобы если падает, поднималось оперативно, но в последнее время падений нет.
А вот эдак 10-кратный прирост производительности при его запуске вместо rlm_exec - таки имеется.