| <sect1 id="repo-ws-config"> |
| |
| <title>Configuring Your Workstation</title> |
| |
| <para> |
| 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. |
| </para> |
| |
| <sect2 id="repo-ws-config-wp"> |
| <title>Workplace</title> |
| <para> |
| 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 |
| <command>useradd</command> and <command>passwd</command> 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 <emphasis>root</emphasis> |
| superuser for doing so. |
| </para> |
| |
| <caution> |
| <para> |
| Do not use the <emphasis>root</emphasis> username for your |
| everyday's work inside your working copy of &TCAR;. This is |
| dangerous and might provoke unreversable damages to your |
| workstation. |
| </para> |
| </caution> |
| |
| <para> |
| 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 this point, it is necessary to |
| decide where the working copy tree will be stored in the |
| workstation filesystem. |
| </para> |
| |
| <para> |
| <emphasis>Case 1: Different Home Directories</emphasis> |
| — Assuming you store your working copy under <filename |
| class="directory">/home/john/artwork/</filename> and I store |
| mine under <filename |
| class="directory">/home/al/artwork/</filename>, 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? (None of them is, of course.) |
| </para> |
| |
| <para> |
| <emphasis>Case 2: One Unique Home Directory</emphasis> — |
| Another case would be that where you and I ourselves use one |
| unique home directory (e.g., <filename |
| class="directory">/home/centos/artwork/</filename>) 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 |
| <emphasis>centos</emphasis> 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. |
| </para> |
| |
| <para> |
| <emphasis>Case 3: Different Home Directories Through Dynamic |
| Expansion</emphasis> — 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 |
| <envar>$HOME</envar> 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). |
| </para> |
| |
| <para> |
| 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. |
| </para> |
| |
| <para> |
| 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. |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="repo-ws-config-envar"> |
| <title>Environment Variables</title> |
| |
| <para> |
| Once you've created the <emphasis>centos</emphasis> 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., <filename |
| class="directory">~/.bash_profile</filename>) 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. |
| </para> |
| |
| <variablelist> |
| <varlistentry> |
| <term>Default text editor</term> |
| <listitem> |
| <para> |
| The default text editor information is controlled by the |
| <envar>EDITOR</envar> environment variable. The |
| <command>centos-art.sh</command> script uses the default text |
| editor to edit subversion pre-commit messages, translation |
| files, documentation files, script files, and similar |
| text-based files. |
| </para> |
| |
| <para> |
| If <envar>EDITOR</envar> environment variable is not set, |
| <command>centos-art.sh</command> script uses <filename |
| class="directory">/usr/bin/vim</filename> as default text |
| editor. Otherwise, the following values are recognized by |
| <command>centos-art.sh</command> script: |
| |
| <itemizedlist> |
| <listitem> |
| <para> |
| <filename class="directory">/usr/bin/vim</filename> |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| <filename class="directory">/usr/bin/emacs</filename> |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| <filename class="directory">/usr/bin/nano</filename> |
| </para> |
| </listitem> |
| </itemizedlist> |
| |
| </para> |
| |
| <para> |
| If no one of these values is set in the <envar>EDITOR</envar> |
| environment variable, the <command>centos-art.sh</command> |
| script uses <filename |
| class="directory">/usr/bin/vim</filename> text editor, the one |
| installed by default in &TCD;. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term>Default locale information</term> |
| <listitem> |
| <para> |
| The default locale information is controlled by the |
| <envar>LANG</envar> environment variable. This variable is |
| initially set in the installation process of &TCD;, |
| specifically in the <emphasis>Language</emphasis> 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 |
| <command>system-config-language</command> command. |
| </para> |
| |
| <para> |
| The <command>centos-art.sh</command> script uses the |
| <envar>LANG</envar> 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;. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term>Default time zone representation</term> |
| <listitem> |
| <para> |
| 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. |
| </para> |
| <para> |
| &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. |
| </para> |
| <para> |
| 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 <envar>TZ</envar> environment |
| variable in your personal profile to correct the time |
| information by yourself. The format of <envar>TZ</envar> |
| environment variable is described in <code>tzset(3)</code> |
| manual page. |
| </para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| </sect2> |
| |
| <sect2 id="repo-ws-config-sudo"> |
| <title>Administrative Tasks</title> |
| |
| <para> |
| 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. |
| </para> |
| |
| <para> |
| To perform administrative tasks in your workstation, you need |
| to login as <emphasis>root</emphasis> or configure the |
| <command>sudo</command> program to temporarily granting the |
| permissions your regular user needs to perform the |
| administrative tasks. The configuration of |
| <command>sudo</command> program is at |
| <filename>/etc/sudoers</filename> file and you need to add the |
| <emphasis>centos</emphasis> user to the list of privileged |
| user as described in the section below: |
| </para> |
| |
| <screen> |
| ## 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 |
| </screen> |
| |
| <para> |
| 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 <function>prepare</function> |
| functionality of the <command>centos-art.sh</command> script |
| in the sake of reducing work and standardize the procedure of |
| performing them. It is also worth to mention that, the |
| <command>centos-art.sh</command> script is available for you |
| to run, study, improve and share your changes as described in |
| <xref linkend="licenses-gpl" />. |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="repo-ws-config-wc"> |
| <title>Working Copy</title> |
| |
| <para> |
| 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. |
| </para> |
| |
| <para> |
| To download the working copy of &TCAR; you need to login as |
| your everyday's work user (i.e., the |
| <emphasis>centos</emphasis> 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: |
| </para> |
| |
| <screen>svn co https://projects.centos.org/svn/artwork ~/</screen> |
| |
| <para> |
| This command will create your working copy of &TCAR; in your |
| workstation, specifically in the <filename |
| class="directory">/home/centos/artwork</filename> directory. |
| </para> |
| |
| <note> |
| <para> |
| If the Subversion's client wasn't installed by default, you |
| need to install it using the following command: |
| </para> |
| <screen>sudo yum install subversion</screen> |
| </note> |
| |
| |
| <para> |
| 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;. |
| </para> |
| |
| <para> |
| 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). |
| </para> |
| |
| <para> |
| This final preparation stuff is automated by the |
| <function>prepare</function> functionality of the |
| <command>centos-art.sh</command> script, as described in <xref |
| linkend="scripts-bash-prepare" />. Execute it right now, |
| to be sure your workstation and your working copy are both |
| ready to be used. |
| </para> |
| |
| </sect2> |
| |
| </sect1> |