package managers | service managers

Service Managers

TODO

• automatic (apt)
• brew services

Package Managers

brew

http://docs.brew.sh

brew is intended to be run as a non-privileged user. This is achieved by making /usr/local owned and writable by that non-privileged user.

{{brew}} installs the files for a package in {{/usr/local/Cellar/PACKAGE/VERSION}}. This path, including the package name and the version, is called a keg. {{brew}} creates symlinks in {{/usr/local/{bin,etc,include,lib,man,opt,share} pointing to files in /usr/local/Cellar.

A brew formula is a ruby file defining a subclass of Formula. The subclass defines a url attribute, which is the url of the tarball to be downloaded, and an install method, which is a script which performs the installation.

Brew formulas are kept in a git repository called a tap. brew makes a shallow git clone of each tapped repository in /usr/local/Homebrew/Library/Taps.

The formulas for the homebrew/core tap can be studied at https://github.com/Homebrew/homebrew-core/tree/master/Formula.

brew cask

brew cask is an extension for brew which is used to add macOS apps.

$ brew tap caskroom/cask
$ brew cask search chrome
$ brew cask install google-chrome
$ brew cask info google-chrome
$ brew cask upgrade google-chrome
$ brew cask uninstall google-chrome

brew services

apt

deb file format

yum

rpm package manager

apk

Alpine Linux package management

choco

To install choco, run the PowerShell as administrator and execute these commands:

PS> set-executionpolicy bypass
PS> iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

choco commands that modify the system (i.e. install or uninstall packages) must be run inside a PowerShell with administrative privilege.

Service Managers

A service manager is responsible for starting services when a system is booted.

In early versions of Unix (Research Unix and BSD), the init process ran shell scripts to initialize the system. The most important script was /etc/rc, but there was also /etc/rc.conf and the directory /etc/rc.d.

With System III and System V, instead of running a shell script, the init process read the /etc/inittab configuration file, which had lines in this format:

id:runlevels:action:process

Run levels determined which services would run. Typically the available run levels were:

To get the current run level:

$ who -r

The actions for each service (start, stop, and restart) were defined by a script in /etc/init.d with a format like this:

case "$1" in
    start)
      echo "starting"
      ;;
    stop)
      echo "stopping"
      ;;
    restart)
      echo "restarting"
      ;;
    *)
      echo "USAGE: start|stop|restart"
      ;;
esac

It was also possible to invoke these actions with the service command:

$ sudo service ssh stop

launchd

A launchd Tutorial

systemd

systemd

upstart

14.10 was the last version of Ubuntu to use Upstart as the init daemon.

windows services

How to: Create Windows Services

To start a program at login, put a shortcut to it in the Startup folder. To open the Startup folder, type Cmd+R and then shell:startup.

The Task Scheduler can run a program at login or at a scheduled time. Search for Schedule tasks to launch it. Then Action | Create Basic Task... At the end of the task creation, one can check the "Open properties dialog..." checkbox. This exposes all the settings available to shortcuts, including the ability to run the task with administrator privilege, which is something that cannot be done by dropping a shortcut into the Startup folder.