intelsdi-x / rkt Goto Github PK

View Code? Open in Web Editor NEW

This project forked from rkt/rkt

0.0 67.0 1.0 25.68 MB

rkt is an App Container runtime for Linux

License: Apache License 2.0

Shell 3.03% Go 86.17% Makefile 7.15% C 1.59% M4 2.07%

rkt's Introduction

DISCONTINUATION OF PROJECT.

This project will no longer be maintained by Intel.

This project has been identified as having known security escapes.

Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project.

Intel no longer accepts patches to this project.

rkt - the pod-native container engine

rkt (pronounced "rock-it") is a CLI for running application containers on Linux. rkt is designed to be secure, composable, and standards-based.

Some of rkt's key features and goals include:

Pod-native: rkt's basic unit of execution is a pod, linking together resources and user applications in a self-contained environment.
Security: rkt is developed with a principle of "secure-by-default", and includes a number of important security features like support for SELinux, TPM measurement, and running app containers in hardware-isolated VMs.
Composability: rkt is designed for first-class integration with init systems (like systemd, upstart) and cluster orchestration tools (like Kubernetes and Nomad), and supports swappable execution engines.
Open standards and compatibility: rkt implements the appc specification, supports the Container Networking Interface specification, and can run Docker images and OCI images. Broader native support for OCI images and runtimes is in development.

Project status

The rkt v1.x series provides command line user interface and on-disk data structures stability for external development. Any major changes to those primary areas will be clearly communicated, and a formal deprecation process conducted for any retired features.

Check out the roadmap for more details on the future of rkt.

Trying out rkt

To get started quickly using rkt for the first time, start with the "trying out rkt" document. Also check rkt support on your Linux distribution. For an end-to-end example of building an application from scratch and running it with rkt, check out the getting started guide.

Getting help with rkt

There are a number of different avenues for seeking help and communicating with the rkt community:

For bugs and feature requests (including documentation!), file an issue
For general discussion about both using and developing rkt, join the rkt-dev mailing list
For real-time discussion, join us on IRC: #rkt-dev on freenode.org
For more details on rkt development plans, check out the GitHub milestones

Most discussion about rkt development happens on GitHub via issues and pull requests. The rkt developers also host a semi-regular community sync meeting open to the public. This sync usually features demos, updates on the roadmap, and time for anyone from the community to ask questions of the developers or share users stories with others. For more details, including how to join and recordings of previous syncs, see the sync doc on Google Docs.

Contributing to rkt

rkt is an open source project and contributions are gladly welcomed! See the Hacking Guide for more information on how to build and work on rkt. See CONTRIBUTING for details on submitting patches and the contribution workflow.

Licensing

Unless otherwise noted, all code in the rkt repository is licensed under the Apache 2.0 license. Some portions of the codebase are derived from other projects under different licenses; the appropriate information can be found in the header of those source files, as applicable.

Security disclosure

If you suspect you have found a security vulnerability in rkt, please do not file a GitHub issue, but instead email [email protected] with the full details, including steps to reproduce the issue. CoreOS is currently the primary sponsor of rkt development, and all reports are thoroughly investigated by CoreOS engineers. For more information, see the CoreOS security disclosure page.

Known issues

Due to limitations in the Linux kernel, using rkt's overlay support on top of an overlay filesystem requires the upperdir and workdir to support the creation of trusted.* extended attributes and valid d_type in readdir responses (see kernel/Documentation/filesystems/overlayfs.txt). When starting rkt inside rkt this means that either:

the inner /var/lib/rkt directory needs to be mounted on a host volume.
the outer or inner rkt container needs to be started using --no-overlay.

Due to a bug in the Linux kernel, using rkt when /var/lib/rkt is on btrfs requires Linux 4.5.2+ (#2175).

Due to a bug in the Linux kernel, using rkt's overlay support in conjunction with SELinux requires a set of patches that are only currently available on some Linux distributions (for example, CoreOS Linux). Work is ongoing to merge this work into the mainline Linux kernel (#1727).

Linux 3.18+ is required to successfully garbage collect rkt pods when system services such as udevd are in a slave mount namespace (see lazy umounts on unlinked files and directories and #1922).

rkt's People

Contributors

Watchers

Forkers

lukasredynk

rkt's Issues

tests: TestEnv panics

Failed to remove temporary data directory "/tmp/datadir-453325704": remove /tmp/datadir-453325704/pods/run/3b0f9f5b-d73b-49a2-8ea1-77fb1b5024e8/stage1/rootfs/sys: device or resource busy

from

testing.func·006()
        /usr/local/go/src/testing/testing.go:441 +0x181
github.com/coreos/rkt/tests.(*dirDesc).cleanup(0xc2082e03c0)
        /home/ppalucki/work/go/src/github.com/coreos/rkt/build-rkt-0.7.0+git/gopath/src/github.com/coreos/rkt/tests/rkt_tests.go:70 +0x228
github.com/coreos/rkt/tests.(*rktRunCtx).cleanup(0xc2081b8b10)
        /home/ppalucki/work/go/src/github.com/coreos/rkt/build-rkt-0.7.0+git/gopath/src/github.com/coreos/rkt/tests/rkt_tests.go:144 +0xc7

skip broken kvm tests

It could be very helpfull to skip some functional kvm tests (which are still broken) during buiding and testing phase on CI

stage0: setEnv are overriten by inheritEnv

In a case of have the same env in a host and rkr runcmd, there will be append to the Enviroment type twice, and use that one from a host.
IMHO SetEnv from cmd should be desired. Can use assertValid in MergeEnv function and add override envs

tests: cgroups aren't read-only

test 'TestCgroups' fails with

[    0.217983] inspect[71]: check-cgroups: FAIL

because nspwan remount (bind remounts) whole cgroups as read-only

systemd-nspawn limits access to various kernel interfaces in the container to read-only, such as /sys, /proc/sys or /sys/fs/selinux. Network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and kernel modules may not be loaded from within the container.

http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

how it is done in nspwan.c can be seen here

kvm: problem with mounting single file as a volume

Steps to reproduce:

sudo ./rkt prepare --pod-manifest nginx_default.json --stage1-path stage1-kvm.aci

nginx_default.json

sudo ./rkt run-prepared $UUID

Got error:

kvm: network unit created: "interface-eth0.service" in "stage1/rootfs/usr/lib/systemd/system" (iface="eth0", addr="172.16.28.85/24")
stage1: warning: no volume specified for mount point "k8s-managed-etc-hosts", implicitly creating an "empty" volume. This volume will be removed when the pod is garbage-collected.
stage1: failed to configure systemd: mkdir stage1/rootfs/opt/stage2/nginx/rootfs/etc/hosts: not a directory

tests: NonRootCaps fails

                [    0.269978] inspect[71]: Capability set: effective: chown, dac_override, dac_read_search, fowner, fsetid, kill, setgid, setuid, setpcap, linux_immutable, net_bind_service, net_broadcast, net_admin, net_raw, ipc_lock, ipc_owner, sys_module, sys_rawio, sys_chroot, sys_ptrace, sys_psacct, sys_admin, sys_boot, sys_nice, sys_resource, sys_time, sys_tty_config, mknod, lease, audit_write, audit_control, setfcap, mac_override, mac_admin, syslog, wake_alarm, block_suspend, audit_read
                [    0.269978] inspect[71]: Capability set: permitted: chown, dac_override, dac_read_search, fowner, fsetid, kill, setgid, setuid, setpcap, linux_immutable, net_bind_service, net_broadcast, net_admin, net_raw, ipc_lock, ipc_owner, sys_module, sys_rawio, sys_chroot, sys_ptrace, sys_psacct, sys_admin, sys_boot, sys_nice, sys_resource, sys_time, sys_tty_config, mknod, lease, audit_write, audit_control, setfcap, mac_override, mac_admin, syslog, wake_alarm, block_suspend, audit_read
                [    0.270978] inspect[71]: Capability set: inheritable:

stage1: missing env files in fly flavor

Seems that there are no env variables which should available when entering into stage2 of application

volumes: works but "is not a mount point" validation error

[    0.264975] ace-validator[85]: 2015/07/09 19:35:25 WARN: "/db" is not a mount point (againts "/") fsid are equal: syscall.Fsid{X__val:[2]int32{-926896844, 1387030233}} == syscall.Fsid{X__val:[2]int32{-926896844, 1387030233}}

    if sfs1.Fsid == sfs2.Fsid {
        return fmt.Errorf("%q is not a mount point", d)
    }

https://github.com/appc/spec/blob/master/ace/validator.go#L485

according to http://man7.org/linux/man-pages/man2/statfs.2.html

    Nobody knows what f_fsid is supposed to contain (but see below).
...

   The f_fsid field
       Solaris, Irix and POSIX have a system call statvfs(2) that returns a
       struct statvfs (defined in <sys/statvfs.h>) containing an unsigned
       long f_fsid.  Linux, SunOS, HP-UX, 4.4BSD have a system call statfs()
       that returns a struct statfs (defined in <sys/vfs.h>) containing a
       fsid_t f_fsid, where fsid_t is defined as struct { int val[2]; }.
       The same holds for FreeBSD, except that it uses the include file
       <sys/mount.h>.

       The general idea is that f_fsid contains some random stuff such that
       the pair (f_fsid,ino) uniquely determines a file.  Some operating
       systems use (a variation on) the device number, or the device number
       combined with the filesystem type.  Several operating systems
       restrict giving out the f_fsid field to the superuser only (and zero
       it for unprivileged users), because this field is used in the
       filehandle of the filesystem when NFS-exported, and giving it out is
       a security concern.

       Under some operating systems, the fsid can be used as the second
       argument to the sysfs(2) system call.

http://golang.org/pkg/path/filepath/#Dir
"""
Dir returns all but the last element of path, typically the path's directory. After dropping the final
element, the path is Cleaned and trailing slashes are removed. If the path is empty, Dir returns ".". If
the path consists entirely of separators, Dir returns a single separator. The returned path does not
end in a separator unless it is the root directory.
"""

TERM environment variable not set in kvm flavor

This caused that some commands, like "clear" doesn't work