This is purely academic curiosity. Is there a way for me to set up a web page, so that surfing to that page will cause IIS to restart (maybe to execute iisreset)?
Technically, it can be done. :-) I am not giving any pointers here. It is just about calling a process with enough privileges. If you have the privileges on the server, you can do it.
You can in fact crash a worker process quite easily too. Server.Transfer("~/default.aspx", true). [Assuming you are writing this code in page_load of default.aspx.
However, please do not try this on production server.
Related
I've been reading for a long time on various places about modules and how they work with IIS 7+. On a test server we installed Advanced Logging and got it configured the way we would like. A question came up though that I can't answer and that is will it take down any of our websites if I install the module? There are a few posts out there that talk about how to install the Advanced logging and some of them mention restarting IIS, or restarting the application pools (which I opted to not do just to see if I really had too, turns out I didn't have to) but as I've learned in the past is to not trust that if I didn't explictly do something it doesn't mean it wasn't done in the background.
The concern boils down to that we have 1 particular website that we want to installed Advanced Logging to. The website is heavily used 24/7 and taking it down unintentionally could get me in loads of trouble. hence my question. If I do install this will it take down our website temporarily to install the module or will it be smart about it and the feature will be available as the app pools cycle on their own?
It depends on the module and what the module changes, if the module modifies the web.config then it will will cause the application pools to restart.
Some modules will modify the applicationhost.config. I believe this module does that and it really depends on what gets modified in that file, some modification will cause restarting and others will not.
You can definitely test installing it on a test machine and see if the pools recycle. That's the approach I would take to get a definitive answer.
In the Azure Management Portal, you can configure your website. As an example, you can change the PHP version your website is using. When you have edited a configuration option, you have to click “Save”.
So far, so good. But you also have the option to restart your site (by clicking “Restart“ next to “Save”).
My question is, when should you restart your website? Are there some configuration changes that require a restart, and others that don't? I haven't found any hints in the user interface.
Are there other situations that require a restart? Say, the website has been running for a given time without a restart?
Also, what are the consequences of restarting a website? Does it affect cookies/sessions in any way (i.e. delete a user's shopping cart or log them out)? Are there any other consequences I should be aware of?
Generally speaking, you may want to restart your website because of application performance issues. For example, you may have a memory leak in your application, connections not getting closed, or other things that would degrade the performance of the application over time. As you monitor your website and observe conditions like this you may make a decision to restart it. Even better, you may even automate the task of restarting when these conditions occurr. Anyway, these kinds of things are not unique to Azure Websites. You would take similar actions for a website running on-premises.
As for configuration changes, if you make a change to your web.config file, this change is detected and your website would be restarted automatically for you. Similarily, if you were to make configuration changes in the CONFIG page of your website in the Azure Management Portal such as application settings, connection strings, etc., then Azure Websites will detect this change to your environment and automatically restart it.
Indeed, restarting a website will result in any session data kept in memory being lost for that instance. Additionally, if you have startup/initialization code that takes time to complete then that will have to be rerun. Again, this is not anything unique to Azure Websites though.
I have a fresh install of Moodle 2.1, PHP v5.3, Windows Server 2008 R2, IIS, MySQL, 3GB Ram, 4 CPUs.
I use Moodle as a VLE for a School, but have recently been having problems with it not responding (the browser just sits & loads, until eventually it receives a network connection error to the site).
Now, if I restart "Manage Server" in IIS - the problem is rectified, but occurs again a few days later. Some people suggested increasing the "recycling" time of the pools which kind of seemed to delay this problem, but it is starting to happen frequently again.
I have tried the Moodle forums but hit a dead end, please can anyone help? Thank You
I had a lot of problems trying to get Moodle going on IIS and eventually abandoned it. It sounds a lot like you have a memory leak (in IIS, not Moodle). A temporary solution would be a scheduled task that restarts IIS before and after the school day to reset it, but this is not ideal.
The pro advice is not to use IIS at all. Apache is the industry standard, it's available as an install package for Windows and it's not enormously hard to install and configure (see moodle.org's instructions). If you have come up blank on the forums and are still having trouble, then I would suggest that the small learning curve to get Apache going is probably the least work in the long run. Have a go on a test machine (could be an old desktop) and see how you get along. There are far, far more people who can help you configure Moodle on Apache than can help on IIS, which is enough reason in itself to have a go.
Sorry I can't be more helpful!
This may be a basic question, but how do I go about effeciently deploying updates to currently running node.js code?
I'm coming from a PHP, JavaScript (client-side) background, where I can just overwrite files when they need updating and the changes are instantly available on the produciton site.
But in node.js I have to overwrite the existing files, then shut-down and the re-launch the application. Should I be worried by potential downtime in this? To me it seems like a more risky approach than the PHP (scripting) way. Unless I have a server cluster, where I can take down one server at a time for updates.
What kind of strategies are available for this?
In my case it's pretty much:
svn up; monit restart node
This Node server is acting as a comet server with long polling clients, so clients just reconnect like they normally would. The first thing the Node server does is grab the current state info from the database, so everything is running smoothly in no time.
I don't think this is really any riskier than doing an svn up to update a bunch of PHP files. If anything it's a little bit safer. When you're updating a big php project, there's a chance (if it's a high traffic site it's basically a 100% chance) that you could be getting requests over the web server while you're still updating. This means that you would be running updated and out-of-date code in the same request. At least with the Node approach, you can update everything and restart the Node server and know that all your code is up to date.
I wouldn't worry too much about downtime, you should be able to keep this so short that chances are no one will notice (kill the process and re-launch it in a bash script or something if you want to keep it to a fraction of a second).
Of more concern however is that many Node applications keep a lot of state information in memory which you're going to lose when you restart it. For example if you were running a chat application it might not remember who users were talking to or what channels/rooms they were in. Dealing with this is more of a design issue though, and very application specific.
If your node.js application 'can't skip a beat' meaning it is under continuous bombardment of incoming requests, you just simply cant afford that downtime of a quick restart (even with nodemon). I think in some cases you simply want a seamless restart of your node.js apps.
To do this I use naught: https://github.com/superjoe30/naught
Zero downtime deployment for your Node.js server using builtin cluster API
Some of the cloud hosting providers Node.js (like NodeJitsu or Windows Azure) keep both versions of your site on disk on separate directories and just redirect the traffic from one version to the new version once the new version has been fully deployed.
This is usually a built-in feature of Platform as a Service (PaaS) providers. However, if you are managing your servers you'll need to build something to allow for traffic to go from one version to the next once the new one has been fully deployed.
An advantage of this approach is that then rollbacks are easy since the previous version remains on the site intact.
Usually we define iis web sites which allow anonymous authentication to run under the IUSR_ComputerName account which has very limited privileges. For example we may decide it cannot access the file system. How does that make our web site any more secured? The user cannot run code on it anyway - only our website code runs and we make sure it does not cause any harm.
Edit: I understand why it is good to be on the safe side (e.g. iis exploit). My question is if there is any direct reason. For example, if I would never give a guest account full privileges on a sql server as it would immediately allow him full control over my server. This does not seem to be the case with iis.
we make sure it does not cause any
harm
You can be never sure about it doesn't cause any harm. One day, it might be exploited, and probably the less privileged user would save your data. No offense, but no one writes perfect code, therefore no code is vulnerability free.
If you have any network service you should assume that some random person on the internet has a command prompt on your machine running as that services's owner.
Now ask what damage that user good do?
Typically, you may need to run your web site in a way that is a little less hardened from a security standpoint than, say, a domain server or exchange. For example, you may need to permit FTP access. Obviously, Internet web sites need to be accessed from the Internet so you cannot simply block all access with your firewall.
Because of the higher vulnerability, it is prudent to run your service with an account that has limited permissions. In the case where a malicious user does succeed in copying their own programs to be run on your server, those programs will have severe limitations as to what they can do.
You can run code on the server, for example you can delete files in a directory if the permissions are not set.