paul@6 | 1 | Introduction
|
paul@6 | 2 | ------------
|
paul@6 | 3 |
|
paul@6 | 4 | The userinstall distribution consists of a number of scripts, together with a
|
paul@6 | 5 | short configuration file, which allows non-root users to set up and use their
|
paul@12 | 6 | own package and dependency management facilities and to download and install
|
paul@12 | 7 | Debian packages without having to obtain root privileges. The software within
|
paul@12 | 8 | installed packages may then be used, subject to certain constraints such as
|
paul@12 | 9 | program environments, library paths, and so on. In effect, userinstall
|
paul@12 | 10 | provides a personal package manager.
|
paul@6 | 11 |
|
paul@6 | 12 | Contact, Copyright and Licence Information
|
paul@6 | 13 | ------------------------------------------
|
paul@6 | 14 |
|
paul@6 | 15 | The current Web page for userinstall at the time of release is:
|
paul@6 | 16 |
|
paul@6 | 17 | http://www.boddie.org.uk/paul/userinstall.html
|
paul@6 | 18 |
|
paul@6 | 19 | Copyright and licence information can be found in the docs directory - see
|
paul@6 | 20 | docs/COPYING.txt and docs/gpl-3.0.txt for more information.
|
paul@6 | 21 |
|
paul@17 | 22 | Thanks to Piotr Roszatycki, the maintainer of fakechroot, for helpfully fixing
|
paul@25 | 23 | system call coverage in that utility in order to attempt to support
|
paul@25 | 24 | cross-distribution bootstrapping.
|
paul@17 | 25 |
|
paul@6 | 26 | Dependencies
|
paul@6 | 27 | ------------
|
paul@6 | 28 |
|
paul@6 | 29 | fakeroot Tested with 1.5.10ubuntu2
|
paul@17 | 30 | fakechroot 2.8 or later required
|
paul@15 | 31 | debootstrap Tested with 0.3.3.2ubuntu3 on Ubuntu Hoary 5.04, 1.0.7~feisty1
|
paul@21 | 32 | on Ubuntu Feisty 7.04, 1.0.20~hardy1 on Ubuntu Hardy
|
paul@6 | 33 |
|
paul@22 | 34 | New in userinstall 0.2 (Changes since userinstall 0.1)
|
paul@22 | 35 | ------------------------------------------------------
|
paul@14 | 36 |
|
paul@14 | 37 | * Fixed an argument parsing error in the user-setup script.
|
paul@21 | 38 | * Adopted lsb-release environment variables instead of new ones like
|
paul@22 | 39 | DISTNAME, exposing derivatives of these variables by default.
|
paul@21 | 40 | * Added explicit keyring package installation.
|
paul@25 | 41 | * Added -do scripts for configuring and entering the chroot.
|
paul@25 | 42 | * Removed specific apt- and dpkg-related scripts, replacing them with the
|
paul@25 | 43 | general -do scripts.
|
paul@25 | 44 | * Added --root options to certain scripts in order to support normal chroot
|
paul@25 | 45 | installations.
|
paul@27 | 46 | * Added support for UML instance construction from distribution
|
paul@27 | 47 | installations, along with networking support and a uml-net script.
|
paul@14 | 48 |
|
paul@6 | 49 | Configuration
|
paul@6 | 50 | -------------
|
paul@6 | 51 |
|
paul@12 | 52 | If the system defaults are not to be used, or if userinstall is not installed
|
paul@6 | 53 | as a system package, the userinstall-defaults file supplied with the
|
paul@12 | 54 | distribution may be edited to specify the nature and location of the personal
|
paul@22 | 55 | package manager.
|
paul@21 | 56 |
|
paul@22 | 57 | The following settings can be edited:
|
paul@21 | 58 |
|
paul@22 | 59 | USERINSTALL_ID This should reflect the distribution being used or, in
|
paul@22 | 60 | special cases, a different distribution. Examples
|
paul@22 | 61 | include Debian and Ubuntu.
|
paul@6 | 62 |
|
paul@22 | 63 | USERINSTALL_CODENAME This should reflect the version of the distribution
|
paul@22 | 64 | being used and need only be altered in special
|
paul@22 | 65 | situations (such as the creation of a sandbox for
|
paul@22 | 66 | testing other distributions).
|
paul@15 | 67 |
|
paul@22 | 68 | Examples of codenames include hardy and jaunty for
|
paul@22 | 69 | Ubuntu and lenny and squeeze for Debian. Note that the
|
paul@22 | 70 | setup process may not work with different distributions
|
paul@22 | 71 | due to library incompatibilities.
|
paul@22 | 72 |
|
paul@22 | 73 | PACKAGEROOT The location of the personal package manager in the
|
paul@22 | 74 | filesystem.
|
paul@22 | 75 |
|
paul@22 | 76 | See the /etc/lsb-release file for example values describing your own system,
|
paul@22 | 77 | with the DISTRIB prefix used instead of the USERINSTALL prefix for each of the
|
paul@22 | 78 | settings.
|
paul@6 | 79 |
|
paul@6 | 80 | If a completely new userinstall-defaults file is created, it is essential that
|
paul@6 | 81 | the above variables be defined so that the scripts know where to create or to
|
paul@12 | 82 | find the personal package manager.
|
paul@6 | 83 |
|
paul@12 | 84 | Creating a Personal Package Manager
|
paul@12 | 85 | -----------------------------------
|
paul@6 | 86 |
|
paul@6 | 87 | In order to install packages as a non-root user, first invoke the user-setup
|
paul@6 | 88 | script; this will create and initialise a basic Debian system with a basic set
|
paul@6 | 89 | of packages installed. For example, with userinstall installed as a system
|
paul@12 | 90 | package, using the system defaults:
|
paul@6 | 91 |
|
paul@6 | 92 | user-setup
|
paul@6 | 93 |
|
paul@12 | 94 | It is possible to override the "template" for the system by specifying a
|
paul@6 | 95 | "mirror" location. This is useful if you have the CD or DVD image for the
|
paul@12 | 96 | distribution already mounted in the filesystem. For example:
|
paul@6 | 97 |
|
paul@6 | 98 | user-setup file:///cdrom
|
paul@20 | 99 |
|
paul@20 | 100 | sudo mount -o loop /home/me/downloads/kubuntu-7.04-alternate-i386.iso /tmp/cdrom
|
paul@20 | 101 | user-setup file:///tmp/cdrom
|
paul@6 | 102 |
|
paul@12 | 103 | An URI must be specified as the "mirror" location, not a normal filename.
|
paul@6 | 104 |
|
paul@22 | 105 | Once the installation is complete, some post-installation is necessary:
|
paul@22 | 106 |
|
paul@22 | 107 | user-postsetup
|
paul@22 | 108 |
|
paul@22 | 109 | If a different distribution is being used for the package manager than that
|
paul@22 | 110 | being run on the system, it might be necessary to specify a country code so
|
paul@22 | 111 | that the configuration of package repositories can be performed successfully.
|
paul@22 | 112 | For example, for repositories mirrored in the United Kingdom (UK):
|
paul@22 | 113 |
|
paul@22 | 114 | user-postsetup uk
|
paul@22 | 115 |
|
paul@22 | 116 | At this point, the package manager should be ready to use.
|
paul@22 | 117 |
|
paul@12 | 118 | Adding Package Repositories to the Package Manager
|
paul@12 | 119 | --------------------------------------------------
|
paul@12 | 120 |
|
paul@12 | 121 | To get access to repositories of packages beyond those provided by the basic
|
paul@12 | 122 | distribution, edit the /etc/apt/sources.list file inside the system. The
|
paul@6 | 123 | user-path script can help you find the exact location of the file:
|
paul@6 | 124 |
|
paul@7 | 125 | user-path /etc/apt/sources.list
|
paul@6 | 126 |
|
paul@6 | 127 | And you can edit the file directly with a text editor (such as vi) as follows:
|
paul@6 | 128 |
|
paul@7 | 129 | vi `user-path /etc/apt/sources.list`
|
paul@6 | 130 |
|
paul@6 | 131 | Installing Packages
|
paul@6 | 132 | -------------------
|
paul@6 | 133 |
|
paul@25 | 134 | To install packages from other repositories, invoke the user-do script and
|
paul@25 | 135 | specify the apt-get program together with options expected by that program.
|
paul@25 | 136 | For example:
|
paul@15 | 137 |
|
paul@25 | 138 | user-do apt-get --help
|
paul@25 | 139 | user-do apt-get update
|
paul@15 | 140 |
|
paul@25 | 141 | Packages can then be installed. For example:
|
paul@15 | 142 |
|
paul@25 | 143 | user-do apt-get install python-cmdsyntax
|
paul@6 | 144 |
|
paul@6 | 145 | Provided that the specified packages are known and their dependencies can be
|
paul@12 | 146 | met, they will be installed into the system.
|
paul@6 | 147 |
|
paul@6 | 148 | Installing Single Packages
|
paul@6 | 149 | --------------------------
|
paul@6 | 150 |
|
paul@25 | 151 | To install individual package files, first copy them into the package manager
|
paul@25 | 152 | directory hierarchy. For example:
|
paul@6 | 153 |
|
paul@25 | 154 | cp python-cmdsyntax_0.91-0ubuntu2_all.deb `user-path /tmp`
|
paul@6 | 155 |
|
paul@25 | 156 | The invoke the dpkg program through the user-do script as follows:
|
paul@25 | 157 |
|
paul@25 | 158 | user-do dpkg -i /tmp/python-cmdsyntax_0.91-0ubuntu2_all.deb
|
paul@7 | 159 |
|
paul@7 | 160 | Using Packages
|
paul@7 | 161 | --------------
|
paul@7 | 162 |
|
paul@7 | 163 | Unlike most packages installed in the usual way by the root user, the installed
|
paul@7 | 164 | packages will not reside within a directory hierarchy rooted at / - the top of
|
paul@7 | 165 | the filesystem. Instead, they will reside in a location such as the following:
|
paul@7 | 166 |
|
paul@7 | 167 | /home/me/.userinstall
|
paul@7 | 168 | /tmp/packages
|
paul@7 | 169 |
|
paul@7 | 170 | (The precise location may be found by running the user-path script.)
|
paul@7 | 171 |
|
paul@7 | 172 | Consequently, to make use of the installed software, it may be necessary to
|
paul@7 | 173 | edit your environment in a number of ways so that it may be located and
|
paul@7 | 174 | correctly loaded, initialised and executed.
|
paul@7 | 175 |
|
paul@7 | 176 | Using Python Packages
|
paul@7 | 177 | ---------------------
|
paul@7 | 178 |
|
paul@7 | 179 | Installed Python packages may be made available to Python by defining the
|
paul@7 | 180 | PYTHONPATH to include the directories usually searched by Python, but which
|
paul@12 | 181 | are actually located within the personal package management environment. For
|
paul@12 | 182 | example, with the Python 2.5 site-packages directory:
|
paul@7 | 183 |
|
paul@11 | 184 | PYTHONPATH=`user-path /usr/lib/python2.5/site-packages/` python2.5
|
paul@11 | 185 |
|
paul@11 | 186 | More complicated extension modules may require further adjustments to the
|
paul@11 | 187 | LD_LIBRARY_PATH and PYTHONPATH variables:
|
paul@11 | 188 |
|
paul@25 | 189 | export LD_LIBRARY_PATH=`user-path /usr/lib`
|
paul@25 | 190 | export PYTHONPATH=`user-path /usr/lib/python2.5/site-packages/`
|
paul@25 | 191 | export PYTHONPATH=${PYTHONPATH}:`user-path /var/lib/python-support/python2.5`
|
paul@22 | 192 |
|
paul@22 | 193 | Entering the Package Manager
|
paul@22 | 194 | ----------------------------
|
paul@22 | 195 |
|
paul@22 | 196 | It is also possible to administer the package manager from within the
|
paul@22 | 197 | installation:
|
paul@22 | 198 |
|
paul@25 | 199 | user-do
|
paul@22 | 200 |
|
paul@22 | 201 | This should provide a "root" prompt which can then be used to issue commands
|
paul@22 | 202 | within the package manager environment. For example:
|
paul@22 | 203 |
|
paul@22 | 204 | apt-get update
|
paul@22 | 205 |
|
paul@22 | 206 | Constructing UML Instances
|
paul@22 | 207 | --------------------------
|
paul@22 | 208 |
|
paul@22 | 209 | For some applications, it can be desirable to provide a completely isolated
|
paul@22 | 210 | environment for package installation and testing. This can be performed using
|
paul@22 | 211 | the User Mode Linux (UML) software.
|
paul@22 | 212 |
|
paul@22 | 213 | To convert a package manager installation into a UML instance, start with the
|
paul@25 | 214 | user-to-uml script which changes the installation's configuration in a number
|
paul@25 | 215 | of areas:
|
paul@22 | 216 |
|
paul@25 | 217 | user-to-uml
|
paul@22 | 218 |
|
paul@25 | 219 | Then, as a privileged user, run the uml-setupdev script to initialise some
|
paul@22 | 220 | UML-specific device files:
|
paul@22 | 221 |
|
paul@22 | 222 | sudo uml-setupdev
|
paul@22 | 223 |
|
paul@22 | 224 | Since UML needs to see its filesystems as images, not directories within an
|
paul@22 | 225 | existing filesystem, the uml-setupfs script needs to create these image files.
|
paul@22 | 226 | For example, to create a root filesystem 1GB in size, along with a swap file
|
paul@22 | 227 | 512MB in size:
|
paul@22 | 228 |
|
paul@22 | 229 | uml-setupfs 4 512
|
paul@22 | 230 |
|
paul@22 | 231 | Again, as a privileged user, these images are then populated with the package
|
paul@22 | 232 | manager contents as follows:
|
paul@22 | 233 |
|
paul@26 | 234 | sudo uml-postsetupfs
|
paul@22 | 235 |
|
paul@22 | 236 | NOTE: Add Linux build process.
|
paul@22 | 237 |
|
paul@27 | 238 | Enabling Networking for UML Instances
|
paul@27 | 239 | -------------------------------------
|
paul@27 | 240 |
|
paul@27 | 241 | To enable networking for a UML instance, use the uml-net script:
|
paul@27 | 242 |
|
paul@27 | 243 | sudo uml-net --start $USER
|
paul@27 | 244 |
|
paul@27 | 245 | Here, $USER should be expanded to the name of the user running the above
|
paul@27 | 246 | command, not the root user.
|
paul@27 | 247 |
|
paul@27 | 248 | To stop networking, use the same script:
|
paul@27 | 249 |
|
paul@27 | 250 | sudo uml-net --stop
|
paul@27 | 251 |
|
paul@22 | 252 | Entering or Starting UML Instances
|
paul@22 | 253 | ----------------------------------
|
paul@22 | 254 |
|
paul@25 | 255 | To enter a UML instance, use the uml-do script:
|
paul@22 | 256 |
|
paul@25 | 257 | uml-do
|