I have a hosted page on Microsoft Azure Web Sites (Shared) and have verified that PHP is enabled and working but I am not able to call PHP in an .html document. Is there any way to enable this?
Searched high and low on this one, sorry if it is a duplicate.
This drove me nuts too, documentation in so many areas is poor. I had the same problem last week.
Here is the fix:
On the management console of the site, under configure, scroll to Handler Mappings.
In handler mappings, in the first box, type *.html
In the second box type D:\Program Files (x86)\PHP\v5.4\php-cgi.exe
Save, then restart the instance. It will now process PHP inside HTML files.
One small thing, which I didn't realise till after as well. I instantly assumed, 5.5 is the latest and greatest, so why wouldn't I just update to 5.5 and use that engine. You can, and changing the folder structure to read 5.5 works, however the 5.5 build on Azure doesn't have PDO for SQL Server which makes connecting to a native SQL database a nightmare. So 5.4 is the best build IMO until they include that as well.
Hope this helps.
EDIT: Not sure if this is applicable to shared, I am using a small instance, but logic should be the same I would have thought.
Related
Hi I have an xpages app that I have built using the mobile extension library controls. The ap works fine if you go straight to the notes server but as soon as we use netscaler to access we are getting errors accessing the extention libarary files. We have tracked it down to not being able to access these “/xsp/.ibmxspres/dojoroot-1.6.1/dojo/dojo.js or whatever is in or around there.
For this post http://www.intec.co.uk/domino-8-5-3-greater-power-over-dojo-thanks-ibm-for-your-work/ it looks like these files use the new OSGi plugin functionality and are contained in a jar file on the server rather than as separate files on the domino server. Any idea how we can get the citrix gateway to see these files and use them?
Thanks
Mel
Seems like a Netscaler configuration problem to me. If the manuals don't help, ServerFault might be the better place to ask this question. As a wild guess: /. might be blocked by default since ../../../ is a popular path-traversal attack vector. Let us know how it goes
I'm about to walk into a project that will have files (mostly PHP) behind web root. I traditionally use Dreamweaver CS4 for development. For upload I'll do a hybrid of Dreamweaver and manual FTP. As a site gets larger and more complex keeping files straight by hand becomes painful (and dangerous) very quickly.
If you are facing similar issues, what are you using? What is the best way to handle this sort of thing? It'd be great if DW was aware of the idea of placing files behind web root, but there doesn't seem to be a way to handle this elegantly.
I think that you might want to check out revision control like Subversion. It does a very good job handling your changes and deploying it to the appropriate server (staging/production). You can even find fairly inexpressive solutions that will do it all for you (meaning once you make a change and send your changes to Subversion /commit/ then Subversion will send them to your sever automatically (or you can do it manually with a click of a button). You can also use Subversion for free, but then you would have to set it up yourself.
The only problem that I see -- I dont think that Dreamweaver CS4 does not support the latest version of Subversion.
You can also check out Git
I hope that helps.
Are there any special security measures to take when deploying a Drupal site to a production server?
For instance: I can imaging that we need to remove install.php from the root directory. Are there any more actions?
Or is there maybe a module available which checks the site for "world readiness"
The status report on http://your-site/admin/reports/status will tell you if anything is not quite right.
Under the performance admin page you can turn on various caching settings, but test your site with them turned on before deploying.
There is a book by greggles for securing drupal, which may be worth a look.
Ideally you've tested your code for insecurities before deploying, but configuration can often be missed. There's a mode for analyzing your Drupal site for misconfiguration that would lead to vulnerabilities http://drupal.org/project/security_review
Security Review makes the following checks:
Safe permissions on system files
PHP in comments or nodes
Whether error reporting is on
Unsafe input formats
If private files is on and if the files directory is outside webroot
Allowed upload extensions
Admin permissions granted to untrusted users
In addition to other suggestions, remove update.php also.
I'd also (re)move /scripts from the webroot
It's a minor thing, but you could remove the text files in the root of the distribution which leak the version number. Such as CHANGELOG.txt etc.
I don't remember how safely cron.php protects itself from flood-calling. You may want to look into whether it is worth limiting that to local-only or command-line-only access.
Ensure that .inc files are processed by PHP.
all this answers make you stop thinking after your install is done - but software has a history and after installing drupal you have one more baby to watch - in drupal´s case watch VERY closely! This means you MUST subscribe to the drupal security mailing list and read all mails that are coming form there - be prepared to get many emails. It is good, that the drupal team is providing these informations fast, but it is sad that there are really too many of these mails, what might be related to drupals programming style. be prepared to get up more than once in the middle of the night to update your drupal installation because some extension developer never did understand, why input from the web must be sanitized (yes, these kind of security problems are still happening in the drupal world.)
So "hardening" means "keeping up with updates", in drupals case these come quite often. Think about this if you have many sites and want to deploy to multiple servers - automatic deploymemts will help you save a lot of time.
Here's an excellent rundown for Drupal 7: http://www.madirish.net/242.
Most of its suggestions are relevant to Drupal 6 as well.
You should also remove the Theme registry rebuilding setting.
It rebuilds your theme registry on every pageload, so it makes your site very slow.
I've got a strong background in Linux and OSX, and just left a job where I was architecting systems based on those platforms.
Now I've got a Windows Server running IIS that has a number of different websites that it hosts. Most of them are just a bunch of HTML, JS and Images, with some ASP for some customer tools. (Each website has a different set of customer tools, or they are the same tools, but with minor code changes between them.) I'm also adding a develop web server with the same code, but the 'bleeding edge' stuff.
I need an effective way of managing changes and updates to the overall codebase (henceforth referring to both the images and the html and the asp, for all the sites). When a dev (or webmaster) checks in changes, I want it to show up automatically on the developer server, but should be manually pushed out to the live server. I'd be tempted to just make the websites SVN repositories, but I'd be concerned about the overhead of having the webdeveloper having to log into the server and trigger an SVN update via commandline/tortise (and heaven forbid, manage tags).
Ideally I'd also manage IIS profile settings between the systems, but the major need is to be able to manage the process, and expose it to our ASP developer, and our webmaster, both of which are used to just FTPing up the files to the live site.
So, any recommendations on tools (beyond some SVN hacking with BAT files + teaching the webmaster how to log into the server and do updates) or workflows that would help this out? I even considered an RPM type package (or some Windows equivalent, of course) to manage the live server, but that seems like a bit too much overhead.
First you need to decide how the webmaster knows that the latest in your SCM is ready for deployment (I assume you want some level of acceptance testing after the developer has checked in).
Depending on the above answer you should be able to define the steps to get the "approved" content built and updated on the web server, then it would be a matter of scripting this.
In the end the problem is not the commands to run, but knowing /when/ to run them, and that the last checkin from developers is not necessarily going to work 100% (even without mistakes two concurrent changes, each working, could conflict).
I'm not new to web publishing, BUT I am new to publishing against a web site that is frequently used. Previously, the apps on this server were not hit very often, but we're rolling out a high demand application. So, what is the best practice for publishing to a live web server?
Is it best to wait until the middle
of the night when people won't be on
it (Yes, I can pretty much rely on
that -- it's an intranet and
therefore will have times of
non-use)
Publish when new updates are made to
the trunk (dependent on build
success of course)
If 2 is true, then that seems bad if someone is using that specific page or DLL and it gets overwritten.
...I'm sure there are lots of great places for this kind of thing, but I didn't use the right google search terms.
#Nick DeVore wrote:
If 2 is true, then that seems bad if
someone is using that specific page or
DLL and it gets overwritten.
It's not really an issue if you're using ASP.NET stack (Webforms, MVC or rolling your own) because all your aspx files get compiled and therefore not touched by webserver. /bin/ folder is completely shadowed somewhere else, so libraries inside are not used by webserver either.
IIS will wait until all requests are done (however there is some timeout though) and then will proceed with compilation (if needed) and restart of AppDomain. If only a few files have changed, there won't even be AppDomain restart. IIS will load new assemblies (or compiled aspx/asmx/ascx files) into existing AppDomain.
#Nick DeVore wrote:
Help me understand this a little bit
more. Point me to the place where this
is explained from Microsoft. Thanks!
Try google for "IIS AppDomain" keywords. I found What ASP.NET Programmers Should Know About Application Domains.
We do most of our updates in the wee small hours.
Handy hint, if this is an ASP.NET site, whatever time of the day you roll out, drop in an App_Offline.htm file with a message explaining to users that the site is down for maintenance.
Scott Guthrie has more info here:
http://weblogs.asp.net/scottgu/archive/2006/04/09/442332.aspx