Subsections of Howtos

Filesystem Virtualization with Runner

Details

You are reading version 017 of this page. The current version can be found here.

Runner is a utility for launching programs under GoboLinux that ensures that the filesystem view of a process will match its dependencies. In other words, Runner eliminates the possibility of library conflicts when running an executable.

Runner is a filesystem virtualization tool that sets up a constrained view of /System/Index for a process based on the executable program’s Dependencies file. It is run as a wrapper, e.g. Runner SomeApp.

Runner builds a custom mount table for the process, like container tools do, but without duplicating files. It dynamically picks the correct parts of your /Programs tree. This approach is feasible in GoboLinux due to way programs are each confined to their own subdirectories.

Preparing the filesystem view

All you have to do is to make sure the dependencies of the program you want to run are correctly listed under the program’s Resources directory - more specifically, in the Dependencies file at /Programs/Name/Version/Resources/Dependencies. You may list program names (e.g., LibPNG), specify a particular version (as in LibPNG 1.4.4) or even let Runner pick the best version given a certain range (e.g., LibPNG >= 1.4.0, < 1.5.0).

Most likely, the program you want to run will already have a sane Dependencies file - every binary package we distribute will have one, just like every compilation recipe do.

The Compile tool

Compile makes use of Runner to control the environment for building software packages. When you type Compile Foo, Compile fetches the recipe for Foo and passes both the Dependencies and BuildDependencies files of that recipe to Runner. This ensure that the right versions of the libraries, headers, and executables needed by that package will be mapped onto /System/Index.

Spawning an application with Runner

For regular GoboLinux packages, simply type Runner application_name. Runner will figure from which entry under /Programs application_name comes from, and will create a custom filesystem view for that application by overlaying its dependencies over /System/Index.

For non-regular GoboLinux packages, such as third-party executables downloaded on your home directory, you can hand-craft a Dependencies file and then provide that file to Runner, as in Runner -d MyDependenciesFile ./third_party_app.

Multi-arch setups

Running a 32-bit application on a 64-bit distro is no different with Runner. Provided that you have the 32-bit dependencies installed under /Programs (such as Glibc/2.18-i686 and Bash/3.1-i686), the Dependencies file of your program simply needs to state the versions of the 32-bit packages it relies on. Afterwards, simply type Runner <application_name> and you are all set.

Set external mailto handler in Firefox

Details

You are reading version 017 of this page. The current version can be found here.

If you use Firefox and are not running it in KDE or Gnome you’ll often times find that mailto: links don’t always or never get handled the way you would like. If you’re interested in setting Firefox to handle mailto: links with an external program of any kind, here is how you do it:

  1. Open Firefox
  2. In the address bar go to the page about:config
  3. First look for the value of network.protocol-handler.expose.mailto and set it to true
    1. If the value doesn’t exists right-click and under “New” choose Boolean, then set the name and value to true
  4. Second look for the value of network.protocol-handler.app.mailto and set it to the application you want handling your mail.
    1. As with the previous value, if it doesn’t exist: right-click and under “New” choose String, then set it to the value of the application you want handling mail.
    2. ex. /System/Index/bin/xmail

Notes

Some useful ways of using this method is to establish a script to launch a web service as your default means of sending email. A simple script to handle that would be:

for the gmail service

. GoboPath
TO=$(echo $1 | sed 's/mailto://')
URL="https://mail.google.com/mail?view=cm&tf=0&to=${TO}"

GAMPS Howto

Details

You are reading version 017 of this page. The current version can be found here.

GAMPS is a GoboLinux/Apache/MySql/P/SSL web serving system. This document is intended to be a step-by-step manual on setting up a MySQL database server and Apache web server with PHP/Python/Perl/SSL support in GoboLinux.

MySQL

  1. First, you have to install MySQL. Fire up a console and type Compile mysql.

Once you’ve answered Compile’s initial wave of questions, you should have enough time to make yourself some coffee.

  • When the compilation has finished, you may choose a config file to use. The mysql configuration is stored in /Programs/MySQL/Settings/mysql, and the config file actually used has to be named my.cnf. The default config file is my-small.cnf. If you’re happy with this, go to the next step; otherwise choose one of the other config files and overwrite my.cnf with it.
  • Now it’s time to start the MySQL server. Do this by typing
StartTask MySQL
Note

If the server crashes at this moment you might want to check the permissions of /Data/MySQL. Owner and group must both be mysql. You can achieve this by typing

and starting the server again.

  • The next step is to set a password for the MySQL root user. Type
mysqladmin -u root password mYNewpAsSw0rD
  • If you want to start the MySQL server automatically at boot time, type
echo 'Exec "Starting MySQL Database Server..." MySQL Start' \ >> /System/Settings/BootScripts/BootUp
  • You can test your MySQL installation by typing
mysql -u root -p

If everything worked, you’ll be prompted for a password, then taken to the MySQL monitor.

OpenSSL - Part 1

Apache

  • As usual, compiling is the first step:
Compile HTTPD
  • After compilng, Apache should be ready to start. Just type
StartTask HTTPD
  • If you want to start the Apache server automatically at boot time, type
echo 'Exec "Starting Apache Web Server..." HTTPD Start' \ >> /System/Settings/BootScripts/BootUp

OpenSSL - Part 2

TODO

PHP

  • To install Apache PHP Module, type
Compile Mod_PHP

You have to restart Apache to load the new PHP module: StopTask HTTPD then StartTask HTTPD.

Python

Compile the module

Compile Mod_Python

Restart Apache again

StopTask HTTPD, StartTask HTTPD

If you use HTTPD 2.0.x you have to edit your httpd.conf (/Programs/HTTPD/Settings/httpd/httpd.conf) to load the Python module with Apache. Add the following line after the other LoadModule directives:

LoadModule python_module modules/mod_python.so AddType application/x-python-code pyo pyc AddType text/x-python py

Perl

TODO

Celebrate!

You’re done! All you have to do now is place your websites at /Depot/WWW/Documents

HAL Howto

Details

You are reading version 017 of this page. The current version can be found here.

With HAL and Ivman and pmount, you can have devices like CD-ROMs and USB flash sticks be automatically mounted and added to your panel or desktop. When you unmount it the mountpoint will be removed from your panel.

  • HAL is a hardware abstraction layer that keeps track of your hardware, both internal and removable. It’s like a database that adds information from the hardware and from .fdi files, and it can also call other programs when certain events happens.
  • Udev tells HAL when hardware is added or removed and replaces Hotplug in this functionality.
  • Ivman is a volume manager that can be set up to automount removable media, and to do all kinds of other stuff. It reacts when media is inserted or removed, or when a property of any device is changed.
  • Dbus is an IPC service that lets all these components communicate with each other.
Note

HAL and Ivman are not limited to storage devices, but also handle stuff like network cards and other hotpluggable devices on USB, Firewire, PCMCIA, etc…

Setup

The following was tried with Udev 070, HAL 0.5.4, DBus 0.50, Ivman 0.6.4, and Pmount 0.9.3. We are going to set things up so that Ivman is run as root and handles the automounting under /Mount/Media , with the help of pmount. Then users can run their own instances of Ivman too, to handle desktop specific stuff (like adding devices to the panel).

  • You need to be running Udev and DBus, make sure that’s the case and that the DBus system bus is started at boot. (Use StartTask messagebus)

  • You also need a recent kernel and glibc compiled against recent headers. This was tested with Glibc 2.3.5 with NPTL compiled against Linux-Libc-Headers 2.6.12.0

  • Install HAL, Pmount and Ivman:

] Compile hal
...
] Compile pmount
...
] Compile ivman
...

Pmount should be patched with http://kymatica.com/stuff/pmount-0.9.3-lijon.patch and HAL should be patched with http://kymatica.com/stuff/hal-0.5.4-lijon.patch (These patches should be included with the recipes, together with the small patch that escapes the $hal.volume.mount_point$ in ivmans src/manager.c:619)

  • Make sure there is nothing in /System/Settings/hal/device.d that does any mounting, becouse we want ivman to handle the mounting! (Actually I don’t think device.d works in HAL 0.5.4 since they moved to info.callouts.* instead…)

  • Make sure there is a haldaemon system group and user, and a plugdev group. Add all users that should be able to access and unmount removable media to the plugdev group. Note that users must log out and in again for the group changes to take effect

  • Start HAL as root:

] StartTask hald
  • Start Ivman as root:
] ivman
Note

If all this works, don’t forget to check that hald and ivman is started in your bootscripts:

Exec "Starting D-Bus system bus..."             messagebus
Exec "Starting HAL daemon..."                   StartTask hald 
Exec "Starting Volume Manager..."               ivman
  • Make sure Ivman is started as your user too: Add this script in your AutoStart folder:
#!/bin/sh
exec 1>&2
echo -n "Launching volume manager... "
if ps -C ivman -o user | grep -q $USER
  then
    echo "Already running."
    exit
  else
    echo "OK"
    exec ivman
fi
  • Disable mounting with usermode ivman, or else there will be problems if more than one user is logged in and running ivman at the same time… We want the root ivman to handle mounting. In ~/.ivman/IvmConfigActions.xml, comment out this section:

Ivman rules to add devices to your ROX panel

  • Create a script named ~/bin/rox.panelput and make it executable:
#!/bin/sh
### Change "Top" below to the panel you want your devices on...
rox --RPC << EOF
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body xmlns="http://rox.sourceforge.net/SOAP/ROX-Filer">
<Panel$1>
<Side>Top</side>
<Path>$2</path>
</panel$1>
</env:body>
</env:envelope>
EOF
  • And here comes the ivman rule, which should be inserted in your ~/.ivman/IvmConfigProperties.xml (this files is created first time you run ivman as a user)
<ivm:Match name="ivm.mountable" value="true">
<ivm:Property name="hal.volume.is_mounted">
<ivm:Action value="true" exec='rox.panelput Add "$hal.volume.mount_point$"' />
<ivm:Action value="false" exec='rox.panelput Remove "$hal.volume.mount_point$"' />
</ivm:property>
</ivm:match>

A nice ~/bin/eject script:

This lets you unmount your media and also FUSE mountpoints with the Eject entry on the right-click menu on mountpoints. Don’t forget to make the script executable.

#!/bin/sh
pumount "$1" 2>/dev/null || fusermount -u "$1" 2>/dev/null ||
echo "Could not unmount with pumount or fusermount -u" >&2

More patches

Spaces in mountpoint names

Ivman 0.6.5 and earlier have the problem that mountpoints are not enclosed by quotes when passed as arg to pmount. So if a inserted media has spaces in the desired mount point, pmount will fail! look in ivmans src/manager.c:619 and put " around the $hal.volume.desiredmountpoint$ thing… This bug was fixed upstream in Ivman 0.6.6, thus this workaround is no longer required.

Better mountpoint names

At least for me, my CD-ROM’s got mounted as /media/hde and stuff like that, this patch to /System/Index/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi fixed it so that media is mounted with the volume label as mountpoint:

-       <match key="@block.storage_device:storage.no_partitions_hint" bool="false">
-
+
<merge key="volume.policy.should_mount" type="bool">true</merge>
<merge key="volume.policy.mount_filesystem" type="copy_property">volume.fstype</merge>

@@ -173,7 +172,7 @@
<merge key="volume.policy.should_mount" type="bool">true</merge>
</match>
</match>
-       </match>
+
</match>
</match>

Note that you can put a copy of this file under /System/Settings/hal/fdi/policy and patch that one instead.

Making different types of media get different icons

With ROX, it’s also possible to have the inserted media get an icon that represents the type of media inserted.

    <?xml version="1.0" encoding="UTF-8"?>
    <deviceinfo version="0.2">
    <device>
    <match key="@block.storage_device:storage.bus" string="usb">
    <match key="info.category" string="volume">
    <merge key="volume.is_usb_storage" type="bool">true</merge>
    </match>
    </match>
    </device>
    </deviceinfo>
  • Change your ~/.ivman/IvmConfigProperties.xml rule to this:
<ivm:Match name="hal.volume.is_usb_storage" value="true">
<ivm:Property name="hal.volume.is_mounted">
<ivm:Action value="true" exec='rox.seticon Set "$hal.volume.mount_point$" $HOME/.ivman/usb.png' />
<ivm:Action value="false" exec='rox.seticon Unset "$hal.volume.mount_point$"' />
</ivm:property>
</ivm:match>

<ivm:Match name="hal.volume.is_disc" value="true">
<ivm:Property name="hal.volume.is_mounted">
<ivm:Action value="true" exec='rox.seticon Set "$hal.volume.mount_point$" $HOME/.ivman/cdr.png' />
<ivm:Action value="false" exec='rox.seticon Unset "$hal.volume.mount_point$"' />
</ivm:property>
</ivm:match>

<ivm:Property name="hal.volume.is_mounted">
<ivm:Action value="true" exec='rox.panelput Add "$hal.volume.mount_point$"' />
<ivm:Action value="false" exec='rox.panelput Remove "$hal.volume.mount_point$"' />
</ivm:property>
</ivm:match>
  • Create this script in ~/bin/rox.seticon and make it executable:
rox --RPC << EOF
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body xmlns="http://rox.sourceforge.net/SOAP/ROX-Filer">
<$1Icon>
<Path>$2</path>
<Icon>$3</icon>
</$1icon>
</env:body>
</env:envelope>
    EOF
  • And put some icons for other.png, cdr.png and usb.png in ~/.ivman/ and you’re done!

Installing Packages from the LiveCD

Details

You are reading version 017 of this page. The current version can be found here.

After installing GoboLinux and booting from the hard disk, you may want to choose software packages from the Live CD to install. To do so, you must mount the squashfs file that contains the image from the Live CD system.

To do that, first mount the CD then mount the desired GoboLinux squashfs file:

mount /Mount/CD-ROM
mount /Mount/CD-ROM/GoboLinux-NonBase.squashfs /Mount/ SquashFS -t squashfs -o loop=/System/Kernel/Devices/loop0`

Now, you can use InstallPackage to install software from the Program/ directory of the Live-CD:

InstallPackage /Mount/SquashFS/Programs/Inkscape

Note 1: after using the squashfs file, you may want unmount it:

umount /Mount/SquashFS

Note 2: To have the dependencies required by an application installed automatically, use the --batch or -b parameter:

InstallPackage --batch Gimp

-or-

InstallPackage --batch /Mount/SquashFS/Programs/Gimp

Java on GoboLinux

Details

You are reading version 017 of this page. The current version can be found here.

This page collects some information for Java on Gobolinux. Right now, not much is here :)

Recipes: GCC-Java Sun-JDK Sun-JRE

How to use Java with Firefox on GoboLinux

ln -s /Programs/Sun-JDK/Current/lib/mozilla/plugins/libjavaplugin_oji.so ~/.mozilla/plugins/libjavaplugin_oji.so

Manual Compile

Details

You are reading version 017 of this page. The current version can be found here.

Building and installing manually from source. This should only be done if one is unable to create a recipe or as an excercise. With very few exceptions, the work of creating a recipe is rewarded by the ease of using Compile.

Note

If you use a local tarball, be sure to have the tarball placed at /Data/Compile/Archives. Also make sure you know whether you have a recipe locally or not, if you ie do not have access to the www on that machine.

I’m using dosbox from CVS as an example here.

First, go into the folder where you have the source (change directory).

phed@Arjuna ~/]cd dosbox
phed@Arjuna ~/dosbox]

Run PrepareProgram with the option -t or –tree to generate the directory tree in /Programs/DOSBox/CVS.

phed@Arjuna ~/dosbox]PrepareProgram -t DOSBox CVS
phed@Arjuna ~/dosbox]

Then run PrepareProgram again without options to run configure

phed@Arjuna ~/dosbox]PrepareProgram DOSBox CVS
PrepareProgram: Preparing...
PrepareProgram: Autoconf configure script detected.
checking build system type... i686-pc-linux-gnu
...
config.status: creating config.h
config.status: executing depfiles commands
phed@Arjuna ~/dosbox]

Then we have to do whatever is required in order to build the application. In the case of DosBox we have to issue make in order to compile the program.

phed@Arjuna ~/dosbox]make
make[1]: L/bin/make  all-recursive
make[1]: Entering directory `/Users/phed/dosbox'
...
make[1]: Leaving directory `/Users/phed/dosbox'
phed@Arjuna ~/dosbox]

Next run SandboxInstall to install the program into the Programs-tree

phed@Arjuna ~/dosbox]SandboxInstall dosbox CVS
SandboxInstall: unionfs is available.  Using UnionSandbox!
SandboxInstall: Installing DOSBox...
...
SandboxInstall: Postprocessing Sandbox
phed@Arjuna ~/dosbox]

And at last, run SymlinkProgram to link it into the LHS tree.

phed@Arjuna ~/dosbox]SymlinkProgram DOSBox CVS
SymlinkProgram: Symlinking DOSBox CVS.
...
SymlinkProgram: Done.
phed@Arjuna ~-->dosbox]

And then we’re done. Enjoy!

Using Ndiswrapper with Proprietary Wireless Drivers

Details

You are reading version 017 of this page. The current version can be found here.

First of all, my network card is a Broadcom 802.11b/g WLAN pci card built-in in my laptop P4 Compaq Presario 2568. I didn’t found Linux kernel drivers for it, so I used the drivers of my WinXP installation.

What I needed to have it working was basically:

  • Install the package WirelessTools
  • Get the Win drivers for the wireless device and the .inf file correspondent
  • Install the ndiswrapper program
  • Use ndiswrapper to install the driver. This is the easy part, just run:
ndiswrapper -i DRIVER.inf
ndiswrapper -m

as gobo.

  • Use WirelessTools to configure the interface and to find an wireless network available
  • Use ifconfig to open the interface and DHCP to configure the connection.
  • Browse the web

You can automate some of this by adding a line to /System/Settings/modprobe.conf of install wlan0 modprobe ndiswrapper && iwconfig wlan0 … (put your usual commands here, with && between) and then adding wlan0 to /System/Settings/BootOptions with the right config.

Package Signing

Details

You are reading version 017 of this page. The current version can be found here.

QuickStart

First you need to create a pair of GPG keys. A nice GUI tool for this is KGpg. This is included with recent KDE-Utils.

If you haven’t used KGpg before, execing kgpg starts the “KGpg Wizard”. Follow the instructions to generate your key pair. Suggestions for key length and other properties? I’ve used the default settings: 1024 and DSA/ElGamal.

After the wizard, export your public key to a file. Use KeyManager --import key.asc to import the public key to Gobo’s system keyring.

Now you can use CreatePackage --sign and SignProgram to create signed packages and /Programs.

Overview

Private keys are kept in the users /.gnupg/keyrings. Public keys, used for verification, are kept in /Programs/Scripts/Current/Data/gpg/goboring.gpg.

Resources/FileHash is a text file containing the md5sums for each file.

Resources/FileHash.sig is the gpg signature for FileHash.

Sandbox Install

Details

You are reading version 017 of this page. The current version can be found here.

If I wanted to run make my self, what would I need to do to sandbox it? It would be useful to know how its done.

tar xvzf Foo.tar.gz
cd Foo
PrepareProgram Foo 1.0 -- --enable-crazy-feature-x
make
PrepareProgram -t Foo 1.0
SandboxInstall Foo 1.0
SymlinkProgram Foo 1.0

Also see Manual Compile

Upgrade Glibc

Details

You are reading version 017 of this page. The current version can be found here.

Question:

Hi, has anyone got any hints for glibc? I compiled 2.5.1 into /Programs/Glibc/2.5.1 but which step should i do next?

(Ideally this should be expanded… i have static versions of tar, bzip, bash, coreutils, binutils, make, but if i symlink brutally then ncurses has some links, so I probably need to do something differently.)

Answer:

I was in an even worse situation, since I was using a dynamic version of those programs. I totally trashed my system: every single program would segfault, and then the kernel started to panic at boot time. But I’ve found a solution which can be used either to fix the above ailment, or to cleanly install a new Glibc.

  1. Boot using the live-CD.

  2. Mount your root partition to /Mount/Media:

    mount /dev/hda6 /Mount/Media
  3. Install the version of Glibc you want. Note that the -r is essential, otherwise your /Systems/Index/bin links will point to subdirectories of /Mount/Media, which won’t be mounted anymore after you reboot.

    goboPrefix="/Mount/Media" SymlinkProgram -r Glibc 2.5.1
  4. Relink against the new Glibc. If you forget this step, all non statically-linked programs will segfault. If your boot process involves any (which it probably does), you won’t even be able to reboot!

    chroot /Mount/Media ldconfig -v

– Gelisam

To make this relatively painless, make sure to compile Glibc with using this command

Compile -l no Glibc

as it will stop Compile from symlinking Glibc after a successful compile and install.