I am assuming we want the ostreesetup command (and other stuff added to
interactive-defaults.ks [2]) to be configured during the compose/build
of the atomic installer iso, so trying to put it in installclass or
common anaconda would not fit here, and we should look for a mechanism
for adding kickstart snippet from installer image to regular kickstart
(and maybe interactive-defaults.ks as well).
For example using something like /usr/share/anaconda/kickstart/ config
file drop directory [1]. File
/usr/share/anaconda/kickstart/10-atomic.cfg generated during installer
iso build would be concatenated with regular kickstart. It would be
actually prepended, but we may want to add option (or have in mind doing
it in the future) to add it at the beginning or at the end (/pre /post
sub directory, or assume regular kickstart being 50-ks.cfgi ?).
Now for atomic we would need the same snippet to be added to
interactive-defaults.ks (non-kickstart installation) so:
- either lorax (atomic installer compose) would put the same snippet
also into interactive-defaults.ks during compose as it does now, but
that would make for example things like placing the 10-atomic.cfg file
via product.img impossible
- or anaconda would add 10-atomic.cfg to both regular kicstart (for
kickstart installation) and interactive-defaults.ks (for non-kickstart
installation), but that may be too inflexible for other possible usages
of the mechanism
- or we would have separate drop subdirs for kickstart and
interactive-defaults.ks
And as Martin Kolman reminded me, we could use the mechanism also to
unify defaults for anaconda password policy (kickstart vs non-kickstart
installations)
[1] We already have /usr/share/anaconda/kickstart/post-scripts
containing eg post scripts for copying screenshots and logs to target
system post install.
[2] /usr/shara/anaconda/interactive-defaults.ks
# Kickstart defaults file for an interative install.
# This is not loaded if a kickstart file is provided on the command line.
auth --enableshadow --passalgo=sha512
firstboot --enable
%anaconda
# Default password policies
pwpolicy root --notstrict --minlen=6 --minquality=50 --nochanges --notempty
pwpolicy user --notstrict --minlen=6 --minquality=50 --nochanges --notempty
pwpolicy luks --notstrict --minlen=6 --minquality=50 --nochanges --notempty
# NOTE: This applies only to *fully* interactive installations, partial
kickstart
# installations use defaults specified in pyanaconda/pwpolicy.py.
# Automated kickstart installs simply ignore the password policy
as the policy
# only applies to the UI, not for passwords specified in kickstart.
%end
ostreesetup --nogpg --osname=rhel-atomic-host --remote=rhel-atomic-host
--url=file:///install/ostree --ref=rhel-atomic-host/7/x86_64/standard
services --disabled cloud-init,cloud-config,cloud-final,cloud-init-local
%post --erroronfail
fn=/etc/ostree/remotes.d/rhel-atomic-host.conf; if test -f ${fn} && grep
-q -e '^url=file:///install/ostree' ${fn}$; then rm ${fn}; fi
%end
%post --erroronfail
rm -f /etc/ostree/remotes.d/*.conf
echo 'unconfigured-state=This system is not registered to Red Hat
Subscription Management. You can use subscription-manager to register.'
>> $(ostree admin --print-current-dir).origin
%end
Radek
On 15.2.2017 16:03, Colin Walters wrote:
I'd like to fix: https://pagure.io/atomic-wg/issue/226
Right now for Atomic Host, we embed the ostree content inside the squashfs,
with the goal that users of the ISO don't have to hit the network. We hook bits into
interactive-defaults.ks; see this change for how it works:
https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8a43d8244?branch=master
However, if one wants to then extract the ISO to do a kickstart install, the
user must repeat the `ostreesetup` bits:
https://lists.fedoraproject.org/archives/list/cloud@xxxxxxxxxxxxxxxxxxxxxxx/message/M6CEAGA3RGXZLSZ5GWSCTMMOV5OOXUUN/
Specifically from his attachment:
ostreesetup --osname="fedora-atomic" --remote="fedora-atomic" --url="file:////run/install/repo/content/repo" --ref="fedora-atomic/25/x86_64/docker-host" --nogpg
which is really internal implementation details that I'd like the ability to change
without breaking people's kickstarts, and conversely not require them to specify
by default.
Are there any facilities today for a "default kickstart" like
/usr/share/anaconda/interactive-defaults.ks, except not just interactive?
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
