Once your workstation has been installed, it is time for you to configure it. The configuration of your workstation consists on defining your workplace, download a working copy from &TCAR; and finally, run the prepare functionality of centos-art.sh script to install/update the software needed, render images, create links, and anything else needed. Once you've installed the workstation and it is up and running, you need to register the user name you'll use for working. In this task you need to use the commands useradd and passwd to create the user name and set a password for it, respectively. These commands require administrative privileges to be executed, so you need to login as root superuser for doing so. Do not use the root username for regular tasks inside your working copy of &TCAR;. This is dangerous and might provoke unreversable damages to your workstation. When you've registered your user name in the workstation, it provides an identifier for you to open a user's session in the workstation and a place to store the information you produce, as well. This place is known as your home directory and is unique for each user registered in the workstation. For example, if you register the user name john in your workstation, your home directory would be located at /home/john/. At this point it is important to define where to download the working copy of &TCAR; inside your home directory. This desition deserves special attention and should be implemented carefully in order to grant a standard environment that could be distributed. Let's see some alternatives. Consider that you store your working copy under /home/john/Projects/artwork/ and I store mine under /home/al/Projects/artwork/, we'll end up refering the same files inside our working copies through different absolute paths. This alternative generates a contradiction when files which hold path information inside are committed up to the central repository from different working copies. The contradiction comes from the question: which is the correct absolute path to use inside such files, yours or mine? (None of them is, of course.) Another case would be that where you and I ourselves use one unique home directory (e.g., /home/centos/Projects/artwork/) to store the working copy of &TCAR; in our own workstations, but configure the subversion client to use different user names to commit changes up from the working copy to the central repository. This alternative might be not so good in situations where you and I have to share the same workstation. In such cases, it would be required that we both share the password information of the same system user (the centos user in our example) which, in addition, gives access to that user's subversion client configuration and this way provokes the whole sense of using different subversion credentials for committing changes to be lost. Most of the absolute paths we use inside the working copy are made of two parts, one dynamic and one relative fixed. The dynamic part is the home directory of the current user and its value can be retrived from the $HOME environment variable. The fixed part of the path is the one we set inside the repositroy structure itself as a matter of organization. What we need here is to find a way to expand variables inside files that don't support variable expansion. This alternative had worked rather fine when we produce produce PNG files from SVG files and XTHML from DocBook files, but the same is not true for absolute paths inside files that are used as in their permanent state inside the repository (e.g., CSS files and other files similar in purpose). As convenction, to use the &TCAR;, you must register the user name centos in your workstation, do login with it, and download the working copy from the central repository using the following command: svn co https://projects.centos.org/svn/artwork /home/centos/Projects/artwork The first time you download the working copy it contains no image files, nor documentation, or localized content inside it. This is because all the files provided in the working copy are source files (e.g., the files needed to produce other files) and it is up to you the action of render them to produce the final files (e.g., images and documentation) used to implement &TCPCVI;. Most of the administrative tasks you need to perform in your working copy of &TCAR; are standardized inside the prepare functionality of centos-art.sh script. Inside centos-art.sh script, all administrative task are invoked trough the sudo command. Thus, in order for the centos-art.sh script to perform administrative tasks, you need to update the sudo's configuration in a way that such administrative actions be allowed. At time of this writing the centos-art.sh script implements just one administrative task, that is package management. Nevertheless, in the future, other administrative tasks might be included as well. To update the sudo's configuration, execute the visudo command as root. Later, uncoment the Cmnd_Alias related to SOFTWARE and add a line for centos username allowing software commands. This configuration is illustrated in . /etc/sudoers configuration file ## Installation and management of software Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum ## Next comes the main part: which users can run what software on ## which machines (the sudoers file can be shared between multiple ## systems). ## Syntax: ## ## user MACHINE=COMMANDS ## ## The COMMANDS section may have other options added to it. ## ## Allow root to run any commands anywhere root ALL=(ALL) ALL ## Allow the centos user to run installation and management of ## software anywhere. centos ALL=(ALL) SOFTWARE Once you've created the centos username, logged in with it, downloaded a working copy from &TCAR; and configured the sudo's configuration file, run the prepare functionality of centos-art.sh script to complete the configuration process using the following command: /home/centos/Projects/artwork/trunk/Scripts/Bash/centos-art.sh prepare To know more about the prepare functionality of centos-art.sh script, see .