Questions[virtuozzo](server)

the hosting provider of my KVM (Strato) recently upgraded the version of Virtuozzo they were using from 6 to 7. Since then a few of my docker containers fail to start with the following error message:

❯ sudo docker start spring_webapp

Error response from daemon: 
OCI runtime create failed: container_linux.go:349: starting container process caused
"process_linux.go:297: applying cgroup configuration for process caused 
\"failed to set memory.kmem.limit_in_bytes, 
because either tasks have already joined this cgroup 
or it has children\"": unknown

Error: failed to start containers: spring_webapp

The only thing the containers that won't start seem to have in common is that they contain a java webapp. Other containers like gitlab or a few mariadb instances seem to start just fine.

A google search for the error message returned some older issues on github but those seem to have been fixed years ago: https://github.com/opencontainers/runc/issues/1083

I am running Ubuntu 18.04 LTS with docker 19.03.12.

Already opened a ticket with my hosting provider but they answered with a canned response that since I have a root server they can't help me, basically saying that it's a problem with my configuration.

Unfortunately I don't know enough about OpenVZ/Virtuozzo to refute them.

Any hint pointing me in the right direction would be highly appreciated :)

Here's the output of /proc/user_beancounters

❯ sudo cat /proc/user_beancounters
         
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
    831745: kmemsize                564412416            766132224  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                   16  9223372036854775807  9223372036854775807                    0
            privvmpages               5148863              5444666  9223372036854775807  9223372036854775807                    0
            shmpages                    41758                74651  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                       919                  919                 1100                 1100                    0
            physpages                 1972269              2444334              8388608              8388608                    0
            vmguarpages                     0                    0  9223372036854775807  9223372036854775807                    0
            oomguarpages              2104451              2452167                    0                    0                    0
            numtcpsock                      0                    0  9223372036854775807  9223372036854775807                    0
            numflock                        0                    0  9223372036854775807  9223372036854775807                    0
            numpty                          4                    4  9223372036854775807  9223372036854775807                    0
            numsiginfo                     16                  129  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                       0                    0  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                       0                    0  9223372036854775807  9223372036854775807                    0
            othersockbuf                    0                    0  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                    0  9223372036854775807  9223372036854775807                    0
            numothersock                    0                    0  9223372036854775807  9223372036854775807                    0
            dcachesize              353423360            552648704  9223372036854775807  9223372036854775807                    0
            numfile                      6327                11230  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numiptent                     219                  222                 2000                 2000                    0

I just got a virtual server (I think virtuozzo) with root access. I wanted to install shorewall but when I want to start it I get the error message

# shorewall start
Compiling...
Processing /etc/shorewall/shorewall.conf...
ERROR: Your kernel/iptables do not include state match support. No version of Shorewall will run on this system

So now I'm wondering what can I do? The system ist ubuntu 11.10.

I've got a fun challenge for you all. A company I'm working with is setting up its development/release workflow and environments. The eventual production environment is a VPS hosted with a popular host running CentOS within a Virtuozzo virtualization environment.

We'd like to install a virtualized instance of the production environment (or something close to it) to each developer's local system. This will allow each developer to test changes locally on his/her own system without tainting anyone else's system when things go wrong.

Clearly, there are many ways to do this, but I imagine there's a specific approach that is superior. This is where I need your help.

So far, the best options seem to be as follows.

Export/Back up the Virtuozzo VM. Download it to a local system and install it into a Virtuozzo Container.

This is the cleanest/purest solution, but it may not work. The cloned VM would still have all of the network configuration from the VPS' network, for example. Would it be hard to write a script to update these (and any other old configuration values) so they are more appropriate for the local VM?

Deploy the codebase to a similarly configured VM created in an arbitrary virtualization product.

This approach isn't as clean, but I know it can work (I've done it before). For example, we could install the same version of CentOS, Apache, MySQL, etc. to a local VMWare VM. The environment wouldn't be identical to the production environment, but it might be close enough to make this workflow feasible.

Another option?

What other options do you think there may be? Or, is one of these options the best? I'd love to hear your thoughts! :)

Edit:

Multiple cPanel/user accounts on the production server

I contacted our VPS' customer support to see if I could obtain access to the Virtuozzo backups; he denied our request but suggested that we might try creating a separate cPanel/user account for each developer. This would allow the environment to be identical to that of the server, but would be a little more inconvenient since the environment would still be running remotely instead of locally. Still, a decent option.

I'm running Fedora Linux on MediaTemple using their (ve) virtual Linux box. Pretty much a clean install (Linux ************ 2.6.18-028stab089.1 #1 SMP Thu Apr 14 13:46:04 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux).

I'm trying to do some Pear installs and need /tmp to be remounted with exec option. No problem, right? So I'm running as root and I just go for it:

[root@host ~]# mount -o remount,exec /tmp
mount: permission denied
[root@host ~]#

Well, this is rather unexpected. MediaTemple support doesn't provide any assistance with this--it's not in the SLA. Given that this is a pretty vanilla setup, perhaps someone out there has an idea what's wrong here?

EDIT:

Here's some additional information. Running mount shows this:
[root@host ~]# mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
/dev/simfs on /tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
/dev/simfs on /var/tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type tmpfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
[root@host ~]#

The contents of /etc/fstab is:

none /dev/pts devpts rw 0 0

Next I tried adding this line to /etc/fstab:

/dev/simfs /tmp simfs rw,exec,relatime,usrquota,grpquota 0 0

Then running mount /tmp results in:

mount: unknown filesystem type 'simfs'

I'm a little confused as to how simfs is listed when you run mount, but when you add it to /etc/fstab it isn't recognized. Nonetheless, this doesn't seem to solve my issue, so I'm still stuck. Any ideas?

UPDATE 6/25/11

@jamiers has found a workaround that MediaTemple posted (see below). However, I'm now wondering about the more fundamental aspect of this problem. Why is it that you can't remount tmp with different options in a virtual environment? From what I can tell, there's nothing inherently restrictive in a virtual environment that would prevent you from doing something like that. Does anyone have an idea why this is the case?

Note: This question is still unresolved - the answer was auto-accepted.

I have a Debian Lenny VPS, that's running virtualized by Parallels/Virtuozzo. Currently, the network interface doesn't have an IPv6 address - and that's good, because I don't have an ip6tables configuration.

But I assume, that I could wake up one day, and ifconfig will show me an ipv6 address for the interface - because I have no control over the kernel or its modules - they're under the control of the hosting company. That would leave the server completely vulnerable to attacks from IPv6 addresses.

What would be the best way to disable IPv6 (for the interface or maybe for the entire host)? Usually I would simply disable the kernel module, but that's not possible in this case.

Update

Maybe I should add, that I can use iptables and everything normally (I'm root on the VPS), but I can't make changes to the kernel or load kernel modules because of the way Virtuozzo works (shared kernel).

lsmod always returns nothing.

I can't call ip6tables -L (it says that I need to insmod, or that the kernel would have to be upgraded).

I don't think, that changes to /etc/modprobe.d/aliases would have any effect, or do they?

Networking Config?

I thought, that maybe I can turn IPv6 off from /etc/network/... Is that possible?