ybox 0.9.8.1__tar.gz → 0.9.11__tar.gz

{ybox-0.9.8.1/src/ybox.egg-info → ybox-0.9.11}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.2
+Metadata-Version: 2.4
 Name: ybox
-Version: 0.9.8.1
+Version: 0.9.11
 Summary: Securely run Linux distribution inside a container
 Author-email: Sumedh Wale <sumwale@yahoo.com>, Vishal Rao <vishalrao@gmail.com>
 License: Copyright (c) 2024-2025 Sumedh Wale and contributors
@@ -25,7 +25,7 @@ License: Copyright (c) 2024-2025 Sumedh Wale and contributors
         
 Project-URL: Homepage, https://github.com/sumwale/ybox
 Project-URL: Issues, https://github.com/sumwale/ybox/issues
-Keywords: Linux in container,toolbox
+Keywords: Linux in container,toolbox,distrobox
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: End Users/Desktop
 Classifier: License :: OSI Approved :: MIT License
@@ -35,12 +35,14 @@ Classifier: Programming Language :: Python :: 3.9
 Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.9
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: packaging
 Requires-Dist: simple-term-menu
 Requires-Dist: tabulate>=0.9.0
+Dynamic: license-file
 
 ## Introduction
 
@@ -54,7 +56,17 @@ of the container including directories to be shared, logging etc.
 
 Special emphasis is given on security where users can choose to lock down
 or open up the container as required with reasonable defaults out of the
-box. There is no sharing of HOME or no privileged mode container.
+box. There is no sharing of HOME or no privileged mode container. This sets
+it apart from other similar solutions like distrobox/toolbx and the reason
+for starting this project since those other solutions don't care about
+security/sandboxing at all and share the entire HOME while running the
+containers in privileged mode. The other problem with those solutions is that
+the shared HOME means that the user's configuration dot files also get shared
+and can cause all kinds of trouble where container apps can overwrite
+with their own versions (especially for updated apps in the containers)
+breaking the app in the host system. It is, however, possible to share the
+entire HOME if user really wants but that needs to be explcitly configured
+in the ini profile.
 
 Expected usage is for users to group similar applications in a container
 and separate out containers depending on different needs like higher/lower
@@ -88,7 +100,7 @@ So, for example, if you want to run the latest and greatest Intellij IDEA commun
 to do is:
 
 ```sh
-# create an Arch Linux based container
+# create an Arch Linux based container and generate systemd service file (if possible)
 ybox-create arch
 # then select an appropriate built-in profile e.g. "dev.ini" from the menu
 
@@ -144,10 +156,11 @@ require you to install in a custom virtual environment which can be done manuall
  fish: `python3 -m venv ybox-venv && source ybox-env/bin/activate.fish`)
 or automatically using `pipx`. Alternatively you can add `--break-system-packages`
 flag to the `pip` command above or add it globally for all future packages using
-`python3 -m pip config set global.break-system-packages true`. The alternative
-approach works well for `ybox` which has a very minimal set of dependencies but
-in the rare case you see any issues due to package conflicts, use `pipx` or
-manual virtual environment.
+`python3 -m pip config set global.break-system-packages true`. This alternative
+approach works well for `ybox` which has a very minimal set of dependencies which will
+not conflict with system packages (rather work with whatever system version is installed),
+but if you prefer keeping the installation separate then use `pipx` or
+a manual virtual environment.
 
 Now you can run the `ybox-create` and other utilities that are normally installed
 in your `~/.local/bin` directory which should be in PATH for modern Linux distributions.
@@ -185,6 +198,8 @@ to point to the full path of the podman or docker executable.
 ybox-create
 ```
 
+By default this will also generate a user systemd service if possible (add `-S` or
+  `--skip-systemd-service` option to skip creation of a user systemd service).
 This will allow choosing from supported distributions, then from the available profiles.
 You can start with the Arch Linux distribution and `apps.ini` profile to try it out. The container
 will have a name like `ybox-<distribution>_<profile>` by default like `ybox-arch_apps` for the
@@ -209,7 +224,9 @@ does not run properly as root, then you cannot run it when using docker unless y
 `sudo/su` to the host user in the container command. However, running as host user when running
 rootless docker will map to a different user ID in the host (as specified in `/etc/subuid` on the
 host) so files shared with the host, including devices like those in `/dev/dri`, will cause
-permission issues that can hinder or break the application.
+permission issues that can hinder or break the application. Hence it is recommended to
+just install podman (even if you already have docker installed) which works out of the
+box in rootless mode in all tested distributions.
 
 
 ### Package management: install/uninstall/list/search/...
@@ -255,7 +272,7 @@ ybox-pkg list -o
 ```
 To show more details of the packages (combine with -a/-o as required):
 ```sh
-ybox-pkg list -o
+ybox-pkg list -v
 ```
 
 List all the files installed by the package:
@@ -295,6 +312,8 @@ Clean package cache, temporary downloads etc:
 ```sh
 ybox-pkg clean
 ```
+Add `-q` option to answer yes for any questions automatically if all your containers use
+the same shared root.
 
 Mark a package as explicitly installed (also registers with `ybox-pkg` if not present):
 ```sh
@@ -303,7 +322,7 @@ ybox-pkg mark firefox -e
 
 Mark a package as a dependency of another (also registers with `ybox-pkg` if not present):
 ```sh
-ybox-pkg mark qt5ct -D zoom  # mark qt5ct as an optional dependency of zoom
+ybox-pkg mark qt5ct -d zoom  # mark qt5ct as an optional dependency of zoom
 ```
 
 Repair package installation after a failure or interrupt:
@@ -342,10 +361,10 @@ ybox-destroy ybox-arch_apps
 ```
 
 Will destroy the `apps` container created in the example before. This does not delete the
-$HOME files, nor does it delete the shared root directory (if enabled). Hence, if you create
+`$HOME` files, nor does it delete the shared root directory (if enabled). Hence, if you create
 a new container having the same shared root, then it will inherit everything installed
 previously. Likewise, if you create the container with the same profile again, then it
-will also have the $HOME as before if you do not explicitly delete the directories
+will also have the `$HOME` as before if you do not explicitly delete the directories
 in `~/.local/share/ybox`.
 
 
@@ -374,10 +393,10 @@ ybox-cmd ybox-arch_apps -- ls -l
 ```
 
 The default profiles also link the .bashrc and starship configuration files from your host
-$HOME directory by default, so you should see the same bash shell configuration as in your
+`$HOME` directory by default, so you should see the same bash shell configuration as in your
 host. These are linked in read-only mode, so if you want to change these auto-linked
 configuration files inside the container, then you will need to create a copy from the symlink
-first (but then it will lose the link from the host $HOME).
+first (but then it will lose the link from the host `$HOME`).
 
 A shell on a container will act like a native Linux distribution environment for most purposes.
 The one prominent missing thing is systemd which is not enabled deliberately since it requires
@@ -423,33 +442,39 @@ for a ybox container. See the full set of options with `ybox-control -h/--help`.
 ### Auto-starting containers
 
 Containers can be auto-started as per the usual way for rootless podman/docker services.
-This is triggered by systemd on user login which is exactly what we want for ybox
+This is triggered by systemd on user login which is exactly what is required for ybox
 containers so that the container applications are available on login and are stopped on
-session logout. For docker the following should suffice:
-
-```sh
-systemctl --user enable docker
-```
+session logout. All the tested Linux distributions support this and provide for user
+systemd daemon on user login.
 
-See [docker docs](https://docs.docker.com/engine/security/rootless/#daemon) for details.
+The `ybox-create` command  autogenerates the systemd service file (in absence of `-S` or
+  `--skip-systemd-service` option) which is also removed by `ybox-destroy` automatically.
+The name of the generated service is `ybox-<NAME>` where `<NAME>` is the name of the
+container if `<NAME>` does not start with `ybox-` prefix, else it is just `<NAME>`.
 
-For podman you will need to explicitly generate systemd service file for each container and
-copy to your systemd configuration directory since podman does not use a background daemon.
-For the `ybox-arch_apps` container in the examples before:
+With a user service installed, the `systemctl` commands can be used to control the
+ybox container (`<SERVICE_NAME>` is `ybox-<NAME>/<NAME>` mentioned above):
 
 ```sh
-mkdir -p ~/.config/systemd/user/
-podman generate systemd --name ybox-arch_apps > ~/.config/systemd/user/container-ybox-arch_apps.service
-systemctl --user enable container-ybox-arch_apps.service
+systemctl --user status <SERVICE_NAME>  # show status of the service
+systemctl --user stop <SERVICE_NAME>    # stop the service
+systemctl --user start <SERVICE_NAME>   # start the service
 ```
 
+If your Linux distribution does not use systemd, then the autostart has to be handled
+manually as per the distribution's preferred way. For instance an appropriate desktop
+file can be added to `~/.config/autostart` directory to start a ybox container on
+graphical login, though performing a clean stop can be hard with this approach.
+Note that the preferred way to start/stop a ybox container is using the `ybox-control`
+command rather than directly using podman/docker.
+
 
 ## Development
 
 Virtual environment setup have been provided for consistent development, test and build
 with multiple python versions. The minimum python version required is 3.9 and tests are
-run against all major python versions higher than that (i.e. 3.10, 3.11, 3.12 and others
-in future).
+run against all major python versions higher than that (i.e. 3.10, 3.11, 3.12, 3.13 and
+    others in future).
 
 The setup uses pyenv with venv which can be used for development with IDEA/PyCharm/VSCode
 or in terminal, running tests against all supported python versions using `tox` etc.
@@ -476,14 +501,23 @@ Next you can install the required python versions and venv environment:
 pyenv/setup-venv.sh
 ```
 
-Finally, you can activate it in bash/zsh:
+Finally, you can activate it.
+
+bash:
+
+```sh
+source pyenv/activate.bash
+source .venv/bin/activate
+```
+
+zsh:
 
 ```sh
-source pyenv/activate.sh
+source pyenv/activate.zsh
 source .venv/bin/activate
 ```
 
-Or in fish shell:
+fish:
 
 ```
 source pyenv/activate.fish

{ybox-0.9.8.1 → ybox-0.9.11}/README.md

@@ -10,7 +10,17 @@ of the container including directories to be shared, logging etc.
 
 Special emphasis is given on security where users can choose to lock down
 or open up the container as required with reasonable defaults out of the
-box. There is no sharing of HOME or no privileged mode container.
+box. There is no sharing of HOME or no privileged mode container. This sets
+it apart from other similar solutions like distrobox/toolbx and the reason
+for starting this project since those other solutions don't care about
+security/sandboxing at all and share the entire HOME while running the
+containers in privileged mode. The other problem with those solutions is that
+the shared HOME means that the user's configuration dot files also get shared
+and can cause all kinds of trouble where container apps can overwrite
+with their own versions (especially for updated apps in the containers)
+breaking the app in the host system. It is, however, possible to share the
+entire HOME if user really wants but that needs to be explcitly configured
+in the ini profile.
 
 Expected usage is for users to group similar applications in a container
 and separate out containers depending on different needs like higher/lower
@@ -44,7 +54,7 @@ So, for example, if you want to run the latest and greatest Intellij IDEA commun
 to do is:
 
 ```sh
-# create an Arch Linux based container
+# create an Arch Linux based container and generate systemd service file (if possible)
 ybox-create arch
 # then select an appropriate built-in profile e.g. "dev.ini" from the menu
 
@@ -100,10 +110,11 @@ require you to install in a custom virtual environment which can be done manuall
  fish: `python3 -m venv ybox-venv && source ybox-env/bin/activate.fish`)
 or automatically using `pipx`. Alternatively you can add `--break-system-packages`
 flag to the `pip` command above or add it globally for all future packages using
-`python3 -m pip config set global.break-system-packages true`. The alternative
-approach works well for `ybox` which has a very minimal set of dependencies but
-in the rare case you see any issues due to package conflicts, use `pipx` or
-manual virtual environment.
+`python3 -m pip config set global.break-system-packages true`. This alternative
+approach works well for `ybox` which has a very minimal set of dependencies which will
+not conflict with system packages (rather work with whatever system version is installed),
+but if you prefer keeping the installation separate then use `pipx` or
+a manual virtual environment.
 
 Now you can run the `ybox-create` and other utilities that are normally installed
 in your `~/.local/bin` directory which should be in PATH for modern Linux distributions.
@@ -141,6 +152,8 @@ to point to the full path of the podman or docker executable.
 ybox-create
 ```
 
+By default this will also generate a user systemd service if possible (add `-S` or
+  `--skip-systemd-service` option to skip creation of a user systemd service).
 This will allow choosing from supported distributions, then from the available profiles.
 You can start with the Arch Linux distribution and `apps.ini` profile to try it out. The container
 will have a name like `ybox-<distribution>_<profile>` by default like `ybox-arch_apps` for the
@@ -165,7 +178,9 @@ does not run properly as root, then you cannot run it when using docker unless y
 `sudo/su` to the host user in the container command. However, running as host user when running
 rootless docker will map to a different user ID in the host (as specified in `/etc/subuid` on the
 host) so files shared with the host, including devices like those in `/dev/dri`, will cause
-permission issues that can hinder or break the application.
+permission issues that can hinder or break the application. Hence it is recommended to
+just install podman (even if you already have docker installed) which works out of the
+box in rootless mode in all tested distributions.
 
 
 ### Package management: install/uninstall/list/search/...
@@ -211,7 +226,7 @@ ybox-pkg list -o
 ```
 To show more details of the packages (combine with -a/-o as required):
 ```sh
-ybox-pkg list -o
+ybox-pkg list -v
 ```
 
 List all the files installed by the package:
@@ -251,6 +266,8 @@ Clean package cache, temporary downloads etc:
 ```sh
 ybox-pkg clean
 ```
+Add `-q` option to answer yes for any questions automatically if all your containers use
+the same shared root.
 
 Mark a package as explicitly installed (also registers with `ybox-pkg` if not present):
 ```sh
@@ -259,7 +276,7 @@ ybox-pkg mark firefox -e
 
 Mark a package as a dependency of another (also registers with `ybox-pkg` if not present):
 ```sh
-ybox-pkg mark qt5ct -D zoom  # mark qt5ct as an optional dependency of zoom
+ybox-pkg mark qt5ct -d zoom  # mark qt5ct as an optional dependency of zoom
 ```
 
 Repair package installation after a failure or interrupt:
@@ -298,10 +315,10 @@ ybox-destroy ybox-arch_apps
 ```
 
 Will destroy the `apps` container created in the example before. This does not delete the
-$HOME files, nor does it delete the shared root directory (if enabled). Hence, if you create
+`$HOME` files, nor does it delete the shared root directory (if enabled). Hence, if you create
 a new container having the same shared root, then it will inherit everything installed
 previously. Likewise, if you create the container with the same profile again, then it
-will also have the $HOME as before if you do not explicitly delete the directories
+will also have the `$HOME` as before if you do not explicitly delete the directories
 in `~/.local/share/ybox`.
 
 
@@ -330,10 +347,10 @@ ybox-cmd ybox-arch_apps -- ls -l
 ```
 
 The default profiles also link the .bashrc and starship configuration files from your host
-$HOME directory by default, so you should see the same bash shell configuration as in your
+`$HOME` directory by default, so you should see the same bash shell configuration as in your
 host. These are linked in read-only mode, so if you want to change these auto-linked
 configuration files inside the container, then you will need to create a copy from the symlink
-first (but then it will lose the link from the host $HOME).
+first (but then it will lose the link from the host `$HOME`).
 
 A shell on a container will act like a native Linux distribution environment for most purposes.
 The one prominent missing thing is systemd which is not enabled deliberately since it requires
@@ -379,33 +396,39 @@ for a ybox container. See the full set of options with `ybox-control -h/--help`.
 ### Auto-starting containers
 
 Containers can be auto-started as per the usual way for rootless podman/docker services.
-This is triggered by systemd on user login which is exactly what we want for ybox
+This is triggered by systemd on user login which is exactly what is required for ybox
 containers so that the container applications are available on login and are stopped on
-session logout. For docker the following should suffice:
-
-```sh
-systemctl --user enable docker
-```
+session logout. All the tested Linux distributions support this and provide for user
+systemd daemon on user login.
 
-See [docker docs](https://docs.docker.com/engine/security/rootless/#daemon) for details.
+The `ybox-create` command  autogenerates the systemd service file (in absence of `-S` or
+  `--skip-systemd-service` option) which is also removed by `ybox-destroy` automatically.
+The name of the generated service is `ybox-<NAME>` where `<NAME>` is the name of the
+container if `<NAME>` does not start with `ybox-` prefix, else it is just `<NAME>`.
 
-For podman you will need to explicitly generate systemd service file for each container and
-copy to your systemd configuration directory since podman does not use a background daemon.
-For the `ybox-arch_apps` container in the examples before:
+With a user service installed, the `systemctl` commands can be used to control the
+ybox container (`<SERVICE_NAME>` is `ybox-<NAME>/<NAME>` mentioned above):
 
 ```sh
-mkdir -p ~/.config/systemd/user/
-podman generate systemd --name ybox-arch_apps > ~/.config/systemd/user/container-ybox-arch_apps.service
-systemctl --user enable container-ybox-arch_apps.service
+systemctl --user status <SERVICE_NAME>  # show status of the service
+systemctl --user stop <SERVICE_NAME>    # stop the service
+systemctl --user start <SERVICE_NAME>   # start the service
 ```
 
+If your Linux distribution does not use systemd, then the autostart has to be handled
+manually as per the distribution's preferred way. For instance an appropriate desktop
+file can be added to `~/.config/autostart` directory to start a ybox container on
+graphical login, though performing a clean stop can be hard with this approach.
+Note that the preferred way to start/stop a ybox container is using the `ybox-control`
+command rather than directly using podman/docker.
+
 
 ## Development
 
 Virtual environment setup have been provided for consistent development, test and build
 with multiple python versions. The minimum python version required is 3.9 and tests are
-run against all major python versions higher than that (i.e. 3.10, 3.11, 3.12 and others
-in future).
+run against all major python versions higher than that (i.e. 3.10, 3.11, 3.12, 3.13 and
+    others in future).
 
 The setup uses pyenv with venv which can be used for development with IDEA/PyCharm/VSCode
 or in terminal, running tests against all supported python versions using `tox` etc.
@@ -432,14 +455,23 @@ Next you can install the required python versions and venv environment:
 pyenv/setup-venv.sh
 ```
 
-Finally, you can activate it in bash/zsh:
+Finally, you can activate it.
+
+bash:
+
+```sh
+source pyenv/activate.bash
+source .venv/bin/activate
+```
+
+zsh:
 
 ```sh
-source pyenv/activate.sh
+source pyenv/activate.zsh
 source .venv/bin/activate
 ```
 
-Or in fish shell:
+fish:
 
 ```
 source pyenv/activate.fish

{ybox-0.9.8.1 → ybox-0.9.11}/pyproject.toml

@@ -28,8 +28,9 @@ classifiers = [
     "Programming Language :: Python :: 3.10",
     "Programming Language :: Python :: 3.11",
     "Programming Language :: Python :: 3.12",
+    "Programming Language :: Python :: 3.13",
 ]
-keywords = ["Linux in container", "toolbox"]
+keywords = ["Linux in container", "toolbox", "distrobox"]
 
 [project.urls]
 Homepage = "https://github.com/sumwale/ybox"

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/__init__.py

@@ -1,2 +1,2 @@
 """`ybox` is a tool to easily manage linux distributions in containers"""
-__version__ = "0.9.8.1"
+__version__ = "0.9.11"

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/cmd.py

@@ -10,6 +10,7 @@ import sys
 from enum import Enum
 from typing import Callable, Iterable, Optional, Union
 
+from ybox import __version__ as product_version
 from ybox.config import Consts
 
 from .print import print_error, print_info, print_notice, print_warn
@@ -207,7 +208,7 @@ def run_command(cmd: Union[str, list[str]], capture_output: bool = False,
             sys.exit(result.returncode)
         else:
             return result.returncode
-    if capture_output and result.stderr:
+    if capture_output and result.stderr and error_msg != "SKIP":
         print_warn(result.stderr.decode("utf-8"), file=sys.stderr)
     return result.stdout.decode("utf-8") if capture_output else result.returncode
 
@@ -221,6 +222,21 @@ def _print_subprocess_output(result: subprocess.CompletedProcess[bytes]) -> None
         print_warn(result.stderr.decode("utf-8"), file=sys.stderr)
 
 
+def parser_version_check(parser: argparse.ArgumentParser, argv: list[str]) -> None:
+    """
+    Update command-line parser to add `--version` option to existing ones that will output the
+    ybox product version and exit if specified in the given list of arguments.
+
+    :param parser: instance of :class:`argparse.ArgumentParser` having the command-line parser
+    :param argv: the list of arguments to be parsed
+    """
+    parser.add_argument("--version", action="store_true", help="output ybox version")
+    # argv may have required positional arguments, hence check for --version separately
+    if "--version" in argv:
+        print(product_version)
+        sys.exit(0)
+
+
 def parse_opt_deps_args(argv: list[str]) -> argparse.Namespace:
     """
     Common command-line parser for `opt_deps` utilities (see [pkgmgr] section of distro.ini)

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/conf/completions/ybox.fish

@@ -29,6 +29,8 @@ end
 complete -f -c ybox-create -s h -l help -d "show help"
 complete -c ybox-create -s n -l name -d "name of the ybox container" -r
 complete -f -c ybox-create -s F -l force-own-orphans -d "force ownership of orphans on shared root"
+complete -f -c ybox-create -s C -l distribution-config -d "path to custom distribution configuration file"
+complete -f -c ybox-create -l distribution-image -d "custom container image"
 complete -f -c ybox-create -s q -l quiet -d "skip interactive questions"
 complete -f -c ybox-create -n "not __fish_seen_subcommand_from (__fish_ybox_complete_distributions)" -a "(__fish_ybox_complete_distributions)"
 

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/conf/distros/arch/init-user.sh

@@ -10,8 +10,8 @@ current_user="$(id -un)"
 # install binaries for paru from paru-bin (paru takes too long to compile)
 PARU="paru --noconfirm"
 echo_color "$fg_cyan" "Installing AUR helper 'paru'" >> $status_file
-export HOME="$(eval echo "~$current_user")"
-cd ~
+export HOME=$(getent passwd "$current_user" | cut -d: -f6)
+cd "$HOME"
 rm -rf paru-bin
 git clone https://aur.archlinux.org/paru-bin.git
 cd paru-bin

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/conf/distros/arch/init.sh

@@ -6,6 +6,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 
 source "$SCRIPT_DIR/entrypoint-common.sh"
 
+export HOME=/root
 # pacman configuration
 PAC="pacman --noconfirm"
 echo_color "$fg_cyan" "Configuring pacman" >> $status_file

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/conf/distros/arch/pkgdeps.py

@@ -17,6 +17,8 @@ where:
                   newlines in the description
 """
 
+# TODO: SW: this is returning back installed packages too which should be skipped
+
 import gzip
 import os
 import re

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/conf/distros/deb-generic/pkgdeps.py

@@ -11,7 +11,7 @@ where:
             and so on; resolution of level > 2 is not required since caller currently ignores those
  * <order>: this is a simple counter assigned to the dependencies where the value itself is of no
             significance but if multiple dependencies have the same value then it means that they
-            are ORed dependencies and only one of them should normlly be selected for installation
+            are ORed dependencies and only one of them need to be selected for installation
  * <installed>: true if the dependency already installed and false otherwise
  * <description>: detailed description of the dependency; it can contain literal \n to indicate
                   newlines in the description
@@ -69,6 +69,7 @@ class PkgDetail(Enum):
     OPTIONAL_DEP = 5
 
 
+# noinspection PyUnusedLocal
 def process_next_item(line: str, parse_line: Callable[[str], tuple[PkgDetail, str]],
                       parse_dep: Callable[[str], Iterable[tuple[str, str, Optional[str]]]],
                       installed: Callable[[str], bool], max_level: int,

{ybox-0.9.8.1 → ybox-0.9.11}/src/ybox/conf/profiles/apps.ini

@@ -1,6 +1,7 @@
 [base]
 name = Profile for CLI and GUI apps
 includes = basic.ini
+ssh_agent = on
 
 [security]
 # SYS_PTRACE may be required by mesa which is invoked indirectly by both firefox and chromium.
@@ -9,6 +10,9 @@ includes = basic.ini
 caps_add = SYS_PTRACE
 
 [mounts]
+# export the host's ssh keys for use by ssh-agent in the container as required ("ro" mode
+#   implies that known_hosts and other files within ~/.ssh cannot be changed)
+ssh = $HOME/.ssh:$TARGET_HOME/.ssh:ro
 music = $HOME/Music:$TARGET_HOME/Music:ro
 pictures = $HOME/Pictures:$TARGET_HOME/Pictures:ro
 videos = $HOME/Videos:$TARGET_HOME/Videos:ro
@@ -19,8 +23,9 @@ videos = $HOME/Videos:$TARGET_HOME/Videos:ro
 
 [app_flags]
 # These flags will be added to Exec line of google-chrome.desktop when it is copied to host.
-# /dev/shm usage is disabled for chrome because that requires ipc=host or mounting host
-# /dev/shm in read-write mode which can be insecure.
-google-chrome = !p --disable-dev-shm-usage !a
-google-chrome-beta = !p --disable-dev-shm-usage !a
-google-chrome-unstable = !p --disable-dev-shm-usage !a
+
+# the --disable-dev-shm-usage flag in chrome/chromium based browsers disables use of /dev/shm
+# which can reduce memory footprint at the cost of performance and increased disk activity
+#google-chrome = !p --disable-dev-shm-usage !a
+#google-chrome-beta = !p --disable-dev-shm-usage !a
+#google-chrome-unstable = !p --disable-dev-shm-usage !a