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$
Related
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
everyone.
I hope that someone can help to answer my question.
I am joining a project in which I have to use various docker containers. I was told that I just needed to use docker-compose to pull down all the necessary containers. I tried this, and got two different errors, based on whether I used sudo or not. My machine is Ubuntu bionic beaver 18.04.4LTS
I have docker-engine installed according to the installation instructions for Bionic on the github page, and docker-compose is likewise installed according to its instructions. I did not create a "docker" group since I have sudo access.
We have two repos that I have to log in to before I can do anything. In order to prevent my passwords from being stored unencrypted in config.json, I followed this guide to set up a secure credential store:
https://www.techrepublic.com/article/how-to-setup-secure-credential-storage-for-docker/
However, rather than asking me for the password and/or passphrase mentioned in this article, the login process makes me enter the actual passwords to the repos. So, the secure credential store may not be working, which might be causing the problem.
At any rate, once I log in and the two commands show login succeeded, I then try to do a
docker-compose pull
on the repos. When I do
sudo docker-compose pull
I get this final error:
docker.errors.DockerException: Credentials store error: StoreError('Credentials store docker-credential-pass exited with "exit status 2: gpg: WARNING: unsafe ownership on homedir '/home/myuser/.gnupg'\ngpg: decryption failed: No secret key".')
an ls of the .gnupg directory is
myuser#myhost$ ls -lA ~ | grep gnupg
drwx------ 4 myuser myuser 226 Feb 9 13:35 .gnupg
gpg --list-secret-keys shows my keypair when I run it as myuser.
I am assuming that what is happening is that because I am running as sudo the user trying to access this directory is root, not myuser, and so it is failing. However, if I leave off the sudo
docker-compose pull
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))
I am guessing that this is because my normal user doesn't have the ability to connect to the docker daemon's Unix socket.
So, how do I make these play together? Is the answer to add a docker group so that the command still runs as myuser and not as root? or is there another way to do this?
Also, why is my credential store not asking me for the password set by docker-credential-pass or the GPG passphrase? I suspect these two are related. Perhaps the pull is trying to send my authentication tokens over again and can't because it doesn't have access to the secure credentials store.
All of the above are guesses. Does anyone know what is going on here?
Thanking you in advance,
Brad
I just wanted to follow up with a solution to this question that worked for me.
Firstly, you need to add your user to the docker group that was created during docker-engine's installation.
sudo usermod --append --groups docker your_user_name
Because I had already used sudo to try this, there were a few files that ended up being created by root.
So, you have to chown a few things.
sudo chown your_user_name:your_group_name ~/.docker/config.json
Note that for the group name I used
docker
but I'm not sure if that's necessary.
Then, there were files inside the ~/.password-store directory that needed to be changed.
sudo chown -R your_user_name:your_group_name ~/.password-store
Most of these files are already owned by you, but the recorded credentials are not.
Then, the magic that fixed it all. From
https://ask.csdn.net/questions/5153956
you have to do this.
export GPG_TTY=$(tty)
and it is this last that makes gpg work.
Then, you can log in to your repos if you have to without using sudo
docker login -u repo_user_name your_repo_host
and then log in with your repo password.
Note that I don't know why you have to use the repo password instead of using the stored credentials.
Once you log in, you should be able to do a
docker-compose pull
without sudo
from the directory where you want the containers to be placed.
Note that you will probably have to provide your GPG passphrase at first. I'm not sure about this because I had already unlocked the key by following the steps in the above link to check to see if docker-credential-pass had the right credential store password stored.
and that should do it.
I am attempting to start a Postgres SQL server on amazon Linux using the command
sudo service postgresql start
I installed the server using this method. I have added it here for simplicity
sudo rpm -i https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-6-x86_64/pgdg-ami201503-96-9.6-2.noarch.rpm
and then
sudo yum install postgresql96-server.x86_64
after which i did this to install the command line tools for postgres
sudo yum install postgresql96.x86_64 postgresql96-libs.x86_64
Any suggestions on how I can start the server ? I usually start the server using
the command
sudo service postgresql start
however its not working in this case as it says "Unrecognized service"
I then tried this
postgres -D /usr/local/pgsql/data
postgres: could not access directory "/usr/local/pgsql/data": No such file or directory. Run initdb or pg_basebackup to initialize a PostgreSQL data directory.
Having the same issue, or similar. May be I installed pgsql from source, don't remember. We could make our own service start files. How? Let's find out! >>RTFM<< starting with what we already know:
man service
which leads us to chkconfig(8), so
man chkconfig
and it gives us an option
chkconfig --add ${svcname}
to add a brand new service under a name we choose!
But before we do, we might actually want to check what's already there. With
service --status-all
we get a list of all known services and their run status. And I found "postmaster" in my list, and as you might know, the PostgreSQL master server to connect to used to be called "postmaster". Yet, when I try
service postmaster status
it also tells me it doesn't know such service. OK, forget it -- for now -- just let's move on with making our own! But I still want to peek what there is in run-level 3 (normal server run level). So I go
ls -1 /etc/rc.d/rc3.d |fgrep post
and there I find: "K36postgresql95"! So, accordingly our service name should be "postgresql95". Trying that:
service postgresql95 status
it says now "postmaster is stopped". Confusingly the name the service reports for itself both in service --status-all and when we individually inquire for it is different than the name used to actually address it in the service command. Good to know. Easy enough to search /etc/rc.d for the name of interest.
service postgresql95 start
now starts the service. And check with
psql -U ${pguser} ${pgdb}
and I find that working. So now all I need to do is enable that service at system boot to auto-start
chkconfig --levels 3 postgresql95 on
and that works, doesn't it?
PS: It doesn't matter that I happen to run version 9.5
I recently installed PostgreSQL 9.2.24 on Amazon Linux 2 and I had to initialize the database manually before being able to create ROLE and DATABASE as I normally would on Ubuntu.
// initialize database after installing with yum
$ sudo postgresql-setup initdb
// start
$ sudo systemctl start postgresql.service
I've updated jdk from 1.8_131 to 1.8_151 for CDH5. So i need to restart the cluster to make it take affect. In the begining i use cloudrea manager web page to restart, but it failed when zookeeper started which is the first step. Then I made a bad choice which is close cloudrea manager in terminal including kill -9 postgresql process. After that, i could't open the cloudrea manager web page.
I use following instructions to start the cluster.
service cloudera-scm-server-db start
service cloudera-scm-server start
service cloudera-scm-agent start
All of them are failed, because /var/log/cloudera-scm-server and /var/log/cloudera-scm-agent disappear.
So I creat these two files manually also include dg.log and cloudera-scm-agent.log
At this time, the server and agent could start. But server-db still can not. The next is some details.
Starting cloudera-scm-server-db (via systemctl): Job for
cloudera-scm-server-db.service failed because the control process
exited with error code. See "systemctl status
cloudera-scm-server-db.service" and "journalctl -xe" for details
journalctl -xe
The CM is using external DB. Failed to start embedded DB service, giving up
service --status-all
What i've done:
So, what should i do now? thank you thank you very much!!!
The above problem had been sovled.
If you open this /etc/cloudera-scm-server/db.properties file, which shown as below.
# cat /etc/cloudera-scm-server/db.properties
Auto-generated by scm_prepare_database.sh
#
Sat Oct 1 12:19:15 PDT 201
#
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=TXqEESuhj5
com.cloudera.cmf.db.setupType=EXTERNAL
EXTERNAL is the crux.
In my CDH service, I use embedded postgresql as my server database. But it's not recommended to use by cloudera offical. I'm a new man on Cloudera, so I made a mistake.
I wrongly use a command which only prepared for Cloudera Manager Server external database.
/usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm scm_password
The above command can config db.properties
As long as you run above command, com.cloudera.cmf.db.setupType will be set to EXTERNAL(For more details about this, you can find in Cloudera docs)
The most direct and effective way is to reset password of scm.
Then
update the password
set Type as EMBEDDED
make port 7432 listening(you can use netstat -nltp to check)
in db.properties.
#vim cat /etc/cloudera-scm-server/db.properties
Auto-generated by scm_prepare_database.sh
Sat Oct 1 12:19:15 PDT 201
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost:7432
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=new_password
com.cloudera.cmf.db.setupType=EMBEDDED
Now close all cloudera-scm service and restart in order server-db,server,agent.
If /var/log was cleared wrongly.
You can creat these files such as /var/log/cloudera-scm-server and /var/log/cloudera-scm-agent manually.
It is noteworthy that you should creat these file by user cloudera-scm, otherwise the log can not be written, and you won't find what error happened from log file.
Following the documentation guide, I have booted up a master and slave and I can see it connected via the logs:
Boot up master
$ domain.sh --host-config=host-master.xml
Boot up slave
$ domain.sh --host-config=host-slave.xml
I've also followed the steps to set up the admin user via the add-user.sh. Further research indicated that I should use the add-user-keycloak.sh script to add an initial admin user:
./add-user-keycloak.sh -u john
Press ctrl-d (Unix) or ctrl-z (Windows) to exit
Password:
Added 'john' to '../standalone/configuration/keycloak-add-user.json', restart server to load user
Reran the master and slave, but cannot login to admin console.
However, what's interesting is when I tried to boot up in standalone mode I was able to the admin console as john:
./standalone.sh
Is this a bug or am I missing something (most likely) that's not in the documentation?
Thanks in advance...
Figured it out, hope this helps somebody.
Before you start in domain cluster mode:
./domain --host-config=host-master.xml
./domain --host-config=host-slave.xml
you must first create the admin so you can log in to admin console using the --sc tag, otherwise add-user-keycloak.sh only adds the admin user for the standalone mode. To do that:
./add-user-keycloak.sh --sc ../domain/servers/server-one/configuration -u john -p password
if configuration folder does not exist, then create the directory.
The ./add-user-keycloak.sh script seems to be a little outdated. Currently (as of Keycloak 12.0.2 version) it creates keycloak-add-user.json file in ./domain/configuration/ directory - That is wrong!
The file should be in ./domain/servers/server-one/configuration.
Now you just have to move the file to that directory, restart the server and it should work properly.
I found this solution on this 2-year old email thread:
https://lists.jboss.org/pipermail/keycloak-user/2018-January/012642.html