OS: RHEL6 and CentOS6
When starting a service such as ntpd (/etc/init.d/ntpd start), the process will have the selinux context:
system_u:system_r:ntpd_t:s0
If I have a cgi that is setuid of root that will allow stop/start of services through a web interface, when starting through this cgi (executing same /etc/init.d/ntpd start) the process has the selinux context:
system_u:system_r:httpd_t:s0
My cgi file selinux context:
system_u:system_r:unconfined_exec_t:s0
How can I make it so when services started through the httpd/cgi suid process executing the /etc/init.d script to start a service, has the correct type on the process? (ntpd_t in this example)
The reason is that there are transitions between domains in SELinux, so it means which process and what context type runs/starts what process and from what file (what SELinux context). So the sysV or systemd starts service by default from systemd_t or something so, but your web server try to start the service from httpd_t. Google how to change domain in SELinux.
Related
I'm currently running a python script as a systemd service. Is there any way to "switch" into the service and take control of the script? The script has a menu but runs calculations in the background in another thread. Most likely not, so is there a way to run a python script 24/7, start on boot, restart on crash etc (just like systemd service) but be able to take control of it after I connect to the server via SSH, so I can manipulate the app?
One solution you could try would be to edit the systemd configuration to launch the process in screen or tmux, then attach that when logging in via SSH.
For instance, in the systemd unit, you might have:
[Service]
Type=single
ExecStart=tmux new "command"
Using Type=single will treat the tmux command as the main process, which would be killed if you stop it with systemctl stop systemprocess
The ExecStart=tmux new "command" creates a new tmux session with the command inside of it.
You can then attach to it using tmux attach as the same user the systemd unit is running as (I believe this is root by default).
I would like to make tomcat auto start with a non-root user while system booting. I have created a daemon.sh under folder /etc/init.d . And I executed chkconfig tomcat on. The linux server is in another city. I access it by ssh. And I cannot reboot server to test it.
The problem is if tomcat start failed while booting, I am afraid that linux server cannot not be start succesfully. That whould be a disaster for me. Perhaps my worry is unnecessary.
How to avoid this problem?
I have packaged a Debian file of our software. Now there is a .sh script that needs to be started to run the program/software. This .sh script actually runs a Django server and few more services.
To actually start this application, we need to run the .desktop file in the menu. This .desktop file in the menu is associated with the .sh script mentioned above. This prompts the terminal and asks for the password. Once the password is given, this will start the services and the terminal stays active.
To close this service completely, we need to kill the process by finding the PID of the process and killing it from the terminal. But now I want to kill this process when I close the terminal.
How can I do that?
If you are trying to create a service (some program that runs in the background), you should create use your system's mechanism for this.
The traditional one, would be a scrip in /etc/init.d/, a more modern approach is to use systemd.
E.g. a file /etc/systemd/system/myservice.system
[Unit]
Description=My Service
[Service]
Type=simple
# you could run the service as a special user
#User=specialuser
WorkingDirectory=/var/lib/myservice/
# execute this before starting the actual script
#ExecStartPre=/usr/lib/myservice/bin/prestart.sh
ExecStart=/usr/bin/myservice
Restart=on-failure
[Install]
WantedBy=multi-user.target
You can then start/stop the service (as root) using:
systemctl start myservice
resp.
systemctl stop myservice
You can have dependency chains of services, so starting myservice will automatically start myhelper1 and myhelper2.
Checkout the manpage systemd.unit.5
When the controlling terminal is closed, the foreground process group should receive a SIGHUP signal. If your target process is already expected to be in the foreground, then it may be that it is catching or ignoring SIGHUP (the default behavior for a process receiving that signal is to terminate).
my group and I are running a server that is based upon Django and uses mod_wsgi to run an Apache server. We will not be working on this project after it is over, so I am attempting to set up cronjob similar functionality to check if the apache server has shut down(system restart or power failure), and if it has, will restart the server for me. I've found documentation on how to check if an apache server is down and restart the server if it is, but our server uses https and thus our start command is pretty verbose.
Can I simply use the functionality provided in these examples:
https://askubuntu.com/questions/277389/cron-job-to-restart-apache
https://www.digitalocean.com/community/tutorials/how-to-use-a-simple-bash-script-to-restart-server-programs
Or do I need a much more complicated process to make this happen?
The command we use to initially start the server is
python manage.py runmodwsgi --host 0.0.0.0 --port 8001 --https-port 8000 --ssl-certificate (certificate Location) --server-name (Domain Name)
I'm pretty new to Linux and using both Mod-wsgi as well as Apache so any help is greatly appreciated.
I suppose it is not good way to resolve this problem.
I recommend you use monit (https://mmonit.com/). It is cool program for checking services.
apt-get install monit
Apache restart configuration directives:
check process httpd with pidfile /var/run/httpd.pid
group apache
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed host 127.0.0.1 port 80
protocol http then restart
if 5 restarts within 5 cycles then timeout
You are better off using the --setup-only option to mod_wsgi-express or the Django integration for it, to generate the configuration but not run it. Then as others have mentioned, integrate it into the system service manager.
The two commands for starting and stopping the Apache/mod_wsgi instance would be apachectl start and apachectl stop, where apachectl is that which was generated when running with the additional --setup-only option.
When running it as a system service, also make sure you use the --server-root option to specify a more persistent location for the generated configuration. Do not use the default under /tmp if running for anything but temporary development sessions as some Linux systems will remove files under /tmp causing things to start failing after a while.
Also, since under a service manager it would generally be starting as root, particularly if listening on port 80 is a requirement, ensure you use the --user and --group options to specify what user/group your Python web application should run as.
Read:
https://pypi.python.org/pypi/mod_wsgi
for more details of the --setup-only option and start-server commands for generating the configuration. Because you are using the Django integration, you will need to use the --setup-only option.
For more informed helped, bring your issue to the mod_wsgi mailing list. The mod_wsgi-express way of running Apache/mod_wsgi is new enough that unlikely that anyone here is really going to know much about it.
There is no need to do this at all. There is no reason to start up Apache manually; once it's installed as a system service, Ubuntu will start it up automatically on restart or crash.
You should reflect on why you feel the need to do this for Apache specifically, and not any of the other system services you depend on, such as the database.
I need to understand the difference between starting a command using init.d script and service start.
For example what is the difference between
/etc/init.d/nginx start and service nginx start.
They do the same thing except service runs the script in a controlled environment. From the service(8) man page:
DESCRIPTION
service runs a System V init script in as predictable environment
as possible, removing most environment variables and with current
working directory set to /.
ENVIRONMENT
LANG, TERM
The only environment variables passed to the init scripts.
Furthermore:
Calling /etc/init.d/* scripts directly is deprecated by facts because:
On latest Debian/Ubuntu distro ( and derived ), sysvinit ( which was default init system ) has been replaced by either upstart or systemd. Thus, if one of the service is managed using either an usptart job or systemd unit configuration file, calling /etc/init.d/* will be a NOOP in sense that the script will exit without further information.
Instead, users must use the service command to start/stop/restart services. The service command is a wrapper which will invoke the right script, in as predictable environment as possible, whatever the init system in use ( sysinit, upstart or systemd ).