Hello everyone i tried to activate tableau server but it said
tsm command not found
i tried to activate it with using command
tsm licenses activate -k myproductkey
Before i tried to run this command
sudo ./initialize-tsm --accepteula
and got this 'warning', i do't really get the 'warning' meaning of it maybe because my lack of english(?)
User 'root' has been selected as the user to add to the TSM authorized group, but
TSM does not allow root as a TSM-authorized user. You must either re-run this
script using 'sudo' while logged in as a normal user instead of root (most common
case), rerun this script with the '-a username' option to select a user other than
root to add to the group, or the '-g' flag to disable group addition completely
and add appropriate users to the group yourself. Canceling.
Why do i get this error and how to resolve it?
Use the -a flag to specify a user to be added to the tsmadmin and tableau groups instead of the user running this script. If you are installing with the root account, the you must specify the -a flag
Related
I was not able to build my dockerfile via jenkins until I added 666 permissions to /var/run/docker.sock. Now, I understand that this is more secure than adding the 'jenkins' user to 'sudoers' list. HOWEVER,
Is there still a better way ?
What are the ways in which this extra permission could be used to my disadvantage ?
What are the ways in which this extra permission could be used to my disadvantage ?
You have given permission for any user on the machine to become root without any password.
Is there still a better way ?
For Jenkins, you just need to run the following to give them access to the docker group so they can run docker commands. This will give the Jenkins user access to become root, so you'll want to be sure your Jenkins is secure or you do not care about users becoming root on this system:
sudo usermod -aG docker jenkins
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$
here's my situation.
I'm running Cruise Control as a Windows Service and trying to get it to connect to a Mercurial Repository on BitBucket over SSH.
I'm pretty sure that everything's configured OK (PuttyGen, Pagaent, etc). I'm remoting onto the server using the same account that I am using to run the service and if I issue hg pull -b ssh://#bitbucket.org// from a command line everything works. I added -v to the ssh configuration in mercurial.ini and I can see all of the steps that are taken.
If I run CC.NET from a command prompt then it builds fine. In the console window I can see the same logging from the SSH operation.
However, if I run CC.NET as a service (using the same user account that I'm logged in on) the call to BitBucket times out. I can find no way to work out why either. The build log doesn't help and neither do ccnet.log or ccnet.trace in the temp directory. I was expecting one of them to contain the logging from the SSH operation, but they don't.
Can anyone help? Is it that running as a service prevents it from connecting to Pagaent (I've started Pagaent by adding it to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run). When I did the pull from the command line I had to OK a dialog, but only once. Is it waiting on the same dialog now that it's running as a service?
Getting close to my wits end here.
Thanks
I did get it working in the end. The trick was to create the public key without a passphrase. When running as a service the solution has to be completely non-interactive and the passphrase option with pagaent.exe just isn't.
Here are the steps:
Use PutTTygen to generate a secure key WITHOUT a passphrase. If you really do need one then you can add it to the mercurial.ini file, but defeats the point for me as it's in plain sight anyway.
Copy a mercurial.ini to two locations: C:\Windows\System32\config\systemprofile and C:\Windows\SysWOW64\config\systemprofile. Probably only one of these was really necessary, but I didn't have the time to experiment. The first is the home directory for the system user when running 64 bit apps, the SysWOW64 location for 32 bit. Make sure that if you do the same as me then keep both files in sync - or go one further and work out which is the correct location.
Add something like this line under the [ui] key in both files:
ssh = "D:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 -C -batch -v -i "[Path to your ppk file]"
Add the passphrase to the end of the command if one was created in step 1.
Make sure that TortoisePlink.exe is specified, not Plink.exe. They should both be in the same directory.
Download psexec from http://technet.microsoft.com/en-gb/sysinternals/bb842062.aspx
Run d:\PSTools\PsExec.exe -s -i cmd.exe. This will open a command line as the system account in interactive mode.
Now do an hg pull, or hg clone or whatever.
A dialog should pop up with a confirmation message. This is a one time thing and the reason that you have to do the PsExec step. OK the dialog.
Now cc.net should be able to be run as a service under the local system account using SSH!
I am running a service called prunner on windows server 2012. I used the command sc to change the username and the password of the service:
sc.exe config myService obj= "sqa265\hero" password= "hero1"
The output of the command is saying that it have succeed but when I go to task manager in order to start the service I get: logon failure!!!
I tried to run the sc command under the user hero and under the user administrator but I still get the same error. But the very strange thing is that if I do the same thing manually via the task manager and service control pane I success and the service go to the state:running!!! But I need to automate this thing, so please any help?
You need to give the account "sqa265\hero" the SeServiceLogonRight permission. As you have noticed setting the credentials up through the control panel works, but what you might not have noticed is that if you tried to use the command line after using the control panel.
You can test this by setting the service back to the Local System account in the control panel, and then running your command-line again.
To fix this from a script, you can use the NTRights utility outlined in this MS knowledgebase article:
http://support.microsoft.com/kb/315276
After you install NTRights, you can run it like this:
NTRights.exe +r SeServiceLogonRight -u "sqa265\hero"
Combined with the sc config commandline you already have, the service should run with those credentials.
Further reading:
http://www.techrepublic.com/article/set-user-rights-using-the-ntrights-utility/5032903
I'm trying to setup Capistrano to do our deployments, but I now stumbled upon what seems to be a common assumption of capistrano users: that the user you SSH to the remote host will have permission to write to the directory of deployment.
Here, administrators are common users with a single distinction: they can sudo. At first, I thought that would be enough, since there are some configurations related to sudo, but it seems that's not the case after all.
Is there a way around this? Creating a user shared by everyone doing deployment is not an acceptable solution.
Edit: to make it clear, no deploy action should happen without calling sudo -- that's the gateway point that checks whether the user is allowed to deploy or not, and it should be a mandatory checkpoint.
The presently accepted answer does not fit that criteria. It goes around sudo by granting extra permissions to the user. I'm accepting it anyway because I've come to the conclusion that Capistrano is fundamentally broken in this regard.
I assume you are deploying to a Linux distro. The easiest way to resolve your issue is to create a group, say, deployers, and add each user who should have the permissions to deploy to that group. Once the group is created and the users are in the group, change the ownership and permissions on the deployment path.
Depending on the distro, the syntax will vary slightly. Here it is for ubuntu/debian:
Create the group:
$ sudo groupadd deployers
Add users to group:
$ sudo usermod -a -G deployers daniel
The last argument there is the username.
Next, update the ownership of the deployment path:
$ sudo chown -R root:deployers /deploy/to/path/
The syntax for is :. Here I am assuming that the user that currently owns the path is root. Update to which ever user should own the directory.
Finally, change the permissions on the deployment path:
$ sudo chmod -R 0766 /deploy/to/path/
That will allow users in the deployers group to read and write all files and directories beneath /deploy/to/path