Обновление со старой версии

[ronin]

Была версия с последним обновлением от 2012 года.
Купили новую версию, пробуем обновиться. Естественно обновление обкатываем на копии действующего сервака в виртуалке. Копию снимали через dump/restore.

Обновляли следующим образом:
1) заменили собственно веб интерфейс
2) грохнули старую базу
3) залили пустую базу из дистрибутива
4) импортировали update_for_expire.sql

Клиенты работают.

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

Код: Выделить всё

An Error Was Encountered

Error Number: 1305

FUNCTION easyhotspot.CEILING does not exist

SELECT `username`, MIN( `acctstarttime` ) AS `start`, MAX( `acctstoptime` ) AS `stop`, CEILING ( TIMESTAMPDIFF (MINUTE, MIN( `acctstarttime`), MAX( `acctstoptime` ) ) / 1440 ) AS `lenth` FROM radacct WHERE username = 'test'

3) Невозможно провести инкассацию по кассирам

ну остальное походу буду ещё выяснять,

по версиям софта
Ubuntu 9.04
PHP 5.2.6
Mysql 5.0.72

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

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

[Dmitry]

Код: Выделить всё

An Error Was Encountered
Error Number: 1305
FUNCTION easyhotspot.CEILING does not exist

Честно говоря, причина данной ошибки (гласящей, что функция CEILING не существует) не понятна вообще, т.к. согласно документации функция CEILING присутствует в MySQL таких версий:

The CEILING function can be used in the following versions of MySQL:
MySQL 5.7, MySQL 5.6, MySQL 5.5, MySQL 5.1, MySQL 5.0, MySQL 4.1, MySQL 4.0, MySQL 3.23

Далее

по версиям софта
Ubuntu 9.04
PHP 5.2.6
Mysql 5.0.72

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

И ведь правду говорит, НУ ОЧЕНЬ старая версия....

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

• Да, вам придется поставить Easyhotspot с нуля на чистый сервер. ОС возьмите, естественно, "посвежее" - Ubuntu 14.04 или Debian 8. Брать Ubuntu 16.04 - пока не рекомендую, вроде как и работает, но иногда выпрыгивают ошибки "там, где их раньше не было"...
• А дальше - увы, но "спортлото". Со старого сервера берете бакап базы данных (сервер автоматом складывает их в папку /root/backup) и этот sql-дамп импортируете в базу Easyhotspot-а. После этого импортируете в базу файл update_for_expire.sql (он попытается привести вашу старую базу к требованиям новой версии программы). Так вот, "спортлото" заключается именно в том, будет ли работоспособна такая "прополированная" база.

[ronin]

Если заливать бекап создающийся по крону - будут проблемы, которые cкрипт update_for_expire.sql не решает.
Лучше экспортировать базу следующим образом:

Код: Выделить всё

mysqldump -u root -p  --insert-ignore --quote-names --no-create-db --skip-add-drop-table --no-create-info --complete-insert easyhotspot > easyhotspot_db.sql

Заливать в ПУСТУЮ базу от свежей установки.

Таким образом нормально перенеслось всё. Чего-то нерабочего пока не заметил.

[Dmitry]

ОК, спасибо за инфу

[ronin]

1. В новой версии при генерации ваучеров поле isprinted прописывается равным 0, в то время как в старой версии - равным 1.
Соответственно ваучер в списке пишется как инкассированный, но без даты инкассации. Проблем при инкассации не вылезет?

2. Стало генериться пачками не более 900 штук. Что можно подкрутить чтобы генерилось больше? Пробовал max_execution_time увеличить с 30 до 600 - не помогло, всё те же 900 максимум.

UPDATE: нашёл константу в файле /var/www/easyhotspot/system/application/models/vouchermodel.php. После изменения генерировать можно пачками по 9999, больше в web интерфесе ввести не получается.

[ronin]

3. Появилась автоматическая привязка мака к ваучеру. Как можно это отключить?

[Dmitry]

1. В новой версии при генерации ваучеров поле isprinted прописывается равным 0, в то время как в старой версии - равным 1.
Соответственно ваучер в списке пишется как инкассированный, но без даты инкассации. Проблем при инкассации не вылезет?

посмотрю, видно что-то там нахомутал

2. Стало генериться пачками не более 900 штук. Что можно подкрутить чтобы генерилось больше? Пробовал max_execution_time увеличить с 30 до 600 - не помогло, всё те же 900 максимум.

UPDATE: нашёл константу в файле /var/www/easyhotspot/system/application/models/vouchermodel.php. После изменения генерировать можно пачками по 9999, больше в web интерфесе ввести не получается.

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

3. Появилась автоматическая привязка мака к ваучеру. Как можно это отключить?

это описано в "индивидуализации хотспота..." (раздел "Отключение «авто-привязки» ваучера к mac-адресу клиента")

[Dmitry]

1. В новой версии при генерации ваучеров поле isprinted прописывается равным 0, в то время как в старой версии - равным 1...

пересмотрел (правда, только в новой версии, но с учетом того, что навскидку я вообще вспомнить не мог, то вполне возможно, что так было сделано весьма давно)....
ИТАК:

• 0 прописывается только в процедуре генерации новых ваучеров кассиром вручную, при этом тут же вдогонку идет генерация pdf-файла с ваучерами, и т.к. после нее ваучеры становятся "напечатанными", сразу же выполняется обновление записей в базе, при котором 0 меняется на 1.
• все остальные процедуры (платежных модулей, гостевые, и т.д. и т.п.) генерят ваучеры сразу с 1...

[ronin]

1. В новой версии при генерации ваучеров поле isprinted прописывается равным 0, в то время как в старой версии - равным 1...

пересмотрел (правда, только в новой версии, но с учетом того, что навскидку я вообще вспомнить не мог, то вполне возможно, что так было сделано весьма давно)....
ИТАК:

• 0 прописывается только в процедуре генерации новых ваучеров кассиром вручную, при этом тут же вдогонку идет генерация pdf-файла с ваучерами, и т.к. после нее ваучеры становятся "напечатанными", сразу же выполняется обновление записей в базе, при котором 0 меняется на 1.
• все остальные процедуры (платежных модулей, гостевые, и т.д. и т.п.) генерят ваучеры сразу с 1...

Ну генерация PDF с таким количеством логинов обречена на неудачу. Мы берём логины из базы и отдельно генерим карточки.

Ручное изменение с 0 на 1 должно безболезненно отработать? Я правильно понял?

[Dmitry]

Ручное изменение с 0 на 1 должно безболезненно отработать? Я правильно понял?

да, должно