Я устанавливаю Ubuntu focal в netboot и у меня есть все основные вещи, которые работают без проблем. Я использую этот шаблон в качестве yaml-файла данных пользователя, и он заставляет пользователя, устанавливает пароль и импортирует все, что я указываю ssh ключ:
#cloud-config
autoinstall:
apt:
geoip: true
preserve_sources_list: false
primary:
- arches: [amd64, i386]
uri: http://us.archive.ubuntu.com/ubuntu
identity: {
hostname: <HOSTNAME>,
password: <PWHASH>,
realname: <USER>,
username: <USER>
}
user-data:
timezone: America/Los_Angeles
keyboard: {layout: us, toggle: null, variant: ''}
locale: en_US
network:
ethernets:
mainif:
match:
macaddress: <MAC>
set-name: eth0
eth0:
dhcp4: true
version: 2
ssh:
allow-pw: true
authorized-keys: [ <SSHKEY> ]
install-server: true
version: 1
Я хочу сделать так, чтобы пользователь должен был изменить свой пароль при первом входе в систему.
Вещи, которые я пробовал:
Поздняя команда
curtin in-target --target=/target --passwd - expire .
Это не удается, потому что поздние команды, по-видимому, выполняются до создания пользователей, несмотря на то, что в документации сказано
Команды Shell выполняются после успешного завершения установки и установки любых обновлений и пакетов, непосредственно перед перезагрузкой системы.`
Программа установки падает, и я вижу в отчете об ошибке /var/crash/$date.unknown.crash
, что команда завершилась неудачно со статусом выхода 1. Вход в систему вручную, chrooting в /target и попытка выполнить команду подтверждают это, говоря, что пользователь 'dan' не существует и не отображается в /etc/passwd или /etc/shadow:
Используя chpasswd: {истекает: True}
в разделе идентификации
Программа установки аварийно завершает работу, говоря, что chpasswd: неожиданна.
используя bootcmd
Это игнорируется
используя запоздалую команду для записи cron в /target
- /usr/bin/echo "@reboot root /usr/bin/passwd - expire dan && rm /etc/cron.d/update-pass" > /target/etc/cron.d/update-pass
Это делает работу, но кажется очень хрупкой и чрезвычайно трудной для поддержания.
Имеет ли автоинсталлятор встроенную функциональность, которую я не нашел?
Правка: Я собираюсь оставить то, что я поделился ниже, но я понял, что я исправил то, что вы хотите изменить опции создания пользователя, когда вы действительно хотите заставить пользователя изменить пароль при первом входе в систему.
Похоже, что в облаке
есть опция пароля по истечении срока действия. Поэтому для изменения файла /целевая цель/варинка/либ/облако/сея/необлако/данные пользователя
все еще можно использовать поздние команды
.
https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords
По умолчанию у всех пользователей системы истек срок действия их паролей (это означает, что при следующем входе пользователя в систему они должны будут быть сброшены)
Глядя на источник, это утверждение, похоже, применимо только к пользователям, пароль которых указан с помощью chpasswd
. Применение следующей конфигурации к данным пользователя -
может заставить пользователя сменить пароль при следующем входе в систему
chpasswd:
list: |
<USER>:<PWHASH>
Original Post ниже
Вам придется сделать что-то вроде использования поздних команд
для вызова sed
, чтобы изменить файл /цель/бар/либ/облако/сед/необлако/да/данные пользователя
.
Программа установки сервера, подзаголовок subiquity, принимает конфигурацию autoinstall
и создает конфигурацию cloud-init
для использования при первой загрузке. Однако, подзаголовок subiquity поддерживает только подмножество того, что cloud-init
на самом деле может сделать. Глядя на исходный код, вы можете увидеть, где на самом деле subiquity на самом деле жесткие коды, с этой настройкой на 'lock_passwd': False,
Вы не можете изменить пользователя в поздних командах
, так как пользователь еще не существует. Пользователь создается при первой загрузке по команде cloud-init
.
Этот фрагмент не протестирован, но такая конфигурация autoinstall
должна делать то, что вы хотите
late-commands:
- sed -ie 's/lock.passwd.*/lock_passwd: true,/' /target/var/lib/cloud/seed/nocloud-net/user-data
Незначительные подробности. В зависимости от версии subiquity, файл user-data
может содержать lock_passwd
или lock-passwd
. Регекс lock.passwd
должен совпадать и с тем, и с тем, что lock_passwd
хочет lock_passwd
. В начальной версии 20.04 была ошибка - https://github.com/canonical/subiquity/pull/784