Once your worstation is installed, it is time for you to configure it. At this point you create a user for everyday's work, configure third party repositories, fix environment variables to fit your personal needs, download the working copy of &TCAR; and prepare it for start using it. Once you've installed the workstation and it is up and running, you need to create the user name you'll use for your everyday's work. 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 your everyday's work inside your working copy of &TCAR;. This is dangerous and might provoke unreversable damages on your workstation. When user names are created inside the workstation, it doesn't create only a user identifier for you to login, but a place for you to store your information, as well. This place is known as your home directory and is unique for each user inside the workstation. At the moment, we face the following design problems related to handling absolute paths inside the working copies of &TCAR;: Case 1: Different home directories Assuming you store your working copy under /home/john/artwork/ and I store mine under /home/al/artwork/, we'll end up refering the same files inside our working copies through different absolute paths. This generates a contradiction when files, holding path information inside, are committed up to the central repository. The contradiction comes from the question: which is the correct absolute path to use inside such files, yours or mine? — No one of them is, of course. Case 2: One unique home directory Another case would be that you and I ourselves use one unique home directory (e.g., /home/centos/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 configuration might be not so good for situations where you and I have to share the same workstation. In such case, 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. Case 3: Different home directories through dynamic expansion Most of the absolute paths we use inside the working copy are made of two parts, one dynamic and one 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 organization matter. What we need here is to find a way to expand variables inside files that don't support variable expansion. So far we've been doing this through creation template instances which are temporal files with translation markers expanded inside. This work rather fine with template files that are one-time-pass (e.g., 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). From the three cases discussed above, the second one (i.e., One unique home directory) seems to be the best candidate. It limits us from using more than one working copy in the same workstation, but gives us the chance of standardizing the use of absolute paths inside all the working copies of &TCAR;. Using absolute paths is very convenient because it is possible to reuse information from different locations inside the working copy, something that would be almost imposible to maintain if relative paths were used instead. Thus, lets assume the second case of handling home directories as default solution to relatively solve the problem of where to store working copies of &TCAR; until a better one shows itself up. The action of providing working copies of &TCAR; that permit to reuse files inside them unifies the way content is produced inside the working copy and provides a convenction for people working on different areas to get attached to in order to syncronize their works and still keep doing it decentralized one another. Once you've created the centos user name for your everyday's work and you had done login with it, there are some environment variables that you can customize to fit your personal needs (e.g., default text editor, default locale information, default time zone representation, etc.). To customize these variables you need to edit your personal profile (i.e., ~/.bash_profile) and set the redefinition there. Notice that you may need to logout and then do login again in order for the new variable values to take effect. Default text editor The default text editor information is controlled by the EDITOR environment variable. The centos-art.sh script uses the default text editor to edit subversion pre-commit messages, translation files, documentation files, script files, and similar text-based files. If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: /usr/bin/vim /usr/bin/emacs /usr/bin/nano If no one of these values is set in the EDITOR environment variable, the centos-art.sh script uses /usr/bin/vim text editor, the one installed by default in &TCD;. Default locale information The default locale information is controlled by the LANG environment variable. This variable is initially set in the installation process of &TCD;, specifically in the Language step. Generally, there is no need to customize this variable in your personal profile. If you need to change the value of this environment variable do it through the login screen of GNOME Desktop Environment or the system-config-language command. The centos-art.sh script uses the LANG environment variable to determine what language to use for printing output messages from the script itself, as well as the portable objects locations that need to be updated or edited when you localize directory structures inside the working copy of &TCAR;. Default time zone representation The time zone representation is a time correction applied to the system time (stored in the BIOS clock) based on your country location. This correction is specially useful to distributed computers around the world that work together and need to be syncronized in time to know when things happened. &TCAR; is made of one server and several workstations spread around the world. In order for all these workstations to know when changes in the server took place, it is required that they all set their system clocks to use the same time information (e.g., through UTC (Coordinated Universal Time)) and set the time correction for their specific countries in the operating system. Otherwise, it would be difficult to know when something exactly happened. Generally, setting the time information is a straight-forward task and configuration tools provided by &TCD; do cover time correction for most of the countries around the world. However, if you need a time precision not provided by any of the date and time configuration tools provided by &TCD; then, you need to customize the TZ environment variable in your personal profile to correct the time information by yourself. The format of TZ environment variable is described in tzset(3) manual page. Sometimes it is necessary that you perform administrative tasks inside the workstation the working copy of &TCAR; is stored in. These tasks might demand you to type many commands (e.g., for configuring a third party repository) or just a one-line command (e.g., for installing a new package). In both cases this kind of tasks require permissions that your user for everyday's work must not have under no mean. To perform administrative tasks in your workstation, you need to login as root or configure the sudo program to temporarily granting the permissions your regular user needs to perform the administrative tasks. The configuration of sudo program is at /etc/sudoers file and you need to add the centos user to the list of privileged user as described in the section below: ## 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 centos ALL=(ALL) ALL This configuration is required in order for automation scripts to realize administrative tasks that otherwise you would need to type one by one. It is worth to mention that all these tasks are organized in the prepare functionality of the centos-art.sh script in the sake of reducing work and standardize the procedure of performing them. It is also worth to mention that, the centos-art.sh script is available for you to run, study, improve and share your changes as described in . Once you've installed and configured the workstation, it is ready to receive the working copy of &TCAR;. In this step, you use Subversion's client to communicate the source repository of &TCAR; and download all the files that make a working copy of it. To download the working copy of &TCAR; you need to login as your everyday's work user (i.e., the centos user) and use the Subversion client installed in your workstation to bring all the files you need to work with from the source repository down to your workstation, just as the following command describes: svn co https://projects.centos.org/svn/artwork ~/ This command will create your working copy of &TCAR; in your workstation, specifically in the /home/centos/artwork directory. If the Subversion's client wasn't installed by default, you need to install it using the following command: sudo yum install subversion Once your working copy of &TCAR; has been downloaded, you should notice that there is 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;. Another consideration to be aware of at this point, is the need of verifying the software installed in the workstation, as well as the creation of symbolic links to connect the content produced inside the working copy to applications outside it (e.g., to make available patterns, brushes, and palettes produced inside the working copy in GIMP, the application used to manipulate images). This final preparation stuff is automated by the prepare functionality of the centos-art.sh script, as described in . Execute it right now, to be sure your workstation and your working copy are both ready to be used.