Skip to content

Conversation

@gizahNL
Copy link
Contributor

@gizahNL gizahNL commented May 10, 2021

Move the default mounts definition to platform specific function & implement the correct mounts definition for FreeBSD

@k8s-ci-robot
Copy link

Hi @gizahNL. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@estesp
Copy link
Member

estesp commented May 10, 2021

All files in containerd need the proper copyright/license header; this checked by CI so you will need update the commit for the 2 new files. Thanks!

@gizahNL
Copy link
Contributor Author

gizahNL commented May 10, 2021

All files in containerd need the proper copyright/license header; this checked by CI so you will need update the commit for the 2 new files. Thanks!

Will do, thx!
I also figured this likely will not build on Windows, so I'll have to rework for that.

@theopenlab-ci
Copy link

theopenlab-ci bot commented May 10, 2021

Build succeeded.

@dmcgowan
Copy link
Member

Thanks for the contribution! Please sign your commit using git commit -s, see https://github.com/containerd/project/blob/main/CONTRIBUTING.md#sign-your-work

@theopenlab-ci
Copy link

theopenlab-ci bot commented May 10, 2021

Build succeeded.

@estesp
Copy link
Member

estesp commented May 10, 2021

/ok-to-test

Comment on lines 37 to 54
{
Destination: "/dev/fd",
Type: "fdescfs",
Source: "fdescfs",
Options: []string{},
},
{
Destination: "/dev/mqueue",
Type: "mqueue",
Source: "mqueue",
Options: []string{"nosuid", "noexec"},
},
{
Destination: "/dev/shm",
Type: "tmpfs",
Source: "shm",
Options: []string{"nosuid", "noexec", "mode=1777"},
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I admit to being very much a newbie with FreeBSD, but I'm wondering whether these are the right defaults. On my FreeBSD host (outside a jail) I only have devfs mounted at /dev. /dev/fd appears to be provided by devfs, and the same is true in the jails that I've set up with runj. I don't have /dev/shm or /dev/mqueue at all on my host either.

$ mount
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot on /zroot (zfs, local, noatime, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/containerd on /var/lib/containerd/io.containerd.snapshotter.v1.zfs (zfs, local, noatime, nfsv4acls)
zroot/containerd/44 on /run/containerd/io.containerd.runtime.v2.task/default/test2/rootfs (zfs, local, noatime, nfsv4acls)
devfs on /run/containerd/io.containerd.runtime.v2.task/default/test2/rootfs/dev (devfs, local, multilabel)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The man page for fdescfs answers at least the question of /dev/fd being provided by devfs, but I'd still like to understand more about whether these are the appropriate defaults.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at my jails (setup via cbsd), I have fdescfs mounted for all of them, the other mounts are indeed not present.

/dev/shm is a Linuxism, and I should remove that, my first intention was to make sure mount doesn't explode when it tries to mount filesystems that are not native to FreeBSD. /dev/mqueue is also save to remove I'd say, it doesn't seem to be mounted anywhere either.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fixup tonight.

Copy link
Member

@samuelkarp samuelkarp May 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at my jails (setup via cbsd), I have fdescfs mounted for all of them, the other mounts are indeed not present.

Should fdescfs be present by default though? It doesn't seem to be mounted by default in the FreeBSD host I've been using that I installed without much customization.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216985 and FreeBSD's ports, bash and OpenJDK need fdescfs.

So questions are;

  • Do we want to provide a minimal set or good enough default to run common programs?
  • Are bash and/or OpenJDK considered "common" to mount fdescfs by default?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bash and OpenJDK needing fdescfs sounds like a good reason to mount it by default to me.

@theopenlab-ci
Copy link

theopenlab-ci bot commented May 13, 2021

Build succeeded.

Copy link
Member

@samuelkarp samuelkarp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (See note below)

One of the committers will need to hit the approve button so CI can run. I also haven't implemented mount in runj yet (though I see you did in your fork) so I haven't been able to test it.

@samuelkarp
Copy link
Member

Integration test failures appear to be unrelated.

Destination: "/dev",
Type: "devfs",
Source: "devfs",
Options: []string{},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been using ruleset=4 in runj so far. A somewhat more-restrictive default might be useful here and the jail(8) manual page suggests using 4.

Copy link
Contributor Author

@gizahNL gizahNL May 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been my intention to pass devfs rule options in a (yet to be defined) OCI specification for FreeBSD.
ruleset=4 sounds like a safe default for the meantime though :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not completely relevant for this PR, but I'm curious to know why you are thinking of embedding devfs rule options in a FreeBSD section rather than mount options. Were you planning to allow for full ruleset definitions rather than referencing existing rulesets?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note: dismissing previous LGTM to track the addition of the default ruleset option prior to merging.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes allowing to build a complete devfs ruleset has been the intention.
FreeBSD allows the ruleset to be specified at mount time, but also allows later modifications of a devfs mountpoint via the CLI devfs tool, even changing the ruleset (rulesets in essence basically just being a series of show and hide commands).
So I'd think having a node in a FreeBSD OCI spec that allows specification of a ruleset & a list of actions to take on the dev mountpoint would be usefull.

Copy link
Member

@samuelkarp samuelkarp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note: dismissing previous LGTM to track the addition of the default ruleset option prior to merging.)

Destination: "/dev",
Type: "devfs",
Source: "devfs",
Options: []string{},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note: dismissing previous LGTM to track the addition of the default ruleset option prior to merging.)

@samuelkarp
Copy link
Member

I've now implemented mount support in runj and tested this change. I'd still like to see the ruleset=4 option included in the default devfs mount, but otherwise this change is looking good.

Signed-off-by: Gijs Peskens <[email protected]>
@gizahNL
Copy link
Contributor Author

gizahNL commented May 25, 2021

I've now implemented mount support in runj and tested this change. I'd still like to see the ruleset=4 option included in the default devfs mount, but otherwise this change is looking good.

done.

@theopenlab-ci
Copy link

theopenlab-ci bot commented May 25, 2021

Build succeeded.

Copy link
Member

@samuelkarp samuelkarp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kzys
Copy link
Member

kzys commented May 25, 2021

@estesp Can you hit the approve button to run GitHub Actions?

One of the committers will need to hit the approve button so CI can run. I also haven't implemented mount in runj yet (though I see you did in your fork) so I haven't been able to test it.

Neither @samuelkarp nor I can do that.

Copy link
Member

@estesp estesp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@estesp estesp merged commit ba4fa32 into containerd:master May 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants