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
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/:
- first create a new branch (yes, this is really necessary)
- git checkout -b my_patch_branch_name
- make your changes (or copy the changed files over)
- commit your changes
- create the patch (save the changes in the new branch compared to the master branch)
- git format-patch master –stdout > fix_empty_poster.patch
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”
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
XSendFilePath /var/services/web /var/services/homes
SetEnv MOD_X_SENDFILE_ENABLED yes
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
When editing files, it is recommended to substitute spaces for tabs. For instance in YAML-files this is essential for the parsing to work.
So for vim you need to set some options. I used the following and got good results:
(found here: http://vim.wikia.com/wiki/Converting_tabs_to_spaces)
Hope this might help someone someday.
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.
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:
$mime_drivers['html']['inline'] = true;
- make a link to that file in /usr/share/psa-horde/imp/config
I can’t guarantee, that this will last beyond the next server reconfig, but for now my users are happy. 😉
Here’s another thing I always find myself googling again and again: How was that editor for the runlevel configuration under linux called again?
Well, the ones I use are:
They are both console-based (ncurses likely) and work like a charm. 😉