diff --git a/documentation/content/en/books/handbook/jails/_index.adoc b/documentation/content/en/books/handbook/jails/_index.adoc --- a/documentation/content/en/books/handbook/jails/_index.adoc +++ b/documentation/content/en/books/handbook/jails/_index.adoc @@ -107,7 +107,7 @@ * High degree of isolation: Processes within the jail are isolated from the host system and other jails. * Independence: Thick jails can have different versions of libraries, configurations, and software than the host system or other jails. -* Security: Since the jail contains its own base system, vulnerabilities or issues affecting the jail environment won't directly impact the host or other jails. +* Security: Since the jail contains its own base system, vulnerabilities or issues affecting the jail environment will not directly impact the host or other jails. Disadvantages of Thick Jails: @@ -126,16 +126,23 @@ Advantages of Thin Jails: -* Resource Efficiency: Thin jails are more resource-efficient compared to thick jails. Since they share most of the base system, they consume less disk space and memory. This makes it possible to run more jails on the same hardware without consuming excessive resources. -* Faster Deployment: Creating and launching thin jails is generally faster compared to thick jails. This can be particularly advantageous when you need to rapidly deploy multiple instances. -* Unified Maintenance: Since thin jails share the majority of their base system with the host system, updates and maintenance of common base system components (such as libraries and binaries) only need to be done once on the host. This simplifies the maintenance process compared to maintaining an individual base system for each thick jail. -* Shared Resources: Thin jails can more easily share common resources such as libraries and binaries with the host system. This can potentially lead to more efficient disk caching and improved performance for applications within the jail. +* Resource Efficiency: Thin jails are more resource-efficient compared to thick jails. +Since they share most of the base system, they consume less disk space and memory. +This makes it possible to run more jails on the same hardware without consuming excessive resources. +* Faster Deployment: Creating and launching thin jails is generally faster compared to thick jails. +This can be particularly advantageous when rapidly deploying multiple instances. +* Unified Maintenance: Since thin jails share the majority of their base system with the host system, updates and maintenance of common base system components (such as libraries and binaries) only need to be done once on the host. +This simplifies the maintenance process compared to maintaining an individual base system for each thick jail. +* Shared Resources: Thin jails can more easily share common resources such as libraries and binaries with the host system. +This can potentially lead to more efficient disk caching and improved performance for applications within the jail. Disadvantages of Thin Jails: -* Reduced Isolation: The primary disadvantage of thin jails is that they offer less isolation compared to thick jails. Since they share a significant portion of the template's base system, vulnerabilities or issues affecting shared components could potentially impact multiple jails simultaneously. +* Reduced Isolation: The primary disadvantage of thin jails is that they offer less isolation compared to thick jails. +Since they share a significant portion of the template's base system, vulnerabilities or issues affecting shared components could potentially impact multiple jails simultaneously. * Security Concerns: The reduced isolation in thin jails could pose security risks, as a compromise in one jail might have a greater potential to affect other jails or the host system. -* Dependency Conflicts: If multiple thin jails require different versions of the same libraries or software, managing dependencies can become complex. In some cases, this might require additional effort to ensure compatibility. +* Dependency Conflicts: If multiple thin jails require different versions of the same libraries or software, managing dependencies can become complex. +In some cases, this might require additional effort to ensure compatibility. * Compatibility Challenges: Applications within a thin jail might encounter compatibility issues if they assume a certain base system environment that differs from the shared components provided by the template. [[service-jails]] @@ -151,7 +158,8 @@ * Zero Administration: A service jail ready service needs only one config line in [.filename]#/etc/rc.conf#, a service which is not service jails ready needs two config lines. * Resource Efficiency: Service jails are more resource efficient than thin jails, as they do not need any additional disk space or network resource. * Faster Deployment: Creating and launching service jails is generally faster compared to thin jails if only distinct services/daemons shall be jailed and no parallel instances of the same service/daemon is needed. -* Shared Resources: Service jails share all resources such as libraries and binaries with the host system. This can potentially lead to more efficient disk caching and improved performance for applications within the jail. +* Shared Resources: Service jails share all resources such as libraries and binaries with the host system. +This can potentially lead to more efficient disk caching and improved performance for applications within the jail. * Process Isolation: Service jails isolate a particular service, it can not see processes which are not a child of the service jail, even if they run within the same user account. Disadvantages of Service Jails: @@ -160,7 +168,8 @@ * Security Concerns: The reduced isolation in service jails could pose security risks, as a compromise in one jail might have a greater potential to affect everything on the host system. Most of the configuration of jails which is discussed below is not needed for service jails. -To understand how jails work, it is recommended to understand those configuration possibilities. The details about what is needed to configure a service jail is in crossref:jails[service-jails-config, Configuring service jails]. +To understand how jails work, it is recommended to understand those configuration possibilities. +The details about what is needed to configure a service jail is in crossref:jails[service-jails-config, Configuring service jails]. [[vnet-jails]] === VNET Jails @@ -217,7 +226,7 @@ Host Networking Mode (IP Sharing):: In host networking mode, a jail shares the same networking stack as the host system. When a jail is created in host networking mode it uses the same network interface and IP address. -This means that the jail doesn't have a separate IP address, and its network traffic is associated with the host's IP. +This means that the jail does not have a separate IP address, and its network traffic is associated with the host's IP. Virtual Networks (VNET):: Virtual Networks are a feature of FreeBSD jails that offer more advanced and flexible networking solutions than a basic networking mode like host networking. @@ -312,17 +321,28 @@ .... <.> `jailname` - Name of the jail. -<.> `exec.start` - Command(s) to run in the jail environment when a jail is created. A typical command to run is "/bin/sh /etc/rc". -<.> `exec.stop` - Command(s) to run in the jail environment before a jail is removed. A typical command to run is "/bin/sh /etc/rc.shutdown". +<.> `exec.start` - Command(s) to run in the jail environment when a jail is created. +A typical command to run is "/bin/sh /etc/rc". +<.> `exec.stop` - Command(s) to run in the jail environment before a jail is removed. +A typical command to run is "/bin/sh /etc/rc.shutdown". <.> `exec.consolelog` - A file to direct command output (stdout and stderr) to. -<.> `allow.raw_sockets` - Allow creating raw sockets inside the jail. Setting this parameter allows utilities like man:ping[8] and man:traceroute[8] to operate inside the jail. +<.> `allow.raw_sockets` - Allow creating raw sockets inside the jail. +Setting this parameter allows utilities like man:ping[8] and man:traceroute[8] to operate inside the jail. <.> `exec.clean` - Run commands in a clean environment. <.> `mount.devfs` - Mount a man:devfs[5] filesystem on the chrooted [.filename]#/dev# directory, and apply the ruleset in the devfs_ruleset parameter to restrict the devices visible inside the jail. <.> `host.hostname` - The hostname of the jail. -<.> `path` - The directory which is to be the root of the jail. Any commands that are run inside the jail, either by jail or from man:jexec[8], are run from this directory. -<.> `ip4.addr` - IPv4 address. There are two configuration possibilities for IPv4. The first is to establish an IP or a list of IPs as has been done in the example. The other is to use `ip4` instead and set the `inherit` value to inherit the host's IP address. -<.> `ip6.addr` - IPv6 address. There are two configuration possibilities for IPv6. The first is to establish an IP or a list of IPs as has been done in the example. The other is to use `ip6` instead and set the `inherit` value to inherit the host's IP address. -<.> `interface` - A network interface to add the jail's IP addresses. Usually the host interface. +<.> `path` - The directory which is to be the root of the jail. +Any commands that are run inside the jail, either by jail or from man:jexec[8], are run from this directory. +<.> `ip4.addr` - IPv4 address. +There are two configuration possibilities for IPv4. +The first is to establish an IP or a list of IPs as has been done in the example. +The other is to use `ip4` instead and set the `inherit` value to inherit the host's IP address. +<.> `ip6.addr` - IPv6 address. +There are two configuration possibilities for IPv6. +The first is to establish an IP or a list of IPs as has been done in the example. +The other is to use `ip6` instead and set the `inherit` value to inherit the host's IP address. +<.> `interface` - A network interface to add the jail's IP addresses. +Usually the host interface. More information about configuration variables can be found in man:jail[8] and man:jail.conf[5]. @@ -915,7 +935,7 @@ # grep _svcj_options /path/to/rc.d/servicename .... -If there is no output, the service is not service jail ready, or does not need any additional privileges like e.g. network access. +If there is no output, the service is not service jail ready, or does not need any additional privileges like for example, network access. If the service is not service jail ready, and needs network access, it can be made ready by adding the necessary config to [.filename]#/etc/rc.conf#: @@ -1156,7 +1176,7 @@ Controlling the resources that a jail uses from the host system is a task to be taken into account by the system administrator. -man:rctl[8] allows you to manage the resources that a jail can use from the host system. +Use man:rctl[8] to manage the resources that a jail can use from the host system. [TIP] ====