Drone error: Login Failed. User limit reached - drone.io

Recently, some colleagues have started working in my team, so I showed them the basics of drone, but when they wanted to access our drone server they get that message:
Login Failed. User limit reached
We login via Github and they have access to the repositories. In fact, one of them did commit something which run the job without any problems, he just could not see it as he could not login. Any ideas on why does he get that message? I have checked our configuration and it doesn’t seem to have any limit to the number of users on drone.

Looks like I reached the limits of the trial license.
I checked the limits of my current license at the /varz URL (eg. https://cloud.drone.io/varz)
Also, about the users seats and repos: https://docs.drone.io/enterprise/usage/

Related

Configuring the failed login attempts control policy

I am configuring the failed login attempts control policy to lock the account after three attempts with the following configuration
When performing the test after 3 attempts in the 4, the account is blocked for a few minutes, but not for 60 minutes as it appears in the rangeSeconds=3600 parameter.
Also, when I open a different web browser where I did the first test, the system allows me to enter and should not allow it since the account should be blocked.
Please know if another person has already made this configuration and how to do it.
Thanks for your help.

Cannot get past Login screen in Modx Revo 2.7.0pl

My problem: Users don't get further from login screen. They show up as logged-in in the manager log and Whos online, but the login screen just shows an empty login-form after submit login.
It all worked for several days after last upgrade to 2.7.0.pl, and then suddenly stopped.
Error log: (ERROR # /home/verkejml/public_html/core/model/modx/moduser.class.php : 362) PHP warning: session_regenerate_id(): Cannot regenerate session id - session is not active.
Tried:
Delete all files in core/cache.
Delete browser cache and cookies.
Different browsers and different users with different permissions, up
to admin.
Reading all forum questions about the same problem, no luck.
I have one admin user logged in, and I'm super afraid to log out that user, if I'm not able to login again, and therefor can't access the manager again.
My setup:
Modx Revo 2.7.0pl.
Just a few "standard" extras installed, all updated.
PHP 7.0.33
Question: Is there anything I can do without reinstall everything, and by that be forced to log out my only logged in user?
I got the answer from the incredibly engaged and knowledgeable problem solver in the Modx community, BobRay:
My (old) settings:
session_cookie_path => (blank)
anonymous_sessions => No
Changed to
session_cookie_path => /
anonymous_sessions => Yes
Thanks to BobRay for great help!
Well, there are any problems with MODX 2.7 + PHP 7.* nowadays.
Here are other possible steps which may help you:
Disable anonymous_sessions setting and relogin again
Remove modSessionHandler value for session_handler_class and relogin again
I have one admin user logged in, and I'm super afraid to log out that user, if I'm not able to login again, and therefor can't access the manager again.
Honestly I don't know how to test without logging out ((

Azure Storage account opening issue

I have an RBAC access to Azure portal. Previously I was able to access storage account and blobs successfully. But suddenly I am unable to access container or blob. I am able to view the storage account listed for me, but cannot access it.
I get error as "Something went wrong while getting your resources. Please try again later." I tried refreshing, clearing cache and signing again. Still facing same issue.
In portal I get notification as "Refresh the browser to try again.
Microsoft_Azure_Storage extension failed to load"
There is no network issue, as I can access all other resources from portal at same point.
Also there is no Unauthorized access issue notification.
Unable to figure out what is the issue.
Any help highly appreciated.
I'd recommend checking the activity logs for recent RBAC changes in case if they happened and someone changed access to containers/blobs, here's how: https://learn.microsoft.com/en-us/azure/role-based-access-control/change-history-report
I'd also recommend checking the list of roles/access you currently have by following these steps: https://learn.microsoft.com/en-us/azure/role-based-access-control/change-history-report
If you are still experiencing the issue, in case if you have a co-admin, check if they are facing the same issues. if they are, please send me your subscription ID, link to this thread, and include attn Adam in the subject to AzCommunity[at]microsoft.com ?
I'll enable a free support ticket to quickly escalate it.
I hade the same issue while I was using VPN from Bangladesh. When I disconnected from the VPN, it works fine.

Keycloak unable to synchronize with LDAP: Synchronization ignored as it's already in progress

I am using Keycloak with LDAP integration. I was synchronizing users successfully from ActiveDirectory. Then at some point when synchronizing all users, I started getting the error: Synchronization ignored as it's already in progress (in fact it is part of the success message) and users are not synchronised. Just before starting to get this error, I played a bit with LDAP provider Edit mode (not sure it's related to the problem).I set it to WRITEABLE, then to UNSYNCED. I deleted one of the users that were previously imported from LDAP, then I switched back to READ_ONLY and tried to get back the deleted user but instead got the synchronization issue. Any idea why I am receiving this error?
Turns out that this was a simple configuration issue. User federation provider property "Import Users" must be On. If users are synced, and then this property is turned Off, further attempts to synchronize users will get the message "Success! Sync of users finished successfully. Synchronization ignored as it's already in progress". The solution is to turn "Import Users" back to On. Thanks to the smart QA engineer who discovered this:)
did you checked the realm settings? I saw the same error and looking in the keycloak logs, showed me that a email in LDAP was not unique. So I disabled "login via email" in realm settings and "allowed duplicate emails" and it's working again

kubernetes on gcp: removed role, account gone how to restore permissions?

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