Power over demons or autorun in Linux
To implement autorun in Linux, quite a lot has already been written in different languages, but I have to search, because I tried to reduce most of it here. It does not fully explain the whole process from scratch, but provided enough information and links to make the automatic launch of programs in Linux a reality.
It is worth noting immediately that in order for the program to be a full-fledged service / daemon, it must be written appropriately ( link1 , link2 ). However, this is not always done, although perhaps this is not entirely correct.
There are several ways to autorun programs in Linux:
The first method is the easiest, but also the most problematic. The file rc.local is not in all distributions. It cannot set the launch level. If there are several programs recorded there, then it is difficult to manage them as services (except to start or stop everything at the same time). And, in the end, launching it undermines the stability of the system from hacking (examples can be easily found in a search engine).
')
The second method is quite exotic, he himself learned about it quite recently, although they write that they are used by many administrators. However, using it, it is impossible to operate with programs launched in such a way as demons, which is rather inconvenient. Yes, and clutter up the inittab ugly.
The latter method is currently the most "kosher", but a bit more complicated than the previous ones (perhaps at first glance). All the system demons are presented to them, which speaks for itself. Therefore, I will consider it below.
There is also a way to autorun graphics programs, but I will describe it at the end, separately from the others, because he has a non-demonic entity.
Immediately I’ll mention that I have Debian 6 and in other distributions the paths may differ slightly.
Autostart program as a demon
Usually, the system already has a lot of tips on how to do this, but still you have to climb different files and search the Internet for additional information. This does not mean that I will describe each letter here, but I will have to look less, I hope.
To get started is to look into the directory /etc/init.d. This contains launch scripts for all services, as well as two files for those who want to write the same for themselves:
README and skeleton
Skeleton contains a blank of the startup script with fairly detailed comments, and the README complements it quite well, despite its small size. You can also look at other files and try to find there something that will clarify an incomprehensible situation.
In the 6th debianʻe for launching daemon scripts, LSB (Linux Script Base) Init Standart is used. You can read more about it here . For systems where LSB is not used it is worth a look here .
Let's take a closer look at the skeleton file. The first thing to start with is, of course, "#! / Bin / sh", because init-script - the startup file. Next comes the commented headline:
It may seem that this is just extra information from the author, but it is not. What is indicated here is used when prescribing the script to the system. This is where the README file comes in handy, which shows that not all possible parameters are listed in the skeleton header. At least there are more:
All parameters and their full description (in English) can be seen here , and in Russian here and here (thanks to awzrno for new links ^ _ ^). I will add to the Russian version that in Required-Start: you can write $ all, then the current script will run after all the others (sometimes it is necessary). Also, X-Interactive: true indicates that this script can interact with the user by prompting you to enter something, such as a password.
Next in the skeleton is the initialization of variables used in the script itself. Some of them will need to be customized. Then check that the daemon itself exists and attempt to read the configuration file (their names must be specified in the variables above), then the rcS variables are loaded, and then one of the most interesting parts of the init file goes:
. / lib / lsb / init-functions
this is the definition of LSB functions of working with logs, LSB-status of the service, work with the process. In some distributions, this file may be located in the /etc/init.d directory. The names and some of the details can be found directly from the comments to the functions in this file, as well as here .
The next part is the script body itself. The body consists of conditional parts that are commands for the daemon: start, stop, restart / reload / force-reload, status. Someone allocates them in separate functions, someone not. In my opinion, the functions look more aesthetic and the code is more understandable. All these commands are combined by the case select statement, which selects the necessary piece of code for execution, depending on the command (parameter) with which the init script was launched.
Thus, to create a regular script, it is enough to substitute the necessary values into the variables at the beginning of the file and, perhaps, add a little code to the start / stop functions (for example, loading / unloading the driver).
After the file is ready, you need to copy it into /etc/init.d and add it to autoload:
update-rc.d <script name> defaults
(or insserv <script name> for debian 6 stable and above)
Remove from startup, you can:
update-rc.d -f <script name> remove
(or insserv -r <script name> for debian 6 stable and above)
Then you can also use the sysv-rc-conf commands in debian or service in the fedora core to enable / disable autoloading of the service.
Autorun graphics software without entering passwords
By itself, the realization of such a possibility lowers the OS security level, since anyone can enter. But there are situations when it is necessary. I will consider options here only for two main graphic managers, since there are no other handy ones.
KDE:
You can remove the login password request in the control center (kcontrol) -> system administration -> login manager -> convenience. There, select the user under which to enter (except for the root) and put the necessary checkboxes (allow autologin and login without entering a password).
To make the program autorun, you need to add a link to the launch file / script of the required software in the /home/<user>/.kde/Autostart directory.
Gnome:
Here you can also remove the password request at the control center (gnome-control-center) -> Login Screen. There, under the root (poke the lock, enter the password) select the user under which to log in (except the superuser).
To start the program again, in the control center, select Startup Applications -> Add and fill out a small form.
For both graphic managers:
If you need to run as a regular user, but from the root, then you still need to configure the rules in / etc / sudoers to run a specific program / set of programs on behalf of the superuser (it is recommended that you use manum for security using visudo). How to do this will not tell, because in man sudoers everything is well painted.
For now.
It is worth noting immediately that in order for the program to be a full-fledged service / daemon, it must be written appropriately ( link1 , link2 ). However, this is not always done, although perhaps this is not entirely correct.
There are several ways to autorun programs in Linux:
- write a program / script call in /etc/rc.local in the background (&) (may be in different locations in different distributions, for example, /etc/rc.d/rc.local) with redirected input / output streams in / dev / null For example, "/ home / user / my_prog 1> / dev / null 2> / dev / null &". Also, in addition, you can use the nohup command;
- make a call to / etc / inittab, according to the rules for its design. Unlike the first method, here you can specify the launch level for the program;
- write a script that allows you to start / stop / restart the program as a daemon, as well as receive information about its status.
The first method is the easiest, but also the most problematic. The file rc.local is not in all distributions. It cannot set the launch level. If there are several programs recorded there, then it is difficult to manage them as services (except to start or stop everything at the same time). And, in the end, launching it undermines the stability of the system from hacking (examples can be easily found in a search engine).
')
The second method is quite exotic, he himself learned about it quite recently, although they write that they are used by many administrators. However, using it, it is impossible to operate with programs launched in such a way as demons, which is rather inconvenient. Yes, and clutter up the inittab ugly.
The latter method is currently the most "kosher", but a bit more complicated than the previous ones (perhaps at first glance). All the system demons are presented to them, which speaks for itself. Therefore, I will consider it below.
There is also a way to autorun graphics programs, but I will describe it at the end, separately from the others, because he has a non-demonic entity.
Immediately I’ll mention that I have Debian 6 and in other distributions the paths may differ slightly.
Autostart program as a demon
Usually, the system already has a lot of tips on how to do this, but still you have to climb different files and search the Internet for additional information. This does not mean that I will describe each letter here, but I will have to look less, I hope.
To get started is to look into the directory /etc/init.d. This contains launch scripts for all services, as well as two files for those who want to write the same for themselves:
README and skeleton
Skeleton contains a blank of the startup script with fairly detailed comments, and the README complements it quite well, despite its small size. You can also look at other files and try to find there something that will clarify an incomprehensible situation.
In the 6th debianʻe for launching daemon scripts, LSB (Linux Script Base) Init Standart is used. You can read more about it here . For systems where LSB is not used it is worth a look here .
Let's take a closer look at the skeleton file. The first thing to start with is, of course, "#! / Bin / sh", because init-script - the startup file. Next comes the commented headline:
### BEGIN INIT INFO # Provides: skeleton # Required-Start: $ remote_fs $ syslog # Required-Stop: $ remote_fs $ syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Example initscript # Description: this file should be used to construct scripts # placed in /etc/init.d. ### END INIT INFO
It may seem that this is just extra information from the author, but it is not. What is indicated here is used when prescribing the script to the system. This is where the README file comes in handy, which shows that not all possible parameters are listed in the skeleton header. At least there are more:
# Should-Start: $ portmap # Should-Stop: $ portmap # X-Start-Before: nis # X-Stop-After: nis # X-Interactive: true
All parameters and their full description (in English) can be seen here , and in Russian here and here (thanks to awzrno for new links ^ _ ^). I will add to the Russian version that in Required-Start: you can write $ all, then the current script will run after all the others (sometimes it is necessary). Also, X-Interactive: true indicates that this script can interact with the user by prompting you to enter something, such as a password.
Next in the skeleton is the initialization of variables used in the script itself. Some of them will need to be customized. Then check that the daemon itself exists and attempt to read the configuration file (their names must be specified in the variables above), then the rcS variables are loaded, and then one of the most interesting parts of the init file goes:
. / lib / lsb / init-functions
this is the definition of LSB functions of working with logs, LSB-status of the service, work with the process. In some distributions, this file may be located in the /etc/init.d directory. The names and some of the details can be found directly from the comments to the functions in this file, as well as here .
The next part is the script body itself. The body consists of conditional parts that are commands for the daemon: start, stop, restart / reload / force-reload, status. Someone allocates them in separate functions, someone not. In my opinion, the functions look more aesthetic and the code is more understandable. All these commands are combined by the case select statement, which selects the necessary piece of code for execution, depending on the command (parameter) with which the init script was launched.
Thus, to create a regular script, it is enough to substitute the necessary values into the variables at the beginning of the file and, perhaps, add a little code to the start / stop functions (for example, loading / unloading the driver).
After the file is ready, you need to copy it into /etc/init.d and add it to autoload:
update-rc.d <script name> defaults
(or insserv <script name> for debian 6 stable and above)
Remove from startup, you can:
update-rc.d -f <script name> remove
(or insserv -r <script name> for debian 6 stable and above)
Then you can also use the sysv-rc-conf commands in debian or service in the fedora core to enable / disable autoloading of the service.
Autorun graphics software without entering passwords
By itself, the realization of such a possibility lowers the OS security level, since anyone can enter. But there are situations when it is necessary. I will consider options here only for two main graphic managers, since there are no other handy ones.
KDE:
You can remove the login password request in the control center (kcontrol) -> system administration -> login manager -> convenience. There, select the user under which to enter (except for the root) and put the necessary checkboxes (allow autologin and login without entering a password).
To make the program autorun, you need to add a link to the launch file / script of the required software in the /home/<user>/.kde/Autostart directory.
Gnome:
Here you can also remove the password request at the control center (gnome-control-center) -> Login Screen. There, under the root (poke the lock, enter the password) select the user under which to log in (except the superuser).
To start the program again, in the control center, select Startup Applications -> Add and fill out a small form.
For both graphic managers:
If you need to run as a regular user, but from the root, then you still need to configure the rules in / etc / sudoers to run a specific program / set of programs on behalf of the superuser (it is recommended that you use manum for security using visudo). How to do this will not tell, because in man sudoers everything is well painted.
For now.
Source: https://habr.com/ru/post/141003/
All Articles