mirror of
git://git.proxmox.com/git/pve-docs.git
synced 2025-02-08 05:57:33 +03:00
docs: fix typos
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
This commit is contained in:
parent
f695945542
commit
456b17fa59
@ -1080,7 +1080,7 @@ The CRS is currently used at the following scheduling points:
|
||||
new target node for the HA services in that group, matching the adapted
|
||||
priority constraints.
|
||||
|
||||
- HA service stopped -> start transtion (opt-in). Requesting that a stopped
|
||||
- HA service stopped -> start transition (opt-in). Requesting that a stopped
|
||||
service should be started is an good opportunity to check for the best suited
|
||||
node as per the CRS algorithm, as moving stopped services is cheaper to do
|
||||
than moving them started, especially if their disk volumes reside on shared
|
||||
|
@ -68,10 +68,10 @@ the Postfix daemon.
|
||||
The configuration for Sendmail target plugins has the following options:
|
||||
|
||||
* `mailto`: E-Mail address to which the notification shall be sent to. Can be
|
||||
set multiple times to accomodate multiple recipients.
|
||||
set multiple times to accommodate multiple recipients.
|
||||
* `mailto-user`: Users to which emails shall be sent to. The user's email
|
||||
address will be looked up in `users.cfg`. Can be set multiple times to
|
||||
accomodate multiple recipients.
|
||||
accommodate multiple recipients.
|
||||
* `author`: Sets the author of the E-Mail. Defaults to `Proxmox VE`.
|
||||
* `from-address`: Sets the from address of the E-Mail. If the parameter is not
|
||||
set, the plugin will fall back to the `email_from` setting from
|
||||
@ -106,10 +106,10 @@ in case of a failed mail delivery.
|
||||
The configuration for SMTP target plugins has the following options:
|
||||
|
||||
* `mailto`: E-Mail address to which the notification shall be sent to. Can be
|
||||
set multiple times to accomodate multiple recipients.
|
||||
set multiple times to accommodate multiple recipients.
|
||||
* `mailto-user`: Users to which emails shall be sent to. The user's email
|
||||
address will be looked up in `users.cfg`. Can be set multiple times to
|
||||
accomodate multiple recipients.
|
||||
accommodate multiple recipients.
|
||||
* `author`: Sets the author of the E-Mail. Defaults to `Proxmox VE`.
|
||||
* `from-address`: Sets the From-addresss of the email. SMTP relays might require
|
||||
that this address is owned by the user in order to avoid spoofing.
|
||||
@ -221,7 +221,7 @@ a matcher must be true. Defaults to `all`.
|
||||
[[notification_matchers_calendar]]
|
||||
Calendar Matching Rules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A calendar matcher matches the time when a notification is sent agaist a
|
||||
A calendar matcher matches the time when a notification is sent against a
|
||||
configurable schedule.
|
||||
|
||||
* `match-calendar 8-12`
|
||||
@ -241,7 +241,7 @@ the node.
|
||||
If a matched metadata field does not exist, the notification will not be
|
||||
matched.
|
||||
For instance, a `match-field regex:hostname=.*` directive will only match
|
||||
notifications that have an arbitraty `hostname` metadata field, but will
|
||||
notifications that have an arbitrary `hostname` metadata field, but will
|
||||
not match if the field does not exist.
|
||||
|
||||
[[notification_matchers_severity]]
|
||||
|
@ -105,7 +105,7 @@ How can I upgrade {pve} to the next point release?::
|
||||
Minor version upgrades, for example upgrading from {pve} in version 7.1
|
||||
to 7.2 or 7.3, can be done just like any normal update.
|
||||
But you should still check the https://pve.proxmox.com/wiki/Roadmap[release notes]
|
||||
for any relevant noteable, or breaking change.
|
||||
for any relevant notable, or breaking change.
|
||||
+
|
||||
For the update itself use either the Web UI __Node -> Updates__ panel or
|
||||
through the CLI with:
|
||||
|
@ -648,7 +648,7 @@ https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F[nftables]
|
||||
rather than iptables.
|
||||
|
||||
WARNING: `proxmox-firewall` is currently in tech preview. There might be bugs or
|
||||
incompatibilies with the original firewall. It is currently not suited for
|
||||
incompatibilities with the original firewall. It is currently not suited for
|
||||
production use.
|
||||
|
||||
This implementation uses the same configuration files and configuration format,
|
||||
|
@ -16,7 +16,7 @@ protects you from errors.
|
||||
A Linux bridge interface (commonly called 'vmbrX') is needed to connect guests
|
||||
to the underlying physical network. It can be thought of as a virtual switch
|
||||
which the guests and physical interfaces are connected to. This section provides
|
||||
some examples on how the network can be set up to accomodate different use cases
|
||||
some examples on how the network can be set up to accommodate different use cases
|
||||
like redundancy with a xref:sysadmin_network_bond['bond'],
|
||||
xref:sysadmin_network_vlan['vlans'] or
|
||||
xref:sysadmin_network_routed['routed'] and
|
||||
@ -26,7 +26,7 @@ The xref:chapter_pvesdn[Software Defined Network] is an option for more complex
|
||||
virtual networks in {pve} clusters.
|
||||
|
||||
WARNING: It's discouraged to use the traditional Debian tools `ifup` and `ifdown`
|
||||
if unsure, as they have some pitfalls like interupting all guest traffic on
|
||||
if unsure, as they have some pitfalls like interrupting all guest traffic on
|
||||
`ifdown vmbrX` but not reconnecting those guest again when doing `ifup` on the
|
||||
same bridge later.
|
||||
|
||||
|
@ -23,7 +23,7 @@ pvescheduler - Proxmox VE Scheduler Daemon
|
||||
==========================================
|
||||
endif::manvolnum[]
|
||||
|
||||
This deamon is responsible for starting jobs according to the schedule,
|
||||
This daemon is responsible for starting jobs according to the schedule,
|
||||
such as replication and vzdump jobs.
|
||||
|
||||
For vzdump jobs, it gets its configuration from the file `/etc/pve/jobs.cfg`
|
||||
|
@ -341,7 +341,7 @@ Exit Nodes Local Routing:: This is a special option if you need to reach a VM/CT
|
||||
|
||||
Advertise Subnets:: Announce the full subnet in the EVPN network.
|
||||
If you have silent VMs/CTs (for example, if you have multiple IPs and the
|
||||
anycast gateway doesn't see traffic from theses IPs, the IP addresses won't be
|
||||
anycast gateway doesn't see traffic from these IPs, the IP addresses won't be
|
||||
able to be reached inside the EVPN network). Optional.
|
||||
|
||||
Disable ARP ND Suppression:: Don't suppress ARP or ND (Neighbor Discovery)
|
||||
|
@ -194,7 +194,7 @@ required to set a password for this type of user upon creation.
|
||||
LDAP
|
||||
~~~~
|
||||
|
||||
You can also use an external LDAP server for user authentication (for examle,
|
||||
You can also use an external LDAP server for user authentication (for example,
|
||||
OpenLDAP). In this realm type, users are searched under a 'Base Domain Name'
|
||||
(`base_dn`), using the username attribute specified in the 'User Attribute Name'
|
||||
(`user_attr`) field.
|
||||
|
2
qm.adoc
2
qm.adoc
@ -852,7 +852,7 @@ You can enable the VNC clipboard by setting `clipboard` to `vnc`.
|
||||
In order to use the clipboard feature, you must first install the
|
||||
SPICE guest tools. On Debian-based distributions, this can be achieved
|
||||
by installing `spice-vdagent`. For other Operating Systems search for it
|
||||
in the offical repositories or see: https://www.spice-space.org/download.html
|
||||
in the official repositories or see: https://www.spice-space.org/download.html
|
||||
|
||||
Once you have installed the spice guest tools, you can use the VNC clipboard
|
||||
function (e.g. in the noVNC console panel). However, if you're using
|
||||
|
@ -172,7 +172,7 @@ image when the storage supports it), this has the advantage that already
|
||||
allocated parts of the image can be re-used later, which can still help save
|
||||
quite a bit of space.
|
||||
|
||||
WARNING: On a storage that's not thinly provisioned, for exampple, LVM or ZFS
|
||||
WARNING: On a storage that's not thinly provisioned, for example, LVM or ZFS
|
||||
without the `sparse` option, the full size of the original disk needs to be
|
||||
reserved for the fleecing image up-front. On a thinly provisioned storage, the
|
||||
fleecing image can grow to the same size as the original image only if the guest
|
||||
|
Loading…
x
Reference in New Issue
Block a user