[BUG] file.manage doesn't see file as symbolic link

[speedytom]

Description file.manage doesn't see file as symbolic link. It seems like regression from 3006.5

Setup root@salt:~# dpkg -l "salt*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================================================ ii salt-api 3007.0 amd64 Generic, modular network access system ii salt-common 3007.0 amd64 shared libraries that salt requires for all packages ii salt-master 3007.0 amd64 remote manager to administer servers via salt

tok-le-wildcard-key: file.managed:

• name: /etc/ssl/tok-le-wildcard.key
• source: salt:///etc/ssl/tok-le-wildcard.key
• makedirs: True
• user: root
• group: root
• mode: 644

root@work-18-09:~# salt-call state.apply misc.ssl-tok-le-wildcard [ERROR ] Source file salt:///etc/ssl/tok-le-wildcard.key not found in saltenv 'base' [ERROR ] Source file salt:///etc/ssl/tok-le-wildcard.crt not found in saltenv 'base' local:

      ID: tok-le-wildcard-key
Function: file.managed
    Name: /etc/ssl/tok-le-wildcard.key
  Result: False
 Comment: Source file salt:///etc/ssl/tok-le-wildcard.key not found in saltenv 'base'
 Started: 10:12:59.933144
Duration: 20.868 ms
 Changes:   

---

lrwxrwxrwx 1 salt salt 48 Sep 15 10:48 tok-le-wildcard.crt -> /home/salt/.acme.sh/tok.ipp.cas.cz/fullchain.cer lrwxrwxrwx 1 salt salt 53 Sep 15 10:49 tok-le-wildcard.key -> /home/salt/.acme.sh/tok.ipp.cas.cz/tok.ipp.cas.cz.key Steps to Reproduce the behavior (Include debug logs if possible and relevant)

Expected behavior This should work without problem. It seems like regression from 3006.5.

One more mote. There is minor bug in the showed version: root@salt:~# salt-master --version salt-master 3006.2 root@salt:~# salt --version salt 3007.0 (Chlorine)

root@salt:~# dpkg -S salt-master salt-master: /etc/init.d/salt-master salt-common: /opt/saltstack/salt/salt-master salt-master: /lib/systemd/system/salt-master.service salt-master: /usr/share/doc/salt-master/copyright salt-common: /usr/share/fish/vendor_completions.d/salt-master.fish salt-common: /opt/saltstack/salt/share/man/man1/salt-master.1 salt-master: /usr/share/man/man1/salt-master.1.gz salt-master: /usr/share/doc/salt-master salt-master: /usr/share/doc/salt-master/changelog.gz salt-master: /usr/bin/salt-master

[AndersonMartins1]

The file.managed state in SaltStack does not recognize the file as a symbolic link. This issue appears to be a regression from version 3006.5.

root@salt:~# dpkg -l "salt*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================================================ ii salt-api 3007.0 amd64 Generic, modular network access system ii salt-common 3007.0 amd64 shared libraries that salt requires for all packages ii salt-master 3007.0 amd64 remote manager to administer servers via salt

State Configuration

tok-le-wildcard-key: file.managed:

• name: /etc/ssl/tok-le-wildcard.key
• source: salt:///etc/ssl/tok-le-wildcard.key
• makedirs: True
• user: root
• group: root
• mode: 644

Reproducible Steps

Run the state file using salt-call state.apply misc.ssl-tok-le-wildcard. Expected Behavior

The file.managed state should recognize the file as a symbolic link and perform the required actions without any errors. This issue appears to be a regression from version 3006.5.

[AndersonMartins1]

There is a minor bug in the version displayed:

root@salt:# salt-master --version salt-master 3006.2 root@salt:# salt --version salt 3007.0 (Chlorine)

The package salt-master is located at the following paths: /etc/init.d/salt-master /opt/saltstack/salt/salt-master /lib/systemd/system/salt-master.service /usr/share/doc/salt-master/copyright /usr/share/fish/vendor_completions.d/salt-master.fish /opt/saltstack/salt/share/man/man1/salt-master.1 /usr/share/man/man1/salt-master.1.gz /usr/share/doc/salt-master /usr/share/doc/salt-master/changelog.gz /usr/bin/salt-master

This indicates where files related to the salt-master package are located on the file system. Here is the description of each path:

/etc/init.d/salt-master: This is the location of the salt-master service init script. It controls the starting, stopping, and restarting of the service. /opt/saltstack/salt/salt-master: This path contains the configuration files and other resources specific to salt-master. /lib/systemd/system/salt-master.service: This is the systemd unit file for the salt-master service. It defines how the service should be managed by systemd. /usr/share/doc/salt-master/copyright: This is the salt-master copyright file, which provides information about the copyright and license of the software. /usr/share/fish/vendor_completions.d/salt-master.fish: This is the salt-master completion file for the Fish shell. It provides automatic completions for salt-master related commands. /opt/saltstack/salt/share/man/man1/salt-master.1: This is the page 1 (man1) manual for the salt-master command. Provides detailed documentation on how to use the command. /usr/share/man/man1/salt-master.1.gz: This is another page 1 (man1) manual for the salt-master command, but in compressed (gzip) format. /usr/share/doc/salt-master: This directory contains additional documentation and resources related to salt-master. /usr/share/doc/salt-master/changelog.gz: This is the changelog file for salt-master, in compressed (gzip) format. /usr/bin/salt-master: This is the location of the salt-master executable, which is the actual program that manages and administers the servers through SaltStack.

[Akm0d]

To be clear, the file path "/etc/ssl/tok-le-wildcard.key" is a symlink that points to elsewhere on your system, but salt is pointed to the symlink for file.manage?

[Akm0d]

@speedytom ^^

[speedytom]

Yes, you are right.