git: c2284083a9 - main - Documentation: Correct some typos
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 04 Sep 2022 12:00:09 UTC
The branch main has been updated by gbe:
URL: https://cgit.FreeBSD.org/doc/commit/?id=c2284083a9814706c43b3d1afa2dd12ce23d7b44
commit c2284083a9814706c43b3d1afa2dd12ce23d7b44
Author: Gordon Bergling <gbe@FreeBSD.org>
AuthorDate: 2022-09-04 11:59:58 +0000
Commit: Gordon Bergling <gbe@FreeBSD.org>
CommitDate: 2022-09-04 11:59:58 +0000
Documentation: Correct some typos
- s/occured/occurred/
---
documentation/content/el/books/handbook/security/_index.adoc | 2 +-
documentation/content/it/books/handbook/security/_index.adoc | 2 +-
website/content/en/status/report-2017-07-2017-09.html | 2 +-
website/content/en/status/report-2019-07-2019-09.html | 4 ++--
website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/documentation/content/el/books/handbook/security/_index.adoc b/documentation/content/el/books/handbook/security/_index.adoc
index 33114a15cf..615a41c964 100644
--- a/documentation/content/el/books/handbook/security/_index.adoc
+++ b/documentation/content/el/books/handbook/security/_index.adoc
@@ -189,7 +189,7 @@ A good security script will also check for changes to user and staff members acc
If you have a huge amount of user disk space, it may take too long to run through every file on those partitions. In this case, setting mount flags to disallow suid binaries and devices on those partitions is a good idea. The `nodev` and `nosuid` options (see man:mount[8]) are what you want to look into. You should probably scan them anyway, at least once a week, since the object of this layer is to detect a break-in attempt, whether or not the attempt succeeds.
-Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occured.
+Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occurred.
Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a manner as possible - remote syslog can be very useful. An intruder will try to cover his tracks, and log files are critical to the sysadmin trying to track down the time and method of the initial break-in. One way to keep a permanent record of the log files is to run the system console to a serial port and collect the information to a secure machine monitoring the consoles.
diff --git a/documentation/content/it/books/handbook/security/_index.adoc b/documentation/content/it/books/handbook/security/_index.adoc
index e57891ac4c..57c8b7e3aa 100644
--- a/documentation/content/it/books/handbook/security/_index.adoc
+++ b/documentation/content/it/books/handbook/security/_index.adoc
@@ -189,7 +189,7 @@ A good security script will also check for changes to user and staff members acc
If you have a huge amount of user disk space, it may take too long to run through every file on those partitions. In this case, setting mount flags to disallow suid binaries and devices on those partitions is a good idea. The `nodev` and `nosuid` options (see man:mount[8]) are what you want to look into. You should probably scan them anyway, at least once a week, since the object of this layer is to detect a break-in attempt, whether or not the attempt succeeds.
-Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occured.
+Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occurred.
Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a manner as possible - remote syslog can be very useful. An intruder will try to cover his tracks, and log files are critical to the sysadmin trying to track down the time and method of the initial break-in. One way to keep a permanent record of the log files is to run the system console to a serial port and collect the information to a secure machine monitoring the consoles.
diff --git a/website/content/en/status/report-2017-07-2017-09.html b/website/content/en/status/report-2017-07-2017-09.html
index af02ff0be7..6ca1fdf2b0 100644
--- a/website/content/en/status/report-2017-07-2017-09.html
+++ b/website/content/en/status/report-2017-07-2017-09.html
@@ -880,7 +880,7 @@
This uses the recently added NT_LWPINFO note to extract
signal information from process cores.</p>
- <p>Hangs that occured when GDB's <tt>kill</tt> command was used
+ <p>Hangs that occurred when GDB's <tt>kill</tt> command was used
were fixed in FreeBSD in r313992.</p>
<h3>Open tasks:</h3><ol><li>Figure out why the powerpc <tt>kgdb</tt> targets are not able to
unwind the stack past the initial frame.</li><li>Test support for sparc64 binaries and kernels.</li><li>Add support for debugging powerpc vector registers.</li><li>Implement <tt>info proc</tt> commands.</li><li>Implement <tt>info os</tt> commands.</li></ol><hr /><br /><h1><a name="Ports" href="#Ports" id="Ports">Ports</a></h1><p>Changes affecting the Ports Collection, whether sweeping
diff --git a/website/content/en/status/report-2019-07-2019-09.html b/website/content/en/status/report-2019-07-2019-09.html
index 190fad2639..f2e48e4fd7 100644
--- a/website/content/en/status/report-2019-07-2019-09.html
+++ b/website/content/en/status/report-2019-07-2019-09.html
@@ -1794,14 +1794,14 @@ and December only and the report will probably be out in mid January.</p><p>-- L
the faulting instruction is restarted. If fault cannot be
handled for
any reason, the next action depends on the mode in which
- the fault occured.
+ the fault occurred.
If it was in kernel, and the kernel installed a helper,
then the helper is
called instead of returning to the faulting instruction.
Otherwise,
a kernel-mode page fault causes a panic.</p>
- <p>If the unhandled fault occured in usermode, then all
+ <p>If the unhandled fault occurred in usermode, then all
Unixes send a
signal to the thread whose execution caused the exception.
POSIX (or
diff --git a/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc b/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc
index a0362524e1..814598c6aa 100644
--- a/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc
+++ b/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc
@@ -86,7 +86,7 @@ system-global context switches. Instead, if the process registered for
rseq(2), on any return to user mode we check if any exceptional
events happened while the thread was in the kernel (context switches may happen
only while the thread is in kernel mode), and if a context switch indeed
-occured, we fire an ast to check whether the program counter is inside the
+occurred, we fire an ast to check whether the program counter is inside the
critical section and jump to the abort handler if it is.
The implementations of membarrier(2) and rseq(2) are clean-room: I used