<paroneayea>I'm curious about how much of a "central" model it has. eg, puppet requires a central server, but propellor has each machine build independently and a central server just kicks off each machine
<davexunit>paroneayea: well, you'd still a central machine that you managed the deployment from, though you could just ship the state files to another computer and control the deployment from there.
<davexunit>it's not like how Puppet has a centralized puppet master daemon
<paroneayea>In the short-term future writing directly to the control group tree from applications should still be OK, as long as the Pax Control Groups document is followed. In the medium-term future it will still be supported to alter/read individual attributes of cgroups directly, but no longer to create/delete cgroups without using the systemd API. In the longer-term future altering/reading attributes will also be unavailable to userspace
<paroneayea>applications, unless done via systemd's APIs (either D-Bus based IPC APIs or shared library APIs for passive operations).
<paroneayea>does that mean systemd is saying "no" to docker also?
<davexunit>so there would be a mapping to a range of uids/gids on the host system?
<_`_>err my mistake, by “they” I meant the user on the host. it's not enough that the container's have their own users/groups, the uids/gids shouldn't match the uids/gids on the host, relative to the host. So if I ran an unprivileged container even as root, if they “hypothetically” break out the process would be uid/gid 100000 or so.
<davexunit>_`_: I'll look into this more sometime, going to focus on basic cgroup stuff for now.
<rekado->if only we had as many people working on the Hurd ... I really want to be able to use all of these nice Hurd-native features in a stable, usable system.
<_`_>davexunit: With recent shadow a range of IDs can be assigned to users as resources. When a user namespace is created a range of IDs can be set up as mapping. eg: add 100,000 to every UID in the container to get the “real UID”. In the linux kernel there are files names /proc/$PID/uid_map and gid_map which contain the mapping table for a process/container.
<rekado->apparmour rules work on paths, so the rules would break whenever a package is updated.
<rekado->selinux is just too complicated to begin with.
<_`_>davexunit: I initially intend to use guix as a local unprivileged user's package manager, on non linux kernel platforms, where the package management is less the satisfactory (e.g. FreeBSD). nix/pkgsrc were unsuitable for these use cases.
<cehteh>.. well and if you try, i failed to install it on a kvm
<Tsyesika>i can't install it unfortunately, i just figured if i could start it from the usb then i could see if the bug i have still exists
<cehteh>you could install X on it (actually in ram or on some backing store with the cow-store stuff) and start that up
<Tsyesika>i can't, i only have two usb ports and since my laptop internal keyboard doesn't work i need 1 usb for my keyboard, 1 for the usb and then network would be the another but that's 3 ports i need
<cehteh>for example some heart bleeds again, but i want my system mostly frozen and not upgrade everything, only install a new openssl and then find any package in the system using the old ssl and alter that package to use the new openssl version
<davexunit>if foo depended on libbar, and you upgraded the libbar recipe, running 'guix pckage -i foo' would build libbar and foo
<davexunit>cehteh: you would just upgrade the openssl recipe and upgrade your profiles
<cehteh>yes .. is there any automatic help for this task?
<davexunit>you likely won't have openssl installed in your profile, but you will have applications that depend on it. running 'guix package -u' will upgrade everything to latest versions, as defined by the package objects in the distro.
<cehteh>well i may want to keep fooapp to the current (possibly older) version .. but using the new openssl