I'm working on setting up a website and at first I thought the website was broken but then I look and I'm getting 403d on everything under /javascript/
I've double checked the filesystem permissions. I can rename the javascript folder to js and access the files just fine from a browser. I've tried finding all the locations where the site tries to access /javascript/ and change it to just /js/ but there are some other scripts running that are generating some script tags and it's not proving easy to find them all.
My question is, is there an easy(ish) way to find where apache may be hanging me up? It's a basic apache2 install on ubuntu 14.04 running in a digital ocean droplet.
Now I feel silly.
Just ran grep -r "javascript" . just the same as I was using it to look for references in the website and I see there's a default aliasing of /javascript in the apache2 conf of javascript-common (though it didn't seem to show up in conf-enabled). I ran sudo a2disconf javascript-common and I had access back to the folder.
Related
I have a legacy CakePHP(1.3.13) app, running on Ubuntu server 16.04, on apache. It is using php 5.6. I'm trying to migrate the app to a development server, also Ubuntu 16.04, but running php 7.2.
On the production machine, php file(s) are being executed even before line 1 of index.php in the app I'm trying to migrate. On the dev box, this isn't happening.
I've sudo tar'ed the entire web server tree, and sudo untar'ed it on the dev box. I've copied the apache site configs, and only edited them for hostnames.
I don't understand why apache is running one or many php files PRIOR to running index.php on the production box. It is apparently loading a custom configuration php file, that sets up some global variable, but for the life of me I can't figure out why this is happening. I'm sure I'm just missing something dumb.
Greg Schmidt nailed it. There was a second auto_prepend_file=MagicallyExecutingScript.php in the php.ini.
I purchased a fancy little "visual menu maker" over at envato (Code Canyon) from here: https://codecanyon.net/item/z-menu-maker-drop-down-and-mega-menu/9240528
I was using their sample app where you can test out the tool and I was able to create a nice little menu for my site. But you have to purchase a license to export the code.
I purchased the license and the first "Getting Started" requirement is to "Start your Web Server and open the index.html file. This is where I'm lost. BTW... for reference, you can scroll to the bottom of that documentation page to see all the files that were included in the download.
When I try to open that "index.html" file in my browser, it doesn't load.
I followed some instructions to get my native Mac Apache server running, and everything seems to be working, with my localhost, but I don't know how to open this file through my Apache Web Server.
Any help would be so appreciated!!
I am assuming you have your Apache installed on your Mac under /etc/apache2 folder
If you want to serve your html files and related components, you need to tell apache from where to find your files
So , you need to configure apache so that it can server your files.
first you need to open an terminal from lunch menu then go to the apache2 installation directory
cd /etc/apache2
Then you need to open httpd.conf file and make necessary changes,
sudo nano /etc/apache2/httpd.conf
You will see "DocumentRoot" line/. Change it with your directory where you put your files.
Change also Directory path with yours. (It should be in same config file such as
with
<Document "some_path">
Then you should restart apache server with command
sudo apachectl restart
Now you can try to access your file . you can also check http://localhost to validate
You need to put the files somewhere within the DocumentRoot of your Apache web server, and then you should be able to visit them with http://localhost/ (assuming the index.html file is in the root of the DocumentRoot).
I'm not familiar with the default setting of DocumentRoot on the Mac port of Apache, but you should be able to find that quite easily in the configuration. On Linux that would commonly be found somewhere under /etc/apache2 or /etc/httpd.
There may be further configuration needed if the files expect some sort of server-side module to be activated (e.g. PHP), but it sounds like they are just plain HTML.
Some good answers were given but I think this particular app needed a few extra steps in order to work properly.
The developer got back to me and told me I'd need to install a MAMP solution in order to run the app.
So I installed that and then took the unzipped folder and all its contents in this folder /MAMP/htdocs/
Then when I visit http://localhost:8888/ZMenuMaker/ the app runs without a hitch!
I've launched Wordpress on Google Compute Engine (via their automated launcher process). It installs quickly and easily and visiting the external IP displayed in my Compute Engine VM Instances Dashboard, I am able access the fresh installation of Wordpress.
However, when I scp an existing Wordpress installation oldWPsite into var/www/ then replace my html directory
mv html htmlFRESH
mv oldWPsite html
my site returns a 'failed to open' error. Directory permissions user:group are identical.
Moreso, when I return the directories to their original configuration
mv html oldWPsite
mv htmlFRESH html
Still, the error persists.
I am familiar with other hosting paradigms where I can easily switch between the publicly served files by simply modifying directory names. Is there something unique about Google Compute Engine? What is the best way to import existing sites, files, etc into the Google Cloud environment?
Replicate
Install Wordpress via Google Launcher on a micro-VM.
Visit public IP of the VM instance.
SCP a fresh installation of Wordpress tovar/www.
Replace the Google installed html directory with the newly created and copied Wordpress directory using mv commands.
Visit public IP of the VM instance.
===
Referenced Questions:
after replacing /var/www/html directory, apache does not work anymore
permission for var/www/html directory - a2enmod command unrecognized on new G-compute VM
The import .htaccess file had https redirect which caused the server to prompt failure since https is not setup in a fresh launch of Wordpress through GCE. Compounding the issue, the browser cache held that memory when the previous site was moved back to the initial conditions.
Per usual, the solution involved the investigation of user errors.
I built the login functionality for a website on an AWS ec2 ubuntu with LAMP setup and it was working fine. The PHP files for this were located in /var/www/html. Then, to also allow login from an android device, I added and began working on the directory android_login_api in the /www folder. After adding several files and directories to this I noticed the website was no longer working and displayed "This webpage is not available" when I attempted to reach it. Despite completely removing android_login_api and attempting to revert the directory /www to just the way it was when it worked, this error remains.
I have spent a few days searching for a solution, but most answers pertain to the setup of apache which was already working fine for me. I tried restarting apache but neither index.php nor any other files I specify can be reached. I have also spent a lot of time trying to edit apache .conf files but with no luck.
Any ideas about what may have happened or if there is a specific path I need but may have accidentally altered would be greatly appreciated.
Most of access problems are caused by incorrect configuration of Virtual Hosts which seems like the problem here.
As you mentioned, the readable directory was /var/www/html and then you tried to access /var/www/android_login_api, which is not accessible by default and is specified in your virtual host file for the website. Location: /etc/apache2/sites-available
If you have done it different to this article, it will be difficult for anyone to help you. Don't create hosts in apache.conf. Read it before reading my answer further.
When you make changes to the virtual host, don't forget to use sudo a2ensite yoursite.com.conf as well as restarting apache service with sudo service apache2 restart after enabling the site.
The last thing that you should know about setting up websites is www directory owner. When you done making changes to files via FTP or SSH, run sudo chown www-data:www-data /var/www -R. www-data is the username like root used by Apache to allow external access. Otherwise the fiels will be accessible only with 0755 permissions by any other user and not 0644.
This is just a bunch of things essential to make changes and work with HTTP servers. Though my answer is not clear and I'm unable to point out your issue, I believe I've given you additional knowlege/consideration points to troubleshoot your issue. Drop a comment for more specifics.
Under Windows7 I am running CentOS-6.2-x86_64-server (on VM) having Apache2 with php5 and mysql installed. The vm is working fine, apache and mysql are started.
Now I want to access a webpage on the vm host being opened by a browser under Windows7.
I get following message:
"Forbidden. You don't have permission to access /index.html on this server."
My windows firewall is activated. Via Windows console I pinged the VM server successfully.
What am I doing wrong or what I have to do?
This is almost certainly an issue of either permissions for the path you're trying to access, or the mode in which you are running Apache. If, in your httpd.conf or ssl.conf files, you have a directive like SSLRequireSSL for this path, it will show a forbidden message when you attempt to access it via http rather than https.
Another reason this can happen is if you have http basic auth set up or some such, and cancel the login process.
Probably the most likely reason though, is simply having too strict permissions set on the folder or files that Apache is attempting to serve. If you go to the path where index.html lives, and make sure that both the directory and the files you want, are set to chmod 644 and make sure that you set things as being executable if there are scripts to be run, then you should be able to serve via apache as expected. You may also then need to chown apache.apache the files in question if they need to be writable by apache as well, but the former should get you going at least.
EDIT: Fixed a typo.