Installing Plone True Gallery

Problem
It should be simple as editing buildout.cfg and runing buildout again.
Edit buildout.cfg with:

$ joe buildout.cfg

Under eggs and zcml sections add collective.plonetruegallery string like:

eggs =
collective.plonetruegallery
...
zcml =
collective.plonetruegallery

Run buildout again with:

$ ./bin/buildout -v

This will give you the error:

Error: Couldn't find a distribution for 'gdata.py>=1.2.3'.

Problem is gdata.py package doesn't exists because it is now known as gdata only.

Solution

$ wget http://pypi.python.org/packages/source/c/collective.plonetruegallery/collective.plonetruegallery-0.6b2.4.tar.gz
$ tar xfz collective.plonetruegallery-0.6b2.4.tar.gz
$ cd collective.plonetruegallery-0.6b2.4
$ joe setup.py
Change gdata.py to gdata under dependency part so it looks like this:
install_requires=[
'setuptools',
'gdata>=1.2.3',
'flickrapi>=1.2',
'simplejson',
'elementtree'
],
$ sudo python2.4 setup.py install
$ joe buildout.cfg

Add zcml slug like:

zcml =
collective.plonetruegallery

Run buildout again with:

$ ./bin/buildout -v

Run your instance with:

$ ./bin/instance fg

Now, it should be under 'add on products' so you can install it.

Managing projects using buildout

Directories in the buildout
Before we dive into buildout.cfg, let us take a quick look at the directories that buildout has created for us:

bin/

Contains various executables, including the buildout command, and the instance Zope control script.

eggs/

Contains eggs that buildout has downloaded. These will be explicitly activated by the control scripts in the bin/ directory.

downloads/

Contains non-egg downloads, such as the Zope source code archive.

var/

Contains the log files (in var/log/) and the file storage ZODB data (in var/filestorage/Data.fs). Buildout will never overwrite these.

src/

Initially empty. You can place your own development eggs here and reference them in buildout.cfg. More on that later.

products/

This is analogous to a Zope instance's Products/ directory (note the difference in capitalisation). If you are developing any old-style Zope 2 products, place them here. We will see how buildout can automatically download and manage archives of products, but if you want to extract a product dependency manually, or check one out from Subversion, this is the place to do so.

parts/

Contains code and data managed by buildout. In our case, it will include the local Zope installation, a buildout-managed Zope instance, and Plone's source code. In general, you should not modify anything in this directory, as buildout may overwrite your changes.

The main [buildout] section
The [buildout] section is the starting point for the file. It lists a number of "parts", which are configured in separate sections later in the file. Each part has an associated recipe, which is the name of an egg that knows how to perform a particular task, e.g. build Zope or create a Zope instance. A recipe typically takes a few configuration options.

Our global settings are as follows:

[buildout]
parts =
plone
zope2
productdistros
instance
zopepy
find-links =
http://dist.plone.org
http://download.zope.org/ppix/
http://download.zope.org/distribution/
http://effbot.org/downloads
eggs =
elementtree
develop =

This specifies that the parts plone, zope2, productdistros, instance and zopepy will be run, in that order. Then, we tell buildout that it can search one of a number of URLs when it is looking for eggs to download. In addition, it will always search the Cheese Shop.

Next, we can list any eggs that buildout should download and install for us. This may include version specifications. For example, if you want sqlalchemy 0.3, but not 0.4, you could list;

eggs =
elementtree
sqlalchemy>=0.3,<0.4dev

Finally, we can list development eggs, by specifying a directory where the egg is extracted in source format. For example:

eggs =
elementtree
my.package
develop =
src/my.package

This presumes that there is an egg called my.package in the src/ directory. We will learn how to create such eggs a little later in this tutorial. Notice how we must also list my.package as an actual egg dependency: development eggs are not automatically added to the "working set" of eggs that are installed for Zope.

The [plone] section
This is very simple - it just uses plone.recipe.plone to download Plone's products and eggs.

[plone]
recipe = plone.recipe.plone

It will use the latest release available. Version numbers for plone.recipe.plone correspond to version numbers for Plone itself. Therefore, to make sure you always get a 3.0.x release, but not a 3.1, you can do:

[plone]
recipe = plone.recipe.plone>=3.0,<3.1dev

When the recipe is run, Plone's products will be installed in parts/plone. The eggs are made available via buildout variable ${plone:eggs}, which we will reference in the [instance] section later, and the URL of a "known good" version of Zope is available in the variable ${plone:zope2-url}.

The [zope2] section
This part builds Zope 2, using plone.recipe.zope2install. If you specified an existing Zope installation, you will not have this part. Otherwise, it looks like this:

[zope2]
recipe = plone.recipe.zope2install
url = ${plone:zope2-url}

Here, we reference the download location for Zope as emitted by the [plone] part. This ensures that we always get the recommended version of Zope. You could specify a download URL manually instead, if you wanted to use a different version of Zope.

When the recipe is run, Zope 2 is installed in parts/zope2. The Zope software home becomes parts/zope2/lib/python.

The [productdistros] section
This uses the plone.recipe.distros recipe, which is able to download distributions (archives) of Zope 2 style products and make them available to Zope. It is empty to begin with:

[productdistros]
recipe = plone.recipe.distros
urls =
nested-packages =
version-suffix-packages =

However, you can list any number of downloads. The recipe is also able to deal with archives that contain a single top-level directory that contains a bundle of actual product directories (nested-packages), or packages that have a version number in the directory name and thus need to be renamed to get the actual product directory (version-suffix-packages).

Consider the following distributions:

# A typical distribution

ExampleProduct-1.0.tgz
|
|- ExampleProduct
| |
| |- __init__.py
| |- (product code)

# A version suffix distribution

AnotherExampleProduct-2.0.tgz
|
|- AnotherExampleProduct-2.0
| |
| |- __init__.py
| |- (product code)

# A nested package distribution

ExampleProductBundle-1.0.tgz
|
|- ExampleProductBundle
| |
| |- ProductOne
| | |- __init__.py
| | |- (product code)
| |
| |- ProductTwo
| | |- __init__.py
| | |- (product code)

Here is what the part would look like if we try to install the three distributions above:

[productdistros]
recipe = plone.recipe.distros
urls =
http://example.com/dist/ExampleProduct-1.0.tgz
http://example.com/dist/AnotherExampleProduct-2.0.tgz
http://example.com/dist/ExampleProductBundle-1.0.tgz
nested-packages = ExampleProductBundle-1.0.tgz
version-suffix-packages = AnotherExampleProduct-2.0.tgz

You can specify multiple downloads on separate lines. When the recipe is run, the product directories for downloaded products are found in parts/productdistros.

The [instance] section
The instance section pulls it all together: It configures a Zope instance using the plone.recipe.zope2instance script. Here is how it looks:

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
debug-mode = on
verbose-security = on
eggs =
${buildout:eggs}
${plone:eggs}
zcml =
products =
${buildout:directory}/products
${productdistros:location}
${plone:products}

Here, we reference the Zope 2 installation from the [zope2] part - if you specified a location yourself when creating the buildout, you would see that one here. Then, we specify the initial admin user and password, and the port that Zope will be bound to. We also turn on debug mode and verbose security. These options are used to generate an appropraite zope.conf file for this instance. See the recipe page in the Cheese Shop for more details on the options available.

Next, we specify which eggs that will be made available to Zope. This references the "global" eggs from the [buildout] section, as well as the eggs specified by Plone. You could add additional eggs here, though it is generally easier to specify these at the top of the file, so that they get included in the ${buildout:eggs} working set.

As explained previously, Zope 3 configure.zcml files are not loaded automatically for eggs or packages not the Products namespace. To load ZCML files for a regular package, we can make buildout create a ZCML slug by listing the package under the zcml option:

zcml =
my.package
my.package-overrides

This assumes that my.package was previously referenced in the buildout. This would load both the main configure.zcml and the overrides.zcml file from this package.

Finally, we list the various directories that contain Zope 2 style products - akin to the Products/ directory in a traditional instance. Notice how the products/ directory in the main buildout directory comes first, followed by the products downloaded with the [productdistros] part, followed by the products downloaded by the [plone] part. This means that even if Plone ships with a product, you could override it (e.g. with a newer product) by putting a product with the same name in the top-level products/ directory.

When the recipe is run, the Zope instance home will be parts/instance, and a control script is created in ./bin/instance.

The [zopepy] section
This final section creates a Python interpreter that has all the eggs and packages (but not Zope 2 style products) that Zope would have during startup. This can be useful for testing purposes.

[zopepy]
recipe = zc.recipe.egg
eggs = ${instance:eggs}
interpreter = zopepy
extra-paths = ${zope2:location}/lib/python
scripts = zopepy

Here, we copy the eggs from the [instance] section, and include in the pythonpath the Zope instance home.

When the recipe is run, the script will be created in ./bin/zopepy.

Managing ZCML files
It is important to realize that Zope will not load configure.zcml files automatically for packages that are not in the Products.* namespace. Instead, you must explicitly reference the package. Buildout can create such a reference (known as a ZCML slug) with the zcml option under the [instance] part. Here is how to ensure that borg.project is available to Zope:

[buildout]
...
eggs =
elementtree
borg.project
...
[instance]
...
zcml =
borg.project

Should you need to load an overrides.zcml or a meta.zcml, you can use a syntax like:

zcml =
some.package
some.package-overrides
some.package-meta

Resources:
http://plone.org/documentation/tutorial/buildout/tutorial-all-pages

GnuPG

Create your public and private keys
In case you do not have '.gnupg' direcotry under your Home directory, create it with:

$ mkdir .gnupg

and set up permissions with:

$ chmod 700 .gnupg

Then generate keys with:

$ gpg --gen-key

Choose key type, key length and key expiration.
Then enter your 'User-ID' which consists of 'Name Surname', 'e-mail' and 'comment'.
Then enter your password for using keys.

To publish your public ID:

$ gpg --keyserver pgp.mit.edu --send-keys [e-mail]

Backing up your secret key
This will list keys on your secret keyring:

$ gpg --list-secret-keys

To make backup use:

$ gpg --output [outfile] --armor --export-secret-key [key_identifier as gleaned from above]

This will list keys on your public keyring:

$ gpg --list-keys

To make backup use:

$ gpg --output [outfile] --armor --export [key_identifier as gleaned from above]

key_identifier is usually in the form of something like: ABCDFE01

Depending on your host, you could also just copy the entire .gpg directory if you wanted to do it that way also.

Of course there is the paperkey utility if you need to make a paperkey backup of your secret key:

http://www.jabberwocky.com/software/paperkey/

Evolution integration
At security tab in settings dialog of your email account enter your key identifier.
You can find it by listing keys with:

$ gpg --list-keys

Search for eight characters where now stands 'XXXXXXXX'

pub 1024D/XXXXXXXX 2004-01-01 Name Surname (comment) [email]

Testing WEP and WPA protection

Aircrack is one of the easiest software bundles which let's you to access wireless protected networks. I have laptop HP Pavilion dv6500 with Intel PRO/Wireless 3945ABG [Golan] Network Connection wireless card. I'm using openSUSE 11.1 64bit as OS with kernel 2.6.27.19-3.2-default.

Wireless card features
* Chipset: Intel WM3945AG
* IEEE Standards: 802.11a, 802.11b, 802.11g
* PCI ID: 8086:4227

Prerequisites
* gcc
* libopenssl-devel
* sqlite3-devel >=3.6.10
* iw
* http://trac.aircrack-ng.org/attachment/ticket/572/sha-compile-fix-64bit.patch

Installation

$ wget http://download.aircrack-ng.org/aircrack-ng-1.0-rc2.tar.gz
$ tar -zxvf aircrack-ng-1.0-rc2.tar.gz
$ cd aircrack-ng-1.0-rc2
Patch source file sha1-sse2.S using instructions in sha-compile-fix-64bit.patch
$ make SQLITE=true
$ sudo make SQLITE=true install

Using airmon-ng
Stop previously started monitoring:

$ sudo airmon-ng stop wlan0
$ sudo airmon-ng stop mon0

Change MAC of your wlan interface

$ sudo ifconfig wlan0 down
$ sudo macchanger -A wlan0
$ sudo ifconfig wlan0 up
$ ifconfig

Create additional wireless interface mon0 in monitor mode

$ sudo airmon-ng start wlan0
$ iwconfig

Change MAC of newly created interface

$ sudo ifconfig mon0 down
$ sudo macchanger -A mon0
$ sudo ifconfig mon0 up
$ ifconfig

From now on you'll be using mon0 interface.

Using airodump-ng
Find wireless network which is protected with:

$ sudo airodump-ng mon0

and write down target ssid (ESSID), MAC adress of access point (BSSID), channel number (CH), encryption type (ENC). When finished CTRL+C to exit.

Create directory for dumping information with:

$ cd ~/Documents
$ mkdir data
$ cd data

Run airodump-ng to capture packets from your access point to dumpfile*.cap. You should always specify a channel with airodump, because otherwise it will try to scan through all channels, and that will break your injection attack.

$ sudo airodump-ng --channel [Access Point channel] --bssid [Access Point bssid] -w [dumpfile] [device]

After a few seconds in airodump-ng, you should notice that there are clients connected to the access point. Connected clients will be listed under "STATION" at the lower half of the screen.
Take note of the MAC address of one of the clients - you will use it in the next step. This could be your faked MAC if there is no clients connected.

Using aireplay attack 3 - ARP Injection
Open another terminal window to run an ARP replay attack. After some time, an ARP packet will come through and the #/s figure in the airodump-ng window will increase. If the RXQ (receive quality %) column is >90 then you should be getting #/s of 200 or higher, but more importantly, it should be much higher than what it was before.

$ aireplay-ng -3 -b [Access Point bssid] -h [client MAC addr. noted in previous step] [device]
-3 - is the number attack we're using. This attack keeps record of ARP packets which are used later on for decifering. There are 6 attacks numbered from 0 - 5.

Using aireplay attack 1 - Fake Authentication Attack
Usually attacks, 1 and 0, work together. There are situations when attack 1 will not work (i.e. MAC filtering is on), but it will work most of the time, and it's real quick. Currently, if you're following along, you should have two terminal windows open and running airodump and aireplay attack 3. If not, go back and follow the directions again.
To initiate attack 1 type:

$ aireplay-ng -1 0 -e [essid] -a [Access Point bssid] -h [yours faked client MAC addr] [device]

-1 - This is the number attack we're using. It is a fake authentication attack, making us authenticated with the AP so that we can deauthenticate, as you'll soon see.
0 - This is the delay between tries, if it doesn't happen on the first try, for a variety of reasons.

You must have fairly good power showing in airodump for this to work. It needs to be over 40 showing in the power column. Your experience may differ greatly. If all goes well, when you press Enter you should see something like:

10:13:24 Sending authentication request (Open System)
10:13:24 Authentication successful
10:13:24 Sending Association Request
10:13:24 Association successful :-)

What just happened is that you became associated with the AP, meaning that if you lose association, the AP will send out a call to get you back. This is what will usually start the ARP request. If you take a look at you console running attack 3, it possibly started getting lots of data in #Data and #/s columns. More often than not, you'll have to wait for the next step.

There can be many reasons that you won't be able to associate with the AP, meaning this attack failed. First of all, the AP may have MAC filtering on, which may be able to be circumvented. Or you may not be close enough to the AP to associate. It can also be that the encryption is WPA, not WEP, so you cannot use this method to inject.

Using aireplay attack 0 - Deauthentication Attack
If your #Data count is flying up, then you can skip this step. If not, or you are trying to crack WPA then read on.
If you followed up until now, you should a few windows open. One is running airodump, another is running aireplay attack 3. The last one ran aireplay attack 1 and you're back at the prompt now.

At the prompt type:

$ aireplay-ng -0 10 -e [essid] -a [Access Point bssid] [device]

-0 - is the attack number we're using. It is a deauthentication attack, meaning it tells the AP that we've disassociated and it tries to reconnect, sending out an ARP, which is what attack 3 is waiting for.
10 - is the amount of times it should send out the deauthentication. It may not reach the AP on the first try or what, so we like to do it a couple of times, hence the number 10.

This attack is best to use for WPA ecryption while waiting for HANDSHAKE to appear in upper right part of dumping screen.

If all went well then attack 3 should have picked up an ARP request, and it should be injecting very, very quickly. Go to the window with airodump, and watch with delight as the #Data count flies up.

Using aireplay attack 2 - Interactive Packet Replay
If your #Data count is not flying up, try this attack in which we are looking for large packet to use:

$ aireplay-ng -2 -p 0841 -c FF:FF:FF:FF:FF:FF -b [Access Point bssid] -h [client MAC addr. noted in previous step] [device]

When ask to use this packet say yes:

Use this packet: y

Final step - aircrack
For WEP encryption wait a few minutes until the #Data reaches 50 000. This should be enough, but we leave the attack running just in case. Just remember that if you are cracking WEP encryption you are waiting for more data and if you are cracking WPA encryption you are waiting for HANDSHAKE to appear in upper right part of dumping screen when some client is connecting on access point. So for WEP you should use aireplay attacks 3, 1 and 0 in that order and for WPA you should use aireplay attacks 3 and 0.

After collected enough data or got a handshake you can disconnect and go to another location with data. Open another terminal window and run aircrack-ng to initiate key searching:

$ sudo aircrack-ng -r masterdb wpa*.cap -w '/path/to/password.lst'

After some time you will have the key.

Resources
http://www.aircrack-ng.org/doku.php?id=tutorial
http://docs.lucidinteractive.ca/index.php/Cracking_WEP_and_WPA_Wireless_Networks

Doom on Linux

Doom 1 and 2

Prerequisites:
* SDL-32bit
* SDL_mixer-32bit

Download Doom legacy engine from:

$ wget http://prdownloads.sourceforge.net/doomlegacy/legacy_142_win32.zip

Copy *.wad files (doom.wad, doom2.wad, etc.) to extracted directory.

Start game with:

$ ./lsdldoom -opengl -IWAD doom.wad

where doom.wad is the name of *.wad file which you want to start.

Doom3 and RoE

Download doom3 installer from

$ wget ftp://ftp.idsoftware.com/idstuff/doom3/linux/

Create directory structure with:

$ mkdir -p /usr/local/games/doom3/base
$ mkdir -p /usr/local/games/doom3/d3xp

Now copy installer to doom3 directory with:

$ sudo cp doom3-linux-1.3.1.1304.x86.run /usr/local/games/doom3/

Start installer and install doom3

$ cd /usr/local/doom3
$ sudo sh doom3-linux-1.3.1.1304.x86.run

Start game with:

$ ./doom3 +set s_driver oss
$ ./doom3 +set s_driver oss +set fs_game d3xp

Create symbolic links with:

$ sudo ln -s /media/doom3/base/pak000.pk4 /usr/local/games/doom3/base
$ sudo ln -s /media/doom3/base/pak001.pk4 /usr/local/games/doom3/base
$ sudo ln -s /media/doom3/base/pak002.pk4 /usr/local/games/doom3/base
$ sudo ln -s /media/doom3/base/pak003.pk4 /usr/local/games/doom3/base
$ sudo ln -s /media/doom3/base/pak004.pk4 /usr/local/games/doom3/base

$ sudo ln -s /media/doom3/d3xp/pak000.pk4 /usr/local/games/doom3/d3xp

Resource:

http://zerowing.idsoftware.com/linux/doom/

Wolfenstein on Linux

Wolfenstein 3D

Well, this is the first FPS I played on PC 386, more then 15 years back at 1993. This was extraordinary experience. Although new games are much more real and gives you better atmosphere and reality, I can't forget this little fellow. So I tried to revive him after 15 years on my linux machine.

You'll need to download source code for wolf engine:

$ wget http://www.stud.uni-karlsruhe.de/~uvaue/chaos/bins/Wolf4SDL-1.6-src.zip

Additional System Requirements:
* Original game data files
* libSDL
* libSDL_Mixer

Using YaST or any other package manager install SDL-devel and SDL_mixer-devel package.
Extract downloaded source code and copy original game files *.wl6 to extracted directory. Don't forget to put original game file names to lowercase.

$ cd /path/to/extracted/source/Wolf4SDL-1.6-src
make

If you can't find original game files, then download shareware 1.4 version from:

$ wget http://www.users.globalnet.co.uk/~brlowe/wolf3d14.zip

and copy *.wl1 files instead. Again, rename file names to lowercase representation. If you are using shareware game files you will also need to change version.h file before compiling. Define CARMACIZED and UPLOAD and comment others. It is well documented and editing won't be problem.

After compiling, start game by starting wolf3d executable:

$ ./wolf3d

Reference:

http://www.happypenguin.org/show?Wolf4SDL

Return to Castle Wolfenstein

Additional System Requirements:
* Original game data files
* libstdc++-libc6.2-2.so which you can get by installing compat package using YaST or using zypper

$ zypper in compat

Create directory structure with:

$ mkdir -p /usr/local/games/wolfenstein/main

Download installer from:

$ wget ftp://ftp.idsoftware.com/idstuff/wolf/linux/wolf-linux-1.41b.x86.run

Copy installer to main directory with:

$ sudo cp wolf-linux-1.41b.x86.run /usr/local/games/wolfenstein

Run installer with:

$ sudo sh wolf-linux-1.41b.x86.run

Copy or create links for game data files:

$ sudo ln -s /media/Wolfenstein/Main/mp_pak0.pk3 /usr/local/games/wolfenstein/main
$ sudo ln -s /media/Wolfenstein/Main/pak0.pk3 /usr/local/games/wolfenstein/main
$ sudo ln -s /media/Wolfenstein/Main/sp_pak1.pk3 /usr/local/games/wolfenstein/main

Start single player with:

$ sudo bash -c 'echo "wolfsp.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss'
$ sudo bash -c 'echo "wolfsp.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss'
$ ./wolfsp

Start multiplayer with:

$ sudo bash -c 'echo "wolf.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss'
$ sudo bash -c 'echo "wolf.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss'
$ ./wolf

Resource:

http://zerowing.idsoftware.com/linux/wolf/
http://www.happypenguin.org/show?Return%20To%20Castle%20Wolfenstein

Kernel upgrade removes NVIDIA module

Using YOU (YaST Online Update) on openSUSE, I upgraded to new kernel version and after restarting system, NVIDIA module cannot be found. I was back to runlevel 3.
To go back to runlevel 5 you have to edit your /etc/X11/xorg.conf and comment the line with # like this:

# driver "nvidia"

or change "nvidia" to "nv" so it looks like this

driver "nv"

Restart your system or try to start X server using:

$ startx

After you reached init 5, go to YaST and serach installed packages with NVIDIA search key. Remove that installed packages to remove old uncompatibile drivers.

From NVIDIA download page, download latest driver that fits your system:

http://www.nvidia.com/object/unix.html

If you are not sure wich driver is right for you, try using this link:

http://www.nvidia.com/Download/index.aspx

Prerequisites

* compiler gcc,
* program make and
* package kernel-source

If you don't have them installed you can do it using YaST.

Go to runlevel 3 by typing the following comand as root in one of the consoles (which you can access by pressing ctrl-alt-f1)

$ init 3

Now go to the directory containing the drivers.

$ cd /the/path/where/you/saved/the/drivers/from/nvidia/website

Now simply type the following and follow instructions

$ sh NVIDIA-Linux-x86_64-180.29-pkg2.run -q

Installer will try to compile nvidia module for your new version of kernel.

The next step is to configure the X.org to use the new nvidia drivers. To do this, type the following

$ sax2 -r -m 0=nvidia

To go back to runlevel 5 type:

$ init 5

After each kernel update you need to run

$ sh NVIDIA-Linux-x86_64-180.29-pkg2.run -K