[Bug]: apache could not be loaded

[MartinEmrich]

What happened?

After upgrading from 3006 to 3008.2, I experience this with apache_* states:

----------
          ID: ssl
    Function: apache_module.enabled
      Result: False
     Comment: State 'apache_module.enabled' was not found in SLS 'ssl.httpd'
              Reason: 'apache_module' __virtual__ returned False: apache module could not be loaded
     Changes:

I noticed depreciation of the module for 3009+, but in 3008 this should continue to work.

Even with -l trace, I see no reason why the module fails.

The apache packages are installed, and the helpers (like a2ensite, apache2ctl etc.) are present.

Type of salt install

Official deb

Major version

3008.x

What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)

debian-13

(corrected values, dropdown list did not contain them)

salt --versions-report output

Salt Version:
          Salt: 3008.2

Python Version:
        Python: 3.14.6 (main, Jun 11 2026, 02:19:05) [GCC 11.2.0]

Dependency Versions:
          cffi: 2.0.0
      cherrypy: 18.10.0
  cryptography: 48.0.0
      dateutil: 2.9.0.post0
     docker-py: Not Installed
         gitdb: 4.0.12
     gitpython: 3.1.50
        Jinja2: 3.1.6
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.1.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 24.0
     pycparser: 3.00
      pycrypto: Not Installed
  pycryptodome: 3.23.0
        pygit2: Not Installed
  python-gnupg: 0.5.6
        PyYAML: 6.0.3
         PyZMQ: 27.1.0
        relenv: 0.22.14
         smmap: 5.0.2
       timelib: 0.3.0
       Tornado: 6.5.7
           ZMQ: 4.3.5

Salt Package Information:
  Package Type: onedir

System Versions:
          dist: debian 13.5 trixie
        locale: utf-8
       machine: x86_64
       release: 6.12.95+deb13-amd64
        system: Linux
       version: Debian GNU/Linux 13.5 trixie

[jheiselman]

This is by design. See #65970. Many modules were moved to extensions and 3008 was the cut off for that.

[MartinEmrich]

@jheiselman the code explicitly says 3009, not 3008:

__deprecated__ = (
    3009,
    "apache",
    "https://github.com/salt-extensions/saltext-apache",
)

[jheiselman]

@MartinEmrich it also depends on apache.a2enmod being available as an execution function, but that doesn't exist anymore. I know that originally all of the apache modules were slated to be removed. My guess is that these may have been left in on accident or maybe someone prematurely removed the functions required to make these work.

def __virtual__():
    """
    Only load if a2enmod is available.
    """
    if "apache.a2enmod" in __salt__:
        return "apache_module"
    return (False, "apache module could not be loaded")

[MartinEmrich]

Ok, this looks ot me like the original (and documented) plan was to deprecate it with 3009, but someone overeagerly removed a dependency (the apache.a2enmod" function) already in 3008, leaving this non-functional.

I doubt that can or will be fixed with a 3008 fix release though, as it would hjave to reintroduce lots of apparently already removed code.

So even though this might turn into kind of a support request now, I am sure this might help others as well:
What's the proper way to use the "salt-extension" now? SSHing into the minion hosts and typing "salt-pip install XXX" of course defies the idea of centralised CM... How do I achieve the same (use apache.* states) as before with this? What to add or modify on the existing salt states for these target minions?

The documentation (https://docs.saltproject.io/en/master/topics/development/salt_extensions.html) sadly does not contain that topic, and even has a dead link to the Github repo).

Thanks!