VideoLAN Web Plugin: xpi vs crx

One of the main issue while preparing streaming solution is answering the obnoxious question:

  • Question: Is possible to use the service through a browser?
  • Answer: No, rtsp isn’t* http, a browser isn’t a tool for accessing any network content.
  • * Actually would be neat having rtsp support within the video tag but that’s yet another large can of worms

Once you say that you have half of your audience leaving. Non technical people is too much used to consider the browser the one and only key to internet. The remaining ones will ask something along those lines:

  • Question: My target user is a complete idiottechnically impairednaive and unaccustomed and could not be confronted with the hassle of a complex installation procedure, is there something that fits the bill?
  • Answer: VideoLAN Web Plugin

Usually that makes some people happy since it’s something they actually know or at least they have heard about. Some might start complaining since they experienced an old version and well it crashed a lot. What would you be beware of is the following one:

  • Question: Actually I need to install the VideoLAN Web Plugin and it requires attention, isn’t there a quicker route?
  • Answer: Yes xpi an crx for Firefox an Chrome

Ok, that answer is more or less from the future and it’s the main subject of this post: Seamless bundling something as big and complex as vlc and make our non tecnical and naive target user happy.

I picked the VideoLAN web plugin since it is actually quite good already, has a nice javascript interface to let you do _lots_ of nice stuff and there are people actually working on it. Additional points since it is available on windows and MacOSX. Some time ago I investigated how to use the extension facility of firefox to have the fabled “one click” install. The current way is quite straightforward and has already landed in the vlc git tree for the curious and lazy:


  
    vlc-plugin@videolan.org
    VideoLAN
    1.2.0-git
    
      
        {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
        1.5
        3.6.*
      
    
  

Putting that as install.rdf in a zip containing a directory called plugins with libvlc, it’s modules and obviously the npapi plugin does the trick quite well.

Chrome now has something similar and it seems also easier so that’s what I put in the manifest.json:

{
"name": "VideoLAN",
"version": "1.2.0.99",
"description": "VideoLan Web Plugin Bundle",
"plugins": [{"path":"plugins/npvlc.dll", "public":true }]
}

Looks simpler and neater, isn’t it? Now we get to the problematic part about chrome extension packaging:

It is mostly a zip BUT you have to prepend to it a small header with more or less just the signature.

You can do that either by using chrome built-in facility or by a small ruby script. Reimplementing the same logic in Makefile using openssl is an option, for now I’ll stick with crxmake.

Then first test build for win32 are available as xpi and crx hosted on lscube.org as usual.

Sadly the crx file layout and the not so tolerant firefox xpi unpacker make impossible having a single zip containing both the manifest.xpi and the install.rdf served as xpi and crx.

by the way, wordpress really sucks

Syslog(3)

Recently Diego complained with me about the mod_accesslog I quickly drafted for Feng.

I didn’t check much about supporting bare files log but I just used syslog since that’s what I use for all the services that support it. Luckily he fixed the glitches I left since his usage patterns are quite different than mine.

Bare file logging usually is used by default in certain applications mostly because:

  • You want to keep per-usage/per-user/per-deploy logs (think certain apache deploys)
  • Your application doesn’t support syslog at all
  • You didn’t knew about syslog and/or your logger daemon is a pain to configure
  • You are fond of logrotate and/or you like to get your disk full of historic data

Having syslog based logging usually has some disadvantages over bare file just because you have to configure both the logger and the application, but gets quite handy when you need to tune all the logs in particular ways like sending them over the network or having the server automatically notify critical issues over email.

I really dislike bare file logging, mostly because I’m quite fond of metalog (so I’m not afraid of configuring my logger) and while deploying gluster for Stack! Studios render farm I really hated having those stupid bare files around while the rest of the well behaving applications would had their log correctly routed from the storage nodes to the almost centralized logging facility.

Having proper centralized logging is surely useful when you have to admin a system with a large number of applications, but for a big and increasing number of nodes it gets a boon.

Moreover if you plan to have read-only netbooted root images and almost zero local storage (more on the crazy solution I’m baking with bartek at Stack! could appear sooner or later) you really start to love it (and have a love-hate relationship with syslog-ng for its less than crystal clear documentation)

Never a panacea: ModSecurity drawbacks

I’ve written before of using ModSecurity for reducing bots traffic, especially for those bots that are not important to the success of a site, like almost all of the so-called “marketing bots”. Unfortunately, installing and setting up ModSecurity with the defaults parameter can cause quite a bit of headaches, especially for technically-oriented applications.

There are indeed quite a few different drawbacks to the use of that module, in particular related to the Core Rule Set that ships with it; some of the rules are quite taxing to the web server (since it has to parse eventually a lot of data), and others are simply hitting false positives quite easily.

For instance, the rule with id 960017 (Host header is a numeric IP address) while very valid usually breaks for the Nagios HTTP check, while the very draconian 950005 will stop any application to receive posts that talks about most Unix paths, including /etc. Luckily enough, mod_security does have means to handle whitelisting from rules with multiple methods: you can use rules that hit on user-agent (bad idea for whitelisting) or source IP (better), or you can use Apache environments.

For instance, my Typo instance has the following entry in its vhost definition to apply both my antispam rules and exclude the draconian rule:

Include /etc/apache2/vhosts.d/modsec_antispam.include
SecRuleRemoveById 950005

(Yes there are a few things that still needs to be cleared up, especially regarding the trackbacks that should probably have different antispam rules from the comments; in particular, trackbacks probably shouldn’t arrive from browsers at all).

So unfortunately, before modsec can be set up as standard piece of software for Apache servers, time has to pass…

Windows 7: To bother the user or not to bother?

Recently has been found out that Microsoft has a whitelist of processes than can run with administrative privileges to prevent bothering the user with UAC when the software should be secure. While this might be a nice thing to do, I don’t really understand why notepad.exe, mspaint.exe and calc.exe would require administrative rights o_O

Also, as the FileOpen dialog from Microsoft permits to modify the file system, I think that it might not be a good idea to give administrative rights for free to software that opens files using it (like notepad and mspaint).

You would say that the solution is simple: just remove software that access the file system from that white list and you will prevent the user from causing damages. Well, this is true, you will prevent the user from doing damages, but as Microsoft has been so kind to give us API like CreateRemoteThread, which doesn’t inform in any way by default the user that its little new puzzle game is going to inject some code inside its uber calc.exe with administrative rights, it is practically possible to run anything with administrative rights under Windows 7.

I think that Microsoft will remove a lot of applications from the white list in the near future, but the problem is that the only effective use of UAC is the one that was present in Vista: Bothering the user for every single thing that happens. In the meanwhile the author of the exploit has been so kind to provide a vide of the exploit itself on his page, you can take a look at it here

Labs has born

I’m glad to say that finally we decided to create labs.axant.it to have a common join point between all our projects. Labs will have news about every project where we are working on and also news from our blog.

Take a look at that if you are a lscube or pyhp user, you might find interesting news about the project you are following.