I have to create a plugin for Grafana. For that i cloned the code from Github and followed this. I have managed to build the grafana but having issue in running the server. I am getting the error
Grafana-server Init Failed: Could not find config defaults, make sure homepath command line parameter is set or working directory is homepath
I did find this issue at issue. I have copied the "sample.ini" and re-named it to "custom.ini" and used the following commands in the bin folder made after building the grafana
.\grafana-server.exe --config D:\Go-UpdatedWorkSpace\grafana\conf\custom.ini
.\grafana-server.exe D:\Go-UpdatedWorkSpace\grafana\conf\custom.ini
.\grafana-server.exe -config D:\Go-UpdatedWorkSpace\grafana\conf\custom.ini
.\grafana-server.exe -config "D:\Go-UpdatedWorkSpace\grafana\conf\custom.ini"
.\grafana-server.exe --config "D:\Go-UpdatedWorkSpace\grafana\conf\custom.ini"
.\grafana-server.exe "D:\Go-UpdatedWorkSpace\grafana\conf\custom.ini"
But non of them worked. I am still getting the error
Grafana-server Init Failed: Could not find config defaults, make sure homepath command line parameter is set or working directory is homepath
What am i doing wrong ? I am new to Grafana development, any help would be much appreciated.
I have managed to resolve the issue. I ran the Grafana locally by using following command
./grafana-server.exe -config "D:\Go-UpdatedWorkSpace\grafana\conf\defaults.ini" -homepath "D:\Go-UpdatedWorkSpace\grafana".
I executed this command on the "bin" folder created after building the grafana with GoLang. (There is also a bin folder inside the homepath directory, i think we can use any of then "bin" folder). Issue was that i was not providing "homepath" in the command. "homepath" is the directory where grafana code is cloned.
In case someone looking for Mac, the below works. I tried with grafana version 8.x . For default install, No need to give -config as -homepath should take care. this could run from any location.
/grafana-install-path/bin/grafana-server -homepath /grafana-install-path web
Related
I have a specific request of running Helm template command in environment with filesystem access read-only on the regular location where Helm cache is stored (I'm executing this command inside AWS Lambda).
An error that I get is:
Error: mkdir .cache: read-only file system
Now, to overcome this problem, my idea is to:
either disable cache when running specific command
point HELM_CACHE_HOME to location which is not read-only (mounted location from EFS file system)
Unfortunately, I was unable to find a way to disable a cache and following command doesn't work (even when running it locally, without any lambda environment):
mkdir -p /tmp/helm/.cache/helm
HELM_CACHE_HOME=/tmp/helm/.cache/helm helm template elasticsearch elastic/elasticsearch --dry-run
ls -la /tmp/helm/.cache/helm
total 0
Any way to do this?
Thanks
Eventually, I've figured out that I've used incorrect environment variable.
For Helm 3, correct variable is:
XDG_CACHE_HOME
Reference: https://helm.sh/docs/faq/#xdg-base-directory-support
However, even if this works, docs say that HELM_CACHE_HOME should also work (which is not the case).
The specific error is:
11634 verbose node v12.14.1
11635 verbose npm v6.13.4
11636 error Error while executing:
11636 error /home/openbmc/code/openbmc/rpi-build/tmp/hosttools/git ls-remote -h -t https://github.com/novnc/noVNC.git
11636 error
11636 error fatal: unable to access 'https://github.com/novnc/noVNC.git/': error setting certificate verify locations:
11636 error CAfile: /opt/poky/3.1/sysroots/x86_64-pokysdk-linux/etc/ssl/certs/ca-certificates.crt
11636 error CApath: none
Testing manually:
If I run the command manually in a new shell, it fails the same, indicating it is using a default certificate path. If I run it in the shell with the environment for bitbake, it works. This is because GIT_SSL_CAINFO is properly defined.
The behavior suggests that when git is run from hosttools, it is not using the bitbake shell environment, because that environment defines a correct GIT_SSL_CAINFO with a path to the buildtools area with a valid certificate.
I assume that poky is creating a special environment for running hosttools independently from my main shell. If this is the case, there needs to be a way to add GIT_SSL_CAINFO into this environment, which I have no idea how to do.
I poked around other targets looking for clues but could not find anything that suggested to me this variable would be defined.
A search of the tree on GIT_SSL_CAINFO did not turn anything up, but it is possible there is a variable with another name.
perhaps there is a way to set http.sslCAInfo to take the place of GIT_SSL_CAINFO?
The context:
I first compiled up the raspberry pi build and tested that it runs. Then I added in meta-phosphor, which also pulls in webui.
webui has a dependency on noVNC, but with a specific version, which appears to cause this command to run and fail.
How I setup the build:
git clone https://github.com/openbmc/openbmc.git
git checkout cb91a77
# Modify layers to include meta-phosphor and webui
scripts/install-buildtools
. /home/openbmc/code/openbmc/poky/buildtools/environment-setup-x86_64-pokysdk-linux
bitbake bmap-tools-native -caddto_recipe_sysroot
. oe-init-build-env rpi-build (per session)
# Modify conf files in rpi-build
bitbake core-image-base
My work around:
sudo git config --system http.sslcainfo /home/openbmc/code/openbmc/poky/buildtools/sysroots/x86_64-pokysdk-linux/etc/ssl/certs/ca-certificates.crt
I would rather handle the problem in the build, but could not find a way to do so.
I'm just fished connect to my kubernete.
But affter that I need to change the gcloud location from /Download to /usr folder.
Next, I run install.sh file for update the new location in .bash_profile.
Then I check gcloud command. It working well
But when I run kubectl get pod. The error showing.
Unable to connect to the server: error executing access token command "/Users/panda/Downloads/google-cloud-sdk/bin/gcloud config config-helper --format=json": err=fork/exec /Users/panda/Downloads/google-cloud-sdk/bin/gcloud: no such file or directory output= stderr=
Hmm, how to update the location of gcloud sdk for solve this problem.
Thanks for your help.
In your Kubeconfig file (probably in ~/.kube/config) you’ll see it has the old path to your gcloud CLI. Update that file with the new path.
I cannot start up a new Meteor application on a Vagrant linux box (running on a Mac). It fails every time with a 'unspecified uncaught exception' in Mongo. I have tried a bunch of things to get this going, but even with the simplest set-up, I cannot get the project running. I would be grateful for any suggestions.
My steps are:
create a completely clean Vagrant box ("ubuntu/trusty64");
install Meteor on the new box (curl https://install.meteor.com/ | sh);
choose a location to create the project;
create a new Meteor project (meteor create app);
start up the project (cd app; meteor)
I know that the permissions on the vagrant shared folder are quirky, so for step #3 above I have tried putting the project:
in the shared guest/host folder, /vagrant,
in a subdirectory of the Vagrant home folder (/home/vagrant),
in a subdirectory of / (with permissions set to vagrant:vagrant), and
in a subdirectory of / with permissions set to root:root, the project created with sudo meteor create app and run with sudo meteor
In all cases, I see this error:
=> Started proxy.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Can't start Mongo server.
MongoDB had an unspecified uncaught exception.
This can be caused by MongoDB being unable to write to a local database.
Check that you have permissions to write to .meteor/local. MongoDB does
not support filesystems like NFS that do not allow file locking.
I cannot tell if this is a Vagrant issue (though I think not, given what I've tried) or a Meteor issue, but I suspect it is Meteor (or one of its many dependencies). I doubt it is a permissions issue, since it failed when running as root. I've tried building meteor from scratch and the build fails and I've tried creating the project with --release 0.9.0 and --release 0.9.2-rc1 and the download is simply killed without explanation.
(1) After step 2 'install Meteor on the new box (curl https://install.meteor.com/ | sh)'
user$ cd /vagrant
user:/vagrant$ meteor create myApp
You should see the myApp folder on your Mac host (the same folder for the vagrantfile)
(2) Insides the myApp folder, you will see the default .meteor folder, make a folder called local if it is no there
user:/vagrant$ cd myApp/.meteor
user:/vagrant/myApp/.meteor$ mkdir local
(3) Create the same folder structure in the /home/vagrant
user:/vagrant/myApp/.meteor$ cd ~
~$mkdir -p myApp/.meteor/local
(4) Link or mount the /vagrant/myApp/.meteor/local to /home/vagrant/myApp/.meteor/local
sudo mount --bind /home/vagrant/myApp/.meteor/local/ /vagrant/myApp/.meteor/local/
or make it permanently
echo “sudo mount --bind /home/vagrant/myApp/.meteor/local/ /vagrant/myApp/.meteor/local/” >> ~/.bashrc && source ~/.bashrc
(5) Now you can start the meteor
~$cd /vagrant/myApp
user:/vagrant/myApp$meteor
The reason why I mount the local folder rather than the <.meteor> folder is that you can still edit the files insides the <.meteor> folder on your Mac host. You can replace myApp with whatever name you want
Hope this help
I'm working with a Windows host, but maybe this will apply to your situation as well.
The only folder which causes the issue is ./meteor/local. If you relocate this with a symlink to be outside of the shared /vagrant folder you should be able to run the meteor app okay.
But, to put a symlink in the shared folder you need to enable symlinks in the VM... which requires starting Vagrant as an admin.
I put together an Vagrantfile with some scripts and instructions here:
https://github.com/ElectronVector/vagrant-meteor
I ran into similar issues trying to run meteor on windows. It seems that mongodb is not able to write in the /vagrant folder. I solved this by doing
sudo mount --bind /home/vagrant/meteorapp/.meteor/ /vagrant/meteorapp/.meteor/
(got that from https://gist.github.com/gabrielhpugliese/5855677)
Here is an answer that solved my problem. Launching meteor project from a shared folder on Debian VMware virtual machine(running on a Windows).
The issue is that mongodb can't create data files inside a shared folder, so in this case just use an existing mongodb for meteor project:
export MONGO_URL=mongodb://localhost:27017/your_db
Doing
vagrant reload --provision
solved my problem.
I think the reason might be some files got corrupted or deleted.
I just downloaded mysql 64 bit as a zip package from their website, extract it to c:\mysql
and added c:\mysql\bin to my path.
I then open a command prompt as administrator and run:
mysqld -install
To install the mysql server as a service. I then go to windows services and start MySQL (also tried sc start MySQL from cmd), but I get the following error message:
Upon inspecting the properties of the service, it shows the path as C:\Program Files\MySQL-5.6.17\bin\ instead of C:\mysql\bin. Any ideas why this is happening?
Use the FULL PATH of your mysql server exe
Try this:
"C:\mysql\bin\mysqld" -install
It turns out that the service installation routine expects the .exe to be at the MySQL default installation directory of C:\Program Files\MySQL-5.6.17\bin\
Your installation with the straightforward mysqld -install could work, albeit only partially, because you had the correct path under Windows PATH
This is certainly a great inadequacy in the MySQL documentation, which does not address this issue at all.
Knowing you might have resolved your problem one way or another, I still thought to post this here as it might be of help to someone with time!
Cheers.