#53: anaconda doesn't allow installation of current fedora-cloud-base.ks
-+-
Reporter: walters | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Resolution:
Keywords: |
-+-
Comment (by walters):
walters dgilmore, did you see the conclusion of yesterday's thread? is
setting a root pw in kickstart then locking good enough?
dgilmore walters: its really not
walters dgilmore, ok, we need to figure this out; i'm interested as I
need to be producing cloud images via anaconda as well
walters should take this to a bug or something
dlehman pardon me for being behind, but what's the problem?
dlehman you want root locked but anaconda doesn't allow that?
dgilmore dlehman: anaconda doesnt allow it without creatinga user
walters dlehman, i think the typing to catch you up is best done in a
bug
dlehman fair enough
dgilmore dlehman: need to be able to say the root account can be locked
if a package that will configure the system on first boot is installed
dlehman dgilmore: and the rationale is that we can't know for sure if
there will be compulsory user-account creation, so we can't lock root,
right?
dgilmore walters: but yeah a bug is probably best
walters https://fedorahosted.org/cloud/ ?
dgilmore dlehman: well we can deal with it all in %post, but that is
easy to get wrong
walters i can wordsmith this
dlehman the only way anaconda could let this slide, I think, is if those
initial-setup packages provide something that says I take full
responsibility for compulsory user account configuration
dlehman then we can just reassign the bugs to those packages when they
inevitably come
dgilmore dlehman: right
dlehman so I think those various packages should have Provides: user-
account-setup
walters https://fedorahosted.org/cloud/ticket/53
dgilmore dlehman: i am okay with that
dgilmore initial-setup cloud-init etc can all provide that
dlehman and that means if they get installed it's their responsibility
to see to it that the accounts are created
dlehman it doesn't matter what else is installed, doesn't matter what
the user does, c c
davidshea we'd need a way to ensure that the service or whatever is
actually enabled on boot. that's all over the place right now
walters are you saying anaconda would come with code to check the rpm
transaction for something with the requisite provides?
dlehman it certainly sounds better than maintaining a list of packages
that may or may not handle it
dlehman I'm not volunteering, but if you want something better than what
we have now this seems like the way to go.
dlehman we can log prominently WARNING: not enforcing user account
creation because package foo will handle it on the reboot
walters though come to think of it, this isn't going to work for me
walters at least not easily
walters since min-metadata-service will likely be in the default tree,
just not enabled
walters as davidshea says
walters maybe in the future i'd have a variant tree for cloud, also with
stuff like the physical kernel drivers stripped out
* walters keeps coming back to the idea of a kickstart verb for this
--
Ticket URL: https://fedorahosted.org/cloud/ticket/53#comment:1
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
