I'm trying to use bolt to reboot a server using command, this used to work but I'm now getting hit with an error:
bolt --format json command run 'sudo /sbin/reboot' --targets <a_valid_server> -u reboot_user --private-key /home/reboot_user/.ssh/id_rsa
terminated with exception (report_on_exception is true)
<snip...>
/opt/puppetlabs/bolt/lib/ruby/gems/2.7.0/gems/net-ssh-6.1.0/lib/net/ssh/transport/packet_stream.rb:75:in `select': closed stream (IOError)
The command works and the server reboots, but I don't need the error relating to the stream being cut short (this is expected behaviour).
I've looked at using plan run reboot as an alternative, but it seems to require a password (which isn't necessary).
Related
I'm using Django on Ubuntu 18.04.
I've got everything set up. And I type python manage.py run_huey in the server (through an SSH connection) to start huey, and it works.
However this is done through the command line through SSH and it will shut off when I close the SSH connection.
How do I keep run_huey running so that it will stay active at all times? Furthermore, after a system reboot, how do I get run_huey to automatically start?
You may explore supervisorctl utility for ubuntu, it keeps process running and can log into file and any other features. Google it.
I have an azure release pipeline to run my backend application on a DigitalOcean server.
I would like to use a tmux window so I can still see the terminal in case I need to debug the production backend.
tmux new-session -A -s tmuxWindowName
pkill java
mv backend/demo-0.0.1-SNAPSHOT.jar backend/backend.jar
java -Xmx800M -jar backend/backend.jar
tmux detach
but this doesn't work because the azure ssh connection is not attached to a terminal. I get the following error:
##[error]open terminal failed: not a terminal
I tried setting the term with "TERM=xterm" and googling this issue comes up with lots of people that are able to manipulate the SSH connection command but I can't since I use an SSH service connection.
What to do?
You can create a detached tmux session by adding -d to new-session which will not require a terminal (until you attach it which will be presumably from somewhere else).
I'm trying to leverage Gitlab Runner to execute builds on remote machine. I have the runner and am using the shell executor to kick off builds locally. Unfortunately, I'm receiving the following error when I kick off something:
Using Shell executor...
standard in must be a tty
ERROR: Job failed: exit status 1
I suspect this is occurring because the user that I'm passing in with the --user parameter can access tty. Any thoughts on how to get this working? The shell type is bash.
Check first if GitLab is doing a sudo once connected to the remote machine, to change user.
If that is the case, with visudo (on that remote machine), do:
Defaults:[username] !requiretty
If not, as in here, check if this is a JVM initialization issue.
I'm following step one of this docker tutorial.
I have installed ubuntu version 14.04 on a virtual box vm.
I intentionally downgraded by docker version so that when I type "docker version" I get Client version: 1.5.0. This is because the server I intend to communicate with is on 1.5.0.
When trying the command "docker run hello-world" I get the response:
"Post http:///var/run/docker.sock/v1.17/containers/create: dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?"
When running "sudo docker run hello-world" I get the response:
Cannot connect to the Docker daemon. Is 'docker -d' running on this host?
Can someone please explain to me what's happening and how can fix it?
Thanks.
Edit: I tried to follow the solution for Linux here
However,
I had tried to follow El Mesa's instructions in that post. However, when I got to running sudo docker -d I got an Error running DeviceCreate (createPool) dm_task_run failed. I don't think I need to start up a anything since I was just following the tutorial and the tutorial just did docker run hello-world immediately after installing docker
Pay attention to the text that immediately preceeds Are you trying to connect to a TLS-enabled daemon without TLS in the error message. In the question asked here it is permission denied, but it could also be no such file or directory (or possibly something else). The former is more likely to mean that the current user is lacking permissions to access docker, and the latter is more likely to mean that there is a problem with the docker service itself, including the possibility that it is not running at all.
So depending on what your situation is look for the answers on this and the
linked question page that focus on the respective problem area.
In my case (CentOS Linux release 7.1.1503 (Core), docker-1.7.1-108.el7.centos.x86_64) it was permission denied. I have added user to the docker group (sudo usermod -a -G docker user) but docker command still didn't work when I ran it under user, while it ran fine under sudo. What I forgot to do is log the user out and back in after adding it to the docker group, which is a step necessary for the group membership to take effect.
Restarting the machine will also solve this issue but it is a more drastic step and will work because it will imply log out / log in step. I would recommend trying to log out and back in before restarting because if it works it will give you more confidence that the group membership was the actual issue. And if it doesn't work you can always try restarting, though if it works after that it will probably work because restarting took care of some other underlying issue.
And one more thing in case you come across it and find yourself in doubt - when you first install docker and wish to add user to the docker group, you may notice (as I did in my case) that the "dockerroot" group exists but not "docker" group. Do not add user to the dockerroot group assuming that is the one you need. Instead create new docker group and add the user to it.
It may be that your docker daemon is not running.
I have ubuntu/docker on a desktop with wireless LAN.
It acts a bit finicky compared to the wired computers from which docker works OK, and duplicates the error message you reported:
$ docker run -it ubuntu:latest /bin/bash
FATA[0000] Post http:///var/run/docker.sock/v1.17/containers/create: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
However, after running:
sudo service docker start
It behaves correctly (at least until the host is rebooted):
$ docker run -it ubuntu:latest /bin/bash
root#2cea4e5f5028:/#
If the system is not starting the docker daemon on boot, as was the case here, then the docker daemon can be automatically started on boot by editing /etc/rc.local to do so. Add the line below immediately before the exit line. This will fork a new bash shell, wait 30 sec for the network setup, etc., to settle, and start the docker daemon. sudo is unnecessary here because /etc/rc.local runs as root.
( sleep 30; /usr/sbin/service docker start ) &
I just got a copy of a VM running SLES10 in which I have Postgresql. I try to start it using the command "postgresql start" but it returns an error message: "could not start postmaster". On the old machine it works fine. The only things I did since copying the machine was to change its IP Address and name, install VMWare Tools and delete the postgresql logs directory /.../postgres/pg_log (I recreated it afterwards). I tried restarting the machine but I still get the error. What can I do to determine the cause of the problem?
What can I do to determine the cause of the problem?
Check out the Postgres and system log files
My bet is that there is some problem with accessing the data directory e.g. the account running the postmaster does not have read/write access to that directory.
Edit
You can try to start Postgres "manually" (as opposed to the system provided scripts) by running:
pg_ctl -D /path/to/data/dir start
then you might be able to see error messages on the console. Make sure you are running this as the postgres user