I'm new here, and I hope someone can help me with Apache2.
I need to configure Apache to download any .xml files, instead of displaying the content.
I have no idea how to do this, and any light or direction that anyone can share on this is greatly appreciated.
You wrote the "displaying", so I understand that you try to get xml from server by brawser. If you really want to change behavior of getting any XML files from server (or from some folder) you can rewrite Mime-header of XML to application/binary. This is in config, you should search mime.conf or like it. Restart server after edit configs. After it Your brawser (and ALL OTHER requests to your server will get XML with header application/binary, then usual applications (and Your brawser) does not know what to do with that content and just will save it. There is some nuances, ex: Some applications can be coded hardly to interpet content as XML, then it nevermind mime-header.
Related
I have a quick question regarding my assignment for school. So essentially it is a webform and I upload a photo and some info, and the .cgi file populates the data into a profile. I got it working when I upload the image to "public_html/images" folder, however the assignment requires me to upload and retrieve the image from "public_html/cgi-bin/assn1/images". The image uploads to both the "public_html/images" and the "../cgi-bin/assn1/images". However, in the case of the latter, I can't retrieve it. Can someone please give me some information as to how I could go about doing this? Also this is the school server so I am limited to what I can do...
profile photo.... <img src="../assn1/images/$fileName">
Any help would be appreciate it. Thank you in advance.
Cheers
What, exactly, do you mean by "I can't retrieve it"? Are you getting some kind of error message or a missing image icon? Is anything being written to the web server error log?
It's possible that the web server is configured so that everything under the /cgi-bin directory is interpreted as a CGI program. In which case, you shouldn't be storing static content there.
I want to change the look and feel(ui customization) of Jenkins. Also I would like to add new views(say like new html pages or web pages) with navigation to the required jenkins pages etc.
Please let me know if any single plugins will help me to do so.Any relevant information(how ever generic) will be very helpful.
Any suggestions or links or tutorials is also appreciated.
PS:- Pretty new to jenkins.The inputs from here will help me to add more details to the questions.
I am looking for documents or tutorials that specify Skinning Jenkins using plugins like :-
https://wiki.jenkins-ci.org/display/JENKINS/Simple+Theme+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/jQuery+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/jQuery+UI+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/JSWidgets+Plugin
The plugin page is providing very little information on how to use these and the benefits and the extend to which the UI can be changed.
Any doc or link is appreciated.
Assuming you don't want to write a Jenkins plugin, for adding pages, the best suggestion I can make is to use an HTTP proxy such as NginX, and configure it so that the pages you want to add are plain html files, and Jenkins is proxied for the rest of them. To a visitor, they will look like they are all part of the same site; you could copy code from the head and body sections of Jenkins-served pages to include some of the navigation.
The Simple Theme Plugin, which you found, will let you do basic customization of the look and feel of Jenkins. I do that for my build server and proxy it using this configuration fragment for NginX. The relevant CSS is in this CSS file - toward the end, look for the // JENKINS CUSTOMIZATION comment.
We use the Simple theme plugin - pointed at a css file for the simple styling, and a JS file to fix a couple of DOM oddities (some of the tables in the new look and feel have mismatching column counts).
Those two files need only be hosted either a handy http server, or you can place them in usercontent.
You need only refresh the page in the browser to see the changes. Both files can then happily reference other files served up too.
Handy things to note:
Jenkins has jquery, parts of YUI loaded and prototype loaded - so you can use them in your scripts.
If while debugging, the refresh gets in the way then use the console to enter the following to temporarily stop it without pausing JS: refreshPart = function() {}
When making DOM tree changes to content that is refreshed - attach it to the layout updates with:
layoutUpdatecallback.add(my_function) - that way your changes are applied to new incoming content.
I am looking for a way to serve a few static HTML pages with TeamCity.
I dont want to set up an apache for that, if not absolutely neccessary.
Does anybody know a simple way (or URL scheme) to access static HTML content. I found the following plugin, but that only inserts snippets of HTML in certain positions on existing pages. No way to include a full page. PluginLink for others as help.
Thanks for ideas,
Chris
Solution:
Go to e.g. C:\TeamCity\webapps\ROOT
Create folder e.g. static
Place file in it (but extension .jsp even if html)
Will be served without any problems (on URL/static/test.jsp)
It's a Tomcat server, just go on your file system where you installed Teamcity and you should be able to find out where you can park some html that will then be available on the Teamcity urls.
I have a one page javascript(Backbone) frontend running on S3 and I'd like to have a couple of deeplinks to be redirected to the same index file. You'd normally do this with mod_rewrite in Apache but there is no way to do this in S3.
I have tried setting the default error document to be the same as the index document, and
this works on the surface, but if you check the actual response status header you'll see the page comes back as a 404. This is obviously not good.
There is another solution, its ugly but better than the error document hack:
It turns out that you can create a copy of index.html and name it simply the same as the subdirectory(minus the trailing slash), so for example if I clone index.html and name it 'about', and make sure the Content-Type is set to text/html (in the metadata tab) all requests to /about will return the new 'about' which is a copy of index.html.
Obviously this solution is sub-optimal and only works with predefined deeplink targets, but the hassle could be lessened if the step to clone index.html was part of a build process for the frontend. Using Backbone-Boilerplate I could write a grunt task to do just that.
Other than these 2 hacky workarounds I dont see a way of doing this other than resorting to hashbangs..
Any suggestions will be greatly appreciated.
UPDATE:
S3 now (for a while actually) supports Index Documents which solves this problem.
Also if you use Route 53 for your DNS management you can set up an alias record pointing to your S3 bucket, so you dont need a subdomain+cname anymore :)
Unfortunately as far as I know (and I use s3 websites quite a bit) you're right on the money. The 404 hack is a really bad idea as you said, and so you basically have these options:
Use a regular backend of some kind and not S3
The Content-Type work-around
Hashbangs
Sorry to be the bearer of bad news :)
For me, the fact that you can't really direct the root of the domain to S3 websites was the deal breaker for some of my stuff. mod_rewrite-type scenarios sounds like another good example where it just doesn't work.
Did you try redirecting to hash? I am not sure if this S3 feature was available when you asked this question, but I was able to fix the problem using these redirection rules in static web hosting section of folder's properties.
<RoutingRules>
<RoutingRule>
<Condition>
<KeyPrefixEquals>topic/</KeyPrefixEquals>
</Condition>
<Redirect>
<ReplaceKeyPrefixWith>#topic/</ReplaceKeyPrefixWith>
</Redirect>
</RoutingRule>
</RoutingRules>
The rest is handled in Backbone.js application.
I am a total noob on this issue, and I wonder if I have to do that where I put the code :
In the virtual host / apache conf file ?
In a httaccess file ?
Redirect all URLs to a single entry point and parse it with a scripting language ?
What are the pro and cons ?
I'd tend to go with the .htaccess because it's easier to maintain as part of a project's files, doesn't require kicking the web server to take effect, and will typically be faster than scripting-level rewrites.
This depends on what exactly you want to do.
Rewriting rules should go in the configuration relating to the directory/site root which is typically your vhost configuration or htaccess (depending on setup).
Doing this through a script only makes sense if your redirect is based on extra information such as matching a 404 to a database of recently moved pages or a 404-URI to a search of some kind.
OK, so I put some summary of what I read on SO about it :
URL rewriting for redirection :
Better to put that in the Apache configuration. using .htaccess is the most flexible way but your Apache conf must allow it, if not, set the rewriting in the Vhost file.
URL rewriting for ressource management :
When it's about managing not found contents, access right or getting clean URL for accessing dynamic contents, you need to set the rewriting in the script file of your app since it's where you have access to the API to handle this kind of things.
So both of the ways are complementary, and you will usually use both at the same time.
.htaccess file in the directory should best place if you dont have any speed optimization concerns. And its also the way to go if your site is hosted on shared webhotel or your web application can create the htaccess files by itself.
Personally i prefer to have every configuration option in the virtualhost config file but thats good only if you have the root access.
It depends if you also need to do outbound URL-rewriting (the modification of links in the actual HTML pages themselves,) in which case, a tool like MOD_REWRITE will not do the trick for you, and you will need to use an "internal" or "native server-side" tool, in the case of Java, you would use something like PrettyFaces, or Rewrite.
These tools can also do the same type of inbound rewriting (like sending redirects to new pages, or forwarding to a new internal resource so that users do not know they are seeing an address/URL change.
My general rule of thumb, however, is that if the URL-rewrite rules need to be available when the application is running, you should use something like MOD_REWRITE, but if the rules only apply to that application itself, then they belong inside the application and you should use a native tool.