I have just created a new microservice with micro new <microservice_name> using Micro. I have then installed the needed dependencies (protobuf) and run make proto, as specified in the official documentation. However, when I run micro run ., I get Fork/exec /usr/local/Cellar/go: permission denied:.
I have already tried:
running the same command with sudo;
checking the permissions for /usr/local/Cellar/go (drwxr-xr-x);
checking the permissions for $HOME/bin/micro (.rwxr-xr-x);
reinstalling Go (brew reinstall go).
Nothing changed: I still get the same error message.
I have just found a solution. The issue I was experiencing was related to Homebrew. After uninstalling Go with brew uninstall go and installing it with the official installer for Mac (available at the official download page) I finally managed to start my microservice with micro server and micro run .
I am looking to play with apache-superset on a cloud-based ide. I have it on my local. I tried unsuccessfully to set it up on gitpod. I wanted suggestions on where can I set it up, opensource preferably not necessarily. I believe cloud9 is 1 such place, but I am looking for other options before I settle. If you've ever set it up on any such platform, even if it is on gitpod and can help me, kindly do so.
[Disclaimer: Gitpod staff]
You can indeed use Gitpod to work on apache-superset, and for that you'll just need a working configuration.
From what I can see in apache-superset's requirements, you'll need to get:
PostgreSQL (e.g. by using Gitpod's official gitpod/workspace-full-postgres Docker base image)
Redis (e.g. by installing it in a Dockerfile via sudo apt-get install)
Various Python dependencies (e.g. by running pip install . after cloning)
Various Node.js dependencies for the front-end (e.g. by running npm install)
Here is a basic configuration I wrote to achieve this:
https://github.com/jankeromnes/incubator-superset/commit/0d345a76ec8126fd1f8b9bc7b6ce4961bf3b593d
What it does is:
Create a Docker image with PostgreSQL and Redis
Once the repository is cloned, open 4 separate Terminals ("tasks"):
Redis server
Superset backend
Superset worker
Superset front-end
All dependencies will be installed automatically, and once the front-end is ready, it will automatically open in a web preview IDE side panel.
You can try it out by opening my personal fork of the apache-superset repository in Gitpod, e.g. by following this link:
https://gitpod.io/#https://github.com/jankeromnes/incubator-superset
We started seeing some strange errors in our logs that normally appear when ruby isn't compiled properly with OpenSSL. But it's inconcistent...
We're getting errors like:
RuntimeError: Unsupported digest algorithm (SHA256). (also with other digests, like sha1). example error trace
Faraday::SSLError (SSL_CTX_new: (null)) example error trace
We managed to reproduce it when starting unicorn using service unicorn start or systemctl start unicorn. But only with some requests... Not all of them. Some requests that use OpenSSL under the hood do work. Others don't.
However, when we start unicorn with /etc/init.d/unicorn start, everything works without a hitch. (to clarify, systemd starts the same /etc/init.d script)
We tried debugging ENV vars, user permissions, file/dir ownership, recompile ruby, bootstrap a new server from scratch... Nothing seems to help.
In case this helps:
unicorn init.d script
unicorn.rb
What are we missing? What can we try that we haven't thought of?
UPDATE 1
output of some debug commands, e.g. OpenSSL, ruby etc
PATH is being set inside the init.d script
unicorn is being executed via su into www-data user
The same problem happens when we use this unicorn.service file in /etc/systemd/system
We're running Ubuntu 16.04 on Gcloud
Ruby was not installed via apt (explicitly removed, in case platform came pre-installed) and compiled from scratch. We're currently running 2.3.4 and tried also 2.3.6. Compiled either manually or using ruby-build. No rbenv, nor RVM.
We install libssl-dev via apt (we're running apt-get install -y autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev before building ruby)
UPDATE 2
We're using a scripted/repeatable build process for the VM (using fabric), and this problem is consistent on multiple VMs we bootstrapped on GCloud. We then tried a VM on DigitalOcean with the same bootstrap scripts, and the problem doesn't seem to appear there.
In both cases we picked Ubuntu 16.04 64bit base image, but obviously there are some differences with kernel versions, base installed packages etc...
UPDATE 3
The problem simply vanished. See my answer below.
#gingerlime I had a similar situation with our Jenkins on GCP, we're using ChefDK 3.1.0 (ruby embeed 2.5.1p57) -- tried other also, over a Jenkins that was running over systemd (Ubuntu 16.04) and upstart (Ubuntu 14.04) -- we tried on both versions, right now running over 16.04 in 4.15.0-1023-gcp kernel version, running a few jobs with kitchen-docker and this problem always emerge in a few situations.
I digged into and found that this only happens when the Etc.getlogin class gets called (for me here), this doesn't return any error, it return the correct info, the correct type of the class (String), but once it gets a call, the Unsupported digest algorithm gets raised.
If I start the process manually by root or jenkins user, this problem doesn't happen. I tried to implement the Etc.getlogin in several different ways, like using ENV['USER'], a fixed String, or other classes from Etc, like getpwuid, simulating the return class and values from Etc.getlogin, and the error doesn't get raised.
I'm not sure if this is some bug related to the ruby version and the custom kernel that GCP instances uses, but it happens in a similar situation like yours, and for me, the Etc.getlogin was the problem. Right now, I fixed by using a custom configuration that doesn't gets the call from this function, and it's working normally.
One option is that this isn't an issue of sysVinit vs systemd at all, but you just haven't triggered the issue with your sysVinit script yet.
When you run your svsVinit script through the systemctl command it's going through a compatibility layer, and there may be a problem there. Your problem would be simplified both yourself and for us if you reproduced the issue directly with a systemd service file and shared that file.
You mentioned debugging ENV, but didn't mention exactly what you checked in the ENV. This is definitely one place where systemd could make a difference. As seen in man systemd.exec, systemd sets $PATH in the environment to a fixed value:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
If this is not exactly the same as when run directly as an sysVinit script, that could be an issue.
I would also check for all your copies of SSL on the system. Do you have more than one? Where? Do you have more than copy of the ruby openssl module loaded?
locate -r lib/.*libssl.*so
Also see the answer to the FAQ: Why do things behave differently under systemd?
(also posted on this github issue)
It looks like the problem just vanished. We were testing and reproducing it consistently, across several Compute Engine instances on Google Cloud. Under certain conditions (unicorn / puma started by systemd, etc), it was completely reproducible both with our own rails app, and with a plain vanilla rails app we've set for testing purposes. It was reproducible across several ruby versions as well (we tested 2.3.4, 2.3.6 and 2.5.0).
Suddenly, all instances that were consistently failing started working without exhibiting these problems. Like it never existed. We didn't even reboot some of those instances, and we saw no evidence of any unattended upgrades taking place... We also had one snapshot of a system that had this problem, and that we can reliably reproduce on. Creating an instance from this snapshot stopped exhibiting it as well from that specific point in time a few hours ago.
We're totally confused as to what might have cause it, and what might have made it disappear... However, without being able to reproduce it now, I guess there's no point leaving this issue open, so will close it. Chalk it up to Deus ex machina I suppose. (perhaps the google support gods, but they haven't reported anything back to us yet)
I am installing a sensu server inside a docker container running ubuntu 14.04 but when I install it for some reason it does not install the sensu-dashboard.
When I run the following command to set up the defaults I get a file does not exist error
> Command: update-rc.d sensu-dashboard defaults
Error: update-rc.d: /etc/init.d/sensu-dashboard: file does not exist
I have searched for the file but does not seem to be installed anywhere.
Has anyone else had this problem before when installing sensu or know how to fix it?
Thank you
The default Dashboard was removed on July 28th so you missed it by a day!! :( You now have to use a different dashboard. Uchiwa is a great choice and is under very heavy development, so I am sure it will continue to become more feature rich.
link to uchiwa's github page
The default Dashboard was removed that is true but if want to use sensu-dashboard then go for Sensu-Enterprise.
Here is the link: http://sensuapp.org/enterprise
I've been trying to figure out this problem for a while now and I thought I'd ask it here on stackexchange in case somebody out there has tried this and successfully got it to work.
I'm trying to install a RAD webapp tool called AppFlower through Xampp for Linux.
I am also experiencing issues with the command below:
symfony afs:init
symfony: command not found
This is the final command used to start up the AppFlower Studio dev environment, but this command doesn't work.
I have tried using:
./symfony afs:init
Same error as above
php ./symfony afs:init
gives a php error saying it isn't installed, but this is Xampp for Linux, so that command won't apply
/opt/lampp/etc/php.ini ./symfony afs:init
it will give a permission denied error, but even with 'sudo' in front, it says 'command not found'
The solution posted on the appflower forum is for xampp itself, but the problem I have is that they use the php.exe command to run the 'symfony afs:init' command, which xampp for linux doesn't have. The closest thing I could think of was to use the php.ini file, but (as seen above) that doesn't work.
Hopefully somebody can assist regarding this issue.
Regards,
Note. The process to run appflower on a manual version of lamp (one in which php, mysql, apache are all downloaded separately) is a lot more complex and the xampp installation is supposed to be much easier (in fact it is) but at the last point of this installation, this 'symfony afs:init' command is the only problem.
If you are already using Linux, why not install AppFlower directly. It's pretty straightforward, maybe i lost something on the way, understanding why you use XAMMP for Linux.
Installation instructions for AppFlower on Ubuntu,
http://www.appflower.com/doc/1_2/learn_install_git_on_ubuntu