Не удается войти во вновь созданную виртуальную машину ARM при использовании Set-AzureRmVMOSDisk с Linux и присоединить

Я пытаюсь разработать рабочий процесс клонирования для моей правильно работающей виртуальной машины ARM под управлением Ubuntu. Эта виртуальная машина была создана из образа Bitnami LAMP в Marketplace.

Я пытаюсь использовать параметр -CreateOption attach вместо fromImage, насколько мне известно, он должен работать... Я знаю, что есть другой вариант: deprovision-> Capture->-CreateOption fromImage, но с этим также возникают проблемы, см. Создание новой виртуальной машины ARM из захваченного образа: имя большого двоичного объекта в URL-адресе должно заканчиваться на '. vhd' extension error Рабочий процесс, которому я следовал, соответствует многим описаниям, и я не понимаю эту проблему входа в систему, надеюсь, я пропустил простой шаг...

Я пробовал этот рабочий процесс дважды с другими исходными виртуальными машинами ARM и получил те же результаты: новая машина кажется полностью работоспособной, но Я не могу войти с известным паролем пользователя на новую машину (через SSH).

Диагностика:

  • Даже веб-сервер и mysql работают на новой машине должным образом, потому что после запуска новой машины я могу просматривать обслуживаемые ею веб-сайты.
  • В приведенном ниже сценарии я пропустил настройку правил для входящего трафика, но успешно разрешил HTTP (см. выше) и SSH. SSH подключается с запросом пароля и оценивает его как неправильный.

Вот что я сделал:

  • Полностью функциональная виртуальная машина ARM остановлена ​​(waagent -deprovision не запускался)
  • Скопировал виртуальный жесткий диск ОС в новый большой двоичный объект .vhd (успешно, сценарий копирования не в тему)
  • Затем запустил следующий скрипт с полным успехом:

.

Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionName "Visual Studio Premium with MSDN"

# Create VM from an existing image

$location = "westeurope"
$vmSize = "Standard_DS2"

#Existing resource name parameters:
$rgName = "rg-wp"
$vnetName= "vn-wp" 
$stName = "mystorage"
#This vhd is a copy of a completely working ARM OS vhd: 
$vhdUri = "https://mystorage.blob.core.windows.net/vhds/disk-wp-01.vhd"

#Newly creatable resource names and other parameters
$vmName = "vm-wp-02"
$nicName="ni-wp-02"
$pipName="pip-wp-02"
$nsgName="nsg-wp-02"
$vhdName = "disk-wp-02"

$vnet = Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $rgName
$storageAccount = Get-AzureRmStorageAccount -AccountName $stName -ResourceGroupName $rgName 

$pip = New-AzureRmPublicIpAddress -Name $pipName -ResourceGroupName $rgName -Location $location -AllocationMethod Static -DomainNameLabel $pipName 
$nsg = New-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName -Location $location
$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id

# Configure VM: 
$vm = New-AzureRmVMConfig -vmName $vmName -vmSize $vmSize
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
$vm = Set-AzureRmVMOSDisk -VM $vm -Name $vhdName -VhdUri $vhdUri -Linux -CreateOption attach

New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm

person g.pickardou    schedule 08.03.2016    source источник
comment
Я только что попытался запустить это на образе bitnami и получаю сообщение об ошибке. Для создания виртуальной машины из образа Marketplace требуется информация о плане в запросе. Вы сталкивались с этим?   -  person Michael B    schedule 08.03.2016
comment
Нет. Однако только что изолированный, диагностированный этот случай, но я думаю, что вы используете -fromImage, а не -attach. Мой скрипт ниже работает как шарм, и виртуальная машина работает как шарм, только учетные данные для входа каким-то образом испорчены. Сообщение об ошибке, о котором вы говорите, я получил, когда пытался создать виртуальную машину из захваченного (не скопированного) образа. См. описанный случай с дополнительной диагностикой здесь: stackoverflow.com/q/35871496/1157814   -  person g.pickardou    schedule 08.03.2016


Ответы (2)


Я просмотрел это, и, кажется, что-то внутри битнами мешает ему войти в систему.

Я не тратил много времени на то, чтобы понять, как все соединяется, но там определенно есть код, который проверяет, когда новая виртуальная машина была развернута из образа, поскольку при этом всегда будут восстанавливаться ключи sshd.

Все ожидаемые файлы идентичны (я сравнил простую коробку Ubuntu и коробку Bitnami)

ошибка, которую он производит,

Mar  8 20:09:19 lamp sshd[2511]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=13.69.83.238  user=ubuntu
Mar  8 20:09:21 lamp sshd[2511]: Failed password for ubuntu from 13.69.83.238 port 32991 ssh2

Тем не менее, /etc/shadow имеет правильную соль / хеш для пароля, который я использую. Кто-то с большим опытом работы с Linux / bitnami может точно определить, в чем заключается ошибка. Но при первой чистке должно получиться...

Это работает точно так, как ожидалось, на обычном образе Ubuntu, поэтому может быть проще создать новую машину с нуля.

В противном случае вы можете получить лучший ответ, опубликовав его на форумах bitnami. (скорее всего, это просто настройка конфигурации)

person Michael B    schedule 09.03.2016
comment
Михаил, большое спасибо. Пожалуйста, не тратьте на это больше времени, случайно у меня есть некоторые результаты диагностики и некоторые мысли по этому поводу. Я собираюсь опубликовать ответ в ближайшее время. - person g.pickardou; 09.03.2016
comment
@g.pickardou Мне будет любопытно это прочитать! - Мне нравится тыкать в такие вещи, это хорошая практика, чтобы быстрее получить ответы для тех, кто оплачивает счета! (что, кажется, делает их счастливыми и, скорее всего, отправит чеки!) - person Michael B; 09.03.2016

Случайно получил диагностические результаты, экспериментируя с capture->create fromImage (CCFI) (не путать с copy->attach (CA), о чем этот вопрос)

Если вас не интересуют подробности, просто перейдите в самый конец и посмотрите «Известное на данный момент простейшее обходное решение».

Диагностика:

  • Если только что созданная виртуальная машина LAMP ARM на торговой площадке bitnami страдает от CA, то первоначальный пользователь-администратор не может войти в систему.

  • Если только что созданная виртуальная машина LAMP ARM на торговой площадке bitnami страдает от ошибки CCFI, то первоначальный пользователь с правами администратора может войти в систему, а новые учетные данные (admin2) также могут войти в систему.

  • если виртуальная машина, созданная с помощью CCFI, подвергается CA, то исходный пользователь-администратор может войти в систему, но admin2 (созданный в предыдущей версии CCFI) не может войти в систему.

После этого эксперимента я смог войти на машину CA-d, которая ранее была CCFI-d, с первоначальным пользователем-администратором.

Изучив /etc/shadow оказалось, что admin2 был отключен: (знак !) перед хешем пароля. Остается только вопрос, кто из умников совершил этот явно нежелательный и неожиданный поступок. У нас есть два подозреваемых и три сценария:

  • какой-то пользовательский скрипт битнами
  • ваагент
  • waagent введен в заблуждение каким-то пользовательским действием битнами или неправильной конфигурацией

Хотя я не уверен, но мое предположение - "чистый waagent", второй - "waagent введен в заблуждение..."

И вот почему: я изучил файл /var/lib/waagent/ovf-env.xml и обнаружил, что

<ns1:UserPassword>REDACTED</ns1:UserPassword>

запись там для последнего подготовленного пользователя. Это для «admin» в случае машины с девственной торговой площадкой и admin2 для машины CCFI-d. Когда машина подвергается CA, этот пользователь будет отключен. Поскольку этот файл принадлежит waagent, я предполагаю, что waagent каким-то образом обнаруживает операцию CA (почему???) и при первом запуске отключает пользователя. Диагностика точно соответствует этой теории.

Одно можно сказать наверняка: эта проблема представляет собой нежелательный автоматизм, который происходит с самой виртуальной машиной и либо специфичен для bitnami, либо специфичен для Linux.

Эта проблема возникает всегда во время/после CA. Это явно нежелательно, потому что CA не имеет ничего общего с инициализацией, деинициализацией, обобщением, очисткой конфиденциальной информации и т. д.

Временное решение:

Испытано и доказано: CCFI, тогда вы можете CA для CCFI-d VM столько раз, сколько захотите.

Известный в настоящее время простейший обходной путь:

Стоит попытаться исключить CCFI из обходного пути, потому что это требует времени. (не говоря о том, что исходная машина, которая была обобщена, больше не может быть запущена по дизайну (Azure)

На любой машине сделайте следующее:

sudo adduser dummyadmin
sudo adduser dummyadmin sudo
edit the /var/lib/waagent/ovf-env.xml file and replace admin to dummyadmin

Если вы сделаете это на любом компьютере, в том числе на изначально созданном, а затем настроенном на рынке компьютере, вы можете свободно СА для него. Конечно, вы не можете войти в новую машину с помощью dummyadmin, но вы можете войти в систему с помощью admin.

person g.pickardou    schedule 09.03.2016
comment
Это хорошее расследование! Обходной путь может состоять в том, чтобы иметь собственный скрипт, который повторно активирует пользователя. Кроме того, я только что прочитал скрипт waagent и не могу увидеть что-нибудь в них, что может быть изменением паролей (есть жестко запрограммированное отключение root) - person Michael B; 09.03.2016
comment
Кто-нибудь делает этот отключенный спорт, его можно обмануть, добавив 2-го dummyadmin... Очень маловероятно, что bitnami читает файл waagent, поэтому четкий диагноз будет, если только добавить dummyamin, (последний пользователь будет в тени файл) и не изменяя файл ovf-env.xml. Потом ЦА. Если dummyuser будет отключен, то битнами, если исходный admin отключен, то waagent. - person g.pickardou; 09.03.2016