My current installation of Redash is somehow corrupted (installing it in a new PC worked fine so I know my local copy is broken), and I want to basically remove it fully and install it again.
I cannot find any documentation of how to uninstall it,
I don't find it installed as a service
I don't find it installed as a application
So how do I reinstall it???
Deleting the redash installation folder will uninstall the redash but if your installation executable is damaged then reinstalling it again alone might not help.
Check if you have any errors with your supervisor demon:
This supervisor demon is automatically started on port number 9001 on your local machine.
Go to http://127.0.0.1:9001/ and see if all the services/workers are up.
If there are any errors post back the log here.
Check if redash has created dir - /opt/redash/, Remove it if exists.
Run this bash for re-install - https://github.com/getredash/redash/blob/master/setup/ubuntu/bootstrap.sh
Related
I've been using DDEV & Docker-Desktop sucessfully to run installs of drupal8 on my windows 10 machine.
Today I decided to create a new install of Drupal8 (I last did this a month ago or so).
I followed the basic steps:
Create new folder (drupal8test)
Ran the ddev config command inside this folder.
accepted the defaults and choose drupal8
Amended config.yaml so the ports do not clash with others on my machine
Ran the command ddev start
I get a couple of alerts from docker desktop and I share folder's it needs
There are no errors and the URL is provided, on going there I get a 404 file cannot be found error
When I look in the drupal8test folder I see the following folders:
.ddev
drush
files
sites
(Expecting to see web).
Any ideas? (I'm quite new to Drupal and DDEV so I'm sure I'm doing something wrong)
Welcome to ddev and to Drupal, Mark!
ddev has never installed Drupal, it's a local development environment.
There are quickstarts for Drupal (all versions), TYPO3, Magento and Magento2, etc at https://ddev.readthedocs.io/en/stable/users/cli-usage/#quickstart-guides
For Drupal 8, you would follow the Drupal 8 Quickstart:
mkdir my-drupal8-site
cd my-drupal8-site
ddev config --project-type=drupal8 --docroot=web --create-docroot
ddev start
ddev composer create "drupal/recommended-project:^8"
ddev composer require drush/drush
ddev launch
I'm not sure I understand the command you showed
.ddev drush files sites
or what it was trying to accomplish, but after doing this install you can just ls and you'll see the web directory. If you're interested in running drush, you can ddev exec drush status for example, or just ddev ssh and use drush.
Anyway, the next time you get stuck, the docs are waiting for you at https://ddev.readthedocs.io/en/stable/ and there is also lots of community support available here and elsewhere.
This only started happening tonight, and even after reverting my totally not-npm related changes it's still happening.
I've got an AWS Elastic Beanstalk setup here where I'm calling eb deploy to deploy a KeystoneJS cms application. As part of the deployment it runs npm install, and I've got a custom fork/branch of the keystone github repo that it's supposed to install. And it does! But for some inexplicable reason /lib/core/ in the Keystone repo is just... not there. I get errors complaining about those missing files, and sure enough the entire folder is not present. They are just not npm installed, despite the rest of the Keystone repo being installed just fine.
I can't reproduce this locally. I'll run npm install, it adds that folder. I'll do npm install <my-fork>, it adds the folder. Every combination locally works just fine, and every deployment I've done to EBS in the PAST has worked just fine. Only tonight has this folder stopped showing up in my installations.
Is it a problem with Elastic Beanstalk? Is it a problem with npm? I've made sure to sync my local npm version (6.8.0) with the EB one, no difference. I've checked to make sure I don't have any .ebignore or .npmignore or .gitignore that might somehow be blocking the core folder, nothing. Unless there's one secretly controlling the temp folder that gets first installed to? I don't know why this would suddenly be an issue though, when it wasn't a couple weeks ago.
Anyone experienced anything like this?
[Edit] For some additional details, changing the keystone version in my package.json to just keystone: "4.0.0" gets me those core files fine. If I install directly from the associated keystone repo, keystone: "keystonejs/keystone", they aren't there. This is again just on the eb install tho, the core files show up for both if I do them locally. But on eb when I install from a git url, which I need to for my specific fork/branch, I see this issue.
Well, I figured it out!
https://npm.community/t/npm-pack-leaving-out-files-6-8-0-only/5382
Someone broke npm 6.8.0. Let my tale be a cautionary one, don't have your deployment scripts set to auto-update npm to the latest version.
I'm following the "Installing CKAN from source" guide. And in the step to start the jetty service: sudo service jetty start. But it doesn't work, it prints "Failed to start jetty.service: Unit jetty.service not found".
Now, if instead that command, I use: sudo /etc/init.d/jetty8 start, the server starts correctly.
So, my guess (not totally sure) is that the jetty.home is not set properly.
For what it's worth, I'm using Ubuntu 16.04, running in virtualbox.
Thanks in advance to anyone who can help me.
P.S: If additional information is needed, please let me know.
For Ubuntu 16, just run sudo systemctl unmask jetty8 then sudo service jetty8 start
If sudo /etc/init.d/jetty8 start works then you should be able to use
sudo service jetty8 start
(note the use of jetty8 instead of jetty).
I'm following the old tutorials off of gettingstartedwithdjango.com.
This series is quite old and I'm new to Django which is why I hit that site in the first place. It became my first introduction to Vagrant. Because the series is old and there are now new versions of Django, Vagrant, etc, I've found just getting through the first tutorial was quite difficult. This was mainly just the gap between Django v1.4 and the current version 1.9 which is what I'm running, including some syntax differences in settings.py and also some discrepancies between the text errata and the video which I had to sort through. It's a pretty detailed exercise if you're completely new to all of this (which I am), so it was quite challenging, and I was thrilled when after probably 12 hours of solid effort I was able to get everything working as was being described in the video but using all new versions of software. Once I got it all set up and working, I halted my Vagrant VM for the night and when I turned it back up (vagrant up) the next morning, I found that the VM would no longer mount its shared folders, essentially rendering the Vagrant VM useless to me as I'm then unable to run code which resides on the host machine (I'm running Windows 7) from within the VM (which is accomplished via the VirtualBox shared folders feature).
Not knowing what was wrong, this prompted me to completely reinstall my Vagrant VM. I was able to get things redeployed successfully with about one hour worth of effort, backtracking through steps I had taken to successfully complete the first tutorial in the first place, in order to back to the same point where I started (before I did the previous vagrant halt). When reinstalling the Vagrant VM I noticed messages that my VirtualBox Guest Additions (4.2.0) did not match the version of VirtualBox I have installed (5.0.10), which I recalled seeing the first time but ignored because it also said this isn't usually a problem and should work (if it weren't for bad luck, I'd have no luck at all). Since for me it didn't work, this led me down a whole rabbit hole of posts from various websites including SO, which ultimately had me updating my Vagrant VM, downloading/mounting/building/installing a new version of VirtualBox Guest Additions, and reloading my Vagrant VM only to wind up in the same boat. Shared folders were still not working!
To be very specific, this is more or less what I tried based on information from many websites:
cd /home/vagrant
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install dkms build-essential linux-headers-generic
sudo apt-get install linux-headers-3.2.0-23-generic
# mounted VBoxGuestAdditions_5.0.10.iso to Vagrant VM
cd /media/cdrom
sudo sh ./VBoxLinuxAdditions.run
sudo reboot
sudo /etc/init.d/vboxadd setup
sudo reload
c:\VAGRANT\vagrant plugin install vagrant-vbguest
c:\VAGRANT\vagrant reload
I was utterly convinced this was going to resolve the issue but it didn't.
Then I found this gem:
http://ddelizia.blogspot.com/2011/02/how-to-share-folder-on-virtual-box-with.html
This shows how to, from within the Vagrant VM, mount the shared folders back to your Windows 7 host. To be specific, here's what I did when I found things were working again:
cd /vagrant
ls -la
<this yielded nothing>
sudo mount.vboxsf vagrant /vagrant # see your VirtualBox Shared Folders settings
cd ~ # /home/vagrant
cd - # /vagrant
ls -la
# this yielded the expected folders from my Win7 host
In the mount.vboxsf command above, the first vagrant (without the /) came from the Name column in my VirtualBox shared folders settings. This is essentially an alias which is used to refer to the actual path on the Win7 host, in my case: C:/VAGRANT. The second vagrant (with the /) in that command is the /vagrant folder on the Vagrant VM (linux).
Given that I spent most of today messing with this and I figure there are plenty of people who are going to run into this same or related problem, I thought I would try to help out and save you all a bunch of time. Good luck.
I've installed a Vagrant + Virtualbox using Chef (+library chef). When I do vagrant up first time, cookbooks get loaded correctly. However, when I do provision afterwards (be it vagrant provision, vagrant reload --provision or vagrant up --provisionI get this error:
Shared folders that Chef requires are missing on the virtual machine.
This is usually due to configuration changing after already booting the
machine. The fix is to run a `vagrant reload` so that the proper shared
folders will be prepared and mounted on the VM.
I searched everywhere and the only solution given is to do vagrant reload --provision, this worked up up to Vagrant 1.3.1.
it seems like there is a bug with sync folders, this clears the cache and fixed it for me. (from your project directory)
rm .vagrant/machines/default/virtualbox/synced_folders
vagrant reload --provision
https://github.com/mitchellh/vagrant/issues/5199
EDIT: this should be fixed in vagrant 1.7.4
That's a fairly common issue with the Vagrant plugins for both Berkshelf and Librarian. Just get used to running that command.
The way to avoid it is to use something like Test-Kitchen instead of the Vagrant plugins. That isn't a drop-in replacement though.