ownCloud private web storage
ownCloud is a webdav based application allowing you to store files on your own personal server on the Internet and access them via http or webdav. Installation is as follows:
Ensure apache2, php and mysql are installed
$ apt-get install apache2 php5 mysql-server php5-mysql sqlite php5-sqlite
Download the latest stable (or the experimental version via git if preferred). At time of writing, the latest stable version is stable version 1.2 and install to the webserver directory:
$ wget 'http://owncloud.org/releases/owncloud-1.2.tar.bz2' $ bunzip2 owncloud-1.2.tar.bz2 $ tar xvf owncloud-1.2.tar $ mv owncloud /var/www/
Appropriate permissions need to be set so that the webserver has full control of the directory. On debian or ubuntu this is:
$ chown -R www-data:www-data /var/www/owncloud
Next you need to decide upon the database used, the administrator user and password. This is done through the "first run wizard" which will appear the first time the owncloud directory is browsed. Sqlite requires no configuration, while selecting MySQL will require additional information to build the tables.
ownCloud first run wizard
After configuration, the standard login will be presented:
ownCloud login page
once logged in files are displayed and options to upload or create directories are available under "More Actions":
ownCloud file listing
The web interface is now functioning as well as access via webdav. Since KDE supports webdav it is possible to configure access to the server storage space via the "Network" place as follows:
Select "Add Network Folder"
Select the "webdav"access method:
Select WebFolder (webdav)
fill in the details, notice that the folder field is set to "/owncloud/webdav/owncloud.php" (this assumes the installation was to /var/www/owncloud on a debian or ubuntu system)
Enter configuration details
Upon saving the details a prompt for the password will appear and an option to "Remember password" so you don't have to re-enter it whenever accessing the folder:
Enter password
The share will now appear in the "Network" places:
ownCloud in Network places
And can be used like any other folder on the system within KDE:
ownCloud access via webdav in KDE
The files themselves are stored in a per-user directory in a sub-folder of the owncloud directory entitled "data"
GRUB2 splash image
GRUB2 supports background images being displayed during the selection phase of the boot process. A wide variety of formats are supported, including jpg, png and tga. The image size should be 640x480 pixels.
Place the image in /boot/grub and run the command update-grub, looking for the indication that the image was found:
$ update-grub Generating grub.cfg ... Found background image: splashimg.png
The next time the system is boot the custom image will be displayed. My example image can be found below
Sample GRUB splash image
Debian and libdvdread
In order to watch all DVDs on Debian, the libdvdcss needs to be installed. This is not distributed with Debian due to certain restrictions, however, if the restrictions do not apply to you then the following correctly installs the necessary files. First is the installation of libdvdread itself
$ apt-get install libdvdread4
In order to install the CSS codings it is necessary to manually obtain them. /usr/share/doc/libdvdread4/README.Debian directs downloads from http://unofficial.debian-maintainers.org/ which then has a link to http://archive.debian-maintainers.org/unofficial/packages/libdvdcss/ from here is a directory entitled "current_i386" (among others) and inside is the deb file required for download. At time of writing the full path is: http://archive.debian-maintainers.org/unofficial/packages/libdvdcss/current_i386/libdvdcss2_1.2.10-1_i386.deb (note that the dev and dbg based deb files are not required for playing DVDs)
Once downloaded the CSS must be manually installed with dpkg
$ dpkg -i libdvdcss2_1.2.10-1_i386.deb
No further configuration is required
iFrames and cookies
While developing something for facebook I noticed that the PHP session of my code was vanishing - but only in InternetExplorer. After searching, it seemed the issue was to do with iFrames (as facebook opens the code in an iFrame). If the domain of the website inside the iFrame doesn't match the domain of the browser (esentially the site hosting the iFrame), then all cookies from that website are declined as they are seen as third party and potentially dangerous.
At present it appears that IE is the only browser to act in this manner, implementing Platform for Privacy Preferences (P3P) Project. However, there are two ways to resolve the issue. The first is to reduce the security settings of the browser, which is not very practical for the developer; and the second is to implement a P3P header with specific tokens set to allow the cookies. For PHP, this would be:
header('P3P: CP="CAO PSA OUR"');
These tokens are better explained here. I have since also found a facebook developers discussion on this issue here.
Where did the link go IE?
At work I noticed some HTML links weren't working in InternetExplorer; the HTML is still recognised as a link but clicking it does nothing. Here is some sample code to demonstrate the issue:
<a href="http://www.google.com">
<table>
<tr>
<td>Hello</td>
</tr>
</table>
</a>Other browsers seem to render this with working link just fine.
Apparently this is not correct HTML, but the standard only specifies how valid code should work, not how invalid code should work and it is therefore up to the implementation to define what to do in that instance. It's a shame that every other browser does something logically expected, but IE plays the odd-one-out.
Minimalist X setup
A minimalist X environment offering the most screen real-estate using xmonad as the window manager of choice and conky as an informational bar. A taskbar is not used.
Xmonad has a configuration file written in Haskell, however, a simple search on the net provided the basics for styling and for starting conky. The file is ~/.xmonad/xmonad.hs and the basics are as follows:
import XMonad
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.ManageDocks
import XMonad.Util.Run(spawnPipe)
import XMonad.Util.EZConfig(additionalKeys)
import System.IO
main = do
xmproc <- spawnPipe "/usr/bin/conky -q"
xmonad $ defaultConfig
{ manageHook = manageDocks <+> manageHook defaultConfig
, layoutHook = avoidStruts $ layoutHook defaultConfig
, normalBorderColor = "#009B95"
, focusedBorderColor = "#FFA900"
, modMask = mod4Mask -- Rebind Mod to the Windows key
}It's pretty self-explanatory and quite readable. Notice that conky is called from within the xmonad config file.
Conky uses a configuration titled ~/.conkyrc and in order to give the feel of a consistent theme, the same colours have been used in conky as they have in xmonad. Clearly this can be customised to your needs:
update_interval 1.0
own_window yes
own_window_type panel
alignment top_middle
gap_x 0
gap_y 0
use_xft yes
xftfont DejaVu Sans Mono:size=10
minimum_size 1280 10
TEXT
${alignr 25} ${color #FFA900} Eth0 ${color #009B95} ${downspeedgraph eth0 11,50 00CC00 FF0000} ${color #FFA900} Disk ${color #009B95} ${diskiograph /dev/sda 11,50 00CC00 FF0000} ${color #FFA900} CPU ${color #009B95} ${cpugraph 11,50} ${color #FFA900} Mem ${color #009B95} ${membar 11,50} ${color #FFA900} ${time %a, %d %b %l:%M%P}Obligatory screenshot of said design (click for fullscreen version):
minimalist xmonad and conky
Building a YUM repo
Yum is the application installer used by RedHat. It connects to various known repos to download requested software. To create a YUM repo simply drop all your rpm files into a directory on a web server and inform the RedHat system you wish to install them on by creating a file in /etc/yum.repos.d
The file should be called something.repo and the format follows the following:
name=My YUM repo baseurl=http://10.0.0.1/redhat5/myrpms/ enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
The gpgkey entry details a file with gpg auth details for the rpms in the repo, however, this will be disabled if gpgcheck is set to '0'.