Laravel 5 Heroku Local doesn't work - php

I've successfully deployed the Laravel application to Heroku.
It works online.
But when I try to run "heroku local" I get:
vendor/bin/heroku-php-apache2: No such file or directory
Which makes sense, since looking into "vendor/bin", the only thing listed is:
psysh -> ../psy/psysh/bin/psysh
So, where's my heroku-php-apache or how do I fix this?

You should have these lines in your composer.json
"require-dev": {
"heroku/heroku-buildpack-php": "*"
}
be sure to run composer update after you add them.

After extensive research, trial and error and talking to the Heroku Support team, I found out that, although Slow Loris's answer was a part of the process, the following answer was given to me by Heroku's Support:
To cut a long story short, heroku local is not officially supported for PHP >applications. The reason is that unlike all the other languages we support on the >platform, PHP has no web servers written in userland. Instead, we use PHP-FPM >together with Apache or Nginx, and the boot scripts (vendor/bin/heroku-(php|hhvm)-(apache2|nginx)) dynamically inject the correct configuration for port >binding and the FastCGI comms sockets.
This works with vanilla PHP and Apache builds, provided that:
1) the current user has all the correct permissions (in your case, >/var/log/apache2/ isn't writable);
2) the correct proxy modules are loaded in the main httpd.conf;
3) the main httpd.conf doesn't bind to a port at all, or at least not to one >under 1024 (which are reserved for superusers).
The main config also needs to be handled by each user on their own, because >sometimes, the modules to be loaded are in libexec/, sometimes in >lib/apache2/modules/, and so forth. Just too many variations; otherwise, we could >ship a full Apache config to users and the experience would be much better.
But the problems don't end there. FPM does not work at all on Windows, and on >most Linux systems, httpd is not a command that works; instead, apache2ctl >handles starting and stopping, and thus, running a server in the foreground is >not possible. In the end, there are simply too many possible permutations in >system configs that make it impossible to ensure every user has a great >experience.
It's simply the current reality in PHP land. Ruby, Python, Node, Java all have >web servers that are written in each respective language, and you don't need >external servers. Which also makes it possible to stream file uploads, handle web >socket upgrades, and so forth. Maybe with PHP 7 we'll see something like that >emerge soon (in PHP 5 it's simply not feasible at all, because a fatal error >kills the engine, so your web server would be gone too).

I know this question is a little dated but I recently deployed a heroku app for the first time and was unable to get heroku local to work for me. I'm on the current branch of Laravel which is 5.8, I am also on Windows 10 using VS Code. I searched all over trying to rectify this issue and could not get it to work no matter what.
I did come up with a solution to be able to work on this locally with only a few lines in terminal.
In VS Code, I used gitbash terminal, once in my heroku project folder composer require laravel/homestead --dev, once that is complete, then we need to install homestead, vendor/bin/homestead make, and then once that is complete, simply run vagrant up and your app will be accessible through localhost:8000.
Docs - https://laravel.com/docs/5.8/homestead
Hope this helps someone!

Related

Ratchet & Websockets - Can not get anything working

So I am fairly new to PHP and websockets and server management in general. But have been tasked with designing a web-app and have determined that the best way to implement this is with websockets. So I found ratchet. And began trying to get it to work. I have a linuxbox with apache already setup, and created a new directory in the webroot and began Ratchet's tutorial. However no matter what I did I could not get even the in-line telnet part working.
I have a composer.phar, I have their script within my composer.json, I followed their instructions for installing ratchet. however when I run the php chat_server.php command it doesn't seem to do anything. The tutorial states that it should take control of the console, and as I saw in a video tutorial it does.
So my ultimate question is - what is causing this not to run properly? Is it a bad installation (Did I mess up installing somewhere or just not install something that is required but was not explicitly stated?) all the code is identical to what is documented here http://socketo.me/docs/hello-world
Some questions when ratchet is not functioning while setting it up.
Is the php process (#php chat_server.php) open?
Are you telnetting from another cli?
can you check if the port on which the chat server should be running is allocated?(#netstat -pln)
Is the zmq library added to the apache modules? (Probably your problem)
If the above aren't working you might try to check if some firewall is blocking the connection internally.
I would suggest starting from a clean machine to execute all set up steps.

Remote Symfony2 + Netbeans workflow (feat. git)

I'm hoping someone have encountered this problem before and will be able to help
So, the problem goes like this: There's 2 developers, each one of them needs 2 versions of a website (development + production). Due to very different operating systems, triple configuration difficulities and administration restrictions on them it's impossible to run projects locally. But there's a bunch of problems while running them remotely:
How to run Symfony2 CLI commands in Netbeans (since those commands need access to db)?
How to differentiate between production/development? I have allowed external access to db for 2 IP addresses, but theres only one parameters.ini file. And once it's used to connect to localhost (when run by http), and second it's used to connect via remote host (when CLI command is run in netbeans)
More info you may ask, so here it goes:
Dev #1: Kubuntu 12.04 x64 3.2.0-25-generic NB#7.1.2
Dev #2: Windows 7 x64 NB#7.1.2
Server: Ubuntu Server 12.04 x64
SQL: PostgreSQL
webserver: Apache2
Our workflow now looks (or at least should look) something like this:
Dev #1 does something locally, but on run changes are being moved to the server so he can check how it went on beta1.sitename.com.
Each change is commited to user branch in git when suitable.
After testing changes are baing merged to master, tested, pulled to a sitename.com, and then tested again.
After this the cycle repeats :)
PS. Valid answer would also be a hint how proper workflow in that kind of situation should be. I've tried already with post-* git handles, and it didn't work really well either...
First of all I would highly recommend trying to solve the development machine issue. There is vagrant which can be used together with chef or puppet (or a specialiced virtual base machine) to move the development environment into a virtual machine executed on the developers pc. This would also solve many issues regarding the remote server.
If this cannot be done, here are some thoughts:
Netbeans commands won't work remotly. Have your developers ssh into the machine and execute their commands their.
I don't get your development/production environment problem. Their should a at least on virtual host with different config/cache/logs for each developer so the configs can be set correctly. The parameters.ini should not be in your git repository (You can handle this by creating a parameters.ini.dist and ignoring the parameters.ini file) so you can have different parameters.
Another interesting thing (presented on the symfony live 2012 Paris) is that you can do SET_ENV SMFONY_PARAMETER_NAME inside your apache vhost and then use %parameter.name% inside your config files (mind the two underscorse). This could be usefull in your case.
There really is no workflow I know of which could handle multiple developers on one machine with different configs and the like. It's just a mess and you either solve your problems with complex scripts which are run everytime something happens or by finding a better solution like virtual machines or different vhosts with different directories on your servers.

How to bundle a php application with 1 click run/install

I create php application for small businesses. Some of the clients may prefer running the app on a local server, therefore my requirement is to create/bundle an app with apache/mysql/php with all the necessary confirguration and one click executable (be it a batch file) such that when the user opens it, it runs the apache server on some port say localhost:1234 and mysql as well.
and opens up the application in the default web browser.
To be more exact, Im looking for something like http://www.simpleinvoices.org/go, check their Simple Invoices for Windows which come budled with apache/php/mysql.
P.S - Im not sure if this question should be at SO or Superuser.
If you actually want to install a web server and a SQL server then Lars' solution would be a way to go. On windows you can generate a .msi installer containing the dependencies you need (like WAMP). An installer executable would be a cleaner solution than a batch file in my opinion, as it will also provide the user with an option to uninstall your software if they wish.
If you want to distribute your application in a standalone version, then you might also want to check a solution like NuSphere's PHPDock - http://www.nusphere.com/products/phpdock.htm
I had the same challenge and came across Uniform Server:
http://www.uniformserver.com/
You download it, add your application to it, start it and everything runs. Lovely.
Superuser would have been better. But depending on your requirements, you should just create a package to install. On windows, package it with WAMP, on linux, package it with either one-click-install or creating packages for the two biggest systems, namely APT and RPM. With the dependency-system on all of them you can make sure, that your application runs right off the bat.
PHP Desktop is the best option I found when researching this.
https://github.com/cztomczak/phpdesktop
PHP Nightrain is also an option:
https://download.cnet.com/PHP-Nightrain/3000-10248_4-76169308.html
Bitnami WAMP stack looks good as well:
https://docs.bitnami.com/installer/infrastructure/wamp/

Best PHP download to keep all my options open?

In the past, I used WAMPserver on windows to parse PHP for me. This is a pre-configured package, focussed on working with MySQL.
When I tried to run PostgreSQL, I got error messages that said that my version of PHP wasn't compiled to work with PostgreSQL.
So, I've recently uninstalled WAMP and every associated with it. I've downloaded Apache 2.2.11 with openSSL, installed as admin(you know, run the command prompt as administrator, cd to the directory where the download was done and have it executed, so the install was done as admin).
That's that. I now have Apache installed, "it works" shows up, so I'm that far.
Now I'm wondering, do I download the exe and install, or the zip, or something else.
What is the best thing to do to make sure that the PHP on my system can handle everything I can ever throw at it?
Also, PHP first, or MySQL/Postgre first.
And lastly, what about PEAR? I need PEAR installed, which isn't standard on Windows. I'm guessing the pear.bat file in the PHP downloads will do that for me?
EDIT: I see one close vote, yet no comment as to why. It makes me wonder how people who are so lazy and rude got to have somany points.
I would recommend downloading the zip package, as configuring php is not really that difficult, and it allows you to add features as needed.
As for whether first to install php or MySQL/PostgreSQL, - it does not really matter. You can install them in any order.
Your guess regarding PEAR is quite correct
i haven't used wamp before, so i can't comment on that
i do however use xampp which sounds very similar
in xampp if i want to enable postgres support i edit the php.ini file and uncomment the postgres section of the ini file, same with any of the extensions that i need
perhaps this might be an alternative you can try if you get stuck
There are many ways to setup a HTTP server/PHP/database machine. Sometimes the behaviour of your development setup will differ from the live server's.
I would recommend finding out the setup your web host is using, then getting a vmware appliance image that fits that as close as possible and get any additional software using it's package manager (which is easier that installing stuff on Windows).
Setup a file sharing link between the VM and the host, make sure you can view the VM's port 80 in a browser running in your host OS and you're set.

Running xinc on OpenBSD's Apache Server

Has anyone been able to get xinc to run correctly under OpenBSD's chrooted default Apache? I'd like to keep our development server running fully chrooted just like our Production server so that we make sure our code runs just fine chrooted.
Have you posted the issue on the Xinc bug tracker? Xinc itself should run fine as it runs both as a daemon and as a web app. As you alluded to, the issue may be that the daemon is not running in a chroot'ed environment where as the web interface is, leading to either side not grabbing the files.
#dragonmantank
In Xinc's case, I hope you used PEAR to install it.
pear list-files xinc/Xinc
This should do it, and show you where your Xinc install put its files. So even though Xinc is "just" one big PHP script, it's still spread out into rc scripts and all those other things which are necessary to make an application run. I'm sure you don't need to add all paths listed there, but probably some in order to make it run.
Aside from Xinc itself, I think it also needs phpUnit and a bunch of other PEAR libs to run, so what I'd propose is this:
pear config-get php_dir
And then you need to add that path (like Henrik suggested) to the chroot environment.
Having never used xinc myself, I can only hint as to how I usually get to chrooting apps.
First step would be to gather information on everything the app needs to run; this I usually accomplish by running systrace(1) and ldd(1) to find out what is needed to run the software.
Go through the output of
systrace -A -d. <app>
ldd <app>
and make sure that everything the app touches and needs (quite a lot of apps touch stuff it doesn't actually need) is available in the chroot environment. You might need to tweak configs and environment variables a bit. Also, if there is an option to have the app log to syslog, I usually do that and create a syslog socket (see the -a option of syslogd(8)) in order to decrease the places the app needs write access to.
What I just described is a generic way to make just about any program run in a chroot environment (however, if you need to import half the userland and some suid commands, you might want to just not do chroot :). For apps running under Apache (I'm sure you're aware that the OpenBSD httpd(8) is slightly different) you have the option (once the program has started; any dynamic libraries still needs to be present in the jail) of using apache to access the files, allowing the use of httpd.conf to import resources in the chroot environment without actually copying them.
Also useful (if slightly outdated) is this link, outlining some gotchas in chrooted PHP on OpenBSD.
First step would be to gather information on everything the app needs to run; this I usually accomplish by running systrace(1) and ldd(1) to find out what is needed to run the software.
I'll give this a try. The big issue I've found with xinc is that while it is a PHP application, it wants to know application installation paths (yet it still spreads stuff into other folders) and runs some PHP scripts in daemon mode (those scripts being the hardest to get running). So, for example, I told it to install to /var/www/xinc and then made a symlink of
/var/www/var/www/xinc -> /var/www/xinc
and it partially worked. I got the GUI to come up bit it refused to recognize any projects that I had set up. I think the biggest problem is that part of it is running a chroot and the other half is running outside.
If all else fails I'm going to just have to build something as we program inside chrooted environments since our production is chrooted. We've run into issues where we code outside of a chroot and then have to back track to find what we need to make it work inside a chroot.

Categories