Which user is a systemd service run as by default in a centos if no user is explicitly specified?
My assumption was that the service would then run as root. However, there seem to be differences in terms of permissions if you explicitly specify User=root.
[Unit]
Requires=docker.service
After=docker.service
[Service]
User=root
...
ExecStartPre=/usr/local/bin/docker-compose down -v --remove-orphans
ExecStartPre=/usr/local/bin/docker-compose rm -fv
ExecStart=/usr/local/bin/docker-compose up --remove-orphans
[Install]
WantedBy=multi-user.target
In this specific case, a docker compose up is executed in the systemd service. The docker images are obtained via the ECR. The credentials for this are provided using amazon-ecr-credential-helper.
When trying to get the image from the ECR, the error message you get is "no basic auth credentials".
But since everything works as desired if you specify the user=root in the systemd service, I assume that the configuration of the amazon-ecr-credential-helper works with docker and that the problem is to be found in the systemd context.
Does any of you have any idea what the explicit specification user=root does?
From man systemd.exec:
User=, Group=
Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID
as argument. For system services (services run by the system
service manager, i.e. managed by PID 1) and for user services of
the root user (services managed by root's instance of systemd
--user), the default is "root", but User= may be used to specify
a different user...
The default is already root. Specifying User=root does not change anything except perhaps to be explicit so a reader understands that this is really being run by root. It makes no difference to systemd
Related
Getting access denied error while running the systemctl command in a pod.
Whenever try to start any service, for example, MySQL or tomcat server in a pod, it gives access denied error.
Is there any way by which I can run systemctl within a pod.
This is a problem related to Docker, not Kubernetes.
According to the page Run multiple services in a container in docker docs:
It is generally recommended that you separate areas of concern by
using one service per container
However if you really want to use a process manager, you can try supervisord, which allows you to use supervisorctl commands, similar to systemctl. The page above explains how to do that:
Here is an example Dockerfile using this approach, that assumes the
pre-written supervisord.conf, my_first_process, and my_second_process
files all exist in the same directory as your Dockerfile.
FROM ubuntu:latest
RUN apt-get update && apt-get install -y supervisor
RUN mkdir -p /var/log/supervisor
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY my_first_process my_first_process
COPY my_second_process my_second_process
CMD ["/usr/bin/supervisord"]
That's a rather short question. The 'systemctl' command does try to talk to the systemd daemon which is not running in a pod by default (it could however). Running multiple services is yet another question about service management. It both cases it could help to use a tool like the docker-systemctl-replacement overwriting /usr/bin/systemctl and registering it as the init-CMD of the container.
I setup a Centos systemd service but I'm not able to read the kubernetes env variables. If I run the bash inside the pod I'm able to see env (such as _UI_SERVICE_PORT_TCP_443=443, KUBERNETES_PORT_443_TCP_ADDR=10.202.0.1 or container=docker) but not when I execute a bash script as a service inside the container.
I also tried Type=forking and ExecStart=/bin/bash believing the executed bash will inherit the kubernetes env but it's clean.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/ LANG=en_US.UTF-8 SHLVL=1
_=/bin/printenv
[Unit] Description= script after boot on k8s After=e.service
[Service] Type=forking ExecStart=#BINDIR#/virtual_service.py
Your problem seems to be related to the handling of environment variables in services. From my understanding, the env vars are stripped when running as a service, so you won't have access to what bash sees when your process runs as a service..
This answer provides a good description and some workarounds.
Hope this helps!
I found the answer for this.
/proc/1/environ contains the environment and i managed to read the env while i'm running as a service.
hope this will help someone in the future.
I've developed a Netty application that allows connections through TCP from various devices. However i'm not entirely sure what is the best way to deploy the application for production use. Right now i package it up in a JAR file and run a screen session on the target server like so:
screen -S Nettyjava -jar Server-Netty.jar
Is this the recommended way to deploy it or is screen the best option available?
screen is not the right tool to run a service in production. If the system has to reboot, you will have to relaunch the service by hand. On most current linux distributions, you can handle this with a systemd service unit file. This allows you to define the working directory, the user, the command to run... Here is an example taken from the Unix & Linux StackExchange question configure java daemon with systemd
[Unit]
Description=Some job
After=network.target
[Service]
WorkingDirectory=/home/user/tmp/testout
SyslogIdentifier=SocketTest
ExecStart=/bin/sh -c "exec java -jar /home/user/programming/tests/java/core/SocketTest/SocketTest.jar"
User=dlt
Type=simple
[Install]
WantedBy=multi-user.target
A good practice consists in creating a specific user for running the service and to restrain his right on the filesystem.
I want to set target to service in CentOS7 (Systemd).
I want to know following.
How to set target to service.
How to show target of service.
In other words, I want to know substitution for following commands.
$ sudo chkconfig --level=2345 mysql on (<- set runlevel)
$ chkconfig --list mysql (<- show runlevel)
I understood that "runlevel" in CentOS6 changed "target" in CentOS7and I should use "systemctl" command.
But problems were not solved.
I heard that following command is replacement for "chkconfig --list"
, but I can't check target and can't set target.
systemctl list-unit-files
Setting the target is done in the unit file for the service. For example:
[Install]
WantedBy=multi-user.target
Then you run systemctl enable $service_name to create a symlink which enables the service to start as part of a particular target. You could also create the symlinks manually. The enable command will print out the paths of the symlinks it's creating.
I think systemctl --reverse list-dependencies $service is the way to find what services and targets depend on a specific services to boot.
I configured project with privateKey authentication. I have server and one node, where i can run all operations, which doesn't require sudo. On the node i have user test, who can run commands with sudo. I'm using this user for running jobs from server on node. When i run the job i get response from node, that i need to type password for user test. There is configuration in rundeck, which allows automate this process. Here is how my project.properties file looks:
#Project Test configuration, generated
#Tue Dec 08 10:52:45 UTC 2015
project.name=Test
resources.source.1.config.requireFileExists=false
project.ssh-authentication=privateKey
resources.source.1.config.includeServerNode=true
resources.source.1.config.generateFileAutomatically=true
resources.source.1.config.format=resourcexml
resources.source.1.config.file=/home/vagrant/projects/Test/etc/resources.xml
project.ssh-keypath=/opt/test/keys/test_prv_key
project.description=Test project
resources.source.1.type=file
sudo-command-enabled=true
sudo-password-storage-path=/home/vagrant/var/storage/content/keys/test.password
sudo-prompt-pattern='^\[sudo\] password for .+:.*'
The problem is, that rundeck doesn't match the pattern for sudo command and connection is dropped in 3s after asking the password.
Upd.
Did not find solution, therefore give user access to sudo without password (NOPASSWD in sudoers)
I encountered a similar problem and after trying every combination of configuration options specified in the documentation I gave up and used this hack instead:
echo #option.sudoPassword# | sudo -S my_command
Try to apply the below config in "/etc/rundeck/project.properties"
project.sudo-command-enabled=true
project.sudo-command-pattern=^sudo$