The application (bin) loads the (service account) credentials fine when it has "normal" permissions. This is the run script:
#!/bin/bash
export GOOGLE_APPLICATION_CREDENTIALS=/home/user/config/gcloud/key.json
./bin
However when bin permission are changed:
chown root:root bin
chmod u+s bin
I get this error:
E1003 10:02:07.563899584 60263 credentials_generic.cc:35] Could not get HOME environment variable.
E1003 10:02:10.563621247 60263 google_default_credentials.cc:461] Could not create google default credentials: UNKNOWN:creds_path unset {created_time:"2022-10-03T10:02:07.563943484+09:00"}
Any advice would be appreciated.
Thanks.
As far as I can tell, this is expected behavior for gRPC. gRPC uses secure_getenv() to get all environment variables. In your case, that means the gRPC ignores the GOOGLE_APPLICATION_CREDENTIALS set.
You may need to change your application to use explicit service account credentials. Something like:
auto is = std::ifstream(filename);
auto json_string =
std::string(std::istreambuf_iterator<char>(is.rdbuf()), {});
auto credentials =
google::cloud::MakeServiceAccountCredentials(json_string);
auto publisher = pubsub::Publisher(
pubsub::MakePublisherConnection(
pubsub::Topic(project_id, topic_id),
google::cloud::Options{}
.set<google::cloud::UnifiedCredentialsOption>(
credentials)));
Related
I am trying to install dynamically windows services from my electron app.
For that i am using the node module "node-windows".
This looks like this:
service = new Service({
name: 'Watcher',
description: 'Watcher',
script: 'Watcher.js',
env: {
name: "SettingsPath",
value: storage.getDataPath()
}
});
service.on('install',function(){
service.start();
});
service.install();
this works very well on my dev machine.
The app requests for permission to create the service and installs it smoothly.
My Problem
If i compile the app to an exe the app doesnt request me for permissions and print an error
Permission Denied. Requires administrative privileges.
The app creates the service exe successfully at that time and doesnt do anything more.
Ok, so i started the app with admin privileges for testing this behavior.
Nice, the app doesnt show any error, creates the service exe AND ahhhhhh installed the service NOT.
Questions
Why does the app no longer ask for permissions when it is compiled?
Why isn't the service installed when the app is compiled?
If you need any additional information, write me a comment. And thanks for your time.
the path to the elevate.cmd in node-windows is incorrect for electron apps.
i have documented the way of trouble here
found some more problems to use the node-windows package:
cant use scripts from electron asar file (exclude files or diable
asar)
the executable path from the generated service config is wrong (its the packaged app executable, but must be node.exe or an equivalent executable)
service will only run on target system if node.js is installed, or you provide an equivalent
I am currently using Chef to deploy a Jenkins instance on a managed node. I am using the following public supermarket cookbook: https://supermarket.chef.io/cookbooks/jenkins .
I am using the following code in my recipe file to enable authentication:
jenkins_script 'activate global security' do
command <<-EOH.gsub(/^ {4}/, '')
import jenkins.model.*
import hudson.security.*
def instance = Jenkins.getInstance()
def hudsonRealm = new HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount("Administrator","Password")
instance.setSecurityRealm(hudsonRealm)
instance.save()
def strategy = new GlobalMatrixAuthorizationStrategy()
strategy.add(Jenkins.ADMINISTER, "Administrator")
instance.setAuthorizationStrategy(strategy)
instance.save()
EOH
end
This works great to setup security on the instance the first time the recipe is run on the managed node. It creates an administrator user with administrator permissions on the Jenkins server. In addition to enabling security on the Jenkins instance, plugins are also installed using this recipe.
Once security has been enabled, installation of plugins which do not yet exist (but are specified to be installed), fail:
ERROR: anonymous is missing the Overall/Read permission
I assume this is an error related to the newly created administrator account, and Chef attempting to install the plugins using the anonymous user as opposed to the administrator user. Is there anything that should be set in my recipe file in order to work around this permissions issue?
The goal here is that in the event a plugin is upgraded to an undesired version or uninstalled completely, running the recipe will reinstall / rollback any plugin changes. Currently this does not appear to be possible if I also have security enabled on the Jenkins instance.
EDIT It should also be noted that currently each time I need to repair plugins in this way, I have to disable security then run the entire recipe (plugin installation + security enable).
Thanks for any help!
The jenkins_plugin resource doesn't appear to expose any authentication options so you'll probably need to build your own resource. If you dive in to the code you'll see that the underlying executor layer in the cookbook does support auth (and a whole bunch of other stuff) so it might be easy to do in a copy-fork (and send us a patch) of just that resource.
We ran into this because we had previously been defining :jenkins_username and :jenkins_password, but those only work with the remoting protocol which is being deprecated in favor of the REST API being accessed via SSH or HTTPS and in newer releases defaults to DISABLED.
We ended up combining the logic from #StephenKing's cookbook and the information from chef-cookbooks/jenkins and this GitHub issue comment on that repo to get our plugin installation working after enabling authentication via Active Directory on our instances (we used SSH).
We basically pulled the example from https://github.com/TYPO3-cookbooks/jenkins-chefci/blob/e1b82e679074e96de5d6e668b0f10549c48b58d1/recipes/_jenkins_chef_user.rb and removed the portion that automatically generated the key if it didn't exist (our instances stick around and need to be mostly deterministic) and replaced the File.read with a lookup in our encrypted databag (or functional equivalent).
recipes/authentication.rb
require 'aws-sdk'
require 'net/ssh'
require 'openssl'
ssm = Aws::SSM::Client.new(region: 'us-west-2')
unless node.run_state[:jenkins_private_key]
key_contents = ssm.get_parameter(name: node['jenkins_wrapper']['secrets']['chefjenkins']['id_rsa']['path'], with_decryption: true).parameter.value
key_path = node['jenkins_wrapper']['secrets']['chefjenkins']['id_rsa']['path']
key = OpenSSL::PKey::RSA.new key_contents
# We use `log` here so we can assert the correct path was queried without exposing or hardcoding the secret in our tests
log 'Successfully read existing private key from ' + key_path
public_key = [key.ssh_type, [key.to_blob].pack('m0'), 'auto-generated key'].join(' ')
# Create the Chef Jenkins user with the public key
jenkins_user 'chefjenkins' do
id 'chefjenkins' # This also matches up with an Active Directory user
full_name 'Chef Client'
public_keys [public_key]
end
# Set the private key on the Jenkins executor
node.run_state[:jenkins_private_key] = key.to_pem
end
# This was our previous implementation that stopped working recently
# jenkins_password = ssm.get_parameter(name: node['jenkins_wrapper']['secrets']['chefjenkins']['path'], with_decryption: true).parameter.value
# node.run_state[:jenkins_username] = 'chefjenkins' # ~FC001
# node.run_state[:jenkins_password] = jenkins_password # ~FC001
recipes/enable_jenkins_sshd.rb
port = node['jenkins']['ssh']['port']
jenkins_script 'configure_sshd_access' do
command <<-EOH.gsub(/^ {4}/, '')
import jenkins.model.*
def instance = Jenkins.getInstance()
def sshd = instance.getDescriptor("org.jenkinsci.main.modules.sshd.SSHD")
def currentPort = sshd.getActualPort()
def expectedPort = #{port}
if (currentPort != expectedPort) {
sshd.setPort(expectedPort)
}
EOH
not_if "grep #{port} /var/lib/jenkins/org.jenkinsci.main.modules.sshd.SSHD.xml"
notifies :execute, 'jenkins_command[safe-restart]', :immediately
end
attributes/default.rb
# Enable/disable SSHd.
# If the port is 0, Jenkins will serve SSHd on a random port
# If the port is > 0, Jenkins will serve SSHd on that port specifically
# If the port is is -1 turns off SSHd.
default['jenkins']['ssh']['port'] = 8222
# This happens to be our lookup path in AWS SSM, but
# this could be a local file on Jenkins or in databag or wherever
default['jenkins_wrapper']['secrets']['chefjenkins']['id_rsa']['path'] = 'jenkins_wrapper.users.chefjenkins.id_rsa'
I am trying to find out how to create a new user in OpenShift enterprise.
According to the documentation (on https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/projects_and_users.html):
Regular users are created automatically in the system upon first login...
This sounds illogical. How does a user login if they dont have a username and password?
Can someone please clarify this - I'm sure there must be some command for creating a new user, but it is not clear.
Thanks
The OpenShift master-config (/etc/openshift/master/master-config.yaml) describes the configuration about authentication. By default the master-config shows something like this for the authentication-part:
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
This means that every user with every password can authenticate. By performing oc get users as system:admin you'll see all the users.
This configuration is not recommended. You're able to configure another form of authentication (htpasswd, ldap, github, ...).
I'm using htpasswd. So than you have to create a file (with htpasswd) which will contain your username + encrypted password. After that you'll need to edit your master-config.yaml. You have to tell it to use HTPasswdPasswordIdentityProvider and link to your file.
You can find those steps here. Don't forget to restart your OpenShift master after performing those steps: sudo service openshift-master restart (origin-master for origin).
After creating users you can assign roles to users
Log in with the default admin (system:admin) and assign roles.
I am creating a script for simply adding a user if OpenShift using HTPasswdPasswordIdentityProvider
wget https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64
mv jq-linux64 jq && chmod 755 jq
FILE=$(cat /etc/origin/master/master-config.yaml | python -c 'import sys, yaml, json; y=yaml.load(sys.stdin.read()); print json.dumps(y,indent=4, sort_keys=True)' | ./jq '.oauthConfig.identityProviders[0].provider.file')
FILE=$(sed -e 's/^"//' -e 's/"$//' <<<"$FILE")
htpasswd $FILE user1
ubuntu#ubuntu-14-lts:~$ export OS_USERNAME=admin
ubuntu#ubuntu-14-lts:~$ export OS_TENANT_NAME=admin
ubuntu#ubuntu-14-lts:~$ export OS_PASSWORD=admin
ubuntu#ubuntu-14-lts:~$ export OS_AUTH_URL=http://localhost:35357/v2.0/
Executed the command to create the Admin tenant
ubuntu#ubuntu-14-lts:~$ sudo keystone tenant-create --name admin --description "Admin Tenant"
got the below error
Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]
modified the url
ubuntu#ubuntu-14-lts:~$ export OS_AUTH_URL="http://localhost:35357/v2.0/"
re-run the same command and same error thrown
ubuntu#ubuntu-14-lts:~$ sudo keystone tenant-create --name admin --description "Admin Tenant"
Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]
Is there any Issues in running the command ?
The issue is probably with sudo - sudo may not maintain environment variables. Depends on configuration.
Why do you need sudo anyway? The keystone command does not require it. Either drop sudo, or add
--os-auth-url http://localhost:35357/v2.0/
to your command. You can also do
sudo -e keystone ...
You have failed to create a new user or tenant because you have no access to keystone... just like you need to login to mysql to create new tables and all, the same is here. The following steps will help you through:
# unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT
# keystone --os-username=ADMIN_USERNAME --os-password=ADMIN_PASSWORD --os-auth-url=http://controller:35357/v2.0 token-get
# source admin_creds //this is the file where you have saved the admin credentials
# keystone token-get
# source creds // this is the other file where you have backed up your admin credentials
now you can run your keystone commands normally. Please put a tick mark if it helped you! lol
i'm trying to run a simple executable using an Azure Web Role.
The executable is stored in the Web Role's local storage.
The executable produces a log.txt file once it has been run.
This is the method I am using to run the executable:
public void RunExecutable(string path)
{
Process.Start(path);
}
Where path is localStorage.RootPath + "Application.exe"
The problem I am facing is that when I open the local storage folder the executable is there however there is no log.txt file.
I have tested the executable, it works if I manually run it, it produces the log.txt file.
Can anyone see the problem?
Try setting an explicit WorkingDirectory for the process... I wonder if log.txt is being created, just not where you expect. (Or perhaps the app is trying to create log.txt but failing because of the permissions on the directory it's trying to create it in.)
If you remote desktop into the instance, can't you find the file created at E:\approot\ folder ? As Steve said, using a WorkingDirectory for the process will fix the issue
You can use Environment.GetEnvironmentVariable("RoleRoot") to construct the URL to your application root