Podman doesn't mount a tmpfs at /tmp by default - it needs to be
separately requested. However, doing it as part of 'podman create ...'
won't add a tmpfs at /tmp for existing toolbox containers. Therefore,
it's best done as part of the entry point.
The mount options are the same as used by systemd (see tmp.mount) to
provide a tmpfs at the host's /tmp.
For what it's worth, the mount flags do differ slightly from the host.
The host has:
$ findmnt --output OPTIONS,PROPAGATION /tmp
OPTIONS PROPAGATION
rw,nosuid,nodev,seclabel shared
The container has:
$ findmnt --output OPTIONS,PROPAGATION /tmp
OPTIONS PROPAGATION
rw,nosuid,nodev,seclabel,uid=100000,gid=100000 private
The uid and gid options don't show up on the host because both are 0,
and hence skipped by the tools.
https://github.com/containers/toolbox/issues/513
Users, who prefer shells other than Bash, tend to get confused when
Toolbox presents a Bash prompt to them. It would be better to be more
upfront about what the problem is, so that users can self-support
themselves.
https://github.com/containers/toolbox/issues/18
Every time Podman changes their JSON API Toolbox breaks horribly. That
is caused by the combination of decoding the JSON purely by hand and by
the complete lack of type assertions to make the process stable.
I previously didn't know that unmarshalling with Go works on the 'do
the best job it can' logic (thank you Owen!). This makes the need to
check for subtle changes in the names of fields go away and type
checking a bit more bearable (marking the questioned field as
interface{} and then immediatelly type switch).
If even now an existing field does not hold an expected value the field
will remain blank.
To take this a bit further, I created two types (toolboxImage and
toolboxContainer) that are used by both functions for returning the
list of images and containers. Instead of using getters for properties
that need some checks or adjustments this uses a custom unmarshaling
function (Owen's idea; thanks!).
The work around populating the two new types is a bit hacky
(marshalling and already unmarshalled JSON - that was unmarshalled to
[]map[string]interface{} - that is then unmarshalled to either
toolboxImage or toolboxContainer. This is done to prevent a major
refactoring before the 0.1.0 release. This should be changed for the
0.2.0 release.
https://github.com/containers/toolbox/pull/503
Rewritten version of Toolbox supports newer syntax for entering a
container: `toolbox enter <name-of-container>`. This new workflow should
be shown in the hint after creating a container with `toolbox create`.
https://github.com/containers/toolbox/issues/489
The Go implementation did not highlight running containers because it
uses a special table writer from 'text/tabwriter' that does not
support colored output [0].
The trick used here is to use ANSI SGR terminal escape sequences [1]
on every line output by the table writer, including headers, and make
the escape sequences use the same number of characters. eg., even
though it's idiomatic to use "\033[0m" to reset the SGR attributes,
such as color; each non-colored line is prefixed with "\033[0;00m" to
ensure that it has the same number of characters as "\033[1;32m", which
is used for bold green output.
Therefore, not only are the non-colored lines wrapped in a redundant
pair of ANSI SGR terminal escape sequences, they are carefully crafted
to match the escape sequences for colored output.
Tested on VTE and xterm.
[0] https://github.com/golang/go/pull/35017
[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parametershttps://github.com/containers/toolbox/pull/494
It doesn't make sense to show a spinner when the output is redirected
to something other than a terminal. When the output is not connected
to a terminal, the terminal escape sequences and other control
characters used to render the spinner leads to some spurious
characters in the output, which confuses the test suite.
This uses the golang.org/x/crypto/ssh/terminal package to check if the
standard output is connected to a terminal or not, which is also what
Podman uses. The other option was the github.com/mattn/go-isatty
package but using it leads to a slightly bigger binary - 7778323 bytes
versus 7782284.
[0] https://github.com/briandowns/spinnerhttps://github.com/containers/toolbox/pull/496
The Go compiler embeds full paths to modules and dependencies into the
binary. This prevents people from reconstructing a bit-for-bit identical
toolbox binary without going through several hoops.
Without patch:
$ strings build/src/toolbox | grep "$HOME" | wc -l
105
With patch:
$ strings build/src/toolbox | grep "$HOME" | wc -l
0
https://github.com/containers/toolbox/pull/448
Signed-off-by: Morten Linderud <morten@linderud.pw>
We call `podman version` every time we want to check Podman's version.
This slows Toolbox down considerably. It's more efficient if we call
`podman version` just once and remember the output during runtime and
use the cached value.
https://github.com/containers/toolbox/pull/481
The subsequent commit will introduce a global variable called
podmanVersion, so this will prevent the local variable from colliding
with the global.
https://github.com/containers/toolbox/pull/481
The subsequent commit will automatically embed the project's version
encoded in Meson into the toolbox binary during the build. This will
remove the need to manually update the version information in the Go
source code. Consolidating the version information reduces the chances
of human error while making a new release. Note, how the 0.0.91 release
forgot to update the version in the Go sources.
This will be done by feeding the version string from Meson into
go-build-wrapper, which will use Go's -X linker flag to embed it into
the final toolbox binary. Since Meson stores the version information
as a string, it's convenient to have the Go code do the same.
https://github.com/containers/toolbox/pull/487
Clients of this package should use the GetVersion function to get the
version as a string. The variable that actually stores the version
information is an implementation detail and meant to be private.
https://github.com/containers/toolbox/pull/487
These keys in 'podman ps --format json' were renamed in Podman 2.0:
* "ID" to "Id"
* "Created" to "CreatedAt"
* "Status" to "State"
The key containing the container's name (ie., "Names") is no longer a
string, but a slice of strings.
https://github.com/containers/toolbox/pull/471
It might happen that the current working directory in the present
environment is missing inside the container that's going to be used.
So far, Toolbox would fail silently, which wasn't very obvious.
Some changes by Debarshi Ray and Harry Míchal.
https://github.com/containers/toolbox/issues/369
Fedora's golang-github-coreos-systemd package is still at version 19,
while the support for Go modules is only available from version 22.
Since all that's necessary is to retrieve the 'Listen' property from
the sssd-kcm.socket unit, it's quite easy to do so directly using Go's
D-Bus bindings.
The systemdNeedsEscape and systemdPathBusEscape functions are copied
from github.com/coreos/go-systemd's needsEscape and PathBusEscape
functions respectively.
The github.com/coreos/go-systemd code is licensed under the ASL 2.0,
the same as Toolbox. It's copyright notice lists 'CoreOS, Inc.', but
since CoreOS has been acquired by Red Hat [1], it should be covered by
Toolbox's existing copyright notices that list 'Red Hat, Inc'.
[1] https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadershiphttps://github.com/containers/toolbox/pull/444
Fedora's golang-github-spf13-cobra package is still at 0.0.5. Since
there's no real need for anything newer, lowering the requirement will
make it easier to build on Fedora.
https://github.com/containers/toolbox/pull/444
Fedora's golang-github-sirupsen-logrus package is still at 1.4.2. Since
there's no real need for anything newer, lowering the requirement will
make it easier to build on Fedora.
https://github.com/containers/toolbox/pull/444
The Go version supports specifying the name of the toolbox container as
'toolbox enter NAME', on top of the 'toolbox enter --container NAME'
form.
https://github.com/containers/toolbox/pull/318
The Go version supports specifying the name of the new toolbox
container as 'toolbox create NAME', in addition to the existing
'toolbox create --container NAME' form.
https://github.com/containers/toolbox/pull/318
