I am trying to access an internal Wordpress blog that I've deployed like the following:
Because when I type the servername, it only displayed the plain HTML without the CSS effects and then when I try to go to the admin page it failed as well.
However when I go to servername/phpMyAdmin all is working well and the Apache server is listening on port 80.
The fact that you're seeing the blog content means that WordPress is installed and is working. If you're not seeing the CSS, it's likely a permissions problem of some kind with the files in your installation directory. If you're running suexec or some other SU wrapper, for example, make sure all the files have write and execute permissions removed (read only) at the group and other levels.
Related
Using the instructions in this link and the "How to Deploy Klondike"
github instructions I have installed the Klondike release on my local IIS (Version 10.0.15063.0). At first it looked promising, but then I realized that the main page is showing "loading..." rather than the Klondike URL. See image:
Additionally the when I click the API page tab, the site navigates to http://localhost:8081/api which returns a 404.0 HTTP error. This error may not seem very surprising as the site's directory does not contain an api directory. However, I have reverse engineering a working server with Klondike configured on it and it also does not have the api directory. Here is an image of the 404.0 error:
Additionally, when I try to nuget pushto localhost:8081, it results with the error in the image here (note, the red blocked out text is the apikey).
Finally, I have left the handleLocalRequestsAsAdmin is set to true, but even though I am on localhost, it does not show me the "LocalAdministrator" link. I believe that all these symptoms are linked to the same issue.
I have tried the following with no affect on the behavior:
Putting this site in c:\inetpub\wwwroot and also in C:\Klondike;
Using different port numbers, such as 8081 and 80;
Putting a 127.0.0.1 alias in my hosts file and binding the value in IIS to the host name; and
Installed the Debugging tools for Windows install as was suggested on the github site and set the debuggingToolsPath to its path.
(at this point, I'm just guessing at the issue)
The settings I have changed in settings.config file are as follows:
packagesPath = C:\Klondike\App_Data\Packages
Left lucenePath = empty string (I also tried this with a value of C:\Klondike\App_Data\Lucene with no affect.
symbolsPath = C:\Klondike\App_Data\Symbols
debuggingToolsPath = C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
ignorePackageFiles = "true"
I have not changed any values in the web.config file from the default web.config release values.
Thank you for any help that you can provide.
I ran into the same problem, although I was installing Klondike on a remote server rather than locally, but still IIS 10. The problem might be you don't have all the IIS components installed or enabled. More specifically, .NET or one of its required components might not be installed or enabled. If you look at the error on the /api link - it has to do with the MapRequestHandler and Static file handler in IIS - this indicates IIS doesn't know how to handle the request, which is an indicator you might be missing the ExtensionlessUrlHandler in IIS, as well as other components. To solve the problem, go to Start -> Control Panel -> Turn Windows features on or off (varies per system, might be under "Programs and Features"), then find the IIS Application Development Features. These might be listed under Internet Information Services -> World Wide Web Services, or Web Server (IIS) -> Web Server, depending on your system. Once you find these Application Development Features, make sure you have an ASP.NET option checked - you might just want to check all the options. Below is screenshot of what it looks like on my system. You might want to reboot after adding those features - not sure if a reboot is required, but it doesn't hurt. After you enable those features, you might start to run into all kinds of file permission errors when running the Klondike app - you might want to just remove Klondike and reinstall it from the zip file. I have a feeling it Klondike doesn't run cleanly the first time it has problems, as it needs to create an App_Data folder with sub directories.
This is very simple to reproduce:
Create a new VM (xtra small in my case, tried both Windows 2012
and 2008R2)
Install IIS using default config.
Create a Web Site using IIS Manager specifying a folder such as
C:\inetpub\simple.
Using Windows Explorer, create a new file called index.txt
Rename the file to index.htm
Edit the file with Notepad to make it a basic but valid html5
document and Save.
From IIS Manager, select the new website and click the Browse
Website link on the right side of the screen.
I get:
HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.
Now look at the Contents of the web site in IIS Manager and you will see that the file has a .txt extension pasted onto the end : index.htm.txt
This does not happen on my local server.
I am new to Azure and probably missing something very basic but right now I feel like I am going insane. Can anyone put me out of my misery?
This is IIS configuration issue, not Azure specific. And I would not even say it is an issue at all.
index.html is not in the list of default documents for IIS. And has never been. index.htm however is. You get 403.14 forbidden, because Directory Browsing is by default forbidden in IIS. Again, absolutely typical IIS configuration which hasn't changed for ages!
Your solutions:
Configure index.html to be in default documents (read how to do this here)
enable directory browsing (read how to do it here)
For the sake of others as stupid as me, this is all down to Windows Explorer configuration. Normally, the first thing that I do with a new Windows install is to turn off 'Hide known filename extensions'. This time I forgot.
I was working on my home server remotely and wanted to make some changes to my .htaccess. I could not see this files using my FTP(filezilla) and thought there was none there. I decided to upload one I had in my computer to my server in public_html and although the upload was successful per FZ, this file is not listed anywhere, even when I physically access the server.
It looks like it is being hidden. The main problem is that after this, now I get the following error message and cannot access my test site:
You don't have permission to access / on this server.
If I access my server and DISABLE SELINUX or make it PERMISSIVE, my pages start working as normal. If I make it ENFORCING my webpage becomes unavailable and I see the error listed above.
Questions:
First of all, how can I make this .htaccess visible in a CentOS 5.6 system?
What is the difference between ENFORCING and PERMISSIVE?
Will I run into Security Risks if I leave my server setup as PERMISSIVE?
Thank you all,
Heh. No one has answered this in 4 months because it's hard to find an answer that is direct & specific (per the guidelines) and won't start a discussion. But I'll give it a try.
FileZilla can show hidden files, the method is different for different versions. Try the View or Server menu, or look for "hidden" in the built-in help.
ENFORCING means that selinux is running and prevents actions that violate its active policies. PERMISSIVE means that selinux is running and logs (but does not prevent) actions that violate its active policies.
Yes. Specifically, in ENFORCING mode, a hostile entity would have to both upload a file with malicious code and set the selinux context for the file in order to run it. In PERMISSIVE mode, they just need to upload the file. This is the most likely explanation for your experience: you uploaded a new .htaccess file, but did not set its selinux context.
I have a new Orchard site which successfully runs the setup and database configuration when running locally. But when I tried to deploy it to the actual server and point a browser to the site, I get a "Directory Listing Denied" error.
Anyone seen this and fixed it?
I figured it out. Running on a shared web server, if IIS is configured for my site to use the default app pool, Orchard is precluded from reading its own files. (Remember that Orchard uses libraries and needs deep read/write access to subdirectories).
So the solution was simply to configure the site to run in its own isolated application pool.
Looks like this on my site's control panel:
Hope this solution helps someone down the line.
My guess is that you deployed the whole source code instead of src/orchard.web.
Hi
My app works fine when run from VSWEBdeveloper10.
But from IIS7.5, it doesnt apply stylesheets at all.
I have checked paths.
When I try to access stylesheet directly from browser, it redirects to the app's login page, and after logging in, it shows a weird sqlserver error.
Dont know how it relates CSS to sqlserver.
Note that, app works perfectly fine with VSWebDeveloper2010 while debugging.
Are you running the application as a virtual directory under the default website on port 80? If so, then your stylesheets and images are possibly not being found because the pathing is now incorrect according to the root of the default website. What works is if you actually create a new website on a separate port. Then your stylesheets will be found without a problem.