Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On 13 Dec 2019, at 15:03, John M. Harris Jr wrote: On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote: What? There are only two images that are release blocking for optical media right now. Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- _RELEASE_MILESTONE_.i so Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- _RELEASE_MILESTONE_.i so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking I'm suggesting one instead of zero. Whatever image you're saying you must have is already non-blocking so I don't even understand what you're complaining about now. This isn't something that *I* personally need. The only ISO image I personally need is the KDE Spin ISO, so you'd be correct. For end-users, there's no need for the complexity of the Everything image to be present, however. If the end user wants to install the GNOME Spin, they shouldn't have to jump through hoops and know what they're picking. I would say that the Everything netinstall image is more useful than the Workstation Live image: * netinstall is smaller * netinstall can be used to install servers * netinstall with updates repo enabled yields current system without doing the almost inevitable post-install (from non-netinstall image) update -- Mike ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On 8 Dec 2016, at 11:22, Dennis Gilmore wrote: On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote: I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2. There is the pxe iso to use boot.fedoraproject.org that would probably better suit your purposes. How does that work on a remote box with no physical access, no DHCP and no console access? Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"? The server netinst iso uses the server defaults, partitioning and filesystem selection. there is no way to do both with a single disk today. it would require who knows what work, I imagine the work is possible its just not an option today. Aren't the server defaults just a matter of package selection? -- Mike ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On 6 Dec 2016, at 09:43, Kamil Paral wrote: Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them: * Workstation Live + netinst * KDE Live * Server DVD + netinst * Everything netinst What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that. On 6 Dec 2016, at 12:20, Adam Williamson wrote: So an alternative to kparal's scheme would be to try and consider this, and say we test: * Workstation live * Everything netinst * Server DVD and consider those to be representative of the broad 'types' of ISOs in terms of the compose process. That way we don't have to test Workstation or Server netinsts, or the KDE live, on optical media. On 7 Dec 2016, at 09:13, Matthew Miller wrote: I think: Workstation x86_64 Live, and at least one netinstall image of any flavor (from which, in a pinch, anything else can be installed via kickstart). I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2. I would be fine with dropping the Server DVD. Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"? -- Mike ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 15 Nov 2016, at 11:37, Bastien Nocera wrote: As mentioned in the fedora-desktop thread about branding, I don't like seeing this sort of randomly generated and nonsensical (and I mean that in that a string of hex characters obviously don't *mean* something) shouldn't be user-visible. Right now, you'd see the hostname on the machine itself in the Sharing and Details panels in GNOME, in bash's prompt, and in quite a few remotely accessible services (the Bluetooth name, shared media, ssh, etc.). There's nothing stopping us from having a hidden/secondary hostname though, and a randomly generated one would fit perfectly for this sort of use case. Now that would be confusing for users -- a hidden name that bears no relation to the exposed name. -- Mike ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnssec-trigger + GNOME + NetworkManager integration
On 10 Jul 2015, at 15:40, Björn Persson wrote: Michael Catanzaro wrote: On Fri, 2015-07-03 at 11:21 -0400, Mike Pinkerton wrote: Isn't the whole point to eliminate the need for third party certificate authorities entirely? Well I think you could choose to do that, or you could choose to use it as an additional security measure on top of traditional certificate authorities. Just to clarify what you are saying -- if there is a third party certificate chain which fails, then you would distrust the site. But if there is no third party certificate authority chain, and DANE succeeds, then you would accept the DANE-provided certificate and trust the site. I was thinking to require both to work, instead of just one or the other. Seems like that would make life hardest for the attacker. [snip] DANE adds a second dimension and we get a matrix of nine possible cases: C0D0: not signed by a CA; has no TLSA records C0D-: not signed by a CA; has TLSA records but verification fails C0D+: not signed by a CA; has TLSA records and verification succeeds C-D0: presents a CA signature but verification fails; has no TLSA records C-D-: presents a CA signature but verification fails; has TLSA records but verification fails C-D+: presents a CA signature but verification fails; has TLSA records and verification succeeds C+D0: signed by a CA and verification succeeds; has no TLSA records C+D-: signed by a CA and verification succeeds; has TLSA records but verification fails C+D+: signed by a CA and verification succeeds; has TLSA records and verification succeeds When you write require both to work it sounds like you would accept only case C+D+. That would mean that you would start rejecting C+D0, denying your users access to all current HTTPS sites that don't use DANE yet, so that's probably not what you mean. All of the C- and D- cases are of course highly suspect and should be rejected, but both C0D+ and C+D0 should be accepted in my opinion. C0D+ is the case that removes people's excuses for not using HTTPS, and seems to be what certificate usage 3 in RFC 6698 is intended for. CAs would still serve a purpose. They could continue to provide big websites with extended validation certificates that allow browsers to assure the user that the website belongs to a particular company or other entity, whereas DANE only ties the public key to the domain name. Maybe some time in the distant future, when DNSsec is nearly ubiquitous, browsers can start rejecting case C+D0 to give the last few stragglers the push they need to start using DANE. I generally agree, except that I see the CAs eventually becoming a legacy artifact, with DANE enabling domains to take control of their own security directly without the mediation of third parties. So I see C+D+ as a transitional step between our current largely C+D0 state and a future C0D+ state. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 3 Jul 2015, at 10:44, Michael Catanzaro wrote: On Fri, 2015-07-03 at 15:43 +0200, Petr Spacek wrote: For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. I was planning to use DANE as a second required check in addition to the normal certificate chain. That is, if either the certificate chain doesn't check out or DANE fails, then something is spooky and the site should be inaccessible. Other browsers are throwing around ideas about using DANE to make the site accessible in the event the certificate chain fails, which seems like the wrong direction to me. I haven't really seen any good arguments in favor of one approach or the other, though. Isn't the whole point to eliminate the need for third party certificate authorities entirely? Just to clarify what you are saying -- if there is a third party certificate chain which fails, then you would distrust the site. But if there is no third party certificate authority chain, and DANE succeeds, then you would accept the DANE-provided certificate and trust the site. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 Self Contained Change: Disabled Repositories Support
On 18 Mar 2015, at 08:40, Miroslav Suchý wrote: On 03/16/2015 06:48 PM, Mike Pinkerton wrote: If the working group deems the software to be that useful, wouldn't it be better to bring its packaging up to the quality of the official Fedora repo, and make it more easily discoverable by all Fedora users, regardless of whether they choose to use that product or a spin or a non-product install of Fedora? Another example - I have two projects in Copr: * spark-cli - command line interface for Spark Core * nanoblogger - blog with just static pages generated by bash sript I have no intention to get them into main Fedora. Mostly because I am not willing to fix bugs. I just packaged it for myself. It works for me and it may work most people. Therefore I assume that it may be useful for somebody out there. We (as Fedora) simply could not package and maintain everything with the same quality. I understand the usefulness of copr for software in development, experimental builds, personal projects, work in progress, etc. I even understand making software there discoverable via a web-based search page -- which you already have. What I don't understand is the wisdom of an official Fedora product endorsing a copr when either the software or packaging (or both) is not of sufficient quality to make it into the official Fedora repo. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 Self Contained Change: Disabled Repositories Support
On 16 Mar 2015, at 12:57, Josh Boyer wrote: a) This change impacts users, while these COPRs are not useful to them. There are no COPR repo files that are installed by default today, which means none of them use this mechanism yet. Which means there is literally no change for any user at this time. As I said, the Change is informational. If such repo files are installed by default, it will be at the discretion of the various Working Groups not the Change proposer. Why would an official product want to endorse unofficial repos? If the working group deems the software to be that useful, wouldn't it be better to bring its packaging up to the quality of the official Fedora repo, and make it more easily discoverable by all Fedora users, regardless of whether they choose to use that product or a spin or a non-product install of Fedora? Just asking what the thinking is here ... -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 10 Mar 2015, at 07:00, Matěj Cepl wrote: On 2015-03-10, 10:15 GMT, Björn Persson wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I think certainly there should be some protection against passwords like monkey (why monkey and not kangaroo, for example?) or iloveyou (as the Pope Francis said our message should be based on love not hate!), but when it tries to do too much more it is getting in the way even to the people who actually know what they are talking about. VM machine used only for temporary compilation on the old platform just doesn't have to have 63-random-chars password from https://www.grc.com/passwords.htm At the risk of complicating someone's life: Given that pattern-based attacks make meaningful password quality checking nigh impossible, why not just drop password quality checks. Instead, give a simple explanation that a secure password should: * be at least xx random characters in length, utilize both lower and upper case letters, as well as numerals and special characters, and not contain any human recognizable pattern -- and that any pattern that one can easily remember is probably insecure; or * be generated by a suitably random password generator, such as a 7 word Diceware password. Then embed a random password generator, such as /usr/bin/apg, and give the user a choice of generating a random password of whatever length the user wants, or simply entering whatever insecure password the user deems appropriate given the anticipated use of the installed OS. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 7 Mar 2015, at 20:35, Stephen John Smoogen wrote: On 7 March 2015 at 15:33, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 15:52, Stephen John Smoogen wrote: On 7 March 2015 at 11:53, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass-phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. They limit it to 1-2 words because it takes a LONG time to crack SHA512crypt passwords. You can do on average 32k - 128k hash crypt checks per second per password. A two word dictionary of diceware would have 2^25.85 passwords in it. A single system is going to take 256 seconds on 2 words. Add in 3 words (2^38.775) and it is 24 days. Add in a 4th word and it is 544 years. Add in a 5th word and it is 4.5 million years. Apparently Diceware's creator is not as confident as you -- he nows recommends more than 5 words. http://arstechnica.com/information-technology/2014/03/diceware- passwords-now-need-six-random-words-to-thwart-hackers/ Perhaps improvements in graphics cards have changed the calculus in recent years. Yes and no. 1) He has always wanted to make sure that an attack was going to take billions of years for the US government on. Thus his level of threat is the 100 billion dollar cluster... Which yes 6 or 7 words would be needed if not 8. Your password of completely random characters will also need to be a lot longer. 2) He is also aware that most of the hacks out there have not been SHA512crypt but MD5sum/SHAsum/NT password breaches. If you are lucky they used md5crypt or the original sha1crypt. Those are formats that yes millions of attacks per second can be done in an offline attempt. If you have no control over how the password is stored then using 4 or 5 words is not enough. 3) Yes graphic cards improve with more cores but they do not increase word size as often because there really isn't much need other than cracking large passwords (bitcoin which is the primary use for video cards doesn't get faster with a larger word so it isn't something people will pay for.) Without a larger word size the various code for doing a SHA512crypt gets slow. Neither of the first two items are things which are going to be general users of Linux are needing to deal with. If you are having to worry about that sort of attack then you are going to need a lot more work than a 100+ bit entropy password. While writing this up I went and checked that the whole thing is outlined point for point in wikipedia http://en.wikipedia.org/wiki/Password_strength To estimate the time just do the following: $15,000 computer - 128k/sec = 2^17. Lets assume moore's law comes in and we have 2^20 by 2020. Take the possible entropy and subtract the 2^17 and that will give you the worst case. I believe it may be 1/4 of that so make it subtract 2^19 currently for one system and 2^29 for a cluster of 1024 computers (so 15 million dollars). 2 words is going to be (25.85-19) 115 seconds for one system and 0.1 for big ass cluster. 3 words is going to be (38.78-19) 236 hours ). 1 day for big ass cluster 4 words is going to be (51.70-19) 221 years). 1 year 5 words is going to be (64.63-19) 1.7 million years) 1700 years. (or 1.7 years for a 15 billion dollar investment). To get equivalent strength from say an all lower case password you are going to need 14 [a-z] characters. Now here is the funny thing. All that speed to get 128k is if the password is less than around 12 characters for most cracking software due to the way the hardware and algorithms have been optimized. If the string is longer
Re: FESCO request to revert password confirmation change in F22
On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass- phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. The catch is that the words must be *randomly* chosen. XKCD doesn't stress that point much, and humans are notoriously bad at choosing randomly. I suspect that many people make up some highly nonrandom four-word passphrase and think they have a correct horse battery staple-quality passphrase. I don't think randomness matters at all, only whether the words are in the word list(s) used by the attacker. In the Ars Technica article, one attacker was using multiple lists, one of which included 111 million words. Another attacker limited himself to a list of 14 million words -- which were real-world passwords that were exposed in an SQL-injection hack several years ago. Note that these words are simply strings -- some might be recognizable as words in a spoken or written language, while others are just character strings (e.g., momof3g or 8kids) that the attacker has culled from one source or another. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Test-Announce] 2015-03-09 @ ** 15:00 ** UTC - Fedora QA Meeting
On 7 Mar 2015, at 02:16, Adam Williamson wrote: for 15:00 UTC. If your clocks go back this weekend, the meeting should be at the same local time as it was before. If your clocks don't go back, it will be one hour earlier. Spring forward, Fall back. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 7 Mar 2015, at 15:52, Stephen John Smoogen wrote: On 7 March 2015 at 11:53, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass-phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. They limit it to 1-2 words because it takes a LONG time to crack SHA512crypt passwords. You can do on average 32k - 128k hash crypt checks per second per password. A two word dictionary of diceware would have 2^25.85 passwords in it. A single system is going to take 256 seconds on 2 words. Add in 3 words (2^38.775) and it is 24 days. Add in a 4th word and it is 544 years. Add in a 5th word and it is 4.5 million years. Apparently Diceware's creator is not as confident as you -- he nows recommends more than 5 words. http://arstechnica.com/information-technology/2014/03/diceware- passwords-now-need-six-random-words-to-thwart-hackers/ Perhaps improvements in graphics cards have changed the calculus in recent years. While writing this up I went and checked that the whole thing is outlined point for point in wikipedia http://en.wikipedia.org/wiki/Password_strength To estimate the time just do the following: $15,000 computer - 128k/sec = 2^17. Lets assume moore's law comes in and we have 2^20 by 2020. Take the possible entropy and subtract the 2^17 and that will give you the worst case. I believe it may be 1/4 of that so make it subtract 2^19 currently for one system and 2^29 for a cluster of 1024 computers (so 15 million dollars). 2 words is going to be (25.85-19) 115 seconds for one system and 0.1 for big ass cluster. 3 words is going to be (38.78-19) 236 hours ). 1 day for big ass cluster 4 words is going to be (51.70-19) 221 years). 1 year 5 words is going to be (64.63-19) 1.7 million years) 1700 years. (or 1.7 years for a 15 billion dollar investment). To get equivalent strength from say an all lower case password you are going to need 14 [a-z] characters. Now here is the funny thing. All that speed to get 128k is if the password is less than around 12 characters for most cracking software due to the way the hardware and algorithms have been optimized. If the string is longer than that the hardware drops in speed by orders of magnitude. So correctstaple is actually going to take longer than I said. In fact all the numbers I put for 3+ words is probably going to be 10-100 times longer. All of this assumes that the attacker is trying to brute force the entire string -- character by character. In the Ars Technica article I linked to in my previous message, the attackers did not try to brute force anything over 6 characters. Instead, they used other strategies, including the combinator strategy that would have broken correcthorse. There are 2 caveats. 1) Once again, Adam was being sarcastic. He knows the password isn't any good because well he TOLD everyone what it was. He was making fun of the fact that libpwquality does not blacklist it.. which means that correctstaple is the new password of choice (when the old one might have been 123456) I saw your first note that Adam was being sarcastic -- although it probably doesn't matter what password he is using for offline testing of Anaconda and release candidates. I was responding to Björn Persson's suggestion that, in discussions of password quality, correcthorsebatterystaple would be an example of a safe password. My point is that, if attackers are using strategies other than brute forcing, which the Ars Technica article suggests is the case, then constructing long passwords out of known words is probably not a safe strategy
Re: FESCO request to revert password confirmation change in F22
On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 14 Jan 2015, at 12:34, Miloslav Trmač wrote: I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Being able to authenticate as root right after installation would be the requirement for me. Let’s be precise here; “able to authenticate as root” is an implementation detail; the underlying requirement is something else. “Able to set up IPA”? “Able to run administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a root shell without any authentication It seems that the boxes affected by this proposal are either product=server or product=nonproduct. For servers, immediately after installing, I log in as root and run a set-up or configuration script which, among other things, sets the box to a non-graphical target and prevents firstboot from ever running. I'm not sure why one would run firstboot on a server. I also do something similar and prevent firstboot from running on boxes set up as general desktops for office workers, etc., as I don't want the first random user who logs into a box to be able to become part of the wheel group and have access to sudo. As far as I can see, firstboot is only useful on one's personal box. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 12 Jan 2015, at 03:56, P J P wrote: Hello, On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote: Earlier in the discussions I was told that this is not really an issue: in production, about every server with remote access also has a KVM. Often not the case in small business or third party hosted environments. Without remote ssh, box is unmanageable. Even if you want to do key-based authentication rather than password, you still need to use password initially to get the key onto the remote box. If you use cloud-init you can specify an initial public key that it inserts against, or even auto enrol it in a central auth system like IPA and hence not ever need a password. So, the major issue(or blocker should we say?) is the virtualized deployments. If there is no solution in sight, maybe last resort is to enable remote root login, possibly in the '%post' install section of the kick-start file. Not just virtualized deployments, but also in remote installs on bare metal. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 12 Jan 2015, at 12:02, P J P wrote: On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote: Not just virtualized deployments, but also in remote installs on bare metal. Okay and the '%post' install section trick won't help there? IIUC, it'd depend on which tool/application is used to do such remote installations and if they provide means to customise/tweak the final install. Sure, if the tool provides the ability to tweak the install to enable password-based root login, then one can log in after installation, upload keys, configure sshd, etc. The question is whether the tool that is available has that ability. Over the years, I have attempted many of the remote installation methods described in the Fedora Installation Guide. Not all of them work when you don't control the remote network. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 8 Jan 2015, at 13:52, Miloslav Trmač wrote: The only other approach I could see for the headless servers would be mandating the enrollment in an identity domain at installation time (such as to FreeIPA or Active Directory). And in this scenario we should absolutely disable PermitRootLogin. So that if you have issues with the connector, you have to reboot the machine and be physically present to fix anything. Not really a grand plan IMO. Earlier in the discussions I was told that this is not really an issue: in production, about every server with remote access also has a KVM. Often not the case in small business or third party hosted environments. Without remote ssh, box is unmanageable. Even if you want to do key-based authentication rather than password, you still need to use password initially to get the key onto the remote box. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
On 24 Dec 2014, at 09:29, P J P wrote: On Wednesday, 24 December 2014 3:07 PM, Andrew Haley wrote: At some loss of usability. To often we hear This is better for security, therefore we should do it without considering the usability trade-off. It'll help if you could define this some loss of usability. If it is about remotely installed VM images, it's also discussed here - https://lists.fedoraproject.org/pipermail/security/2014- December/002061.html Remotely installed on bare metal. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Other download options
On 10 Dec 2014, at 11:52, Jerry James wrote: On Wed, Dec 10, 2014 at 6:27 AM, Maros Zatko mza...@redhat.com wrote: Yes, there is netinstall in the Server variant, I suppose it's not the same as Workstation one and (as a user) I'm getting pretty confused now :) I'm getting kind of confused myself. I want to grab an image to throw onto an old machine for my kids to use. I just want a desktop with a web browser and a mail client. Workstation isn't suitable; they aren't developers (yet). Server and Cloud are definitely right out. I don't want a Live CD; I want to actually install. (In the past, installing from a Live CD left one with different defaults than an install from DVD, so I've learned to avoid the Live CD. Perhaps that reflex is now wrong.) I guess I could go with one of the spins, but I don't see a GNOME spin anywhere. Is there really no DVD image for a generic GNOME desktop install? Maybe I should make Kevin happy and get the KDE spin. :-) Actually, the KDE, Xfce, LXDE, and Mate spins all seem likely to fit my use case, but I'm very surprised that there isn't a GNOME equivalent. Or is there? If there is, I can't tell from the information on getfedora.org. What are we recommending for people who want to install a generic access the Internet type of environment for non-techies? None of the products obviously address that audience. This issue has been addressed tangentially in the marathon Workstation defaults to wide-open firewall thread. As best I can tell from Matthew Miller's responses there, Fedora has abandoned that portion of its previous user base that was using Fedora as a general, secure by default, Gnome desktop OS. Those users are no longer supported by any Fedora product. I also am trying to figure out how I can use Fedora going forward to support general desktop requirements for SMB office workers, creative types and others who have heretofore been using Fedora as a general, secure by default, Gnome desktop OS. The only ideas I have come up with so far are: • Install Fedora 20, update it, then fedup to nonproduct variant of Fedora 21; or • Use the server net install to install a minimal system as a nonproduct variant of Fedora 21, and then install a long list of packages needed to convert it into a general desktop OS. I have not yet tested and don't know how practical either of those ideas is. My users are accustomed to Gnome, so I prefer not to change to one of the alternative desktop environment spins if there is an easy way forward with Gnome. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Other download options
On 10 Dec 2014, at 12:52, Ben Cotton wrote: On Wed, Dec 10, 2014 at 12:47 PM, Mike Pinkerton pseli...@mindspring.com wrote: I also am trying to figure out how I can use Fedora going forward to support general desktop requirements for SMB office workers, creative types and others who have heretofore been using Fedora as a general, secure by default, Gnome desktop OS. The only ideas I have come up with so far are: Why not the Workstation product with a firewall configuration more to your liking? Is there something besides the firewall that causes Fedora 21 Workstation to not meet your needs? Primarily the uncertainty of what changes the Workstation WG has made, coupled with Matthew Miller's comments that: Right now, 'desktop system with a security focus for new users' isn't a key part of that effort. ... So, if you're not in the target of that focus, where do you look? Well, you can certainly pick one of our other desktop spins ... None of those spins is Gnome-based. For office workers, creative types and similar, there is always a mixture of new and old users, a mixture of savvy and not, and always a few folks who, unless prevented, would do incredibly stupid things that put your whole network at risk. Security is always a prime concern. I would not have known about the firewall issue if Kevin Kofler had not kindly flagged it to this list. If the Workstation WG is willing to implement such a basic change with little notice -- and the two sentences in the Release Notes don't give adequate notice that Fedora has switched from a secure by default to an insecure by default firewall configuration -- then I can't trust the Workstation product until I can audit all of its configurations to determine where and how they differ from those I can support for my users. I don't have the time to do that. I also don't know whether Workstation updates will pull in other similarly bad ideas in the future, and whether I would have to re- audit all of the configuration after each update. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 8 Dec 2014, at 10:33, Matthew Miller wrote: On Mon, Dec 08, 2014 at 02:31:58PM +, Ian Malone wrote: There are three products: workstation, server, cloud. Workstation is the one for desktop use. That leaves server to aim for the traditional fedora user base, since cloud is (understandably) a very different thing. So if you want a desktop system with a security focus where do you look now? So, it's important to understand — here on the devel list, certainly — that these three are part of a marketing strategy, and in order for such a thing to be effective and not just fluffy talk, it does involve technical changes to match the plan. Right now, desktop system with a security focus for new users isn't a key part of that effort. I certainly don't dispute that user security and education are good goals, and I don't think anyone on the workstation team does either — it's just a matter of the steps we take to get there. It is fine and well to target a new group of users -- developers who want developer features. Remember, though, that Fedora has been used, and continues to be used, as a general desktop OS by many folks and in many organizations. Indeed, Fedora's old market positioning was primarily as a desktop OS suitable for a range of users. Do not make the oft-repeated and often fatal mistake of burning your old market when trying to grow a new one. From a marketing standpoint, that is just crazy. In a for-profit company, where products are connected to revenue streams, it would be a you just bet your career move which nine times out of ten you would lose. Opening up the firewall by default, and omitting the user interface to change it, all to satisfy the assumed needs of the user base you wish to add -- a user base that is tech savvy enough to customize the firewall rules they want -- seems misguided and is certainly hostile to your old market which had a very different expectation of the firewall defaults. So, if you're not in the target of that focus, where do you look? Well, you can certainly pick one of our other desktop spins, which have different firewall defaults. In recent years Fedora has been known primarily as a secure by default Gnome desktop OS. To suggest that anyone interested in a secure by default Gnome desktop OS should have to resort to a not-yet- existent spin is to admit that you are abandoning your current market in search of greener fields elsewhere. Or, you can do what I do: start with Fedora Workstation and then configure it in a way that makes sense for my needs, or if you're deploying for users into a managed environment, use the tools the OS provides to preconfigure the system for whatever makes sense there. My take-away is that Fedora next isn't yet ready for wide deployment by me. The Workstation group has made a significant, and unexpected by many of us, change in firewall defaults. It is probably not their only decision that will surprise us. Some of the decisions made by the server and cloud teams may also be surprising. Until all of the defaults, and the embedded thinking they represent, are better known, the only product I intend to support is product=nonproduct built on a minimal install. Understand that I am not hostile to Fedora next. As one who has run Fedora on servers since FC2, I do applaud the additional thought and consideration being given to servers and clouds. They are truly different use cases. It is good that the needs of server and cloud admins are being more fully addressed. As one who has also supported Fedora on general desktops for a number of years, I think you are making a mistake in not tending the user base you already have on the desktop. Whether you can grow a new developer-centric user base segment is an open question, but you already have a general desktop user base which you can keep and grow on -- at least until those who provide support to that user base lose confidence in Fedora as a suitable OS for those users out-of-the-box. Perhaps the Workstation team thought that opening up the firewall defaults was the best compromise. I disagree. Perhaps a better compromise would have been to leave the old defaults in place, and add a new pre-configured more open zone for those who want fewer constraints. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 8 Dec 2014, at 17:07, Matthew Miller wrote: On Mon, Dec 08, 2014 at 03:20:30PM -0500, Mike Pinkerton wrote: burning your old market when trying to grow a new one. From a marketing standpoint, that is just crazy. In a for-profit company, where products are connected to revenue streams, it would be a you just bet your career move which nine times out of ten you would lose. The classic Innovators Dilemma actually posits that the reverse situation is _worse_. (For the record, I don't think we're at that crisis point — but we could be, because the computing world is changing.) The classic Innovator's Dilemma juxtaposes known current requirements of your market vs. unknown future requirements. I'm talking about customers you already have vs. customers that you might like to have, but don't yet have and might possibly never have. Ditching existing customers in order to court potential customers is rarely a winning strategy, and really isn't necessary. But also, we get into the even _more_ classic parable of the blind people and the elephant — and the recent thread about metrics. You have a strong idea of what the primary classic Fedora userbase is, and I have a slightly different one, and I think if we ask the room, we'll get a dozen different answers. We do need better real knowledge of our user base — both current and future. Any efforts into improving that in a meaningful way are very welcome. (And that includes this conversation; just because I don't necessarily agree doesn't mean I'm not listening.) Sure, knowing the user base is important. Short of that, we do know who Fedora's previous target users were and, assuming even modest success, we can assume that some percentage of the user base matches that range of target users. For those of us who have provided support for Fedora as a general desktop OS, we also have some idea of what our local user base is. In recent years Fedora has been known primarily as a secure by default Gnome desktop OS. To suggest that anyone interested in a secure by default Gnome desktop OS should have to resort to a not-yet-existent spin is to admit that you are abandoning your current market in search of greener fields elsewhere. I don't actually think we're abandoning anyone, here. In my experience, the classic Fedora user is relatively savvy, or else leans on friends who are. They tend to take the various parts of the project they like and shape it — and whether something is on or off by default isn't a huge concern. (I have a whole checklist of items that I like a certain way on my system that I'm definitely not going to try to make the default, and that's fine.) Yep, enthusiasts were one part of Fedora's previous target user base, but they weren't all of it. They certainly aren't part of the user base for which I have to provide support, which is mostly SMB office users with a smattering of other types. We could have decided to double-down on growing that enthusiast segment, but, first, that's not what the people who showed up to do the work decided; and second, I actually think we continue to serve the hackers and tinkerers very nicely with the spins and nonproduct option. What we're not doing is expanding I'm not suggesting that Fedora not expand into a new market segment. I'm simply suggesting that you not abandon existing users in order to do so. I also think you're also kind of setting up an argument against something no-one is for. Secure by default is a not a well-defined term, I can't quite parse that, but I think you are intentionally misunderstanding what I wrote. Secure by default might not be a detailed specification, but it is certainly understood as a general user expectation, one that I think Fedora has heretofore generally met. I *will* talk to the designers about plans for presenting the zone information in a different way. I personally am conscientious about setting my coffeeshop wifi to public — but I know why and where to dig for it. Making that more discoverable and usable would be a meaningful improvement. Perhaps the Workstation team thought that opening up the firewall defaults was the best compromise. I disagree. Perhaps a better compromise would have been to leave the old defaults in place, and add a new pre-configured more open zone for those who want fewer constraints. Wait, my last paragraph was a great end to a long message :) but I need to also add: please take a look at the actual implementation. The above suggestion is _exactly_ what was done. But which zone is the out-of-the-box default? -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to handle upgrades to Fedora 21
On 3 Oct 2014, at 19:37, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant The nonstandard and noncompliant names seem a bit pejorative. However, fedora-release-custom and fedora-release-diy (do-it- yourself) and fedora-release-pyop (pick-your-own-packageset) and fedora-release-byob (bring-your-own-blueprint) all have similar meanings to this US-English speaker, and all seem like reasonable choices, although the last three might require a parenthetical explanation for some folk. Yes, Myrtle Green would make a nice color for the bike shed. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
On 25 Jul 2014, at 07:52, Phil Knirsch wrote: Summary: Mattdm then followed with 2 1/2 additional topics: 1a. Identifying different Fedora products -- fedora-release-* contents and /etc/os-release As I understand it, you are trying to decide where and how to set a flag that will signal the product that is either installed or to be installed. There was mention of dropping product specific snippets in /usr/lib/os-release.d/ as one solution. Does it have to be any more complex than the approach used by systemd? If fedora-release were to drop all product specific snippets in /usr/lib/os-release.d/, then a system admin could use a symbolic link in /etc/os-release.d to flag which product (or no product) he wanted installed. Similar to: /etc/systemd/system/default.target - /lib/systemd/system/ graphical.target a system admin could set a symbolic link: /etc/os-release.d/product - /usr/lib/os-release.d/workstation.product Then, if a system admin wanted to change the box to a server, or to a non-productized box, he could simply change the symbolic link to: /etc/os-release.d/product - /usr/lib/os-release.d/server.product or /etc/os-release.d/product - /usr/lib/os-release.d/generic.product and then run whatever product syncing tool you develop -- perhaps: dnf product-sync 2. a generic fedora netinstall I appreciate your continued consideration of this item. I'm not clear on how Anaconda is supposed to work with different products, but if it is reading whatever product flag you set in order to determine the package list, couldn't a single netinstall CD work for all products, as well as a generic, non-productized install, assuming that there were a place in the UI to specify which product the user wanted installed? -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 10 Jul 2014, at 07:04, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2014 05:08 PM, Matthew Miller wrote: On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote: I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work. A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed? * dredges up meeting logs -- http://meetbot.fedoraproject.org/teams/server-wg/server-wg. 2014-02-25-16.00.html That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. A minimal netinstall would be ok if there is a simple way to replace the productized fedora-release package with a plain, non- productized fedora-release package. In saying that, I am making an assumption that, once the fedora- release package is switched out, then any product requirements or constraints would disappear and the system would be a traditional, non-productized Fedora system that could then be configured however the system administrator chose. Is that assumption wrong? Thanks. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 7 Jul 2014, at 11:17, Josh Boyer wrote: On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2014 03:43 AM, William wrote: On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote: That's misleading. Fedora hasn't been releasing do-it-yourself releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of = F20. Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong. josh It's also misleading given how much focus has been given to the three new products that will be released: So why now is there a non-productised version? That's not been advertised much. I honestly don't know how much more we could have advertised that. We've been talking about it since the beginning. Particularly about how the Fedora Products are additive to the classic Fedora and that spins aren't going away (they're non-productized versions too). You're talking about additive in the they all use the same repos sense, but there is no planned install media that will be produced similar to the F20 release. There are the 3 products, and there are the spins. The product closest to the existing Fedora default is Workstation, and we're targeting a live media as the primary deliverable. There have been 0 plans or discussions around fedup/upgrades from F20 so far. While I appreciate that the Fedora project has goals that it wants to achieve with the three new products, I had assumed based on the explanations that I have read that: 1. There will not be any change in the repo structure -- no separate repos for separate products. 2. For those of us who are not interested in the new products or do not find their minimum package assurances to be important in our use cases, there will still be a traditional non-productized Fedora. 3. There will still be plain non-productized versions of /etc/os- release (or wherever the systemd guys are relocating it) and /etc/ fedora-release. 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. 5. A fedup upgrade will be possible from a traditional non- productized Fedora 20 system to a traditional non-productized Fedora 21 system and, in due time, from traditional non-productized Fedora 21 to 22, etc. Am I mistaken on any or all of this? -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Software Management call for RFEs
On 23 May 2013, at 01:27, Björn Persson wrote: Adam Williamson wrote: On Thu, 2013-05-23 at 02:20 +0300, Oron Peled wrote: Thinking about it, the terminology adopted by comps is clearer and provides a generalization of this -- if someone select something they get: - Mandatory packages (cannot be deselected) - Default packages (selected, but the user may deselect) - Optional packages (deselected, but the user may select) Borrowing similar logic for rpm we could have in the spec file: Name: acme Requires: foo, foo-utils InstallDefault: bar, perl-bar, python-bar InstallOptional: baz, baz-ldap Now it would be classic to use --with/--without as command line flags, but it's already taken :-( I'm pretty sure that's precisely the distinction expressed by Suggests and Recommends, FWIW. For interactive operations that's how I envision it, yes. When yum lists the packages it's going to install and asks for confirmation, it would list recommended packages and their requirements under Installing because of recommendations, and suggested packages under Suggested packages not being installed. The user can then choose to abort the operation and run the command again, adding some suggested packages to the command line or using --exclude on some of the recommended ones. Because this is an interactive operation, rather than aborting, why not change (y/N) to (y/N/m). If the user chooses m for modify, then yum could ask whether the user wanted to delete a recommended package and, if response is y, show the recommended packages one line at a time for a y or n response. Then yum could ask whether the user wanted to add a suggested package and, if response is y, show the suggested packages one line at a time for a y or n response. Dealing with the modifications interactively would be less annoying than aborting and typing a new yum command full of -- excludes or additional package names. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 5 May 2013, at 20:31, Chris Adams wrote: Once upon a time, Lars Seipel lars.sei...@gmail.com said: - the checksums for netinstall images are signed with a Fedora key - the corresponding public key is made available through https - therefore the integrity of installer images can be verified That's only verifiable after the fact (when you want to use the installer) if you burn to CD/DVD (which I believe is less common these days). If you put it on a USB stick with something like livecd-iso-to-disk it gets changed. That also doesn't protect against malicious updates.img from the install server. In any case, I was talking about validation _during_ install, not prior to install. How many people compare the ISO checksum and the signature on the checksum file? AFAIK there is not automated tool to do that, so it is a bunch of manual steps. Sure, the steps are manual: download iso, download checksum file, verify signature on checksum file, verify checksum on iso. Once I've done that, though, I have a reasonable expectation that the iso -- and anaconda, the keys and rpms on it -- are good. And I only have to do those steps once per release image, not every time I install a system. I know that the images that I stored on my local repo server are ones that I have previously checked. Whether I then put that image on an USB stick, or mount it on a local network server, or stick it in a DVD drive, I trust that image and its contents as much as I trust anything coming from the Fedora project. For me, though, the real head scratcher is this: the keys on that iso are the ones that yum will use to verify signatures on updates -- why are they trustworthy enough for that, but not for verifying signatures on rpms downloaded via netinstall or additional repos configured in the DVD's installation source spoke? Makes no sense to me. To bring this back around to the topic of this thread, this is the reason that I've continued to use the DVD for installations, and then do a yum upgrade afterwards. It is the only way that I know to ensure that all installed rpms are actually verified. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 4 May 2013, at 02:03, Chris Adams wrote: Creating a complete chain of trust is hard. Sure, creating a complete chain of trust is hard, but the closest thing we have to it today is downloading an iso and verifying its checksum -- and trusting that (a) the release team verified the keys on the iso image, and (b) the checksum file hasn't been been tampered with. The keys on that iso are the ones that yum will use to check package signatures on updates. Why they are not used to check the signatures on packages anaconda installs is beyond me. It might be imperfect security, but it seems much more reasonable than abandoning signature checking altogether on a netinstall. The repo works fine for yum after installation. Is it a mirror of the Fedora or Everything directory? I haven't checked in a bit, but at one point there was some difference between the two related to the comps file (which defines the groups displayed in anaconda). yum would work fine without the comps file (except for groupinstall and such). We have internal mirrors of Fedora, Everything and Updates. I tried to use Fedora but will experiment with both it and Everything today. Have you tried doing a netinstall from a specific mirror that you specified in the source spoke of anaconda rather than using the pre- configured repo? Did it work? Yes. I operate a mirror server, and then I also have a couple of private mirrors hanging off of it I use for my stuff (one at the office and one at home). The problem I'm going to have in testing the F19 TC is that, for bandwidth reasons, our internal repo only mirrors the current version and arch that we use -- F18 on x86_64 at the moment. So I'll just have to pick a handful of external mirrors and try them. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 3 May 2013, at 09:45, Jóhann B. Guðmundsson wrote: Why bother with the DVD et all and enter countless debates what should and should not be on it. Why not just make the assumption that administrators will use the netinstall and or ks and desktop users will use live spins? When you download the DVD iso you can verify its checksum. Does anaconda check package signatures for the netinstall? Does netinstall even work well? For F18 I planned to do netinstalls on a dozen or so desktop workstations and a couple of new servers, using our internal trusted Fedora repo. After specifying our internal repo as the source, netinstall would not allow me to choose the software to install -- all I got was the yellow triangle on the summary page, and blank pages where I should have been able to choose Gnome desktop, network server, etc. If I selected the software first, then chose our internal Fedora repo as the source, netinstall would delete the software choice, leaving me in the same predicament -- I could choose either the software to install or the repo from which to install it, but not both. Of course, anaconda won't start the installation until both are satisfied. So, in the end, I had to do all the installations with a DVD, then do updates from our internal Fedora repo. I've been meaning to file a bug about this, but haven't found the time yet. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 3 May 2013, at 15:07, Chris Adams wrote: Once upon a time, Mike Pinkerton pseli...@mindspring.com said: Does anaconda check package signatures for the netinstall? I believe so. Checksums are definately checked (RPM won't install a corrupt package). Are you sure that signatures are checked? If so, why this feature? https://fedoraproject.org/wiki/Features/ PackageSignatureCheckingDuringOSInstall Does netinstall even work well? Certainly. I actually haven't installed Fedora (or RHEL/CentOS) any other way in a long time (probably at least 5 years). Just about all of the RHEL/CentOS installs, and some of the Fedora installs, were from kickstart, but most of the Fedora installs were interactive. For F18 I planned to do netinstalls on a dozen or so desktop workstations and a couple of new servers, using our internal trusted Fedora repo. After specifying our internal repo as the source, netinstall would not allow me to choose the software to install -- all I got was the yellow triangle on the summary page, and blank pages where I should have been able to choose Gnome desktop, network server, etc. I would say that sounds like there was something wrong with your repo. The repo works fine for yum after installation. Have you tried doing a netinstall from a specific mirror that you specified in the source spoke of anaconda rather than using the pre- configured repo? Did it work? I am going to take Rahul's earlier suggestion and try the current F19 TC this weekend to see if I get any better result. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 13 Mar 2013, at 10:16, Nicolas Mailhot wrote: Anyway, here is a proposal for an alternative way to deal with the boot sequence. There have been a number of suggestions that have taken a Windows 8 approach to this problem -- auto-detecting error conditions or enabling one to reboot into a boot menu. I can't say that I'm confident of the error detection, or that I'm happy about having to boot once into the wrong system just so I can reboot into a boot menu that will enable me to boot into the right system. That doesn't seem particularly efficient or user- friendly. Let me make a case for an Apple approach. Although the reaction here was somewhat dismissive of the various start-up keys that Apple enables, the Apple approach does have three great advantages: 1. In the most frequent case, there is no interruption of the boot sequence for the default system. 2. If one wants to invoke one of the Apple start-up options, the normal practice is to hold down the appropriate key, then power on the Mac, and continue holding down the key until one hears the start- up chime and sees that the system is booting. There is no short time interval that one has to hit just right. Like big icons on the edge of the screen, holding down a key from power on provides the fattest target for a user to hit -- sort of Fitts law in a temporal dimension. 3. The key combinations are well-known. Decades of using the same key combinations have ingrained them in Mac culture. A new Mac user might not know the right key combination, but any mailing list or forum will have dozens of Mac users who can quickly recite the key combinations for starting from a CD or DVD, clearing the PRAM (a long- time voodoo practice among some Mac users), starting target disk mode, etc. In the case of Fedora: + If a key were selected -- and I don't think you have to enable all of them -- and advertised in all of the user mailing lists, fora, Quick Start documentation, Installation Guide, User Guide, etc., then within a year or so just about every Fedoran would know and could quickly recite to newbies hold down the F (as in Fedora) key to get to advanced boot options. + If a user could hold the key down from before power on until the boot options menu appeared, then Fedora could still do extremely fast booting without presenting the user with a short time interval to hit. If grub finds the keyboard, and detects no F key hold down, it would continue to boot immediately with no further delay. I recall there was some objection about BIOS buffer clearing, and don't know what problems that would present to this proposal. On the plus side, though, there wouldn't be any need for gnarly auto- detection of error conditions. By the way, in this brave new fast boot world, how is one expected to get to the BIOS or firmware set-up programs? -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 13 Mar 2013, at 14:51, Chris Murphy wrote: By the way, in this brave new fast boot world, how is one expected to get to the BIOS or firmware set-up programs? Firmware specific. F1 and F2 are very common. HP and some Toshibas are Esc. My question was more timing than keystroke -- whatever the keystroke, I don't think I can hit it in the 1 second boot scenario. On 13 Mar 2013, at 13:39, Matthew Garrett wrote: By the way, in this brave new fast boot world, how is one expected to get to the BIOS or firmware set-up programs? Use UI that sets an EFI variable and then reboot. If I understand this correctly, I have to log into a working system in order to set a flag in the firmware that will allow me to reboot into the firmware set-up program. I'm not yet sold on having to boot into a working system in order to get back to the firmware or boot menu on a reboot. Beyond the annoyance of having to boot something I don't want in order to get where I want to go, the process seems fragile to me. Perhaps with age comes patience -- or orneriness, I'm not quite sure -- but I'm inclined to think that accepting the addition of 1-2 seconds to boot time in order to have available a power-on key-hold route to a boot menu and firmware set-up program is not a particularly bad trade-off. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 15:28, Michael Scherer wrote: Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit : On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? Then you need to have the network configuration, etc. This can be done, but for now, the feature is not in dracut, see this bug for a similar request for encrypted root : https://bugzilla.redhat.com/show_bug.cgi?id=524727 That bug looks like a superset of what would be needed to run the network and sshd from the initramfs. As for network configuration, in the past (I haven't tried it with F18's new Anaconda), one could do a VNC-enabled install by passing a minimal network configuration (interface and IP address), as well as a VNC password, on the kernel line. Perhaps for a ssh-enabled fedup, one could do something similar, passing an interface and IP address to fedup, possibly as well as a one-time use ssh password and a permitted remote IP address block from which one could connect. How those persist across the reboot -- whether fedup writes those to the kernel line in grub.conf as one would do with a remote VNC install, or they are written into the initramfs -- would be a question. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 12:11, Chris Murphy wrote: After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10 minutes). Meanwhile, a yum upgrade involves a transition from download to upgrade without notification, concomitant with the potential for arbitrary and untimely implosion that could hose the entire upgrade. And this is on a supposedly important computer that can't be down for 2 hours? Umm? I really don't understand this thread. Over the years, I have yum upgraded remote boxes from RHL 7.3 to F16. On a remote yum upgrade, you can follow yum's progress -- see if it hangs, see any failure warnings, etc., fix what you can after it finishes -- then hold your breath when you reboot. If the box isn't back online within 2 minutes, you know you have a major problem and contact the data center immediately. If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off- track. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I think the lack of feedback with fedup is a known weak area that needs improvement. I found that by deleting 'quiet rhgb' and adding one of the debug options to the fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a: journalcti --follow And I get live updates throughout the process. I don't recall hang without some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps are available, I think at least one of them is. I can see how this would help when sitting in front of the box, but when you're hundreds or thousands of miles away, it isn't really an option. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? It would be nice if one could start fedup with a flag that would tell it to start the network and sshd upon reboot, and enable feedback to a remote user. That would make the process a lot less worrisome. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 25 Jan 2013, at 14:23, Simo Sorce wrote: Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... A) One single reboot you do after not upfront. If you are on a server logged in via ssh you can often keep doing some work while most of the system is being updated and you can more easily remote updates. B) I will *not* trust an update system that cuts me out of my remote server and make me *hope* it will come up later. If yum freaks out for *whatever* reason I want to be there with an emergency shell open via ssh to try to recover the system. Not have to call the colocation and figure out what happened from possibly missing logs *if the system boots at all*. I've been saved more than once by a shell open during changes in the configuration or upgrades, that is non-negotiable to me. I do the same for the same reasons. C) Not all updates require immediate reboot. If I am updating the kernel and some minor package, I can as well decide to reboot at the end of the day, rarely the update is so critical I have to reboot NOW! For normal updates, yes. But I would not start an upgrade from one Fedora release to another at an inconvenient time and then wait to reboot hours later. In this discussion of whether yum upgrade would be enhanced alongside FedUp, I had assumed that FedUp would only be used for upgrading from one Fedora release to the next, not for regular software updates. Is that assumption wrong? -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Usr Move - More, Please
On 30 Jan 2012, at 00:17, Kevin Kofler wrote: Mike Pinkerton wrote: Additionally, app style programs will become more common in the future, whether on a portable or a desktop. Those app style programs are the only way one can create a central marketplace for small, easily downloaded and installed, distro-agnostic programs. Such a marketplace will become increasingly important to the vitality of any computing platform, including Linux. Keeping apps separate from managed and locally-compiled programs would be useful. I don't get how your nonstandard /app is any different from the standard /opt, i.e. why your distinction is needed. You seem to suggest that /usr/local should be a symlink to /opt, but that's misunderstanding how /opt is expected to work. /opt is supposed to work like your /app, /usr/ local is supposed to work like your /opt. So the distinction you apparently want already exists, there is no need to come up with new non-FHS directories. It is already common and recommended practice to install to /opt/ appname, not to /opt directly, that's the difference between /opt and /usr/local! Anything installing directly to /opt (i.e. putting e.g. binaries into /opt/bin) is abusing /opt and needs to be fixed. If (1) we mount /usr ro over the network, and (2) we want /usr to be reserved for managed software (for a variety of reasons), then /usr/ local really doesn't fit anymore. Because /opt is the only other current directory that makes sense for locally-compiled programs, I would symlink /usr/local - /opt. I understand that the FHS recommends installing to /opt/appname, but there is no enforcement of that. Currently compliance is a matter of local policy. I also don't think that the app model is something we should encourage, at all (package management exists for a reason!), but that is fairly irrelevant for this discussion because the model is already covered well by /opt. You might not want to encourage the app model, but that boat already left the dock. For Linux distros to be players on portables and desktops, they need to recognize that there is an appetite among the user base for app type programs that are easy to install (drag- and-drop). By bundling most of their dependencies, app type programs become one way to create a cross-distro app marketplace. If we end up with separate app marketplaces for Fedora, SUSE, Debian, Ubuntu, et alios, they are all going to languish. On the other hand, a single app marketplace for mainstream Linux distros might well prosper. I would keep app type programs separate from locally-compiled programs. With different update and back-up strategies for the two types of programs, the separation makes housekeeping a lot easier. If you prefer /opt/app and /opt/local, and symlink /usr/local - /opt/ local, that would work for me. I like the general approach that systemd has taken to configuration -- putting most of its default configuration in /lib/systemd and allowing host-specific entries in /etc/systemd to override them. I would like to see programs (including systemd) adopt a more rigorous version of that approach -- with all default configuration in /usr. The result would be that, immediately after installation, /etc would be empty. That is not possible without patching all the applications. FWIW, KDE applications already do this, in fact we have 4 layered directories of configuration, in increasing order of priority: * /usr/share/config: upstream defaults, installed by the package itself * /usr/share/kde-settings/kde-profile/default/share/config/: Fedora defaults, installed by the kde-settings package * /etc/kde: machine defaults, put in place by the local system administrator * ~/.kde/share/config: per-user settings, made by the individual user But most applications' configuration systems are not as flexible as KConfig and therefore cannot support this model without (heavy) patching. (Actually, we have to patch even KConfig to support the 4 layers! But the patch is very small because KConfig already has a concept of resource search paths. Most configuration systems are hardcoded to only look in /etc and/or some place in the user's home directory. And many of those systems are only used by one piece of software, so there would be a lot of code to patch.) So your non-FHS conf directories just cannot be arbitrarily implemented by a distribution where the upstream code doesn't support the concept. I understand. I think the concept of cascading configuration files is useful enough, though, that it would be a worthwhile goal. Perhaps when he finishes with systemd, Lennart can figure out how to interpose a generalized configuration cascader that would ease the pain. And, yes, I appreciate all the good work Lennart has been doing. -- Mike Pinkerton Still drinking the Kool-Aid -- devel mailing list devel@lists.fedoraproject.org https
Re: Usr Move - More, Please
On 30 Jan 2012, at 10:01, Emanuel Rietveld wrote: On 01/30/2012 03:38 PM, Mike Pinkerton wrote: You might not want to encourage the app model, but that boat already left the dock. For Linux distros to be players on portables and desktops, they need to recognize that there is an appetite among the user base for app type programs that are easy to install (drag-and-drop). By bundling most of their dependencies, app type programs become one way to create a cross- distro app marketplace. If we end up with separate app marketplaces for Fedora, SUSE, Debian, Ubuntu, et alios, they are all going to languish. On the other hand, a single app marketplace for mainstream Linux distros might well prosper. Unifying package management across distros would a Good Thing (tm). Once there's a unified interface to the package management system, you can envision things like app marketplaces that simply instruct the distribution to install that distribution's package of a particular app. Clicking Firefox would do yum install firefox on fedora and apt-get install firefox on Ubuntu. Let us do everything in our power to make this happen! If I understand you correctly, you are suggesting that a third party app marketplace, offering both open source and proprietary apps, would maintain multiple repos for apps based on distro, version and arch, and then implement the download of the appropriate version by utilizing the existing package management system, making apps part of the system's managed software. To make something like that viable, your app marketplace would probably also need to provide a packaging infrastructure to app developers that would enable them to build packages for all covered distros, versions and archs without actually having to learn each of the packaging systems. As for propietary software, there's nothing the open source community can do to influence the design decisions of proprietary software vendors. What you can do, however, is recognize that, if given the opportunity, your user base will download and install app type programs, and that it would be better to provide an appropriate place within the file system to place those apps. My suggestion -- which assumed that apps would not be managed by the package management system (because users will do what users do) -- was that an appropriate place would segregate app type programs from both managed software and locally-compiled software. Segregation would make housekeeping easier given the different update and back-up strategies that might be appropriate for app type programs. To return to your suggestion, but modify it a bit, perhaps there needs to be an unified interface for downloading, installing and launching app type programs that would (1) know where in a particular distro's file system they should be installed, and (2) provide easy access to app type programs from whichever GUI the user employs. -- Mike Pinkerton the Kool-Aid tastes great -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Usr Move - More, Please
I am late to the game but wanted to thank Harald and Kay for their efforts, and to encourage them to go even further. History has brought us to a point where there are at least 7 standard places to put binaries (not counting ~/bin): /bin /opt /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin plus a handful more locations for libraries. I accept your premises that the historical reasons for this division of binaries are no longer compelling, that the present variety of locations is confusing and works against cross-distro compatibility and that simplification is a good thing in itself. I encourage you to simplify things further by merging /usr/sbin into /usr/bin. While the reasons for the current categorization of binaries are no longer compelling, I think there is a case to make for a new division of binaries. Specifically, it is useful to separate those programs that are managed by a package management system from those that are not. Additionally, app style programs will become more common in the future, whether on a portable or a desktop. Those app style programs are the only way one can create a central marketplace for small, easily downloaded and installed, distro-agnostic programs. Such a marketplace will become increasingly important to the vitality of any computing platform, including Linux. Keeping apps separate from managed and locally-compiled programs would be useful. I like the general approach that systemd has taken to configuration -- putting most of its default configuration in /lib/systemd and allowing host-specific entries in /etc/systemd to override them. I would like to see programs (including systemd) adopt a more rigorous version of that approach -- with all default configuration in /usr. The result would be that, immediately after installation, /etc would be empty. So here is my suggestion: /app(host specific app style programs -- drag-and-drop installed programs wholly contained within a single directory tree with no dependencies outside that tree -- and which include defaults that can be overriden by configuration in an user's home directory) /etc(host specific configuration -- overrides all defaults -- package manager cannot write to this directory) /opt(unmanaged software -- both site and host specific) /bin /conf (all site or locally-compiled programs would put their default configuration files here) /lib /usr(managed software -- both distro and site packaged) /bin /conf /distro(distro default configuration files) /site (site default configuration -- overrides distro defaults) /lib With this directory structure, as a site administrator I can package my own site-wide configuration files, put them in a local repo, and override the distro default configuration. By limiting /etc to host- specific configuration, I maintain a clean separation of: + distro-default configuration files, which are never edited, and which are updated as distro packages are updated, + my site-default configuration files, which are never edited, and which are updated from my local repo, and + host-specific configuration files, which would probably only be necessary for a handful of programs per host. This approach also makes backing up easier. There is no need to back up any part of /usr -- it can be re-installed from repos, if it is not being mounted from a remote server. On a server, one would need to back up unmanaged software from /opt, host-specific configuration from a much slimmed-down /etc, and data files from /srv and /var. On a portable or desktop, /opt will probably be empty, /var will be expendable, and one would just need to back up /app, a much slimmed- down /etc, and /home, which should contain users data files and user- specific configuration for apps. This suggestion creates one new top-level directory, keeps the confusing historical names for compatibility purposes, and turns at least 5 current directories into symlinks: /bin- /usr/bin /sbin - /usr/bin /lib- /usr/lib /usr/local - /opt /usr/sbin - /usr/bin Bottomline, congratulations Harald and Kay on a good first step to simplifying and rationalizing the file structure. Now keep going. -- Mike Pinkerton Kool-Aid Drinker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
