Перейти к содержимому
Калькуляторы

Вопрос спецам по Lanbilling'y переход с 1.9 до 2.0

Кто как подчищает старые неактуальные данные из БД ЛанБиллинга? Что можно удалить без последствий? А то при бэкапах базы размер начинает удручать.

Если посмотреть размер таблиц, то ТОП выглядит так:

 SELECT table_name AS "Table Name",ROUND(((data_length + index_length) / 1024), 2) AS "Size in (KBytes)" FROM information_schema.TABLES WHERE table_schema = "radius" ORDER BY (data_length + index_length) DESC;
+-----------------------+------------------+
| Table Name            | Size in (KBytes) |
+-----------------------+------------------+
| auth_hist20191224     |         25232.00 |
| auth_hist20200121     |         21136.00 |
| vg_blocks             |         20048.00 |
| auth_hist20200402     |         10240.00 |
| auth_hist20200209     |          4048.00 |
| auth_hist20230816     |          3600.00 |
| auth_hist20230817     |          3536.00 |
| auth_hist20230815     |          3536.00 |
| auth_hist20230818     |          3376.00 |
| auth_hist20230703     |          3296.00 |
| auth_hist20231010     |          3040.00 |
| auth_hist20201008     |          3040.00 |
| auth_hist20231005     |          3024.00 |
| auth_hist20231012     |          3008.00 |
| auth_hist20231018     |          3008.00 |
| auth_hist20230704     |          3008.00 |
| auth_hist20231015     |          3008.00 |

 

 

 SELECT table_name AS "Table Name",ROUND(((data_length + index_length) / 1024), 2) AS "Size in (KBytes)" FROM information_schema.TABLES WHERE table_schema = "billing" ORDER BY (data_length + index_length) DESC;
+--------------------------------------------+------------------+
| Table Name                                 | Size in (KBytes) |
+--------------------------------------------+------------------+
| rentcharge                                 |        832736.00 |
| day                                        |        769456.00 |
| user00220211215                            |        488539.83 |
| user00220211216                            |        472928.49 |
| user00220211214                            |        436599.45 |
| user00220211217                            |        410322.61 |
| user00220211213                            |        372322.04 |
| user00220211229                            |        355030.24 |
| user00220230802                            |        334701.17 |
| user00220230718                            |        329134.05 |
| user00220211208                            |        319522.85 |
| user00220211210                            |        314003.63 |
| user00220211209                            |        307724.62 |
| user00220211206                            |        294726.70 |
| user00220230711                            |        291849.03 |
| user00220211207                            |        289203.86 |
| user00220211228                            |        267626.16 |
| user00220211220                            |        247772.71 |
| user00220230823                            |        242006.19 |
| user00220211221                            |        241221.03 |

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Ответ был, что auth_hist* содержит историю авторизаций и можно удалить до нужного момента.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 часов назад, Urs_ak сказал:

auth_hist* содержит историю авторизаций и можно удалить до нужного момента.

Т.е. просто DROP TABLE для кучи таблиц?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 часов назад, Urs_ak сказал:

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

 

Аналогично, только я для staff_history_dynamic ~71,781,789 строк 16.2 ГБ делал:

DELETE  FROM `staff_history_dynamic` WHERE timefrom < '2017-06-30 00:00:00';

каждый раз с диапазоном в месяц

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, Andrei сказал:

Т.е. просто DROP TABLE для кучи таблиц?

Да

 

Я вот так сделал по годам:

 

mysql -As -uroot -p -e 'show tables like "auth_hist2019%"' radius > clean_db.txt
for i in `cat clean_db.txt`; do echo "drop table $i;" ; done > clean_db_2.txt
mysql -As -uroot -p radius < clean_db_2.txt
 

и ничего страшного не произошло

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще можно старые сессии радиус-агента почистить, например:

DELETE  FROM `billing.day` WHERE timefrom < '2019-01-01 00:00:00';

 

И потом надо прогнать mysqlcheck -o ? Иначе ведь размер базы не меняется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коллеги, кто на какой версии биллинга остановился? Что из сборок достаточно стабильное?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Но это геморрой на несколько недель, с попыткой проверить не сломалось ли что.

Поэтому у нас 2.0.38 пока.

Но мы ничего сложного не используем (тарифы/услуги хитрые и т.п.).

 

Могу только отметить, что тут есть подсветка разным цветом пользователь/учетная запись (отключенные так-сяк, заблокированные).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У нас 2.0 сборка 031. Перед НГ общались с разработчиками и менеджер настоятельно рекомендовала обновиться на последнюю сборку - 046.

34 минуты назад, Urs_ak сказал:

иначе потом апгрейды сложнее будут проходить.

Мы обновлялись с 16й сборки до 31й, вроде без проблем. Но если что-то правили в ЛК (у нас там интегрированы переходы на внешние платежные системы), то при обновлении это всё похерится. Надо бэкапить ЛК и потом расставлять вручную всё на свои места.

 

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

 

Ну и немаловажно: у нас 31я сборка стоит на 9м дебиане, а он разработчиками в новых сборках не поддерживается, надо 10 или 11. Так что еще и ОС обновлять надо будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

19 часов назад, Urs_ak сказал:

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

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

Но это геморрой на несколько недель, с попыткой проверить не сломалось ли что.

Поэтому у нас 2.0.38 пока.

 

 

Да, в курсе, оно понятно, что лучше чаще обновляться, но опыт с этим софтом говорит об обратном, работает - не трогай!

Но это не пугает. Благо, есть запасной сервер с ключём где можно протестировать обновление, да и вообще посмотреть новый софт.

 

18 часов назад, Andrei сказал:

У нас 2.0 сборка 031. Перед НГ общались с разработчиками и менеджер настоятельно рекомендовала обновиться на последнюю сборку - 046.

Мы обновлялись с 16й сборки до 31й, вроде без проблем. Но если что-то правили в ЛК (у нас там интегрированы переходы на внешние платежные системы), то при обновлении это всё похерится. Надо бэкапить ЛК и потом расставлять вручную всё на свои места.

Ну и немаловажно: у нас 31я сборка стоит на 9м дебиане, а он разработчиками в новых сборках не поддерживается, надо 10 или 11. Так что еще и ОС обновлять надо будет.

 

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

 

Но есть еще такой опыт как просто перенос базы под новую инсталляцию, под наши условия. Да, надо понимать, что делаешь и для чего, читать нюансы  при переходе от версии к версии и вообще, потому как есть изменения в базе и прочее. Но у нас есть уже опыт в этом направлении и таки, это даже лучше и быстрее чем просто обновлять через update.sql, практически без косяков. Короче, все решаемо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пренес админку на другой сервер(архив/разархив), но почему то отображаться стала на английском. Всегда четко все переезжало. Думал, может от локали зависит, пробовал менять , не помогает, не пойму. Что может еще повлиять, было у кого такое? Верcия 2.0-14

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Попробуйте кеши везде почистить. 

где-то в самом биллинге есть кеш ЛК, и в браузере. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, кеши чистил, не помогло.

Изначально решил перенести на 11 Deb. Установлен был РНР 5.6, но пормудохавшись, ничего путного не вышло, циклическая перезагрузка страницы в клиентском разделе + на английском админка.

Решил вернуться к 14 убунте ибо изначально на ней работало, все заработало  как надо "из коробки", но там устанавливилась РНР 5.5. В итоге вернувшись на свежий дистриб дебиана установил репозиторий с поддержкой рнр 5.5 и все "взлетело" как надо, пока придется на нем посидеть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 01.02.2024 в 14:27, No_name сказал:

В итоге вернувшись на свежий дистриб дебиана установил репозиторий с поддержкой рнр 5.5 и все "взлетело" как надо

Тоже вылезла проблема, которая похоже связана с php

Внезапно перестал работать вход в личный кабинет. При попытке войти пишет:
Exception
Failed to download wsdl

В логе апача

[Tue Feb 13 10:55:31.091377 2024] [:error] [pid 9234] [client 188.130.171.67:10123] exception.Exception Exception: Failed to download
wsdl in /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_RemoteWSDL.php:90

Stack trace:

#0 /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_LBClient.php(18): SOAP_RemoteWSDL->__construct(Object(LB\\HTTP\\Client), Array, Object(SOAPLoggers))

#1 /usr/share/lanbilling/phpclient/client/extensions/LANBilling.php(161): SOAP_LBClient->__construct()

#2 /usr/share/lanbilling/phpclient/framework/YiiBase.php(224): LANBilling->__construct()

#3 /usr/share/lanbilling/phpclient/framework/base/CModule.php(393): YiiBase::createComponent(Array)

#4 /usr/share/lanbilling/phpclient/framework/base/CModule.php(530): CModule->getComponent('lanbilling')

#5 /usr/share/lanbilling/phpclient/framework/base/CApplication.php(168): CModule->preloadComponents()

#6 /usr/share/lanbilling/phpclient/components/Application.php(11): CApplication->_construct(Array)

#7 /usr/share/lanbilling/phpclient/framework/YiiBase.php(132): Application->_construct(Array)

#8 /usr/share/lanbilling/phpclient/components/LBStart.php(152): YiiBase::createApplication('Application', Array)

#9 /usr/share/lanbilling/phpclient/client/public/api.php(30): LBStart->run(Array)

#10 {main}REQUEST_URI=/lbweb-client/---

 

[Tue Feb 13 10:55:31.091407 2024] [:error] [pid 9234] [client 188.130.171.67:10123] soap Failed to download wsdl (Server responded with status 404)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Странно, что внезапно. Судя по 404 то проблеме в сервере. Кто там что делал? Или с клиента запрос неверный стал уходить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, No_name сказал:

Кто там что делал?

В том-то и дело, что ничего не делали. Сервак стоит в виртуалке. На хост-системе могли что-то делать, но не в виртуалке.

 

Первое упоминание ошибки "Failed to download wsdl" в логе apache2 встречается 9 февраля:

 

[Fri Feb 09 10:23:18.583694 2024] [:error] [pid 6864] [client 85.140.117.175:35156] soap Failed to download wsdl (Server responded with status 404), referer: http://www.alfa-tele.ru/
[Fri Feb 09 10:23:18.583807 2024] [:error] [pid 6864] [client 85.140.117.175:35156] exception.Exception Exception: Failed to download wsdl in /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_RemoteWSDL.php:90Stack trace:#0 /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_LBClient.php(18): SOAP_RemoteWSDL->__construct(Object(LB\\HTTP\\Client), Array, Object(SOAPLoggers))#1 /usr/share/lanbilling/phpclient/client/extensions/LANBilling.php(161): SOAP_LBClient->__construct()#2 /usr/share/lanbilling/phpclient/framework/YiiBase.php(224): LANBilling->__construct()#3 /usr/share/lanbilling/phpclient/framework/base/CModule.php(393): YiiBase::createComponent(Array)#4 /usr/share/lanbilling/phpclient/framework/base/CModule.php(530): CModule->getComponent('lanbilling')#5 /usr/share/lanbilling/phpclient/framework/base/CApplication.php(168): CModule->preloadComponents()#6 /usr/share/lanbilling/phpclient/components/Application.php(11): CApplication->__construct(Array)#7 /usr/share/lanbilling/phpclient/framework/YiiBase.php(132): Application->__construct(Array)#8 /usr/share/lanbilling/phpclient/components/LBStart.php(152): YiiBase::createApp
lication('Application', Array)#9 /usr/share/lanbilling/phpclient/client/public/api.php(30): LBStart->run(Array)#10 {main}REQUEST_URI=/lbweb-client/api.php?HTTP_REFERER=http://www.alfa-tele.ru/---, referer: http://www.alfa-tele.ru/
[Fri Feb 09 10:23:18.583825 2024] [:error] [pid 6864] [client 85.140.117.175:35156] soap Failed to download wsdl (Server responded with status 404), referer: http://www.alfa-tele.ru/

 

В логе ядра за 9 февраля ничего подозрительного нет, но за сутки до этого:

 

08.02.2024 09:22:26.940640 ERROR    LWP910 [src/radius.cpp:2593] Billing error: Lost connection to MySQL server during query
08.02.2024 09:22:26.941088 WARNING  LWP917 [src/radius_session.cpp:553] Out-of-order packet with Acct-Delay-Time = 5, difference = 5. Time corrected
08.02.2024 09:22:26.942440 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:27.931604 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:28.931790 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:29.932327 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:30.937753 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:31.941839 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:32.954659 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:33.954663 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:34.955200 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:35.956951 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:36.957794 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:37.957916 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:38.958417 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:39.959161 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:40.959156 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:41.961271 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:42.961479 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:43.963364 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:44.349526 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:22:44.963919 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:45.352097 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:22:45.963897 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:46.352705 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:22:46.968506 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:22:47.373931 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:22:47.972915 ERROR    LWP907 [src/radius.cpp:1899] 0:
...
08.02.2024 09:23:04.130350 ERROR    LWP908 [src/radius.cpp:2438] Exception while Flushing: Can't connect to MySQL server on '127.0.0.1' (111)
08.02.2024 09:23:04.486500 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:23:05.040346 ERROR    LWP907 [src/radius.cpp:1899] 0:
08.02.2024 09:23:05.040676 ERROR    LWP909 [src/radius.cpp:1087] RoutinesThread error: 0:
08.02.2024 09:23:05.141552 ERROR    LWP908 [src/radius.cpp:2438] Exception while Flushing: Can't connect to MySQL server on '127.0.0.1' (111)
08.02.2024 09:23:05.487247 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:23:06.046518 ERROR    LWP909 [src/radius.cpp:1087] RoutinesThread error: 0:
08.02.2024 09:23:06.046636 ERROR    LWP907 [src/radius.cpp:1899] 0:
...
08.02.2024 09:28:10.333539 ERROR    LWP909 [src/radius.cpp:1087] RoutinesThread error: Can't connect to MySQL server on '127.0.0.1' (111)
08.02.2024 09:28:10.334328 ERROR    LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:]
08.02.2024 09:29:17.893283 WARNING  LWP917 [src/radius_session.cpp:553] Out-of-order packet with Acct-Delay-Time = 5, difference = 5. Time corrected
08.02.2024 09:35:11.799695 WARNING  LWP909 [src/radius.cpp:1137] Session expired. User-Name: 'beleckiy', Session-ID: '0/0/1/4_0000000000060C83'

 

И судя по логам хост-системы в это время 8 февраля проходил rebuild raid-массива.

 

1 час назад, No_name сказал:

Или с клиента запрос неверный стал уходить?

А вот тут не понял вопрос. Клиент просто открывает стартовую страницу входа в ЛК.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, Andrei сказал:
Exception while Flushing: Can't connect to MySQL server on '127.0.0.1'

Что с базой она доступна хотя бы из консоли?

 

1 час назад, Andrei сказал:

А вот тут не понял вопрос. Клиент просто открывает стартовую страницу входа в ЛК

 

Просто у нас клиентски вход и база на разных серверах.

Да и что там с логированием в новых версиях, в случаях с варнингом происходит, не знаю. Потому и спросил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, No_name сказал:

Что с базой она доступна хотя бы из консоли?

Конечно. И админка работает совершенно нормально. Мы и не знали об этой проблеме с ЛК, пока клиенты не пожаловались на невозможность зайти в ЛК,

ЛК, база и админка - всё на одном сервере.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В общем похоже, что дело не в ЛанБиллинге, а просто  в файлухе:

 

В /var/log/kernel.log:

Feb 13 18:38:00 debian9lb kernel: [3383680.583435] EXT4-fs error (device sda1): ext4_iget:4508: inode #3806891: comm LBcore: bad extra_isize (35945 != 256)
Feb 13 18:38:00 debian9lb kernel: [3383680.588212] EXT4-fs error (device sda1): ext4_iget:4508: inode #3806891: comm LBcore: bad extra_isize (35945 != 256)
и т.д.

 

В dmesg тоже:

[Tue Feb 13 20:21:03 2024] EXT4-fs error (device sda1): ext4_iget:4508: inode #3806891: comm LBcore: bad extra_isize (35945 != 256)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 часов назад, Andrei сказал:

И судя по логам хост-системы в это время 8 февраля проходил rebuild raid-массива.

А с рейдом то всё окей? Ребилд просто так не начинается, сравните файловую с бекапом, может там уже частично мусор, а не данные. Да прибудет с Вами святой Бекапий!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, bike сказал:

А с рейдом то всё окей?

Сейчас с рейдом все ОК. Ребилд начался потому что один из дисков почему-то вывалился из рейда, но потом сразу подхватился обратно. smart на нем посмотрели - все в норме.

Грузанулись с live-iso, почекали файловую систему, сказано было "все ОК, починилось", виртуалка стартовала, база данных на месте, но личный кабинет не работает с теми же симптомами.

Завтра спросим саппорт  - может какие бинарники надо из бэкапа достать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

решение:

# смотрим установленные пакеты lb
dpkg -l | grep lb

# проверка checksum в /var/lib/dpkg/info
ls -l  /var/lib/dpkg/info/lb*
sudo apt install debsums
sudo debsums lbcore --changed
#... показала, что /usr/local/billing/api3.wsdl missing

# так же можно проверить и все пакеты lb:
sudo debsums --change lbweb-client lbarcd lbcore lbweb-admin lbweb-common lbucd

# Итого, если проверять всё, то список измененных или отстутствующих файлов выглядит так:
sudo debsums --changed
debsums: missing file /etc/billing.conf.LBarcd.sample (from lbarcd package)
debsums: missing file /usr/local/billing/LICENSES (from lbcore package)
debsums: missing file /usr/local/billing/api3.wsdl (from lbcore package)
/usr/local/billing/lib/python3.6/lib/python3.6/site-packages/pip/_vendor/certifi/cacert.pem
/usr/local/billing/lib/python3.6/lib/python3.6/site-packages/requests/cacert.pem
/usr/local/billing/lib/python3.6/lib/python3.6/site-packages/requests/certs.py
/usr/local/billing/mysql/update_pre.sql
debsums: missing file /etc/billing.conf.LBinet.sample (from lbinet package)
debsums: missing file /etc/billing.conf.LBircd.sample (from lbircd package)
debsums: missing file /etc/billing.conf.LBphone.sample (from lbphone package)
debsums: missing file /etc/billing.conf.LBucd.sample (from lbucd package)
/usr/share/lanbilling/phpclient/admin/public/.htaccess
/usr/share/lanbilling/phpclient/client/components/payment/ckassa/Payment_CKassa_Pay.php
/usr/share/lanbilling/phpclient/client/config/settings.php
/usr/share/lanbilling/phpclient/client/controllers/PaymentController.php
/usr/share/lanbilling/phpclient/client/views/menu/config.php
/usr/share/lanbilling/phpclient/client/views/payment/form.php
/usr/share/lanbilling/phpclient/client/views/payment/promised/form.php
/usr/share/lanbilling/phpclient/client/views/site/login.php

 

Восстановили из дистрибутива файл /usr/local/billing/api3.wsdl и личный кабинет заработал.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Заодно и https сделайте на ваш клиентский раздел раз он в интернет смотрит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.