Bug#919231: Salt-master unable to access directories
On Wed, Apr 24, 2019 at 7:13 AM Michael Biebl wrote: > Hi Felipe > > On Wed, 3 Apr 2019 15:29:44 -0300 Felipe Sateler > wrote: > > Unfortunately the fix seems to have been merged with some other > > refactorings and the diff is not as small[1]. I'll try to check if some > of > > the patches are not necessary. > > > > > > [1] https://github.com/systemd/systemd/pull/12005/files > > > Were you able to make some progress here? > > I'm considering making another upload for buster to fix #927008 (without > that upstream patch, systemd-journal-remote/upload is pretty much > useless in buster) > Sorry, I have been buried with $work, so I haven't been able to look at this. I don't think I'll have time in the short term either > -- Saludos, Felipe Sateler
Bug#919231: Salt-master unable to access directories
Hi Felipe On Wed, 3 Apr 2019 15:29:44 -0300 Felipe Sateler wrote: > Unfortunately the fix seems to have been merged with some other > refactorings and the diff is not as small[1]. I'll try to check if some of > the patches are not necessary. > > > [1] https://github.com/systemd/systemd/pull/12005/files Were you able to make some progress here? I'm considering making another upload for buster to fix #927008 (without that upstream patch, systemd-journal-remote/upload is pretty much useless in buster) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#919231: Salt-master unable to access directories
On Wed, Apr 3, 2019 at 2:26 PM Michael Biebl wrote: > On Wed, 27 Feb 2019 10:33:48 -0300 Felipe Sateler > wrote: > > Control: found -1 241-5 > > Control: tags -1 confirmed upstream > > Control: forwarded -1 https://github.com/systemd/systemd/issues/11842 > > > > I was able to reproduce the issue, and forwarded this upstream. > > Seems like something which we should consider fixing for buster. > > Felipe, this bug is marked as fixed upstream. Since you already had a > look at this issue, could you cherry-pick the necessary upstream commits > and verify that the issue is fixed? > Unfortunately the fix seems to have been merged with some other refactorings and the diff is not as small[1]. I'll try to check if some of the patches are not necessary. [1] https://github.com/systemd/systemd/pull/12005/files -- Saludos, Felipe Sateler
Bug#919231: Salt-master unable to access directories
On Wed, 27 Feb 2019 10:33:48 -0300 Felipe Sateler wrote: > Control: found -1 241-5 > Control: tags -1 confirmed upstream > Control: forwarded -1 https://github.com/systemd/systemd/issues/11842 > > I was able to reproduce the issue, and forwarded this upstream. Seems like something which we should consider fixing for buster. Felipe, this bug is marked as fixed upstream. Since you already had a look at this issue, could you cherry-pick the necessary upstream commits and verify that the issue is fixed? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#919231: Salt-master unable to access directories
Control: found -1 241-5 Control: tags -1 confirmed upstream Control: forwarded -1 https://github.com/systemd/systemd/issues/11842 I was able to reproduce the issue, and forwarded this upstream. -- Saludos, Felipe Sateler
Bug#919231: Salt-master unable to access directories
Thanks, that workaround fixes it indeed. Verzonden met ProtonMail Mobile Oorspronkelijk bericht Aan 6 feb. 2019 19:19, Benjamin Drung schreef: > reassign 919231 systemd 240-5 > retitle 919231 CacheDirectory/StateDirectory does not change owner/group > thanks > > Hi Stijn, > > your bug description was enough for me to reproduce this misbehavior > and tracked it down to systemd not behaving like the documentation > describes: > > StateDirectory=, CacheDirectory= > Except in case of ConfigurationDirectory=, the innermost specified > directories will be owned by the user and group specified in User= > and Group=. If the specified directories already exist and their > owning user or group do not match the configured ones, all files > and directories below the specified directories as well as the > directories themselves will have their file ownership recursively > changed to match what is configured. As an optimization, if the > specified directories are already owned by the right user and > group, files and directories below of them are left as-is, even > if they do not match what is requested. > > The salt-master systemd service is configured to use > /var/lib/salt/pki/master and /var/cache/salt/master as state and cache > directory. salt should change the ownership, but it does not. Steps to > reproduce: > > Take a minimal Debian 9 installation and: > > ``` > root@debian:~# apt install salt-master > root@debian:~# sed -i 's/stretch/buster/g' /etc/apt/sources.list > root@debian:~# apt upgrade > [...] > Setting up salt-master (2018.3.3+dfsg1-2) ... > Installing new version of config file /etc/salt/master ... > Job for salt-master.service failed because the control process exited > with error code. > See "systemctl status salt-master.service" and "journalctl -xe" for > details. > invoke-rc.d: initscript salt-master, action "restart" failed. > ● salt-master.service - The Salt Master Server > Loaded: loaded (/lib/systemd/system/salt-master.service; enabled; > vendor preset: enabled) > Active: failed (Result: exit-code) since Wed 2019-02-06 16:16:37 > UTC; 8ms ago > Docs: man:salt-master(1) > file:///usr/share/doc/salt/html/contents.html > https://docs.saltstack.com/en/latest/contents.html > Process: 31417 ExecStart=/usr/bin/salt-master (code=exited, > status=13) > Main PID: 31417 (code=exited, status=13) > > Feb 06 16:16:37 debian systemd[1]: Starting The Salt Master Server... > Feb 06 16:16:37 debian salt-master[31417]: Failed to create directory > path "/var/lib/salt/pki/master/minions" - [Errno 13] Permission denied: > '/var/lib/salt/pki/master/minions' > Feb 06 16:16:37 debian systemd[1]: salt-master.service: Main process > exited, code=exited, status=13/n/a > Feb 06 16:16:37 debian systemd[1]: salt-master.service: Failed with > result 'exit-code'. > Feb 06 16:16:37 debian systemd[1]: Failed to start The Salt Master > Server. > dpkg: error processing package salt-master (--configure): > installed salt-master package post-installation script subprocess > returned error exit status 1 > [...] > ``` > > Instead of doing an upgrade test, you can just do the test on testing > by stopping salt-master, changing the permission to root and starting > salt-master. > > ``` > root@debian:~# systemctl cat salt-master.service > # /lib/systemd/system/salt-master.service > [Unit] > Description=The Salt Master Server > Documentation=man:salt-master(1) > file:///usr/share/doc/salt/html/contents.html > https://docs.saltstack.com/en/latest/contents.html > After=network.target > > [Service] > LimitNOFILE=10 > Type=notify > NotifyAccess=all > ExecStart=/usr/bin/salt-master > User=salt > Group=salt > CacheDirectory=salt/master > RuntimeDirectory=salt > StateDirectory=salt/pki/master > > [Install] > WantedBy=multi-user.target > root@debian:~# ls -ld /var/lib/salt /var/lib/salt/pki > /var/lib/salt/pki/master > drwxr-xr-x 3 salt salt 4096 Feb 6 16:16 /var/lib/salt > drwxr-xr-x 3 root root 4096 Feb 6 16:16 /var/lib/salt/pki > drwx-- 7 root root 4096 Feb 6 16:10 /var/lib/salt/pki/master > root@debian:~# ls -ld /var/cache/salt /var/cache/salt/master > drwxr-xr-x 3 root root 4096 Feb 6 16:10 /var/cache/salt > drwxr-xr-x 8 root root 4096 Feb 6 16:11 /var/cache/salt/master > rroot@debian:~# dpkg -l | grep systemd | sed 's/ \+amd64 .*$//' > ii libnss-systemd:amd64 240-5 > ii libpam-systemd:amd64 240-5 > ii libsystemd0:amd64 240-5 > ii python-systemd 234-2+b1 > ii python3-systemd 234-2+b1 > ii systemd 240-5 > ii systemd-sysv 240-5 > ``` > > The workaround is to manually change the owner/group to salt: > > root@debian:~# chown -R salt:salt /var/lib/salt/pki/master > /var/cache/salt/master > root@debian:~# systemctl start salt-master > > -- > Benjamin Drung > System Developer > Debian & Ubuntu Developer > > 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany > E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de > > Head Office: Berlin, Germany > District Court Berlin Charlottenburg,
Bug#919231: Salt-master unable to access directories
reassign 919231 systemd 240-5 retitle 919231 CacheDirectory/StateDirectory does not change owner/group thanks Hi Stijn, your bug description was enough for me to reproduce this misbehavior and tracked it down to systemd not behaving like the documentation describes: StateDirectory=, CacheDirectory= Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured ones, all files and directories below the specified directories as well as the directories themselves will have their file ownership recursively changed to match what is configured. As an optimization, if the specified directories are already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what is requested. The salt-master systemd service is configured to use /var/lib/salt/pki/master and /var/cache/salt/master as state and cache directory. salt should change the ownership, but it does not. Steps to reproduce: Take a minimal Debian 9 installation and: ``` root@debian:~# apt install salt-master root@debian:~# sed -i 's/stretch/buster/g' /etc/apt/sources.list root@debian:~# apt upgrade [...] Setting up salt-master (2018.3.3+dfsg1-2) ... Installing new version of config file /etc/salt/master ... Job for salt-master.service failed because the control process exited with error code. See "systemctl status salt-master.service" and "journalctl -xe" for details. invoke-rc.d: initscript salt-master, action "restart" failed. ● salt-master.service - The Salt Master Server Loaded: loaded (/lib/systemd/system/salt-master.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2019-02-06 16:16:37 UTC; 8ms ago Docs: man:salt-master(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html Process: 31417 ExecStart=/usr/bin/salt-master (code=exited, status=13) Main PID: 31417 (code=exited, status=13) Feb 06 16:16:37 debian systemd[1]: Starting The Salt Master Server... Feb 06 16:16:37 debian salt-master[31417]: Failed to create directory path "/var/lib/salt/pki/master/minions" - [Errno 13] Permission denied: '/var/lib/salt/pki/master/minions' Feb 06 16:16:37 debian systemd[1]: salt-master.service: Main process exited, code=exited, status=13/n/a Feb 06 16:16:37 debian systemd[1]: salt-master.service: Failed with result 'exit-code'. Feb 06 16:16:37 debian systemd[1]: Failed to start The Salt Master Server. dpkg: error processing package salt-master (--configure): installed salt-master package post-installation script subprocess returned error exit status 1 [...] ``` Instead of doing an upgrade test, you can just do the test on testing by stopping salt-master, changing the permission to root and starting salt-master. ``` root@debian:~# systemctl cat salt-master.service # /lib/systemd/system/salt-master.service [Unit] Description=The Salt Master Server Documentation=man:salt-master(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html After=network.target [Service] LimitNOFILE=10 Type=notify NotifyAccess=all ExecStart=/usr/bin/salt-master User=salt Group=salt CacheDirectory=salt/master RuntimeDirectory=salt StateDirectory=salt/pki/master [Install] WantedBy=multi-user.target root@debian:~# ls -ld /var/lib/salt /var/lib/salt/pki /var/lib/salt/pki/master drwxr-xr-x 3 salt salt 4096 Feb 6 16:16 /var/lib/salt drwxr-xr-x 3 root root 4096 Feb 6 16:16 /var/lib/salt/pki drwx-- 7 root root 4096 Feb 6 16:10 /var/lib/salt/pki/master root@debian:~# ls -ld /var/cache/salt /var/cache/salt/master drwxr-xr-x 3 root root 4096 Feb 6 16:10 /var/cache/salt drwxr-xr-x 8 root root 4096 Feb 6 16:11 /var/cache/salt/master rroot@debian:~# dpkg -l | grep systemd | sed 's/ \+amd64 .*$//' ii libnss-systemd:amd64 240-5 ii libpam-systemd:amd64 240-5 ii libsystemd0:amd64 240-5 ii python-systemd234-2+b1 ii python3-systemd 234-2+b1 ii systemd 240-5 ii systemd-sysv 240-5 ``` The workaround is to manually change the owner/group to salt: root@debian:~# chown -R salt:salt /var/lib/salt/pki/master /var/cache/salt/master root@debian:~# systemctl start salt-master -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#919231: Salt-master unable to access directories
Hi Benjamin, Can you tell me what info you need? Anything I should check? Salt-master and systemd package info: $ apt policy systemd systemd: Installed: 240-4 Candidate: 240-4 Version table: 240-5 50 50 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages *** 240-4 450 450 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages 450 http://cdn-fastly.deb.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status $ apt policy salt-master salt-master: Installed: 2018.3.3+dfsg1-2 Candidate: 2018.3.3+dfsg1-2 Version table: *** 2018.3.3+dfsg1-2 450 450 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages 450 http://cdn-fastly.deb.debian.org/debian testing/main amd64 Packages 50 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status
