I have setup a Vagrant box with Ubuntu 12.04 and Apache2 (all very vanilla, as per Vagrant's tutorial). I've been testing it for web development and I stumbled across a weird issue (not sure if bug or feature):
I have setup a synced folder across my machine and the VM folder. Apache has been serving the files mostly well, except (up to now) for a JSON file I'm using.
If I edit it locally, it seemingly syncs it to the VM folder. Both copies are the same.
Although, if I XHR it from the browser after modifying it, I still get the previously served version of that file.
At first, I thought the browser had it cached, but after trying with 2 different browsers (Chrome(ium) and Firefox), after clearing their respective cache, the issue remained.
I finally managed to go around it by reloading (vagrant reload) the VM.
What I was wondering is if this is a bug or a feature and how can I go around it. Is Apache configurable to not cache server side for a specific folder/file/filetype?
vagrant use previous setting until you provision that new setting again, so after every change in vagrant do provision to see reflected output. There is no apache2 cache problem.
For that use command
vagrant reload vmname --provision
if your vm name is default then use
vagrant reload default --provision
it will reboot vagrant vm and apply change to vm .After provision you will be able to see changes.
Finally figured it out. This relates to an issue that occurs with both Apache and /or Nginx: the sendfile option in server configuration.
Basically a new file wasn't being sent/updated client side even when it was changed server-side by Vagrant sync mechanism.
Check this answer for a solution: here.
Related
I am building a docker which i can use for my work. I am using MacOS. If I create docker container with xdebug installed (Ubuntu 16, php7.2, xdebug, apache), code execution is extremely slow even if i am not listening to xdebug port. I have already get rid of 'mounts'.
So I decided to created something like this:
docker structure
And everything works just like i want. When i change cookie in browser, my wesbite works fast, but when i change cookie to another one, i am able to debug. But i am facing a problem that it logs out me when i change that cookie value and nginx proxies me to another server. (Each apache is a single docker container with ubuntu and apache)
So my question is if there is a workaround for this so I could share session between server that I don't get logged out? Or at least any ideas what needs to be changed in that scheme.
P.S. My project is Magento 2 and probably the source of an issue is in this one. But i actually don't think so.
According to https://www.nginx.com/products/nginx/load-balancing/, the sticky session is a feature of nginx plus.
I was trying to get the Apache server to work. When I was done with it I uninstalled the service and deleted all the server files. However I noticed even after all that going to localhost address shows me this page
How do I go on about removing this page from my localhost? Thanks
To expand on the previous comment ... after killing all httpd processes (and this may be a problem because Apache will respawn children) ... then reboot the system to see if the problem persists.
If it does persist, then Apache has not been uninstalled and it'll have to be uninstalled. If the system uses sysvinit, look in /etc/init.d for a script that starts Apache and disable that script.
If the problem does not persist then Apache was properly uninstalled and the problem will not recur.
For reasons too insane to even go into, I am attempting to install using the Bitnami Magento 1.9.2.4 image on a fresh Amazon AWS/Lightsail Ubuntu 16.04 instance (2gbs to avoid complaints and be sure I don't run into anything unnecessary).
I think this is really more of an Apache question. After I finish the install (success), I can't get the server to respond via the instance IP address at the default port (8080).
Regarding the old Bitnami Image, you can get (or wget) that Magento 1.9.2.4 image still, it's over here:
wget "https://downloads.bitnami.com/files/stacks/magento/1.9.2.4-3/bitnami-magento-1.9.2.4-3-linux-x64-installer.run"
So for the sake of anyone who's trying to work through the whole process, once you pull the above down to your instance you need to chmod the above file to 755. This assumes you are in the directory with your download:
chmod 755 bitnami-magento-1.9.2.4-3-linux-x64-installer.run
Then run it using it's full path, like:
/home/ubuntu/bitnami-magento-1.9.2.4-3-linux-x64-installer.run
So the install is going to ask a bunch of questions, for anyone keeping track my answers were all yes (ie. yes to Git, PhpMyAdmin, Beetailer... whatever that is).
Then I created an admin user / password etc.
As far as the port I didn't have anything running on 8080 so the install defaulted the port to 8080 with HTTPS on 8443 with MySQL on 3306 (more on ports in a minute).
I think Host/Domain is one of the keys to this problem. When I couldn't get the server to respond I just recreated an instance and tried a different Domain during the install process. I tried: internal AWS IP, External ACTUAL IP, 127.0.0.1
Here's what the Magento 1.9 Domain prompt looks like:
So basically that sort of brings us up to date.
Once I finished the install, like a normal human used to using bitnami as a cloud image I assumed the server would respond at whatever the default path was at the IP address it was running on. Ie:
BASEIPADDRESS:8080/magento
Not the case. When I hit that the server does NOT respond, hence the question. In addition to the above I have also tried the BASEIPADDRESS, and the BASEIPADDRESS:8080
Results checking open ports
So since the server is not responding I figured I would check the ports.
First I checked using netstat:
netstat -lntu
I got back:
Then I realized that netstat is now depreciated... so I went with:
ss -lntu
I got back:
(excuse the images, formatting wouldn't work for text)
To me it looks like 8080 (default) is open in both of those results. So why isn't the server responding at the default location?
#Bitnami Status = OK
Checking the status with:
/home/ubuntu/magento-1.9.2.4-3/ctlscript.sh status
Everything looks good:
apache already running
mysql already running
Memcached not running
Since it says Memcached was not running, I started memcached to see if that was the issue, no it was not.
I can access the instance via SSH and yes I am sure the IP is right. See images above.
I also posted this to the Bitnami community but haven't heard anything over there. Will cross populate as I get ideas.
It looks to me that you configured Magento using the private IP address, so you would not be able to access from your browser. A way to check it is by executing the following command in your machine:
curl -L 127.0.0.1:8080/magento
If that provides output, then the IP is misconfigured, so you would need to reinstall using the proper IP
So this ended up being PRIMARILY due to not running the Bitnami stack installer as root / sudo:
sudo /home/ubuntu/bitnami-magento-1.9.2.4-3-linux-x64-installer.run
Why Install with Sudo on AWS/Lightsail?
So the reason you need to install as sudo has to do with the fact that when run as the normal user (ie. not root) the installer defaults to port 8080 which is NOT open on aws by default. To complicate matters further you may not be able to get things running properly even if you manually swap to port 80 AFTER you run the installer.
To avoid a scenario where port 80 requires root access to utilize I just re-created my instance and ran the installer as root with the above command.
Host Setting
During install I selected the public IP for the "Host" prompt and everything worked as I thought it might (straight out of the box).
Thanks to Javier Salermon who put me on the right track and the devs at Bitnami for cueing me into the fact that 8080 is not open by default.
Traefik v1.3.1
Docker CE for Windows: 17.06.0-ce-win18 (12627)
I have the /acme folder routed to a host volume which contains the file acme.json. With the Traefik 1.3.1 update, I noticed that Traefik gets stuck in an infinite loop complaining that the "permissions 755 for /etc/traefik/acme/acme.json are too open, please use 600". The only solution I've found is to remove acme.json and let Traefik re-negotiate the certs. Unfortunately, if I need to restart the container, I have to remove acme.json again or I'm stuck with the same issue again!
My guess is that the issue lies with the Windows volume mapped to Docker but I was wondering what the recommended workaround would even be for this?
Can I change permissions on shared volumes for container-specific deployment requirements?
No, at this point, Docker for Windows does not enable you to control (chmod) the Unix-style permissions on shared volumes for deployed containers, but rather sets permissions to a default value of 0755 (read, write, execute permissions for user, read and execute for group) which is not configurable.
Traefik is not compatible with regular Windows due to the POSIX permissions check. It may work in the Windows Subsystem for Linux since that has a Unix-style permission system.
Stumbled across this issue when trying to get traefik running on Docker for Windows... ended up getting it working by adding a few lines to a dockerfile to create the acme.json and set permissions. I then built the image and despite throwing the "Docker image from Windows against a non-Windows Docker host security warning" when I checked permissions on the acme.json file it worked!
[
I setup a repo and have it auto building to the dockerhub here for further testing.
https://hub.docker.com/r/guerillamos/traefik/
https://github.com/guerillamos/traefikwin/blob/master/Dockerfile
Once I got that built I switched the image out in my docker-compose file and my DNS challenge to Cloudflare worked like a charm according to the logs.
I hope this helps someone!
I downloaded latest version of Odoo (Openerp v8) from GitHub. When installed on my localhost (my pc) it works fine. Now whenever I tried to install it on my remote server, database is created but not loaded and I have a blank page when it comes to my-remote-ip:8072/web (I launched it openerp-gevent along my config file but the same happens with the openerp-server command too).
When I check the log file, the process is stuck at:
.... INFO my-db-username openerp.addons.base.ir.ir_http: Generating
routing map
The last request processed by the system is:
'werkzeug.request': http://my-remote-ip:8072/web/js/web.assets_backend/77f77e2' [GET]>
This request is not served and leads to a blank page. I'm on ubuntu 14.04.
I wonder if there is protection in the coding that prevents odoo to be used from a remote server.
Please, can someone help me how to bypass this issue?
Use different DB for your remote server not same as localhost.
try to run remote server using this command
./openerp-server --xmlrpc-port=8072
you can change the port number.
Hope this will help... :)
I've been testing in virtual machines recently. IMHO check the postgress database and if all is working fine, then check python dependences, perhaps you missed some?
I've used this quick guide with success for my ubuntu 14.04 Vm with odoo 8
Thanks but your answer is not satisfying. I said that it works well on a local installation. And I know quite well about the installation process whatsoever.
Now, try to install Odoo on a remote server using your IP adress (which is my case as I haven't given a domain name to my VPS yet). You will notice that the installation process is not going to its end and points to a blank screen. I need to have feedbacks from persons who have tried the same operation. Again, thanks for all your valuable contributions to this issue.