I'm running gitlab on RHEL 6, 5.4 was running fine for the past month or so -- I upgraded to 6.0 and things appeared ok, but users can no longer remove their groups from the groups settings. I get a 500 error.
I thought the error was part of the upgrade process, so deployed 6.0 as a new install, and everything works fine except for users can not remove groups from the groups settings. Administrators can remove groups via the admin panel, but not the groups settings.
odd thing, the logs look exactly the same, same auth token, same GET request. Beyond reading the log files, i'm not sure where to start debugging this issue. Any Ideas?
Maybe related is the following issue on the issue tracker: https://github.com/gitlabhq/gitlabhq/issues/4870
Related
I`ve created a new user and set that as an administrator but still failed to log in after times of trial. However, I find some information in console, but can not solve it after enable-disable plugins and multiple times of re-installation of rabbitmq-server.
BTW I am using CentOS 7.9.
Solved the question by changing browser from chrome to IE, edge also works.
So I installed a single host Openshift OKD v3.11 cluster. I installed it on a VM running Centos 7.8.2003.
It seems to have installed ok except that it continually streams verbose logs to /var/log/messages. Around 5 logs per second and all seem to be about throttling requests. Example of a typical log message:
******Jun 13 15:49:13 centos7 journal: I0613 14:49:13.011402 1 request.go:485] Throttling request took 196.341689ms, request: GET:https://172.30.0.1:443/api/v1/namespaces/openshift-service-cert-signer/serviceaccounts/service-serving-cert-signer-sa*****
The only reference I have managed to find is a question here but the access to the discussion is only available to those with deep pockets.
https://access.redhat.com/solutions/3348921
I assume these logs are nothing to worry about and so my main question is what is the "best"/cleanest/simplest/easiest way to ensure the Openshift cluster doesn't continue to fill up /var/log/messages but will still log any important messages there?
I would recommend looking at the root cause for this behavior. These messages indicate that there are a lot of requests coming to your API. Typically this is due to some application performing calls in a tight loop leading to this many messages. In your case check your openshift-service-cert-signer if you can see any warnings or an abnormal amount of log messages.
If you want to get rid of the throttling messages, you can increase the amount of Queries per second (QPS) for the API server: Recommended Practices for OKD Master Hosts (lower part).
The only reference I have managed to find is a question here but the access to the discussion is only available to those with deep pockets. https://access.redhat.com/solutions/3348921
I do not understand why you're saying that, as I can access that document with my free Red Hat account without any subscriptions. Have you tried with a free account as it says on the site?
Simon's answer was helpful but I've finally got to the bottom of this.
The problem was simply that the version of Docker I had installed was old. At the time of writing the latest version of Centos is 7.8.2003 and if you install that and then simply run "yum install docker" hoping that you'll get something at least reasonably new and certainly compatible with the rest of the linux installation, you'll probably be making a mistake.
The right thing to do is to follow the simple steps here:
https://docs.docker.com/engine/install/centos/
The reason I found the problem was because excessive logging of my openshift cluster wasn't the only issue. I started seeing strange behaviour of other containers. A process of trial and error narrowed down the issue to the default Centos version of docker. Once I followed the page above all my problem vanished including the original problem of /var/log/message getting hammered by openshift containers.
The main reason I decided to answer my own question was because surely someone else is going to be as impatient/thick as me and simply install Centos7 then try "yum install docker" without knowing they're about to enter a world of pain.
I am wrapping headless chrome using the excellent ChromeHtmlToPDF library. This we are using to dynamically render PDFs from a website. This works locally under IIS express, and also works on the server when recompiled as a console app, so the technology works. However running under IIS, chrome always exits immediately and a error of "one or more parameters are invalid", is returned.
You can fix this by passing Chrome a custom user profile directory:
chrome.exe --user-data-dir="C:\NewChromeProfile" ...
This directory will be created by the account under which Chrome is running, and therefore the account will have the permissions it needs.
After many many hours looking into this I finally solved it by running it under my own user, the restricted IIS user, then comparing the activity logs generated by the excellent microsoft process monitor.
I tracked it down to file permissions on one directory: C:\Windows\System32\config\systemprofile\AppData\Local\Google\Chrome\User Data
The app pool user needs write + modify permissions to this directory. It's up to you if you feel this is an acceptable security risk; however for us it is, for now.
This is where headless chrome stores it's crashpad directory. No amount of parameter fiddling seems to be able to dissuade it of this. That seems to be a bug.
Hope this helps someone else, I couldn't find anything on this anywhere.
Current version of Mamp Pro is 5.04 (15996). The available updates window says "Mamp 5.0.0 > 5.1. Update fails with a message saying Error: Update could not be validated. Please make sure you are using a secure network and try again."
Is it odd that the update does not say 5.0.4 > 5.1??
I have no idea what secure network is referred to. Everything on my computer is as secure as I can make it. Especially the wireless network.
I'm running High Sierra 10.13.6 on a new iMac.
This issue has affected other updates in the past. Not sure what the exact cause is, however, the workaround is straight forward.
1, Download the latest version manually from MAMP here.
2, Run the installer, closing MAMP beforehand.
3, Once restarted, the option to 'upgrade' will present itself, click install and it should work no problem.
Edit: Since 5.3 -> 5.4, there is no need for step 3. Just the first 2.
The Windows Store App Cert kit fails to start.
Normally the flow is:
Start App Cert Kit
Choose Windows Store Application
Choose App
Choose Certs to Run
Run Certs
Save results
Currently, it fails just before 'Choose App'.
I get this result:
I have tried uninstalling and reinstalling, installed all updates, running appcert.exe reset. All to no avail.
I think it may have to do with the same issue I get with the Windows Store app. I have 38 languages installed (our app supports all of them) and the Windows Store app doesn't like it. I've had to escalate with customer support repeatedly for this, and have not had it resolved properly. I wonder if the same issue applies here.
So I was unable to start the UI, but I was still able to run the appcert by manually calling it on the command line as described here. It worked fine. One thing to note is that between each attempt, make sure to run appcert.exe reset.