Не удалось выполнить очистку UniFi Controller на AWS

Не удалось выполнить очистку UniFi Controller на AWS, UniFi Network

wintegrations

Guest

18.01.2018 22:52:00

[ОБНОВЛЕНИЕ] – Думаю, проблема в том, что у меня в хранилище нет места, после долгого разговора с поддержкой. Сейчас пытаюсь выполнить инструкцию по очистке контроллера через ssh, но не могу успешно запустить сухой прогон. mongo_prune_js.js сохраняется нормально.

prior.ubuntu@ip-xxx-xx-x-xx:~$ sudo mongo --port 27117 < mongo_prune_js.js
MongoDB shell version: 2.4.9
connecting to: 127.0.0.1:27117/test
Fri Jan 19 00:57:18.154 Error: couldn't connect to server 127.0.0.1:27117 at src/mongo/shell/mongo.js:147
exception: connect failed

[Оригинальный пост] – UniFi контроллер на AWS показывает офлайн, но инстанс доступен через SSH

Я немного пересмотрел, с чем нужна помощь! Сегодня меня попросили проверить моё UniFi контроллер, и оказалось, что контроллер, размещённый на AWS, офлайн. Я попытался подключиться к нему через SSH и сразу же получилось... Даже обновил UniFi контроллер. Но я не могу зайти на контроллер через браузер или через unifi.ubnt.com. Выдало сообщение, что мой бесплатный первый год заканчивается 30 января, но это не должно влиять на подключение к UniFi в облаке.

[скорее всего, сейчас неактуально]

Кто-нибудь может помочь восстановить доступ сюда? У этого контроллера несколько сайтов и куча точек доступа.

Что я пробовал:
- SSH подключение к AWS инстансу (успешно)
- Обновление UniFi до последней стабильной версии (успешно)
- Вход через URL, который я настроил для перехода на мой elastic IP с SSL сертификатом (неудача)
- Вход через elastic IP AWS (неудача)
- Перезагрузка инстанса через EC2 консоль управления (успешно)
- Прямой доступ через приложение UniFi iOS к elastic IP контроллера (неудача)

Что я ещё не пробовал:
AWS показывает, что доступно обновление Ubuntu с 14.04.5 до 16.04.3 (не уверен, стоит ли этим сейчас заморачиваться)

slooffmaster

Guest

04.04.2018 20:49:00

@obryseco,
@wintegrations
Дефицит места вряд ли может быть первопричиной. Убедитесь, что у вас есть резервная копия или снимок, а затем посмотрите, могут ли помочь эти ссылки: https://stackoverflow.com/questions/7979218/mongodb-assertion-failure-isok-db-pdfile-h https://stackoverflow.com/questions/12985100/exited-mongodb-uncleanly-and-now-unsure-how-to-get-it-running-again.
Признаюсь, я не гуру MongoDB, но настоятельно рекомендую обновиться до MongoDB 3.2 и Oracle Java8.

obryseco Guest	#3 04.04.2018 20:03:00 @wintegrations @slooffmaster У меня большие сомнения... Может ли это быть проблемой с местом, если я использую всего 42% от доступного пространства? Из 30 ГБ, которые у меня есть, сейчас занято 12 ГБ...

obryseco

Guest

04.04.2018 19:59:00

В файле mongod.log, судя по всему, происходит проблема, при этом выводится:

***** SERVER RESTARTED *****
Вт Апр 3 21:28:40.668 [initandlisten] MongoDB запускается: pid=10512 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=ip-172-31-44-173
Вт Апр 3 21:28:40.669 [initandlisten] версия БД v2.4.9
Вт Апр 3 21:28:40.669 [initandlisten] git version: nogitversion
Вт Апр 3 21:28:40.669 [initandlisten] информация о сборке: Linux orlo 3.2.0-58-generic #88-Ubuntu SMP Вт Дек 3 17:37:58 UTC 2013 x86_64 BOOST_LIB_VERSION=1_54
Вт Апр 3 21:28:40.669 [initandlisten] аллокатор: tcmalloc
Вт Апр 3 21:28:40.669 [initandlisten] опции: { bind_ip: "127.0.0.1", dbpath: "/usr/lib/unifi/data/db", logappend: true, logpath: "/usr/lib/unifi/logs/mongod.log", nohttpinterface: true, port: 27117, unixSocketPrefix: "/usr/lib/unifi/run" }
Вт Апр 3 21:28:40.679 [initandlisten] папка журнала=/usr/lib/unifi/data/db/journal
Вт Апр 3 21:28:40.679 [initandlisten] восстановление: файлов журнала нет, восстановление не требуется
Вт Апр 3 21:28:40.689 [initandlisten] локальная ошибка Assertion failure isOk() src/mongo/db/pdfile.h 392
Вт Апр 3 21:28:40.693 [initandlisten] исключение в initAndListen: 0 assertion src/mongo/db/pdfile.h:392, процесс завершается
Вт Апр 3 21:28:40.693 dbexit:
Вт Апр 3 21:28:40.693 [initandlisten] выключение: закрываем слушающие сокеты...
Вт Апр 3 21:28:40.693 [initandlisten] выключение: сбрасываем diaglog...
Вт Апр 3 21:28:40.693 [initandlisten] выключение: закрываем сокеты...
Вт Апр 3 21:28:40.693 [initandlisten] выключение: ждем завершения fs preallocator...
Вт Апр 3 21:28:40.693 [initandlisten] выключение: блокировка для финального коммита...
Вт Апр 3 21:28:40.693 [initandlisten] выключение: финальный коммит...
Вт Апр 3 21:28:40.693 [initandlisten] выключение: закрываем все файлы...
Вт Апр 3 21:28:40.694 [initandlisten] closeAllFiles() завершено
Вт Апр 3 21:28:40.694 [initandlisten] очистка журнала...
Вт Апр 3 21:28:40.694 [initandlisten] удаление файлов журнала
Вт Апр 3 21:28:40.703 [initandlisten] выключение: удаляем fs lock...
Вт Апр 3 21:28:40.703 dbexit: настоящее завершение работы

***** SERVER RESTARTED *****
Вт Апр 3 21:28:44.796 [initandlisten] MongoDB запускается: pid=10520 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=ip-172-31-44-173
Вт Апр 3 21:28:44.796 [initandlisten] версия БД v2.4.9
Вт Апр 3 21:28:44.796 [initandlisten] git version: nogitversion
Вт Апр 3 21:28:44.796 [initandlisten] информация о сборке: Linux orlo 3.2.0-58-generic #88-Ubuntu SMP Вт Дек 3 17:37:58 UTC 2013 x86_64 BOOST_LIB_VERSION=1_54
Вт Апр 3 21:28:44.796 [initandlisten] аллокатор: tcmalloc
Вт Апр 3 21:28:44.796 [initandlisten] опции: { bind_ip: "127.0.0.1", dbpath: "/usr/lib/unifi/data/db", logappend: true, logpath: "/usr/lib/unifi/logs/mongod.log", nohttpinterface: true, port: 27117, unixSocketPrefix: "/usr/lib/unifi/run" }
Вт Апр 3 21:28:44.808 [initandlisten] папка журнала=/usr/lib/unifi/data/db/journal
Вт Апр 3 21:28:44.808 [initandlisten] восстановление: файлов журнала нет, восстановление не требуется
Вт Апр 3 21:28:44.817 [initandlisten] локальная ошибка Assertion failure isOk() src/mongo/db/pdfile.h 392
Вт Апр 3 21:28:44.821 [initandlisten] исключение в initAndListen: 0 assertion src/mongo/db/pdfile.h:392, процесс завершается
Вт Апр 3 21:28:44.821 dbexit:
Вт Апр 3 21:28:44.821 [initandlisten] выключение: закрываем слушающие сокеты...
Вт Апр 3 21:28:44.821 [initandlisten] выключение: сбрасываем diaglog...
Вт Апр 3 21:28:44.821 [initandlisten] выключение: закрываем сокеты...
Вт Апр 3 21:28:44.821 [initandlisten] выключение: ждем завершения fs preallocator...
Вт Апр 3 21:28:44.821 [initandlisten] выключение: блокировка для финального коммита...
Вт Апр 3 21:28:44.821 [initandlisten] выключение: финальный коммит...
Вт Апр 3 21:28:44.821 [initandlisten] выключение: закрываем все файлы...
Вт Апр 3 21:28:44.822 [initandlisten] closeAllFiles() завершено
Вт Апр 3 21:28:44.822 [initandlisten] очистка журнала...
Вт Апр 3 21:28:44.822 [initandlisten] удаление файлов журнала
Вт Апр 3 21:28:44.831 [initandlisten] выключение: удаляем fs lock...
Вт Апр 3 21:28:44.831 dbexit: настоящее завершение работы

И так процесс перезапускается снова и снова.

wintegrations

Guest

04.04.2018 19:57:00

@slooffmaster

@obryseco

Похоже, у меня была такая же проблема. Mongodb даже не запускается из-за отсутствия свободного места. При первом входе мне выдало, что я использую 99% доступного хранилища. UniFi запускался и работал (на инстансе AWS без возможности входа), а вот mongodb — нет.

obryseco

Guest

04.04.2018 19:38:00

2018-04-03 21:23:29,696] <inform-40> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,697] <inform-172> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,697] <inform-45> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,698] <inform-50> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,699] <inform-39> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,700] <inform-22> INFO inform - от [80:2a:a8:3e:3c:ec](7011, BZ2, 3.9.19.8123): состояние=CONNECTED, ext/stun_ip=148.101.40.153, dev_ip=10.0.0.5, up=2808364
2018-04-03 21:23:29,701] <inform-22> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,701] <inform-195> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:29,703] <inform-122> INFO db - ожидание подключения к базе данных...
2018-04-03 21:23:43,033] <db-server> ERROR system - [exec] ошибка, rc=137
2018-04-03 21:23:43,161] <db-server> INFO db - DbServer остановлен
2018-04-03 21:23:56,546] <db-server> ERROR system - [exec] ошибка, rc=137
2018-04-03 21:23:56,901] <db-server> INFO db - DbServer остановлен
2018-04-03 21:24:02,537] <db-server> ERROR system - [exec] ошибка, rc=137
2018-04-03 21:24:02,542] <db-server> INFO db - DbServer остановлен
2018-04-03 21:24:11,377] <db-server> ERROR system - [exec] ошибка, rc=137
2018-04-03 21:24:11,384] <db-server> INFO db - DbServer остановлен
2018-04-03 21:24:24,326] <db-server> ERROR system - [exec] ошибка, rc=137
2018-04-03 21:24:24,330] <db-server> INFO db - DbServer остановлен
2018-04-03 21:24:35,573] <db-server> ERROR system - [exec] ошибка, rc=137
2018-04-03 21:24:35,575] <db-server> INFO db - DbServer остановлен
2018-04-03 21:24:51,172] <launcher> INFO system - ======================================================================
2018-04-03 21:24:51,177] <launcher> INFO system - UniFi 5.5.24 (сборка atag_5.5.24_9806 - релиз) запущена
2018-04-03 21:24:51,177] <launcher> INFO system - ======================================================================
2018-04-03 21:24:51,194] <launcher> INFO system - BASE dir:/usr/lib/unifi
2018-04-03 21:24:51,208] <launcher> INFO system - Текущий системный IP: 172.31.44.173
2018-04-03 21:24:51,213] <launcher> INFO system - Имя хоста: ip-172-31-44-173
2018-04-03 21:24:56,035] <launcher> INFO db - ожидание подключения к базе данных...
2018-04-03 21:24:56,538] <launcher> INFO db - подключение к mongodb://127.0.0.1:27117
2018-04-03 21:24:57,776] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:24:57,776] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:01,904] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:01,904] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:06,024] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:06,024] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:10,160] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:10,160] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:14,279] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:14,279] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:18,408] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:18,408] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:22,544] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:22,544] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:26,668] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:26,668] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:30,792] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:30,792] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:34,916] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:34,916] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:39,048] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:39,048] <db-server> INFO db - DbServer остановлен
2018-04-03 21:25:43,176] <db-server> ERROR system - [exec] ошибка, rc=100
2018-04-03 21:25:43,176] <db-server> INFO db - DbServer остановлен

slooffmaster Guest	#7 04.04.2018 19:11:00 @obryseco Проверь оба лог-файла в /var/log/unifi/ — возможно там есть подсказки, почему сервер или mongod ведут себя странно.

obryseco

Guest

04.04.2018 18:43:00

Одно, что я заметил... В последние дни у меня возникали проблемы с входом в AWS Unifi контроллер, так как он почему-то случайным образом уходил в офлайн. Я проверял мониторинг Cloud Watch на панели EC2, и там отображается то, что видно на прикреплённом изображении. Похоже, контроллер уходит в офлайн, когда загрузка CPU достигает 100%.

Мой вопрос: связано ли это с высокой загрузкой процессора и есть ли какие-то конкретные параметры, которые нужно настроить при запуске инстанса для развёртывания unifi контроллера? Может быть, инстансы на бесплатном тарифе просто не справляются с нагрузкой для unifi контроллера?

obryseco

Guest

04.04.2018 18:22:00

@slooffmaster

Я выполнил команду df -h в терминале, чтобы проверить размер файловой системы. Вот что она выводит:
ubuntu@ip-xxx-xx-xx-xxx:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 255M 12K 255M 1% /dev
tmpfs 54M 908K 53M 2% /run
/dev/xvda1 30G 12G 17G 42% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 266M 0 266M 0% /run/shm
none 100M 0 100M 0% /run/user

Если я правильно смотрю на значения, у меня достаточно места на диске. Во всяком случае, вчера, когда я подключался к контроллеру по ssh, первое сообщение в терминале было: «System information disabled due to load higher than 1.0» (не знаю, связано ли это с оффлайн-статусом...). Сейчас система выводит эту информацию, но контроллер всё ещё оффлайн:
System information as of Wed Apr 4 17:53:46 UTC 2018
System load: 0.48
Memory usage: 8%
Processes: 48
Usage of /: 40.4% of 29.40GB
Swap usage: 0%
Users logged in: 0

В этом контроллере у меня 2 сайта:
Сайт 1: 26 точек доступа, 4 коммутатора (8 портов) и 1 USG (все проблемы начались после установки USG, настроенного на тесты скорости каждые 20 минут)
Сайт 2: только 1 точка доступа

В любом случае, я извлёк последний автобэкап для восстановления системы, если другого решения не будет. Какие ещё причины могут вызвать оффлайн-состояние контроллера при сохранном доступе по ssh, если место не проблема (и очистка кэша тоже невозможна)?

P.S. Спасибо!

@wintegrations

Спасибо за все подсказки и поддержку, я следую вашим рекомендациям по восстановлению, если другого способа не найдётся.

wintegrations

Guest

#10

04.04.2018 06:32:00

@slooffmaster

Я думал, что он уже перешёл этот этап. Можно ли увеличить объём без проблем? Было бы здорово получить информацию о том, как это сделать, если подобная ситуация повторится. После всех поисков казалось, что это довольно рискованный шаг! Жаль, что тебя не было рядом, когда я проходил через все эти мучения, чтобы всё запустить снова. Моя главная проблема была в том, что у mongoDB даже не было достаточно места для запуска, и поэтому скрипт очистки оказался бесполезным. Попробовав метод со снимком, я случайно получил стандартный контроллер UniFi. Когда я перешёл точку невозврата, моё спасение — это был файл автозапаса.

slooffmaster

Guest

#11

04.04.2018 06:25:00

@obryseco

Сначала проверьте доступное пространство, чтобы определить, не в этом ли причина ваших проблем. Если дело действительно в этом, вы можете либо расширить том, либо разобраться, как освободить место. Если свободного места достаточно, mongod снова запустится, когда вы запустите сервис unifi, после чего вы сможете очистить базу данных.

wintegrations

Guest

#12

04.04.2018 03:52:00

В основном я писал это для себя, но, надеюсь, смогу помочь направить тебя в нужное русло. Ты на Mac или PC? Проверь, есть ли у тебя сохранённый файл автозаписи и достаточно ли он свежий.

Подключись по SSH к своему AWS-инстансу и выполни следующие шаги для проверки каталога с бэкапами:

sudo su
# тебе нужен root-доступ
# задай пароль для root на всякий случай, чтобы не забыть
passwd root
# перейди в каталог с бэкапами
cd /usr/lib/unifi/data/backup
# выведи список всех файлов в этой папке (честно, не помню, показывает ли это дату изменения, или я для этого использовал другой метод... обновлю, если вспомню)
ls -a

Если найдёшь нужный файл, пора извлекать его.
# скопируй файл из каталога с бэкапами в домашнюю папку своего инстанса — туда, где у тебя есть права для сохранения и скачивания. Замени текст в [ ] на имя и расширение твоего файла:
cp [filename].unf /home/ubuntu/
# поменяй права у скопированного файла, чтобы можно было скачать
chmod -R 777 [filename].unf
# не забудь потом отключить пароль для root (Amazon предпочитает, чтобы ты использовал учётную запись пользователя, а не root, если это возможно)
passwd -l root

Тебе понадобится SFTP-клиент, чтобы получить доступ и скачать файл бэкапа (я использовал CyberDuck на Mac).

После того как скачал бэкап, создай снимок (snapshot) своего тома в AWS (нашёл видеоурок на форумах), затем создай новый том из этого снимка (можно того же размера, поскольку он избавится от временного хранилища, как я описывал выше).

Это должно запустить твою UniFi, после чего можно восстановить данные из бэкапа и выпить пивка.

На решение этой проблемы у меня ушло несколько недель — чуть не потерял весь контроллер и конфигурацию в процессе.

obryseco

Guest

#13

04.04.2018 03:29:00

У меня такая же проблема. В итоге мой контроллер оказался оффлайн на AWS EC2, и к нему невозможно было получить доступ ни через приложение, ни через веб. Подключился через SSH, вошёл, пытался запустить тест, но получил точно тот же результат: «connect failed».

ubuntu@ip-xx-xx-xx-xxx:~$ mongo --port 27117 < mongo_prune_js.js
MongoDB shell version: 2.4.9
connecting to: 127.0.0.1:27117/test
Wed Apr 4 03:19:33.193 Error: couldn't connect to server 127.0.0.1:27117 at src/mongo/shell/mongo.js:147
exception: connect failed

Появлялись ли какие-то обновления по этой теме?

wintegrations

Guest

#14

02.02.2018 18:20:00

После того как я нашёл резервную копию в каталоге /usr/lib/unifi/data/backup, смог скопировать её в домашнюю директорию и скачать с помощью CyberDuck на моём Mac.

Из терминала:
1. sudo su — понадобился доступ к root
2. passwd root — установил пароль для root на всякий случай, если забуду
3. cd /usr/lib/unifi/data/backup
4. cp filename.unf /home/ubuntu/
5. chmod -R 777 filename.unf
6. passwd -l root — убрал пароль доступа для root
7. Зашёл через CyberDuck на Mac и скачал файл
8. Создал снепшот своего AWS EBS тома, согласно другой теме на форуме
9. Подключился к своему elastic IP
10. Запустил стандартный мастер настройки UniFi контроллера (используя ссылку восстановления из резервной копии) — и вуаля. Мне ОЧЕНЬ повезло, что я нашёл авто-бэкап. Потерял 2 или 3 сети, добавленные с октября 2017 года, но в целом всё почти цело.

Спасибо за ваши ответы. Хоть мне и удалось обойтись без чистки, я точно вынес пару уроков про UniFi, linux/ubuntu, AWS и многое другое.

wintegrations

Guest

#15

01.02.2018 23:52:00

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

root@ip-xxx-xx-x-xx:/usr/lib/unifi/data/backup# ls -l
total 3212
-rw------- 1 unifi root 88624 May 25 2017 5.4.11_2z9pl2sz.unf
-rw------- 1 unifi root 86464 Mar 10 2017 5.4.11_b1jcv7g6.unf
-rw------- 1 unifi root 170512 Feb 19 2017 5.4.11_default.unf
-rw------- 1 unifi root 1802192 Oct 17 06:45 5.4.11.unf
-rw------- 1 unifi root 260912 Jan 25 2017 5.4.8.unf
-rw------- 1 unifi root 170336 Feb 9 2017 5.4.9_default.unf
-rw------- 1 unifi root 88336 Jan 25 2017 5.4.9_eijmy0n9.unf
-rw------- 1 unifi root 599376 Feb 13 2017 5.4.9.unf
drwx------ 2 unifi root 4096 Jan 25 2017 autobackup
-rw------- 1 unifi root 450 Oct 17 06:45 meta.json

Как узнать дату последнего изменения файла? Похоже, у меня есть резервная копия от октября 2017 года. Как я могу скачать её из этой папки? Я использую Terminal на Mac для SSH и CyberDuck на Mac, надеясь скачать этот файл. Когда пытаюсь зайти в эту папку через CyberDuck, он пропускает меня только до папки UniFi, дальше — отказ в доступе. Могу использовать команду chown, чтобы изменить права, но не уверен, повлияет ли это на контроллер. Я временно получил root-права через sudo su в Terminal.

[Не по теме] Моей ошибкой было то, что я не делал актуальные бэкапы. Сначала боялся, что слишком много места займет постоянное создание резервных копий и будет огромный счет в AWS. Задним числом всё понятно, но сейчас уж точно было бы меньше проблем, если бы я это сделал вовремя!

wintegrations

Guest

#16

01.02.2018 23:47:00

Спасибо за ответ. Да, unifi работает, как указано. Даже перезагружал unifi и пробовал снова. Я выяснил, что скрипт очистки не работает, потому что у MongoDB недостаточно свободного места для запуска. При проверке статуса он показывает «Остановлен/Ожидание». Попробовал следующее: создал snapshot моего EBS-тома на AWS, как советовал другой пользователь на форуме UniFi, подключил его к своему экземпляру t2.micro и загрузился. Система загрузилась нормально, и при входе в UniFi с этого snapshot тома он ведет себя так, будто UniFi в исходном состоянии и предлагает мастер настройки. Странно, что при запуске именно этого snapshot и проверке через SSH он показывает, что я теперь использую вдвое меньше места и при успешном пробном запуске (dryrun) сообщает ноль точек данных для очистки. Если я переключаюсь обратно на другой том, он все равно показывает 97% заполнения и падает на том же этапе, что и раньше. Если я создаю snapshot том точно такого же размера, как оригинал, он опять показывает 97% заполненности, но если делаю том, например, на 5 ГБ больше, возвращаюсь к UniFi в исходном состоянии. Даже пробовал просто расширить snapshot том на 5 ГБ — и опять появляется мастер настройки UniFi по умолчанию. Я в растерянности, что делать дальше! Есть ли какие-то файлы, которые можно вручную удалить через SSH, чтобы освободить место, или как вручную произвести очистку, если MongoDB не запускается? Есть мысли?

slooffmaster Guest	#17 04.04.2018 06:44:00 @wintegrations https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html

Читают тему (гостей: 1)