Re: Call for Bikeshedding: remote auth at install time
On Tue, 2013-06-11 at 07:47 +0200, Stef Walter wrote: even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? I will, yes. I'm inferring that you *don't* need me to file a bug for pidgin because you're already looking at it? Is that (still) correct? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 17.06.2013 13:22, David Woodhouse wrote: On Tue, 2013-06-11 at 07:47 +0200, Stef Walter wrote: even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? I will, yes. I'm inferring that you *don't* need me to file a bug for pidgin because you're already looking at it? Is that (still) correct? Would be helpful to file a bug ... to make sure we're talking about the samething.. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 06/05/2013 03:37 PM, Stef Walter wrote: What does work, and has been tested is logging in as root and simply typing this: realm join mydomain.com I filed https://bugzilla.redhat.com/show_bug.cgi?id=975182 because of confusing error messages when there is no pre-existing AD computer acct: realm join --user=przemek mydomain ... Password for przemek: ... Enter przemek's password: Failed to join domain: User specified does not have administrator privileges ! Insufficient permissions to join the domain mydomain realm: Couldn't join realm: Insufficient permissions to join the domain The error message is incorrect---I do have the required privileges: the real reason is that at this point the domain has to have a computer account created for this computer, and it didn't. If I create the computer account in Windows AD and retry, the operation succeeds: realm join --user=przemek mydomain ... Password for przemek: ... Enter przemek's password: DNS update failed: NT_STATUS_UNSUCCESSFUL Using short domain name -- MYDOMAIN Joined 'myhost' to dns domain 'mydomain' DNS Update for myhost failed: ERROR_DNS_GSS_ERROR * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.3WTOYW -U przemek ads keytab create Enter przemek's password: * /usr/bin/systemctl enable sssd.service ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service' * /usr/bin/systemctl restart sssd.service * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart /usr/bin/systemctl enable oddjobd.service * Successfully enrolled machine in realm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 17.06.2013 20:44, Przemek Klosowski wrote: On 06/05/2013 03:37 PM, Stef Walter wrote: What does work, and has been tested is logging in as root and simply typing this: realm join mydomain.com I filed https://bugzilla.redhat.com/show_bug.cgi?id=975182 because of confusing error messages when there is no pre-existing AD computer acct: Thanks for the bug. But I think this is a WONTFIX (or can't fix). Details in the bug. Please correct me if I've missed something. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Sun, 2013-06-09 at 09:24 +0930, Glen Turner wrote: I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. FWIW I've had some of this working fairly nicely. A firstboot module takes the user's AD credentials, uses the internal PKI infrastructure to obtain SSL certificates for wifi and VPN, drops the appropriate NetworkManager config into place. That's the easy bit. Also configuring Evolution-EWS and pidgin-sipe is a bit harder, and Evolution is even *harder* to configure like that now that its account config has been improved (I last had it working when it involved gconftool-2). And Fedora 19 should *finally* make it vaguely sane to import the corporate SSL CAs to a central location rather than having to do it in seventeen different places for different SSL libraries and sometimes even special locations for *particularly* braindamaged applications (pidgin). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 10.06.2013 23:35, David Woodhouse wrote: On Sun, 2013-06-09 at 09:24 +0930, Glen Turner wrote: I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. FWIW I've had some of this working fairly nicely. A firstboot module takes the user's AD credentials, uses the internal PKI infrastructure to obtain SSL certificates for wifi and VPN, drops the appropriate NetworkManager config into place. That's the easy bit. Also configuring Evolution-EWS and pidgin-sipe is a bit harder, and Evolution is even *harder* to configure like that now that its account config has been improved (I last had it working when it involved gconftool-2). And Fedora 19 should *finally* make it vaguely sane to import the corporate SSL CAs to a central location rather than having to do it in seventeen different places for different SSL libraries and sometimes Fedora 19 makes this possible (drop a file in a directory, run a command), and Fedora 20 will make in smooth (tools, apis for it). even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
Kickstart is fine for centrally managed devices. They've got experienced sysadmins who don't mind getting dirty with configuration files. The real kicker is people who manage their own device: not just BYOD but also part-time sysadmins who can't run the corporate distribution. These people can suck substantial time from deep support at the help desk. For those people there does needs to be an easy way for them to configure a network authenticating account. But there's no need for that to be in the installation dialogues. Considering that IT support might approach them well after installation and say our policy is that machine authenticate against the Corporate Blah rather than have local authentication there's a strong argument for being able to do this well away from installation. I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. -glen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Sun, 2013-06-09 at 09:24 +0930, Glen Turner wrote: Kickstart is fine for centrally managed devices. They've got experienced sysadmins who don't mind getting dirty with configuration files. The real kicker is people who manage their own device: not just BYOD but also part-time sysadmins who can't run the corporate distribution. These people can suck substantial time from deep support at the help desk. For those people there does needs to be an easy way for them to configure a network authenticating account. But there's no need for that to be in the installation dialogues. Considering that IT support might approach them well after installation and say our policy is that machine authenticate against the Corporate Blah rather than have local authentication there's a strong argument for being able to do this well away from installation. I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. Thanks. Those are some good thoughts, but since I'm just the test monkey, I'm on a strict focus: 'blocker or not blocker'. I'm sure the devs working on remote auth configuration would be interested in your thoughts, though! -- 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
Re: Call for Bikeshedding: remote auth at install time
On 04.06.2013 15:34, Simo Sorce wrote: On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. Realmd is a good tool, but works only with Windows Ad or FreeIPA. It is useless to configure against a classic directory and/or Kerberos server or NIS or things like that. Agreed that is the case right now. But it's a goal to make it grow into those relevant use cases in that area so that we can have a non-Red-Hat-specific tool and API for accomplishing these things. On the other hand neither authconfig or realmd will ever provide all a GUI for the possible ways (many broken) ways you can possibly configure network authentication. Anaconda used to have authconfig integration, was it yanked on rewrite ? Anaconda did not have the GTK dialog. firstboot was the one that had it. And it's really broken for most use cases. It doesn't install necessary software or anything like that. So one really needs to know ahead of time all the dependencies of the network authentication you plan to use, and choose those in the installer. It was part of the plan to have a GUI for realmd be part of anaconda. But the merge of the basic anaconda kickstart patches, took so so long to merge (they've been ready since October) that the GUI bits were not done in time. See 'Contingency Plan' here: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration#Contingency_Plan Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Wed, 2013-06-05 at 16:55 +0200, Stef Walter wrote: On 04.06.2013 15:34, Simo Sorce wrote: On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. Realmd is a good tool, but works only with Windows Ad or FreeIPA. It is useless to configure against a classic directory and/or Kerberos server or NIS or things like that. Agreed that is the case right now. But it's a goal to make it grow into those relevant use cases in that area so that we can have a non-Red-Hat-specific tool and API for accomplishing these things. On the other hand neither authconfig or realmd will ever provide all a GUI for the possible ways (many broken) ways you can possibly configure network authentication. Anaconda used to have authconfig integration, was it yanked on rewrite ? Anaconda did not have the GTK dialog. firstboot was the one that had it. And it's really broken for most use cases. It doesn't install necessary software or anything like that. So one really needs to know ahead of time all the dependencies of the network authentication you plan to use, and choose those in the installer. It was part of the plan to have a GUI for realmd be part of anaconda. But the merge of the basic anaconda kickstart patches, took so so long to merge (they've been ready since October) that the GUI bits were not done in time. See 'Contingency Plan' here: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration#Contingency_Plan So the endgame here is that there will be no remote authentication option in anaconda *nor* in firstboot. Can we get a button to skip g-i-s mandatory user creation then ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 05.06.2013 17:38, Simo Sorce wrote: On Wed, 2013-06-05 at 16:55 +0200, Stef Walter wrote: On 04.06.2013 15:34, Simo Sorce wrote: On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. Realmd is a good tool, but works only with Windows Ad or FreeIPA. It is useless to configure against a classic directory and/or Kerberos server or NIS or things like that. Agreed that is the case right now. But it's a goal to make it grow into those relevant use cases in that area so that we can have a non-Red-Hat-specific tool and API for accomplishing these things. On the other hand neither authconfig or realmd will ever provide all a GUI for the possible ways (many broken) ways you can possibly configure network authentication. Anaconda used to have authconfig integration, was it yanked on rewrite ? Anaconda did not have the GTK dialog. firstboot was the one that had it. And it's really broken for most use cases. It doesn't install necessary software or anything like that. So one really needs to know ahead of time all the dependencies of the network authentication you plan to use, and choose those in the installer. It was part of the plan to have a GUI for realmd be part of anaconda. But the merge of the basic anaconda kickstart patches, took so so long to merge (they've been ready since October) that the GUI bits were not done in time. See 'Contingency Plan' here: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration#Contingency_Plan So the endgame here is that there will be no remote authentication option in anaconda *nor* in firstboot. Is it really gone from firstboot? Can we get a button to skip g-i-s mandatory user creation then ? I think that makes sense for some Fedora use cases. It would mean skipping g-i-s all together, since it's heavily centered around setting up a user. In any case Matthias is the upstream maintainer and I think Fedora packager too. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Wed, 2013-06-05 at 21:22 +0200, Stef Walter wrote: So the endgame here is that there will be no remote authentication option in anaconda *nor* in firstboot. Is it really gone from firstboot? firstboot does not exist any more. There are two replacements in F19. 'initial-setup' is used for all non-GNOME paths; it is basically a thin wrapper around a few of anaconda's spokes. It uses the exact same user creation spoke code as anaconda, so it supports whatever anaconda supports. 'gnome-initial-setup' is used for all GNOME installs (well, unless you fiddle with a kickstart). Up until g-i-s 0.10.x - what's in F19 Beta - its remote auth configuration code was entirely and irretrievably broken; the screen was there but it had zero chance of ever achieving anything. From 0.11 on - what's in F19 Final TC1 and later - it ought to be working a bit better, so there is _some_ capability for remote auth configuration on our default desktop, but it's very new code, probably still buggy, and limited in scope (as of course you know). Can we get a button to skip g-i-s mandatory user creation then ? I think that makes sense for some Fedora use cases. It would mean skipping g-i-s all together, since it's heavily centered around setting up a user. In any case Matthias is the upstream maintainer and I think Fedora packager too. There's a bug report where Simo and Matthias have gone around a few times on this: https://bugzilla.redhat.com/show_bug.cgi?id=958189 . I'll say no more. On the non-GNOME path, user creation can be skipped in initial-setup. -- 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
Re: Call for Bikeshedding: remote auth at install time
On 04.06.2013 17:44, Adam Williamson wrote:
On Tue, 2013-06-04 at 10:26 -0400, Przemek Klosowski wrote:
For what it's worth, remote authentication is increasingly important
where I sit, so everything that makes it easier to set up is welcome. As
of now, my cheat sheet for older Fedoras and RHEL is several pages long
and involves manual reconfiguration of samba/winbind, kerberos and pam
modules--but I haven't tried to do it in F19 yet, either way. What keeps
bugging me is that the whole lashup is fragile and involves magic
('winbind crashed with no error messages; restart it; oops crashed
again; restart samba maybe; YAY, success, don't touch anything')
I would be tickled pink if it's a more supported workflow now. I will
check it out and file bugs or kudos, depending on the outcome.
If you have issues, would love to hear about them. Please CC me on bugs.
If you're interested in getting involved, you can look through the test
cases here:
https://fedoraproject.org/wiki/Test_Day:2013-05-09_SSSD_Improvements_and_AD_Integration
Well, right now, you're not going to get any further than the cited bug
report (https://bugzilla.redhat.com/show_bug.cgi?id=965883 ) with
anaconda / i-s; that's all you get. g-i-s 0.11 should have
somewhat-working remote auth config support for the first time, though
as Simo has noted, it is more or less limited to AD and FreeIPA, and it
hasn't been tested very much at all (because up until 0.11 it was
utterly broken). Fedora 19 Final TC1 should be the first build with
g-i-s 0.11.
What does work, and has been tested is logging in as root and simply
typing this:
realm join mydomain.com
Alternatively put that command in kickstart.
Use --verbose to see gory details, and --user if necessary.
And then you should be able to use remote authentication and identities.
For now that's with FreeIPA and AD domains, but hopefully we'll be able
to do more later.
Cheers,
Stef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. For me, as a system administrator of a number of labs that all use Fedora, the main inconvenience is being forced to create a local user at install time. I don't mind going through manual configuration to get LDAP / Kerberos setup on the desktop, but it's a pain to setup a local user, complete with password that passes the complexity checks, just to delete it. Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
Basically, we (as in, the people who do blocker review) need to know if remote auth at install/firstboot time is really important. Once we know that, we can go out and get the blocker decisions against anaconda, i-s, g-i-s, whatever else correct. Just trust us, and answer the initial question. We're doctors. :) By remote auth at install time fo you mean set it up and log straight in as a remote user or just set it up? From experience kerberos generally likes a reboot before it will work properly because it likes to have realms and reverse DNS and all that stuff right from boot. Personally I think in a lot of use cases where they setup remote auth it would be done as part of a kick start install and not matter so much so personally I don't see it as a blocker issue. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Tue, Jun 4, 2013 at 8:06 AM, Jonathan Dieter jdie...@lesbg.com wrote: On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. For me, as a system administrator of a number of labs that all use Fedora, the main inconvenience is being forced to create a local user at install time. I don't mind going through manual configuration to get LDAP / Kerberos setup on the desktop, but it's a pain to setup a local user, complete with password that passes the complexity checks, just to delete it. Don't you manage those lab builds with a build system and kickstarts to automate the install and configuration of things like ldap/kerberos? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Mon, 2013-06-03 at 21:53 -0400, Matthias Clasen wrote: On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. We've fixed the remote auth support in gnome-initial-setup in https://admin.fedoraproject.org/updates/FEDORA-2013-9570/gnome-initial-setup-0.11-1.fc19 so it is not entirely impossible anymore. Works only for a very limited set of cases, and afaik it does not configure the whole system. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Tue, 2013-06-04 at 09:19 +0100, Peter Robinson wrote: Basically, we (as in, the people who do blocker review) need to know if remote auth at install/firstboot time is really important. Once we know that, we can go out and get the blocker decisions against anaconda, i-s, g-i-s, whatever else correct. Just trust us, and answer the initial question. We're doctors. :) By remote auth at install time fo you mean set it up and log straight in as a remote user or just set it up? From experience kerberos generally likes a reboot before it will work properly because it likes to have realms and reverse DNS and all that stuff right from boot. Personally I think in a lot of use cases where they setup remote auth it would be done as part of a kick start install and not matter so much so personally I don't see it as a blocker issue. There is absolutely no problem configuring Kerberos at any time, no reboot required (I know very well, my team works with kerberos daily). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGt5XoACgkQeiVVYja6o6O2lQCgqhHIFLXRXbWI0FIZBhsfy5U0 aIoAoIXpWiim1H8bjDnSX9LEzOlTyZrT =pV7x -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. Realmd is a good tool, but works only with Windows Ad or FreeIPA. It is useless to configure against a classic directory and/or Kerberos server or NIS or things like that. Anaconda used to have authconfig integration, was it yanked on rewrite ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 06/03/2013 09:07 PM, Adam Williamson wrote:
We all know what devel@ does best, so let's fire up the power of the
bikeshedding machine :)
We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of
release blocker candidates that we evaluated at the blocker review
meeting this morning. Attendance at blocker reviews is pretty spotty
these days (please, people, come out and feel in a position of ABSOLUTE
POWER), and no-one present felt like they were a huge expert on typical
remote authentication use cases, so we really didn't feel qualified to
make a call on this one.
As things stand, in Fedora 19, it's basically impossible to configure
remote authentication from the install/firstboot process. If you want to
use remote auth, you'd have to create a local user first and then do it
using whatever tools are available. anaconda / initial-setup has a
button for Use network login... on its 'user creation' spoke which
ought to be where you configure remote auth, but right now it does
precisely nothing at all.
Whether this is a blocker or not comes down to a judgement call, because
it hinges on whether this is a significant inconvenience for a large
enough number of users. So we need to know from people who use Fedora in
remote auth environments whether it's a big problem not to be able to
set it up at install / firstboot time, or whether you'd be okay with
creating a local user to get through initial-setup and then configuring
remote auth from that local account.
For what it's worth, remote authentication is increasingly important
where I sit, so everything that makes it easier to set up is welcome. As
of now, my cheat sheet for older Fedoras and RHEL is several pages long
and involves manual reconfiguration of samba/winbind, kerberos and pam
modules--but I haven't tried to do it in F19 yet, either way. What keeps
bugging me is that the whole lashup is fragile and involves magic
('winbind crashed with no error messages; restart it; oops crashed
again; restart samba maybe; YAY, success, don't touch anything')
I would be tickled pink if it's a more supported workflow now. I will
check it out and file bugs or kudos, depending on the outcome.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 06/04/2013 02:26 PM, Przemek Klosowski wrote:
('winbind crashed with no error messages; restart it; oops crashed
again; restart samba maybe; YAY, success, don't touch anything')
Pre systemd winbind/samba migration or after systemd winbind/migration (
which means we might need to fix something in the samba units )
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 06/04/2013 10:28 AM, Jóhann B. Guðmundsson wrote:
On 06/04/2013 02:26 PM, Przemek Klosowski wrote:
('winbind crashed with no error messages; restart it; oops crashed
again; restart samba maybe; YAY, success, don't touch anything')
Pre systemd winbind/samba migration or after systemd winbind/migration (
which means we might need to fix something in the samba units )
pre-migration, but the crash is 'reliable' i.e. when it crashes it
crashes all the time. By the way, what is systemd going to do in such
case---restart a couple of times and give up, I hope?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Tue, 2013-06-04 at 10:06 +0300, Jonathan Dieter wrote: On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. For me, as a system administrator of a number of labs that all use Fedora, the main inconvenience is being forced to create a local user at install time. I don't mind going through manual configuration to get LDAP / Kerberos setup on the desktop, but it's a pain to setup a local user, complete with password that passes the complexity checks, just to delete it. gnome-initial-setup forces creation of a user account, but there are sekrit hacks you can use to skip it - https://bugzilla.redhat.com/show_bug.cgi?id=958189#c9 gives one (or you could just not include g-i-s in your kickstart). anaconda and initial-setup do not force the creation of a user account. (also as another sidebar, g-i-s is no longer enforcing the password complexity check; anaconda and i-s never have, it's only a warning). -- 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
Forced user creation (was Re: Call for Bikeshedding: remote auth at install time)
On Tue, 2013-06-04 at 08:43 -0400, Simo Sorce wrote: On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. Can we get back an option to not create a user at first boot ? Can we please not derail the discussion? But, at present, only g-i-s does this, and that's up to upstream GNOME. anaconda and i-s do not (and will not) require user creation. i-s will be amended to warn if you don't create an account (like firstboot did), but it will let you go ahead if you acknowledge the warning (like firstboot did). -- 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
Re: Call for Bikeshedding: remote auth at install time
On Tue, 2013-06-04 at 10:26 -0400, Przemek Klosowski wrote:
For what it's worth, remote authentication is increasingly important
where I sit, so everything that makes it easier to set up is welcome. As
of now, my cheat sheet for older Fedoras and RHEL is several pages long
and involves manual reconfiguration of samba/winbind, kerberos and pam
modules--but I haven't tried to do it in F19 yet, either way. What keeps
bugging me is that the whole lashup is fragile and involves magic
('winbind crashed with no error messages; restart it; oops crashed
again; restart samba maybe; YAY, success, don't touch anything')
I would be tickled pink if it's a more supported workflow now. I will
check it out and file bugs or kudos, depending on the outcome.
Well, right now, you're not going to get any further than the cited bug
report (https://bugzilla.redhat.com/show_bug.cgi?id=965883 ) with
anaconda / i-s; that's all you get. g-i-s 0.11 should have
somewhat-working remote auth config support for the first time, though
as Simo has noted, it is more or less limited to AD and FreeIPA, and it
hasn't been tested very much at all (because up until 0.11 it was
utterly broken). Fedora 19 Final TC1 should be the first build with
g-i-s 0.11.
--
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
Call for Bikeshedding: remote auth at install time
We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. Thanks! -- 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
Re: Call for Bikeshedding: remote auth at install time
On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. We've fixed the remote auth support in gnome-initial-setup in https://admin.fedoraproject.org/updates/FEDORA-2013-9570/gnome-initial-setup-0.11-1.fc19 so it is not entirely impossible anymore. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Mon, 2013-06-03 at 21:53 -0400, Matthias Clasen wrote: On Mon, 2013-06-03 at 18:07 -0700, Adam Williamson wrote: As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. We've fixed the remote auth support in gnome-initial-setup in https://admin.fedoraproject.org/updates/FEDORA-2013-9570/gnome-initial-setup-0.11-1.fc19 so it is not entirely impossible anymore. I was trying to glide right by that one without introducing unnecessary complexity into the discussion - I've found people who haven't actually experienced both paths have a hard time wrapping their heads around The Great Initial Setup Dichotomy. But yes, in F19 Beta it was broken in g-i-s too, but soon it should not be. But we have a fully-supported paths which never hit g-i-s at all - a KDE install, a minimal install - so I think we can actually skate right by it for the purpose of this discussion. Basically, we (as in, the people who do blocker review) need to know if remote auth at install/firstboot time is really important. Once we know that, we can go out and get the blocker decisions against anaconda, i-s, g-i-s, whatever else correct. Just trust us, and answer the initial question. We're doctors. :) -- 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
Re: Call for Bikeshedding: remote auth at install time
On Mon, 2013-06-03 at 19:02 -0700, Adam Williamson wrote: But yes, in F19 Beta it was broken in g-i-s too, but soon it should not be. But we have a fully-supported paths... excuse me just one second, I hear the doorbell... ... oh, dear. It seems to be my high school English teacher, holding a sturdy length of 2x4 with a rusty nail in it. -- 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
Re: Call for Bikeshedding: remote auth at install time
Don't mess with teachers. They have tenure. :-) From: Adam Williamson awill...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, June 3, 2013 7:04 PM Subject: Re: Call for Bikeshedding: remote auth at install time On Mon, 2013-06-03 at 19:02 -0700, Adam Williamson wrote: But yes, in F19 Beta it was broken in g-i-s too, but soon it should not be. But we have a fully-supported paths... excuse me just one second, I hear the doorbell... ... oh, dear. It seems to be my high school English teacher, holding a sturdy length of 2x4 with a rusty nail in it.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Mon, Jun 03, 2013 at 06:07:59PM -0700, Adam Williamson wrote: Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. So my personal experience with Fedora (going back to Fedora 12) in an environment with nwtwork auth is that it never worked at install time. I always eneded up createing a local account and then configuring the network auth from there. Sure I tried it when I could but when it didn't work well I just ignored it and moved on. If I'd thought it was more of an issue I would have filed bugs but it was always an it'd be nice not a must have. I don't even recall seeing an option for F18, and haven't tried the F19 betas myself. Oh and black and blue stripes is the ONLY option for any bikesehd. Yours Tony pgpBczzkn0N7G.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
