Ok, just began playing with installing Fedora 23. I see that now, if your password is weak, the install won't continue. Youidiotdevelopers, by the way, works as a password.
So...
I thought we went through this last time and it was decided that as NO ONE wanted it, it would be dropped. What happened?
Is this still one person's idea? It's beginning to feel like a US politician, make some horrendous decision, an outcry is raised, it's dropped, then snuck in next time.
Before opening a bugzilla, I'm curious--is this simply the same person trying to sneak this in and hoping no one would notice this time, or was it a FESCO decision.
On Sat, Jul 25, 2015 at 11:04:43AM -0400, Scott Robbins wrote:
Ok, just began playing with installing Fedora 23. I see that now, if your password is weak, the install won't continue. Youidiotdevelopers, by the way, works as a password.
So...
I thought we went through this last time and it was decided that as NO ONE wanted it, it would be dropped. What happened?
Anyway, for those who don't think this is a good idea, I've opened a bug
https://bugzilla.redhat.com/show_bug.cgi?id=1246771
On Sat, 25 Jul 2015 11:27:32 -0400 Scott Robbins scottro@nyc.rr.com wrote:
On Sat, Jul 25, 2015 at 11:04:43AM -0400, Scott Robbins wrote:
Ok, just began playing with installing Fedora 23. I see that now, if your password is weak, the install won't continue. Youidiotdevelopers, by the way, works as a password.
So...
I thought we went through this last time and it was decided that as NO ONE wanted it, it would be dropped. What happened?
Anyway, for those who don't think this is a good idea, I've opened a bug
Please don't.
This is being worked out via a FESCo standardized passphrase policy.
https://fedorahosted.org/fesco/ticket/1455
We should have a draft soon, please don't heap ire on anaconda folks.
I'm not sure when we will get the changes landed, but please be patient.
kevin
On Sat, 25 Jul 2015, Kevin Fenzi wrote:
On Sat, 25 Jul 2015 11:27:32 -0400 Scott Robbins scottro@nyc.rr.com wrote:
Anyway, for those who don't think this is a good idea, I've opened a bug
Please don't.
This is being worked out via a FESCo standardized passphrase policy.
https://fedorahosted.org/fesco/ticket/1455
We should have a draft soon, please don't heap ire on anaconda folks.
There is more than a draft. There is code that is annoying people, hence this thread.
The suggested change that suppsedly is not here yet is to have a uniform password-quality standard.
The password setting "request" as part of an install is different from all other password settings. It comes before the user has been able to customize the system. Any quality standard that is part of an install should be advisory only, regardless of any otherwise uniform standard. Whether others are advisory should be customizeable.
Does the password standard for install-time passwords currently come from anaconda? If so, heaping comments on the anaconda people is the thing to do. If not, the comment heap should go elsewhere. In neither case do I see the point of patience. Patience is likely to give the people that matter a false sense of approval or tolerance.
I'm not sure when we will get the changes landed, but please be patient.
On Mon, 27 Jul 2015 01:19:55 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
There is more than a draft. There is code that is annoying people, hence this thread.
The suggested change that suppsedly is not here yet is to have a uniform password-quality standard.
The password setting "request" as part of an install is different from all other password settings. It comes before the user has been able to customize the system. Any quality standard that is part of an install should be advisory only, regardless of any otherwise uniform standard. Whether others are advisory should be customizeable.
The above is stuff thats all being worked on, yelling at anyone is unlikely to change the speed at which it gets done.
Does the password standard for install-time passwords currently come from anaconda? If so, heaping comments on the anaconda people is the thing to do. If not, the comment heap should go elsewhere. In neither case do I see the point of patience. Patience is likely to give the people that matter a false sense of approval or tolerance.
You're of course welcome to do whatever you like, but in my experience Open source maintainers treat impatient / intolerant people either by ( consciously or unconsciously ) ignoring them ("I have 50 bug reports from patient / tolerant people to look at") and/or by even becoming more determined to not make the change suggested by such people ("If I make this change it might make people think we respond to impatient / intolerant people").
So, IMHO, you are not pursuing the best way to get your change made.
kevin
On Mon, 27 Jul 2015, Kevin Fenzi wrote:
On Mon, 27 Jul 2015 01:19:55 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
There is more than a draft. There is code that is annoying people, hence this thread.
The suggested change that suppsedly is not here yet is to have a uniform password-quality standard.
The password setting "request" as part of an install is different from all other password settings. It comes before the user has been able to customize the system. Any quality standard that is part of an install should be advisory only, regardless of any otherwise uniform standard. Whether others are advisory should be customizeable.
The above is stuff thats all being worked on, yelling at anyone is unlikely to change the speed at which it gets done.
What does "worked on" mean? It seem to me that that is precisely the issue. It could mean fixing the problem. It could mean setting it in stone.
My expectation, and I think that of others, is that for anaconda, it will be set in stone.
Does the password standard for install-time passwords currently come from anaconda? If so, heaping comments on the anaconda people is the thing to do. If not, the comment heap should go elsewhere. In neither case do I see the point of patience. Patience is likely to give the people that matter a false sense of approval or tolerance.
You're of course welcome to do whatever you like, but in my experience Open source maintainers treat impatient / intolerant people either by
Patience and impatience are not completely complementary. They both refer to behavior that is in some sense an outlier.
( consciously or unconsciously ) ignoring them ("I have 50 bug reports from patient / tolerant people to look at") and/or by even becoming more determined to not make the change suggested by such people ("If I make this change it might make people think we respond to impatient / intolerant people").
How is a maintainer or a standard writer suppose to distinguish patience-based silence from approval-based silence?
Is there currently any reason to suppose that from now on anaconda will not enforce its notion of strong passwords?
In case the current work includes the setting in stone of anaconda's demand for "strong" passwords, what can or should those who prefer encouragement to enforcement do about it?
On Tue, 28 Jul 2015 17:39:55 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
The above is stuff thats all being worked on, yelling at anyone is unlikely to change the speed at which it gets done.
What does "worked on" mean?
I have been talking with pam, libpwquality, anaconda, gnome-initial-setup and passwd maintainers to come up with a technical way to implement a default policy. As well as a way to override it for local users or products that wish a different policy.
I have been spending a bunch of time exchanging emails, looking at libpwquality code and working out something everyone can implement.
It seem to me that that is precisely the issue. It could mean fixing the problem. It could mean setting it in stone.
My expectation, and I think that of others, is that for anaconda, it will be set in stone.
What does 'set in stone mean'? The current behavior? No. The proposed policy (which I just submitted to fesco for approval) wouldn't be the same as the current anaconda behavior.
...snip...
How is a maintainer or a standard writer suppose to distinguish patience-based silence from approval-based silence?
When a maintainer or standard writer says: "We are working on this, please hang on" and you wait that is patience. When you say "NO! I am filing bugs and complaining instead" thats anoying.
Is there currently any reason to suppose that from now on anaconda will not enforce its notion of strong passwords?
Yes, because there will be a distro wide policy that anaconda (and other local password changing things) will follow.
In case the current work includes the setting in stone of anaconda's demand for "strong" passwords, what can or should those who prefer encouragement to enforcement do about it?
Well, I would personally say you should wait until there was a proposed policy to look at. Now there is:
https://fedorahosted.org/fesco/ticket/1455#comment:30
Feel free to comment there or in the fesco meeting tomorrow.
If there's a great deal of problem with it we could also push it back to a discussion on the devel list.
The frustrating thing for me here is that I have been working on this (as my other piles of tasks permit) for a while now and then people come along and start yelling that it's not changed yet, and tell me that they refuse to wait until there's a proposal, they want to complain to anaconda folks now (who are also waiting until there's a fesco policy).
I appreciate that this is a very hot button issue for some folks, and I also appreciate that you want a solution 2 weeks ago, but I'm doing the best I can here to move us all to a nice standard distro policy and we aren't even at alpha yet.
kevin
On Jul 28, 2015 6:07 PM, "Kevin Fenzi" kevin@scrye.com wrote:
On Tue, 28 Jul 2015 17:39:55 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
The above is stuff thats all being worked on, yelling at anyone is unlikely to change the speed at which it gets done.
What does "worked on" mean?
I have been talking with pam, libpwquality, anaconda, gnome-initial-setup and passwd maintainers to come up with a technical way to implement a default policy. As well as a way to override it for local users or products that wish a different policy.
I have been spending a bunch of time exchanging emails, looking at libpwquality code and working out something everyone can implement.
It seem to me that that is precisely the issue. It could mean fixing the problem. It could mean setting it in stone.
My expectation, and I think that of others, is that for anaconda, it will be set in stone.
What does 'set in stone mean'? The current behavior? No. The proposed policy (which I just submitted to fesco for approval) wouldn't be the same as the current anaconda behavior.
...snip...
How is a maintainer or a standard writer suppose to distinguish patience-based silence from approval-based silence?
When a maintainer or standard writer says: "We are working on this, please hang on" and you wait that is patience. When you say "NO! I am filing bugs and complaining instead" thats anoying.
Is there currently any reason to suppose that from now on anaconda will not enforce its notion of strong passwords?
Yes, because there will be a distro wide policy that anaconda (and other local password changing things) will follow.
In case the current work includes the setting in stone of anaconda's demand for "strong" passwords, what can or should those who prefer encouragement to enforcement do about it?
Well, I would personally say you should wait until there was a proposed policy to look at. Now there is:
https://fedorahosted.org/fesco/ticket/1455#comment:30
Feel free to comment there or in the fesco meeting tomorrow.
If there's a great deal of problem with it we could also push it back to a discussion on the devel list.
The frustrating thing for me here is that I have been working on this (as my other piles of tasks permit) for a while now and then people come along and start yelling that it's not changed yet, and tell me that they refuse to wait until there's a proposal, they want to complain to anaconda folks now (who are also waiting until there's a fesco policy).
I appreciate that this is a very hot button issue for some folks, and I also appreciate that you want a solution 2 weeks ago, but I'm doing the best I can here to move us all to a nice standard distro policy and we aren't even at alpha yet.
kevin
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Thanks for working on this, Kevin. Personal opinions aside, I know you're very thorough and dedicated, and it is appreciated wholeheartedly.
--Pete
On Tue, 28 Jul 2015, Kevin Fenzi wrote:
On Tue, 28 Jul 2015 17:39:55 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
The above is stuff thats all being worked on, yelling at anyone is unlikely to change the speed at which it gets done.
What does "worked on" mean?
I have been talking with pam, libpwquality, anaconda, gnome-initial-setup and passwd maintainers to come up with a technical way to implement a default policy. As well as a way to override it for local users or products that wish a different policy.
If "local users" means people typing in passwords, that is good.
I have been spending a bunch of time exchanging emails, looking at libpwquality code and working out something everyone can implement.
It seem to me that that is precisely the issue. It could mean fixing the problem. It could mean setting it in stone.
My expectation, and I think that of others, is that for anaconda, it will be set in stone.
What does 'set in stone mean'? The current behavior? No. The proposed policy (which I just submitted to fesco for approval) wouldn't be the same as the current anaconda behavior.
That would be good, but from what I can see, the proposal does not specify a particular behavior. It specifies parameters from which a policy can be generated.
Is there currently any reason to suppose that from now on anaconda will not enforce its notion of strong passwords?
Yes, because there will be a distro wide policy that anaconda (and other local password changing things) will follow.
No one was worried that there might not be a distro-wide policy. The worry was that the policy would be truly annoying.
Happily, that seems not to be the case.
From the proposed policy:
We should have a base passphrase/password policy for applications to use. This allows them all to be consistent and also provide our users with needed security. Additionally, we should make it possible for our users to adjust this base policy as they need depending on their use cases.
We should provide a way for users or products to adjust this policy, and also a way to allow overriding it (if the policy allows).
If "users ... overriding it" means that the person typing in the password can just say yes, that is good. If anaconda's policy does not allow, that would be bad.
From what I can tell, anaconda might be shipped with a policy that requires
666-character passwords and does not allow the user to just say yes.
In case the current work includes the setting in stone of anaconda's demand for "strong" passwords, what can or should those who prefer encouragement to enforcement do about it?
Well, I would personally say you should wait until there was a proposed policy to look at. Now there is:
https://fedorahosted.org/fesco/ticket/1455#comment:30
Feel free to comment there or in the fesco meeting tomorrow.
If there's a great deal of problem with it we could also push it back to a discussion on the devel list.
The frustrating thing for me here is that I have been working on this (as my other piles of tasks permit) for a while now and then people come along and start yelling that it's not changed yet, and tell me that they refuse to wait until there's a proposal, they want to complain to anaconda folks now (who are also waiting until there's a fesco policy).
The *decision* to fix the annoyance that started this discussion does not require waiting for fesco. The anaconda folks can, if they so desire, make anaconda warn about bad passwords without necessarily rejecting them. It's possible that the anaconda folks promised to do just that. If so, I missed it. A pointer to said promise would be good news.
I've seen at least one case of vehemence over clarity by a professional writer. In the heat of the utterance, neither said writer nor most of his readers noticed that he had not quite stated what they thought he had.
A sufficiently annoyed anaconda person might respond with vehemence that they are working on it. Not very informative if the reader suspects that they do not share the same judgement of the status quo. "working on it" might mean setting the status quo in stone*.
I appreciate that this is a very hot button issue for some folks, and I also appreciate that you want a solution 2 weeks ago, but I'm doing the best I can here to move us all to a nice standard distro policy and we aren't even at alpha yet.
Again, the issue was never "how fast are we getting a policy?". The issue was always "what policy are we getting?".
How many people usually participate in alpha?
* to set in stone -- to make something so permanent that to change it takes effort akin to hammer and chisel work.
On Wed, 29 Jul 2015 02:14:27 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Tue, 28 Jul 2015, Kevin Fenzi wrote:
On Tue, 28 Jul 2015 17:39:55 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
The above is stuff thats all being worked on, yelling at anyone is unlikely to change the speed at which it gets done.
What does "worked on" mean?
I have been talking with pam, libpwquality, anaconda, gnome-initial-setup and passwd maintainers to come up with a technical way to implement a default policy. As well as a way to override it for local users or products that wish a different policy.
If "local users" means people typing in passwords, that is good.
It means local authentication. As opposed to say a password in a remote freeipa server or the password to your google account or the like.
That would be good, but from what I can see, the proposal does not specify a particular behavior. It specifies parameters from which a policy can be generated.
I'm not sure I am able to parse your meaning there.
No one was worried that there might not be a distro-wide policy. The worry was that the policy would be truly annoying.
ok, but perhaps you could wait until there is a policy to decide that?
Many things could be anoying someday somehow.
If "users ... overriding it" means that the person typing in the password can just say yes, that is good. If anaconda's policy does not allow, that would be bad.
Yes, the person will be able to see "Your password is too simple" Or "Your password is based on a dictionary word" or "Your password is in this list of 10,000 cracked passwords from other sites on the net" or whatever and then they can decide to just use that poor password anyhow.
From what I can tell, anaconda might be shipped with a policy that requires 666-character passwords and does not allow the user to just say yes.
Hyperbole. ;)
The *decision* to fix the annoyance that started this discussion does not require waiting for fesco. The anaconda folks can, if they so desire, make anaconda warn about bad passwords without necessarily rejecting them. It's possible that the anaconda folks promised to do just that. If so, I missed it. A pointer to said promise would be good news.
Sure, anaconda developers can choose to do whatever they like, and in the absence of a distro wide policy they did so.
I've seen at least one case of vehemence over clarity by a professional writer. In the heat of the utterance, neither said writer nor most of his readers noticed that he had not quite stated what they thought he had.
I'm not following here...
A sufficiently annoyed anaconda person might respond with vehemence that they are working on it. Not very informative if the reader suspects that they do not share the same judgement of the status quo. "working on it" might mean setting the status quo in stone*.
Well, sure, thats the case in any open source project. You as a user of that project are welcome to try and convince the people doing work to change things to what you desire. If you fail to do this, then it will not get done. After a decision has been made to you suppose more and more queries to change the decision will go well?
I appreciate that this is a very hot button issue for some folks, and I also appreciate that you want a solution 2 weeks ago, but I'm doing the best I can here to move us all to a nice standard distro policy and we aren't even at alpha yet.
Again, the issue was never "how fast are we getting a policy?". The issue was always "what policy are we getting?".
How many people usually participate in alpha?
No idea. Stats are very hard to come by for lots of reasons.
kevin
On Wed, Jul 29, 2015 at 02:49:09PM -0600, Kevin Fenzi wrote:
Well, sure, thats the case in any open source project. You as a user of that project are welcome to try and convince the people doing work to change things to what you desire. If you fail to do this, then it will not get done. After a decision has been made to you suppose more and more queries to change the decision will go well?
Well, though I feel like a troll for being the one to raise this--and it's also causing heated discussion on the CentOS list, that's the point. Maybe, if they realize how many people it annoys, they'll drop it.
Anyway, while an 8 character lowercase letter number combo was considered too weak, sizematters was considered sufficient.
I think, that like many other decisions disliked by the more experienced, they're going to wind up doing it, and once again, a few people will, when it goes into RHEL, be annoyed enough to leave, but not enough to really affect their business--who wants to change the O/S on 100, or even 5, servers?
I think that closing the two bug reports immediately was somewhat premature.
Again, the issue was never "how fast are we getting a policy?". The issue was always "what policy are we getting?".
Or perhaps, why are we suddenly instituting this policy?
I believe that I used the analogy last time they tried, of the TSA. It gives some appearance of security, does almost no good, and serves to annoy the vast majority.
On Wed, 29 Jul 2015 17:03:33 -0400 Scott Robbins scottro@nyc.rr.com wrote:
On Wed, Jul 29, 2015 at 02:49:09PM -0600, Kevin Fenzi wrote:
Well, sure, thats the case in any open source project. You as a user of that project are welcome to try and convince the people doing work to change things to what you desire. If you fail to do this, then it will not get done. After a decision has been made to you suppose more and more queries to change the decision will go well?
Well, though I feel like a troll for being the one to raise this--and it's also causing heated discussion on the CentOS list, that's the point. Maybe, if they realize how many people it annoys, they'll drop it.
Perhaps. But it's a far cry from: "Here's a poll we did that asked X and Y% of people said they didn't like it" vs "Die developer! I hate you"
Anyway, while an 8 character lowercase letter number combo was considered too weak, sizematters was considered sufficient.
I'm not sure I follow this?
I think, that like many other decisions disliked by the more experienced, they're going to wind up doing it, and once again, a few people will, when it goes into RHEL, be annoyed enough to leave, but not enough to really affect their business--who wants to change the O/S on 100, or even 5, servers?
Well, if we are still talking about anaconda initial password behavior, it only affects people installing from the gui, not kickstart users. Also, there's a way to customize it (for both), and also you can change it to whatever you like after you install. I'm not sure this was "disliked by the more experienced".
I think that closing the two bug reports immediately was somewhat premature.
Again, the issue was never "how fast are we getting a policy?". The issue was always "what policy are we getting?".
Or perhaps, why are we suddenly instituting this policy?
Please be carefull of your quoting. I didn't say those things. ;)
I believe that I used the analogy last time they tried, of the TSA. It gives some appearance of security, does almost no good, and serves to annoy the vast majority.
I don't see the similarity here, but ok.
Anyhow, I likely will stop replying to this thread unless theres specific things I can answer. I have tons to do. ;)
kevin
On Wed, Jul 29, 2015 at 03:10:37PM -0600, Kevin Fenzi wrote:
On Wed, 29 Jul 2015 17:03:33 -0400
Scott Robbins scottro@nyc.rr.com wrote:
On Wed, Jul 29, 2015 at 02:49:09PM -0600, Kevin Fenzi wrote: Anyway, while an 8 character lowercase letter number combo was considered too weak, sizematters was considered sufficient.
I'm not sure I follow this?
More or less a throwaway line. I made the point that 8 characters, no matter how random, was not sufficient but a password of all lower case with two dictionary words was OK. Not really germane to the disucssion. The "Anyway" part meant that _I_ am not all that bothered by it as the password requirements aren't very complex--or very useful, in my less than humble opinion.
I think, that like many other decisions disliked by the more experienced, they're going to wind up doing it, and once again, a few people will, when it goes into RHEL, be annoyed enough to leave, but not enough to really affect their business--who wants to change the O/S on 100, or even 5, servers?
Again, the issue was never "how fast are we getting a policy?". The issue was always "what policy are we getting?".
(To clarify, this statement was made by me, Scott)
Or perhaps, why are we suddenly instituting this policy? <---From
Scott, NOT Kevin.
I'm sorry--if anyone thought that I was implying that you said that, I most sincerely apologize--I've always felt you were one of the more reasonable and responsive to user Fedora folk.
Please be carefull of your quoting. I didn't say those things. ;)
I've kept that part in, emphasizing that it was me, not you--again, if anyone thought that was you saying it, please accept my apologies.
I believe that I used the analogy last time they tried, of the TSA. It gives some appearance of security, does almost no good, and serves to annoy the vast majority.
I don't see the similarity here, but ok.
Anyhow, I likely will stop replying to this thread unless theres specific things I can answer. I have tons to do. ;)
Fair enough. :) And, (again, no sarcasm here) much of it being for the benefit of Fedora and its users.
On Wed, 29 Jul 2015 17:28:41 -0400 Scott Robbins scottro@nyc.rr.com wrote: ...snip...
(To clarify, this statement was made by me, Scott)
Or perhaps, why are we suddenly instituting this policy? <---From
Scott, NOT Kevin.
I'm sorry--if anyone thought that I was implying that you said that, I most sincerely apologize--I've always felt you were one of the more reasonable and responsive to user Fedora folk.
I try. Sometimes it works. :)
Please be carefull of your quoting. I didn't say those things. ;)
I've kept that part in, emphasizing that it was me, not you--again, if anyone thought that was you saying it, please accept my apologies.
Not a big deal, it happens to us all, I just wanted to note it. :)
kevin
On 07/29/2015 02:10 PM, Kevin Fenzi wrote:
Well, if we are still talking about anaconda initial password behavior, it only affects people installing from the gui, not kickstart users. Also, there's a way to customize it (for both), and also you can change it to whatever you like after you install. I'm not sure this was "disliked by the more experienced".
I would appreciate more info on these options.
I currently use the kickstart option to set initial passwords, is there something else?
How could I customize the password settings for installing from the gui?
I also couldn't find any way to do it after installation. system-config-authentication didn't seem to be able to disable the password quality checks. I have to directly modify the pam.d files to remove pwquality, which is a rather unfortunate drastic measure.
On Wed, 29 Jul 2015 14:51:29 -0700 Samuel Sieb samuel@sieb.net wrote:
On 07/29/2015 02:10 PM, Kevin Fenzi wrote:
Well, if we are still talking about anaconda initial password behavior, it only affects people installing from the gui, not kickstart users. Also, there's a way to customize it (for both), and also you can change it to whatever you like after you install. I'm not sure this was "disliked by the more experienced".
I would appreciate more info on these options.
I currently use the kickstart option to set initial passwords, is there something else?
If you set the password in the kickstart, it doesn't do any quality checks at all. You could set it to "a" if you liked.
How could I customize the password settings for installing from the gui?
You would need to add a /etc/security/pwquality.conf.d/yourname.conf with the settings you desired. For a boot image like a netinstall or dvd you would need to have that in the package set when you make the image. For a live I think you could just add it after you booted if you like (or add it in the kickstart to be made).
I also couldn't find any way to do it after installation. system-config-authentication didn't seem to be able to disable the password quality checks. I have to directly modify the pam.d files to remove pwquality, which is a rather unfortunate drastic measure.
Modify /etc/security/pwquality.conf.d/whatever.conf
(at least with f23/rawhide). I doubt thats been pushed to older stable releases.
kevin
On Thu, 30 Jul 2015, Kevin Fenzi wrote:
On Wed, 29 Jul 2015 14:51:29 -0700 Samuel Sieb samuel@sieb.net wrote:
On 07/29/2015 02:10 PM, Kevin Fenzi wrote:
How could I customize the password settings for installing from the gui?
You would need to add a /etc/security/pwquality.conf.d/yourname.conf with the settings you desired. For a boot image like a netinstall or dvd you would need to have that in the package set when you make the image. For a live I think you could just add it after you booted if you like (or add it in the kickstart to be made).
I didn't know one could edit files during an install. I'd thought one had to wait until anaconda caused a reboot. At that point, anaconda has already quality-checked your root password.
On Thu, 6 Aug 2015 00:56:29 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 30 Jul 2015, Kevin Fenzi wrote:
On Wed, 29 Jul 2015 14:51:29 -0700 Samuel Sieb samuel@sieb.net wrote:
On 07/29/2015 02:10 PM, Kevin Fenzi wrote:
How could I customize the password settings for installing from the gui?
You would need to add a /etc/security/pwquality.conf.d/yourname.conf with the settings you desired. For a boot image like a netinstall or dvd you would need to have that in the package set when you make the image. For a live I think you could just add it after you booted if you like (or add it in the kickstart to be made).
I didn't know one could edit files during an install.
well, before an install. Before you run anaconda / livinst.
I'd thought one had to wait until anaconda caused a reboot. At that point, anaconda has already quality-checked your root password.
If you are using the live media you should be able to change the libpwquality settings and have anaconda use them.
kevin
-
Kevin Fenzi -
Michael Hennebry -
Pete Travis -
Samuel Sieb -
Scott Robbins