From be58a3f595b5996bed20a8cc7891767eb6429209 Mon Sep 17 00:00:00 2001 From: tschettervictor Date: Sun, 16 Nov 2025 14:10:27 -0700 Subject: [PATCH] doc updates --- docs/chapters/comparing.rst | 3 +- docs/chapters/configuration.rst | 301 +++++++++++++++++++ docs/chapters/getting-started.rst | 6 +- docs/chapters/jail-config.rst | 197 ------------ docs/chapters/jail-startup-configuration.rst | 90 ------ docs/chapters/upgrading.rst | 2 +- docs/index.rst | 2 - usr/local/share/bastille/cmd.sh | 4 +- usr/local/share/bastille/migrate.sh | 1 - usr/local/share/bastille/pkg.sh | 4 +- usr/local/share/bastille/rcp.sh | 2 - usr/local/share/bastille/service.sh | 4 +- usr/local/share/bastille/sysrc.sh | 4 +- usr/local/share/bastille/umount.sh | 4 +- usr/local/share/bastille/verify.sh | 2 - 15 files changed, 311 insertions(+), 315 deletions(-) delete mode 100644 docs/chapters/jail-config.rst delete mode 100644 docs/chapters/jail-startup-configuration.rst diff --git a/docs/chapters/comparing.rst b/docs/chapters/comparing.rst index 703558c4..31d54fef 100644 --- a/docs/chapters/comparing.rst +++ b/docs/chapters/comparing.rst @@ -18,8 +18,7 @@ as a list of popular managers and their status on each option. | | Shell | Shell, C | Shell, | Shell | Shell, | | | | | Rust | | Python | +--------------+-------------+--------------+-----------+-----------+-----------+ -| Dep | None | C | Rust | None | Python | -|endencies | | | | | | +| Dependencies | None | C | Rust | None | Python | +--------------+-------------+--------------+-----------+-----------+-----------+ | Jail | vnet, | clone, | thick | basejail | clone, | | Types | bridged | copy, | | | basejail, | diff --git a/docs/chapters/configuration.rst b/docs/chapters/configuration.rst index b0d91975..234f1fa7 100644 --- a/docs/chapters/configuration.rst +++ b/docs/chapters/configuration.rst @@ -126,3 +126,304 @@ environment or user. Then, it can be used in a couple of ways. - If you use sudo, you will need to run it with ``sudo -E bastille bootstrap...`` to preserve your users environment. This can also be persisted by editing the sudoers file. - If you do set the ``BASTILLE_CONFIG`` variable, you do not need to specify the config file when running Bastille as that specified user. + +Note: FreeBSD introduced container technology twenty years ago, long before the +industry standardized on the term "container". Internally, FreeBSD refers to +these containers as "jails". + +Jail Startup Configuration +-------------------------- + +Bastille can start jails on system startup, and stop them on system shutdown. +To enable this functionality, we must first enable Bastille as a service using +``sysrc bastille_enable=YES``. Once you reboot your host, all jails with +``boot=on`` will be started when the host boots. + +If you have certain jails that must be started before other jails, you can use +the priority option. Jails will start in order starting at the lowest value, and +will stop in order starting at the highest value. So, jails with a priority value +of 1 will start first, and stop last. + +See :doc:`Targeting `for more info. + +Boot +^^^^ + +The boot setting controls whether a jail will be started on system startup. If +you have enabled bastille with ``sysrc bastille_enable=YES``, all jails with +``boot=on`` will start on system startup. Any jail(s) with ``boot=off`` will not +be started on system startup. + +By default, when jails are created with Bastille, the boot setting is set to ``on`` +by default. This can be overridden using the ``--no-boot`` flag. +See ``bastille create --no-boot TARGET...``. + +You can also use ``bastille start --boot TARGET`` to make Bastille respect the +boot setting. If ``-b|--boot`` is not used, the targeted jail(s) will start, +regardless of the boot setting. + +Jails will still shut down on system shutdown, regardless of this setting. + +The ``-b|--boot`` can also be used with the ``stop`` command. Any jails with +``boot=off`` will not be touched if ``stop`` is called with ``-b|--boot``. Same +goes for the ``restart`` command. + +This value can be changed using ``bastille config TARGET set boot [on|off]``. + +This value will be shown using ``bastille list all``. + +Depend +^^^^^^ + +Bastille supports configuring jails to depend on each other when started and +stopped. If jail1 "depends" on jail2, then jail2 will be started if it is not +running when ``bastille start jail1`` is called. Any jail that jail1 "depends" +on will first be verified running (started if stopped) before jail1 is started. + +For example, I have 3 jails called nginx, mariadb and nextcloud. I want to +ensure that nginx and mariadb are running before nextcloud is started. + +First we must add both jails to nextcloud's depend property with +``bastille config nextcloud set depend "mariadb nginx"``. +Then, when we start nextcloud with ``bastille start nextcloud`` it will verify +that nginx and mariadb are running (start if stopped) before starting nextcloud. + +When stopping a jail, any jail that "depends" on it will first be stopped. +For example, if we run ``bastille stop nginx``, then nextcloud will first be +stopped because it "depends" on nginx. + +Note that if we do a ``bastille restart nginx``, however, nextcloud will be +stopped, because it "depends" on nginx, but will not be started again, because +the jail we just restarted, nginx, does not depend on nextcloud. + +Parallel Startup +^^^^^^^^^^^^^^^^ + +Bastille supports starting, stopping and restarting jails in parallel mode using +the ``rc`` service script. To enable this functionality, set +``bastille_parallel_limit`` to a numeric value. + +For example, if you run ``sysrc bastille_parallel_limit=4``, then Bastille will +start 4 jails at a time on system startup, as well as stop or restart 4 jails at +a time when ``service bastille...`` is called. + +This value is set to 1 by default, to only start/stop/restart jails one at a time. + +Startup Delay +^^^^^^^^^^^^^ + +Sometimes it is necessary to let a jail start fully before continuing to the +next jail. + +We can do this with another sysrc value called ``bastille_startup_delay``. +Setting ``bastille_startup_delay=5`` will tell Bastille to wait 5 seconds between +starting each jail. + +You can also use ``bastille start -d|--delay 5 all`` or +``bastille restart -d|--delay 5 all`` to achieve the same thing. + +jail.conf +--------- + +In this section we'll look at the default config for a new container. The +defaults are sane for most applications, but if you want to tweak the settings +here they are. + +A ``jail.conf`` template is used each time a new container is created. This +template looks like this: + +.. code-block:: shell + + {name} { + devfs_ruleset = 4; + enforce_statfs = 2; + exec.clean; + exec.consolelog = /var/log/bastille/{name}_console.log; + exec.start = '/bin/sh /etc/rc'; + exec.stop = '/bin/sh /etc/rc.shutdown'; + host.hostname = {name}; + interface = {interface}; + mount.devfs; + mount.fstab = /usr/local/bastille/jails/{name}/fstab; + path = /usr/local/bastille/jails/{name}/root; + securelevel = 2; + + ip4.addr = interface|x.x.x.x; + ip6 = disable; + } + + +devfs_ruleset +^^^^^^^^^^^^^ + +.. code-block:: shell + + devfs_ruleset + The number of the devfs ruleset that is enforced for mounting + devfs in this jail. A value of zero (default) means no ruleset + is enforced. Descendant jails inherit the parent jail's devfs + ruleset enforcement. Mounting devfs inside a jail is possible + only if the allow.mount and allow.mount.devfs permissions are + effective and enforce_statfs is set to a value lower than 2. + Devfs rules and rulesets cannot be viewed or modified from inside + a jail. + + NOTE: It is important that only appropriate device nodes in devfs + be exposed to a jail; access to disk devices in the jail may + permit processes in the jail to bypass the jail sandboxing by + modifying files outside of the jail. See devfs(8) for + information on how to use devfs rules to limit access to entries + in the per-jail devfs. A simple devfs ruleset for jails is + available as ruleset #4 in /etc/defaults/devfs.rules. + + +enforce_statfs +^^^^^^^^^^^^^^ + +.. code-block:: shell + + enforce_statfs + This determines what information processes in a jail are able to + get about mount points. It affects the behaviour of the + following syscalls: statfs(2), fstatfs(2), getfsstat(2), and + fhstatfs(2) (as well as similar compatibility syscalls). When + set to 0, all mount points are available without any + restrictions. When set to 1, only mount points below the jail's + chroot directory are visible. In addition to that, the path to + the jail's chroot directory is removed from the front of their + pathnames. When set to 2 (default), above syscalls can operate + only on a mount-point where the jail's chroot directory is + located. + + +exec.clean +^^^^^^^^^^ + +.. code-block:: shell + + exec.clean + Run commands in a clean environment. The environment is + discarded except for HOME, SHELL, TERM and USER. HOME and SHELL + are set to the target login's default values. USER is set to the + target login. TERM is imported from the current environment. + The environment variables from the login class capability + database for the target login are also set. + + +exec.consolelog +^^^^^^^^^^^^^^^ + +.. code-block:: shell + + exec.consolelog + A file to direct command output (stdout and stderr) to. + + +exec.start +^^^^^^^^^^ + +.. code-block:: shell + + exec.start + Command(s) to run in the jail environment when a jail is created. + A typical command to run is "sh /etc/rc". + + +exec.stop +^^^^^^^^^ + +.. code-block:: shell + + exec.stop + Command(s) to run in the jail environment before a jail is + removed, and after any exec.prestop commands have completed. A + typical command to run is "sh /etc/rc.shutdown". + + +host.hostname +^^^^^^^^^^^^^ + +.. code-block:: shell + + host.hostname + The hostname of the jail. Other similar parameters are + host.domainname, host.hostuuid and host.hostid. + + +mount.devfs +^^^^^^^^^^^ + +.. code-block:: shell + + mount.devfs + Mount a devfs(5) filesystem on the chrooted /dev directory, and + apply the ruleset in the devfs_ruleset parameter (or a default of + ruleset 4: devfsrules_jail) to restrict the devices visible + inside the jail. + + +mount.fstab +^^^^^^^^^^^ + +.. code-block:: shell + + mount.fstab + An fstab(5) format file containing filesystems to mount before + creating a jail. + + +path +^^^^ + +.. code-block:: shell + + path + The directory which is to be the root of the jail. Any commands + run inside the jail, either by jail or from jexec(8), are run + from this directory. + + +securelevel +^^^^^^^^^^^ + +By default, Bastille containers run at ``securelevel = 2;``. See below for the +implications of kernel security levels and when they might be altered. + +Note: Bastille does not currently have any mechanism to automagically change +securelevel settings. My recommendation is this only be altered manually on a +case-by-case basis and that "Highly secure mode" is a sane default for most use +cases. + +.. code-block:: shell + + The kernel runs with five different security levels. Any super-user + process can raise the level, but no process can lower it. The security + levels are: + + -1 Permanently insecure mode - always run the system in insecure mode. + This is the default initial value. + + 0 Insecure mode - immutable and append-only flags may be turned off. + All devices may be read or written subject to their permissions. + + 1 Secure mode - the system immutable and system append-only flags may + not be turned off; disks for mounted file systems, /dev/mem and + /dev/kmem may not be opened for writing; /dev/io (if your platform + has it) may not be opened at all; kernel modules (see kld(4)) may + not be loaded or unloaded. The kernel debugger may not be entered + using the debug.kdb.enter sysctl. A panic or trap cannot be forced + using the debug.kdb.panic and other sysctl's. + + 2 Highly secure mode - same as secure mode, plus disks may not be + opened for writing (except by mount(2)) whether mounted or not. + This level precludes tampering with file systems by unmounting + them, but also inhibits running newfs(8) while the system is multi- + user. + + In addition, kernel time changes are restricted to less than or + equal to one second. Attempts to change the time by more than this + will log the message "Time adjustment clamped to +1 second". + + 3 Network secure mode - same as highly secure mode, plus IP packet + filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be + changed and dummynet(4) or pf(4) configuration cannot be adjusted. diff --git a/docs/chapters/getting-started.rst b/docs/chapters/getting-started.rst index d80cbe2c..d730b566 100644 --- a/docs/chapters/getting-started.rst +++ b/docs/chapters/getting-started.rst @@ -18,7 +18,7 @@ enabled, otherwise UFS) and the ``pf`` firewall. Alternatively, you can run ``bastille setup OPTION`` command with any of the supported options to configure the selected option by itself. -To see a list of available options, see the ``setup`` subcommand. +To see a list of available options, see the :doc:`/chapters/subcommands/setup` subcommand. .. code-block:: shell @@ -57,7 +57,7 @@ There are a few different types of jails we can create, described below. you are doing. Created with the ``--empty|-E`` option. * Linux jails are jails that run linux. Created with the ``--linux|-L`` option. - See :doc:`Linux Jails `. + See :doc:`/chapters/linux-jails`. We will focus on thin jails for this guide. @@ -78,7 +78,7 @@ To be able to reach a service inside the jail, use ``bastille rdr``. ishmael ~ # bastille rdr nextcloud tcp 80 80 This will forward traffic from port 80 on the host to port 80 inside the jail. -See also :doc:`rdr `. +See also :doc:`/chapters/subcommands/rdr`. VNET Jail ^^^^^^^^^ diff --git a/docs/chapters/jail-config.rst b/docs/chapters/jail-config.rst deleted file mode 100644 index 8b15029b..00000000 --- a/docs/chapters/jail-config.rst +++ /dev/null @@ -1,197 +0,0 @@ -Note: FreeBSD introduced container technology twenty years ago, long before the -industry standardized on the term "container". Internally, FreeBSD refers to -these containers as "jails". - -jail.conf -========= -In this section we'll look at the default config for a new container. The -defaults are sane for most applications, but if you want to tweak the settings -here they are. - -A ``jail.conf`` template is used each time a new container is created. This -template looks like this: - -.. code-block:: shell - - {name} { - devfs_ruleset = 4; - enforce_statfs = 2; - exec.clean; - exec.consolelog = /var/log/bastille/{name}_console.log; - exec.start = '/bin/sh /etc/rc'; - exec.stop = '/bin/sh /etc/rc.shutdown'; - host.hostname = {name}; - interface = {interface}; - mount.devfs; - mount.fstab = /usr/local/bastille/jails/{name}/fstab; - path = /usr/local/bastille/jails/{name}/root; - securelevel = 2; - - ip4.addr = interface|x.x.x.x; - ip6 = disable; - } - - -devfs_ruleset -------------- -.. code-block:: shell - - devfs_ruleset - The number of the devfs ruleset that is enforced for mounting - devfs in this jail. A value of zero (default) means no ruleset - is enforced. Descendant jails inherit the parent jail's devfs - ruleset enforcement. Mounting devfs inside a jail is possible - only if the allow.mount and allow.mount.devfs permissions are - effective and enforce_statfs is set to a value lower than 2. - Devfs rules and rulesets cannot be viewed or modified from inside - a jail. - - NOTE: It is important that only appropriate device nodes in devfs - be exposed to a jail; access to disk devices in the jail may - permit processes in the jail to bypass the jail sandboxing by - modifying files outside of the jail. See devfs(8) for - information on how to use devfs rules to limit access to entries - in the per-jail devfs. A simple devfs ruleset for jails is - available as ruleset #4 in /etc/defaults/devfs.rules. - - -enforce_statfs --------------- -.. code-block:: shell - - enforce_statfs - This determines what information processes in a jail are able to - get about mount points. It affects the behaviour of the - following syscalls: statfs(2), fstatfs(2), getfsstat(2), and - fhstatfs(2) (as well as similar compatibility syscalls). When - set to 0, all mount points are available without any - restrictions. When set to 1, only mount points below the jail's - chroot directory are visible. In addition to that, the path to - the jail's chroot directory is removed from the front of their - pathnames. When set to 2 (default), above syscalls can operate - only on a mount-point where the jail's chroot directory is - located. - - -exec.clean ----------- -.. code-block:: shell - - exec.clean - Run commands in a clean environment. The environment is - discarded except for HOME, SHELL, TERM and USER. HOME and SHELL - are set to the target login's default values. USER is set to the - target login. TERM is imported from the current environment. - The environment variables from the login class capability - database for the target login are also set. - - -exec.consolelog ---------------- -.. code-block:: shell - - exec.consolelog - A file to direct command output (stdout and stderr) to. - - -exec.start ----------- -.. code-block:: shell - - exec.start - Command(s) to run in the jail environment when a jail is created. - A typical command to run is "sh /etc/rc". - - -exec.stop ---------- -.. code-block:: shell - - exec.stop - Command(s) to run in the jail environment before a jail is - removed, and after any exec.prestop commands have completed. A - typical command to run is "sh /etc/rc.shutdown". - - -host.hostname -------------- -.. code-block:: shell - - host.hostname - The hostname of the jail. Other similar parameters are - host.domainname, host.hostuuid and host.hostid. - - -mount.devfs ------------ -.. code-block:: shell - - mount.devfs - Mount a devfs(5) filesystem on the chrooted /dev directory, and - apply the ruleset in the devfs_ruleset parameter (or a default of - ruleset 4: devfsrules_jail) to restrict the devices visible - inside the jail. - - -mount.fstab ------------ -.. code-block:: shell - - mount.fstab - An fstab(5) format file containing filesystems to mount before - creating a jail. - - -path ----- -.. code-block:: shell - - path - The directory which is to be the root of the jail. Any commands - run inside the jail, either by jail or from jexec(8), are run - from this directory. - - -securelevel ------------ -By default, Bastille containers run at ``securelevel = 2;``. See below for the -implications of kernel security levels and when they might be altered. - -Note: Bastille does not currently have any mechanism to automagically change -securelevel settings. My recommendation is this only be altered manually on a -case-by-case basis and that "Highly secure mode" is a sane default for most use -cases. - -.. code-block:: shell - - The kernel runs with five different security levels. Any super-user - process can raise the level, but no process can lower it. The security - levels are: - - -1 Permanently insecure mode - always run the system in insecure mode. - This is the default initial value. - - 0 Insecure mode - immutable and append-only flags may be turned off. - All devices may be read or written subject to their permissions. - - 1 Secure mode - the system immutable and system append-only flags may - not be turned off; disks for mounted file systems, /dev/mem and - /dev/kmem may not be opened for writing; /dev/io (if your platform - has it) may not be opened at all; kernel modules (see kld(4)) may - not be loaded or unloaded. The kernel debugger may not be entered - using the debug.kdb.enter sysctl. A panic or trap cannot be forced - using the debug.kdb.panic and other sysctl's. - - 2 Highly secure mode - same as secure mode, plus disks may not be - opened for writing (except by mount(2)) whether mounted or not. - This level precludes tampering with file systems by unmounting - them, but also inhibits running newfs(8) while the system is multi- - user. - - In addition, kernel time changes are restricted to less than or - equal to one second. Attempts to change the time by more than this - will log the message "Time adjustment clamped to +1 second". - - 3 Network secure mode - same as highly secure mode, plus IP packet - filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be - changed and dummynet(4) or pf(4) configuration cannot be adjusted. diff --git a/docs/chapters/jail-startup-configuration.rst b/docs/chapters/jail-startup-configuration.rst deleted file mode 100644 index 92f58339..00000000 --- a/docs/chapters/jail-startup-configuration.rst +++ /dev/null @@ -1,90 +0,0 @@ -Jail Startup Configuration -========================== - -Bastille can start jails on system startup, and stop them on system shutdown. -To enable this functionality, we must first enable Bastille as a service using -``sysrc bastille_enable=YES``. Once you reboot your host, all jails with -``boot=on`` will be started when the host boots. - -If you have certain jails that must be started before other jails, you can use -the priority option. Jails will start in order starting at the lowest value, and -will stop in order starting at the highest value. So, jails with a priority value -of 1 will start first, and stop last. - -See :doc:`Targeting `for more info. - -Boot ----- - -The boot setting controls whether a jail will be started on system startup. If -you have enabled bastille with ``sysrc bastille_enable=YES``, all jails with -``boot=on`` will start on system startup. Any jail(s) with ``boot=off`` will not -be started on system startup. - -By default, when jails are created with Bastille, the boot setting is set to ``on`` -by default. This can be overridden using the ``--no-boot`` flag. -See ``bastille create --no-boot TARGET...``. - -You can also use ``bastille start --boot TARGET`` to make Bastille respect the -boot setting. If ``-b|--boot`` is not used, the targeted jail(s) will start, -regardless of the boot setting. - -Jails will still shut down on system shutdown, regardless of this setting. - -The ``-b|--boot`` can also be used with the ``stop`` command. Any jails with -``boot=off`` will not be touched if ``stop`` is called with ``-b|--boot``. Same -goes for the ``restart`` command. - -This value can be changed using ``bastille config TARGET set boot [on|off]``. - -This value will be shown using ``bastille list all``. - -Depend ------- - -Bastille supports configuring jails to depend on each other when started and -stopped. If jail1 "depends" on jail2, then jail2 will be started if it is not -running when ``bastille start jail1`` is called. Any jail that jail1 "depends" -on will first be verified running (started if stopped) before jail1 is started. - -For example, I have 3 jails called nginx, mariadb and nextcloud. I want to -ensure that nginx and mariadb are running before nextcloud is started. - -First we must add both jails to nextcloud's depend property with -``bastille config nextcloud set depend "mariadb nginx"``. -Then, when we start nextcloud with ``bastille start nextcloud`` it will verify -that nginx and mariadb are running (start if stopped) before starting nextcloud. - -When stopping a jail, any jail that "depends" on it will first be stopped. -For example, if we run ``bastille stop nginx``, then nextcloud will first be -stopped because it "depends" on nginx. - -Note that if we do a ``bastille restart nginx``, however, nextcloud will be -stopped, because it "depends" on nginx, but will not be started again, because -the jail we just restarted, nginx, does not depend on nextcloud. - -Parallel Startup ----------------- - -Bastille supports starting, stopping and restarting jails in parallel mode using -the ``rc`` service script. To enable this functionality, set -``bastille_parallel_limit`` to a numeric value. - -For example, if you run ``sysrc bastille_parallel_limit=4``, then Bastille will -start 4 jails at a time on system startup, as well as stop or restart 4 jails at -a time when ``service bastille...`` is called. - -This value is set to 1 by default, to only start/stop/restart jails one at a time. - -Startup Delay -------------- - -Sometimes it is necessary to let a jail start fully before continuing to the -next jail. - -We can do this with another sysrc value called ``bastille_startup_delay``. -Setting ``bastille_startup_delay=5`` will tell Bastille to wait 5 seconds between -starting each jail. - -You can also use ``bastille start -d|--delay 5 all`` or -``bastille restart -d|--delay 5 all`` to achieve the same thing. diff --git a/docs/chapters/upgrading.rst b/docs/chapters/upgrading.rst index d7e3dc5a..a8e7544c 100644 --- a/docs/chapters/upgrading.rst +++ b/docs/chapters/upgrading.rst @@ -184,5 +184,5 @@ no longer need the option to revert the change you can destroy the old release. ``bastille destroy X.Y-RELEASE`` to fully delete the release, including the cache (cache is not used with pkgbase). -``bastille destroy [-c|--no-cache] X.Y-RELEASE`` to retain the cache directory +``bastille destroy -c|--no-cache X.Y-RELEASE`` to retain the cache directory (not supported when using pkgbase). diff --git a/docs/index.rst b/docs/index.rst index ac9857bb..476120ce 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -15,8 +15,6 @@ https://docs.bastillebsd.org. chapters/installation chapters/getting-started chapters/configuration - chapters/jail-config - chapters/jail-startup-configuration chapters/targeting chapters/subcommands/index chapters/usage diff --git a/usr/local/share/bastille/cmd.sh b/usr/local/share/bastille/cmd.sh index de003c68..806f8235 100644 --- a/usr/local/share/bastille/cmd.sh +++ b/usr/local/share/bastille/cmd.sh @@ -116,6 +116,4 @@ done if [ "${ERRORS}" -ne 0 ]; then error_exit "[ERROR]: Command failed on ${ERRORS} jails." -fi - -echo \ No newline at end of file +fi \ No newline at end of file diff --git a/usr/local/share/bastille/migrate.sh b/usr/local/share/bastille/migrate.sh index 54e2e007..e324555c 100644 --- a/usr/local/share/bastille/migrate.sh +++ b/usr/local/share/bastille/migrate.sh @@ -393,4 +393,3 @@ for _jail in ${JAILS}; do info "\nSuccessfully migrated '${_jail}' to '${HOST}'.\n" done -echo diff --git a/usr/local/share/bastille/pkg.sh b/usr/local/share/bastille/pkg.sh index 4f1675a2..09dfe8a0 100644 --- a/usr/local/share/bastille/pkg.sh +++ b/usr/local/share/bastille/pkg.sh @@ -142,6 +142,4 @@ done if [ "${ERRORS}" -ne 0 ]; then error_exit "[ERROR]: Command failed on ${ERRORS} jails." -fi - -echo \ No newline at end of file +fi \ No newline at end of file diff --git a/usr/local/share/bastille/rcp.sh b/usr/local/share/bastille/rcp.sh index e6cf297c..1a9eba3a 100644 --- a/usr/local/share/bastille/rcp.sh +++ b/usr/local/share/bastille/rcp.sh @@ -94,6 +94,4 @@ jail_path="$(echo ${bastille_jailsdir}/${TARGET}/root/${JAIL_PATH} | sed 's#//#/ if ! cp "${OPTION}" "${jail_path}" "${host_path}"; then error_exit "[ERROR]: RCP failed: ${jail_path} -> ${host_path}" -else - echo fi \ No newline at end of file diff --git a/usr/local/share/bastille/service.sh b/usr/local/share/bastille/service.sh index a63dd780..ee1c9632 100644 --- a/usr/local/share/bastille/service.sh +++ b/usr/local/share/bastille/service.sh @@ -110,6 +110,4 @@ done if [ "${ERRORS}" -ne 0 ]; then error_exit "[ERROR]: Command failed on ${ERRORS} jails." -fi - -echo \ No newline at end of file +fi \ No newline at end of file diff --git a/usr/local/share/bastille/sysrc.sh b/usr/local/share/bastille/sysrc.sh index 1cd25325..da7e0f74 100644 --- a/usr/local/share/bastille/sysrc.sh +++ b/usr/local/share/bastille/sysrc.sh @@ -110,6 +110,4 @@ done if [ "${ERRORS}" -ne 0 ]; then error_exit "[ERROR]: Command failed on ${ERRORS} jails." -fi - -echo \ No newline at end of file +fi \ No newline at end of file diff --git a/usr/local/share/bastille/umount.sh b/usr/local/share/bastille/umount.sh index 7a20812b..4cd7ec1e 100644 --- a/usr/local/share/bastille/umount.sh +++ b/usr/local/share/bastille/umount.sh @@ -128,6 +128,4 @@ for _jail in ${JAILS}; do echo "Unmounted: ${_jailpath}" -done - -echo \ No newline at end of file +done \ No newline at end of file diff --git a/usr/local/share/bastille/verify.sh b/usr/local/share/bastille/verify.sh index a27f0a52..c8d34daf 100644 --- a/usr/local/share/bastille/verify.sh +++ b/usr/local/share/bastille/verify.sh @@ -195,5 +195,3 @@ case "${1}" in usage ;; esac - -echo