Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Salt state to set system runlevel or target #46484

Open
craigafinch opened this issue Mar 11, 2018 · 6 comments
Open

Salt state to set system runlevel or target #46484

craigafinch opened this issue Mar 11, 2018 · 6 comments
Labels
Execution-Module Feature new functionality including changes to functionality and code refactors, etc. Platform Relates to OS, containers, platform-based utilities like FS, system based apps severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around State-Module
Milestone

Comments

@craigafinch
Copy link

Description of Issue/Question

I want to write a Salt state that installs and enables a minimal X Windows GUI on a CentOS 7 system. I need a state to ensure that a specific systemd default target has been set for the system. An equivalent command is:

systemctl set-default graphical.target

I also can't find a state to manage the legacy System V runlevels. Does such a state exist? If so, I am requesting to improve the documentation, because I searched pretty extensively and couldn't find anything. If it does not exist, please consider this to be a feature request.

Versions Report

Salt Version:
           Salt: 2017.7.4

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.21.1
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.1
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Aug  4 2017, 00:39:18)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: centos 7.4.1708 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-693.17.1.el7.x86_64
         system: Linux
        version: CentOS Linux 7.4.1708 Core
salt-minion 2017.7.4 (Nitrogen)
@garethgreenaway garethgreenaway added the Question The issue is more of a question rather than a bug or a feature request label Mar 12, 2018
@garethgreenaway garethgreenaway added this to the Blocked milestone Mar 12, 2018
@garethgreenaway
Copy link
Contributor

garethgreenaway commented Mar 12, 2018

@craigafinch Thanks for the report. I would suggest taking a look at the systemd execution module, which you can call from state files. It is also possible to configure the runlevel of the system using the system module and the init function within that module, https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.system.html#salt.modules.system.init

@craigafinch
Copy link
Author

@garethgreenaway Thank you for your reply. From what I can tell, neither of those modules will accomplish what I want. The systemd module only manages services, not targets. The init function in the system module sets the current runlevel of the target system. It doesn't set the default runlevel. For example, initcan force the system into a particular runlevel right now, but it can't configure the machine to go into that runlevel automatically on the next boot.

@gbrayut
Copy link

gbrayut commented Mar 3, 2019

It would be nice to have the default target managed by the module, but for now the following should work for systemd init systems:

# Ensure default target is set to 'multi-user.target' (non-graphical). Change to 'graphical.target' if that is what you prefer
systemd_default_target:
  cmd.run:
    - name: systemctl set-default multi-user.target
    - unless: test `systemctl get-default` = 'multi-user.target'

@stale
Copy link

stale bot commented Jan 9, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Jan 9, 2020
@stale stale bot closed this as completed Jan 16, 2020
@bdrx312
Copy link
Contributor

bdrx312 commented Dec 21, 2022

Please reopen. This appears to still be a valid issue. It would be useful to have a state to set the default and current target to be able to enable graphical.target for a desktop host for example.

@OrangeDog OrangeDog reopened this Jan 9, 2023
@OrangeDog OrangeDog added Feature new functionality including changes to functionality and code refactors, etc. Execution-Module State-Module Platform Relates to OS, containers, platform-based utilities like FS, system based apps and removed Question The issue is more of a question rather than a bug or a feature request stale labels Jan 9, 2023
@OrangeDog
Copy link
Contributor

Are there service managers other than systemd and init.d/upstart that have a similar concept?
I am wondering what a good cross-platform name would be for the functions.

@OrangeDog OrangeDog added the severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around label Jan 9, 2023
@OrangeDog OrangeDog modified the milestones: Blocked, Approved Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Execution-Module Feature new functionality including changes to functionality and code refactors, etc. Platform Relates to OS, containers, platform-based utilities like FS, system based apps severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around State-Module
Projects
None yet
Development

No branches or pull requests

5 participants