I have a cron job that needs to be run under ec2-user on my EC2 instance and it needs to be able to write to the standard log files for my web app. However, the log files are owned by webapp (as per normal).
I've successfully changed the permissions on the log files so that they are accessible by both the owner and the group webapp:webapp. But where I'm running into trouble is when I try to add the ec2-user to the webapp group.
I can do it fine in SSH with sudo usermod -a -G webapp ec2-user but when I try to add this command via EB container-commands, I get an error saying that you must have a tty to run sudo. Running the command without sudo gives me /bin/sh: usermod: command not found.
Anybody know of any other way to be able to add ec2-user to the webapp group via the Elastic Beanstalk deployment config.
Not sure about the issue with the sudoers file, but generally a cleaner way to add a user to a group (than manually executing a command) is to use the users section of the .ebextensions file. For example, in .ebextensions/something.config:
users:
ec2-user:
groups:
- webapp
You should not use sudo, the deploy script is ran by root.
Also, this is a server command, do it in the commands section instead of container commands section.
commands:
01_set_user_role:
command: "usermod -a -G webapp ec2-user"
You need to run this command from a container_command before executing any commands with sudo:
echo Defaults:root \!requiretty >> /etc/sudoers
In context (in .ebextensions/yourconf.config)
container_commands:
001-enableroot:
command: echo Defaults:root \!requiretty >> /etc/sudoers #disables error related to needing a tty for sudo, allows running without cli
Related
I'm trying to create a TeamCity build agent on docker. i pulled the official image and tried to start it with default configurations with below command
docker run -d --name teamcity-agent -e SERVER_URL="http://teamcity-server-instance:80" -v /opt/docker/teamCity/teamcity_agent/conf:/data/teamcity_agent/conf jetbrains/teamcity-agent
but it exits with code 1 every time i run it and below are the logs for that
can anyone suggest a solution to this
Thank you in advance
Did you try changing the mod? sudo chmod 666 /opt/docker.
This gives the File owner, The group members, and others read + write permission over that directory.
you can check the permissions you have via: ls -la /opt
I can't run docker commands as my own user. But I know that the service is running because I can run commands as sudo:
$ docker ps
Cannot connect to the Docker daemon at unix:///run/user/1000/docker.sock. Is the docker daemon running?
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
(snip) (snip) (snip) 13 days ago Up 2 hours (healthy) 9000/tcp (snip)
I am successfully running a few containers, and they each work, but I have another not listed in 👆 that I need to run as my own user.
I am part of the docker group:
$ groups
docker www-data video tim
I'm not sure what else to check. I do have this:
$ echo $DOCKER_HOST
unix:///run/user/1000/docker.sock
Also:
$ uname -r
5.4.0-65-generic
$ docker --version
Docker version 19.03.6, build 369ce74a3c
This is on Ubuntu 18.04.5 LTS
As you followed all the post installation steps correctlly, as far as I can tell, my best guess is that has to do with the DOCKER_HOST environment variable.
Does it help if you unset DOCKER_HOST? (Perhaps you need to log out, so it has an effect.)
On my system, docker ps works with sudo, but once I set DOCKER_HOST=unix:///run/user/1000/docker.sock, I get the same error as you.
For some background, here is a question about the DOCKER_HOST variable. In essence, that variable should normally not be set.
Return to the default sock path (unix:///var/run/docker.sock), by unsetting DOCKER_HOST and removing an errant config files:
unset DOCKER_HOST
rm -r ~/.docker
The Docker Daemon must be restarted after creating the “docker” group:
sudo services docker restart
Then, ensure you add your current user to the group:
sudo usermod -a -G docker $USER
This will ensure your user has access to the socket file.
UPDATE: 12/2022
Recently had to do this on Ubuntu 22.04 LTS and ran into the login shell persisting the previous group.
Since the UI manages the login shell, a restart is either required, or you need to replace the process with exec. You can work around this issue, until you restart, by replacing your current shell process: (use $0 instead, if $SHELL doesn't match your preferred shell)
exec sudo -u $USER -E $SHELL
I am working with Jenkins and I want to start a script with forever using Jenkins with a different user named aroot.
So my build configuration I write this command:
sudo -u aroot forever start -a --uid 'server' bin/www
It works fine but forever still tries to access the jenkins user and when I try to see the scripts running under forever by using the command:
forever list
I see nothing. Why does this happen? I have changed the user to aroot but it still tries to start the script under jenkins user. What should I do here?
I even tried changing the default jenkins user to aroot but after this, the Jenkins just does not restart.
you should not need the forever thing going. just enable it from systemctl
# systemctl enable jenkins.service
how you get it to run as different users is by editing this file.
# vi /etc/sysconfig/jenkins
and changing this line to whatever user you want.
JENKINS_USER="aroot"
When you restart it will be running as that user but you will need to chown all files in /var/lib/jenkins so it has the correct ownership.
I have Ubuntu 18.04. and after installing docker i added my user to docker group with the command
sudo usermod -aG docker ${USER}
and logged in
su - ${USER}
and if I check id, my user is added to docker group.
But when I reopen the terminal i cant do docker commands without sudo unless i explicitly do su ${USER}
also, I can't find docker group with the default user.
What am I missing here?
#larsks already replied to the main question in a comment, however I would like to elaborate on the implications of that change (adding your default user to the docker group).
Basically, the Docker daemon socket is owned by root:docker, so in order to use the Docker CLI commands, you need either to be in the docker group, or to prepend all docker commands by sudo.
As indicated in the documentation of Docker, it is risky to follow the first solution on your personal workstation, because this just amounts to providing the default user with root permissions without sudo-like password prompt protection. Indeed, users in the docker group are de facto root on the host. See for example this article and that one.
Instead, you may want to follow the second solution, which can be somewhat simplified by adding to your ~/.bashrc file an alias such as:
alias docker="sudo /usr/bin/docker"
Thus, docker run --rm -it debian will be automatically expanded to sudo /usr/bin/docker run --rm -it debian, thereby preserving sudo’s protection for your default user.
I have a service that I want to start with system startup. I have built a ap#.service definition for it as a template, because there could be many instances.
Defined in the root systemd, this works well, and starts and stops the service with the system. The service instance is installed with systemctl enable ap#inst1 as would be expected. Root is also able to start and stop the service without problems. The service runs in its own account (myuser), not root, controlled by User=myuser in the ap#.service template.
But I want user 'myuser' to be able to start and stop their own service, without compromising system security.
I switched to using a user systemd, and enabled lingering with loginctl enable-linger myuser. I then enable the service defined in the ~myuser/.config/systemd/user directory. The service now starts and stops cleanly with the system, as designed. If I log in to a terminal as 'myuser', systemctl --user start ap#inst1, and systemctl --user stop ap#inst1 both work perfectly.
However, if I log in as a different user (user2) and perform sudo su - myuser in a terminal, then systemctl --user commands now fail with error message "Failed to get D-Bus connection: no such file or directory".
How do I enable systemctl --user to work after a sudo su - myuser command to switch the user?
I found the answer on another site with further searches using different terms.
The solutions needed was to provide the shell with information to reach the correct DBUS for the user.
By adding the following environment variables to the shell before running systemctl --user, the DBUS problem is eliminated, and systemctl operates correctly.
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
To ensure that the DBUS_SESSION_BUS_ADDRESS is available in the sudo shell, I added the environment variables to ~/.bash_profile of the target userid. This requires that a login shell ( sudo su - myuser or sudo -l myuser) is created in order to create the correct environment.
Alternatively, add the creation of the environment variables to ~/.bashrc (or equivalent for other shells). The environment will then be established anew for all shell creations.
systemd 248 (released March 2021) introduced support for the syntax -M myuser# for specifying another user.
$ sudo systemctl --user -M myuser# start ap#inst1
A side-note:
If you want to get an interactive login shell for the user myuser
$ sudo machinectl shell myuser#