Restarting only a portion of a rack/Sinatra app - apache

The great thing about PHP is that if you have something like
clothes.com, clothes.com/men.php, clothes.com/women.php
Then if you only edit the men's page, only that particular "app" will be restarted.
But on rack/Sinatra I have to touch the restart.txt file to restart the ENTIRE website.
Is there a way around this problem, so that users browsing other parts of the site wont have any problems while another part of the site get edited?
(i'm using mod-passenger on Apache, not that it's important..)

This would be true in all cases anyway for editing (non-inline) views (not layouts).
Aside from that, if you're really worried about this then I'd suggest using versioned folders to hold the application code. When you do a deployment, change the proxy to point at the newer version. Those who had already made requests will remain on an instance of Apache and the application that is already running, as long as their request remains alive, and seemlessly (unless you've broken something with the code) move to the new code on the next request.
It's also a convenient way to rollback to the/a previous version quickly and easily.

Check out the sinatra reloader from sinatra contrib

Related

Change Azure App API in real time

Prior to migrating from Mobile to App Services I could change node.js APIs in real time. Now changes seem to take an undetermined time to go live. I don't know if they're now being compiled or cached anywhere along the way. Ideally I would like to regain the ability to effect immediate change.
Technically, there is a file watcher that watches a subset of the files in your site - when you change one of those files, the site is meant to restart, thus making your change go live. This is configured in the web.config file which is a part of your site.
Make sure that the web.config is configured to watch the files you are interested in.
Restarting the site manually is a backup step that is effective.

Website move: how to block/detect all HTTP requests to old domain

I'm moving a website from old.com to new.com/old, but I have to make sure it works before deleting old.com.
It's a very large legacy website that probably has links, images, scripts and other things hardcoded to old.com. The problem is that these references to old.com aren't obvious since the site loads up perfectly since old.com is still up.
Is there a way to block all requests to old.com from my local machine only, or some other tool to make finding these references simpler?
The former is done by updating your hosts file on your local machine to point old.com to something else, this overrides what the internet DNS states. The latter very much depends on how your application is build and there is not enough info here.

Ektron really slow to startup on local host, how to improve this?

We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.

Updating OSX right click context menu with new service item

I have created an application that exposes a OSX service for certain file by adding an NSService entry into my applications info.plist (as in http://www.macosxautomation.com/services/learn/), but I find that upon installing my application on a new machine the service doesn't show up quickly in the finder right click context menu.
I know that this is because pasteboard services hasn't re-indexed the /Applications folder and "discovered" the newly installed service.
I also know that I can force a re-index and discovery by manually running /System/Library/CoreServices/pbs.
The question here is what is the best way to ensure that my service shows up as quickly as possible for users who are installing my application for the first time.
I could execute a system call to "/System/Library/CoreServices/pbs" when my application starts up --If the user immediately starts my application--, but that only partly solves the problem (in addition I wonder if there is a better Cocoa API based way of doing this).
If my application is generally only accessed via the context menu, a user will never think to go out and start the application in the first place. They will only think it is broken when the context menu isn't there.
I am not distributing my application with an installer. I am simply providing a bundle that can be dragged and dropped into /Applications (as I believe Apple usually suggests).
Is there a way to expedite the process of service discovery when doing an installation in this fashion, so that there isn't any period of time where the user is without the newly installed service?
As a side note, it appears that the problem may not exist in 10.8 (or at least be as pronounced). Apple may have made this indexing happen more quickly in their most recent release.
I've actually ended up using
system("killall pbs;/System/Library/CoreServices/pbs -flush");
in one of my apps, just as you describe, though it's a long time ago, when 10.5 was in question as well.
You might want to try this function, however:
void NSUpdateDynamicServices(void)
which according to the documentation acts just like flushing pbs, but is a cleaner solution.
Also, if (according to your description), the app is nothing but a service, consider making it a really just a service - see (Installing the Service)
To build a standalone service, use the extension .service and store it in Library/Services.

Is it possible to debug mod_security2 issues without root access?

I've been developing an application in CakePHP recently, and all was well until it wasn't. On our development server (which I control) the application runs just fine. On the live server (which our university controls) most of my POST requests result in a 403 page. I've figured out that PHP is never even being called in these cases, and I'm 99% certain that the only real configuration difference between the two is mod_security2.
Here's my trouble. I cannot see the error_log file, because I am not root. I can't even list the directory that it's in. We have got to have the slowest admin on the planet, and I'm trying to get past this issue as quickly as possible. Is there any way to debug mod_security2 without simply throwing bits of post data at it until it breaks hoping to "guess" at what you might be doing wrong?
I've tried looking through the configuration files (which I do have read access to) but I've never used this mod before, and it's like wading through molasses. I don't even know where to begin.
Disabling the mod outright isn't an option, I'm simply going to have to work with it I'm afraid. HELP.