I am a CS professor trying to teach web app development (Flask, Rails, SparkJava, etc.) using Heroku.
Our computing environment is a centrally managed Linux system, where neither the students nor I, have root permission. The students also have a very limited file and disk quotas: 200MB of space, and 4000 individual files.
I used to be able to provide them a way to give them access to the Heroku toolbelt by hacking the "standalone install" to get around the default assumption that the person doing the install has root permission.
But it is no longer working. When I install into a directory and run from there, the Heroku toolbelt keeps trying to "auto-update" into the ~/.local/share for each individual user and since the Heroku-CLI installation has over 12000 files in it (!) it blows their file quota.
This is madness. I want to have just ONE installation of the Heroku toolbelt client, update it centrally and NOT have each student have to have their own copy. Is this too much to ask? Is there any way to do this?
There used to be some trick to making the client think it was already up-to-date or some way to configure it to NOT do the auto-update. But I can't find how to do it.
(Thanks in advance for all of your good ideas such as: have them work on their own laptops, make a VM, have them work on AWS, etc. Those are all great ideas for some parallel universe in which they are feasible. If I could use any other computing environment, I'd already been doing that. This is the one I have. If I can't make Heroku work here, I just can't use Heroku in class. And it's frustrating because it used to work.)
As a quick and dirty solution you can in lib/heroku/updater.rb change
def self.needs_update?
compare_versions(latest_version, latest_local_version) > 0
end
to
def self.needs_update?
false
end
and you will not be bugged with updates anymore. You have to do this each time you want to update manually.
A better more maintainable solution would be to get a config value or something similar for controlling this behavior accepted upstream in the toolbelt, which is open source at https://github.com/heroku/heroku
Related
I was asked recently to install Hubstaff (a famous application for tracking your data, like screenshots, URLs, etc., on your computer and reporting it to your management team) on my Debian machine. After checking their download page (https://app.hubstaff.com/download) I found out that for the Linux version, I have to download a .sh file and run it (so no package manager, not a .deb file) This app tracks almost everything from my machine (https://hubstaff.com/how-tracking-works), but they don't explain how it follows them. Like they can track the URLs I visit (and no matter what browser I use), how do they do that? Are they checking my network packets?
Do you guys think is it safe to do such a thing? E.g., they say they don't track my keyboard, but they can find out if it's used or not (for idle purposes). Well, they might be right about it, but what if somebody hacks them? I feel like if I use this app, I am making my computer public. Please help me learn about it.
Hello I have been wanting to get into working with a framework and Laravel seems like a decent one to try.
I have seen a lot of tutorials that tell you how to setup Laravel locally with Homestead or variants.
I am wanting to install and setup Laravel on my dedicated remote server with my hosting company. From there I want to be able to work with it on my local MacBook or MacPro.
I have not been able to find a good tutorial to make this happen in the fashion I want to do it.
I work with PHP and related daily but usually login to FTP and edit files with TextWrangler and save them and go about my day so my methods are dated and not efficient.
One side note is that I also have a Dell PowerEdge server running CentOS and VestaCP in my office as my development server so nothing is done locally per say (on my own computer) so the question and answer will apply to both my remote server and my remote but local development server.
Any suggestions are always welcome.
Best Regards,
Bradley
Assuming you have full root access to your remote servers, you should install composer on them and install Laravel in whichever way suits you. Then you can edit your project files just as if you were working on it locally.
Seriously though, the biggest thing you should add to your development arsenal (in case you haven't already) which will make your development process so much more resilient is Git.
Set up a free Bitbucket account, get a free Git client, and learn how commits, pushes, pulls, branches and deployments work. The easiest approach for deployment is to use a service such as Envoyer.
That way you can develop and test locally (even if 'locally' is a remote machine) and not really have to worry about breaking your app by making a mistake in controller or something on the live server.
Using Vagrant to have a number of developers share the same environment I see two approaches that people are using.
Create a box file with entire basic environment installed, and share it on Vagrant cloud?
Create a setup script that will "apt-get install" and "git clone" everything that is needed?
With 1st approach I don't like the fact that you have to host large files, also changes to environment would be harder to do (uploading the subsequent version of the entire box?).
Its difficult to make an answer for this, I can only share my experience, I started with #1 and provided a full box to my team, the box was 13 GB but it worked fine (although was not too easy to share), then when we had to upgrade any 3rd party software its was more difficult (it was also before the time vagrant update was available) but still I like option #2 much more flexible now. The provisioning takes 2-3 hours but we can run it at night, repeat the process anytime and at the end, its much easier to provision a new instance for a new member.
I tried to adopt Vagrant in our team. I created a Vagrantfile and make provisioning in some way. Everything works as charm, but ...
It's unclear for me how I can automate some routine tasks like:
running django(I use django, but it's framework agnostic problem) dev server on 0.0.0.0
running grunt watcher
providing a separate console for django-specific commands
It is looks like vagrant not intended to help with this kind of automation and I look for some community adopted way to do that. I goggled and found nothing.
I see a few way to that:
bootstrap.sh script but messy and hard to mantain
something like tmuxinator -- requires tmux on host machine and now it's impossible to put tmuxconfig in project repo
etc
What is the 'canonical' way to resolve this problem?
P.S.: Please, think about designers, manual testers and other guys which like to use tools as is
In general you are best off using a provisioner. To be honest, a bootstrap.sh file is a good place to start unless you want to learn the ins and outs of something like chef / ansible / salt / puppet. If you do you might want to start at salt (SaltStack) because it is written in python which I'm guessing you use given the django angle.
For your specific questions:
Part of the point of vagrant is it lets you develop against real stacks and real web servers so you can avoid the "oh, that don't quite work the same on apache" moment that often comes in projects. So for your first question I would look at how to provision the app behind apache / nginx or whatever you are using for the production web servers.
Because of the shared file systems users can just run grunt locally on the host machine. This also lets grunt do things like hook into OSX notifications.
I'm not familiar with tmuxinator so I'm not sure how to start here. But if it is a service that the server really runs then you should figure out a way to package the install and deploy it to the provisioned VM. As for configuration, is it possible to get a dev config in the repo?
Same as #Wyatt, I recommend use Vagrant with provision tools, such as puppet, saltstack, chef, anisble, etc. These tools are created for the requirements you ask for, and most are open source. Choice is no wrong, you can start learning from any one, they are similar.
With that, you can quickly and easily run several VM servers with all applications installed automatically. With the customised Puppet codes or chef cookbooks, you can update them any time and provision to VM easily, you can re-use them for your PROD environment as well.
Take some times to learn one of these automation tools first, you will get benefit to save a lot of time.
I use Puppet, and recommend the best puppet book PRO PUPPET to you. It has all you need.
It's a late Sunday night and I decided to mess around with Facebook applications. Turns out they now offer you easy integration with heroku which, of course, I decided to try out.
I patiently waited for the toolbelt to download, installed it and, as usual, nothing will run for me without bit of a struggle.
So I did what I could, googled the problem I'm having and realized that the problem is most likely caused by the fact that my user folder contains non-latin characters.
To make sure that this is the problem, I created another user account, installed heroku toolbelt on it and it works just fine.
Are there any suggestions on how to get this to run without me having to work on the test account?
Thank you for your time!
edit
Forgot to ask wether it's possible to change the folder heroku uses?
edit
Still haven't found anything that would help me fixing this, is there really no way how to fix this?
I've attached the screenshot of error
I've stumbled on this post while being in much the same position. Here goes a solution:
Edit ...\Heroku\lib\heroku\helpers.rb such that def home-directory is as follows:
def home_directory
running_on_windows? ? (ENV['HEROKU_HOME'] || ENV['USERPROFILE']).gsub("\\","/") : ENV['HOME']
end
Now if you set the HEROKU_HOME environment variable to anything the Heroku toolbelt will use that as home. (FWIW: As I have run into this with other tools as well, I set up a link with US-ASCII-only letters to my standard home directory under Users.)
I think what you should do is run the heroku login command from the Git Bash client rather than from the default Windows command line. I have been using the heroku-toolbelt on Windows 7 for about a year now and have not encountered any such problem whatsoever. I had found a way to enable latin characters in the Windows command line sometime ago writing a program in CLIPS, but I don't quite remember how the command goes right now, or what configurations I did. However, if you don't have the standalone Git client installed you can always grab it from: http://git-scm.com.