Давно пользуюсь терминальным клиентом ZOC . Не умоляю возможности Putty, но я привык к нему, все настроено и всем устраивает.
но в UBUNTU 14 и выше пошел баг — не подключается по SSH, причем из Putty все работает.
выдает ошибку:
[SSH] FAIL: no kex alg<br /><br />решается просто.<br />в файле /etc/ssh/sshd_config добавляем стоку<br /><br />
KexAlgorithms diffie-hellman-group1-sha1<br /><br />и перезапускаем сервис.
ЗАмена Openfiler
т.к самому скоро переезжать, то собираю инфу, хотя у меня и vSphere, но…
http://www.vm4.ru/2008/11/vi3.html
Переезд VI3. Опыт. Грабли.
Понадобилось мне переехать. Для этого была отключена вся инфраструктура VI3.
Какие были проблемы.
1. Отсутствие бекапов. Да, не удивляйтесь, но их не было.Делайте ! Пусть даже и через Clone на горячей системе, если нет VCB. Такой Clone можно делать начиная с ESX 3.5 U2. Их отсутствие прибавило мне седых волос и убавило нервных клеток (хоть они и восстанавливаются).
2. Не делайте suspend для ВМ. После запуска VI и ВМ, часть ВМ машин работала криво. Где отъехала сеть, где демоны, где пинг был огромным. Пришлось всё перезагружать. К тому же с suspend-машину нельзя отредактировать, что очень было надо. Лучше выключить все ВМ машины.
3. Видимо отключение ESX хостов надо проводить через maintance mode. После включения VI, луны с VMFS оказались заблокированными. Как с этим бороться.
http://blog.vadmin.ru/2008/11/vi.html
4. DNS это маленькая подзадача. Выносится на отдельную маленькую ВМ. НО ! После включения VC, хосты ввести нельзя — DNS’а нет ! Выход — прописать имена в файл hosts на VC. Правильный выход — второй DNS не на ВМ.
5. Не штатная проблема. После включения ESX хостов, у меня не оказалось DataStore’s. LUN’ы видны, а DataStore нет. А точнее луны пустые.
Как это получилось я не знаю, и вряд ли когда-нибудь узнаю. Как лечить — рассказано здесь.
http://blog.vadmin.ru/2008/11/vmfs.html
Вообщем ситуация такова: хранилище exchane больше 200гб, место на диске заканчивается с умопомрачительной быстротой, «резать» пока возможности нет, т.к. не знаешь сколько это займет. вариант выживания один — перенос базы на новый больший диск, благо все это работает на связке ESX vSphere + OpenFiler, т.е. минус перезагрузка для подключения дисков.
Цель этой заметки — примерно обрисовать время по переносу для «будущих поколений».
Итак, вся процедура проделывается по такой инструкции(полный вариант инструкиции на http://support.microsoft.com/kb/821915):
1. Запустите диспетчер Exchange System Manager.
2. Откройте группу администраторов, содержащую базу данных, которую необходимо изменить.
3. В списке Storage Group щелкните правой кнопкой мыши хранилище почтовых ящиков или общих папок, которое необходимо изменить, и выберите Properties.
4. Откройте вкладку Database.
5. Нажмите кнопку Browse рядом с именем базы данных, которую необходимо изменить, после чего укажите новый диск или папку для файлов.
Примечания.
* При переносе баз данных можно переместить базу данных Exchange (файл .edb) или потоковую базу данных Exchange Streaming (файл .stm), а также обе эти базы.
* Если базы данных по-прежнему присоединены, появится следующее сообщение:
You are about to perform the following operation(s):
— change Exchange database location
To perform the requested operation(s), the store must be temporarily dismounted which will make it inaccessible to any user.
Do you want to continue?
Нажмите кнопку Да, чтобы автоматически отключить базу данных и перенести ее в другое место.
6. Завершив перенос баз данных, подключите их вручную.
Файлы журналов и базы данных можно перемещать в любую созданную папку. Перемещая файлы журналов и баз данных, для сохранения целостности данных можно создать файловую структуру Exchsrvr\Mdbdata, однако делать это не обязательно.
В сухом остатке получаем перенос базы на каналах в 1Гб занял 5 часов….все прошло пучком, базы целы, пользователи довольны.:)