I am unable to create project in open shift. I created a project previously and deleted it. Looks like a project exists but unable to access or delete it. Seems like i am stuck. Also logging into the console https://console.preview.openshift.com/console/ doesn't show any existing projects.
I ran the following oc commands from the terminal.
Any suggestions on how to resolve this issue?
Thanks
XX:~ XX$ oc new-project test
Error from server: projectrequests "test" is forbidden: user XX cannot create more than 1 project(s).
XX:~ XX$ oc delete project test
Error from server: User "XX" cannot delete projects in project "test"
XX:~ XX$ oc status
Error from server: User "XX" cannot get projects in project "default"
XX:~ XX$ oc get projects
You need to give privileges/policies to your user which will allow the actions you want to perform.
If you are just in a proof-of-concept environment I would recommend the make your user cluster-admin in the whole cluster. This will give all the possible privileges to your user. Of course this in't recommended for every user in a 'real' environment.
First you need to authenticate with the 'default admin' which is created after the installation. This default admin-user isn't working with the normal user/password authentication. It's using a client certificate.
oc login -u system:admin --config=/etc/origin/master/admin.kubeconfig
Now you will see a list of the available projects (default, openshift management, etc). Now you're able to give cluster-roles to other users.
Make your user cluster-admin over the whole cluster
oadm policy add-cluster-role-to-user cluster-admin (youruser)
Now you have the cluster-admin privileges inside the whole cluster. You are also able to give privileges for some user in a specific project and not in the whole cluster. Than you have to use:
oadm policy add-role-to-user <role> <username> (in the current project)
This will give the role to a user, but only inside the project from where you've performed this command.
For more information about the avaiable cluster roles and policies I will point to the official documentation.
I raised a defect with Openshift Team as pointed out in the Support Link.
https://docs.openshift.com/online/getting_started/devpreview_faq.html#devpreview-faq-support
Here is the response i received from Support Team.
It seems that you have issued a bug and followed up for this already:
https://bugzilla.redhat.com/show_bug.cgi?id=1368862
After the cause is investigated, our operations team will sure clean up the project manually for you to allow you continue working with the developer preview
Latest update:
The project has now been cleaned up and you should be able to create a new project.
I am able to create Project in Openshift now.
Related
I am having trouble working through the Compute Engine Quickstart: Build a to-do app with a MongoDB tutorial. (edit: I am running the tutorial from within the compute engine console; i.e. https://console.cloud.google.com/compute/instances?project=&tutorial=compute_quickstart)
I SSH into the backend instance. I enter the "gcloud compute" command as copied from the tutorial. I am prompted to enter a passphrase. The following is returned:
WARNING: The public SSH key file for gcloud does not exist.
WARNING: The private SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
...
<< Identifying detail ommitted >>
...
**ERROR: (gcloud.compute.ssh) Could not fetch resource:
- Insufficient Permission**
I had run through this stage of the tutorial on a previous occasion with no problems.
I am working from a Windows 10 PC with the google-cloud-sdk installed. I am using google chrome. I have tried in both regular and incognito modes.
Any help or advice greatfully received!
DaveDub
It looks like the attempt to SSH is recognising the instance in your project, but the user doesn't have the required permissions to access the machine.
Have you tried running:
gcloud auth login
and completing the web-based authorization to ensure you are attempting to access the machine as the correct (authenticated) user? This process ensures the Cloud SDK you are running inherits the permissions of the user specified in the web-based authorisation. See here for more information on this.
It's also worth adding the link to the tutorial you are following to your question.
Besides the accepted answer, be sure you are in the correct gcloud project
gcloud projects list
Then
gcloud config set project <your-project>
I just ran into this for yet another reason. Google has always had poor handling of multi-user auth conflicts with their business products. Whatever you sign into a clean chrome session with 'first' gets a 'special', invisible role. I've noticed with gsuite that I get 'forced' into that first user when I try to access the admin panel, and the only way to escape is to make sure that whatever google user I use for the gsuite admin is 'first', or open an incognito window. I've seen this bug for years, can't believe it still exists.
Anyways, I ran into a similar issue. Somehow I was the wrong google user, so the link I got when copy/pasting out of 'connect with gcloud command' was implying wrong google user. Only noticed later when I just gave up and used the terminal that I was not my normal user... So, might look into that.
I am working for an IBM Business Partner and I am trying to complete a first PoC ICP installation. The basic installation has worked. I did not configure LDAP during the deployment but I am trying to add an LDAP connection in the console now, afterwards.
Unfortunately, I always fail. And there seem to be a number for limitations and/or bugs in the LDAP connection of ICP to the point of making it unuseable.
First, I would like to connect to an IBM Domino Directory as my LDAP server. Anyone who has worked with a Domino directory before knows that many Domino deployments have an O=Org suffix where Org is a company name containing spaces. For example, in our case it is "O=ARS GmbH". I would normally need to use this as the base DN (search base). However, ICP does not allow spaces in this field ... that need to be fixed! Any other LDAP client product I tried to connect to our Domino directory over many years was able to deal with spaces in the base DN.
Next, in a Domino directory usually the groups do have a different suffix (e.g. search base) than users. But ICP only offers ONE base DN field and not separate base DN fields for users and groups. Any other LDAP client ... DOES offer this. This needs to be fixed in ICP as well.
Next, the bind DN field does not allow some commonly used special characters which are often found in account names, such as the - character. This needs to be fixed as well (as it happens, the special user ID we have in our Domino directory which we use for LDAP binding is named dir-client ...).
Well, after hitting all those blocking problems, I finally tried to connect to our Microsoft Active Directory. This time I could successfully complete the LDAP connection. After doing so, I turned to "Users" and discovered I need to "Import group". However, no matter what I try to enter as (correct) values into the CN and OU fields, I only end up with an "internal server error".
Further more, after I could save the LDAP connection to Active Directory, I could no longer log in to the console with the builtin admin account! But since I could not import any users/groups, I could not assign that role to an LDAP account ... luckily, I had a VM snapshot of the master server and could thus revert to the state before.
This is really frustrating ...
I ran into identical issue when hooking up to an openldap server running in a docker container. It took me awhile to figure out the ICP pod and container where the log file is to get more information than "Internal Server Error".
Here is how to find the relevant ICP pod/container log:
Look for the "auth-idp" pods in the kube-system namespace. I use:
kubectl get pods --namespace=kube-system | grep auth-idp
If you are running an HA cluster, you will have a pod on each master node.
In my case I have 3 master nodes. If you are running only a single master, then you will have only one auth-idp pod.
Again, in an HA scenario, you need to figure out which is your current master node. (The easiest, crude way to do that is ssh to your master VIP and see which node you land on.)
Now figure out which pod is running on the current master node. On each pod I use:
kubectl describe pod auth-idp-vq5bl --namespace=kube-system | grep IP
or
kubectl get pod auth-idp-vq5bl --namespace=kube-system -o wide
The one on the IP that is the current master node is where the log of interest will be.
The container in the pod that has the log of interest is: platform-identity-mgmt
To actually see the log file use:
kubectl logs auth-idp-vq5bl --namespace=kube-system --container=platform-identity-mgmt
At that point you will be able to scroll through the log and see a more detailed error message.
In the case of my error the log indicated my search filter for the group was not working properly. I decided to mess with the user ID map and user filter so I used a user ID map of *:cn and a user filter of: (&(cn=%v)(objectclass=inetOrgPerson)) Once I changed those in the ICP LDAP configuration, the user import succeeded. However, later I realized the logins were not working because the login is based on a search on userid or uid. So I changed the user ID map back to *:uid and the user filter back to (&(uid=%v)(objectClass=inetOrgPerson)). That corrected the login issue. I added some users to my LDAP group and reimported the group and the import worked as well. At this point, I'm not sure what was going on with the original import not working until I messed with the user ID map and user filter. Go figure.
In my OpenLDAP directory instance my groups are all under ou=groups and each group member is listed as, e.g., cn=Peter Van Sickel,dc=ibm,dc=com. I had to edit the group member to get it using the full DN of an actual user.
My users are all directly under the root DN: dc=ibm,dc=com.
As to specific issues with other LDAPs, it is my experience that each has its own set of idiosyncrasies to get things working as desired.
whilst 'hardening' the accounts - namely removing or toning down accounts with editor permissions on the projects I removed editor from what appears to be the kubernetes account that container engine uses on the back end of gcloud commands.
Once you remove the last role from an account it vanishes - hard lesson to learn!
Removed editor
serviceAccount:386242358897#cloudservices.gserviceaccount.com
It meant I initially couldn't deploy because it couldn't access container registry.
So I deleted the cluster and recreated expecting the account to get recreated. That failed due to insufficient permissions.
so I manually removed the compute instances (it wouldn't have permissions to recreate them), then templates and then the cluster.
As the UI now thinks you have no clusters it looks like you are back to the beginning. So I ran my scripts and they failed.
ERROR: (gcloud.container.clusters.create) Opetion [https://container.googleapis.com/v1/projects/xxxx/zones/europe-west2-b/operations/operation-xxxx'
startTime: u'2017-10-17T17:59:41.515667863Z'
status: StatusValueValuesEnum(DONE, 3)
statusMessage: u'Deploy error: "Not all instances running in IGM. Expect 1. Current actions &{Abandoning:0 Creating:0 CreatingWithoutRetries:0 Deleting:0 None:0 Recreating:1 Refreshing:0 Restarting:0 Verifying:0 ForceSendFields:[] NullFields:[]}. Errors [https://www.googleapis.com/compute/beta/projects/xxxx/zones/europe-west2-b/instances/gke-xxxx-default-pool-xxxx:PERMISSIONS_ERROR]".'
targetLink: u'https://container.googleapis.com/v1/projects/xxxx/zones/europe-west2-b/clusters/xxxx'
zone: u'europe-west2-b'>] finished with error: Deploy error: "Not all instances running in IGM. Expect 1. Current actions &{Abandoning:0 Creating:0 CreatingWithoutRetries:0 Deleting:0 None:0 Recreating:1 Refreshing:0 Restarting:0 Verifying:0 ForceSendFields:[] NullFields:[]}. Errors [https://www.googleapis.com/compute/beta/projects/xxxx/zones/europe-west2-b/instances/xxxx:PERMISSIONS_ERROR]".
Updated property [container/cluster].
when I try to create through UI I get this
Permission denied (HTTP 403): Google Compute Engine: Required 'compute.zones.get' permission for 'projects/xxxx/zones/us-central1-a'
Have done a number on it!
My problem is that I don't see a way of giving permissions back to whatever account it is trying to use (as I cannot see that account if it exists) nor can I see how to attach a new service account with permissions that are needed to whatever is doing the work under the hood.
UPDATE:
So ...
I recreated the account at the organisation level. Gave it service account role there because you cannot modify the domain of the accounts at project level.
I have then modified that at the project level to have editor permissions.
This means i can deploy a cluster but ... still cannot create load balancer - insufficient permissions
Error creating load balancer (will retry): Error getting LB for service default/bot: googleapi: Error 403: Required
'compute.forwardingRules.get' permission for 'projects/xxxx/regions/europe-west2/forwardingRules/xxxx', forbidden
the user having the problem this time is:
service-xxx#container-engine-robot.iam.gserviceaccount.com
So ...
I played with recreating accounts etc. Eventually got Kubernetes working again.
A week later tried to use datastore and discovered that AppEngine was dead beyond dead.
The only recourse was to start a new project from scratch.
The answer to this question is (some may laugh at its self evidence, but we are all in a rush at some point).
DO NOT CREATE USER ACCOUNTS OR GIVE THEM PERMISSIONS BEYOND WHAT THEY NEED BECAUSE DELETING THEM LATER IS REALLY NOT WORTH THE RISK.
Thankyou for listening :D
We updated our Couchbase from 4.6 Community edition to 5.0.0-2873 Enterprise Edition for testing purposes and our software using the java-client started throwing InvalidPasswordException when trying to open a bucket.
As I've found, every newly created bucket has authType='sasl' and a randomly generated saslPassword.
I've tried creating a bucket using the CLI instead of the GUI:
couchbase-cli bucket-create -c localhost:8091 -u Administrator -p password --bucket=general --bucket-ramsize=1300 --bucket-type=couchbase --bucket-password=
I got the following error:
ERROR: unrecognized arguments: --bucket-password=password
I also tried the bucket-edit function with the same result.
According to the documentation the argument should be valid.
I also tried using the REST API to change bucket authentication (and similarly password), but even though this didn't throw any erros, the authType and the password remained the same.
curl -X POST -u Administrator:password -d 'authType=none' http://<host>:8091/pools/default/buckets/general
Again, according to the documentation this should work.
If I query the bucket information for the sasl password and provide that for the openBucket function then the connection works, however we really don't want to use this feature in our system.
So, any other ideas how it would be possible to remove the bucket authentication in our 5.0EE Couchbase setup?
In Couchbase 5.0 we no longer support bucket passwords and have moved to using role based access control when connecting to buckets. This means that in 5.0 the standard (pre-production) way to connect to a bucket is by using the Administrator user and password that you created when setting up the cluster. In case you're unsure what the Administrator user is, it is the user you create when you first go through the Couchbase setup wizard or the it is the username and password you specify on the command line when running the couchbase-cli cluster-init command.
One thing to note is that using the Administrator user/password is the standard pre-production workflow. I would recommend that when you go into production you create separate users for your application which only have access to cluster resources they need to access in the cluster. You can do this by going to the Users tab in the Administration Console and creating a new user and giving them the Full Bucket Access role which is the standard role that applications should have.
You might now be saying to yourself that this all sounds great, but when I use the Administrator user/password I still am having issues. If this is the case the reason is because you have Couchbase 5.0, but your SDK is not new enough to handle the new RBAC authentication mechanism in 5.0. The workaround for this is to create a user in the Users tab with the same name as the bucket and give that user the Full Bucket Access role. You can then use this user to authenticate.
One last thing to mention is that during an upgrade from a pre-5.0 cluster to a 5.0 cluster Couchbase will automatically create a user for each bucket. The each user will have the same name as one of the buckets and the password for that user will correspond to the bucket password. This is done mainly to ensure that there is no application downtime during an upgrade. After upgrading the cluster the next step should ideally be to upgrade the Couchbase client library to have it start using RBAC authentication.
If you need to stay with old approach and no password you can use cochbase-cli with --rbac-username and --rbac-password "", but you need to specify password as "", e.g.
./couchbase-cli user-manage -c localhost:8091 -u Admin -p password --set --rbac-username <UserForBucket> --roles bucket_full_access[<BucketName>] --rbac-password "" --auth-domain local
SonarQube v5.2
I am trying to create a technical user (one that is authenticated locally and not against our LDAP). I have added a user name to the conf/sonar.properties file and restarted SonarQube. But, when I log in (as an administrator), the new user doesn't show up in the Administration | Security | Users list. We have two previously defined technical users (including admin) which do show up.
The admin guide doesn't say much http://docs.sonarqube.org/display/SONARQUBE52/Authentication.
Is there another step needed to create a technical user?
You need to manually create the user in SonarQube, it won't be automatically at startup.
Note that the SonarQube version you're using is no more supported, you should migrate to the latest LTS version 5.6.X => local users (previously known as technical users) are better managed :
- No more need to update sonar.properties
- You just have to create a user from the web server, this user will automatically be considered as a local user.
I've updated http://docs.sonarqube.org/display/SONAR/Authentication in order to remove the "Technical" word.