Apt commands on new ubuntu16 template container creates apt-key errors #130
Comments
|
I just setup a new peer. My old peer was just filled with templates and broken 🗡 . Here's what I got after running apt-get update:
Here's what my version information looks like on my peer:
|
|
NOTE: My plugin version is old because I never updated the plugin in my browser since I use chrome (most stable). Most changes were made to Safari plugin for 3.0.0. The key things to note is the SS version, the RH version, and the P2P version. As I said on Slack, I have a feeling your peer's gorjun cache is broken. We need to look at the logs to see why Gorjun is not handling apt-get pulls of repository Package files. |
|
OK I have confirmed that this is not working on your peer. I created an environment that I own across your peer and mine: two containers one each on our peers. Here's the output I get on the container running in your peer's container (notice it does not happen on my peer's container). My container running in your peer:
My container running in my peer (same env)root@Container-1-MIc:/# apt-get update |
|
We have figured out that this works fine on Debian system, but we always have problems on Ubuntu 16.04. The problem described in this issue is not related to Gorjun since there is no Gorjun URL in the list of APT repository. |
|
This issue appears to be affected by the snap security architecture:
Apt debug log:
Kernel apparmor log:
|
|
https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-apparmor If you find that lxc-start is failing due to a legitimate access which is being denied by its Apparmor policy, you can disable the lxc-start profile by doing: sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start lxc.aa_profile = unconfined Would be interesting to try the lxc.aa_profile to see if that solves this particular issue. If so we can look into how to set the profile so it doesn't happen. |
|
The lxc-start unconfined operation is ok but the totally unconfined container is not. That worries me around the security implications it could have. |
|
We should understand those because since apparmor is not enabled on Debian by default, the above should pretty much just run the RH as it would if running on Debian. Anyway - my suggestion was not disabling apparmor permanently but merely see if that solves the issue - the figure out which part of apparmor preventing the proper apt-get update. |
|
Yeah I agree, but that also means, on Debian, we're not running with confinement and that's scary. Maybe we need to add the same AA rules to the Debian RH. |
|
I'm sure though that |
|
Well - afaik Debian simply hasn't got apparmor enabled by default. |
|
Tried to set Append Restart the container and attach to it Run Looking at the AppArmor status, the container is still confined in complain mode under the |
|
But that does not make this any less odd really. As far as I can see - NO apparmor mode is enforced - only in complaint mode. According to apparmor doc: NOT ENFORCE! So - we still don't know what is happening here! |
|
Just for reference - Ubuntu bug that appears to be related - however, none of the work arounds described works: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1577926 Also - tried strace: |
|
So it sounds to me like some things are enforced yet not documented. I think we need to sift through the set of AppArmor access control rules. |
|
Read up on that thread. This shxt is cryptic. UPDATE: tried all the workarounds without success (i.e. chmod 1777 on /tmp) The id_map mechanism might have something to do with that though. |
|
Even with apparmor completely disabled And after a reboot, I'm getting the same error inside the container: This might have nothing to do with apparmor. |
|
This workaround works: edit /etc/defaults/grub Set: GRUB_CMDLINE_LINUX_DEFAULT="apparmor=0" Run: update-grub Reboot and that's it. I would suggest that this essentially emulates on Ubuntu how things are run on Debian. This is NOT the right way to do this obviously but at least it proves beyond doubt that this is apparmor related. |
|
Interesting observation. On a freshly booted system with containers running: After a failed apt-get update: Back on the host: In other words - these are generated dynamically. They are however all listed as "complain". |
|
Another interesting page: https://bugs.launchpad.net/snappy/+bug/1670475 Seems to indicate a kernel bug in the kernel xenial uses by default. However, updating to: root@usmp1: Did NOT solve the issue. |
|
Fixed. |
When trying to do an initial
apt-get updateon a fresh ubuntu16 container, the command fails, claiming that there was an error in runningapt-keyand asking ifgnupgis installed. Full error trace below:Versions of the various components are as follows:
SS version | 6.1.3
RH version | 6.1.4
P2P version | 6.1.9. Packet version: 5
Plugin version | 3.0.0
The text was updated successfully, but these errors were encountered: