WIP:Update man pages for chage, shadow, passwd #1243
Conversation
Signed-off-by: Alejandro Colomar <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
Our caller, strtoday(), already handles a raw number. Signed-off-by: Alejandro Colomar <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
| This field may be empty, in which case no passwords are | ||
| required to authenticate as the specified login name. | ||
| However, some applications which read the | ||
| <filename>/etc/shadow</filename> file may decide not to permit | ||
| any access at all if the password field is empty. | ||
| This field may be empty, in which case | ||
| no passwords are required to authenticate with the specified login name. |
There was a problem hiding this comment.
@hallyn , I'm not native. What sounds better to you? 'as' or 'with'?
| that the password is locked. The remaining characters on the | ||
| that the password is locked. The remaining characters on the |
There was a problem hiding this comment.
Hi @domiborges !
This is a contentious thing. The correct amount of inter-sentence space is two. See some history about this:
https://web.archive.org/web/20171217060354/http://www.heracliteanriver.com/?p=324.
Don't let others lie to you about it; one space is wrong. :-)
TL;DR: editorial companies moved from two spaces to one space to reduce costs, by being able to hire less experienced editors.
There was a problem hiding this comment.
On the other hand, semantic newlines preclude this at all. After period, one should start a new source line.
There was a problem hiding this comment.
In the Linux man-pages project, we have two spaces as a rule, for commit messages (in the source code of manual pages we don't need this rule, due to semantic newlines).
|
I have applied your first two patches into my PR. I've signed them on your behalf (with some minor tweaks too). Thanks! The rest still need some review. |
| <para> | ||
| Passing the value <emphasis>-1</emphasis> or an empty string | ||
| as the <replaceable>LAST_DAY</replaceable> | ||
| clears the value and removes the password change requirement. | ||
| </para> |
There was a problem hiding this comment.
@hallyn and @alejandro-colomar does it make sense to empty the last changed date?
There was a problem hiding this comment.
I don't know if it's useful for anything. A dummy value of 0 would serve the same purpose I guess.
Are you considering removal of the feature?
There was a problem hiding this comment.
I'm just trying to understand whether it makes sense. Even though the functionality was there the man page didn't explain it, so probably many users weren't aware of it.
There was a problem hiding this comment.
I think it makes sense. We must support a shadow file without the value, and new users have an empty value, so it makes sense that someone may want to reset a user back to "factory settings", and to do so, they'll want to remove it. However, I think we don't need two ways to specify that. An empty string would be enough. IMO, -1 should be a valid date referring to the day before Epoch.
| Passing the number <emphasis remap='I'>-1</emphasis> as the | ||
| <replaceable>EXPIRE_DATE</replaceable> will remove an account | ||
| expiration date. | ||
| Passing the value <emphasis remap='I'>-1</emphasis> |
There was a problem hiding this comment.
Thanks! I will also amend this in the patch I've picked into my PR.
| The user is first prompted for their old password, if one is present. | ||
| This password is then encrypted and compared with the stored password. | ||
| The user has only one attempt to enter the correct password. | ||
| The superuser can bypass this step to allow changing forgotten passwords. |
| Then, the password is tested for complexity. | ||
| <command>passwd</command> rejects any password that does not meet | ||
| the required complexity. | ||
| Do not to include the system default erase or kill characters. |
| age where the user is expected to replace this password. See <citerefentry> | ||
| <refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum> | ||
| </citerefentry>for more information. | ||
| Defines the number of days after a password exceeds its maximum age |
| The date on which the user account will be disabled. The date is | ||
| Sets the date on which the user account will be disabled. The date must be | ||
| specified in the format <emphasis remap='I'>YYYY-MM-DD</emphasis>. |
There was a problem hiding this comment.
useradd and usermod accept the same input values as chage for expiredate. I'd recommend you to use the same text here.
Hi! @ikerexxe suggested I could use the opportunity of #1238 to review and update these man pages. I did an initial review so we can start a discussion.
I'm marking the PR as a draft as it depends on #1238