Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
Hi Adam, Firstboot stays available in RHEL for this reason (legacy plugins). Fedora modules will probably have to be updated. At least that was the plan. It is very easy to write a new module with the new API. Ping vpodzime, he has a development guide. -- Martin Sivák msi...@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ - Original Message - > On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote: > > So I'm writing a blog post on this topic ATM, and that really kinda > > brought home how messy this design is at present. > > One thing that doesn't seem to have been covered in the discussion — > what about third-party firstboot modules? > > For an install on a corporate machine we have a firstboot module which > asks for the Active Directory credentials, joins the Samba domain, > obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions > those in NetworkManager, adds a local user with the appropriate > username, provisions accounts in Evolution-EWS and pidgin-sipe, etc. > > With firstboot gone, what form should our plugin take? > > -- > dwmw2 > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
Hi, Just to clarify things. Anaconda currently requires root password OR user with administrator privileges (wheel group). So if you set root password in Anaconda, initial-setup will start, but can be dismissed immediately. It might be good idea to add some explanation text to initial-setup together with the hiding feature (some configuration is hidden because it was set during the first install phase..) to avoid user confusion. -- Martin Sivák msi...@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
Hi, a quick note before I start: I am no longer maintainer of initial-setup. But since I started it I will answer some of the questions. > the main reason why we still have i-s while it's possible to do these > setup tasks in Anaconda itself are OEM installations. And I'm pretty > sure we don't have many ;-) OEM installations. We (Fedora) probably don't, but we need this functionality for other products as well. Plus there are some (enterprise..) hardware configurations that need special treatment before the first login. > So I agree with - putting as much functionality into Anaconda - licence, > welcome screen, user creation (at least recommend the creation in the > installer) and then there would be no reason to run i-s (unless user > is not created) and system-wide part of g-i-s. It was actually intended to behave this way from the beginning. All the screens are shared with Anaconda (and all we have right now live as part of Anaconda source code). The hide/skip functionality is missing, but there is a proof of concept patch that hides all already configured screens from initial-setup (http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/commit/?h=msivak&id=f679cafc5541b30b31bd5039004b6ccdcae3b54c). > Another reason why I'd prefer this solution are neverending problems with > firstboot/i-s theming under KDE. No theming, initial-setup is the last step of installation and so should be considered DE agnostic. For this reason it also looks the same as the installer. > > So, vpodzime, msivak: can we lobotomize initial-setup? We do not have to, initial-setup is just an empty shell that can execute Anaconda screens (either core screens or plugins, but the API is Anaconda based). Best regards -- Martin Sivák msi...@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ - Original Message - > - Original Message - > > On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote: > > > > > but still, it seems to be worth considering. Alternatively, we could > > > make i-s behave a lot more like g-i-s: it could dump its 'root password' > > > and 'date/time' spokes, and only run at all, and only to allow user > > > creation, if you didn't create a user during anaconda. > > > > Thinking about it more, this really seems to be the way to go. Forcing > > user creation in anaconda is a problem for someone who wants to do a > > minimal install with no user account. Doing the above would reduce the > > paths to something manageable without compromising any existing use > > cases. > > Well, > the main reason why we still have i-s while it's possible to do these > setup tasks in Anaconda itself are OEM installations. And I'm pretty > sure we don't have many ;-) OEM installations. > > I talked to vpodzime last week about the possibilities - two features > that are still not implemented are for EULA/license and Welcome screen. > Historically it was in firstboot as far as I know, is it the right place? > I'd say no - Anaconda is the first UI you see and with possibility to > finish all steps in one tool, it's non sense. For OEM again - it's different. > > So I agree with - putting as much functionality into Anaconda - licence, > welcome screen, user creation (at least recommend the creation in the > installer) and then there would be no reason to run i-s (unless user > is not created) and system-wide part of g-i-s. > > Another reason why I'd prefer this solution are neverending problems with > firstboot/i-s theming under KDE. > > > So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison > > the root password and time/date spokes, and make it only do user > > creation, and only run it if a user account was not created during > > anaconda? That seems to be the path forward to sanity, in my mind > > anyway. > > +1, I think Vratislav will be on board too after our latest > conversation ;-). > > Jaroslav > > > -- > > Adam Williamson > > Fedora QA Community Monkey > > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > > http://www.happyassassin.net > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi, the this should be not a problem. The intended logic here is requiring enabled root OR user(s). We might add ssh keys as a valid option if needed too (but I am not sure about entering the key, typing it manually is probably not a good idea). Moreover, initial-setup has a working quit button. Martin - Original Message - > > > From: Stephen Gallagher > > > That said, the current firstboot allows you to just walk through > > and > > skip user creation, last I checked. So I'm not sure why you need to > > cancel it. If you just don't enter anything in the username and > > password fields, it doesn't stop you. > > > Exactly right, and that's all I'm asking for out of the new firstboot > -- preferably with a keystroke or click from the initial firstboot > dialog. > > I just want to avoid what happened for a few old Fedora releases > (10-13 ish) where you were not allowed to skip user creation/joining > a domain short of having to go out out of your way by booting into a > non-default run-level, removing firstboot, etc. > > -- > John Florian > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi, > > When I install a freeipa server I do not want firstboot because I > > am not > > going to create local users anyway. I am going to install freeipa > > and > > then create users in LDAP. > Could such use cases not be built into firstboot? Right you are, see another proposed feature that works with FreeIPA and AD: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi, this has nothing to do with Gnome. Initial-setup will prepare system-wide settings regardless on the WM as firstboot did. The only difference here (which is not implemented yet) is to skip the user creation screens in case GDM is the login manager and Gnome asks for it. In that case GIE part of GDM will setup the users instead of firstboot. Rest of the screens will be shown as usual. Martin - Original Message - > On 01/28/2013 11:46 AM, Jaroslav Reznik wrote: > > = Features/NewFirstboot = > > https://fedoraproject.org/wiki/Features/NewFirstboot > > > > Feature owner(s): Martin Sivák > > > > This feature proposes new initial setup application with better > > integration to > > the NewUI anaconda and to Gnome Initial Experience. > > > > Will this work with other *DE's then Gnome? > > JBG > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi, yes, all the screens are shared with the Anaconda installer and the internal data structure is closely tied to kickstart. This allows us to configure almost everything using kickstart and then dump the final kickstart for the admin to see (as we always did). Headless is a bit harder, someone has to setup the users and root password. The init script supports it properly on s390, but not on the other platforms yet. How do you think we should detect headless mode? If the system was installed using serial console, systemd will ensure that the text interface is accessible there (the default terminal device) I hope. Martin - Original Message - > On Mon, Jan 28, 2013 at 11:46:40AM +, Jaroslav Reznik wrote: > > Anaconda, initial-setup and Gnome Inital Experience will > > communicate to ensure > > the screens are not shown multiple times. So for example the root > > password > > setup or user creation process will be done only in one place, > > depending on > > the installed system. > > Will it be possible to do all of the things within kickstart? > > Will there be a text-mode interface? > > Will the firstboot system be able to detect headless boots and do > something > sensible, or will such systems be stuck waiting for someone to attach > and > poke buttons? > > > -- > Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi, the tool will be started using systemd unit file which can be disabled. It will have to be explicit (even minimal install needs users or root password), but we can figure something out. Martin - Original Message - > > > From: Jaroslav Reznik > > > > = Features/NewFirstboot = > > https://fedoraproject.org/wiki/Features/NewFirstboot > > Please consider in the development of this to provide a simple means > to bypass this as easily as is currently possible with firstboot. > Our use case rarely involves making a custom kickstart (where we > could exclude this), but we do use the standard install image either > in Mimimal mode or with a user's preferred DE and then we have > puppet (or ansible or the like) do the rest, including > authentication set up, etc. I only mention this because in a Fedora > of long ago, firstboot insisted on creating a local user and it was > obnoxious to have to boot into single user mode first just so that > firstboot could be removed, puppet installed and the rest of the set > up be automated as desired. > > Firstboot is great for those who need it, but please remember that > not all need it. > > -- > John Florian > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi, no, system-config-* is not going to be used anywhere. Martin - Original Message - > Jaroslav Reznik wrote: > > = Features/NewFirstboot = > > https://fedoraproject.org/wiki/Features/NewFirstboot > > > > Feature owner(s): Martin Sivák > ... > > Firstboot currently depends on system-config-users, > system-config-authentication and system-config-date, causing them to > be included in a new Fedora installation. Those of us in the GNOME > community have been working to eliminate the need for these utilities > for some time. Will your proposal enable firstboot to lose its > dependencies on them? > > Allan > -- > IRC: aday on irc.gnome.org > Blog: http://afaikblog.wordpress.com/ > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi Adam, it will use Anaconda screens that already exist (like Time and Date, Root password) or are planned for F19 (User creation). So the project itself does not require any heavy coding. The 3rd party screens are out of our hands, but are not necessary for the system to work. The current firstboot does very little, it can create user and somehow update date and time. But yes, if we fail to accomplish this, the old firstboot is not going away, because it already does all the mandatory tasks. Martin - Original Message - > On Mon, 2013-01-28 at 11:46 +, Jaroslav Reznik wrote: > > = Features/NewFirstboot = > > https://fedoraproject.org/wiki/Features/NewFirstboot > > > > Feature owner(s): Martin Sivák > > > > This feature proposes new initial setup application with better > > integration to > > the NewUI anaconda and to Gnome Initial Experience. > > > > == Detailed description == > > Since the Anaconda installer moved to the NewUI Hub and Spoke > > concept, we can > > reuse much of it's architecture and screens in the after reboot > > configuration > > utility -- initial-setup. So the idea behind the firstboot > > replacement is that > > we will have a new app that will use the same Hub and Spoke model > > and the same > > API as Anaconda. > > > > This will give us the possibility of letting the user configure his > > system > > either during the package extraction or after reboot (important for > > OEMs). It > > will also allow other teams (power management, security team, IPA) > > to prepare > > their own screens for Anaconda and initial-setup and so further > > enhancing the > > user experience. > > > > Anaconda, initial-setup and Gnome Inital Experience will > > communicate to ensure > > the screens are not shown multiple times. So for example the root > > password > > setup or user creation process will be done only in one place, > > depending on > > the installed system. > > > > The old Firstboot will still stay as a fallback in case somebody > > still has his > > old Firstboot plugins he needs to use. > > I am concerned about the timeframe on this. The completion percentage > seems rather optimistic: > > "Percentage of completion: 70% (the engine is working, package > undergoing review, no configuration screens present)" > > To me, 'initial framework coding is complete but we haven't written > any > of the code that actually does stuff yet' is a long way short of 70%. > Especially since this is just re-using anaconda's hub/spoke setup, as > I > read it, so presumably implementing the 'engine' was the *easy* bit > of > the work. > > Does FESCo agree that 70% is a realistic completion percentage for > the > current state? Has a reliable evaluation of the likely amount of work > involved here, and the necessary time, been completed? > > At the least I'd suggest we take care to make sure the old firstboot > works in the F19 context as part of testing, and Martin prioritizes > fixes for it if we find any, so the contingency plan is viable if > work > on the new one is not sufficiently complete by Beta. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Hi, > If/when the "real work" behind a feature has been done early enough, > getting from Fedora alpha to final consists of just a few bugfixes Ah well.. only if everybody else did this so all the dependencies are stable. In which case you just moved the development freeze to earlier date. No improvement.. > > Basically there should not be any "this cannot be reverted" (there > > is > > no such thing really) features. If it is evident before the feature > > freeze that a given feature would not be ready in time we have to > > punt > > it to the next release PERIOD. Then there will be no possibility of major rewrites ever. Because some changes just take more than few months to execute and supporting a branch with very old (anaconda's GUI first commit in git is from 1999) codebase takes a lot of manpower. And to use drago's words: We do not have unlimited resources. When Gnome decides they are not fixing bugs for Gnome2 and put all resources to fixing Gnome3, you can wait, because most apps still depend on the mostly stable Gnome2 anyway and the bugs are not show stoppers, merely annoyances. When we do this in anaconda, you can't just use the older release, because other components are changing underneath us and the old release will break. So you will write bugs and RFEs for us to fix in the old branch so you meet your release deadline and mostly nobody will be testing the new branch. One release later at the alpha time.. we will get into the same issue of not being ready. We will take the heat whatever model we choose. So we have chosen. When this is done, we will have UI which has sane API and is separated from the other internal components and that will allow us to maintain the installer and firstboot in much better and easier way. Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
