EPIC4 maildir patch
Sunday, March 30. 2014
Trivial mod_rewrite: Redirect to another file in the same directory
Wednesday, March 19. 2014
I found a funny quote at Htaccess Rewrites - Rewrite Tricks and Tips, it says:
``Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo. ''
-- Brian Moore
bem@news.cmc.net
The quote is originally at http://httpd.apache.org/docs/2.0/rewrite/. Now obsoleted documentation for old Apache version.
I'll have to second Brian's opinion. I've touched the subject earlier at Advanced mod_rewrite: FastCGI Ruby on Rails /w HTTPS.
My YUM-repo definition RPM had a bug in it (see: CentOS 6 PHP 5.4 and 5.5 yum repository) and I had to release a new version of it. There exist already couple of links to the file. Why didn't I think of a situation where an update is released? Darn! So, let's keep the URL alive, even if a new version of the file with different name is released. That way everybody stays happy.
Attempt 1: Failure
An over enthusiastic "hey, that should be simple!" -type of naive solution. Create a .htaccess-file into the appropriate directory with content:
RedirectPermanent oldname.rpm newname.rpm
Well ... no. The result is a HTTP/500 and in the error log there was a:
/home/the/entire/path/here/.htaccess: Redirect to non-URL
Ok. It didn't work.
Attempt 2: Failure
Let's ramp this up. Forget the simple tools, hit it with mod_rewrite! Make .htaccess contain:
RewriteEngine on
RewriteRule ^oldname\.rpm$ newname.rpm [R=301]
Well ... no. The result is a HTTP/404, because the redirect goes really wrong. The result will be http://my.server.name/home/the/entire/path/here/newname.rpm, which is pretty far from being correct. There is a funny mix of URL and the actual filesystem storage.
The reason can be found from the Apache docs at RewriteRule PT-flag:
"The target (or substitution string) in a RewriteRule is assumed to be a file path, by default. The use of the [PT] flag causes it to be treated as a URI instead."
and
"Note that the PT flag is implied in per-directory contexts such as <Directory> sections or in .htaccess files."
That phrase can be translated as:
- Internally RewriteRule works with filesystem paths
- When using RewriteRule from a .htaccess-file it does not use filesystem paths, but URLs
- A .htaccess-file really messes things up
Something more elegant is obviously needed.
Attempt 3: Failure
I studied the Apache docs and found a perfect solution! What about if there was a way to discard the filesystem path entirely. Nice! Let's go that way, make .htaccess contain:
RewriteEngine on
RewriteRule ^oldname\.rpm$ newname.rpm [R=301,DPI]
Well ... no. I have the DiscardPathInfo-flag there, but it changes absolutely nothing. It is the same with or without the flag. It clearly says that "The DPI flag causes the PATH_INFO portion of the rewritten URI to be discarded" in the docs. Apparently the flag is used for completely different thing (which I'm having hard time to comprehend), but the thing is that I cannot use it to fix my redirect.
Attempt 4: Success!
After browsing the Apache-docs even more I struck gold. The docs for RewriteBase-directive say:
"This directive is required when you use a relative path in a substitution in per-directory (htaccess) context"
and
"This misconfiguration would normally cause the server to look for an "opt" directory under the document root."
That's exactly what I'm doing here. I have a relative path. I'm using a substitution in a .htaccess-file. It even mis-behaves precisely like in the example from the docs.
The solution is to make .htaccess contain:
RewriteEngine on
RewriteBase /path/here/
RewriteRule ^oldname\.rpm$ newname.rpm [R=301]
Now it works exactly as I want it to do! Nice! 
When a request is done for the old filename, Apache will do an external redirect and notify browser about the new version. wget fails to save the file with the new name (it will use the old name), but for example Firefox does that correctly.
Conclusion
Darn that voodoo is hard.
The mod_rewrite's complexity simply laughs at any system administrator. I consider myself to be one of the experienced ones, but still ... I find myself struggling with the subject.
Java 1.7 update 51 breaking Cisco ASDM login
Monday, March 10. 2014
One day I needed to drill a hole to a Cisco firewall. I went to Adaptive Security Device Manager and could not log in. Whaat?!
It did work before, but apparently something changed. Sneak peek with Wireshark revealed that SSL handshake failed. Java console has something like this in it:
java.lang.SecurityException: Missing required Permissions manifest attribute in main jar: https://dm-launcher.jar
at com.sun.deploy.security.DeployManifestChecker.verifyMainJar(Unknown Source)
at com.sun.deploy.security.DeployManifestChecker.verifyMainJar(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
and:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Java couldn't trust Server
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
Little bit of googling revealed Issues Accessing ASDM at Cisco's learning network and Cisco ASDM blocked by Java? at spiceworks.com. So I wasn't alone with the problem. Oracle's release notes for update 51 revealed a number of changes to earlier versions. Java is still piece of shit, but they're trying to fix it. Too little, too late. It is very unfortunate that I have to have Java Runtime installed and use it for a number of important applications. Now Oracle is making radical changes to JRE to improve its flaky security and these customer companies like Cisco cannot keep up with the changes.
Anyway, enough rant, here is how to fix it. The idea is to take the self-signed certificate from the Cisco firewall and import it for Java. This is yet another nice feature of a Windows-computer. There needs to be separate a separate certificate store for operating system, browser and Java.
First go to web-interface of the Cisco appliance. Internet Explorer cannot export a certificate from a web site, so use a Firefox or Chrome or pretty much any other browser. Save the certificate to a file. Like this:
When you have the file, go to Control Panel on Windows:
Select Java and Security-tab:
From there you can find Manage Certificates. Import the certificate-file from there:
It is very, very important that you first select Certificate Type: Secure Site. Any other certificate type won't fix the problem.
On the security-tab there is an exception list for certificates. Adding an exception won't fix this, since the problem is with the fact that the certificate is self-signed.
Now login works again.
When I first encountered this issue, I asked help from couple of guys who are very familiar with Cisco IOS (not Apple iOS). The initial response was "What is ASDM?" Apparently the GUI is not the expert's way to go.
Firefox per dir save
Sunday, March 9. 2014
Once upon a time there was a Firefox version which remembered where something was saved from a website. I think the last download destination directory was stored per host. I clearly remember that when I downloaded something from SourceForge, it would remember the directory, but since there are number of projects I download from it didn't always be a correct one. But for websites, I use for only one piece of software, it was always correct.
Then something changed. My Firefox wouldn't remember my destinations anymore.
Now for some nostalgic reason I wanted the functionality back. My loyal/hated aide Google found me a solution for that. A Mozilla support forum discussion named Changing FF25 download location in Win7 - Browse will not get past /User folder. It clearly states that such a setting exists, but is now off by default. When I went to my about:config, it looked like this:
Like the support forum promised, the configuration directive is hidden. They say hidden, but actually it is not created at all. Luckily you can add it by yourself by right clicking on the Firefox configuration:
Just add a new boolean variable with name browser.download.lastDir.savePerSite and you're good to go. Remember to set the value into true. It is enabled immediately, no restarting or anything needed.
The last thing for me to do is keep wondering why it was enabled in a couple of versions when it was introduced and then turned off.
