I have recently decided to try out Laravel Sail instead of my usual setup with Vagrant/Homestead. Everything seems to be beautifully and easily laid out but I cannot seem to find a workaround for changing domain names in the local environment.
I tried serving the application on say port 89 with the APP_PORT=89 sail up command which works fine using localhost:89 however it seems cumbersome to try and remember what port was which project before starting it up.
I am looking for a way to change the default port so that I don't have to specify what port to serve every time I want to sail up. Then I can use an alias like laravel.test for localhost:89 so I don't have to remember ports anymore I can just type the project names.
I tried changing the etc/hosts file but found out it doesn't actually help with different ports
I essentially am trying to access my project by simply typing 'laravel.test' on the browser for example.
Also open for any other suggestions to achieve this.
Thanks
**Update **
After all this search I actually decided to change my workflow to only have one app running at a time so now I am just using localhost and my CPU and RAM loves it, so if you are here moving from homestead to docker, ask yourself do you really need to run all these apps at the same time. If answer is yes research on, if not just use localhost, there is nothing wrong with it
To change the local name in Sail from the default 'laravel.test' and the port, add the following to your .env file:
APP_SERVICE="yourProject.local" APP_PORT=89
This will take effect when you build (or rebuild using sail build --no-cache) your Sail container.
And to be able to type in 'yourProject.local' in your web browser and have it load your web page, ensure you have your hosts file updated by adding
127.0.0.1 yourProject.localto your hosts file. This file is located:
Windows 10 – “C:\Windows\System32\drivers\etc\hosts”
Linux – “/etc/hosts”
Mac OS X – “/private/etc/hosts”
You'll need to close all browser instances and reopen after making chnages to the hosts file. With this, try entering the alias both with and without the port number to see which works. Since you already set the port via .env you may not need to include it in your alias.
If this doesn't work, change the .env APP_URL=http://yourProject.local:89
Ok another option, in /routes/web.php I assume you have a route set up that may either return a view or call a controller method. You could test to see if you can have this
‘return redirect('http://yourProject.local:89');’ This may involve a little playing around with the routes/controller, but this may be worth looking into.
Related
So, I've just created a new site on Laravel Homestead. I pretty much always use .app as my local tld, and I've not had a problem with it before.
I've just created 2 new ones in my homestead.yaml file:
admin.philcross.app
philcross.app
I've run vagrant reload --provision and verified it's in my /etc/hosts file. Both domains are, and point to my VM.
If I go to philcross.app, it works. I see the webpage. If I go to admin.philcross.app, it fails, tells men There's an ICANN collision. However if I view the source, I see my webpage source. Not the error source.
To make it even more weirder, I already use a couple of local other domains locally exactly like the above (for example subdomain.domain.app locally). And it works.
The admin.philcross.app domain also works in Firefox.
I'm using Chrome, on Ubuntu 16.10.
I've tried altering the order of the domain mapping in my homestead.yaml file (ie putting admin.philcross.app before philcross.app and vice versa).
I've tried multiple timesvagrant halt / vagrant up / vagrant reload --provision / vagrant provision`
I've tried opening my hosts file with sudo and saving
Does anyone else have any ideas? I'm completely stuck, and all googling so far has just said to put the subdomain in the homestead.yaml file (not helpful).
.app is a real TLD, owned by Google. It isn't open for registrations yet, but it is likely to become available soon; your browser is warning you that your domain is likely to conflict with a real domain in the near future.
Don't use .app for internal applications or development, even locally. (Don't use .dev either; it, too, is a real TLD that belongs to Google!) Use one of the four top-level domains that has been explicitly and permanently reserved for testing:
.test
.example
.invalid
.localhost
map your sites to same root:
sites:
- map: philcross.app
to: /home/vagrant/philcross/public
- map: admin.philcross.app
to: /home/vagrant/philcross/public
Situation:
As a developer I'd like to "clone" our development environment (on an office server) so we can use it locally (for example when no/limited internet access is available). We've decided to give Vagrant a try.
What did I do?
First I used PuPHPet to create a basic config including nginx, php (incl modules), composer, git, memcached etc. You can find my config here. I also added a nginx vhost for our website.dev. This is where I run into the first problem.
We use a few additional config settings to the location block. A rewrite, a fastcgi_pass and a include. This is not available so I searched a lot online and I found out I could use the following statement (was more a try/fail/retry).
location_cfg_append:
{ rewrite: ".* /dispatch.php break", include: "fastcgi-params.conf", fastcgi_pass: "127.0.0.1:9000" }
First question:
This does work, however is this the way to do this? I'm not sure if I should be editing this config file (the file generated by PuPHPet) directly.
Second question:
How should I 'upload' the fastcgi-params.conf file I want to include? I did not find a way to do this in the config.yaml but there is a way to run some scripts. For now I've added a echo [contents] > /etc/nginx/fastcgi-params.conf that does work. However...
Third question:
When the VM is provisioned the nginx config is created. When that is done nginx is restarted. However at that moment the fastcgi-params.conf file does not exist yet (this is created AFTER the provisioning).
When nginx reloads this will fail, trigger an error and the machine can not finish the provision sequence (so it will never create the config file).
I can create this file on the next boot (and then nginx will work) but this cannot be the correct way to do this. So: how can I (before nginx 'installation') create / deploy a file to the VM? Or more generic (question 2): How can I upload a file to the VM?
If this is totally not the way to go please let me know! This are our first steps into creating a locally development machine so other/better methods are welcome.
First question: This does work, however is this the way to do this? I'm not sure if I should be editing this config file (the file generated by PuPHPet) directly.
Yes, I encourage this.
Second question: How should I 'upload' the fastcgi-params.conf file I want to include?
Place it inside one of your shared folders. It'll be available within the VM and you can reference it that way.
Third question
The above answer fixes this issue.
I need to install multiple iDempiere instances in one server. The customized packages are different in build and the db they are using. Is there any way to deploy both of it in one server and access like localhost:8080/client1, localhost:8080/client2 . Any help appreciated.
When I want to reference several application servers I need to copy the path of various installations
and change the database name and port of each application :
/opt/idempiere-server-production/ (on port 8080 for example) for production
And
/opt/idempiere-server-test/ (on port 8081 for example) for test
the way you said is not possible, because the idempiere server for webapp is known as
http://hostname:port/webui
Running multiple instances of idempiere on a single server is not too difficult.
Here is what you need to take care of:
Install the instances into different directories. The instances do not need to share any common files. So you are just fine making a full installation for each instance.
Make sure each instance uses its own data base. Use different names for the instance data bases.
Make sure the idempiere server instances use different tcp ports.
If you really should need to use a single port to access all of the instances you could use a http server like apache or ngnix to do define virtual hosts. Proxying or use of rewrite rules will then allow you to do the desired redirections. (I am using subdomains and apache mod_proxy to do the job)
There is another benefit to using subdomains for browser access: If all your server instances use the same host name the client browser will sometimes not be able to keep cookies from different instances apart, which can lead to a blocked session as discussed here in the idempiere google group.
Use different DB user names. The docs advise not to change the default user name Adempiere and this is ok for a single instance installation. Still if you use a single DB user for all of your instances you will run into trouble once you need to restore a database from a backup file. The RUN_DBRestore.sh will delete and recreate the DB user which is not possible when the user owns more than one DB.
You can run all of your instances as services in parallel. Before the installation of another instance rename the service script: sudo mv /etc/init.d/idempiere /etc/init.d/idempiere-theInstance. Of course you will need to do some book keeping work wth the service controller of your OS to ensure that the renamed services are started as desired.
The service controller talks to the iDempiere server via the OSGI console. For this to work without problems in a multi instance environment you need to assign a different telnet port number to each of the instances: in the editor of your choice open the file /etc/init.d/iDempiere. Find the line export TELNET_PORT=12612 and change the port number to something else.
Please Note:
OS specific descriptions in this guide are for Ubuntu 16/18 or Debian, if on another OS you need to do some research.
I have been using the described approach to host idempiere versions 5 and 6 for some time now and did not have any problems so far. Still make sure you do your own thorough tests if you want to go that route.
If you run into any problems (and maybe even manage to solve them) please report back to the community. (by giving your own answer to this question or by posting to the idempiere google group) Thanks!
You can have as many setups on your server as you like. When you run the setup to create your properties, simply chose other web ports for each installation. You also may need to slightly change the webservers configuration if they have some default ports.
Has anyone successfully got this combination working?
It seems to run correctly on the client side, but there's something about Cloud9's file system that means changes aren't detected when files are saved, so I'm having to restart the app every time.
problem is that cloud 9 gives u only one port(process.env.PORT) and you are using this port for running web server and you don't any have additional port for live-reload server.
for CSS you can use Live.js
Safareli is correct that Cloud 9 gives you only one port, but Live.js, the website Safareli linked in fact does work with refreshing everything, although I don't know how taxing it is to C9 since it is refreshing for headers pretty much all the time.
I've an application running on a dev server and connecting to a dev-db hosting an oracle instance.
Now i'm deploying the on a prod/prod-db machine
Since the dev-db url is hardcoded inside the java code, the just-copied binaries still points to dev-db. As a quick warkaround i added a line in Windows Host file on prod so that dev-db now points to prod-db IP address. It's work, but i'm not very satisfied of this global-scope solution.
I was wondering if exits a way to make a hosts file "private" for a certain environments ie. only valid in the scope of my running application
No, there's no way to do this, and it's a bad approach anyway.
You should instead fix the real problem, which is the hard-coding of the address inside your java code. Put such things in a properties file, and use a different properties file for production.