How to unpack a gem for local usage?

This bugged me for a while, so I decided to make a note to self for future reference.
If you try to include the gem in your bundle (e.g. for a rails app), you need to unpack the gemspec too.

The commands are:
 $ gem unpack gemname --target vendor/gems
 $ cd vendor/gems/gemname-VERSION
 $ gem unpack gemname --spec
Advertisements

(how to) create a patch with GIT

I admit this is probably not an ideal setup, but I’m running apps, that I checkout and update via GIT. If the publisher issues an update, all I have to do is run git pull (or switch to tag or branch).
Another upside is that I can track any changes I made to the code – a technique called monkey-patching. The changes are usually needed to adapt the software (PHP, Ruby, Java) to my particular needs. I therefore makes little sense to contribute those changes back to the (open source) project.

If you want to apply those changes to a different installation or re-apply after an (software-internal) update, you need a way to replicate the changes. A good way for this are patches – one or more files containing only the changes made to particular files.

Here’s the short version for creating a patch, found at https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/:

  1. first create a new branch (yes, this is really necessary)
    • git checkout -b my_patch_branch_name
  2. make your changes (or copy the changed files over)
  3. commit your changes
  4. create the patch (save the changes in the new branch compared to the master branch)
    1. git format-patch master –stdout > fix_empty_poster.patch
  5. done.

To apply the patch, run the following:

  • git am –signoff < fix_empty_poster.patch

This actually applies the patch and signs off on it, which means the changes are commited to the branch (most likely main) your current copy is on. Check “git log” and you’ll find the applied patch in the comments.

That’s it – just a short procedure.

PS: To switch your current working copy back to the master branch, run “git checkout master”

Owncloud pdf viewer not working on synology NAS

I ran into this problem multiple times now. Unfortunately, it occured with a considerable delay, so I had forgotten about the solution the second and third time around.

The error is, that you click on a PDF-file in your owncloud web interface file listing and want to view it. But no luck – the viewer only gives you an error message.

Like, the error is caused by an Apache module called mod_xsendfile.
On my synlogy NAS it has a config file located at: /etc/httpd/conf/extra/mod_xsendfile.conf-user

This you need to edit to contain the following:

LoadModule xsendfile_module modules/mod_xsendfile.so
XSendFile on
XSendFilePath /var/services/web /var/services/homes
SetEnv MOD_X_SENDFILE_ENABLED yes
XSendFilePath /volume1

Especially the last directive is key to making owncloud work again.

Now restart the webserver with:
httpd -k restart

Hope this saved you some time. It will for me the next time I encounter this error. 😉

PS: found this fix at: https://forum.owncloud.org/viewtopic.php?f=26&t=21036

log into mySQL on Plesk server

If you can’t log into your mySQL with your admin username and password on a Plesk (> 11) machine, this is for you. Try:
# mysql -u admin -p`cat /etc/psa/.psa.shadow`

This takes the contents of the /etc/psa/.psa.shadow file and uses it as the password for your mySQL-server. This works for me and seems to be the new default. 😉

Hope this works for you, too.

enable horde webmail to display html (and multi-part) messages inline

Did your users complain, that they can’t open emails with html content in them? Are those users using your Horde installation? 😉

This problem occurs due to the default setting in Horde Webmail, which is justifyable: Displaying HTML content and images opens the door for SPAM and potentially even malware. So, I’d even go so far and say it is a good default. But we all want to make our users happy, right? So how do we go about this?

Easy: Look at the documentation here -> http://www.horde.org/apps/imp/docs/INSTALL

Then stop and think: “shoot, I have a Plesk machine that might override the settings at every reload of domain.” 😦
Ok – I’ve been there. Here’s my (admittedly imperfect) solution:

  • create a file called mime_drivers.local.php in /etc/psa-webmail/horde/imp
  • put the following content in:
<?php
$mime_drivers['html']['inline'] = true;
?>
  • make a link to that file in /usr/share/psa-horde/imp/config
  • done

I can’t guarantee, that this will last beyond the next server reconfig, but for now my users are happy. 😉