Hi, On Mon, Sep 15, 2014 at 07:32:51AM +0200, Tobias Hunger wrote:
As I understand this, systemd expects daemons to deal with no settings in /etc and /var.
/var stores files, not settings. Most daemons will run OK with empty /var. But what do you do with the files? Some kind of rsync gluework?
I do not consider this a problem. When you use somebodies images you need to trust that person. I do not consider trusting the keys that person provides to be a problem.
But it is a problem which has already been discussed. If you have N images, and 1 has its key stolen, all N are in danger. So, it's not about (not) trusting the developer.
This is madness. I remember sometime ago there was a witchhunt against daemons that write to /etc (cups is the worst offender). So why is it OK for systemd to do so? I personally don't want systemd to come anywhere near my /etc. Please package the tmpfiles.d/sysusers stuff with virtkick or whatever, but not with pacman.
Any privileged process can mess with /etc at any time. With factory reset at least you get a pristine copy to compare the files in /etc against.
Sure, and then we call it malicious... What do you call pristine? The files shipped on a livecd? Or an empty default configs shipped with daemons? So far, there are only things like groups/users, but those are trivialities.
Arch did embrace systemd, it should make it easy to use all its features. I am not proposing to enable them by default.
We already have enabled by default ldconfig.service enabled, systemd-update-done.service, etc, which messed a number of my containers. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D