diff --git a/Documentation/Distro/apache-test-page.docbook b/Documentation/Distro/apache-test-page.docbook deleted file mode 100644 index 64680f4..0000000 --- a/Documentation/Distro/apache-test-page.docbook +++ /dev/null @@ -1,113 +0,0 @@ - - - -
- - Apache HTTP Server Test Page - - - This page is used to test the proper operation of the - Apache HTTP server after it has been installed. If you can - read this page it means that the Apache HTTP server - installed at this site is working properly. - - - - - - If you are a member of the general public - - The fact that you are seeing this page indicates that the - website you just visited is either experiencing problems or is - undergoing routine maintenance. - - - If you would like to let the administrators of this website - know that you've seen this page instead of the page you - expected, you should send them e-mail. In general, mail sent - to the name webmaster and directed to the - website's domain should reach the appropriate person. - - - For example, if you experienced problems while visiting - www.example.com, you should send e-mail to - webmaster@example.com. - - - - - If you are the website administrator - - You may now add content to the directory /var/www/html/. Note that until - you do so, people visiting your website will see this page and - not your content. To prevent this page from ever being used, - follow the instructions in the file - /etc/httpd/conf.d/welcome.conf. - - - You are free to use the images below on Apache and CentOS - Linux powered HTTP servers. Thanks for using Apache and - CentOS! - - - - - - - - - - - - - - - - - - - - - - About CentOS - - The Community ENTerprise Operating System (CentOS) is an - Enterprise-class Linux Distribution derived from sources - freely provided to the public by a prominent North American - Enterprise Linux vendor. CentOS conforms fully with the - upstream vendors redistribution policy and aims to be 100% - binary compatible. (CentOS mainly changes packages to remove - upstream vendor branding and artwork.) The CentOS Project is - the organization that builds CentOS. - - - For information on CentOS please visit the CentOS website. - - - - - CentOS is an Operating System and it is used to power this - website; however, the webserver is owned by the domain owner - and not the CentOS Project. If you have issues with the - content of this site, contact the owner of the domain, not the - CentOS project. - - - Unless this server is on the CentOS.org domain, the CentOS - Project doesn't have anything to do with the content on this - webserver or any e-mails that directed you to this site. - - - For example, if this website is www.example.com, you would - find the owner of the example.com domain at the following - WHOIS server: . - - - - -
- diff --git a/Documentation/Distro/eula.docbook b/Documentation/Distro/eula.docbook deleted file mode 100644 index 099cb46..0000000 --- a/Documentation/Distro/eula.docbook +++ /dev/null @@ -1,35 +0,0 @@ - - - -
- - CentOS =RELEASE= EULA - - - - - - - - - - - =COPYRIGHT_YEAR_LAST= - The CentOS Project - - - - CentOS =RELEASE= comes with no guarantees or - warranties of any sorts, either written or implied. - The Distribution is released as GPL - work. Individual packages in the distribution come - with their own licences. - - - - - -
diff --git a/Documentation/Distro/firefox-service-agreement.docbook b/Documentation/Distro/firefox-service-agreement.docbook deleted file mode 100644 index 8721c13..0000000 --- a/Documentation/Distro/firefox-service-agreement.docbook +++ /dev/null @@ -1,252 +0,0 @@ - - - -
- - Mozilla Firefox - Website Services Agreement - - - The accompanying version of Mozilla Firefox utilizes - website information services (Services), - such as safe-browsing features, which are provided by the - Mozilla Corporation and made available to you under - additional terms. By using the Services, you consent to - the terms of the referenced Mozilla Firefox Website - Services Agreement. - - - - - - If you do not agree to these terms, do not use the Services - and disable the Services in Edit > - Preferences > - Security and uncheck the options - for both: Tell me if the site I'm visiting is a - suspected attack site and Tell me if the site - I'm visiting is a suspected forgery. - - - - - Version 3.0, June 2008 - - - During the Mozilla Firefox installation process, and at later - times, you may be given the option of installing additional - components from third-party software providers. The - installation and use of those third-party components may be - governed by additional license agreements. - - - - In this Mozilla Firefox Website Services Agreement - (Agreement), the accompanying executable - version of Mozilla Firefox shall be referred to as the - Product. - - - - The Product utilizes website information services - (Services), such as safe-browsing features, - which are provided by the Mozilla Corporation - (Mozilla) and made available to you subject to - the terms below. By using the Services, you consent to the - terms of this Agreement. If you do not agree to the terms of - this Agreement, do not use the Services and disable the - Services in the preferences/security menu. - - - - Use Of Service - - - Mozilla permits you to use the Services via the Product. This - Agreement will also govern the use of Services made available - to you as a result of your installing any executable software - upgrades to the Product provided to you by CentOS, where those - Services replace and/or supplement the Services provided - through use of the Product. In such a case, the - Product shall also refer to such installed upgrades. - However, if such upgrades are accompanied by a separate - agreement from Mozilla, the terms of that agreement will - govern. - - - - - - Termination - - If you breach this Agreement your right to use the Services - will terminate immediately and without notice, but all - provisions of this Agreement except the Use of Services - (Paragraph 1) will survive termination and continue in effect. - - - - - Proprietary Rights - - Subject to this Agreement and to all applicable licensing - terms governing your use of the Product, Mozilla, for itself - and on behalf of its licensors, hereby reserves all - intellectual property rights in the Services, except for the - rights expressly granted in this Agreement. You may not - remove or alter any trademark, logo, copyright or other - proprietary notice in or on the Product. This agreement does - not grant you any right to use the trademarks, service marks - or logos of Mozilla or its licensors. Nothing in this - Agreement shall be construed to limit any rights granted under - open source licenses applicable to the Product and to - corresponding source code versions of the Product. - - - - - Privacy Policy - - The Mozilla Firefox Privacy Policy is made available online at - , as that - policy may be updated from time to time. - - - - - Website Information Services - - Mozilla and its contributors, licensors and partners work to - provide the most accurate and up-to-date phishing and malware - information. However, they cannot guarantee that this - information is comprehensive and error-free: some risky sites - may not be identified, and some safe sites may be identified - in error. - - - - - Disclaimer Of Warranty - - The product and services are provided as is - with all faults. to the extent permitted by law, mozilla and - mozilla's distributors, and licensors hereby disclaim all - warranties, whether express or implied, including without - limitation warranties that the product and services are free - of defects, merchantable, fit for a particular purpose and - non-infringing. you bear the entire risk as to selecting the - product and services for your purposes and as to the quality - and performance of the product and services. this limitation - will apply notwithstanding the failure of essential purpose of - any remedy. some jurisdictions do not allow the exclusion or - limitation of implied warranties, so this disclaimer may not - apply to you. - - - - - Limitation Of Liability - - Except as required by law, mozilla and its distributors, - directors, licensors, contributors and agents (collectively, - the mozilla group) will not be liable for any - indirect, special, incidental, consequential or exemplary - damages arising out of or in any way relating to this - agreement or the use of or inability to use the product and - the services, including without limitation damages for loss of - goodwill, work stoppage, lost profits, loss of data, and - computer failure or malfunction, even if advised of the - possibility of such damages and regardless of the theory - (contract, tort or otherwise) upon which such claim is based. - the mozilla group's collective liability under this agreement - will not exceed the greater of $500 (five hundred dollars) and - the fees paid by you under the license (if any). Some - jurisdictions do not allow the exclusion or limitation of - incidental, consequential or special damages, so this - exclusion and limitation may not apply to you. - - - - - U.S. Goverment End-Users - - This Product is a commercial item, as that term - is defined in 48 C.F.R. 2.101, consisting of commercial - computer software and commercial computer - software documentation, as such terms are used in 48 - C.F.R. 12.212 (Sept. 1995) and 48 C.F.R. 227.7202 (June - 1995). Consistent with 48 C.F.R. 12.212, 48 C.F.R. - 27.405(b)(2) (June 1998) and 48 C.F.R. 227.7202, all U.S. - Government End Users acquire the Product with only those - rights as set forth therein. - - - - - Miscellaneous - - - - - This Agreement constitutes the entire agreement between - Mozilla and you concerning the subject matter hereof, and it - may only be modified by a written amendment signed by an - authorized executive of Mozilla. - - - - - Except to the extent applicable law, if any, provides - otherwise, this Agreement will be governed by the laws of the - state of California, U.S.A., excluding its conflict of law - provisions. - - - - - This Agreement will not be governed by the United Nations - Convention on Contracts for the International Sale of Goods. - - - - - If any part of this Agreement is held invalid or - unenforceable, that part will be construed to reflect the - parties' original intent, and the remaining portions will - remain in full force and effect - - - - - A waiver by either party of any term or condition of this - Agreement or any breach thereof, in any one instance, will not - waive such term or condition or any subsequent breach thereof. - - - - - Except as required by law, the controlling language of this - Agreement is English. - - - - - You may assign your rights under this Agreement to any party - that consents to, and agrees to be bound by, its terms; the - Mozilla Corporation may assign its rights under this Agreement - without condition. - - - - - This Agreement will be binding upon and inure to the benefit - of the parties, their successors and permitted assigns. - - - - - - - -
diff --git a/Documentation/Distro/release-notes.docbook b/Documentation/Distro/release-notes.docbook deleted file mode 100644 index 7896e26..0000000 --- a/Documentation/Distro/release-notes.docbook +++ /dev/null @@ -1,67 +0,0 @@ - - - -
- - CentOS =RELEASE= Release Notes - - - - - - - - - - - =COPYRIGHT_YEAR_LAST= - The CentOS Project - - - - The CentOS =RELEASE= Release Notes are licensed under - a Creative - Common Attribution-ShareAlike 3.0 License. - - - - - - The CentOS Project welcomes you to CentOS =RELEASE=. - - - - The complete release notes for CentOS =RELEASE= can be found - online at: . - - - - A list of frequently asked questions and answers about CentOS - =RELEASE= can be found online at: - . - - - - If you are looking for help with CentOS, we recommend you - start at the for pointers to the different sources where you can get - help. - - - - If you would like to contribute to The CentOS Project, see - for areas where you - could help. - - - - For more information about The CentOS Project in general - please visit our homepage at: . - - -
diff --git a/Documentation/Distro/welcome.docbook b/Documentation/Distro/welcome.docbook deleted file mode 100644 index 9c8ee15..0000000 --- a/Documentation/Distro/welcome.docbook +++ /dev/null @@ -1,108 +0,0 @@ - - - -
- - Welcome to CentOS =RELEASE= - - - - - - - - - - - =COPYRIGHT_YEAR_LAST= - The CentOS Project - - - - CentOS =RELEASE= comes with no guarantees or warranties of - any sorts, either written or implied. The Distribution is - released as GPL - work. Individual packages in the distribution come with - their own licences. - - - - - - What is CentOS? - - CentOS is an Enterprise-class Linux - Distribution derived from sources freely provided to the - public by a prominent North American Enterprise Linux vendor. - CentOS conforms fully with the upstream vendors redistribution - policy and aims to be 100% binary compatible. (CentOS mainly - changes packages to remove upstream vendor branding and - artwork.) - - - CentOS is developed by a small but growing team of core - developers. In turn the core developers are supported by an - active user community including system administrators, network - administrators, enterprise users, managers, core Linux - contributors and Linux enthusiasts from around the world. - - - - - Advantages - - CentOS has numerous advantages including: an active and - growing user community, quickly rebuilt, tested, and QA'ed - errata packages, an extensive mirror - network, developers who are contactable and responsive - reliable Enterprise Linux class distribution, multiple free - support avenues. - - - - - Support - - The following free support avenues are available: - - - - - - The CentOS Website - - - - - The CentOS Wiki - (includes a dynamic FAQ) - - - - - The - CentOS IRC Chat - - - - - The CentOS Mailing - List - - - - - The CentOS Forums - - - - - - -
diff --git a/Documentation/Manuals/Distro/apache-test-page.docbook b/Documentation/Manuals/Distro/apache-test-page.docbook new file mode 100644 index 0000000..64680f4 --- /dev/null +++ b/Documentation/Manuals/Distro/apache-test-page.docbook @@ -0,0 +1,113 @@ + + + +
+ + Apache HTTP Server Test Page + + + This page is used to test the proper operation of the + Apache HTTP server after it has been installed. If you can + read this page it means that the Apache HTTP server + installed at this site is working properly. + + + + + + If you are a member of the general public + + The fact that you are seeing this page indicates that the + website you just visited is either experiencing problems or is + undergoing routine maintenance. + + + If you would like to let the administrators of this website + know that you've seen this page instead of the page you + expected, you should send them e-mail. In general, mail sent + to the name webmaster and directed to the + website's domain should reach the appropriate person. + + + For example, if you experienced problems while visiting + www.example.com, you should send e-mail to + webmaster@example.com. + + + + + If you are the website administrator + + You may now add content to the directory /var/www/html/. Note that until + you do so, people visiting your website will see this page and + not your content. To prevent this page from ever being used, + follow the instructions in the file + /etc/httpd/conf.d/welcome.conf. + + + You are free to use the images below on Apache and CentOS + Linux powered HTTP servers. Thanks for using Apache and + CentOS! + + + + + + + + + + + + + + + + + + + + + + About CentOS + + The Community ENTerprise Operating System (CentOS) is an + Enterprise-class Linux Distribution derived from sources + freely provided to the public by a prominent North American + Enterprise Linux vendor. CentOS conforms fully with the + upstream vendors redistribution policy and aims to be 100% + binary compatible. (CentOS mainly changes packages to remove + upstream vendor branding and artwork.) The CentOS Project is + the organization that builds CentOS. + + + For information on CentOS please visit the CentOS website. + + + + + CentOS is an Operating System and it is used to power this + website; however, the webserver is owned by the domain owner + and not the CentOS Project. If you have issues with the + content of this site, contact the owner of the domain, not the + CentOS project. + + + Unless this server is on the CentOS.org domain, the CentOS + Project doesn't have anything to do with the content on this + webserver or any e-mails that directed you to this site. + + + For example, if this website is www.example.com, you would + find the owner of the example.com domain at the following + WHOIS server: . + + + + +
+ diff --git a/Documentation/Manuals/Distro/eula.docbook b/Documentation/Manuals/Distro/eula.docbook new file mode 100644 index 0000000..099cb46 --- /dev/null +++ b/Documentation/Manuals/Distro/eula.docbook @@ -0,0 +1,35 @@ + + + +
+ + CentOS =RELEASE= EULA + + + + + + + + + + + =COPYRIGHT_YEAR_LAST= + The CentOS Project + + + + CentOS =RELEASE= comes with no guarantees or + warranties of any sorts, either written or implied. + The Distribution is released as GPL + work. Individual packages in the distribution come + with their own licences. + + + + + +
diff --git a/Documentation/Manuals/Distro/firefox-service-agreement.docbook b/Documentation/Manuals/Distro/firefox-service-agreement.docbook new file mode 100644 index 0000000..8721c13 --- /dev/null +++ b/Documentation/Manuals/Distro/firefox-service-agreement.docbook @@ -0,0 +1,252 @@ + + + +
+ + Mozilla Firefox + Website Services Agreement + + + The accompanying version of Mozilla Firefox utilizes + website information services (Services), + such as safe-browsing features, which are provided by the + Mozilla Corporation and made available to you under + additional terms. By using the Services, you consent to + the terms of the referenced Mozilla Firefox Website + Services Agreement. + + + + + + If you do not agree to these terms, do not use the Services + and disable the Services in Edit > + Preferences > + Security and uncheck the options + for both: Tell me if the site I'm visiting is a + suspected attack site and Tell me if the site + I'm visiting is a suspected forgery. + + + + + Version 3.0, June 2008 + + + During the Mozilla Firefox installation process, and at later + times, you may be given the option of installing additional + components from third-party software providers. The + installation and use of those third-party components may be + governed by additional license agreements. + + + + In this Mozilla Firefox Website Services Agreement + (Agreement), the accompanying executable + version of Mozilla Firefox shall be referred to as the + Product. + + + + The Product utilizes website information services + (Services), such as safe-browsing features, + which are provided by the Mozilla Corporation + (Mozilla) and made available to you subject to + the terms below. By using the Services, you consent to the + terms of this Agreement. If you do not agree to the terms of + this Agreement, do not use the Services and disable the + Services in the preferences/security menu. + + + + Use Of Service + + + Mozilla permits you to use the Services via the Product. This + Agreement will also govern the use of Services made available + to you as a result of your installing any executable software + upgrades to the Product provided to you by CentOS, where those + Services replace and/or supplement the Services provided + through use of the Product. In such a case, the + Product shall also refer to such installed upgrades. + However, if such upgrades are accompanied by a separate + agreement from Mozilla, the terms of that agreement will + govern. + + + + + + Termination + + If you breach this Agreement your right to use the Services + will terminate immediately and without notice, but all + provisions of this Agreement except the Use of Services + (Paragraph 1) will survive termination and continue in effect. + + + + + Proprietary Rights + + Subject to this Agreement and to all applicable licensing + terms governing your use of the Product, Mozilla, for itself + and on behalf of its licensors, hereby reserves all + intellectual property rights in the Services, except for the + rights expressly granted in this Agreement. You may not + remove or alter any trademark, logo, copyright or other + proprietary notice in or on the Product. This agreement does + not grant you any right to use the trademarks, service marks + or logos of Mozilla or its licensors. Nothing in this + Agreement shall be construed to limit any rights granted under + open source licenses applicable to the Product and to + corresponding source code versions of the Product. + + + + + Privacy Policy + + The Mozilla Firefox Privacy Policy is made available online at + , as that + policy may be updated from time to time. + + + + + Website Information Services + + Mozilla and its contributors, licensors and partners work to + provide the most accurate and up-to-date phishing and malware + information. However, they cannot guarantee that this + information is comprehensive and error-free: some risky sites + may not be identified, and some safe sites may be identified + in error. + + + + + Disclaimer Of Warranty + + The product and services are provided as is + with all faults. to the extent permitted by law, mozilla and + mozilla's distributors, and licensors hereby disclaim all + warranties, whether express or implied, including without + limitation warranties that the product and services are free + of defects, merchantable, fit for a particular purpose and + non-infringing. you bear the entire risk as to selecting the + product and services for your purposes and as to the quality + and performance of the product and services. this limitation + will apply notwithstanding the failure of essential purpose of + any remedy. some jurisdictions do not allow the exclusion or + limitation of implied warranties, so this disclaimer may not + apply to you. + + + + + Limitation Of Liability + + Except as required by law, mozilla and its distributors, + directors, licensors, contributors and agents (collectively, + the mozilla group) will not be liable for any + indirect, special, incidental, consequential or exemplary + damages arising out of or in any way relating to this + agreement or the use of or inability to use the product and + the services, including without limitation damages for loss of + goodwill, work stoppage, lost profits, loss of data, and + computer failure or malfunction, even if advised of the + possibility of such damages and regardless of the theory + (contract, tort or otherwise) upon which such claim is based. + the mozilla group's collective liability under this agreement + will not exceed the greater of $500 (five hundred dollars) and + the fees paid by you under the license (if any). Some + jurisdictions do not allow the exclusion or limitation of + incidental, consequential or special damages, so this + exclusion and limitation may not apply to you. + + + + + U.S. Goverment End-Users + + This Product is a commercial item, as that term + is defined in 48 C.F.R. 2.101, consisting of commercial + computer software and commercial computer + software documentation, as such terms are used in 48 + C.F.R. 12.212 (Sept. 1995) and 48 C.F.R. 227.7202 (June + 1995). Consistent with 48 C.F.R. 12.212, 48 C.F.R. + 27.405(b)(2) (June 1998) and 48 C.F.R. 227.7202, all U.S. + Government End Users acquire the Product with only those + rights as set forth therein. + + + + + Miscellaneous + + + + + This Agreement constitutes the entire agreement between + Mozilla and you concerning the subject matter hereof, and it + may only be modified by a written amendment signed by an + authorized executive of Mozilla. + + + + + Except to the extent applicable law, if any, provides + otherwise, this Agreement will be governed by the laws of the + state of California, U.S.A., excluding its conflict of law + provisions. + + + + + This Agreement will not be governed by the United Nations + Convention on Contracts for the International Sale of Goods. + + + + + If any part of this Agreement is held invalid or + unenforceable, that part will be construed to reflect the + parties' original intent, and the remaining portions will + remain in full force and effect + + + + + A waiver by either party of any term or condition of this + Agreement or any breach thereof, in any one instance, will not + waive such term or condition or any subsequent breach thereof. + + + + + Except as required by law, the controlling language of this + Agreement is English. + + + + + You may assign your rights under this Agreement to any party + that consents to, and agrees to be bound by, its terms; the + Mozilla Corporation may assign its rights under this Agreement + without condition. + + + + + This Agreement will be binding upon and inure to the benefit + of the parties, their successors and permitted assigns. + + + + + + + +
diff --git a/Documentation/Manuals/Distro/release-notes.docbook b/Documentation/Manuals/Distro/release-notes.docbook new file mode 100644 index 0000000..7896e26 --- /dev/null +++ b/Documentation/Manuals/Distro/release-notes.docbook @@ -0,0 +1,67 @@ + + + +
+ + CentOS =RELEASE= Release Notes + + + + + + + + + + + =COPYRIGHT_YEAR_LAST= + The CentOS Project + + + + The CentOS =RELEASE= Release Notes are licensed under + a Creative + Common Attribution-ShareAlike 3.0 License. + + + + + + The CentOS Project welcomes you to CentOS =RELEASE=. + + + + The complete release notes for CentOS =RELEASE= can be found + online at: . + + + + A list of frequently asked questions and answers about CentOS + =RELEASE= can be found online at: + . + + + + If you are looking for help with CentOS, we recommend you + start at the for pointers to the different sources where you can get + help. + + + + If you would like to contribute to The CentOS Project, see + for areas where you + could help. + + + + For more information about The CentOS Project in general + please visit our homepage at: . + + +
diff --git a/Documentation/Manuals/Distro/welcome.docbook b/Documentation/Manuals/Distro/welcome.docbook new file mode 100644 index 0000000..9c8ee15 --- /dev/null +++ b/Documentation/Manuals/Distro/welcome.docbook @@ -0,0 +1,108 @@ + + + +
+ + Welcome to CentOS =RELEASE= + + + + + + + + + + + =COPYRIGHT_YEAR_LAST= + The CentOS Project + + + + CentOS =RELEASE= comes with no guarantees or warranties of + any sorts, either written or implied. The Distribution is + released as GPL + work. Individual packages in the distribution come with + their own licences. + + + + + + What is CentOS? + + CentOS is an Enterprise-class Linux + Distribution derived from sources freely provided to the + public by a prominent North American Enterprise Linux vendor. + CentOS conforms fully with the upstream vendors redistribution + policy and aims to be 100% binary compatible. (CentOS mainly + changes packages to remove upstream vendor branding and + artwork.) + + + CentOS is developed by a small but growing team of core + developers. In turn the core developers are supported by an + active user community including system administrators, network + administrators, enterprise users, managers, core Linux + contributors and Linux enthusiasts from around the world. + + + + + Advantages + + CentOS has numerous advantages including: an active and + growing user community, quickly rebuilt, tested, and QA'ed + errata packages, an extensive mirror + network, developers who are contactable and responsive + reliable Enterprise Linux class distribution, multiple free + support avenues. + + + + + Support + + The following free support avenues are available: + + + + + + The CentOS Website + + + + + The CentOS Wiki + (includes a dynamic FAQ) + + + + + The + CentOS IRC Chat + + + + + The CentOS Mailing + List + + + + + The CentOS Forums + + + + + + +
diff --git a/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter-menu.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter-menu.texinfo new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter-menu.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter-nodes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter-nodes.texinfo new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter-nodes.texinfo @@ -0,0 +1 @@ + diff --git a/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter.texinfo new file mode 100644 index 0000000..05e1ecb --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Branches/chapter.texinfo @@ -0,0 +1,16 @@ +@node Branches +@chapter The @file{branches} Directory +@cindex The @file{branches} Directory + +@c -- Chapter Introduction +This directory implements the Subversion's branches concept in a +trunk, branches, tags repository structure. The @file{branches} +directory structure provides an intermediate space for creating +temporal changes that might be later merged into @file{trunk} +directory structure (@pxref{Trunk}). + +@c -- Chapter Menu +@include Branches/chapter-menu.texinfo + +@c -- Chapter Nodes +@include Branches/chapter-nodes.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter-menu.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter-menu.texinfo new file mode 100755 index 0000000..b8240ba --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter-menu.texinfo @@ -0,0 +1,4 @@ +@menu +* GNU General Public License:: +* GNU Free Documentation License:: +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter-nodes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter-nodes.texinfo new file mode 100755 index 0000000..bd707d6 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter-nodes.texinfo @@ -0,0 +1,9 @@ +@node GNU General Public License +@section GNU General Public License +@cindex GNU General Public License +@include trunk/Scripts/Bash/Functions/Help/Texinfo/Templates/en_US/Licenses/GPL.texinfo + +@node GNU Free Documentation License +@section GNU Free Documentation License +@cindex GNU Free Documentation License +@include trunk/Scripts/Bash/Functions/Help/Texinfo/Templates/en_US/Licenses/GFDL.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter.texinfo new file mode 100755 index 0000000..e5ffcbd --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Licenses/chapter.texinfo @@ -0,0 +1,5 @@ +@node Licenses +@appendix Licenses +@cindex Licenses +@include Licenses/chapter-menu.texinfo +@include Licenses/chapter-nodes.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter-menu.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter-menu.texinfo new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter-menu.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter-nodes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter-nodes.texinfo new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter-nodes.texinfo @@ -0,0 +1 @@ + diff --git a/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter.texinfo new file mode 100644 index 0000000..cfd4897 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Tags/chapter.texinfo @@ -0,0 +1,16 @@ +@node Tags +@chapter The @file{tags} Directory +@cindex The @file{tags} Directory + +@c -- Chapter Introduction +This directory implements the Subversion's tags concept in a trunk, +branches, tags repository structure. The @file{tags/} directory +structure provides frozen branches. Generally, we use frozen branches +to make check-points in time for development lines under +@file{branches/} or @file{trunk/} directory structure. + +@c -- Chapter Menu +@include Tags/chapter-menu.texinfo + +@c -- Chapter Nodes +@include Tags/chapter-nodes.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter-menu.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter-menu.texinfo new file mode 100644 index 0000000..fccaa2d --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter-menu.texinfo @@ -0,0 +1,23 @@ +@menu +* Trunk Identity:: +* Trunk Identity Brushes:: +* Trunk Identity Brushes Corporate:: +* Trunk Identity Fonts:: +* Trunk Identity Images:: +* Trunk Identity Images Brands:: +* Trunk Identity Images Brands Logos:: +* Trunk Identity Images Brands Symbols:: +* Trunk Identity Images Brands Types:: +* Trunk Identity Images Themes:: +* Trunk Identity Models:: +* Trunk Identity Models Brands:: +* Trunk Identity Models Brands Logos:: +* Trunk Identity Models Icons:: +* Trunk Identity Models Themes:: +* Trunk Identity Palettes:: +* Trunk Identity Patterns:: +* Trunk Identity Webenv:: +* Trunk Scripts:: +* Trunk Scripts Functions:: +* Trunk Scripts Functions Prepare:: +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter-nodes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter-nodes.texinfo new file mode 100644 index 0000000..1aba12c --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter-nodes.texinfo @@ -0,0 +1,21 @@ +@include Trunk/identity.texinfo +@include Trunk/identity-brushes.texinfo +@include Trunk/identity-brushes-corporate.texinfo +@include Trunk/identity-fonts.texinfo +@include Trunk/identity-images.texinfo +@include Trunk/identity-images-brands.texinfo +@include Trunk/identity-images-brands-logos.texinfo +@include Trunk/identity-images-brands-symbols.texinfo +@include Trunk/identity-images-brands-types.texinfo +@include Trunk/identity-images-themes.texinfo +@include Trunk/identity-models.texinfo +@include Trunk/identity-models-brands.texinfo +@include Trunk/identity-models-brands-logos.texinfo +@include Trunk/identity-models-icons.texinfo +@include Trunk/identity-models-themes.texinfo +@include Trunk/identity-palettes.texinfo +@include Trunk/identity-patterns.texinfo +@include Trunk/identity-webenv.texinfo +@include Trunk/scripts.texinfo +@include Trunk/scripts-functions.texinfo +@include Trunk/scripts-functions-prepare.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter.texinfo new file mode 100644 index 0000000..8421fe0 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/chapter.texinfo @@ -0,0 +1,15 @@ +@node Trunk +@chapter The @file{trunk} Directory +@cindex The @file{trunk} Directory + +@c -- Chapter Introduction +The @file{trunk} directory structure implements the Subversion's trunk +concept in a trunk, branches, tags repository structure. It provides +the main development line inside @value{TCAR} and is made of the +following components: + +@c -- Chapter Menu +@include Trunk/chapter-menu.texinfo + +@c -- Chapter Nodes +@include Trunk/chapter-nodes.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-brushes-corporate.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-brushes-corporate.texinfo new file mode 100644 index 0000000..265f3fc --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-brushes-corporate.texinfo @@ -0,0 +1,10 @@ +@node Trunk Identity Brushes Corporate +@section @file{trunk/Identity/Brushes/Corporate} +@cindex Trunk identity brushes corporate + +... + +@c -- <[centos-art(SeeAlso) +@itemize +@end itemize +@c -- ]> diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-brushes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-brushes.texinfo new file mode 100644 index 0000000..ec6d853 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-brushes.texinfo @@ -0,0 +1,80 @@ +@node Trunk Identity Brushes +@section @file{trunk/Identity/Brushes} +@cindex Trunk identity brushes + +The @file{trunk/Identity/Brushes} directory exists to organize GIMP +brushes used inside @value{TCPCVI}. + +A brush is a pixmap or set of pixmaps used for painting through an +image manipulation program like GIMP. Inside the repository, brushes +are initially created in @file{.xcf} format and later exported to any +of the brush formats recognized by GIMP (e.g., @file{.gbr} or +@file{.gih}) using the same name of its source file. + +The @file{trunk/Identity/Brushes} directory is under version control. + +The @file{trunk/Identity/Brushes} directory contains no file, but the +following organizational directories: + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Identity Brushes Corporate} +@end itemize +@c -- ]> + +Content rendition inside @file{trunk/Identity/Brushes} directory is +not supported. + +In order for brushes to be loaded by GIMP, they should be stored in +the @file{~/.gimp-2.2/brushes} directory. This location is out of +@value{TCAR} and doesn't provide version control by itself. To be able +of using version controlled brushes inside GIMP, we store brush +related files inside @file{trunk/Identity/Brushes} directory and +create links to them from @file{~/.gimp-2.2/brushes} directory. + +@float Example,trunk-identity-brushes-1 +@verbatim +trunk/Identity/Brushes +|-- Corporate +| |-- symbol.xcf +| `-- symbol.gbr (file) <-- ~/.gimp-2.2/brushes/corporate-symbol.gbr (link) +|-- TreeFlower +| |-- flower.gbr (file) <-- ~/.gimp-2.2/brushes/treeflower-flower.gbr (link) +| |-- flower.xcf +| |-- branch.gbr (file) <-- ~/.gimp-2.2/brushes/treeflower-branch.gbr (link) +| |-- branch.xcf +| |-- trunk.gbr (file) <-- ~/.gimp-2.2/brushes/treeflower-trunk.gbr (link) +| `-- trunk.xcf +`-- Others + `-- ... +@end verbatim +@caption{Relation between brushes inside the workstation.} +@end float + +The entire link preparation and maintainance of brushes inside the +working copy is automated by @code{prepare} functionality of +@command{centos-art.sh} script. + +Inside the working copy, brushes might be created individually in +different locations, but they all need to be linked from one unique +location (i.e., @file{~/.gimp-2.2/brushes}). This configuration may +provoke brushes to overlap one another if a consistent name +convenction is not implemented correctly. In that sake, the brushes +file names are build using their directory and file names as reference +in order to build unique names that can be used as identifiers. + +Brushes produced with GIMP has a description field associated that is +shown in the Brushes panel of GIMP. This description is set when the +brush is created as @file{.xcf} file and can be updated when it is +exported either to @file{.gbr} or @file{.gih} format. It wouldn't be +too useful to have two or more brushes using the same description so, +we also make description of brush files unique, too. In that sake, use +the file name as description but without including the file extension +(e.g., if we have the @file{centos-flame-3.gbr} brush, its description +would be @code{centos-flame-3}). + +More information about GIMP brushes can be found in +@url{file:///usr/share/gimp/2.0/help/en/index.html,The Gimp Manual}, +specifically in the section related to +@url{file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.html, +Brushes}. diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-fonts.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-fonts.texinfo new file mode 100644 index 0000000..a77a537 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-fonts.texinfo @@ -0,0 +1,54 @@ +@node Trunk Identity Fonts +@section @file{trunk/Identity/Fonts} +@cindex Trunk identity fonts + +The @file{trunk/Identity/Fonts} directory exists to organize +typographies used inside @value{TCPCVI} that aren't packaged inside +@value{TCD}. + +The @file{trunk/Identity/Fonts} directory is under version control. + +Content rendition inside @file{trunk/Identity/Fonts} directory is not +supported. + +@c -- describe, in one paragraph, what a font is. + +In order for fonts to be available inside programs like GIMP and +Inkscape, font files should be stored either in +@file{/usr/share/fonts} or @file{~/.fonts} directory. These locations +are out of @value{TCAR} and doesn't provide version control by +themselves. In order for version controlled typographies to be +available inside programs like GIMP and Inkscape, we store them under +@file{trunk/Identity/Fonts} directory and create links to them from +@file{~/.fonts} directory. + +@float Example, trunk-identity-fonts-1 +@verbatim +trunk/Identity/Fonts +`-- denmark.ttf (file) <-- ~/.fonts/denmark.ttf (link) +@end verbatim +@caption{Relation between fonts inside the workstation.} +@end float + +The creation and maintainance of links related to fonts inside the +working copy are automated by @code{prepare} functionality of +@command{centos-art.sh} script. + +Inside @value{TCPCVI}, the @samp{DejaVu LGC} typography is used as +default typography in all visual manifestations. The @samp{DejaVu LGC} +typography comes with @value{TCD} so there is no need to store it in +@file{trunk/Identity/Fonts} for you to use. + +Inside @value{TCPCVI}, the @samp{Denmark} typography is used as base +to build The CentOS Logo (i.e., the main graphic design that +connects/identifies all visual manifestations related to The CentOS +Project). The @samp{Denmark} typography doesn't come with @value{TCD} +so it is store in @file{trunk/Identity/Fonts} for you to use. + +The license information of @samp{Denmark} typography isn't very clear, +at least not as clear as the one in @samp{DejaVu LGC} typography is. +Using a typography with a doubtful license might put in risk the +content produced from it. To prevent such issues, it would be better +to move on from @samp{Denmark} typography to another typography (free, +preferably) that retain the same visual style of @samp{Denmark}, but +with a clearer copyright and license notice. diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-logos.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-logos.texinfo new file mode 100644 index 0000000..00a2741 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-logos.texinfo @@ -0,0 +1,42 @@ +@node Trunk Identity Images Brands Logos +@section @file{trunk/Identity/Images/Brands/Logos} +@cindex Trunk identity images brands logos + +The @file{trunk/Identity/Images/Brands/Logos} exists to organize +images related to The CentOS Logos, in different formats (e.g., PNG, +JPG, PDF, TIF, XBM, XPM) and dimensions. + +The CentOS Logo is a construction made of The CentOS Symbol and The +CentOS Type. The CentOS Symbol and The CentOS Logo are the main visual +manifestations of the organization known as @value{TCPROJ}. As The +CentOS Symbol, The CentOS Logo is used to ``brand'' images produced by +@value{TCPROJ} and provide a visual connection between images so they +can be monolithically recognized as part of @value{TCPROJ}. The CentOS +Logo must be exactly the same everytime it is printed out and a route +to reproduce it in such a way must be available so as to avoid +reproduction mistakes when images are branded with it. + +The @file{trunk/Identity/Images/Brands/Logos} directory and the files +inside it aren't under version control. + +The @file{trunk/Identity/Images/Brands/Logos} directory contains files +used by the @file{redhat-logos} package, specifically the files inside +the @file{/usr/share/pixmaps/redhat} directory. + +The @file{trunk/Identity/Images/Brands/Logos} directory organizes +files under directories numerically named (e.g., @file{48}, @file{64}, +@file{128}, etc.). Inside these directories, image files are stored +in specific heights and named as +@file{centos-.}, where @code{} +describes the file content and @code{} sets the file +extension. In all cases, the directory name can be used as reference +to determine the image height of files stored inside. For example, +the directory @file{48} stores image files of 48 pixels height in +different formats. + +Content rendition inside @file{trunk/Identity/Images/Brands/Logos} +directory takes place through the following command: + +@verbatim +centos-art render trunk/Identity/Images/Brands/Logos --dont-commit-changes +@end verbatim diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-symbols.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-symbols.texinfo new file mode 100644 index 0000000..3ac5b2f --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-symbols.texinfo @@ -0,0 +1,40 @@ +@node Trunk Identity Images Brands Symbols +@section @file{trunk/Identity/Images/Brands/Symbols} +@cindex Trunk identity images brands symbols + +The @file{trunk/Identity/Images/Brands/Symbols} exists to organize +images related to The CentOS Symbol, in different formats (e.g., PNG, +JPG, PDF, TIF, XBM, XPM) and dimensions. + +The CentOS Symbol is the graphical part of The CentOS Logo. As The +CentOS Logo, The CentOS Symbol is used to ``brand'' images produced by +@value{TCPROJ} and provide a visual connection between images so they +can be monolithically recognized as part of @value{TCPROJ}. The CentOS +Symbol must be exactly the same everytime it is printed out and a +route to reproduce it in such a way must be available so as to avoid +reproduction mistakes when images are branded with it. + +The @file{trunk/Identity/Images/Brands/Symbols} directory and the files +inside it aren't under version control. + +The @file{trunk/Identity/Images/Brands/Symbols} directory contains +files used by the @file{redhat-logos} package, specifically the files +inside the @file{/usr/share/pixmaps/redhat} directory. + +The @file{trunk/Identity/Images/Brands/Symbols} directory organizes +files under directories numerically named (e.g., @file{48}, @file{64}, +@file{128}, etc.). Inside these directories, image files are stored +in specific heights and named as +@file{centos-.}, where @code{} +describes the file content and @code{} sets the file +extension. In all cases, the directory name can be used as reference +to determine the image height of files stored inside. For example, +the directory @file{48} stores image files of 48 pixels height in +different formats. + +Content rendition inside @file{trunk/Identity/Images/Brands/Symbols} +directory takes place through the following command: + +@verbatim +centos-art render trunk/Identity/Images/Brands/Symbols --dont-commit-changes +@end verbatim diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-types.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-types.texinfo new file mode 100644 index 0000000..c1b1f88 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands-types.texinfo @@ -0,0 +1,44 @@ +@node Trunk Identity Images Brands Types +@section @file{trunk/Identity/Images/Brands/Types} +@cindex Trunk identity images brands types + +The @file{trunk/Identity/Images/Brands/Types} exists to organize +images related to The CentOS Symbol, in different formats (e.g., PNG, +JPG, PDF, TIF, XBM, XPM) and dimensions. + +The CentOS Type is the typographical part of The CentOS Logo. +Comparing with both The CentOS Logo and The CentOS Symbol, The CentOS +Type by its own, provides poor visual connection between images that +intend to be recongnized as a monolithic part of @value{TCPROJ} and +shouldn't be used alone. Instead, The CentOS Logo or The CentOS Symbol +are prefered. The CentOS Symbol must be exactly the same everytime it +is printed out and a route to reproduce it in such a way must be +available so as to avoid reproduction mistakes when images are branded +with it. + +The @file{trunk/Identity/Images/Brands/Types} directory and the files +inside it aren't under version control. Files in this location are +mainly used to build The CentOS Logo from combining both The CentOS +Type and The CentOS Symbol in specific situations that might be needed +doing so. + +The @file{trunk/Identity/Images/Brands/Types} directory contains files +used by no package, as far as we've found out. + +The @file{trunk/Identity/Images/Brands/Types} directory organizes +files under directories numerically named (e.g., @file{48}, @file{64}, +@file{128}, etc.). Inside these directories, image files are stored +in specific heights and named as +@file{centos-.}, where @code{} +describes the file content and @code{} sets the file +extension. In all cases, the directory name can be used as reference +to determine the image height of files stored inside. For example, +the directory @file{48} stores image files of 48 pixels height in +different formats. + +Content rendition inside @file{trunk/Identity/Images/Brands/Types} +directory takes place through the following command: + +@verbatim +centos-art render trunk/Identity/Images/Brands/Types --dont-commit-changes +@end verbatim diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands.texinfo new file mode 100644 index 0000000..f2d8270 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-brands.texinfo @@ -0,0 +1,27 @@ +@node Trunk Identity Images Brands +@section @file{trunk/Identity/Images/Brands} +@cindex Trunk identity images brands + +The @file{trunk/Identity/Images/Brands} directory exists to organize +brand information related to @value{TCPROJ}. + +The @file{trunk/Identity/Images/Brands} directory isn't under version +control. + +The @file{trunk/Identity/Images/Brands} contains no file, but the +following organizational directories: + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Identity Images Brands Logos} +@item @ref{Trunk Identity Images Brands Symbols} +@item @ref{Trunk Identity Images Brands Types} +@end itemize +@c -- ]> + +Content rendition inside @file{trunk/Identity/Images/Brands} directory +takes place through the following command: + +@verbatim +centos-art render trunk/Identity/Images/Brands --dont-commit-changes +@end verbatim diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-themes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-themes.texinfo new file mode 100644 index 0000000..ea7432e --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images-themes.texinfo @@ -0,0 +1,7 @@ +@node Trunk Identity Images Themes +@section @file{trunk/Identity/Images/Themes} +@cindex Trunk identity images themes +... + +@menu +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images.texinfo new file mode 100644 index 0000000..2a710e3 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-images.texinfo @@ -0,0 +1,25 @@ +@node Trunk Identity Images +@section @file{trunk/Identity/Images} +@cindex Trunk identity images + +The @file{trunk/Identity/Images} directory exists to store all image +files (e.g., PNG, JPG, PPM, etc.) related to @value{TCPCVI}. + +The @file{trunk/Identity/Images} directory is under version control. + +The @file{trunk/Identity/Images} directory contains no file, but the +following organizational directories: + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Identity Images Brands} +@item @ref{Trunk Identity Images Themes} +@end itemize +@c -- ]> + +Content rendition inside @file{trunk/Identity/Images} directory takes +place through the following command: + +@verbatim +centos-art render trunk/Identity/Images --dont-commit-changes +@end verbatim diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-brands-logos.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-brands-logos.texinfo new file mode 100644 index 0000000..3e01581 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-brands-logos.texinfo @@ -0,0 +1,8 @@ +@node Trunk Identity Models Brands Logos +@section @file{trunk/Identity/Models/Brands/Logos} +@cindex Trunk identity models brands logos + +... + +@menu +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-brands.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-brands.texinfo new file mode 100644 index 0000000..e6bd846 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-brands.texinfo @@ -0,0 +1,9 @@ +@node Trunk Identity Models Brands +@section @file{trunk/Identity/Models/Brands} +@cindex Trunk identity models brands + +... + +@menu +* Trunk Identity Models Brands Logos:: +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-icons.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-icons.texinfo new file mode 100644 index 0000000..2c56d59 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-icons.texinfo @@ -0,0 +1,10 @@ +@node Trunk Identity Models Icons +@section @file{trunk/Identity/Models/Icons} +@cindex Trunk identity models icons + +... + +@c -- <[centos-art(SeeAlso) +@itemize +@end itemize +@c -- ]> diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-themes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-themes.texinfo new file mode 100644 index 0000000..e0c2c6a --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models-themes.texinfo @@ -0,0 +1,10 @@ +@node Trunk Identity Models Themes +@section @file{trunk/Identity/Models/Themes} +@cindex Trunk identity models themes + +... + +@c -- <[centos-art(SeeAlso) +@itemize +@end itemize +@c -- ]> diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models.texinfo new file mode 100644 index 0000000..b725181 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-models.texinfo @@ -0,0 +1,13 @@ +@node Trunk Identity Models +@section @file{trunk/Identity/Models} +@cindex Trunk identity models + +... + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Identity Models Brands} +@item @ref{Trunk Identity Models Icons} +@item @ref{Trunk Identity Models Themes} +@end itemize +@c -- ]> diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-palettes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-palettes.texinfo new file mode 100644 index 0000000..1502894 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-palettes.texinfo @@ -0,0 +1,7 @@ +@node Trunk Identity Palettes +@section @file{trunk/Identity/Palettes} +@cindex Trunk identity palettes +... + +@menu +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-patterns.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-patterns.texinfo new file mode 100644 index 0000000..d4cf568 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-patterns.texinfo @@ -0,0 +1,7 @@ +@node Trunk Identity Patterns +@section @file{trunk/Identity/Patterns} +@cindex Trunk identity patterns +... + +@menu +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-webenv.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-webenv.texinfo new file mode 100644 index 0000000..de47fe1 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity-webenv.texinfo @@ -0,0 +1,7 @@ +@node Trunk Identity Webenv +@section @file{trunk/Identity/Webenv} +@cindex Trunk identity webenv +... + +@menu +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity.texinfo new file mode 100644 index 0000000..788f31e --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/identity.texinfo @@ -0,0 +1,33 @@ +@node Trunk Identity +@section @file{trunk/Identity} +@cindex Trunk identity + +The @file{trunk/Identity} directory describes @value{TCPCI}, what it +is and the components it is made of. + +@value{TCPCI} is the ``persona'' of the organization known as The +CentOS Project. The CentOS Project Corporate Identity plays a +significant role in the way The CentOS Project, as organization, +presents itself to both internal and external stakeholders. In general +terms, The CentOS Project Corporate Identity expresses the values and +ambitions of The CentOS Project organization, its business, and its +characteristics. @value{TCPCI} provides visibility, recognizability, +reputation, structure and identification to The CentOS Project by +means of Corporate Design, Corporate Communication, and Corporate +Behaviour. + +From Corporate Design, Corporate Communication and Corporate +Behaviour, it is the Corporate Design the one organized inside +@file{trunk/Identity} directory through the following components: + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Identity Brushes} +@item @ref{Trunk Identity Fonts} +@item @ref{Trunk Identity Images} +@item @ref{Trunk Identity Models} +@item @ref{Trunk Identity Palettes} +@item @ref{Trunk Identity Patterns} +@item @ref{Trunk Identity Webenv} +@end itemize +@c -- ]> diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts-functions-prepare.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts-functions-prepare.texinfo new file mode 100644 index 0000000..2035cf9 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts-functions-prepare.texinfo @@ -0,0 +1,86 @@ +@node Trunk Scripts Functions Prepare +@section @file{trunk/Scripts/Functions/Prepare} +@cindex Trunk scripts functions prepare + +The @file{trunk/Scripts/Functions/Prepare} directory exists to +organize the @code{prepare} functionality of @command{centos-art.sh} +script. The @code{prepare} functionality is written in Bash and its +main goal is to standardize the final configuration stuff your +workstation needs, once the working copy of @value{TCAR} has been +downloaded inside it. + +The @file{trunk/Scripts/Functions/Prepare} directory and all files +inside it are under version control. + +Content rendition inside @file{trunk/Scripts/Functions/Prepare} is not +supported. + +Inside @file{trunk/Scripts/Functions/Prepare} directory, file names +and function names share the same name convenction with the exception +that file names end with a @samp{.sh} suffix while function names +doesn't. Both, file names and function names, begin with +@samp{prepare_} prefix followed by a description of what the function +does. + +Inside @file{trunk/Scripts/Functions/Prepare} directory, you can find +the following functions: + +@defun prepare +The @code{prepare} (initialization) function creates the base +execution environment required to standardize final configuration +stuff needed by your workstation, once the working copy of +@value{TCAR} has been downloaded in it. +@end defun + +@defun prepare_getOptions +The @code{prepare_getOptions} function parses command options provided +to @command{centos-art.sh} script when the first argument in the +command-line is the @samp{prepare} word. This function decides what +action to perform based on options provided. To parse options, this +function makes use of @command{getopt} program. +@end defun + +@defun prepare_updateLinks +The @code{prepare_updateLinks} function updates the symbolic +link relation that connects your workstation with the files inside the +working copy of @value{TCAR}. This function makes brushes, palettes, +patterns and fonts inside the working copy available to programs like +GIMP and Inkscape installed in your workstation. +@end defun + +@defun prepare_updateImages +The @code{prepare_updateImages} function initializes image files +inside the working copy. This function makes a list of all design +models inside the working copy and renders them one by one to produces +the related output images. +@end defun + +@defun prepare_updateManuals +The @code{prepare_updateManuals} function initializes +documentation files inside the working copy. This function makes a +list of all documentation manuals source files inside the working copy +and produces related output for them. +@end defun + +@defun prepare_updatePackages +The @code{prepare_updatePackages} function verifies the required +packages your workstation needs to have installed in order for +@command{centos-art.sh} script to run correctly. If one or +more packages are uninstalled or out of date, the +@command{centos-art.sh} script asks you to confirm their +installation or actualization through the @command{sudo yum} command. +@end defun + +@defun prepare_getEnvars +The @code{prepare_getEnvars} function outputs a brief description of +relevant environment variables the @command{centos-art.sh} script +makes use of. +@end defun + +@defun prepare_getLinkName DIRECTORY, FILE +The @code{prepare_getLinkName} function takes a @var{DIRECTORY} path +as first argument and a @var{FILE} path as second argument to output a +file name with the path information that remains from substracting the +@var{DIRECTORY} path from the @var{FILE} path provided as argument. +@end defun + diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts-functions.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts-functions.texinfo new file mode 100644 index 0000000..d2e0116 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts-functions.texinfo @@ -0,0 +1,69 @@ +@node Trunk Scripts Functions +@section @file{trunk/Scripts/Functions} +@cindex Trunk scripts functions + +The @file{trunk/Scripts/Functions} directory exists to organize common +and spectic functionalities related to the @command{centos-art.sh} +script. Common functionalities are loaded once the +@command{centos-art.sh} script is executed and made available for +sepecific functionalities to reuse. + +The @file{trunk/Scripts/Functions} directory and all files inside it +are under version control. + +Content rendition inside `trunk/Scripts/Functions' directory is not +supported. + +Inside @file{trunk/Scripts/Functions} directory, specific +functionalities are organized in the following directories: + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Scripts Functions Prepare} +@end itemize +@c -- ]> + +Inside @file{trunk/Scripts/Functions} directory, common +functionalities are stored in files prefixed with the @samp{cli} +string as described below: + +@defun cli "$@@" +The @code{cli} functionality initializes the command-line interface +(cli) of @command{centos-art.sh} script. This function evaluates the +first argument provided to @command{centos-art.sh} script and call the +specific functionality that respondes to it. The @code{cli} function +is directly called from @file{centos-art.sh} itself once global +variables are defined, working copy verification performed, common +functionalities exported into the execution environment, and signals +trapped. The @code{cli} function receives all positional parameters +passed to @command{centos-art.sh} as argument. + +The @code{cli} function creates the a new environment inside that one +created by @command{centos-art.sh} script execution. Variables defined +herein will be avaialble to all specific functionalities and common +functionalities used inside specific functionalities. + +@defvar FUNCNAM +The @var{FUNCNAM} variable stores the function name passed as first +argument to @command{centos-art.sh} script using the file convenction +specified by @code{cli_getRepoName} function. +@end defvar + +@defvar FUNCDIR +The @var{FUNCDIR} variable stores the absolute path of directory +holding @command{centos-art.sh} script functions, both common and +specific. +@end defvar + +@defvar FUNCDIRNAM +... +@end defvar + +@defvar FUNCSCRIPT +... +@end defvar + +@defvar ARGUMENTS +... +@end defvar +@end defun diff --git a/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts.texinfo b/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts.texinfo new file mode 100644 index 0000000..51d2a43 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/Trunk/scripts.texinfo @@ -0,0 +1,73 @@ +@node Trunk Scripts +@section @file{trunk/Scripts} +@cindex Trunk scripts + +The @file{trunk/Scripts} directory exists to organize automation +scripts related to @value{TCPCVI}. Such automation scripts are +implemented through @command{centos-art.sh} script, a bash scripts +designed to automate most frequent tasks performed inside the working +copy of @value{TCAR} (e.g., image rendition, content documentation, +content translation, etc.). + +The @file{trunk/Scripts} directory and all files inside it are under +version control. + +The @file{trunk/Scripts} directory contains just one file, the +@file{centos-art.sh} file. This file is the invocation script the +@command{centos-art} command calls to. In addition to +@file{centos-art.sh} file, the following directories are available: + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Scripts Functions} +@end itemize +@c -- ]> + +Content rendition inside @file{trunk/Scripts} is not supported. + +Once the @command{centos-art.sh} script is executed, the following +variables are available all along the script execution: + +@defvar CLI_PROGRAM +The @var{CLI_PROGRAM} variable is read-only and contains the name of +the script, which is @samp{centos-art}, without extension. +@end defvar + +@defvar CLI_PROGRAM_ID +The @var{CLI_PROGRAM_ID} variable is read-only and contains the +process identification assigned to @command{centos-art.sh} script, +once executed. +@end defvar + +@defvar CLI_VERSION +The @var{CLI_VERSION} variable is read-only and contains the version +number of @command{centos-art.sh} script. +@end defvar + +@defvar CLI_BASEDIR +The @var{CLI_BASEDIR} variable is read-only and contains the absolute +path of directory where @command{centos-art.sh} script is stored in. +@end defvar + +@defvar CLI_TEMPDIR +The @var{CLI_TEMPDIR} variable is read-only and contains the absolute +path of directory where temporal files created by +@command{centos-art.sh} script are stored in. +@end defvar + +@defvar TEXTDOMAIN +The @var{TEXDOMAIN} variable is read-only and contains the name of the +program we are providing localization for (i.e., @samp{centos-art.sh}). +@end defvar + +@defvar TEXTDOMAINDIR +The @var{TEXTDOMAINDIR} variable is read-only and contains the +absolute path of directory holding localization messages for +@command{centos-art.sh}. In order for this variable to take effect, +its value must be set using the +@file{$@{BASEDIR@}/$@{LANG@}/LC_MESSAGES/$@{TEXDOMAIN@}} construction; +where @var{BASEDIR} is an absolute path inside your workstation, +@var{LANG} a language code based on the standards @samp{ISO-639} and +@samp{ISO-3166} (e.g., @samp{es_ES} for Spanish from Spain, +@samp{fr_FR} for French from France, etc.). +@end defvar diff --git a/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-index.texinfo b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-index.texinfo new file mode 100755 index 0000000..b197b13 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-index.texinfo @@ -0,0 +1,8 @@ +@node Index +@unnumbered Index +@syncodeindex fn cp +@syncodeindex vr cp +@syncodeindex ky cp +@syncodeindex pg cp +@syncodeindex tp cp +@printindex cp diff --git a/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-menu.texinfo b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-menu.texinfo new file mode 100644 index 0000000..2209765 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-menu.texinfo @@ -0,0 +1,7 @@ +@menu +* Trunk:: +* Branches:: +* Tags:: +* Licenses:: +* Index:: +@end menu diff --git a/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-nodes.texinfo b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-nodes.texinfo new file mode 100644 index 0000000..d30344b --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs-nodes.texinfo @@ -0,0 +1,3 @@ +@include Trunk/chapter.texinfo +@include Branches/chapter.texinfo +@include Tags/chapter.texinfo diff --git a/Documentation/Manuals/Tcar-fs/en_US/tcar-fs.conf b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs.conf new file mode 100755 index 0000000..789f831 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs.conf @@ -0,0 +1,36 @@ +# This file controls the manual configuration. This file is divided +# in configuration sections (e.g., `main' and `templates') which, in +# turn, are organized in the form `variable = value'. +# ---------------------------------------------------------------------- +# $Id$ +# ---------------------------------------------------------------------- + +[main] + +# Specify documentation backend used by documentation manual. This is +# the format used to write documentation manual source files. +manual_format = "texinfo" + +# Specify title style used by sections inside the manual. Possible +# values to this option are `cap-each-word' to capitalize each word in +# the section title, `cap-first-word' to capitalize the first word in +# the section title only and `directory' to transform each word in the +# section title into a directory path. From all these options, +# `cap-each-word' is the one used as default. +manual_section_style = "directory" + +# Specify the order used by sections inside the manual. By default new +# sections added to the manual are put on the end to follow the +# section `created' order. Other possible values to this option are +# `ordered' and `reversed' to sort the list of sections alphabetically +# from A-Z and Z-A, respectively. +manual_section_order = "ordered" + +[templates] + +# Specify relation between template files and section definition files +# inside the manual. Template definition is set on the left side using +# relative path. The section main definition file is described on the +# right using a regular expression. The first match wins. +Chapters/section-functions.texinfo = "^.+-functions-[[:alnum:]]+\.texinfo$" +Chapters/section.texinfo = "^.+\.texinfo$" diff --git a/Documentation/Manuals/Tcar-fs/en_US/tcar-fs.texinfo b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs.texinfo new file mode 100644 index 0000000..e1f6b42 --- /dev/null +++ b/Documentation/Manuals/Tcar-fs/en_US/tcar-fs.texinfo @@ -0,0 +1,83 @@ +\input texinfo @c -*-texinfo-*- +@c -- Header -------------------------------------------------- + +@setfilename tcar-fs.info +@settitle The CentOS Artwork Repository File System +@documentlanguage en +@afourpaper +@finalout + +@c -- Variables ----------------------------------------------- + +@set TCENTOS The Community Enterprise Operating System +@set TCPROJ @url{http://www.centos.org/, The CentOS Project} +@set TCWIKI @url{http://wiki.centos.org/, The CentOS Wiki} +@set TCMLISTS @url{http://lists.centos.org/, The CentOS Mailing Lists} +@set TCBUGS @url{http://bugs.centos.org/, The CentOS Bugs} +@set TCMIRRORS @url{http://mirrors.centos.org/, The CentOS Mirrors} +@set TCPLANET @url{http://planet.centos.org/, The CentOS Planet} +@set TCFORUMS @url{http://forums.centos.org/, The CentOS Forums} +@set TCINFOML @email{centos-info@@centos.org, The CentOS Information Mailing List} +@set TCDEVSML @email{centos-devel@@centos.org, The CentOS Developers Mailing List} +@set TCDOCSML @email{centos-docs@@centos.org, The CentOS Documentation Mailing List} +@set TCARTWML @email{centos-artwork@@centos.org, The CentOS Artwork Mailing List} +@set TCL10NML @email{centos-l10n@@centos.org, The CentOS Localization Mailing List} +@set TCAR @url{https://projects.centos.org/svn/artwork/, The CentOS Artwork Repository} +@set TCAS @url{https://projects.centos.org/trac/artwork/, The CentOS Artwork SIG} + +@set TCPCVI The CentOS Project Corporate Visual Identity +@set TCPCI The CentOS Project Corporate Identity +@set TCPCVIS The CentOS Project Corporate Visual Identity Structure +@set TCPCMVIS The CentOS Project Monolithic Corporate Visual Identity Structure + +@set TCD The CentOS Distribution + +@c -- Summary description and copyright ----------------------- + +@copying +This manual describes the directories inside @value{TCAR}. You can use +this manual as reference to know where to store or look for +information inside your working copy of @value{TCAR}. + +Copyright @copyright{} 2009, 2010, 2011 The CentOS Project + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A +copy of the license is included in the section entitled @ref{GNU Free +Documentation License}. +@end copying + +@c -- Titlepage, contents, copyright --------------------------- + +@titlepage +@title The CentOS Artwork Repository +@subtitle File System +@author Alain Reguera Delgado +@page +@vskip 0pt plus 1filll +@insertcopying +@end titlepage +@contents + +@c -- `Top' node and master menu ------------------------------- + +@ifnottex +@node Top +@top The CentOS Artwork Repository File System +@insertcopying +@end ifnottex + +@include tcar-fs-menu.texinfo + +@c -- The body of the document -------------------------------- + +@include tcar-fs-nodes.texinfo + +@c -- The end of the document --------------------------------- + +@include Licenses/chapter.texinfo +@include tcar-fs-index.texinfo + +@bye diff --git a/Documentation/Manuals/Tcar-ug/Identity.docbook b/Documentation/Manuals/Tcar-ug/Identity.docbook new file mode 100644 index 0000000..d36b086 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity.docbook @@ -0,0 +1,17 @@ + + + Corporate Visual Identity + + + + ... + + + + &identity-project; + &identity-brand; + &identity-distro; + &identity-web; + &identity-showroom; + + diff --git a/Documentation/Manuals/Tcar-ug/Identity.ent b/Documentation/Manuals/Tcar-ug/Identity.ent new file mode 100644 index 0000000..144c375 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity.ent @@ -0,0 +1,19 @@ + + + + + + + + + + + + + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Brand.docbook b/Documentation/Manuals/Tcar-ug/Identity/Brand.docbook new file mode 100644 index 0000000..0c0ba19 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Brand.docbook @@ -0,0 +1,11 @@ + + + The CentOS Brand + + &identity-brand-intro; + &identity-brand-symbol; + &identity-brand-type; + &identity-brand-logo; + &identity-brand-motif; + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Brand/intro.docbook b/Documentation/Manuals/Tcar-ug/Identity/Brand/intro.docbook new file mode 100644 index 0000000..84a602a --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Brand/intro.docbook @@ -0,0 +1,49 @@ + + + Introduction + + + &TCBRAND; is the main visual manifestaion of &TCP;. &TCP; + uses &TCBRAND; to connect all the visual manifestions it is + made of (e.g., GNU/Linux Distributions, Web sites, Stationery, + etc.) and, this way, provides recognition + + + ... just as a GPG signature might do for RPM packages. + + + among similar projects available on the Internet. The CentOS + Brand is made of a graphical component (&TCSYMBOL;) and a + typographical component (&TCTYPE;) that, when put together, + make &TCLOGO;. The components that make &TCBRAND; can be used + together or separately, considering that, in hierarchy order, + &TCLOGO; is rather prefered than &TCSYMBOL;, as well as + &TCSYMBOL; is rather prefered than &TCTYPE;. + + + + In addition to those components mentioned above, &TCBRAND; + includes another component named &TCMOTIF;. &TCMOTIF; is + mainly used as background on images and is directly related to + the look and feel of all visual manifestations &TCP; shows its + existence on. In contrast with &TCLOGO;, &TCSYMBOL; and + &TCTYPE;; &TCMOTIF; might change from time to time providing a + vehicle to refresh how &TCP; looks and feels. + + + + &TCBRAND; and all the visual manifestations derivated from it + are available for you to study and propose improvement around + a good citizen's will inside &TCC;, but you are not allowed to + redistribute them elsewhere, without the given permission of + &TCP;. + + + + If you need to redistribute either &TCLOGO; or any visual + manifestation derived from it, write your intentions to the + The CentOS Developers mailing list (centos-devel@centos.org). + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Brand/logo.docbook b/Documentation/Manuals/Tcar-ug/Identity/Brand/logo.docbook new file mode 100644 index 0000000..14c4a9a --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Brand/logo.docbook @@ -0,0 +1,4 @@ + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Brand/motif.docbook b/Documentation/Manuals/Tcar-ug/Identity/Brand/motif.docbook new file mode 100644 index 0000000..7341757 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Brand/motif.docbook @@ -0,0 +1,5 @@ + + The CentOS Motif + ... + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Brand/symbol.docbook b/Documentation/Manuals/Tcar-ug/Identity/Brand/symbol.docbook new file mode 100644 index 0000000..f22e38d --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Brand/symbol.docbook @@ -0,0 +1,4 @@ + + The CentOS Symbol + ... + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Brand/type.docbook b/Documentation/Manuals/Tcar-ug/Identity/Brand/type.docbook new file mode 100644 index 0000000..07c3b14 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Brand/type.docbook @@ -0,0 +1,5 @@ + + The CentOS Type + ... + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Distribution.docbook b/Documentation/Manuals/Tcar-ug/Identity/Distribution.docbook new file mode 100644 index 0000000..0236910 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Distribution.docbook @@ -0,0 +1,16 @@ + + + The CentOS Distribution + ... + + + Release Schema + ... + + + + ... + ... + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Project.docbook b/Documentation/Manuals/Tcar-ug/Identity/Project.docbook new file mode 100644 index 0000000..9c39eb8 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Project.docbook @@ -0,0 +1,41 @@ + + + The CentOS Project + + + The CentOS Project Corporate Identity is the + persona of the organization known as The CentOS + Project. The CentOS Project Corporate Identity plays a + significant role in the way The CentOS Project, as + organization, presents itself to both internal and external + stakeholders. In general terms, The CentOS Project Corporate + Identity expresses the values and ambitions of The CentOS + Project organization, its business, and its characteristics. + + + + The CentOS Project Corporate Identity provides visibility, + recognizability, reputation, structure and identification to + The CentOS Project organization by means of Corporate Design, + Corporate Communication, and Corporate Behaviour. + + +
+ The CentOS Project Corporate Identity. + + The CentOS Project Corporate Identity. + + + + + + +
+ + &identity-project-mission; + &identity-project-design; + &identity-project-communication; + &identity-project-behaviour; + &identity-project-structure; + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Project/behaviour.docbook b/Documentation/Manuals/Tcar-ug/Identity/Project/behaviour.docbook new file mode 100755 index 0000000..bd22f04 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Project/behaviour.docbook @@ -0,0 +1,21 @@ + + + Corporate Behaviour + + + &TCP; corporate behaviour is focused on the effective + interaction of each member involved in the organization (e.g., + core developers, community members, etc.). It is related to + ethics and politics used to do the things inside the + organization. It is related to the sense of direction chosen + by the organization and they way the organization projects + itself to achieve it. + + + + &TCP; corporate behaviour takes place through &TCP; corporate + communication, as described in . + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Project/communication.docbook b/Documentation/Manuals/Tcar-ug/Identity/Project/communication.docbook new file mode 100755 index 0000000..c46dd12 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Project/communication.docbook @@ -0,0 +1,141 @@ + + + Corporate Communication + + + &TCP; corporate communication is focused on the effective + propagation of corporate messages. Propagation of corporate + messages is closely related to the media the organization uses + as vehicle to distribute its corporate messages. + + + + &TCP; corporate communication takes place through the + following visual manifestations: + + + + + + &TCD; + + + This visual manifestation communicates its existence + through software packages. There are packages that make a + remarkable use of images, packages that make a moderate + use of images, and packages that don't use images at all. + This visual manifestation is focused on providing &TCP; + images required by software packages that do use images in + a remarkable way, specially those holding the upstream + brand (e.g., anaconda, + grub, syslinux, + gdm, kdebase). + + + + + The Community Enterprise Operating System itself + (communicates the essense of &TCP; existence.). + + + + + Release Schema (Lifetime) and all the stuff related (e.g., + Release Notes, Documentation, Erratas, etc.). + + + + + + + + &TCW; + + + This visual manifestation communicates its existence + through web applications. These web applications are free + software and come from different providers which + distribute their work with predefined visual styles. + Frequently, these predefined visual styles have no visual + relation among themselves and introduce some visual + contraditions when they all are put together. Removing + these visual contraditions is object of work for this + visual manifestation. + + + + + The CentOS Chat. + + + + + The CentOS Mailing Lists. + + + + + The CentOS Forums. + + + + + The CentOS Wiki. + + + + + Special Interest Groups (SIGs). + + + + + Social Events, Interviews, Conferences, etc. + + + + + The extensive network of mirrors available for downloading + ISO files as well as RPMs and SRPMs used to build them up + in different architectures. + + + + + + + + &TCS; + + + This visual manifestation communicates its existence + through production of industrial objects carrying &TCBRAND;. + These branded objects are directed to be distributed on + social events and/or shops. They provide a way of + promotion and commercialization that may help to reduce + &TCP; expenses (e.g., electrical power, hosting, servers, + full-time-developers, etc.), in a similar way as donations + may do. + + + + + Stationery (e.g., Posters, Stickers, CD Lables and Sleeves). + + + + + Clothes (e.g., Shirts, T-shirts, Pullovers, Caps). + + + + + Installation media (e.g., CDs, DVD, Pendrives). + + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Project/design.docbook b/Documentation/Manuals/Tcar-ug/Identity/Project/design.docbook new file mode 100755 index 0000000..7429c7f --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Project/design.docbook @@ -0,0 +1,96 @@ + + + Corporate Graphic Design + + + The corporate design is focused on the effective presentation + of corporate messages. As corporate messages we understand all + the information emitted from the organization; and when we say + all we mean everything that can be + perceived through the human senses. The corporate design takes + care of defining what this information is and controlling the + way it goes out the organization producing it. + + + + When the organization doesn't take control over the corporate + messages it produces, the organization is letting that area of + its identity to the unknown and the results might be good or + not so good, it is hard to know. The issue to see here is + that even the organization doesn't take control over its + corporate messages, they are always talking about the + organization. Taking control of corporate messages is a + decition the organization needs to take by itself, based on + its need of better describe what it is. + + + + In the very specific case of &TCP;, we'll concentrate our + attention on corporate messages that reach us through the + visual sense. This is, all the visual manifestations &TCP; is + made of. As visual manifestaions we understand all the visible + media &TCP; uses to manifest its existence on. At this point + it is necessary to consider what &TCP; is, what its mission is + and what it is producing. This, in order to identify which + visual manifestations the organization is demanding attention + of corporate design for. + + + + Inside &TCP; we identify and apply corporate design to the + following visual manifestations: + + + + + + + &TCD; — This visual manifestation exists to cover all + actions related to artwork production and rebranding, required + by &TCD; in order to comply with upstream's redistribution + guidelines. This visual manifestation is described in . + + + + + + &TCW; — This visual manifestation exists to cover all + actions related to artwork production required by &TCP; to + manifest its existence in the World Wide Web medium. This + visual manifestation is described in . + + + + + + &TCS; — This visual manifestation exists to cover all + actions related to artwork production required by &TCP; to + manifest its existence through media produced industrially + (e.g., stationery, clothes, CDs, DVDs, etc.). This visual + manifestation is described in . + + + + + + The visual manifestations identified above seem to cover most + media required by &TCP;, as organization, to show its + existence. However, other visual manifestations could be + added in the future, as long as they be needed, to cover + different areas like stands, buildings, offices, road + transportation or whaterver visual manifestation &TCP; + thouches to show its existence. + + + + Once all visual manifestations have been identified and + defined through design models, it is time to visually remark + their connection with &TCP;. This kind of connection is + realized by applying &TCBRAND; to design models inside visual + manifestations supported through corporate design. + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Project/mission.docbook b/Documentation/Manuals/Tcar-ug/Identity/Project/mission.docbook new file mode 100644 index 0000000..507873d --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Project/mission.docbook @@ -0,0 +1,40 @@ + + + Corporate Mission + + + &TCP; exists to produce &TCD;, an Enterprise-class Linux + Distribution derived from sources freely provided to the + public by a prominent North American Enterprise Linux vendor. + &TCD; conforms fully with the upstream vendors redistribution + policy and aims to be 100% binary compatible. (&TCD; mainly + changes packages to remove upstream vendor branding and + artwork.). + + + + &TCD; is developed by a small but growing team of core + developers. In turn the core developers are supported by an + active user community including system administrators, network + administrators, enterprise users, managers, core Linux + contributors and Linux enthusiasts from around the world. + + + + &TCD; has numerous advantages including: an active and growing + user community, quickly rebuilt, tested, and QA'ed errata + packages, an extensive mirror network, developers who are + contactable and responsive of a reliable Enterprise-class + Linux Distribution, multiple free support avenues including a + Wiki, + IRC + Chat, Email Lists, Forums, and + a dynamic FAQ. + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Project/structure.docbook b/Documentation/Manuals/Tcar-ug/Identity/Project/structure.docbook new file mode 100755 index 0000000..a0d20f9 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Project/structure.docbook @@ -0,0 +1,91 @@ + + + Corporate Structure + + + &TCP; corporate structure is based on a &MCVIS;. In this + configuration, one unique name and one unique visual style is + used in all visual manifestation &TCP; is made of. + + + + In a monolithic corporate visual identity structure, internal + and external stakeholders use to feel a strong sensation of + uniformity, orientation, and identification with the + organization. No matter if you are visiting web sites, using + the distribution, or acting on social events, the one unique + name and one unique visual style connects them all to say: + Hey! we are all part of &TCP;. + + + + Other corporate structures for &TCP; have been considered as + well. Such is the case of producing one different visual style + for each major release of &TCD;. This structure isn't + inconvenient at all, but some visual contradictions could be + introduced if it isn't applied correctly and we need to be + aware of it. To apply it correctly, we need to know what &TCP; + is made of. + + + + &TCP;, as organization, is mainly made of (but not limited to) + three visual manifestions: &TCD;, &TCW; and &TCS;. Inside + &TCD; visual manifestations, &TCP; maintains near to four + different major releases of &TCD;, parallely in time. + However, inside &TCW; visual manifestations, the content is + produced for no specific release information (e.g., there is + no a complete web site for each major release of &TCD; + individually, but one web site to cover them all). Likewise, + the content produced in &TCS; is industrially created for no + specific release, but &TCP; in general. + + + + In order to produce the &TCPMCVIS; correctly, we need to + concider all the visual manifestations &TCP; is made of, not + just one of them. If one different visual style is + implemented for each major release of &TCD;, which one of + those different visual styles would be used to cover the + remaining visual manifestations &TCP; is made of (e.g., &TCW; + and &TCS;)? + + + + Probably you are thinking: yes, I see your point, but &TCBRAND; + connects them all already, why would we need to join them up + into the same visual style too, isn't it more work to do, and + harder to maintain? + + + + Harder to maintain, more work to do, probably. Specially when + you consider that &TCP; has proven stability and consistency + through time and, that, certainly, didn't come through + swinging magical wands or something but hardly working out to + automate tasks and providing maintainance through time. With + that in mind, we consider &TCPCVIS; must be consequent with + such stability and consistency tradition. It is true that + &TCBRAND; does connect all the visual manifestations it is present + on, but that connection is strengthened if one unique visual + style backups it. In fact, whatever thing you do to strength + the visual connection among &TCP; visual manifestations would + be very good in favor of &TCP; recognition. + + + + Obviously, having just one visual style in all visual + manifestations for eternity would be a very boring thing and + would give the idea of a visually dead project. So, there is + no problem on creating a brand new visual style for each new + major release of &TCD;, in order to refresh &TCD; visual + style; the problem itself is in not propagating the brand new + visual style created for the new release of &TCD; to all other + visual manifestations &TCP; is made of, in a way &TCP; could + be recognized no matter what visual manifestation be in front + of us. Such lack of uniformity is what introduces the visual + contradition we are precisely trying to solve by mean of + themes production in &TCAR;. + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Showroom.docbook b/Documentation/Manuals/Tcar-ug/Identity/Showroom.docbook new file mode 100644 index 0000000..db87232 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Showroom.docbook @@ -0,0 +1,11 @@ + + + The CentOS Showroom + ... + + + ... + ... + + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Web.docbook b/Documentation/Manuals/Tcar-ug/Identity/Web.docbook new file mode 100644 index 0000000..5a5ba5d --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Web.docbook @@ -0,0 +1,7 @@ + + + The CentOS Web + + &identity-web-intro; + + diff --git a/Documentation/Manuals/Tcar-ug/Identity/Web/intro.docbook b/Documentation/Manuals/Tcar-ug/Identity/Web/intro.docbook new file mode 100644 index 0000000..956fa35 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Identity/Web/intro.docbook @@ -0,0 +1,9 @@ + + + Introduction + + + ... + + + diff --git a/Documentation/Manuals/Tcar-ug/Locales.docbook b/Documentation/Manuals/Tcar-ug/Locales.docbook new file mode 100644 index 0000000..656b9d8 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Locales.docbook @@ -0,0 +1,21 @@ + + + Localization + + + ... + + + + ... + ... + + + ... + ... + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Locales.ent b/Documentation/Manuals/Tcar-ug/Locales.ent new file mode 100644 index 0000000..48245e8 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Locales.ent @@ -0,0 +1,2 @@ + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals.docbook b/Documentation/Manuals/Tcar-ug/Manuals.docbook new file mode 100644 index 0000000..44bacd4 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals.docbook @@ -0,0 +1,30 @@ + + + Documentation + + + + &TCAR; documentation work line is implemented through + documentation manuals. Documentation manuals are + implemented through different documentation formats + provided inside &TCD; (e.g., + Docbook, + Texinfo, + LaTeX, etc.). Structuring + tasks related to documentation systems (e.g., creating, + editing, deleting, copying, renaming, etc.) are + standardized through the help functionality + of centos-art.sh script, as described + in . This way, people + writting documentation don't need to deal with underlaying + tasks like creating files, updating menus, nodes, cross + references and wondering where to put everything in + &TCAR;. + + + + + &manuals-production; + &manuals-formats; + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals.ent b/Documentation/Manuals/Tcar-ug/Manuals.ent new file mode 100644 index 0000000..c68bc34 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals.ent @@ -0,0 +1,13 @@ + + + + + + + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Formats.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Formats.docbook new file mode 100644 index 0000000..9fac62b --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Formats.docbook @@ -0,0 +1,10 @@ + + + Documentation Formats + + &manuals-formats-intro; + &manuals-formats-texinfo; + &manuals-formats-docbook; + &manuals-formats-latex; + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Formats/docbook.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Formats/docbook.docbook new file mode 100644 index 0000000..99935e3 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Formats/docbook.docbook @@ -0,0 +1,47 @@ + + + DocBook + + + This section describes the implementation of DocBook + documentation format inside the help + functionality of centos-art.sh script described in . In this section we assume you + have a basic understanding of DocBook documentation system. + + + + Document Structure + + ... + + + + + Document Templates + + ... + + + + + Document Expansions + + ... + + + + + Document Configuration + + ... + + + + + Document Internationalization + + ... + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Formats/intro.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Formats/intro.docbook new file mode 100644 index 0000000..8facc02 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Formats/intro.docbook @@ -0,0 +1,26 @@ + + + Introduction + + + &TCD; provides support for different documentation formats, + including Texinfo, LaTeX, DocBook and LinuxDoc. These formats + have their own specifications and requirements to create and + maintain documentation manuals written through them. Inside + &TCAR;, the help functionality of + centos-art.sh script provides an interface + where documentation format specifications have been already + considered for you to be able of creating and maintaining + documentation manuals without needing to take care of those + underlaying structuring tasks. + + + + This chapter describes how the help + functionality of centos-art.sh script + implements the different documentation source formats + available inside &TCD;, and the internationalization + issues related to documentation manuals produced through them. + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Formats/latex.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Formats/latex.docbook new file mode 100644 index 0000000..6440ea2 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Formats/latex.docbook @@ -0,0 +1,47 @@ + + + LaTeX + + + This section describes the implementation of LaTeX + documentation format inside the help + functionality of centos-art.sh script described in . In this section we assume you + have a basic understanding of LaTeX language. + + + + Document Structure + + ... + + + + + Document Templates + + ... + + + + + Document Expansions + + ... + + + + + Document Configuration + + ... + + + + + Document Internationalization + + ... + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Formats/texinfo.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Formats/texinfo.docbook new file mode 100644 index 0000000..5efdce2 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Formats/texinfo.docbook @@ -0,0 +1,835 @@ + + + Texinfo + + + This section describes the implementation of Texinfo + documentation format inside the help + functionality of centos-art.sh script + described in . In this + section we assume you have a basic understanding of Texinfo + documentation system. Otherwise, if you don't know what + Texinfo documentation system is, read the Texinfo manual first + (e.g., by running the info texinfo command) + and then, come back here. + + + + Document Structure + + The help functionality of + centos-art.sh provides a document structure + that makes documentation manuals created through it to be + scalable and maintainable through time. This document + structure follows the idea of an upside-down tree to organize + chapters, sections, subsections and the like, as described in + . + + + + The first time you use the help + functionality to create a documentation manual in Texinfo + format, the help functionality considers + the working directory you are placed in to determine where to + store the documentation manual source files. When the current + working directory is branches/Manuals/Texinfo, the + documentation manual directory is created therein. On all + other situations, the documentation manual directory is + created under trunk/Manuals directory. Once + the documentation manual directory has been created, the + help functionality creates the related + definition files using Texinfo documentation templates, as + described in . + + + + Inside the documentation manual directory, source files are + stored inside language-specific directories. The + language-specific directories are necessary to implement + internationalization of Texinfo source files, as described in + . + + + + Inside the language-specific directory, the following files + exist to store the manual's main definitions (e.g., title, + subtitle, author, copyright notice, chapters, appendixes, + indexes and all the similar stuff a documentation manual would + have). In addition to these files, there is one directory for + each chapter created inside the manual. Inside each chapter + directory, you'll found the files controlling the section + definitions related to that chapter they belong to. The + section files (a.k.a. documentation entries) + are suffixed with a texinfo extension and named + arbitrarily, as it is illustrated in . + Inside section files it is where you write the manual's + content itself. + + + + Texinfo document structure + + Texinfo document structure + + + trunk/Manuals/${MANUAL_NAME} +`-- ${LANG} + |-- ${CHAPTER_NAME} + | |-- chapter-menu.texinfo + | |-- chapter-nodes.texinfo + | |-- chapter.texinfo + | `-- ${SECTION_NAME}.texinfo + |-- Licenses + | |-- chapter-menu.texinfo + | |-- chapter-nodes.texinfo + | `-- chapter.texinfo + |-- ${MANUAL_NAME}.conf + |-- ${MANUAL_NAME}-index.texinfo + |-- ${MANUAL_NAME}-menu.texinfo + |-- ${MANUAL_NAME}-nodes.texinfo + `-- ${MANUAL_NAME}.texinfo + + + + + + + Texinfo (as in texinfo-4.8-14.el5) doesn't + support part sectioning inside documentation manuals, so + neither does the help functionality of + centos-art.sh script. Nevertheless, you can + create several documentation manuals and + considered them as part of a bigger + documentation manual to workaround this issue. + + + + In this document structure, the creation of documentation + manuals, chapters and sections is not limitted. You can create + as many documenation manuals, chapters and sections as you + need. The only limitation would be the amount of free space + required to store the Texinfo source files and the output + files produced from them. + + + + + + Document Templates + + Texinfo document templates provide the initial state the + help functionality of + centos-art.sh script needs in order to + create and maintain document structures, as that one described + in . + + + + Texinfo document templates are language-specific. This means + that there is (or, at least, must be) one Texinfo document + template for each language you plan to support documentation + manuals for. By default, &TCAR; provides a default Texinfo + document template under en_US + directory. This template structure is used when your current + locale is English language or when you are creating/editing a + documentation manual in a language other than English, but no + language-specific document template for that language exists + in the directory: + + + +trunk/Scripts/Bash/Functions/Help/Texinfo/Templates + + + This directory organizes all Texinfo document templates using + the format LL_CC, where LL is the language code (as in + ISO-639) and CC the country code (as in ISO-3166). The + directory structure of Texinfo document templates is + illustrated in the and + implemented through the following files: + + + + + manual.texinfo + + + This file can be found inside the language-specific directory + and contains the manual's main definitions (e.g., document + title, document language, document authors, copyright notice, + etc.). + + + + + + manual-menu.texinfo + + + This file can be found inside the language-specific directory + and contains the menu definitions of chapters inside the + manual. Menu definitions in this file are automatically + updated when a new chapter is created or deleted through the + help functionality of + centos-art.sh script. Generally, you don't + need to edit this file once the documentation manual has been + created. + + + When a documentation manual is created for first time, this + file is copied from Texinfo document template directory + structure to the documentation manual being currently created. + At this specific moment, this file contains the following + Texinfo menu definition: + + + @menu +* Licenses:: +* Index:: +@end menu + + + Later, when chapters are added to or deleted from the + documentation manual, the content of this file varies adding + or deleting menu entries accordingly. Nevertheless, the two + entries shown above are ignored when new chapters are added to + or removed from the list, so they will always be present in + this file. To preserve the manual consistency, the + help functionality prevents you from + deleting any of these chapters once the documentation manual + has been created. + + + + + + + manual-nodes.texinfo + + + This file can be found inside the language-specific directory + and contains the node definitions of all chapters inside the + manual. Node definitions in this file are automatically + created based on menu definitions (see + manual-menu.texinfo file above) and they + don't include any content here. Instead, as part of the node + definition, the @include command is used to + connect each node with its content. Generally, you don't need + to edit this file once the documentation manual has been + created. + + + + + + manual-index.texinfo + + + This file can be found inside the language-specific directory + and contains the Texinfo commands used to generated an + organized view of all indexes you defined inside documentation + entries so they can be quickly accessed. Generally, you don't + need to edit this file once the documentation manual has been + created. + + + + + + manual.conf + + + This file contains the initial configuration of documentation + manuals written in Texinfo format. When a documentation manual + is created for first time, this file is copied into its target + directory so you be able of later customizing specific + information like menu order, title styles and template + assignments. The content of this file is described in . + + + + + + chapter.texinfo + + + This file contains the Texinfo's main chapter definition used + by help functionality when new chapters + are created inside documentation manuals. When chapters are + created for first time, they come without any introduction or + documentation entry inside. If you want to add/update any + information inside the chapter definition itself, edit the + related chapter file inside the documentation manual you are + working on, not the template file used to create it. + + + + + + chapter-menu.texinfo + + + This file is part of Texinfo's main chapter definition and + should be initially empty. Later, when chapters are created + for first time, this file is copied as it is (i.e., empty) + into the documentation manual to store the Texinfo menu + entries related to all documentation entries created inside + the chapter. The Texinfo menu entries related to documentation + entries are automatically created using Texinfo source files + as reference. + + + + + + chapter-nodes.texinfo + + + This file is part of Texinfo's main chapter definition and + contains the node definition the help + functionality uses as reference to create the list of Texinfo + nodes related to all documentation entries created inside the + chapter. The node definition of documentation entries is + automatically created from the menu definition of + documentation entries (see + chapter-menu.texinfo file above), once it + has been updated from Texinfo source files. + + + + + + section.texinfo + + + This file contains the Texinfo section definition used by + help functionality when new documentation + entries are created inside the chapters of a documentation + manual. When documentation entries are created for first time, + they are created as empty documentation entries that you need + to fill up with content. Again, if you want to update the + content of sections inside the documentation manual, update + the related documentation entry inside the documentation + manual, not the template file used to create it. + + + + The creation of documentation entries inside the documentation + manual is represented by the + ${SECTION_NAME}.texinfo file, as + described in . In + this example, ${SECTION_NAME} is a variable + string refering the file name of documentaiton entries. + The file names of documentation entries is made of letters, + numbers and the minus sign (which is generally used to + separate words). + + + + Documentation entries are not limited inside a documentation + manual. You can create as many documentation entries as you + need to describe the content of your manual. + + + + + + + There are other files which aren't related to manual's source + files, but to manual's output files. Such files are described + below and can be found either inside or outside the + language-specific directories so you can control common and + specific output settings through them. These files aren't + copied into the directory structure of new documentation + manuals created through the help + functionality of centos-art.sh script. + Instead, they remain inside the template directory structure + so as to be reused each time the output of documentation + manuals is rendered. + + + + + manual-init.pl + + + This file can be found inside and outside language-specific + directories and contains the Texi2html initialization script. + When this file is outside the language-specific directory, it + contains common customizations to all language-specific + outputs (e.g., changing the output DTD). When this file is + inside the language-specific directory, it contains + translations for that language-specific output (e.g., special + words like See, Index, Contents, Top, etc., are localized + here). + + + + + + manual.sed + + + This file can be found inside and outside language-specific + directories and contain special transformations for Texi2html + output. Again, when this file is inside language-specific + directories the transformation have are applied to that + language-specific XHTML output and when it is outside + language-specific directories the transformations are applied + to all language-specific XHTML outputs. Most transformations + achived through this file are to produce admonitions since + Texinfo documentation format (as in + texinfo-4.8-14.el5) doesn't have an + internal command to build them. + + + + + + + Texinfo document template + + Texinfo document template + + + trunk/Scripts/Bash/Functions/Help/Texinfo/Templates +|-- ${LANG} +| |-- Chapters +| | |-- chapter-menu.texinfo +| | |-- chapter-nodes.texinfo +| | |-- chapter.texinfo +| | `-- section.texinfo +| |-- Licenses +| | |-- GFDL.texinfo +| | |-- GPL.texinfo +| | |-- chapter-menu.texinfo +| | |-- chapter-nodes.texinfo +| | `-- chapter.texinfo +| |-- manual-index.texinfo +| |-- manual-init.pl +| |-- manual-menu.texinfo +| |-- manual-nodes.texinfo +| |-- manual.conf +| |-- manual.sed +| `-- manual.texinfo +|-- manual-init.pl +`-- manual.sed + + + + + + + Inside the directory structure of Texinfo document templates, + the Chapters directory + organizes chapter specific models used to create and maintain + both chapter and sections files inside manuals. On the other + hand, the Licenses + directory organizes the license information linked from all + manuals. Notice the license information is not copied into + documentation manuals when they are created, but refered from + this location where they are maintained. This configuration + permites that all documentation manuals written in Texinfo + format inside &TCAR; do use the same license information and + if a change is committed to the license files, such changes be + immediatly propagated to documentation manuals the next time + their output files be updated. + + + + + Document Expansions + + The document expansions are special constructions used to + generate content dynamically inside Texinfo source files. + + + + The <code>SeeAlso</code> Expansion + + + This expansion creates a list of links with section entries + one level ahead from the section entry being currently + processed. In this construction, the TYPE variable can be + either itemize, enumerate or + menu. When no TYPE variable is provided, the + itemize value is considered as default. + + + @c -- <[centos-art(SeeAlso,TYPE) +@c -- ]> + + + This expansion might result useful when you are documenting + the repository file system. For example, if you are currently + editing the documentation entry related to trunk/Identity directory and want + to create a linkable list of all documentation entries in the + first level under it, the code you'll have once the + construction be expanded would look like the following: + + + +@c -- <[centos-art(SeeAlso) +@itemize +@item @ref{Trunk Identity Brushes} +@item @ref{Trunk Identity Fonts} +@item @ref{Trunk Identity Images} +@item @ref{Trunk Identity Models} +@item @ref{Trunk Identity Palettes} +@item @ref{Trunk Identity Patterns} +@item @ref{Trunk Identity Webenv} +@end itemize +@c -- ]> + + + + An interesting thing to notice here is that document + expansions are executed each time the related documentation + entry is edited or updated. Following with the example above, + if the documentation entries related to directories under + trunk/Identity changes + for some reason (e.g., they are removed from documentation + manual), the list generated as result of document expansion + will be updated automatically after editing the documentation + entry or updating the documentation manual structure. + + + + + + + + Document Configuration + + The document configuration is stored in the + ${MANUAL_NAME}.conf file, inside the + documentation manual directory structure. This file is + originally copied from manual.conf + template file when the documentation manual is created for + first time. The content of + ${MANUAL_NAME}.conf file is organized in + sections. Each section here is written in one line of its own + and have the form [section_name]. Under sections, + the configuration settings take place through + name="value" pairs set in one line each. Notice + that quotation marks around the option_value are required. + Comments are also possible using the # character + at the begining of lines. Comments and empty lines (including + tabs and white spaces) are ignored. In case more than one + section or option appear with the same name inside the + configuration file, the first one found will be used. Nested + section definitions are not supported. + + + [section_name] +# This is a comment. +option_name = "option_value" + + + The ${MANUAL_NAME}.conf file is specific + to document templates. If you are using Texinfo document + template to create documentation manuals, then the default + configuration file for that documentation manual is taken from + Texinfo document template directory structure. However, if you + are using a document template different to Texinfo document + template, the default configuration file will be taken from + the related document template directory structure you are + creating the documentation manual from. + + + + The <code>[main]</code> Section + + The [main] section organizes settings that let + you customize the way sections and menu definitions are + created inside the documentation manual. The following options + are available in this section: + + + + + manual_format + + + This option specifies the documentation format used by manual. + To write documentation manuals in Texinfo format, the value + of this option must always be: + + manual_format = "texinfo" + + + Once the documentation manual has been created, you must not + change the value of option. + This will produce an error. + + + + + + + manual_section_style + + + This option specifies the title style used by sections inside + the manual. Possible values to this option are + `cap-each-word' to capitalize each word in the section title, + `cap-first-word' to capitalize the first word in the section + title only and `directory' to transform each word in the + section title into a directory path. From all these options, + `cap-each-word' is the one used as default. + + manual_section_style = "cap-each-word" + + + + + manual_section_order + + + This option specifies the order used by sections inside the + manual. By default new sections added to the manual are put on + the end to follow the section order in which they were + `created'. Other possible values to this option are `ordered' + and `reversed' to sort the list of sections alphabetically + from A-Z and Z-A, respectively. + + manual_section_order = "created" + + + + + + + The <code>[templates]</code> Section + + The [templates] section provides the assignment + relation between template files and documentation entry files + inside the manual. The template definition is set on the left + side using relative path and the documentation entry files are + described on the right side using a regular expression. The + first match wins. + + Chapters/section.texinfo = "^.+\.texinfo$" + + + + + + Document Internationalization + + To produce localized documentation manuals through Texinfo + documentation format it is necessary to create one + documentation manual for each language it is desired to + support documentation for. Documentation manuals created in + this configuration don't have a direct relation among + themselves except that one adopted by people writting them to + keep their content syncronized. In this configuration + translators take one documentation manual as reference (a.k.a. + the source manual) and produce several translated manuals + based on its content. To keep track of changes inside the + source manual, the underlaying version control system must be + used considering that there is no direct way to apply + gettext + + The gettext program translates + a natural language message into the user's language, by + looking up the translation in a message catalog. For more + information about the gettext + program, run info gettext. + + procedures to Texinfo source files. + + + + In order to maintain localization of Texinfo source files + through gettext procedures, it is + necessary to convert the Texinfo source files into + XML format first. This way it would be possible to make use of + locale and render + functionalities from centos-art.sh script + to maintain translation messages in different languages + through portable objets and producing localized XML files + based on such portable objects, respectively. Once the + localized XML file is available, it would be a matter of using + an XSLT processor (see the xsltproc + command) to realize the convertion from XML to a localize + Texinfo (or possible other) format. Nevertheless, this + workaround fails because the Document Type Definition (DTD) + required to validate the XML file produced from + makeinfo (as in + texinfo-4.8-14.el5) is not availabe inside + &TCD; (release 5.5), nor it is the XSLT files required to + realize the transformation itself for such DTD. + + + + Another similar approach to maintain localization of Texinfo + source files through gettext + procedures would be to convert Texinfo source file to DocBook + format; for who the required DTD and XSLT files are available + inside &TCD;. This way, following a procedure similar to that + one describe for XML files above, it would be possible to end + up having localized DocBook files that can be used as source + to produce localized output for both online and printing + media. However, the DocBook output produced from + makeinfo command (as in + texinfo-4.8-14.el5) isn't a valid DocBook + document according to DocBook DTDs available inside &TCD; + (release 5.5) thus provoking the validation and transformation + of such a malformed document to fail. + + + + Document Language + + The language information of those documentation manuals + produced through Texinfo documentation format is declared by + Texinfo's @documentlanguage command. This + command receives one argument refering the language code (as + in ISO-639 standard) and must be set inside the manual's main + definition file. Generally, there is no need to change the + document language declaration once it has been created by the + help functionality of + centos-art.sh script; unless you + mistakently create the manual for a locale code different to + that one you previously pretended to do in first place, of + course. + + + + The language information used in both Texinfo source files and + XHTML output produced by the help + functionality of centos-art.sh script is + determined by the user's session LANG + environment variable. This variable can be customized in the + graphical login screen before login, or once you've login by + explicitly setting the value of LANG + environment variable inside the + ~/.bash_profile file. + + + + + To create documentation manuals in English language the + LANG environment variable must be set to + en_US.UTF-8 or something similar. Likewise, if + you want to create documentation manuals in a language other + than English, be sure the LANG environment + variable is set to the appropriate locale code. + + The appropriate locale code to set here can be found in + the output produced by the locale -a | + less command. + + + + + + When producing output from Texinfo source files using the + makeinfo command (as in the + texinfo-4.8-14.el5 package), the language + information set by @documentlanguage is ignored + in Info and HTML output, but cosidered by Tex program to + redefine various English words used in the PDF output (e.g., + Chapter, Index, + See, and so on) based on the current language + set in. + + + + + + Document Encoding + + The encoding information of documentation manuals produced + through Texinfo documentation format is declared by Texinfo's + @documentencoding command and can take either + US-ASCII, ISO-8859-1, + ISO-8859-15 or ISO-8859-2 as + argument. Nevertheless, you should be aware that the + help functionality of + centos-art.sh script doesn't declare the + @documentencoding inside Texinfo source files. + Let's see why. + + + + When the @documentencoding command is set in + Texinfo source files, the terminal encoding you use to read + the Info output produced from such files must be set to that + encoding information you provided as argument to + @documentencoding command; this, before using an + Info reader to open the Info output file in the terminal. + Otherwise, when the terminal and the Texinfo source files + encoding definition differ one another, characters defined + through Texinfo's special way of producing floating accents + won't be displayed as expected (even when the + is provided to + makeinfo command). On the other hand, when + the @documentencoding command is not set in + Texinfo source files, it is possible to write and read + documentation manuals using the UTF-8 encoding without needing + to use Texinfo's special way of producing floating accents + because the terminal encoding would be able to interpret the + characters entered when the Texinfo source files were written + in first place. + + + + When Texinfo's special way of producing floating accents isn't + used, HTML entities are not produced in XHTML output produced + by texi2html, nor in the HTML output + produced by makeinfo, nor in PDF output. + In this last case, when producing PDF output, you can realize + what the floating accents are by trying to produce an + accentuated Spanish i letter (e.g., + í). When you do so, you'll note that that + construction puts the accentuation mark + over the i letter's dot, + instead of removing the i letter's dot and + put the accentuation mark on its place. In the case of XHTML + output, however, it possible to produce well localized XHTML + output by setting + + + <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> + + + on the head section of each XHTML output to instruct the web + browsers what encoding to use to display the document content. + Of course, in order to display the document content correctly, + the web browser should provide support for UTF-8 encoding. + + + + These contradictions provide the reasons over which it was + decided not to set the @documentencoding in those + Texinfo source files produced by the help + functionality of centos-art.sh script. Now, + considering them, we can conclude that it is no viable way to + localize Texinfo source files through + gettext procedures so one + documentation manual must be created for each language we + desire to support documentation for. In this configuration, + it is difficult the production of well localized PDF output, + but it is possible to produce well localized Info, Text, and + XHTML outputs as long as no document encoding be explicitly + set inside Texinfo source files and UTF-8 be used as default + terminal character encoding. + + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production.docbook new file mode 100644 index 0000000..58451f0 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production.docbook @@ -0,0 +1,12 @@ + + + Documentation Production Cycle + + &manuals-production-intro; + &manuals-production-identifying-goals; + &manuals-production-identifying-title; + &manuals-production-identifying-structure; + &manuals-production-implementing-structure; + &manuals-production-maintaining-structure; + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-goals.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-goals.docbook new file mode 100644 index 0000000..ace14cc --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-goals.docbook @@ -0,0 +1,50 @@ + + + Identifying Document Goals + + + The first step in producing a documentation manual is to + clearly understand what you exactly need to document and why + you need to do so. The obvious answer to this question would + be to describe the basic ideas behind an implementation so it + can be useful once published. It is important that you find + out the reasons you need to do what you are doing and, also, + those helping you to retain the motivation to keep doing it in + the future. Otherwise, without such foundations, you'll surely + end up leaving the effort soon enough to make a lost cause + from your initial work. + + + + Before The CentOS Artwork Repository File + System documentation manual exist, there was an + emerging need to understand what each directory inside the + growing directory layout was for, how they could be used and + how they could be connected one another. At that moment, the + directory layout was very unstable and explaining the whole + idea behind it was not possible, there were too many changing + concepts floating around which needed to be considered in the + same changing way. So, to understand what was happening, the + The CentOS Artwork Repository File + System documentation manual was created. + + + + The The CentOS Artwork Repository File + System manual was conceived based on the idea of + individually documenting each directory inside the repository + and, later, by considering all directory documentations + together, it would be (hypothetically) possible to correct the + whole idea through an improvement cycle that would consolidate + the final idea we try to implement. + + + + Other documentation manuals can be based on reasons different + from those described above, however, no matter what those + reasons be, it will be helpful to make yourself a clean idea + about what you are going to document exactly before putting + your hands on it. + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-structure.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-structure.docbook new file mode 100644 index 0000000..a8ac28b --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-structure.docbook @@ -0,0 +1,142 @@ + + Identifying Document Structure + + Once both the manual's title and the manual's directory name + have been defined, it is time for you to plan the document + structure through which the manual's content will be + organized. + + + + The document structure of documentation manuals is specific to + that documentation format used to write documentation source + files. Nevertheless, no matter what the documentation format + be, the document structure produce produced from the + help functionality of + centos-art.sh script follows and + upside-down tree configuration. In this configuration, + documentation manuals can be organized through parts, + chapters, sections, and several subsection levels based in + whether the chosen documentation format supports them or not. + + + + Considering the The CentOS Artwork Repository File + System documentation manual, we already know that + it was conceived to document each directory structure &TCAR; + is made of using Texinfo format and the sectioning levels + supported by it. At this point we phase that &TCAR; has more + levels deep than sectioning commands available inside Texinfo + formats. This way it is not possible to use one sectioning + command for each directory level inside the repository + directory structure we need to document. Based on these + issues, it is imperative to reaccomodate the document + structure in order to be able of documenting every directory + &TCAR; is made of, using the sectioning levels supported by + most documentation formats inside &TCD;, no matter how many + levels deep the repository directory structure has. + + + + As consequence, The CentOS Artwork Repository File + System ended up being organized through the + following documentation structure: + + + + + Chapter 1. The trunk + Directory + + + This chapter describes the trunk directory inside the + repository and all subdirectories inside it. The first level + of directories (i.e., the trunk directory itself) is + described inside the chapter entry. Deeper directory levels + are all documented through sections and have a file for their + own. It is also possible to write subsections and + subsubsections, however, they don't have a file for their own + as sections do. Subsections and Subsubsections should be + written as part of section files (i.e., when writting + sections). + + + + + + Chapter 2. The branches + Directory + + + This chapter describes the branches directory and all + directories inside it following the same structure described + for trunk directory + above. + + + + + + Chapter 3. The tags + Directory + + + This chapter describes the tags directory and all + directories inside it following the same structure described + for trunk directory + above. + + + + + + Appendix A. Licenses + + + This appendix is confined to organize licenses mentioned + in the manual. The content of this appendix is out of + documenatation manual scope itself and is shared among all + documentation manuals written through the + help of centos-art.sh + script inside &TCAR;. + + + + + + Index + + + This chapter organizes links to those index definitions you + defined inside the documentation manual. The index information + displayed by this chapter is auto-generated each time the + manual's output files are created so this chapter is not + editable. + + + + + + + The document structure illustrated above is also considered + the default document structure used by the + help functionality of + centos-art.sh script when you produce new + documentation manuals inside &TCAR;. In contrast with document + structure illustrated above, the default document structure + used by help functionality doesn't + include sectioning constructions like parts, chapters, + sections, subsections and the like. Such structuring + constructions should be specified by you when building the + documentation manual. The only exceptions to this restriction + are sectioning structures used to organize contents like + Index and Licenses, which are + considered inseparable components of documentation manuals + stored inside &TCAR;. + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-title.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-title.docbook new file mode 100644 index 0000000..7f71b82 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production/identifying-title.docbook @@ -0,0 +1,26 @@ + + Identifying Document Title + + Once you've make yourself an clean idea of what the + documentation manual is for and the needs behind, it is time + for you to define the manual's title and the manual's + directory name. Both manuals' title and manual's directory + name describe what the documentation manual is about. The + manual's title is used inside the documentation while the + manual's directory name is used to store the related source + files inside &TCAR; directory structure. Generally, the + manual's title is a phrase of few words and the manual's + directory name is the abbreviation of that phrase set as + manual's title. + + + + Following with our example, the manual's title chosen was + The CentOS Artwork Repository File + System and its directory name was set to + Tcar-fs to comply with the + file name convenctions described at . + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production/implementing-structure.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production/implementing-structure.docbook new file mode 100644 index 0000000..0f34347 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production/implementing-structure.docbook @@ -0,0 +1,53 @@ + + + Implementing Document Structure + + + This section describes the steps you should follow to + implement document structures like that one described in . + + + + Creating Document Structure + + + To create new documentation manuals inside &TCAR; you need to + use the help functionality of + centos-art.sh script, as shown in the + following command: + + + centos-art help --edit "manual-name" + + + The first time you execute this command, you will be prompted + to enter manual specific information like document format, + document title, document subtitle, document author, etc. Once + this information has been collected the + help functionality performs some + repository verifications and creates the manual source files + inside the manual's directory name you specified as + manual-name. + + + + When you create new documentation manuals, take care of the + locale information you are currently using. This information + is generally set in the LANG environment + variable and is used by the help + functionality of centos-art.sh script to + define the language of new documentation manual and the + document template used to build it, as well. + + + + Once the documentation structure has been created this way, + the recently created documentation manual is ready to receive + new chapters and sections as it is described in . + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production/intro.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production/intro.docbook new file mode 100644 index 0000000..5b3f328 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production/intro.docbook @@ -0,0 +1,21 @@ + + + Introduction + + + This chapter describes the procedure you should follow to + create and maintain documentation manuals inside &TCAR;. + + + + This chapter describes general concepts that can be applied + through the documentation formats supported inside the + help functionality of + centos-art.sh script. To illustrate the + production process related to documentation manuals inside + &TCAR;, this chapter uses the The CentOS Artwork + Repository File System (TCAR-FS) documentation + manual as example. + + + diff --git a/Documentation/Manuals/Tcar-ug/Manuals/Production/maintaining-structure.docbook b/Documentation/Manuals/Tcar-ug/Manuals/Production/maintaining-structure.docbook new file mode 100644 index 0000000..fcd7d83 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Manuals/Production/maintaining-structure.docbook @@ -0,0 +1,99 @@ + + + Maintaining Document Structure + + + This section describes the steps you should follow to maintain + documentation structures like that one described in . + + + + Editing Document Structure + + + + + centos-art help --edit "tcar-fs::trunk" + + + + This command creates the base structure for the + trunk chapter and opens its main definition + file with your favorite text editor so you can update the + chapter introduction. This very same procedure is used to + create branches and tags + chapters, just be sure to change the chapter field + accordingly. + + + + + + + centos-art help --edit "tcar-fs::trunk:identity" + + + + This command creates the identity section + inside the trunk chapter. If the chapter + doesn't exist it will be created first. In this command, the + identity section refers to trunk/Identity directory inside + &TCAR;. In order to document other directories, follow the + same procedure but using minus signs to separate directories. + For example, to document the trunk/Identity/Models/Themes + directory you should use the + tcar-fs::trunk:identity-models-themes + documentation entry. + + + + + In the very specific case of + TCAR-FS manual, it is also possible + to refer chapters and sections using a path/to/dir format. + For example, the reference + tcar-fs::trunk:identity-models-themes + can be also specified as trunk/Identity/Models/Themes, + in case you feel more confortable with it than the former + one. + + + + + + + + + Copying Document Structure + + ... + + + + + Deleting Document Structure + + ... + + + + + Renaming Document Structure + + ... + + + + + Updating Document Structure + + ... + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository.docbook b/Documentation/Manuals/Tcar-ug/Repository.docbook new file mode 100644 index 0000000..739870e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository.docbook @@ -0,0 +1,90 @@ + + + Repository + + + + Welcome to &TCARUG;, the official documentation of &TCAR;. + + + + This book describes the corporate visual identity of &TCP; and + the way it is produced. If you are interested in making &TCP; + a more beautiful project, this book is definitly for you. + + + + To make the information in this book managable, it has been + organized in the following parts: + + + + + + describes the convenctions you should + follow to keep everything organized and consistent inside the + repository directory structure, how to to install and + configure a working copy inside your workstation. At the end + of this part you will find a history of most relevant changes + committed to the repository along the years. + + + + + + describes the corporate visual + identity of the organization known as &TCP; and the production + tasks related to image rendition inside &TCAR;. If you are a + graphic designer, this part of the book might result + interesting to you. + + + + + + describes production tasks related to + content internationalization and localization inside &TCAR;. + If you are a translator, this part of the book might result + interesting to you. + + + + + + describes production tasks related + to content documentation inside &TCAR;. If you are a + documentor, this part of the book might result interesting to + you. + + + + + + describes automation of production + tasks inside &TCAR;. If you are a programmer, this part of the + book might result interesting to you. + + + + + + organizes the licenses mentioned + in this book. + + + + + + + This book assumes you have a basic understanding of &TCD;. If + you need help with it, go to the Help page inside + &TCWIKI; for or a list of different places you can find help. + + + + &repo-convs; + &repo-ws; + &repo-history; + + diff --git a/Documentation/Manuals/Tcar-ug/Repository.ent b/Documentation/Manuals/Tcar-ug/Repository.ent new file mode 100644 index 0000000..e0f889f --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository.ent @@ -0,0 +1,25 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions.docbook new file mode 100644 index 0000000..71f68f8 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions.docbook @@ -0,0 +1,16 @@ + + + Repository Convenctions + + &repo-convs-mission; + &repo-convs-layout; + &repo-convs-worklines; + &repo-convs-filenames; + &repo-convs-relbdirs; + &repo-convs-syncpaths; + &repo-convs-extending; + &repo-convs-publishing; + &repo-convs-authoring; + &repo-convs-copying; + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/authoring.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/authoring.docbook new file mode 100755 index 0000000..bc4d243 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/authoring.docbook @@ -0,0 +1,30 @@ + + + Repository Authoring + + + The content produced inside &TCAR; is copyright of &TCP;. + This is something you, as author, should be aware of because + you are contributing your creation's rights to someone else; + &TCP; in this case. This way, your work is distributed using + &TCP; as copyright holder, not your name (even + you remain as natural author of the work). Because &TCP; is + the copyright holder, is the license chosen by &TCP; the one + applied to your work, so it is the one you need to agree with + before making a creation inside &TCAR;. + + + + &TCP; is a community project controlled by its own community + of users. Inside the community, The CentOS Administrators + group is the higher authority and the only one able to set + core desition like the kind of license used inside the project + and subprojects like &TCAR;. + + + + The redistribution conditions of &TCAR; are described in . + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/copying.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/copying.docbook new file mode 100755 index 0000000..36658fa --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/copying.docbook @@ -0,0 +1,60 @@ + + + Repository Copying Conditions + + + &TCP; uses &TCAR; to produce &TCP; corporate visual identity. + + + + The &TCAR; is not in the public domain; it is copyrighted and + there are restrictions on their distribution, but these + restrictions are designed to permit everything that a good + cooperating citizen would want to do. What is not allowed is + to try to prevent others from further sharing any version of + this work that they might get from you. + + + + Specifically, we want to make sure that you have the right to + give away copies of &TCAR;, that you receive source code or + else can get it if you want it, that you can change this work + or use pieces of it in new free works, and that you know you + can do these things. + + + + To make sure that everyone has such rights, we have to forbid + you to deprive anyone else of these rights. For example, if + you distribute copies of the &TCAR;, you must give the + recipients all the rights that you have. You must make sure + that they, too, receive or can get the source code. And you + must tell them their rights. + + + + Also, for our own protection, we must make certain that + everyone finds out that there is no warranty for the &TCAR;. + If this work is modified by someone else and passed on, we + want their recipients to know that what they have is not what + we distributed, so that any problems introduced by others will + not reflect on our reputation. + + + + The &TCAR; is released as a GPL work. Individual packages + used by &TCAR; include their own licenses and the &TCAR; + license applies to all packages that it does not clash with. + If there is a clash between the &TCAR; license and individual + package licenses, the individual package license applies + instead. + + + + The precise conditions of the license for the &TCAR; are found + in . This manual specifically + is covered by the conditions found in . + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/extending.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/extending.docbook new file mode 100644 index 0000000..4df7761 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/extending.docbook @@ -0,0 +1,44 @@ + + + Extending Repository Layout + + + Occasionly, you may find that new components of &TCPCVI; need + to be added to the repository in order to work them out. If + that is the case, the first question we need to ask ourselves, + before starting to create directories blindly all over, is: + What is the right place to store it? + + + + To build a directory structure inside the repository you need + to define the concept behind it first. Later you need to + create a new directory inside the repository, remembering that + there are locations inside the repository that already define + concepts you probably would prefer to reuse. For example, the + trunk/Identity/Images/Themes + directory stores artistic motifs of different themes, the + trunk/Identity/Models/Themes + directory stores design models for themes, the trunk/Manuals directory stores + documentation, the trunk/Locales stores translation + messages, and the trunk/Scripts stores automation + scripts. + + + + The best suggestion we can probably give you would be to send + a mail with your questions to the CentOS developers mailing + list (centos-devel@centos.org). + This is the place where development of &TCAR; takes place and + surely, in community, it will be possible to find a place for + your new component inside the repository. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/filenames.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/filenames.docbook new file mode 100644 index 0000000..9cde7ba --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/filenames.docbook @@ -0,0 +1,23 @@ + + + Repository File Names + + + Inside &TCAR;, file names are all written in lowercase (e.g., + 01-welcome.png, + splash.png, + anaconda_header.png, etc.) and directory + names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel + case (e.g., TreeFlower, + etc.). In the very specific case of repository documentation + entries, file names follow the directory naming convenction. + This is because they are documenting directories and that is + something we want to remark. So, to better describe what we + are documenting, documentation entries follow the name + convenction used by the item they document. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/layout.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/layout.docbook new file mode 100644 index 0000000..1977365 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/layout.docbook @@ -0,0 +1,67 @@ + + + Repository Layout + + + &TCAR; is supported by Subversion, a + version control system which allows you to keep old versions + of files and directories (usually source code), keep a log of + who, when, and why changes occurred, etc., like CVS, RCS or + SCCS. + + + + &TCAR; is made of one source repository and + many working copies of that source repository. + The working copies are independent one another, can be + distributed all around the world and provide a local place for + designers, documentors, translators and programmers to perform + their work in a descentralized way. The source repository, on + the other hand, provides a central place for all independent + working copies to interchange data and provides the + information required to permit extracting previous versions of + files at any time. + + + + The first level of directories inside &TCAR; provides + organization through a convenctional trunk/, branches/ and tags/ layout. As proposition we + are assuming that: + + + + + + The trunk/ + directory is where development changes take place. + + + + + + The branches/ + directory is where maintainance changes take place. + + + + + + The tags/ directory + is where final releases take place. + + + + + + The second level of directories inside &TCAR; provides + organization for different work lines, as described in . All other subsequent + directory levels from third level on exist to organize + specific concepts related to the work line they belong to. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/mission.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/mission.docbook new file mode 100755 index 0000000..d4a2c95 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/mission.docbook @@ -0,0 +1,9 @@ + + + Repository Mission + + + &TCAR; exists to produce &TCP; corporate visual identity. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/publishing.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/publishing.docbook new file mode 100755 index 0000000..fe1447e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/publishing.docbook @@ -0,0 +1,59 @@ + + + Repository Publishing + + + When you perform changes inside your working copy, those + changes are local to your working copy only. In order for you + to share your changes with others, you need to commit them up + to the central repository the working copy you are using was + initially downloaded from. To commit your changes up to the + central repository you use the commit + command from the Subversion's client you've installed in your + workstation. + + + + Initially, when you get registered inside &TCAR;, you won't be + able to publish your changes to &TCAR; immediatly. It is + necessary that you prove your interest in contributing first + sending a mail to the CentOS + Developers mailing list (centos-devel@centos.org), + preferably in conjunction with a description of the changes + you pretend to commit. This restriction is necessary in order + to protect the source repository from spammers. + + + + Once you've received access to publish your changes, they will + remain valid to you and there is no need for you to request + permission to publish new changes as long as you behave as a + good cooperating citizen. + + + + As a good cooperating citizen one understand of a person who + respects the work already done by others and share ideas with + authors before changing relevant parts of their work, + specially in situations when the access required to realize + the changes has been granted already. Of course, there is a + time when conversation has taken place, the paths has been + traced and changing the work is so obvious that there is no + need for you to talk about it; that's because you already did, + you already built the trust to keep going. As complement, the + mailing list mentioned above is available for sharing ideas in + a way that good relationship between community citizens could + be constantly balanced. + + + + The relationship between community citizens is monitored by + repository administrators. Repository administrators are + responsible of granting that everything goes the way it needs + to go in order for &TCAR; to accomplish its mission (see ). + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/relbdirs.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/relbdirs.docbook new file mode 100644 index 0000000..d9c9474 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/relbdirs.docbook @@ -0,0 +1,121 @@ + + + Repository Path Types + + + In order for automation scripts to produce content inside a + working copy of &TCAR;, it is required that all work lines be + related somehow. The relation between work lines is used by + automation scripts to know where to retrive the information + they need to work with (e.g., input files, translation + messages, output locations, etc.). This kind of relation is + built using two path constructions known as master + paths and auxiliar paths. + + + + Master Paths + + + A master path refers to a directory inside the repository that + contain input files required to produce output files through + automation scripts. Examples of master paths inside the + repository include: + + + + + + trunk/Identity/Models/Brands + + + + + trunk/Manuals/Tcar-ug + + + + + trunk/Identity/Models/Themes/Default/Distro/5/Anaconda + + + + + + + + Auxiliar Paths + + + An auxiliar path refers to directories inside the repository + considered auxiliar for one single master path. Auxiliar path + can be either for output or localization. Assuming the master + path provides the input information, the auxiliar paths + provide the auxiliar information which describes how and where + that input information must be rendered by automation scripts. + Examples of auxiliar paths inside the repository include: + + + + + + trunk/Identity/Images/Brands + + + + + trunk/Manuals/Tcar-ug/es_ES + + + + + trunk/Locales/Manuals/Tcar-ug/es_ES + + + + + trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES + + + + + trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES + + + + + + The relationship between master and auxiliar paths is built by + combining the second directory level of master paths with + directories in the second directory level of repository + layout. In the second directory level of repository layout, + the Identity, Manuals and Scripts directories are always + used to create the master paths and the output auxiliar paths. + The Locales directory, + on the other hand, is always used to create localization + auxiliar paths for all the master paths available under + Identity, Manuals and Scripts directories. + + + + For example, if the LANG environment + variable is set to es_ES.UTF-8 and you execute + the render functionality of + centos-art.sh script with the trunk/Manuals/Tcar-ug master + path as argument, it will produce &TCARUG; in Spanish language + using translation messages from + trunk/Locales/Manuals/Tcar-ug/es_ES + auxiliar path and would save final documentation output files + under trunk/Manuals/Tcar-ug/es_ES + auxiliar path. + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/syncpaths.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/syncpaths.docbook new file mode 100644 index 0000000..c4f30aa --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/syncpaths.docbook @@ -0,0 +1,99 @@ + + + Syncronizing Repository Paths + + + Once both master and auxiliar paths have been related in the + repository, they shouldn't be changed except you absolutly + need to do so. In this cases, when you need to change master + or auxiliar paths, it is required that you also change the + relation between them so as to retain their bond. This + process of keeping master and auxiliar paths + connected between themselves is known as + path syncronization. + + + + Path syncronization is required for automation scripts to know + where to store final output, where to retrive translation + messages from, and whatever information you might need to + count with. If the relation between master paths and auxiliar + paths is lost, there is no way for automation scripts to know + where to retrive the information they need to work with or + where to store the output information produced from it. + Through path syncronization we organize and extend the content + production inside the repository. + + + + Path syncronization affects both movement of files and + replacement of content inside files. Movement of files is + related to actions like renaming files and directories inside + the repository. Replacement of content inside files is + related to actions like replacing information (e.g., paths + information) inside files in order to keep file contents and + file locations consistent one another after a file has been + moved. + + + + The order followed to syncronize path information is very + important because the versioned nature of the files we are + working with. When a renaming action needs to be performed + inside the repository, we avoid making replacements inside + files first and file movements later. This would demand two + commit actions: one for the files' internal changes and + another for the file movement itself. Instead, we prefer to + perform file movements first and files' internal replacements + later. This way it is possible to commit both changes as if + they were just one. + + + + + There is no support for URLs actions inside + centos-art.sh script. The + centos-art.sh script is designed to work + with local files inside the working copy only. If you need to + perform URL actions directly, use Subversion's commands + instead. + + + + + At this moment there isn't full implementation of path + syncronization inside centos-art.sh script + and that is somthing we need to do oursleves. However, the + texinfo backend inside the + help functionality does provide a restricted + implementation of path syncronization to documentation area + through the , + and options. You can read this + implementation and use it as reference to implement path + syncronization in other areas. + + + + The plan for a full implementation of path syncronization + inside centos-art.sh script would be to + create individual restricted implementations like the one in + texinfo backend for other areas that demand it + and then, create a higher implmentation that combines them all + as needed. This way, if we try to rename a repository + directory, the higher action can know which are all the + restricted actions that should be performed in order + to make the full path syncronization. + + + + For example, if the directory we are renaming is a master + path, it is required to syncronize the related output and + localization auxiliar paths. On the other hand, if the + directory we are renaming through full path syncronization is + an auxiliar path, it is required to determine first what is + the related master path and later, perform the syncronization + from master path to auxiliar paths as if the path provided + would be the master path not the auxiliar path. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Convenctions/worklines.docbook b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/worklines.docbook new file mode 100644 index 0000000..7daef4e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Convenctions/worklines.docbook @@ -0,0 +1,183 @@ + + + Repository Work Lines + + + The content production inside &TCAR; has been divided into + individual work lines that relate one another based on the + idea of doing one thing well. In this model, the content + produced individually by each work line is combined one + another later to achieve higher purposes (e.g., corporate + identity for &TCP;). The repository work lines, as conceived + here, provide a relaible environment for people to work + syncronized and descentralized. + + + + The action of combining work lines inside &TCAR; is known as + the corporate identity production cycle. The rest of this + section describes the work lines available in the repository + and how they fit inside the corporate identity production + cycle. + + + + + Visual Identity + + + The visual identity is the first component we work out in + order to produce a new corporate identity. Through this work + line, graphic designers create models and + motifs for all the visual manifestation &TCP; + is made of. Once design models and artistic motifs are set in + place, graphic designers use the render + functionality described in to combine both design models and artistic motifs into + final images. + + + + The main purposes of this work line is define all the visual + manifestations the &TCP; is made of and provide design models + and artistic motifs for them in order to render the set of + images required to transmit the visual style that identifies + &TCP; as unique organization. To know more about &TCPCVI;, + read . + + + + The visual identity work line takes palce in the trunk/Identity directory. + + + + + + + + Localization + + + The content localization is the second component that must be + worked out in the corporate identity production cycle. + Through this work line translators localize source files + (e.g., SVG, DocBook, Shell scripts) which are later use to + produce localized images, localized documentation and + localized automation scripts. To localize source files, + translators use + the locale functionality described in + which takes care of + retriving translatable strings from source files and provide a + consistent localization interface based on GNU + gettext multi-lingual message + production tool set and xml2po command. + + + + The main purpose of this work line is extend the visual + identity (produced in English language) to as many native + languages as possible in order for people which doesn't + understand English languague to feel more confortable with + &TCP; and its messages. To know more about the specific + localization process read . + + + + The localization work line takes palce in the trunk/Locales directory. + + + + + + + Documentation + + + The documentation work line is the third component that must + be worked out in the corporate identity production cycle. + Through this work line documentors settle down the conceptual + and practical used to edificate &TCAR;. To write + documentation, documentors use the help + functionality described in which provides a consistent interface for building + documentation through different documentation backends (e.g., + Texinfo, DocBook, LaTeX, etc.). + + + + The main purpose of this work line is describe the standard + procedures &TCAR; realies on, as well as conceive a place to + help you understand what &TCAR; is and what can you do with + it. + + + + The documentation work line takes palce in the trunk/Manuals directory. + + + + + + Packaging + + + The packaging work line is the fourth component that must be + worked out in the corporate identity production cycle. Through + this work line packager gather final images, final + translations and final documentation related to art works and + put all together inside RPM packages. For this purpose, + packagers use the pack describe in + which provides a + consistent interface for building packages inside the + repository. + + + + The main purpose of this work line is pack all the information + &TCP; requires to rebrand &TCD; according Red Hat + redistribution guidelines. + + + + The packaging work line takes palce in the trunk/Packages directory. + + + + + + + Automation + + + The automation work line is the fifth and last component that + must be worked out in the corporate identity production cycle. + This work line closes the production cycle and provides the + production standards graphic designers, documentors, + translators and packagers need to make their work consistent + and reusable. For this purpose, programmers develop the + centos-art.sh script described in . + + + + The main purpose of this work line is standardize the + interaction of work lines in a reliable way. + + + + The automation work line takes palce in the trunk/Scripts directory. + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/History.docbook b/Documentation/Manuals/Tcar-ug/Repository/History.docbook new file mode 100644 index 0000000..6f587c0 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/History.docbook @@ -0,0 +1,16 @@ + + + Repository History + + + This chapter summarizes relevant changes committed to &TCAR; + along the years. + + + &repo-history-2008; + &repo-history-2009; + &repo-history-2010; + &repo-history-2011; + &repo-history-2012; + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/History/2008.docbook b/Documentation/Manuals/Tcar-ug/Repository/History/2008.docbook new file mode 100644 index 0000000..42f6c6e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/History/2008.docbook @@ -0,0 +1,67 @@ + + + 2008's + + + &TCAR; started at The CentOS Developers + Mailing List around 2008, on a discussion about how to + automate slide images used by Anaconda (&TCD; installer). In + such discussion, Ralph + Angenendt rose up his hand to ask —Do you have + something to show?—. + + + + To answer the question, Alain Reguera + Delgado suggested a bash script which combined SVG and + SED files in order to produce PNG images in different + languages —in conjunction with the proposition of + creating a Subversion repository where translations and image + production could be distributed inside &TCC;—. + + + + Karanbir + Singh considered the idea intresting and provided the + infrastructure necessary to support the effort. This way, + &TCAS; and &TCAR; were officially created and made world wide + available. In this configuration, users were able to register + themselves and administrators were able to assign access + rights to registered users inside &TCAR;, both using a web + interface. + + + + Once &TCAR; was available, Alain Reguera Delgado uploaded the + bash script used to produce the Anaconda + slides;See Ralph Angenendt documented it very + well;See and people started to download working + copies of &TCAR; to produce slide images in their own + languages.See the following Google + search. + + + + From this time on &TCAR; has been evolving into an automated + production environment where &TCC; can conceive &TCP; + corporate visual identity. + + + + The exact changes commited to &TCAR; through history can be + found in the repository + logs so you can know the real history about it. For + those of you who just want to get a glance of changes + committed, see . + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/History/2009.docbook b/Documentation/Manuals/Tcar-ug/Repository/History/2009.docbook new file mode 100644 index 0000000..883943c --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/History/2009.docbook @@ -0,0 +1,55 @@ + + + 2009's + + + Around 2009, the rendition script was at a very rustic state + where only slide images could be produced, so it was + redesigned to extend the image production to other areas, + different from slide images. In this configuration, one SVG + file was used as input to produce a translated instance of it + which, in turn, was used to produce one translated PNG image + as output. The SVG translated instance was created through SED + replacement commands. The translated PNG image was created + from the SVG translated instance using Inkscape command-line + interface. + + + + The repository directory structure was prepared to receive the + rendition script using design templates and translation files + in the same location. There was one directory structure for + each art work that needed to be produced. In this + configuration, if you would want to produce the same art work + with a different visual style or structure, it was needed to + create a new directory structure for it because both the image + structure and the image visual style were together in the + design template. + + + + The rendition script was moved to a common place and linked + from different directory structures. There was no need to have + the same code in different directory structures if it could be + in just one place and then be linked from different locations. + + + + Corporate identity concepts began to be considered. As + referece, it was used the book "Corporate Identity" by Wally + Olins (1989) and Wikipedia + related links. This way, the rendition script main's + goal becomes to: automate the production process of + a monolithic corporate visual identity structure, based on the + mission and the release schema of The CentOS + Project. + + + + The repository directory structures began to be documented by + mean of flat text files. Later, documentation in flat text + files was moved onto LaTeX format and this way &TCARUG; was + initiated. + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/History/2010.docbook b/Documentation/Manuals/Tcar-ug/Repository/History/2010.docbook new file mode 100644 index 0000000..eb859fc --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/History/2010.docbook @@ -0,0 +1,78 @@ + + + 2010's + + + Around 2010, the rendition script changed its name from + render.sh to + centos-art.sh and became a collection of + functionalities where rendition was just one among others + (e.g., documentation and localization). + + + + The centos-art.sh was initially conceived + to automate frequent tasks inside the repository based in the + idea of Unix toolbox: to create small and specialized tools + that do one thing well. This way, functionalities inside + centos-art.sh began to be identified and + separated one another. For example, when images were rendered, + there was no need to load functionalities related to + documentation manual. This layout moved us onto common + functionalities and specific + functionalities inside + centos-art.sh script. Common + functionalities are loaded when + centos-art.sh script is initiated and are + available to specific functionalities. + + + + Suddenly, no need was found to keep all the links spreaded + around the repository in order to execute the + centos-art.sh script from different + locations. The centos-art command-line + interface was used instead. The centos-art + command-line interface is a symbolic link stored inside the + ~/bin directory + pointing to centos-art.sh script. As + default configuration, inside The CentOS Distribution, the + path to ~/bin is + included in the search path for commands (see + PATH environment variable). This way, using + the centos-art command-line interface, it + is possible to execute the centos-art.sh + script from virtually anywhere inside the workstation, just as + we frequently do with regular commands. + + + + Start using GNU getopt as default option parser inside the + centos-art.sh script. + + + + The repository directory structure was updated to improve the + implementation of corporate visual identity concepts. + Specially in the area related to themes. Having both structure + and style in the same file introduced content duplication when + producing art works. Because of this reason, they were + separated into two different directory structures: the design + models and the artistic motifs directory structures. From + this point on, the centos-art.sh was able + to produce themes as result of arbitrary combinations between + design models (structure) and artistic motifs (visual styles). + + + + In the documentation area, the documents in LaTeX format were + migrated to Texinfo format. In this configuration, each + directory structure in the repository has a documentation + entry associated in a Texinfo structure which can be read, + edited and administered (e.g., renamed, deleted and copied) + interactively through centos-art.sh script. + Additionally, the texi2html program was used to produced + customized XHTML output in conjunction with CSS from &TCW;. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/History/2011.docbook b/Documentation/Manuals/Tcar-ug/Repository/History/2011.docbook new file mode 100644 index 0000000..3dfdb68 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/History/2011.docbook @@ -0,0 +1,51 @@ + + + 2011's + + + Around 2011, the centos-art.sh script was + redesigned to start translating XML-based files (e.g., SVG and + Docbook files) through xml2po program and + shell scripts (e.g., Bash scripts) through GNU gettext tools. + This configuration provided a stronger localization interface + for graphic designers, translators and programmers. The SED + replacement files are no longer used to handle localization. + + + + The render, help and + locale functionalities consolidated + themselves as the most frequent tasks performed in &TCAR; + working copy. Additionally, the prepare + and tuneup functionalities were also + maintained as useful tasks. + + + + In the documentation area, it was introduced the + transformation of localized DocBook XML DTD instances through + the render and + locale functionalities. In this + configuration, you use locale + functionality to localize DocBook source files to your + prefered language and later, using the + render functionality, you can produce the + localized XTHML and PDF output as specified in a XSLT layer. + Unfortunly, the transformation DocBook XML -> FO -> PDF + (through PassiveTex) seems to be buggy inside CentOS 5.5, so + it was commented inside the centos-art.sh + script. Most documentation is now organized in DocBook format, + even Texinfo format remains as the only format with automated + production tasks. + + + + In the automation area, the centos-art.sh + script introduced the capability of reading configuration + files. The main goal here was moving some command-line options + from functionalities onto a more persistent medium. Most + configuration files were set to define the position of brands + inside images and documentation manual specific options. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/History/2012.docbook b/Documentation/Manuals/Tcar-ug/Repository/History/2012.docbook new file mode 100644 index 0000000..420f41f --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/History/2012.docbook @@ -0,0 +1,255 @@ + + + 2012's + + + &TCAR; development was eventually stopped at November 2011 + until July 2012 when we needed to make the + centos-art.sh script a bit more + customizable than it presently was. For example, it was + considered as a need that functionalities inside the + centos-art.sh script must be not just + conceived independent one another but reusable in different + contexts as well. + + + + + Make Localization Of <command>centos-art.sh</command> + Script Specific To Different Contexts + + + The procedure used to locale messages inside the + centos-art.sh script had to be re-designed + in order to accept such pluggable behavior into the script. We + couldn't publish unique centos-art.sh.po + and centos-art.sh.mo files because they + may contain different information in different contexts. For + example, if you are using the render and + help functionalities you only need + translation messages for them and not those from other + functionalities that may exist in the central repository but + you didn't download nor use into your working copy. + + + + One solution for this could be to have independent PO files + for each functionality of centos-art.sh + script which are combined to create the final PO and MO files + that gettext uses to retrive + translated strings when centos-art.sh + script is running. For this solution to be effective, you must + be selective about the functionalities and locales directories + you download into your working copy. For example, if you want + to use the render functionality and its locale messages only, + you must download the required directories and exclude others. + + + + + In case you don't want to be selective and download the whole + repository, the creation of the + centos-art.sh.po, + centos-art.sh.pot and + centos-art.sh.mo files will occur + automatically the first time you run the + prepare functionality (which require the + locale functionality to be available), or + later, by running the following command: + centos-art locale trunk/Scripts/Bash --update + + + + For more information about the prepare + and locale functionalities, see and respectively. + + + + + + As shown in , both + Commons and Locales + functionalities will always be required directories. The + Commons directory contains the common + functionalities and the Locales directory + contains the standard procedures you need to run in order to + build the final centos-art.sh.mo file + used by gettext to retrive + translation strings when the centos-art.sh + script is running. Remember that + centos-art.sh.pot, + centos-art.sh.po files aren't under + version control and they are built by combining each + funtionality message.po file into a PO and later a MO file. + + + + Directory structure of a rendering-only context + + Directory structure of a rendering-only context + + + +/home/centos/Projects/artwork/trunk/ +|-- Locales/ +| `-- Scripts/ +| `-- Bash/ +| `-- es_ES/ +| |-- Functions/ +| | |-- Commons/ +| | | |-- messages.po +| | | `-- messages.pot +| | |-- Locales/ +| | | |-- messages.po +| | | `-- messages.pot +| | `-- Render/ +| | |-- messages.po +| | `-- messages.pot +| |-- LC_MESSAGES/ +| | `-- centos-art.sh.mo +| |-- centos-art.sh.po +| `-- centos-art.sh.pot +`-- Scripts/ + `-- Bash/ + |-- Functions/ + | |-- Commons/ + | |-- Locales/ + | `-- Render/ + `-- centos-art.sh + + + + + + + + A practical example of using the solution described above may + be found when you are working on the corporate identity of + &TCP; and then need to start a new corporate identity project + for another organization. You want to keep the directory + structure of &TCAR; and its automation tool, the + centos-art.sh script. Your new project + requires you to introduce new functionalities to + centos-art.sh which don't fit the needs of + &TCP; (e.g., you want to introduce a + report functionality to mesure how much + connect time do you consume through your PPP internface.) or + you just want to keep the directory structure of your new + project as simple as possible. + + + + To go through this it is possible to mix specific parts of + different central repositories into one single working copy. + This is the working copy you'll use to manage your new + project. In , we + see how the Render, + Locales and Commons directories which come + from the &TCAR; has been integrated into the working copy of + your new project. + + + + Mixing automation functionalities. + + Mixing automation functionalities. + + + +/home/al/Projects/Myapp/trunk/ +|-- Locales/ +| `-- Scripts/ +| `-- Bash/ +| `-- es_ES/ +| |-- Functions/ +| | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/ +| | | |-- messages.po +| | | `-- messages.pot +| | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/ +| | | |-- messages.po +| | | `-- messages.pot +| | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ +| | | |-- messages.po +| | | `-- messages.pot +| | `-- Report/ +| | |-- messages.po +| | `-- messages.pot +| |-- LC_MESSAGES/ +| | `-- myapp.sh.mo +| |-- myapp.sh.po +| `-- myapp.sh.pot +`-- Scripts/ + `-- Bash/ + |-- Functions/ + | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/ + | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/ + | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ + | `-- Report/ + `-- myapp.sh + + + + + + + + At this point, your working copy contains files from two + different central repositories. One repository provides the + files of your new organization project and the other one + provides the files related to the render + functionality from &TCAR;. In this environment, all updates + commited to the Render, + Locales and Commons directories at &TCAR; + will be available to you too, the next time you update your + working copy. Likewise, if you change something in any of + these directories and commit your changes, your changes will + be available to poeple working in &TCAR; the next time they + update their working copies. + + + + Understanding the need of mixing different central + repositories into a single working copy is an important step + for reusing the functionalities that come with centos-art.sh + script, but it is not enough if you want to customize the + information produced by it. By default, the centos-art.sh + script uses information related to &TCP;. You probably need to + change this if you are producing images to a different + organization than &TCP;. For example, some of the information + you might need to change would be the copyright holder, + brands, domain names, mailing lists, and so forth. To change + this information you need to duplicate the file + centos-art.sh and rename it to something + else. Later, you need to edit the renamed version and change + variables inside according your needs. In , we used the name + myapp.sh instead of + centos-art.sh so the information we set + inside it could reflect the specific needs that motivated the + creation of a new project without affecting those from &TCP;. + + + + Most of the information you need to change in your duplicated + version of centos-art.sh file is + controlled by a set of read-only variables. You modify these + variables here and they will be available all along the script + execution time. For example, you can change the value of + CLI_WRKCOPY variable inside your duplicated + version of centos-art.sh to change the + absolute path you use to store your working copy. + + + + + Update DocBook Documentation Structure And Processing + + ... + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Workstation.docbook b/Documentation/Manuals/Tcar-ug/Repository/Workstation.docbook new file mode 100644 index 0000000..cf55d5e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Workstation.docbook @@ -0,0 +1,9 @@ + + + Preparing Your Workstation + + &repo-ws-intro; + &repo-ws-install; + &repo-ws-config; + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Workstation/config.docbook b/Documentation/Manuals/Tcar-ug/Repository/Workstation/config.docbook new file mode 100644 index 0000000..35b055a --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Workstation/config.docbook @@ -0,0 +1,349 @@ + + + Configuring Your Workstation + + + 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. + + + + Define Your Workplace + + 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. + + + + Different absolute paths + + 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.) + + + + + + One unique absolute path + + 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. + + + + + Different absolute paths through dynamic expansion + + 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). + + + + + Different absolute paths, dynamic expansion, symbolic + links, relative links, and environment variables + + + With this solution it is possible to store working copies of + &TCAR; on different locations inside the same workstation + without lose relation between files. Here we use the + TCAR_WORKDIR environment variable to set the location of the + working copy inside the workstation. Later the centos-art.sh + scripts uses this value as reference to determine where the + working copy is. This value is also the one used for dynamic + expansion inside design models and other similar files. In the + case of web projects where different components are required + to produce the final content, we create symbolic links between + them and use relative paths so it is possible to reuse them + and retain the relation between them in different contexts. + + + + For example, lets consider the organization of XHTML manuals + rendered from DocBook source files. When you render a DocBook + manual inside &TCAR; it creates XHTML files. This XHTML files + use images and common style sheets for better presentation. + Both of these images and styles components live outside the + XHTML structure so, in order to make them available + relatively to the XHTML structure, we created symbolic links + from the XHTML structure to the outside location where they + are in. The creation of symbolic links takes place + automatically when each DockBook manual is rendered through + centos-art.sh, which uses the value of + TCAR_WORKDIR environment variable as reference to determine + the absolute path of the working copy. + + + + Bacause absolute paths are no longer stored inside permanent + files and centos-art.sh script uses the + TCAR_WORKDIR environment variable to determine where the + working copy is stored in the workstation, it should be safe + to download working copies of &TCAR; anywhere in the + workstation. One just have to be sure that the value of + TCAR_WORKDIR environment variable does match the location of + the working copy you are using. + + + + + + + + Download Your Working Copy + + + In order to use &TCAR; you need to download a working copy + from the central repository into your workstation. To + download such working copy use the following command: + + + svn co https://projects.centos.org/svn/artwork ~/ + + + This command will create your working copy inside your home + directory, specifically in a directory named artwork. Inside this directory + you will find all the files you need to work with inside + &TCAR;. If you want to have your working copy in a location + different to that one shown above, see . + + + + 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 to render them in order to produce + the final files (e.g., images and documentation) used to + implement &TCPCVI;. + + + + + + Configure Administrative Tasks + + + 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 through 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 (e.g., + installing themes locally from the working copy for testing + purposes.). + + + + 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 your username + allowing software commands. This configuration is illustrated + in . + + + + The <filename>/etc/sudoers</filename> configuration file + + /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. +al ALL=(ALL) SOFTWARE + + + + + + + + + + Run Preparation Tool + + Once you've both downloaded a working copy from &TCAR; + and configured the sudo's configuration + file successfully, run the prepare + functionality of centos-art.sh script to + complete the configuration process using the following + command: + + + ~/artwork/trunk/Scripts/Bash/centos-art.sh prepare + + + To know more about the prepare + functionality of centos-art.sh script, see + . + + + + + Changing Your Working Copy Default Path + + By default your working copy should be store in your home + directory, specifically in the location ~/artwork. This location may not + be the final location where you want to have your working copy + in situations where you are working on several projects at the + same time or you already have a define location to organize + your projects inside your home directory. Thus, you may need + to change the default location of your working copy to a more + appropriate location. + + + + The default path to your working copy is controlled by the + TCAR_WORKDIR environment variable. This + variable is firstly defined in your personal profile after + running the prepare functionality of + centos-art.sh script. So, to change the + path of your working copy correctly, do the following: + + + + + + Create the parent directory you will use to store your working + copy. For example: + mkdir -p ~/Projects/CentOS + + + + + Move the currently downloaded working copy from ~/artwork to + your new location. For example: + mv ~/artwork ~/Projects/CentOS/ + + + + + Edit ~/.bash_profile file to set the new + location (without trailing slash) of your working copy as value + of TCAR_WORKDIR environment variable. For example: + TCAR_WORKDIR=${HOME}/Projects/CentOS/artwork + + + + + Do log out from your active user's seesion and do log in again + so the environment changes take effect. Or just update the + current environment information by running the following + command: + . ~/.bash_profile + + + + + Update internal links by running the following command: + ${TCAR_WORKDIR}/trunk/Scripts/Bash/centos-art.sh prepare --links + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Workstation/install.docbook b/Documentation/Manuals/Tcar-ug/Repository/Workstation/install.docbook new file mode 100644 index 0000000..8c0f46b --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Workstation/install.docbook @@ -0,0 +1,41 @@ + + + Installing Your Workstation + + + To install your workstation use &TCD; default configuration as + proposed by &TCD; installer. This includes default + partitioning and packages. &TCAR; is been completly develop + upon &TCD; and realies on such environment to achieve most + automation tasks. In order to get a reproducable environment, + it is convenient that you, too, use the same operating system + that we do. + + + + Supported Platforms + + + &TCAR; has been tested in the following platforms: + + + + + + The CentOS Distribution major release 5 update 5, for i386 and + i686 architectures. + + + + + + In case you be using a working copy of &TCAR; in a different + platform from those listed here, please send a mail to centos-devel@centos.org + notifying it. It is our intention to make &TCAR; as portable + as possible through different major releases of &TCD;. + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/Workstation/intro.docbook b/Documentation/Manuals/Tcar-ug/Repository/Workstation/intro.docbook new file mode 100644 index 0000000..ec285ad --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/Workstation/intro.docbook @@ -0,0 +1,27 @@ + + + Introduction + + + The workstation is the machine you use to store your working + copy of &TCAR;. The working copy is an ordinary directory + tree on your workstation, containing a collection of files + that you can edit however you wish. The working copy is your + own private work area related to &TCAR; where you perform + changes and receive changes from others. + + + + In order to make your workstation completely functional, it is + necessary that you install it and configure it to satisfy the + needs demanded by the working copy of &TCAR; you later + download in it. + + + + This chapter describes the steps you need to follow in order + to install and configure a workstation for using a working + copy of &TCAR; in all its extention. + + + diff --git a/Documentation/Manuals/Tcar-ug/Repository/introduction.docbook b/Documentation/Manuals/Tcar-ug/Repository/introduction.docbook new file mode 100644 index 0000000..a059dc5 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Repository/introduction.docbook @@ -0,0 +1,120 @@ +
+ + Overview + + + The corporations always have a corporate identity, even when + they don't take an intentional control over it. It is a choise + from the corporation to define how much control to take over + its identity. This kind of control is expensive and not all + corporations are able to maintain it. However, it is + necessary that, based on pragmatic facts, the corporation + assume an acceptable degree of compromise with its identity in + order to create a consistent idea of itself in a way that can + be progresively improved through time. + + + + During the years (2003-2009), we've seen a growing interest + inside &TCC; for helping on &TCP; development. Some people + seem to be very clear about what the project needs are and how + to maintain it being a very stable project, but others however + don't to get what &TCP; is (even it is explained time after + time) and sometimes decide to put their efforts in the wrong + direction making everything to be a waste of time and source + of distraction from what is really needed. + + + + &TCAR; phases the question What can I do for + &TCP;? by identifying different work lines you can + join in and providing automated production mechanisms that + complement one another according to each work line needs so + consistent results can be achieved inside a distributed + environment under version control. For example, consider an + environment where there are graphic designers to produce + images, documentors to produce documentation manuals (whose + can use images produced by graphic designers), programmers to + produce automation scripts (needed to standardize production + tasks) and translators to localize source files created by + graphic designers, documetors and programmers. Once such + environment has been implemented, it would be possible for + packagers to take localized images and localized documentation + from &TCAR; (through an automation script probably) to + rebrand/update the content of those packages inside &TCD; that + must include information specific to &TCP; itself (e.g., boot + loader, distribution installer, release notes, display + managers, release notes, web browsers default page, etc.). + + + + Most production tasks inside &TCAR; are focused on the files + needed to implement &TCP; corporate visual identity. + + Notice that, here, visual identity means everything + perceived through the human's visual sences (i.e., the + human eyes), but the corporate identity is a wider concept + that extends to all human senses (i.e., visibilty (eyes), + audition (ears), scent (nose), touch (fingers), and savour + (tongue)), not just that one related to visual aspects. + Nevertheless, we need to be consequent with the media + where &TCP; manifests its existence on, as described in + . + This includes everything from file edition + (e.g., text width, text indentation, line numbering, text + tabulation, etc.) up to how the web sites, distribution, and + industrial stuff (e.g., pullovers, caps, installation media, + etc.) look and feel. Notice that, more specific details like + typography, window design, icons, menu items, etc., inside + &TCD; are already covered by &TCP; upstream provider. In our + effort to be 100% binary compatible with the upstream provider + and also keeping maintainance low, we stand over those + specific details as much as possible assuming them as default. + However, if you feel brave enough (and prove your ability to + keep yourself being that way) it would be possible to open a + work line for you to maintain variants of such very specific + details inside &TCAR;. + + + + In addition to visual manifestations, there are also emotional + feelings and ethical behaviours that must be considered as + part of &TCP; corporate identity. A pleasant experience in + this area includes &TCWIKI;, specifically the way it was + conceived and administered. When the &TCWIKI; was published, + &TCP; published a list of needs with it so anyone could + contribute based on them. Not much time after that, the list + of tasks triggered some souls' motivations ruled by the good + will of initiating the translation of that content published + inside the wiki, redesigning its visual style, proposing the + TreeFlower theme for &TCD;, and reducing to zero the + contraditions of precoceived minds with respect, reason and + passion. As result of this experience, we found that &TCC; + posseses an incredible strong creative force, however, a long + path must be traveled before it can be focalized into the + right direction because: it isn't enough just telling what the + right direction is, it is also necessary to provide the + vehicles for &TCC; be able of moving through it. + + + + &TCAR; extends the feelings and ethicals behaviours from + &TCWIKI; to itself by identifying the visual manifestations + &TCP; is made of (i.e., tracing a direction) and allowing + people to develop them through standardized procedures inside + a colaborative environment (i.e., providing the vehicles). + + + + Finally, if you find yourself needing to do something for + &TCP; and &TCAR; isn't the place for it, be sure to define + what that something exactly is and also make it a community + effort so it can be validated as something useful to the + community itself. Otherwise, the effort would loose its + initial sense soon enough so as to be considered seriously. + Notice that the way these needs are described may take + different forms: they can be written and organized inside a + book, an article, or even a well documented program ;-). + + +
diff --git a/Documentation/Manuals/Tcar-ug/Scripts.docbook b/Documentation/Manuals/Tcar-ug/Scripts.docbook new file mode 100644 index 0000000..3645deb --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts.docbook @@ -0,0 +1,12 @@ + + + Automation + + + ... + + + &scripts-bash; + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts.ent b/Documentation/Manuals/Tcar-ug/Scripts.ent new file mode 100644 index 0000000..584d443 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts.ent @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash.docbook new file mode 100644 index 0000000..c3f53c3 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash.docbook @@ -0,0 +1,14 @@ + + + The Bash Script (<command>centos-art.sh</command>) + + &scripts-bash-intro; + &scripts-bash-environment; + &scripts-bash-prepare; + &scripts-bash-render; + &scripts-bash-locale; + &scripts-bash-help; + &scripts-bash-pack; + &scripts-bash-tuneup; + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/environment.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/environment.docbook new file mode 100644 index 0000000..45d81db --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/environment.docbook @@ -0,0 +1,234 @@ + + + Execution Environment + + + When you login in your computer you enter into a unique user + environment which you can customize by setting environment + variables in the ~/.bash_profile + file.To know more about environment variables, + see the bash(1) man page. This way different + users can benefit from their own environment variables to + customize the execution of centos-art.sh + script in a safe way. For example, users can use the + variables of their environments to set different locations for + their working copies of &TCAR;.See + + + + When you execute the centos-art.sh script, + you create a new environment inside the user environment which + we call the script environment. This environment inherits all + variables from the user environment and contains the variables + and functionalities defined by the script itself. If your only + interest is using the centos-art.sh script + to accomplish tasks inside the working copy, you don't need to + know the whole environment it uses, but the user environment + only. However, if your interest is improving it somehow, to + know the environment where it is run is a fundamental + knowledge you need to be armed with in order to understand + where to put the code you want to contribute inside the + script. + + + + The script environment + + The script environment + + + +------------------------------------------------------- +User environment +----|-------------------|------------------------------ +. |-- TCAR_WORKDIR |-- EDITOR . +. |-- LANG |-- HOME . +. `-- centos-art.sh `-- ... . +. ----|---------------------------------------- . +. centos-art.sh script environment . +. ----|-----------------|---------------------- . +. . |-- CLI_NAME `-- init() . . +. . |-- CLI_VERSION |-- render() . . +. . |-- CLI_BASEDIR | |-- svg() . . +. . |-- CLI_FUNCDIR | `-- docbook() . . +. . |-- CLI_TEMPDIR |-- help() . . +. . `-- ... | |-- docbook() . . +. . | `-- texinfo() . . +. . |-- locale() . . +. . `-- ... . . +. ............................................. . +....................................................... + + + + + + + + To study the environment of centos-art.sh + script, you need to consider the directory structure under + trunk/Scripts/Bash/. In + this structure each directory under Functions/ creates a new function + environment inside the script environment. You can only + execute one function environment at a time for each script + environment. In some cases, it is possible to find a + sub-function environment which takes place inside the function + environment. Such is the case of the + render functionality which produces both + images and DocBook manuals. + + + + + If you need more environment levels from sub-function + environment on, then it is a good time for you to consider the + creation of a new function environment at all. + + + + + User's Profile (<filename>~/.bash_profile</filename>) + + + Default working copy + TCAR_WORKDIR=${HOME}/artwork + + The TCAR_WORKDIR environment variable is + specific to centos-art.sh script and + controls the working copy default location in the workstation. + This variable doesn't exist just after installing your + workstation. This variable appears inside the + ~/.bash_profile file (and so in the user + environment of yours) after configuring your workstation, as + described in . + + + + + + Default execution path + PATH=$PATH:$HOME/bin + + This is the location where we store links to executable files + inside the working copy. + + + + + Default text editor + EDITOR=/usr/bin/vim + + 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 none 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 use 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 zone information is a + straight-forward task and configuration tools provided by + &TCD; do cover time correction for most of the countries + around the world, thus we don't include it to your personal + profile. + + + + In case 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. + + + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/help.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/help.docbook new file mode 100644 index 0000000..12c43c3 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/help.docbook @@ -0,0 +1,247 @@ + + + Standardizing Documentation Tasks + + + The help functionality is the interface + the centos-art.sh script provides to + standardize frequent documentation tasks, based on specific + documentation formats, as described in . + + + + Syntax + + centos-art help [OPTIONS] [DOCENTRY] + + + The DOCENTRY parameter specifies the + documentation entry you want to process. It can be provided + one or more times in the form + MANUAL:PART:CHAPTER:SECTION or + MANUAL::CHAPTER:SECTION based on whether the + manual documentation backend you are using supports + structuring through parts or not. When + DOCENTRY parameter is not provided, + &TCAR; Repository File System documentation + manual is used as default value. + + + + To determine the documentation format to use, when new + documentation manuals are created and no configuration file is + available, the help functionality request + you to enter one of the supported documentation formats and + then, uses it to create the documentation manual. Once the + documentation manual is created, the document configuration + file is available inside the manual directory structure and + used to retrive the document format information, instead. + + + + + Options + + The help functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + Supress all commit and update actions realized over files, + before and after the action itself had took place over files + in the working copy. + + + + + + + + + This option looks for KEYWORD inside the + manual specified in the documentation entry and display + related information you to read. + + + + + + + + + Edit documentation entry related to path specified by + DOCENTRY parameter. + + + The DOCENTRY parameter must point to any + directory inside the working copy. When more than one + DOCENTRY are passed as non-option + arguments to the centos-art.sh script + command-line, they are queued for further edition. The + edition itself takes place through your default text editor + (e.g., the one you specified in the EDITOR + environment variable) and the text editor opens one file at + time (i.e., the queue of files to edit is not loaded in the + text editor.). + + + + + + + + + Read documentation entry specified by + DOCENTRY path. This option is used + internally by centos-art.sh script to refer + documentation based on errors, so you can know more about them + and the causes that could have provoked them. + + + + + + + + + Update output files rexporting them from the specified backend + source files. + + + + + + + + + Duplicate documentation entries inside the working copy. + + + When documentation entries are copied, it is required to pass + two non-option parameters in the command-line. The first + non-option parameter is considered the source location and the + second one the target location. Both source location and + target location must point to a directory under the working + copy. + + + + + + + + + Delete documentation entries specified by + DOCENTRY inside the working copy. It is + possible to delete more than one documentation entry by + specifying more DOCENTRY parameters in the + command-line. + + + + + + + + + Rename documentation entries inside the working copy. + + + When documentation entries are renamed, it is required to pass + only two non-option parameters to the command-line. The first + non-option parameter is considered the source location and the + second one the target location. Both source location and + target location must point to a directory under the working + copy. + + + + + + + When documentation entries are removed (e.g., through + or + options), the help functionality takes + care of updating nodes, menus and cross references related to + documentation entries in order to keep the manual structure in + a consistent state. + + + + + Description + + ... + + + + + Environment + + ... + + + + + Authors + + The following people have worked in the + help functionality: + + + + + Alain Reguera Delgado <alain.reguera@gmail.com> + + + + + + + License + +Copyright (C) 2009-2012 The CentOS Project + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/intro.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/intro.docbook new file mode 100644 index 0000000..00ee91e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/intro.docbook @@ -0,0 +1,4 @@ + + Introduction + ... + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/locale.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/locale.docbook new file mode 100644 index 0000000..2596369 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/locale.docbook @@ -0,0 +1,285 @@ + + + Standardizing Content Localization + + + The locale functionality is the + interface the centos-art.sh script provides + to standardize localization tasks inside the working copy. + + + + Syntax + + centos-art locale [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process are stored in. This paramter can be + provided more than once in order to process more than one + directory path in a single command execution. When this + parameter is not provided, the current directory path where + the command was called from is used instead. + + + + + Options + + The locale functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + Reduce the list of files to process inside + DIRECTORY using REGEX as + pattern. You can use this option to control the amount of + files you want to locale. The deeper you go into the + directory structure the more specific you'll be about the + files you want to locale. When you cannot go deeper into the + directory structure through DIRECTORY + specification, use this option to reduce the list of files + therein. + + + + + + + + + Supress all commit and update actions realized over files, + before and after the actions themselves had took place over + files in the working copy. + + + + + + + + + This option updates both POT and PO files related to source + files. Use this option everytime you change translatable + strings inside the source files. + + + + + + + + + This option edits the portable object related to source files. + When you provide this option, your default text editor is used + to open the portable object you, as translator, need to change + in order to keep source file messages consistent with their + localized versions. In the very specific case of shell + scripts localization, this option takes care of updating the + machine object (MO) file the shell script requires to + displayed translation messages correctly when it is executed. + + + + + + + + + This option unlocalizes source files. When you provide this + option, the localization directory related to source files is + removed from the working copy in conjunction with all portable + objects and machine objects inside it. + + + + + + + + + This option suppresses machine objects creation when shell + scripts are localized. + + + + + + + + + Description + + + The localization process is very tied to the source files we + want to provide localized messages for. Inside the working + copy of &TCAR; it is possible to localize XML-based files + (e.g., SVG and Docbook) and programs written in most popular + programming languages (e.g., C, C++, C#, Shell Scripts, + Python, Java, GNU awk, PHP, etc.). + + + + The localization process initiates by retriving translatable + strings from source files. When source files are XML-based + files, the only requisite to retrive translatable strings + correctly is that they be well-formed. Beyond that, the + xml2po command takes care of everything + else. When source files are Shell script files, it is + necessary that you previously define what strings inside the + script are considered as translatable strings in order for + xgettext command to retrive them correctly. + To define translatable strings inside shell scripts, you need + to use either gettext, + ngettext, eval_gettext + or eval_ngettext command as it is following + described: + + + + + + Use the gettext command to display the + native language translation of a textual message. + + MESSAGE="`gettext "There is no entry to create."`" + + + + + Use the ngettext command to display the + native language translation of a textual message whose + grammatical form depends on a number. + + MESSAGE="`ngettext "The following entry will be created" \ + "The following entries will be created" \ + $COUNT`:" + + + + + Use the eval_gettext command to display the + native language translation of a textual message, performing + dollar-substitution on the result. Note that only shell + variables mentioned in the message will be dollar-substituted + in the result. + + MESSAGE="`eval_gettext "The location \\\"\\\$LOCATION\\\" is not valid."`" + + + + + Use the eval_ngettext command to display + the native language translation of a textual message whose + grammatical form depends on a number, performing + dollar-substitution on the result. Note that only shell + variables mentioned in messages will be dollar-substituted in + the result. + + MESSAGE="`eval_ngettext "The following entry will be created in \\\$LOCATION" \ + "The following entries will be created in \\\$LOCATION" \ + $COUNT`:" + + + + + Once translatable strings are retrived, a portable object + template (POT) file is created for storing them. Later, the + POT file is used to create a portable object (PO). The + portable object is the place where localization itself takes + place, it is the file translators edit to localize messages. + When translatable strings change inside source files, it is + necessary that you update these POT and PO files in order to + keep consistency between source file messages and their + localized versions. + + + + Inside source files, translatable strings are always written + in English language. In order to localize translatable strings + from English language to another language, you need to be sure + the LANG environment variable has been already + set to the locale code you want to localize message for or see + them printed out before running the + locale functionality of + centos-art.sh script. Localizing English + language to itself is not supported. + + + + To have a list of all locale codes you can have localized + messages for, run the following command: locale -a | + less. + + + + + Environment + + ... + + + + + Authors + + The following people have worked in the + locale functionality: + + + + + Alain Reguera Delgado <alain.reguera@gmail.com> + + + + + + + License + +Copyright (C) 2009-2012 The CentOS Project + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/pack.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/pack.docbook new file mode 100755 index 0000000..f52e18a --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/pack.docbook @@ -0,0 +1,65 @@ + + + Standardizing Packaging Tasks + + + ... + + + + Syntax + + ... + + + + + Options + + ... + + + + + Description + + ... + + + + + Environment + + ... + + + + + Authors + + ... + + + + + License + +Copyright (C) 2009-2012 The CentOS Project + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/prepare.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/prepare.docbook new file mode 100644 index 0000000..fdc9d5e --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/prepare.docbook @@ -0,0 +1,259 @@ + + + Standardizing Configuration Tasks + + + The prepare functionality is the + interface the centos-art.sh script provides + to standardize the content production tasks inside the working + copy. + + + + Syntax + + + Assuming this is the very first time you run the + centos-art command, you'll find that there + isn't such a command in your workstation. This is correct + because you haven't created the symbolic link that makes it + available in your execution path, yet. In order to make the + centos-art command available in the + execution path of your workstation, you need to run the + centos-art.sh script using its absolute + path first: + + + ~/artwork/trunk/Scripts/Bash/centos-art.sh prepare [OPTIONS] + + + Later, once the centos-art command is + available in your execution path, there is no need for you to + use any absolute path again. From this time on, you can use + the centos-art command-line interface + directly, as the following example describes: + + + centos-env prepare [OPTIONS] + + + + + Options + + + When the centos-art command is executed + with the prepare functionality, it + accepts the following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option whould have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + This option verifies packeges required by automation scripts + and installs or updates them as required. When required + packages aren't installed or need to be updated, the + centos-art uses the sudo + and yum to perform either installations or + actualizations tasks. In both cases, it is required that you + configure the /etc/sudoers configuration + file first, as discribed in . + + + + + + + + + + This option creates or updates the portable objects (PO) and + machine object (MO) used by gettext + to retrive translated strings related to + centos-art.sh script. This option calls + the locale functionality of centos-art.sh + with the option, as described in + . + + + + + + + + + This option maintains the file relation between your working + copy and configuration files inside your workstation through + symbolic links. When you provide this option, the + centos-art.sh script puts itself into your + system's execution path through its command line interface + centos-art and makes common brushes, + patterns, palettes and fonts inside the working copy, + available to applications like GIMP in order for you to make + use of them without loosing version control over them. + + + + This option removes all common fonts, brushes, patterns, and + palettes currently installed in your home directory, in order + to create a fresh installation of them all again, using the + working copy as reference. + + + + + + + + + + This option initializes image files inside the working copy. + When you provide this option, the + centos-art.sh calls the + render functionality to create images + related to each design model available in your working copy, + as described in . + + + + + + + + + This option initializes documentation files inside the working + copy. When you provide this option, the + centos-art.sh script calls both the + render and help + functionality to produce DocBook and Texinfo manuals, + respectively. + + + + + + + + + Print the name and value of some of the environment variables + used by centos-art.sh script as described + in . + + + + + + + + + Set default environment values to your personal profile + (~/.bash_profile). + + + + + + + + + Description + + + When no option is provided to prepare + functionality, the centos-art.sh script + uses the , + , + , and + options, in that order, as default + behaviour. Otherwise, if you provide any option, the + centos-art.sh script avoids its default + behaviour and executes the prepare + functionality as specified by the options you provided. + + + + Notice that it is possible for you to execute the + prepare functionality as many times as + you need to. This is specially useful when you need to keep + syncronized the relation between content produced inside your + working copy and the applications you use outside it. For + example, considering you've added new brushes to or removed + old brushes from your working copy of &TCAR;, the link + information related to those files need to be updated in the + ~/.gimp-2.2/brushes + directory too, in a way the addition/deletion change that took + place in your working copy can be reflected there, as well. + The same is true for other similar components like fonts, + patterns and palettes. + + + + + + Environment + + ... + + + + + Authors + + The following people have worked in the + prepare functionality: + + + + + Alain Reguera Delgado <alain.reguera@gmail.com> + + + + + + + License + +Copyright (C) 2009-2012 The CentOS Project + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/render.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/render.docbook new file mode 100644 index 0000000..59b1ddd --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/render.docbook @@ -0,0 +1,288 @@ + + + Standardizing Content Rendition + + + The render functionality is the interface + the centos-art.sh script provides to + standardize the content production tasks inside the working + copy. + + + + Syntax + centos-art render [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process are stored in. This paramter can be + provided more than once in order to process more than one + directory path in a single command execution. When this + parameter is not provided, the current directory path where + the command was called from is used instead. + + + + + Options + + + The render functionality accepts the + following options: + + + + + + + + This option supresses all output messages except error + messages. When this option is passed, all confirmation + requests are supressed and a possitive answer is assumed for + them, just as if the option + would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + This option reduces the list of files to process inside + DIRECTORY using REGEX as + pattern. You can use this option to control the amount of + files you want to render. The deeper you go into the + directory structure the more specific you'll be about the + files you want to render. When you cannot go deeper into the + directory structure through DIRECTORY + specification, use this option to reduce the list of files + therein. + + + + + + + + + This option supresses all commit and update actions realized + over files, before and after the action itself had took place + over files in the working copy. + + + + + + + + + This option expands the =\RELEASE=, + =\MAJOR_RELEASE=, and + =\MINOR_RELEASE= translation makers based on + NUMBER value. Notice that translation + markers here were escaped using a backslash (\) + in order to prevent their expansion. Use this option when you + need to produce release-specific contents, but no release + information can be retrived from the directory path you are + currently rendering. + + + + + + + + + This option expands the =\ARCHITECTURE=, + translation makers based on ARHC value. + Notice that translation markers here were escaped using a + backslash (\) in order to prevent their + expansion. Use this option when you need to produce + architecture-sepecific contents but no architecture + information can be retrived from the directory path you are + currently rendering. + + + + + + + + + This option specifies the name of theme model you want to use + when producing theme artistic motifs. By default, if this + option is not provided, the Default theme + model is used as reference to produce theme artistic motifs. + To know what values does the NAME variable + can have, run ls + ~/artwork/trunk/Identity/Models/Themes command. + + + + + + + + + This option lets you apply a command as post-rendition action. + In this case, the COMMAND represents the + command-line you want to execute in order to perform in-place + modifications to base-rendition output. + + + + + + + + + This option lets you apply a command as last-rendition action. + In this case, the COMMAND argument + represents the command string you want to execute in order to + perform in-place modifications to base-rendition, + post-rendition and directory-specific rendition outputs. + + + + + + + + Description + + + Inside the working copy of &TCAR;, rendition tasks take place + inside renderable directories. The rendition itself is + performed through a serie of rendition flows named + base-rendition, post-rendition, last-rendition and + directory-specific rendition. + + + + Renderable directories are convenctional locations inside the + working copy where you can find source files, output files and + auxiliar files. Source files are used to produce output files. + Auxiliar files are used to modify the way output files are + produced from source files (e.g., to produce localized + output). Auxiliar files are optionals. + + + Renderable directories are made of several directories but + only the output dirctory path is passed to + render functionality as + DIRECTORY parameter in the command-line. + The directories related to source and auxiliar files are + automatically constructed based on a directory organization + convenction. This way, the render + functionality collects all the information it needs to work + with. + + + Inside the working copy, renderable directories are divided in + two categories in a way differences between them can be + preserved. These categories are named direct + production and theme production. These + categories provide the file organization convenction the + render functionality needs, to produce + content based on rendition flows. + + + + Direct Production + + ... + + + + + Theme Production + + ... + + + + + Base Rendition Flow + + ... + + + + + Post Rendition Flow + + ... + + + + + Last Rendition Flow + + ... + + + + + Directory-Specific Rendition Flow + + ... + + + + + + + Environment + + ... + + + + + Authors + + The following people have worked in the + render functionality: + + + + + Alain Reguera Delgado <alain.reguera@gmail.com> + + + + + + + License + +Copyright (C) 2009-2012 The CentOS Project + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + + diff --git a/Documentation/Manuals/Tcar-ug/Scripts/Bash/tuneup.docbook b/Documentation/Manuals/Tcar-ug/Scripts/Bash/tuneup.docbook new file mode 100644 index 0000000..bf37edc --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/Scripts/Bash/tuneup.docbook @@ -0,0 +1,295 @@ + + + Standardizing File Maintainance + + + The tuneup functionality is the + interface the centos-art.sh script provides + to standardize the maintainance tasks related to individual + files inside the working copy. + + + + Syntax + + centos-art tuneup [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process are stored in. This paramter can be + provided more than once in order to process more than one + directory path in a single command execution. When this + parameter is not provided, the current directory path where + the command was called from is used instead. + + + + + Options + + The tuneup functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + Reduce the list of files to process inside + path/to/dir using + REGEX as pattern. You can use this + option to control the amount of files you want to tuneup. The + deeper you go into the directory structure the more specific + you'll be about the files you want to tuneup. When you cannot + go deeper into the directory structure through + path/to/dir specification, use this + option to reduce the list of files therein. + + + + + + + + + Supress all commit and update actions realized over files, + before and after the action itself had took place over files + in the working copy. + + + + + + + + Description + + + Tasks related to file maintainance are repetitive. You might + find yourself doing them time after time inside the working + copy of &TCAR;. Some of these maintainance tasks do update top + comments on shell scripts, create table of contents for web + pages, update metadata related to design models and remove + unused definitions from design models. + + + + When you execute the tuneup functionality of centos-art.sh + script, it looks for all files that match the supported + extensions (e.g., .sh, + .svg and .xhtml) in the directory + specified, builds a list with them and applies the + maintainance tasks using file extensions as reference. + + + + When shell scripts are found, the tuneup + functionality of centos-art.sh script reads a comment template + from + trunk/Scripts/Functions/Tuneup/Shell/Config/topcomment.sed + and applies it to all shell scripts found, one by one. As + result, all shell scripts will end up having the same + copyright and license information the comment template does. + + + In order for the shell script top comment template to be + applied correctly, the shell scripts you write must have the + structure described in . + + + + Shell script top-comment template. + + Shell script top-comment template. + + + + 1| #!/bin/bash + 2| # + 3| # doSomething.sh -- The function description goes here. + 4| # + 5| # Copyright + 6| # + 7| # ... + 8| # + 9| # ---------------------------------------------------------------------- +10| # $Id$ +11| # ---------------------------------------------------------------------- +12| +13| function doSomething { +14| +15| } + + + + + + + + The tuneup functionality of + centos-art.sh script replaces all lines + between the Copyright line (e.g., line 5) + and the first separator line (e.g., line 9), inclusively. + Everything else will remain immutable in the file. + + + + When scalable vector graphics are found, the tuneup + functionality reads a SVG metadata template from + trunk/Scripts/Functions/Tuneup/Svg/Config/metadata.sed + and applies it to all files found, one by one. Immediatly + after the metadata template has been applied and, before + passing to next file, all unused definition are removed from + the file, too. + + + The metadata applied by the SVG metadata template is created + dynamicaly combining the absolute path of the file being + currently modified, the workstation's date information, the + centos-art.sh script copyright holder + (e.g., =COPYRIGHT_HOLDER=) as reference and the Creative + Common Distribution-ShareAlike 3.0 License as default license + to release SVG files. + + + The elimination of unused definitions inside SVG files takes + place through Inkscape's + option, as described in its man page (e.g., man + inkscape). + + + + When HTML files are found, the tuneup + functionality of centos-art.sh script + transforms web page headings to make them accessible through a + table of contents. The table of contents is expanded in + place, wherever the <div + class="toc"></div> piece of code be in the + file. Once the table of contents has been expanded, there is + no need to put anything else in the page. You can run the + tuneup functionality everytime you update + the heading information so as to update the table of contents, + too. + + + In order for this functionality to build the table of contents + from headings, you need to put headings in just one line. The + headin level can vary from h1 to h6 + with attribute definitions accepted. Closing tag must be + present and also match the openning tag. Inside the heading + definition an anchor definition must be present with attribute + definitions accepted. The value of name + and href attributes from the anchor + element are set dynamically using the md5sum output of + combining the page location, the head- + string and the heading content itself. If any of the + components used to build the heading reference changes, you + need to run the the tuneup functionality of + centos-art.sh script in order for the + anchor elements to use the correct information. + + + For example, the headings shown in produces the table of + contents shown in . + + + + HTML heading definition. + + HTML heading definition. + + + +<h1 class="title"><a name="head-8a23b56a28dfa7277d176576f217054a">Forms</a></h1> +<h2 class="title"><a name="head-629f38bc607f2a270177106b450aeae3">Elements</a></h2> +<h2 class="title"><a name="head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a></h2> + + + + + + + + HTML table of contents definition. + + HTML table of contents definition. + + + +<div class="toc"> <p>Table of contents</p> <dl><dt><a href="#head-8a23b56a28dfa7277d176576f217054a">Forms</a> <dl><dt><a href="#head-629f38bc607f2a270177106b450aeae3">Elements</a> </dt><dt><a href="#head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a> </dt></dl> </dt></dl> </div> + + + + + + + + + Environment + + ... + + + + + Authors + + The following people have worked in the + tuneup functionality: + + + + + Alain Reguera Delgado <alain.reguera@gmail.com> + + + + + + + License + +Copyright (C) 2009-2012 The CentOS Project + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + + diff --git a/Documentation/Manuals/Tcar-ug/tcar-ug.docbook b/Documentation/Manuals/Tcar-ug/tcar-ug.docbook new file mode 100644 index 0000000..15d29c3 --- /dev/null +++ b/Documentation/Manuals/Tcar-ug/tcar-ug.docbook @@ -0,0 +1,92 @@ + + + + + %Entities; + + + + + %Identity; + + %Locales; + + %Manuals; + + %Repository; + + %Scripts; + + ]> + + + + + + The CentOS Artwork Repository + User's Guide + + + + Alain + Reguera Delgado + + + + + 2009 + 2010 + 2011 + 2012 + &TCP;. All rights reserved. + + + + + Permission is granted to copy, distribute and/or modify + this document under the terms of the GNU Free + Documentation License, Version 1.2 or any later version + published by the Free Software Foundation; with no + Invariant Sections, no Front-Cover Texts, and no + Back-Cover Texts. A copy of the license is included in + . + + + + + + 1.0 + Today + + Alain + Reguera Delgado + + + + Under development. + + + + + + + + + &preface; + &repo; + &identity; + &locales; + &manuals; + &scripts; + + + &licenses; + + diff --git a/Documentation/Manuals/Tcpi-ug/Commons.ent b/Documentation/Manuals/Tcpi-ug/Commons.ent new file mode 100755 index 0000000..f5bcdd1 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Commons.ent @@ -0,0 +1,23 @@ + + + + + + +&TC; Project"> + + +&TC; Mirrors"> +&TC; Wiki"> + + + + +The CentOS Artwork Repository"> +&TCPI; User's Guide"> diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity.docbook new file mode 100644 index 0000000..fd0139b --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity.docbook @@ -0,0 +1,16 @@ + + + Connectivity + + + + This part of the book describes how to connect your computer + to the telephone network and configure the programs required + to establish the connection through which you will transmit + data using computers. + + + + &connectivity-ppp; + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity.ent b/Documentation/Manuals/Tcpi-ug/Connectivity.ent new file mode 100644 index 0000000..c0cee7e --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity.ent @@ -0,0 +1,7 @@ + + + + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp.docbook new file mode 100644 index 0000000..018d471 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp.docbook @@ -0,0 +1,11 @@ + + + PPP + + &connectivity-ppp-overview; + &connectivity-ppp-modem; + &connectivity-ppp-server; + &connectivity-ppp-client; + &connectivity-ppp-network; + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/client.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/client.docbook new file mode 100644 index 0000000..06405e0 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/client.docbook @@ -0,0 +1,17 @@ + + + The Client Computer + + + When you are configuring the client computer, you need to + install the wvdial, pppd + and system-config-network packages. From + these packages, to configure your Modem connection, you only + need to use the interface provided by the + system-config-network package. This + interface controls configuration files related to + pppd and + wvdial programs for you. + + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/modem.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/modem.docbook new file mode 100644 index 0000000..3a168ee --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/modem.docbook @@ -0,0 +1,194 @@ + + + The Modem Device + + + In order to establish a PPP link between two computers using + the telephone line as medium for data transmission, you will + need to install and configure a modem device in each computer + you plan to connect. On the other hand, if you're planning to + use PPP to connect the same computer to different networks + simultaneously (e.g., to build a proxy between them), you will + need to install and configure one modem device for each + different network you plan to establish such simultaneous + connection in the same computer. + + + + Installing Modem Devices + + To install a modem device in the computer, you need to attach + the modem hardware to the computer and later the telephone + line to the modem hardware. To attach the modem hardware to + your computer, you need to connect the serial or USB cable + that comes from the modem hardware to the appropriate input on + your computer (whether serial or USB). To connect the modem + hardware to the telephone line, you need to unplug the cable + that connects your telephone device and plug it on the modem + device, specifically in the port reserved for data + transmission. Later, using a similar cable, you could connect + your telephone device to the modem's telephone port, so you + can realize telephone calls when no data transmition take + place through modem's data port. + + + + To be on the safe side, do everything related to hardware + installation with the computer turned off. Then, when + everthing has been put in place, turn the computer on. Once + the operating system is up and running, you can verify the + modem hardware using either the lsusb or + lspci commands, based on whether you + attached the modem device to an USB or serial port, + respectivly. These commands need to be run with + administrative privileges, thus, you probably need to do + sudo on them or login as root user in order to execute + them. For example, assuming you logged in as root user and you installed an + USB modem hardware as mentioned before, the output of + lsusb command would be similar to that + following: + + + +Bus 003 Device 001: ID 0000:0000 +Bus 001 Device 001: ID 0000:0000 +Bus 001 Device 002: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader +Bus 002 Device 001: ID 0000:0000 +Bus 005 Device 003: ID 06e0:f104 Multi-Tech Systems, Inc. +MT5634ZBA-USB MultimodemUSB (new firmware) +Bus 005 Device 001: ID 0000:0000 +Bus 005 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse +Bus 004 Device 001: ID 0000:0000 + + + + The relevant line in this output is that one mentioning the + existence of your modem. For example, Multi-Tech System, + Inc. MT5634ZBA-USB MultimodemUSB (new + firmware) + + I want to thank my friend Brians Suarez Alonso for + bringing this modem hardware to me and for his paitient, + resisting my repetitive calls at night to realize + connection tests. + + . This line confirms that your modem hardware is + supported by &TCD; and it is possible to transmit data through + it. Otherwise, if the modem you installed doesn't appear in + this list, it is probably because such hardware is not + supported by &TCD;, yet. + + + + Once you have confirmed the modem hardware has been installed + in the computer (either client or server), you need to + determine the device name the operating system assigned to it. + This information is required by programs like + mgetty and + wvdial, so they can know what + device to talk to. Assuming you've connected your modem + device through an USB port, the operating system will assign + the the /dev/ttyACM0 device file to talk + to it. On the other hand, assuming you've connected your + modem device through a serial port, the operating system will + use the /dev/ttyS0 device file to talk to + it. To be absolutly sure about what device name the operating + system assigned to your modem hardware, you can use the + lshal command from hal + package. + + + + + Configuring Modem Devices + + + Inside &TCD;, modem devices can be configured using the + system-config-network tool. This tool is a + manages modem configuration files under the + /etc/sysconfig/network-scripts and + /etc/wvdial.conf. Inside + /etc/sysconfig/network-scripts, modem + configuration files can take different file names. To identify + them you need to open the file and checking the value set on + DEVICE variable. This variable can take + values like ppp0 for the first modem device, + ppp1 for the second modem device, and so on for + other modem devices. + + + + The configuration files of modem devices may vary based on + whether the computer is acting as server, client or both. + When you configure the modem device on the server computer, + you should take care of specifying both the IP address + (IPADDR) and the network mask (NETMASK) inside the + configuration file. Otherwise, the established connection + might end up having the wrong IP information you need to + transfer data correctly through it, assuming the other end + isn't configured to specify it. When you configure the modem + device on the server computer, there is no need for you to set + any configuration related to wvdial, unless you be thinking to + make your server computer to act as a client of another server + computer. In fact, in the server computer, you can create the + modem configuration file by yourself based on the information + provided at + /usr/share/doc/initscripts-*/sysconfig.txt + + + + + When you configure the modem device on the client computer, + you don't need to take care of specifying either the IP + address or network mask because the server computer will + assign them for you. The assignment of client computer IP + address is configured by ppp daemon + when it is executed by mgetty after + an incoming call has arrived to modem's port. + + + + Modem configuration file + + Modem configuration file + + + +# Please read /usr/share/doc/initscripts-*/sysconfig.txt +# for the documentation of these parameters. +TYPE=modem +DEVICE=ppp0 +BOOTPROTO=none +ONBOOT=no +USERCTL=yes +PEERDNS=yes +AC=off +BSDCOMP=off +VJCCOMP=off +CCP=off +PC=off +VJ=off +LINESPEED=115200 +MODEMPORT=/dev/ttyACM0 +PROVIDER=ProviderName +DEFROUTE=yes +PERSIST=no +PAPNAME=faith +WVDIALSECT=ProviderName +MODEMNAME=Modem0 +DEMAND=no +IPV6INIT=no +IDLETIMEOUT=600 +NETMASK=255.255.255.0 +IPADDR=192.168.1.1 + + + + + + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/network.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/network.docbook new file mode 100644 index 0000000..7fa47ba --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/network.docbook @@ -0,0 +1,637 @@ + + + The Network Of Computers + + + This section describes how you could distribute server and + client computers to create a collaborative network. + + + + One PPP Network Of Two Computers + + + The simpliest configuration we can achieve over the telephone + network involves two computers only, where one computer would + be acting as server and another as client. In this + configuration, the client computer establishes connection to + the server to make use of internet services provided therein. + + + + When the client computer calls the server computer, the call + is attended by mgetty and then + passed to pppd for establishing a + PPP conversation between the two computers. The first thing + in a PPP conversation is the user authentication and then + (after a sucessful athentication), the IPCP conversation takes + place to set IP addresses and start data transmission over the + link recently created. In this configuration, the client + computer can set its IP address when configuring the Modem + device (see ) or + leave the server computer to assign one (assuming you are + calling a server computer). If you are configuring a server + computer, then it is necessary that you set the IP address and + netmask of the IP network you are planning to set, using the + Modem device configuration file. + + + + Configuring the IP address and netmask information inside + Modem device configuration file is very important in order to + prevent errors when transmitting data across the link. When + the the netmask information isn't set in the Modem device + configuration file, the pppd daemon on the server computer + tries to retrive such information from the client computer and + if the client computer didn't specify one either, the network + recently created would end up having a wrong information + (e.g., 255.255.255.255) which provokes + the point-to-point connection to fail when someone tries to + transfer data through it. + + +
+ One PPP network of two computers + + One PPP network of two computers + + + +Provice-A PPP Server Province-A PPP Client +--------------------------\ /-------------------------- +192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 +--------------------------/ \-------------------------- + + + + +
+ + + The + describes the simpliest configuration we can implement for a + point-to-point connection. This configuration involves two + computers only, one acting as server (the server computer) and + other acting as client (the client computer). The client + computer calls the server computer to establish a PPP + connection in order to use whatever internet service the + server computer provides. In the figure we can see that there + are two IP addresses involved (192.168.1.1 and 192.168.1.2) inside the same + newtork (255.255.255.0). + + + + This configuration might be convenient for people in the same + location, near one another. Here, the client computer + establishes connection by mean of a local telephone call and + can use whatever internet service the server computer + provides. Since the connection lifetime is limited (see ) and only two + peers can be connected at the same time (assuming only one + Modem is attached to the server computer), the implementation + of some internet services like chat may be not a practical + offer for the server computer to provide. However, internet + services like e-mail fit perfectly on this environment where + more than one client computer would be struggling among + themselves for establishing connection with the server + computer (e.g., people connect to send/receive their e-mail + messages to/from the server computer). + + + + + + One PPP Network Of Several Computers + + + Based on , it is + possible to provide an extended version including several + server computers that may communicate between themselves to + distribute data collected from client computers they serve to. + For example, consider the telephone network of a country which + is organized in provinces and each province is divided in + several municipalities. In such organization, it would be + possible to set one or more server computers for each province + and let near people to dial-up on them to use whatever + internet service they provide. Later, it could be possible + for each server computer to establish a dial-up connections + with other near server computers in order to share information + from one province to another, as it is illustrated in . + + + + When setting the IP information, it is important that each + server computer sets both IP address and IP network mask + information in the Modem device configuration file so + different IP address can be use between different server + computers. It is also important that they all be configured to + use authentication between themselves before transmitting any + data across a PPP established connection so the information + being transmitted can be protected. + + + + When making telephone calls, if someone in Province-A needs to + send a message to someone in Province-C (which is far away + from Province-A and making a telephone call there would imply + a considerable amount of money), there is no need (even it is + possible and sometimes prefered) for that person to realize a + direct telephone call from Province-A to Province-C. Instead, + that person in Province-A can send its messages to the server + computer on its province (the nearest server on its location) + making a local telephone call and then, such server computer + would take care of delivering the information using other + server computers, following the same concept of nearest + delivery. + + +
+ One PPP network of several computers + + One PPP network of several computers + + + +Provice-A PPP Server Province-A PPP Client +--------------------------\ /-------------------------- +192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 +--------------------------/ | \-------------------------- + | +Provice-B PPP Server | Province-B PPP Client +--------------------------\ | /-------------------------- +192.168.1.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.4/24 +--------------------------/ | \-------------------------- + | +Provice-C PPP Server | Province-C PPP Client +--------------------------\ | /-------------------------- +192.168.1.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.6/24 +--------------------------/ \-------------------------- + + + + +
+ + + The more distant a telephone call is, the more expensive it + is. This way, to move information from one province to + another, each server computers must be configured to send + information to the nearest province until reaching its + destination. For example, if you are in Province-A and want to + send an e-mail message to Province-D, the server computer + configured in Province-A must sed the e-mail message to + Province-B, then server in Province-B must be configured to + send such message to Province-C, and finally C to D. This is + required because making a direct call from Province-A to + Province-D would be otherwise too much expensive to pay. + + + + Since telephone calls are required to establish connections + between computers and each call costs money based on the + location and the destination, it is required to set a + convenction in how telephone calls are realized from one + server computer to another, specially if you plan to establish + connection between server computer placed on different + provices in order to exchange data between them. + + + + + + Do you make direct telephone calls to make direct data delivery? + — This configuration could be very expensive to maintain + (considering the telephone call distances), but data will be + delivered very fast to their destinations. + + + + + Do you call the nearest server computer and let it to deliver + your data to its destination? — This configuration could + be less expensive to maintain (considering the telephone call + distances), but data delivery will take much more time to + reach their destinations and there is no way to be sure it + will do. + + + + + + + Whatever calling schema be chosen, the server computers will + always talk through UUCP to transfer data from one place to + another. The server computers will operate with two IP + addresses each, unless you plan to connect one of the server + computers to a different network (Internet, maybe?). One IP + address would identify the server computer itself and the + other would identify the client computer establishing PPP + connection to the server computer. In this configuration it + is very importat that each server and client computer does + have one unique IP address. This way it would be possible to + move the information from one computer to another. Notice that + the number of PPP clients is directly related to the number of + telephone lines a server computer has configured to receive + incomming calls on. If there is only one telephone line + attached to the server computer then, only one client computer + will be able to establish connection to that server computer. + Other PPP clients will need to wait until the telephone line + gets free in order to establish connection with that server + computer. On the other hand, if the server computer has two + (or more) attached telephone lines, it would be possible to + attend incoming calls from two (or more) PPP client at the + same time. As resume, we can say that: the more telephone + lines the server computer has attached in, the more + simultaneous connections that computer will be able to + attend/realize from/to other computers. + + + + + + One PPP+Ethernet Network Of Several Computers + + + Assuming all server computers with a Modem device have also + one (or more) Ethernet interface attached (which is very + common nowadays), it would be possible to extend the + configuration described in + creating one Ethernet network for each server computer in the + configuration. For this configuration to be implemented it is + required one or more switch devices (based on the amount of + computers such network needs to have) for each ethernet + network interface a server computer has, as described in . + + +
+ One PPP+Ethernet network of several computers + + One PPP+Ethernet network of several computers + + + +Province-A PPP/ETH Server Province-A PPP Client +--------------------------\ /-------------------------- +192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 +--------------------------/ | \-------------------------- +192.168.0.1/24 | Ethernet | +---------------------|---- | + | | + +--------+ | + | Switch | | + +--------+ | + | | +---------------------|-- | +LAN1: 192.168.0.2-254/24 | +------------------------ | +Province-A ETH Clients | + | +Province-B PPP/ETH Server | Province-B PPP Client +--------------------------\ | /-------------------------- +192.168.1.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.4/24 +--------------------------/ | \-------------------------- +192.168.2.1/24 | Ethernet | +---------------------|---- | + | | + +--------+ | + | Switch | | + +--------+ | + | | +---------------------|-- | +LAN2: 192.168.2.2-254/24 | +------------------------ | +Province-B ETH Clients | + | +Province-C PPP/ETH Server | Province-C PPP Client +--------------------------\ | /-------------------------- +192.168.1.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.6/24 +--------------------------/ \-------------------------- +192.168.3.1/24 | Ethernet +---------------------|---- + | + +--------+ + | Switch | + +--------+ + | +---------------------|-- +LAN3: 192.168.3.2-254/24 +------------------------ +Province-C ETH Clients + + + + +
+ + + In this configuration, computers connected to the switch will + also be considered as client computers. It is necessary that a + coordination be implemented at time of setting IP addresses to + new server computers so no IP address be duplicated on the + computer network. The illustration above describes one main + network (192.168.1/24) which connects + all the server computers using the telephone lines as medium + for data transmission. The Modem interface connects just one + computer at a time either client or server (assuming only one + Modem device is installed and configured in + the computer acting as server). The telephone line is used by + client computers to establish PPP connections with the server + computer and by server computers to exchange data with other + server computers, as well. On the other hand, the ethernet + interface attached to each server computer let the + administrator of each server computer to connect up to 252 + computers simultaneously, assuming a class C network as shown + above be used. + + There are also class A and class B network types which can be + used to connect much more computers than a class C network + allows to. + + + + + + + + About Bridging Calls To Transfer Data + + + When the server computers call other server computers to + bridge data delivery, the server computer in, let's say, + Province-A (srv-1.a.domain.tld) will never know that there is + a server computer on Province-C (srv-1.c.domain.tld) or + Province-D (srv-1.d.domain.tld), but in Province-B + (srv-1.b.domain.tld) + only, its nearest location. So, when a message is sent from + srv-1.a.domain.tld to the server computer in + srv-1.d.domain.tld, the server computer in srv-1.a.domain.tld + contacts its nearest server computer (i.e., + srv-1.b.domain.tld) and delivers to it all messages sent to + srv-1.d.domain.tld. Later, since srv-1.b.domain.tld doesn't + know about srv-1.d.domain.tld server either, it delivers all + messages directed to srv-1.d.domain.tld to its nearest server + computer (i.e., srv-1.c.domain.tld). Later, the server + computer in srv-1.c.domain.tld, which knows about + srv-1.d.domain.tld, delivers to it all the messages it has for + it. Notice that, in order for this configuration to work, + system administrators attending the server computers must work + syncronized to garantee a well defined route for messages to + follow. Otherwise, if one of the server computers in the path + creates a route for a server computer that doesn't exist + (or doesn't define a route at all), the information will never + reach its destination when such computer is acting as a bridge + between other two server computers. + + + ++------------------------+ +------------------------+ +------------------------+ +---------------------+ +| To: bob@d.domain.tld | | To: bob@d.domain.tld | | To: bob@d.domain.tld | | Bob's mailbox | +| From: mat@a.domain.tld | | From: ana@b.domain.tld | | From: jef@c.domain.tld | | (Final destination) | +| Body: 500KB | | Body: 500KB | | Body: 500KB | | | ++---|--------------------+ +---|--------------------+ +---|--------------------+ +------------------^--+ + | | | | +----v--------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|------------------|--- +srv-1.a.domain.tld | 75Km Call | srv-1.b.domain.tld | 75Km Call | srv-1.c.domain.tld | 75Km Call | srv-1.d.domain.tld +-------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|---------------------- +relay to: | 5 min | relay to: | 10 min | relay to: | 15 min | +srv-1.b.domain.tld | 500KB | srv-1.c.domain.tld | 1.0MB | srv-1.d.domain.tld | 1.5MB | + + + + + About Directing Calls To Transfer Data + + + When the server computers make direct telephone calls (no + bridge in-between is used to transfer data), the server + computer in Province-A (srv-1.a.domain.tld) contacts the + server computer in Province-D (srv-1.d.domain.tld) making a + direct telephone call up to it. In this configuration, the + telephone call might cost more than those in a bridged + configuration where several smaller telephone calls are dialed + in-between the final server computer; or less, considering + that when server computers in a bridged configuration exchange + data they may move data accumulated from other server + computers, while a direct telephone call would transmit data + from one server computer to another without any accumulated + data from other server computers. There is no need to + overload the server computers with foreign data when each + server computer could call themselves to transfer data + directly. + + + ++------------------------+ +---------------------+ +| To: bob@d.domain.tld | | Bob's mailbox | +| From: mat@a.domain.tld | | (Final destination) | +| Body: 500KB | | | ++--|---------------------+ +------------------^--+ + | | +---v---------------------|<~~~~~~~~~~>|-------------------|--- +srv-1.a.domain.tld | 225Km Call | srv-1.d.domain.tld +-------------------------|<~~~~~~~~~~>|----------------------- +relay to: | 5 min | +srv-1.d.domain.tld | 500KB | + + + + The elapsed time in a server-to-server conversation is + directly related to the amount of data that need to be moved + from one server to another and the baud rate of the connection + established between the two Modem devices. In a direct + telephone call configuration, telephone calls could result to + be less expensive than those in bridged configurations where + server computers may accumulate traffic from other server + computers in the path. The accumulation of traffic between + server computers increases the amount of time the last server + computer in the path before the final destination needs, in + order to transmit everything to the final destination. In a + bridged telephone call configuration, server computers acting + as bridges do act as servers as well and produce their own + traffic which is added to that one already accumulated in + them from other server computers. This may provoke a heugh + traffic in a server-to-server conversation (remarkably on the + last destination before the final destination), that could be + potentially increased with each new server computer added to + the string of server computers acting as bridges one another. + + + + + + About Authenticating PPP Users + + + The client computers will need to authenticate against the + server computer each time they intend to establish a PPP + connection. The username and password required by client + computers will be public and will be rarely changed. + + + + Credentials for PPP authentication + + Credentials for PPP authentication + + + + ISP Name: projects.centos.org +ISP Phone: +53043515094 + Username: faith + Password: mail4u.2k10 + + + + + + + + The server computer provides only one telephone line available + (e.g., +53043515094) to receive incoming calls. This affects + directly the possibilities a client computer has to establish + connection with the server computer in an environment where + several client computers are struggling among themselves to + establish a dial-up connection with the server computer. To + prevent this kind of issues from happening, it is innevitable + for the server computer to provide more telephone lines for + incoming calls (at least one for each user the server computer + expects to receive incoming calls from). + + + + + + About Restricting PPP Connections + + + The server computer restricts the lifetime of established + Modem connections to 15 minutes from the establishment moment + on. Once the connection has been established, if the link is + idle for 1 minute, the server computer will also close the + established connection to free the telephone line. This + control can be implemented through the + and options + inside the pppd's configuration + file as described in . + + + + The server computer restricts the incoming calls from client + computers every night from 10:00PM to 12:00AM. Outside this + range of time, the telephone could be answered by a person, + not a computer. This control can be implemented through a cron + job and the /etc/nologin.ttyxx file; + where ttyxx represents the device name of your Modem (e.g., + /etc/nologin.ttyACM0 would prevent the + Modem device installed in /dev/ttyACM0 + from answering calls). + + + +# Activate Modem to attend incoming calls. +59 21 * * * [ -f /etc/nologin.ttyACM0 ] && /bin/rm /etc/nologin.ttyACM0 +# Deactivate Modem to prevent incoming calls from being attended. +59 23 * * * [ ! -f /etc/nologin.ttyACM0 ] && /bin/touch /etc/nologin.ttyACM0 + + + + + + About Providing Internet Services + + + The implementation of internet services which require + persistent connections (e.g., + chats) should not be considered as + a practical offer for PPP client computers. Instead, only + asynchronous services (e.g., + e-mail) should be supported for + them. This restriction is required to reduce the connection + times demanded such services. For example, consider an + environment where you establish connection with a server + computer to send/receive e-mails messages and then quickly + disconnect from it to free the telephone line so others be + able of using it. In this environment, there is no need for + you and others to be both connected at the same time to + send/receive e-mail messages to/from each other. The e-mails + sent from other person to you will be available in your + mailbox the next time you get connected to the server computer + and use your e-mail client to send/receive e-mail messages. + Likewise, you don't need to be connected to the server + computer in order to write your e-mail messages. You can + write down your messages off-line and then establish + connection once you've finished writing, just to send them out + and receive new messages that could have been probably sent to + you. + + + + Another issue related to e-mail exchange is the protocol used + to receive messages. Presently, there are two popular ways to + do this, one is through IMAP and another through POP3. When + you use IMAP protocol, e-mail messages are retained in the + server computer and aren't downloaded to client computer. + Otherwise, when you use POP3 protocol, e-mail messages are + downloaded to the client computer and removed from server + computer. Based on the resources we have and the kind of link + used by the client computer to connect the server computer, + using POP3 is rather prefered than IMAP. However both are made + available. + + + + Assuming you use IMAP protocol to read your mailbox, be aware + that you need to be connected to the server computer. Once + the connection is lost you won't be able to read your messages + (unless your e-mail client possesses a feature that let you + reading messages off-line). Moreover, you run the risk of + getting your mailbox out of space. If your mailbox gets out of + space, new messages sent to you will not be deliver to your + mailbox. Instead, they will be deferred for a period of time + (e.g., about 5 days when using + Postfix defaults) hoping you to + free the space in your mailbox to deliver them. If you don't + free space on your mailbox within this period of time, the + deferred e-mails will be bounced back to their senders and you + will never see them. On the other hand, assuming you are + using POP3 protocol to read your mailbox, you always keep your + mailbox free to receive new e-mails messages and keep them for + you until the next time you establish connection with the + server computer and download them to your client computer + using your e-mail client. + + + + The information generated inside the server computer is + isolated from Internet. This way, any information generated + inside the server computer will be available only to people + connected to the same network the server computer is connected + to. For example, don't ever expect to send/receive e-mails + to/from Internet e-mail accounts like Gmail or Yahoo, nor + visiting web sites like Google or Wikipedia either. For + this to happen, an established connection must exist first + between the server computer you are establishing connection + through and the Internet network those services are available + in. Without that link, it is not possible to direct your + requests to those sites, nor receive any response from them. + + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/overview.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/overview.docbook new file mode 100644 index 0000000..de2356f --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/overview.docbook @@ -0,0 +1,55 @@ + + + Overview + + + This chapter describes how you can use the Point-to-Point + Protocol (PPP) to create collaborative networks in situations + where the telephone network is the only medium you and your + friends have access to. With PPP you can prepare a server + computer to provide internet services for client computers + that use the telephone network as medium for data transmition. + The configuration described here can be thought as one client + computer that establishes connection to a server computer in + order to use the internet services it provides, however, based + on this concept, other configuration are also possible to + satisfy situations where more than two computers need to be + involved. + + + + The operating system used by both server and client computers + will be &TCD; release 5.5 + + Thank to my friend Manual Chavez Manzano (Manny) for + finding a way to download this release of &TCD; and bring + it to me as a gift when I was completly isolated from + Internet without any possibility of downloading it by + myself. + + . The configuration described in this book doesn't + use third party software. All the software needed in this + configuration is available inside &TCD;. In case you are + using a different operating system in your client computer, + you'll need to look the appropriate application your operating + system provides to establish PPP connections and configure it + to establish connection with the server computer described in + . Generally, the + most you need to establish connection with the server computer + is a telephone number and the credentials for authentication, + if any. + + + + In this chapter you'll find how to configure your client + computer to dial-up the server computer automatically when + client applications (e.g., e-mail clients, web browsers, etc.) + request data transmition for the server computer at a moment + where no connection has been established with it, yet. Also, + this chapter covers different considerations you could take + into account to keep the telephone line as free as possible, + so different client computers be able of establishing + connection to the same server computer as quickly as possible. + + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/policy.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/policy.docbook new file mode 100644 index 0000000..5bcef6c --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/policy.docbook @@ -0,0 +1,5 @@ + + + Usage Convenctions + + diff --git a/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/server.docbook b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/server.docbook new file mode 100644 index 0000000..57160e0 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Connectivity/Ppp/server.docbook @@ -0,0 +1,288 @@ + + + The Server Computer + + + When you are configuring the server computer, you need to + install and configure both mgetty + and pppd programs. The + mgetty program lets you attend + incoming calls and must be configured to run through + init daemon in order + to take control over the Modem device. By default, inside + &TCD; (release 5.5), mgetty isn't + configured to start with init daemon so you need to do it + yourself (see ). + Later, for attending connection requests, you need to + configure mgetty to use the + pppd program, so the Point-to-Point + Protocol (PPP) can be talked and IP packages can be exchange + between the client computer and the server computer. Later, + you need to configure pppd to + adjust it to your needs (see ). Once + you've configured both mgetty and + pppd programs, the server computer + should be ready to attend incoming calls. + + + + <package>mgetty</package> + + Taken from mgetty man page: — Mgetty + is a smart getty replacement, designed to be + used with hayes compatible data and data/fax modems. Mgetty + knows about modem initialization, manual modem answering (so + your modem doesn’t answer if the machine isn’t ready), UUCP + locking (so you can use the same device for dial-in and + dial-out). Mgetty provides very extensive logging facilities + —. + + + Before using the configuration provided here, it would be + useful for you to read the documentation provided in the + mgetty and SysVinit + packages. This will let you to understand what you are + configuring. + + + + <filename>/etc/inittab</filename> + +# Run mgetty to control a Multi-Tech (MT5634ZBA-USB) modem attached to +# `/dev/ttyAMC0' device. Incoming calls will be attended without fax +# initalization. +ACM0:2345:respawn:/sbin/mgetty -D ttyACM0 + + + + + <filename>/etc/mgetty+sendfax/login.config</filename> + +# Automatic PPP startup on receipt of LCP configure request (AutoPPP). +# mgetty has to be compiled with "-DAUTO_PPP" for this to work. +# Warning: Case is significant, AUTOPPP or autoppp won't work! +# Consult the "pppd" man page to find pppd options that work for you. +# +# NOTE: for *some* users, the "-detach" option has been necessary, +# for others, not at all. If your pppd doesn't die after hangup, try +# it. +# +# NOTE2: "debug" creates lots of debugging info. LOOK AT IT if +# things do not work out of the box, most likely it's a ppp problem! +# +# NOTE3: "man pppd" is your friend! +# +# NOTE4: max. 9 arguments allowed. +# +#/AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap login debug +/AutoPPP/ - a_ppp /usr/sbin/pppd 192.168.1.1:192.168.1.2 + + + + In this configuration, we set both local and remote IP + addresses to fix the IP information used by computers once the + PPP connection has been established. All other options are + taken from the options file (see ). If we + don't specify both local and remote IP addresses when pppd is + initialized, pppd will try to take such information from the + first Modem device you configured (e.g., ppp0) and will expect + the remote peer to provide its IP address. This situation can + introduce some contraditions (e.g., the local and remote + address may be on a different network.) that would make the + connection to fail. + + + + Another issue we might face out would be the netmask + specification of the poin-to-point network established between + the two computers. Inside the pppd-2.4.4 man page there is no + reference to the option, however, + there is a mention to it on the sample files installed with it + which is quiet confussing. It seems to be required that one of + the two computers establishing connection defines the netmask + information of the network they are creating. So, to do it on + the server computer (the one receiving calls), it is needed to + set the netmask definition in the Modem device configuration + file of it () along with the local IP address. Otherwise, even local and + remote IP addresses be specified through the pppd, the + connection will end up having the 255.255.255.255 netmask + which would let you ping the computer on the other end but + that will not last too long before it fails and iptables seems + to get very confused about it. + + + + Since we are already using pppd to attend login requests, + there is no need to invoke the + login program. So, comment the + related line as described below. + + + +#* - - /bin/login @ + + + + + + <filename>/etc/mgetty+sendfax/dialin.config</filename> + + I didn't touch this file, but you might need to. + + + + + <filename>/etc/mgetty+sendfax/mgetty.config</filename> + + I didn't touch this file, but you might need to. + + + + + + + <package>pppd</package> + + Taken from pppd man page: — PPP is the protocol used for + establishing internet links over dial-up modems, DSL + connections, and many other types of point-to-point links. + The pppd daemon works together with the kernel PPP driver to + establish and maintain a PPP link with another system (called + the peer) and to negotiate Internet Protocol (IP) addresses + for each end of the link. Pppd can also authenticate the peer + and/or supply authentication information to the peer. PPP can + be used with other network protocols besides IP, but such use + is becoming increasingly rare —. + + + + Before using the configuration provided here, it would be + useful for you to read the documentation provided in the + ppp package. This will let you to + understand what you are configuring. + + + + <filename>/etc/pppd/options</filename> + +# Enables connection debugging facilities. If this option is given, +# pppd will log the contents of all control packets sent or received +# in a readable form. The packets are logged through syslog with +# facility daemon and level debug. This information can be directed +# to a file by setting up /etc/syslog.conf appropriately (see +# syslog.conf(5)). +debug + +# Require the peer to authenticate itself before allowing network +# packets to be sent or received. This option is the default if the +# system has a default route. If neither this option nor the noauth +# option is specified, pppd will only allow the peer to use IP +# addresses to which the system does not already have a route. +auth + +# Specifies that pppd should create a UUCP-style lock file for the +# serial device to ensure exclusive access to the device. By default, +# pppd will not create a lock file. +lock + +# Specify which DNS Servers the incoming Win95 or WinNT Connection +# should use Two Servers can be remotely configured. +ms-dns 192.168.1.1 + +# If this option is given, pppd will send an LCP echo-request frame to +# the peer every n seconds. Under Linux, the echo-request is sent when +# no packets have been received from the peer for n seconds. Normally +# the peer should respond to the echo-request by sending an +# echo-reply. This option can be used with the lcp-echo-failure +# option to detect that the peer is no longer connected. +lcp-echo-interval 30 + +# If this option is given, pppd will presume the peer to be dead if n +# LCP echo-requests are sent without receiving a valid LCP echo-reply. +# If this happens, pppd will terminate the connection. Use of this +# option requires a non-zero value for the lcp-echo-interval +# parameter. This option can be used to enable pppd to terminate +# after the physical connection has been broken (e.g., the modem has +# hung up) in situations where no hardware modem control lines are +# available. +lcp-echo-failure 4 + +# Specifies that pppd should disconnect if the link is idle for n +# seconds. +idle 60 + +# Specifies that pppd should disconnect if the link have been active +# for n seconds. +maxconnect 900 + +# Disable the IPXCP and IPX protocols. +noipx + + + + + <filename>/etc/pppd/cha-secrets</filename> + +# Secrets for authentication using CHAP +# client server secret IP addresses + +# Specify the client configuration. This is when this manchine calls +# someone's else machine and tries to establish a point-to-point +# connection. Most of this configuration is handled by the +# `system-config-network' utility. +# +####### redhat-config-network will overwrite this part!!! (begin) ########## +####### redhat-config-network will overwrite this part!!! (end) ############ + +# Specify the server configuration. This is when someone's else +# machine calls this machine trying to establish a point-to-point +# connection. This part of the configuration isn't handled by +# `system-config-network' utility. By default, there is one line to +# verify client's identity with authenticating it and one line to let +# the server computer to authenticate itself with the client computer +# in case the client computer requires so. All client computers will +# be authenticated through the `faith' user. However, it is possible +# to provide anonymous authentication to client computers by using an +# empty client identity (as explained in pppd's man page) in order to +# restrict the IP address they can use. +# +"faith" "projects" "mail4u.2k10" "192.168.1.2" +#"" "projects" "" "192.168.1.2" +"projects" * "mail4u.2k10" + + + + Assuming the hostname of the server computer is + projects, when a client computer uses the faith + username to login on it, the 192.168.1.2 IP address will be + assigned to that client computer after a successful + authentication. This configuration is just for one Modem + device attached to the server computer. In case you have more + than one Modem device attached to the server computer, it + would be necessary to add one username for each Modem device + you have, in order to permit the client computers to connect + simultaneously. It is not possible to have two or more + computers with the same IP address in the same network. + + + + + + <filename>/etc/pppd/pap-secrets</filename> + + This file contains the same information of + cha-secrets file does. See . + + + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Licenses.docbook b/Documentation/Manuals/Tcpi-ug/Licenses.docbook new file mode 100755 index 0000000..bcb5cec --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Licenses.docbook @@ -0,0 +1,7 @@ + + + Licenses + + &licenses-gfdl; + + diff --git a/Documentation/Manuals/Tcpi-ug/Licenses.ent b/Documentation/Manuals/Tcpi-ug/Licenses.ent new file mode 100755 index 0000000..dd7f27a --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Licenses.ent @@ -0,0 +1,2 @@ + + diff --git a/Documentation/Manuals/Tcpi-ug/Licenses/gfdl.docbook b/Documentation/Manuals/Tcpi-ug/Licenses/gfdl.docbook new file mode 100755 index 0000000..33f6e8c --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Licenses/gfdl.docbook @@ -0,0 +1,591 @@ + + + GNU Free Documentation License + + Version 1.2, November 2002 + + Copyright © 2000, 2001, 2002 Free Software Foundation, + Inc. 675 Mass Ave, Cambridge, MA 02139, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + Preamble + + The purpose of this License is to make a manual, + textbook, or other functional and useful document + free in the sense of freedom: to assure + everyone the effective freedom to copy and redistribute it, + with or without modifying it, either commercially or + noncommercially. Secondarily, this License preserves for the + author and publisher a way to get credit for their work, while + not being considered responsible for modifications made by + others. + + This License is a kind of copyleft, which + means that derivative works of the document must themselves be + free in the same sense. It complements the , which is a copyleft license + designed for free software. + + We have designed this License in order to use it for + manuals for free software, because free software needs free + documentation: a free program should come with manuals + providing the same freedoms that the software does. But this + License is not limited to software manuals; it can be used for + any textual work, regardless of subject matter or whether it + is published as a printed book. We recommend this License + principally for works whose purpose is instruction or + reference. + + + + + + Applicability and definitions + + This License applies to any manual or other work, in any + medium, that contains a notice placed by the copyright holder + saying it can be distributed under the terms of this License. + Such a notice grants a world-wide, royalty-free license, + unlimited in duration, to use that work under the conditions + stated herein. The Document, below, refers to + any such manual or work. Any member of the public is a + licensee, and is addressed as you. You accept + the license if you copy, modify or distribute the work in a + way requiring permission under copyright law. + + A + Modified Version of the Document means any work + containing the Document or a portion of it, either copied + verbatim, or with modifications and/or translated into another + language. + + A + Secondary Section is a named appendix or a + front-matter section of the Document that deals exclusively + with the relationship of the publishers or authors of the + Document to the Document's overall subject (or to related + matters) and contains nothing that could fall directly within + that overall subject. (Thus, if the Document is in part a + textbook of mathematics, a may not explain any mathematics.) The relationship could be + a matter of historical connection with the subject or with + related matters, or of legal, commercial, philosophical, + ethical or political position regarding them. + + The Invariant Sections are certain + whose titles are + designated, as being those of Invariant Sections, in the + notice that says that the Document is released under this + License. If a section does not fit the above definition of + Secondary then it is not allowed to be designated as + Invariant. The Document may contain zero Invariant Sections. + If the Document does not identify any Invariant Section then + there are none. + + The + Cover Texts are certain short passages of text + that are listed, as Front-Cover Texts or Back-Cover Texts, in + the notice that says that the Document is released under this + License. A Front-Cover Text may be at most 5 words, and a + Back-Cover Text may be at most 25 words. + + A + Transparent copy of the Document means a + machine-readable copy, represented in a format whose + specification is available to the general public, that is + suitable for revising the document straightforwardly with + generic text editors or (for images composed of pixels) + generic paint programs or (for drawings) some widely available + drawing editor, and that is suitable for input to text + formatters or for automatic translation to a variety of + formats suitable for input to text formatters. A copy made in + an otherwise file format whose + markup, or absence of markup, has been arranged to thwart or + discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of + text. A copy that is not is called Opaque. + + Examples of suitable formats for copies + include plain ASCII without markup, Texinfo input format, + LaTeX input format, SGML or XML using a publicly available + DTD, and standard-conforming simple HTML, PostScript or PDF + designed for human modification. Examples of transparent + image formats include PNG, XCF and JPG. Opaque formats + include proprietary formats that can be read and edited only + by proprietary word processors, SGML or XML for which the DTD + and/or processing tools are not generally available, and the + machine-generated HTML, PostScript or PDF produced by some + word processors for output purposes only. + + The Title + Page means, for a printed book, the title page itself, + plus such following pages as are needed to hold, legibly, the + material this License requires to appear in the title page. + For works in formats which do not have any title page as such, + Title Page means the text near the most + prominent appearance of the work's title, preceding the + beginning of the body of the text. + + A section Entitled XYZ means a named + subunit of the Document whose title either is precisely XYZ or + contains XYZ in parentheses following text that translates XYZ + in another language. (Here XYZ stands for a specific section + name mentioned below, such as Acknowledgements, + Dedications, Endorsements, or + History.) To Preserve the Title + of such a section when you modify the Document means that it + remains a section Entitled XYZ according to + this definition. + + The Document may include Warranty Disclaimers next to + the notice which states that this License applies to the + Document. These Warranty Disclaimers are considered to be + included by reference in this License, but only as regards + disclaiming warranties: any other implication that these + Warranty Disclaimers may have is void and has no effect on the + meaning of this License. + + + + + + Verbatim copying + + You may copy and distribute the Document in any medium, + either commercially or noncommercially, provided that this + License, the copyright notices, and the license notice saying + this License applies to the Document are reproduced in all + copies, and that you add no other conditions whatsoever to + those of this License. You may not use technical measures to + obstruct or control the reading or further copying of the + copies you make or distribute. However, you may accept + compensation in exchange for copies. If you distribute a + large enough number of copies you must also follow the + conditions in section . + + You may also lend copies, under the same conditions + stated above, and you may publicly display copies. + + + + + + Copying in quantity + + If you publish printed copies (or copies in media that + commonly have printed covers) of the Document, numbering more + than 100, and the Document's license notice requires Cover + Texts, you must enclose the copies in covers that carry, + clearly and legibly, all these : + Front-Cover Texts on the front cover, and Back-Cover Texts on + the back cover. Both covers must also clearly and legibly + identify you as the publisher of these copies. The front + cover must present the full title with all words of the title + equally prominent and visible. You may add other material on + the covers in addition. Copying with changes limited to the + covers, as long as they preserve the title of the Document and + satisfy these conditions, can be treated as verbatim copying + in other respects. + + If the required texts for either cover are too + voluminous to fit legibly, you should put the first ones + listed (as many as fit reasonably) on the actual cover, and + continue the rest onto adjacent pages. + + If you publish or distribute Opaque copies of the + Document numbering more than 100, you must either include a + machine-readable copy along with each Opaque copy, + or state in or with each Opaque copy a computer-network + location from which the general network-using public has + access to download using public-standard network protocols a + complete copy of the Document, free of added + material. If you use the latter option, you must take + reasonably prudent steps, when you begin distribution of + Opaque copies in quantity, to ensure that this + copy will remain thus accessible at the stated location until + at least one year after the last time you distribute an Opaque + copy (directly or through your agents or retailers) of that + edition to the public. + + It is requested, but not required, that you contact the + authors of the Document well before redistributing any large + number of copies, to give them a chance to provide you with an + updated version of the Document. + + + + + + Modifications + + You may copy and distribute a of the Document under the + conditions of sections and above, + provided that you release the under precisely this License, with the filling the role of the + Document, thus licensing distribution and modification of the + to whoever possesses a + copy of it. In addition, you must do these things in the + : + + + + + Use in the (and on + the covers, if any) a title distinct from that of the + Document, and from those of previous versions (which + should, if there were any, be listed in the History + section of the Document). You may use the same title + as a previous version if the original publisher of + that version gives permission. + + + List on the , as + authors, one or more persons or entities responsible + for authorship of the modifications in the , together with at least + five of the principal authors of the Document (all of + its principal authors, if it has fewer than five), + unless they release you from this requirement. + + + + State on the the + name of the publisher of the , as the + publisher. + + + + Preserve all the copyright notices of the + Document. + + + + Add an appropriate copyright notice for your + modifications adjacent to the other copyright + notices. + + + + Include, immediately after the copyright + notices, a license notice giving the public permission + to use the under the terms of this + License, in the form shown in the Addendum + below. + + + + Preserve in that license notice the full lists + of and required + given in the Document's + license notice. + + + + Include an unaltered copy of this License. + + + + Preserve the section Entitled + History, Preserve its Title, and add to + it an item stating at least the title, year, new + authors, and publisher of the as given on the . If there is no section + Entitled History in the Document, create + one stating the title, year, authors, and publisher of + the Document as given on its , then add an item describing the as stated in the previous + sentence. + + + + Preserve the network location, if any, given in + the Document for public access to a copy of the Document, and + likewise the network locations given in the Document + for previous versions it was based on. These may be + placed in the History section. You may + omit a network location for a work that was published + at least four years before the Document itself, or if + the original publisher of the version it refers to + gives permission. + + + + For any section Entitled + Acknowledgements or + Dedications, Preserve the Title of the + section, and preserve in the section all the substance + and tone of each of the contributor acknowledgements + and/or dedications given therein. + + + + Preserve all the of the Document, + unaltered in their text and in their titles. Section + numbers or the equivalent are not considered part of + the section titles. + + + + Delete any section Entitled + Endorsements. Such a section may not + be included in the . + + + + Do not retitle any existing section to be + Entitled Endorsements or to conflict in + title with any . + + + Preserve any Warranty Disclaimers. + + + + + If the includes new + front-matter sections or appendices that qualify as and contain no material copied + from the Document, you may at your option designate some or + all of these sections as invariant. To do this, add their + titles to the list of in the 's license notice. These titles + must be distinct from any other section titles. + + You may add a section Entitled + Endorsements, provided it contains nothing but + endorsements of your by various + parties–for example, statements of peer review or that + the text has been approved by an organization as the + authoritative definition of a standard. + + You may add a passage of up to five words as a + Front-Cover Text, and a passage of up to 25 words as a + Back-Cover Text, to the end of the list of in the . Only one passage of + Front-Cover Text and one of Back-Cover Text may be added by + (or through arrangements made by) any one entity. If the + Document already includes a cover text for the same cover, + previously added by you or by arrangement made by the same + entity you are acting on behalf of, you may not add another; + but you may replace the old one, on explicit permission from + the previous publisher that added the old one. + + The author(s) and publisher(s) of the Document do not by + this License give permission to use their names for publicity + for or to assert or imply endorsement of any . + + + + + + Combining documents + + You may combine the Document with other documents + released under this License, under the terms defined in + section above for + modified versions, provided that you include in the + combination all of the of + all of the original documents, unmodified, and list them all + as of your combined work + in its license notice, and that you preserve all their + Warranty Disclaimers. + + The combined work need only contain one copy of this + License, and multiple identical may be replaced with a single + copy. If there are multiple with the same name but + different contents, make the title of each such section unique + by adding at the end of it, in parentheses, the name of the + original author or publisher of that section if known, or else + a unique number. Make the same adjustment to the section + titles in the list of in + the license notice of the combined work. + + In the combination, you must combine any sections + Entitled History in the various original + documents, forming one section Entitled + History; likewise combine any sections Entitled + Acknowledgements, and any sections Entitled + Dedications. You must delete all sections + Entitled Endorsements. + + + + + + Collection of documents + + You may make a collection consisting of the Document and + other documents released under this License, and replace the + individual copies of this License in the various documents + with a single copy that is included in the collection, + provided that you follow the rules of this License for + verbatim copying of each of the documents in all other + respects. + + You may extract a single document from such a + collection, and distribute it individually under this License, + provided you insert a copy of this License into the extracted + document, and follow this License in all other respects + regarding verbatim copying of that document. + + + + + + Aggregation with independent works + + A compilation of the Document or its derivatives with + other separate and independent documents or works, in or on a + volume of a storage or distribution medium, is called an + aggregate if the copyright resulting from the + compilation is not used to limit the legal rights of the + compilation's users beyond what the individual works permit. + When the Document is included in an aggregate, this License + does not apply to the other works in the aggregate which are + not themselves derivative works of the Document. + + If the Cover Text requirement of section is applicable to these + copies of the Document, then if the Document is less than one + half of the entire aggregate, the Document's may be placed on covers that bracket + the Document within the aggregate, or the electronic + equivalent of covers if the Document is in electronic form. + Otherwise they must appear on printed covers that bracket the + whole aggregate. + + + + + + Translations + + Translation is considered a kind of modification, so you + may distribute translations of the Document under the terms of + section . Replacing + with translations + requires special permission from their copyright holders, but + you may include translations of some or all in addition to the original + versions of these . You + may include a translation of this License, and all the license + notices in the Document, and any Warranty Disclaimers, + provided that you also include the original English version of + this License and the original versions of those notices and + disclaimers. In case of a disagreement between the + translation and the original version of this License or a + notice or disclaimer, the original version will + prevail. + + If a section in the Document is Entitled + Acknowledgements, Dedications, + or History, the requirement (section ) to Preserve its Title + (section ) will + typically require changing the actual title. + + + + + + Termination + + You may not copy, modify, sublicense, or distribute the + Document except as expressly provided for under this License. + Any other attempt to copy, modify, sublicense or distribute + the Document is void, and will automatically terminate your + rights under this License. However, parties who have received + copies, or rights, from you under this License will not have + their licenses terminated so long as such parties remain in + full compliance. + + + + + + Future Revisions of this License + + The Free Software Foundation may publish new, revised + versions of the GNU Free Documentation License from time to + time. Such new versions will be similar in spirit to the + present version, but may differ in detail to address new + problems or concerns. See . + + Each version of the License is given a distinguishing + version number. If the Document specifies that a particular + numbered version of this License or any later + version applies to it, you have the option of + following the terms and conditions either of that specified + version or of any later version that has been published (not + as a draft) by the Free Software Foundation. If the Document + does not specify a version number of this License, you may + choose any version ever published (not as a draft) by the Free + Software Foundation. + + + + + + How to use this License for your documents + + To use this License in a document you have written, + include a copy of the License in the document and put the + following copyright and license notices just after the title + page: + + +Copyright (C) YEAR YOUR NAME. + +Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, +Version 1.2 or any later version published by the Free Software +Foundation; with no Invariant Sections, no Front-Cover Texts, and +no Back-Cover Texts. A copy of the license is included in the +section entitled GNU Free Documentation License. + + + If you have , + Front-Cover Texts and Back-Cover Texts, replace the + with...Texts. line with this: + + +with the Invariant Sections being LIST THEIR TITLES, with the +Front-Cover Texts being LIST, and with the Back-Cover Texts being +LIST. + + + If you have + without , or some other + combination of the three, merge those two alternatives to suit + the situation. + + If your document contains nontrivial examples of program + code, we recommend releasing these examples in parallel under + your choice of free software license, such as the GNU General + Public License, to permit their use in free software. + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Preface.docbook b/Documentation/Manuals/Tcpi-ug/Preface.docbook new file mode 100755 index 0000000..3291a2b --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Preface.docbook @@ -0,0 +1,69 @@ + + + Preface + + + Welcome to &TCPIUG;. + + + + This book describes how you can configure &TCD; to use the + telephone network as physical medium for data transmission + using computers, so you can create your own collaborative + networks to share information with your friends in freedom. + + + + To implement the configuration described in this book, you + need two or more computers connected to the telephone network + of your country by mean of modem devices. Optionally, you + could use Ethernet devices (e.g., switches) to create local + area networks (LANs) on both ends of each connection + established over the telephone network for sharing information + between them. For example, consider an infrastructure where + you have one LAN for each province in your country and then, + each of these LANs is connected one another to share + information between them using the country's telephone + network. This infrastructure would be as expensive as + telephone calls and consume of electrical power required by + computers and communication devices would be. + + + + To make the information of this book managable, it has been + organized in the following parts: + + + + + + describes how to configure + server and client computers to transfer IP packages through + the telephone network. This is the first step you need to + setup in order to use the internet services described in . + + + + + describes how to configure server + and client computers to exchange information using internet + services over the telephone network. Once you complete this + part of the book, your collaborative network should be ready + for production. + + + + + describes the lincense documents + mentioned in this book so you can know what you can and cannot + do with the information provided in this book. + + + + + &preface-overview; + &preface-docconvs; + &preface-feedback; + + diff --git a/Documentation/Manuals/Tcpi-ug/Preface.ent b/Documentation/Manuals/Tcpi-ug/Preface.ent new file mode 100755 index 0000000..263be1d --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Preface.ent @@ -0,0 +1,4 @@ + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Preface/docconvs.docbook b/Documentation/Manuals/Tcpi-ug/Preface/docconvs.docbook new file mode 100755 index 0000000..1c2da7b --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Preface/docconvs.docbook @@ -0,0 +1,68 @@ +
+ + Document Convenctions + + + In this manual, certain words are represented in different + fonts, typefaces, sizes, and weights. This highlighting is + systematic; different words are represented in the same style + to indicate their inclusion in a specific category. The types + of words that are represented this way include the + following: + + + + + + ... + + + + + + Additionally, we use several different strategies to draw your + attention to certain pieces of information. In order of + urgency, these items are marked as a note, tip, important, + caution, or warning. For example: + + + + + Remember that Linux is case sensitive. In other words, a + rose is not a ROSE is not a rOsE. + + + + + + The directory /usr/share/doc/ contains + additional documentation for packages installed on your + system. + + + + + + If you modify the DHCP configuration file, the changes do + not take effect until you restart the DHCP daemon. + + + + + + Do not perform routine tasks as root — use a regular + user account unless you need to use the root account for + system administration tasks. + + + + + + Be careful to remove only the necessary partitions. + Removing other partitions could result in data loss or a + corrupted system environment. + + + +
diff --git a/Documentation/Manuals/Tcpi-ug/Preface/feedback.docbook b/Documentation/Manuals/Tcpi-ug/Preface/feedback.docbook new file mode 100755 index 0000000..c532212 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Preface/feedback.docbook @@ -0,0 +1,14 @@ +
+ + Send In Your Feedback + + + If you find a bug in this manual, we would like to hear about + it. To report bugs related to this manual, send an e-mail to + the docs@projects.centos.org mailing list + specifying the manual name, the section where you found the + bug, why you considered it a bug and anything that help us to + identify where the problem is exactly. + + +
diff --git a/Documentation/Manuals/Tcpi-ug/Preface/overview.docbook b/Documentation/Manuals/Tcpi-ug/Preface/overview.docbook new file mode 100755 index 0000000..027aef8 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Preface/overview.docbook @@ -0,0 +1,399 @@ +
+ + Overview + + + Since 1999, I've been working for cuban State as Webmaster and + lately as system administrator. On April 2009, I decided to + stop working for cuban State due the increasing feeling of + repression I experimented with the restrictions impossed by + cuban State in the information area when I tried to find an + alternative way to express myself different from what such + restrictions impossed. This environment made me find that the + cuban political system lacks of such independent alternatives + for cubans to use. I don't pretend to use this book to detail + the political system I live on, but I do want to say that the + more I got involved with the cuban political system the more + distance I felt between the most pure of myself and the + actions the system expected from me to do as system + administrator, and what could be an alternative way for cubans + inside the island that, like me, feel the same need of + independent expression. + + + + Everything in the human life is directly related to + information. Our actions are based on the information we have. + The information is the base of education and evolution. It is + the only way we can know how to do the right thing for us and + others. I beleive that, in order to provide a good education, + the universal information must be accessable to everyone in a + transparent way, based on facts and without any manipulation + (i.e., in way others can reproduce or verify what the + information refers to). That kind of information is good + information to based our lives on. However, there are also bad + information that we need to differentiate from good + information using our own conscience, not that one from + others. I like the idea of structuring my life over pragmatic + fatcs that I can verify together with a deep faith on what I + am that help me to persist along the duty. The pragmatic fatcs + provides the steps of the stair of my life and the faith, the + force my body needs to climb up the stair. + + + + The years I worked for cuban State coincided with those years + I began to realized myself about the steps of my stair and the + faith on my movements. Lot of contradictions have been + appearing in front of me since then, but a magical thing + inside me (conscience) always tell me not to abandon the must + pure of my self and keep going with this travel I'm still + walking on; even when moving up one step in the stair feels + like rasping the skin of my body against a rough wall. I know + it will heal, but it hurts when happens. The only way to + support the pain is to have faith on the rightness of your + actions. That's the price of don't loosing oneself when + walking over pragmatic facts in a confussed and unarmed + society. That's the price of showing out that truth is inside + us, not outside us. It is the way of showing the truth is in + the one's faith, no matter what it be, but in feeling it + somehow, specially when it comes from understanding what we + are and the immense gift it is to have conscience of our + univeral existence as part of that unknown nature we, as + living humans, cannot ever have conscience of. + + + + I've experimented faith in free software and the philosophy + behind it by mean of &TCP;, but no possible way to manifest it + independently from cuban State. The cuban State controls all + the communication media and very few possibilities are + available for cubans to build up independent collaborative + networks using computers inside the island for sharing + information apart from cuban State restrictions and + conditions. One of these possibilities is the telepohne + network the cuban State provides, which has national scope. + Generally, cubans use the telephone network to talk among + themselves, but it is also possible to use this network to + transmit information that cannot be communicated using the + regular method of human talking. It is possible to attach + computers to the telephone network the cuban State provides to + transmit whatever information a computer can produce (e.g., + images, documents, programs, etc.) from one location in the + island to another and encrypting the information traveling + along the wire to garantee its privacy (e.g., the source + computer protects the information in a way that only the + target computer is able to unprotect. If the information is + intercepted by a computer located in the transmission middle, + it would be useless for that computer since only the target + can use it once it has been unprotected). We'll see more about + this later. + + + + In these last years (2009-2011), the cuban State has shown + signs to start using free software with the idea of + reaching a technological independency which is + quiet contradictory to me. What independency we are talking + about here? Independency for whom, and from whom? Based on + the meaning of the word, independency is the lack of any + dependency, so the only way I see the cuban State will be able + to reach such technological independency would be creating and + maintaining an entire technological infrastructure (e.g., + computers, communication devices, operating systems written + from scratch, etc.) inside its political boundaries without + any intervention from the outside world. Otherwise, the cuban + State would be inevitably dependent from someone else that can + differ at some point of the production string and that would + be something unacceptable, because it would compromise the + idea the cuban State had about independency in first place + (i.e., no dependency). + + + + If the vision described above about what the cuban State tries + to mean by reaching a technological + independency sounds appropriate to you, the cuban + State is misunderstanding or trying to distort the real + meaning of free software and the philosophy behind it. The + free software is built from people and dedicated to people who + might be in need of it, with the hope of being useful and + garantee the freedom of computer users paying or not a + monetary price for it. The cuban State, on the other hand, + introduces free software at convenience because there are + entire operating systems free of charge which the cuban State + can study and change as needed, not in the sense of + guaranteeing the freedom it provides to people, but as a way + to control what software does cubans use and the way they do + that. It is another impositions cubans should comply with, no + matter what they think about it. + + When I was working in the health sector of cuban State + (2003-2007), my superior told me once that I couldn't keep + using &TCD; on servers any longer, because system + administrators at central level stopped using Red Hat + related distribution and started to use Debian. I don't + want to enter in a debate why one or another distribution, + that's not the point. But I do want to mention that this + decision shouldn't be taken from one day to another + without any consideration about all the time people spent + studying (and working for) one specific GNU/Linux + distribution. My opinion was rejected and they kept + themselves showing me that it was a matter of politics one + should follow, no matter what one thought about it. I + couldn't accept that and fired up myself from that + institution. I cannot change from one operating system to + another just because someone else wants to. + + Some people might think that there is no problem + in that because it is free software anyway. Yes, that's true, + but think that again: Shouldn't you have the freedom to decide + what free software to use, and also what community you join + to? No one must impose you anything about which social + community you participate in, that is a decision you need to + take by yourself, not from someone else. + + + + The free software isn't free because of its name, but the + legal, social, economical and political environment it is used + in. If licenses used by software producers to release their + works (either freely or privatively) aren't protected somehow + in that environment, software producers wont be motivated to + create any software at all (either free or privative). + Consider what is happening in Cuba with Windows, the operating + system produced by Microsoft corporation: when someone install + the Windows operating system, one of the first screens in the + installation process is the License Agreement under which + Microsoft corporation releases its product. This agreement + relys on the copyright concept, a legal instrument that was + initially created to motivate authors to create more. + Likewise, the Free Software Foundation relys on the copyright + concept to distribute free software. The fact the License + Agreement of Windows operating system isn't complied in Cuba + (e.g., no cuban pays Microsoft corporation for using its + operating system) as Microsoft imposses in its License + Agreement, is a clear sign of international copyright + violation, no matter if Cuba can or cannot establish + commercial treatments with Microsoft corporation because of + the Embargo impossed by United States of America against Cuba. + It is an ethical matter cubans need to comply with in order to + help reducing the tension against both nations by showing + respect for their creators and the way they expect their + products to be distributed world-wide. Personally, I don't + use Windows operating system since 2003 when I discovered the + free software philosophy, + + I want to thank my teacher Jesús Aneiros Sosa for + intructing me in the free software philosophy and for + leading the Linux User Group (LUG) of Cienfuegos during so + many years and transmiting the feeling of freedom. + + but I am worried about the legal issues cubans + might face when developing free software. For example, will + the cuban State treat the free software license in the same + way it treats privative software licenses? If the cuban State + has no legal regulation to protect the international copyright + concept (i.e., letting authors to publish their works the way + they want to and provide the legal protections needed to + deprive people from using those creations in a way different + from that one conceived by their authors), it would be very + difficult to truly motivate people to create free software (or + anything else) in Cuba. The main problem here is that you can + write free software, but what instrument you have to protect + it from others to make your code privative and forbbid you, + this way, from using further improvements over the code you + wrote yourself. + + + + It is important to remember that the free software movement + was initiated by Richard Stallman in the United States of + America, based on the legal system of that country, + specifically in the copyright concept being in force. In order + to use free software, in the sense of freedom thought by + Richard Stallman, it is required that a similar underlaying + legal system in matters of copyright concepts be present in + Cuba, or an agreement be complied among all countries (e.g., + The Berna Treatment) for this matters. I've heard that Cuba + signed The Berna Treatment, however what is happening with + Windows operating system gives the impression that cuban State + is not complying with the agreement it signed on there. For + cuban society to understand what free software and the + philosophy behind it really are, it is required to force a + strong concept of copyright in the cuban legislation, even + when some authors might want to deny the cuban State from + using the work they produce or use it under conditions the + cuban State doesn't agree with. It is required to give that + legal power to cuban authors, the people who create. I wonder + if the cuban State is ready for that; and if not, why? I + really would like to know in order to find a solution. + + + + Free software communities are the place where free software is + produced. There are international, national and local + communities grouped under the free software philosophy. In + Cuba, because all the communication media are controlled by + the cuban State and conceived to its own benefit, it is + difficult for anyone differing from cuban State to have access + to communication media where the free software communities + live in. I strongly beleive that for the free software + philosophy to touch the heart of cubans, all free software + communities must be accessable to cubans. However, while the + cuban State keeps itself being inbetween, controlling how the + cubans can or cannot integrate any specific way of living, + there will not be free software in Cuba, nor any freedom for + cubans to make use of. + + + + Another frequent topic mentioned by the cuban State + information media is the migration from privative software to + free software. The migration from privative software to free + software must be initiated from people's deepest comprehension + of what they are doing, not from impositions of another + inquestionable order everybody needs to comply with. So, + cubans need to feel what freedom is and express it in order to + perceive a deep impact of free software in cuban society. We + cannot pretend that cubans will use free software based on a + lie or a distorted idea about the freedom it provides, an idea + like that wont last much before it falls itself into pieces. + People need a way of identifying themselves apart from any + social or political system in order for them to be able of + decide whether or not to be part of one. + + + + It is impossible to truly defend freedom if one doesn't have + felt what it is. The cuban State never talks (at least + officially) about introducing free software for freeing the + cuban society from privative software. In fact, if you compare + the privative software and the way cuban State restricts the + information management, + + See resolution 129 emitted by cuban Ministerium of + Informatics and Telecommunications (MIT). + + you may find them very similar. The resolutions + emitted by cuban State are specific to statal instituions that + use computers to share information. I don't know of any legal + estipulation about using information and communication + technologies by nautural people outside the statal sector and, + spite of it, I've heard of cubans that has been called by the + cuban State security departament to explain why they built a + computer network in the neighbourhood to share information + (isn't that obvious) and finally they were intimidated to stop + doing so. There isn't a legal instrument in either direction + that one can use as pattern to act legally. The cuban State + has all the legal power to condemn you as cuban, but you are + completly unarmed against it. If the cuban State really wants + to be democratic, it needs to give to cubans the arms they + need to fight against it without fear of being defeated. + Indeed, there would be no defeating at all, but evolution into + new political states based on cubans needs. It is the majority + of cubans who should define how The Cuban Tree evolves, not a + few minority that opresses the unarmed masses. + + + + Internet access is another obscured issue inside Cuba. Around + 2008, Cuba and Venezuela signed up an agreement to connect + both nation with a trasatlantic fiber optic cable for high + speed Internet access. In 2011 the cuban State announced the + arrival of such cable to cuban national territory, but nothing + more has been mentioned since then. There is a terrible + silence about it that make people woundering what happend with + that millionary invertion. Some people ask themselves why to + spend so much money on that if cubans cannot make use of it + and others prefer to think that the entire project failed. It + is difficult to know what happend exactly because, again, + there isn't any alternative way of communication but those + provided and controlled by the cuban State. The fact is that, + at present time (2011), there isn't a legal way for cubans to + contract an Internet service at home, nor even a viable way to + acquire a fixed telephone line at home either. + + I know of people that have requested a fixed telephone + line for their home and more than three years have passed + and they haven't the line yet. It is also known by + everyone that others don't even have to make any request + to have a fixed telephone line at home. + However, the same isn't true for extrangers + coming from other countries who are visiting Cuba or staying + inhere as residents. The cuban State permits these persons to + access Internet paying a service in offices called Telepuntos + or from home using different fees. Some cubans cannot + understand this, nor the logic behind it either. Have cubans + to change their nationality in order to have Internt access + from their homes in Cuba? + + + + In Cuba there is only one telecommunication corporation named + ETECSA. This organization gives the impresion of being very + tied to cuban State and controlling everything related to + telephone networks and dedicated links for data transmistion + in the island. + + I heard of a case where someone tried to establish an + independent connection from Cuba to another country using + the air as phisical medium for data trasmission and that + person is pressently suffering years in a cuban prison + because the cuban State considered such action as illegal + actions. At this moment I haven't more information about + this case. It is very difficult to be accurate about such + things without an alternative information medium, apart + from those under cuban State control. + + Based on the fact that cuban telephone network is + the only communication medium most cubans have direct access + to, my attention is centered on it as phisical medium for + exchanging information using computers. It is important to + remark that, when using the telephone network as medium for + data transmission, there are limitations in the number of + simultaneous connections it is possible to phisically + establish between computers, it could be difficult to obtain + the Modem devices inside the island, and it could be too much + expencive to make international calls in order to exchange + information with public services available on different + networks outside Cuba's political boundaries. Besides all + these restrictions, the cuban telephone network has a national + scope that can be efficiently used by cubans inside the island + to share information using computers at a monetary cost of + national telephone calls and the electrical power consumed by + computers and communication devices (e.g., modems and + switches). + + + + I beleive that most of problems the cubans presently have are + caused by a lack of information we need to face in order to + understand what we are and where we are going to, in the sense + of an interdependent human being's society. To face the + information problem, it is needed to make available + independent ways for cubans to express themselves in freedom + and provide, this way, the base arguments needed to edificate + the solutions of those problems we face today. That's my goal + with this work: educating myself in the compromise of + providing an independent space for cubans to discuss and + coordinate how to create collaborative networks using the + cuban telephone network + + Considering that I and most cubans haven't access to + dedicated links or real IP addresses for data transmission + at present time. + + as phisical medium to transmit information using + computers in freedom. + + + + The motivation for this work was taken from the free software + philosophy exposed by Richard Stallman in his book + Free Sofware Free Society and my + personal experience from 2003 to 2009 as active member inside + &TCP; international community. + + +
diff --git a/Documentation/Manuals/Tcpi-ug/Services.docbook b/Documentation/Manuals/Tcpi-ug/Services.docbook new file mode 100644 index 0000000..014d921 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services.docbook @@ -0,0 +1,10 @@ + + + Services + + &services-dns; + &services-mail; + &services-http; + &services-ldap; + + diff --git a/Documentation/Manuals/Tcpi-ug/Services.ent b/Documentation/Manuals/Tcpi-ug/Services.ent new file mode 100644 index 0000000..b76c2c0 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services.ent @@ -0,0 +1,13 @@ + + + + + + + + + + + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Dns.docbook b/Documentation/Manuals/Tcpi-ug/Services/Dns.docbook new file mode 100644 index 0000000..78dd877 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Dns.docbook @@ -0,0 +1,11 @@ + + + Domain Name Service + + + ... + + + &services-dns-overview; + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Dns/overview.docbook b/Documentation/Manuals/Tcpi-ug/Services/Dns/overview.docbook new file mode 100644 index 0000000..2f57c37 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Dns/overview.docbook @@ -0,0 +1,9 @@ + + + Overview + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Http.docbook b/Documentation/Manuals/Tcpi-ug/Services/Http.docbook new file mode 100644 index 0000000..ce85a8b --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Http.docbook @@ -0,0 +1,11 @@ + + + Web Service + + + ... + + + &services-http-overview; + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Http/overview.docbook b/Documentation/Manuals/Tcpi-ug/Services/Http/overview.docbook new file mode 100644 index 0000000..00335b6 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Http/overview.docbook @@ -0,0 +1,9 @@ + + + Overview + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Ldap.docbook b/Documentation/Manuals/Tcpi-ug/Services/Ldap.docbook new file mode 100644 index 0000000..eba7579 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Ldap.docbook @@ -0,0 +1,11 @@ + + + Directory Service + + + ... + + + &services-ldap-overview; + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Ldap/overview.docbook b/Documentation/Manuals/Tcpi-ug/Services/Ldap/overview.docbook new file mode 100644 index 0000000..f2af74e --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Ldap/overview.docbook @@ -0,0 +1,9 @@ + + + Overview + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Mail.docbook b/Documentation/Manuals/Tcpi-ug/Services/Mail.docbook new file mode 100644 index 0000000..04a47d2 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Mail.docbook @@ -0,0 +1,10 @@ + + + Mail Service + + &services-mail-overview; + &services-mail-mta; + &services-mail-mda; + &services-mail-mua; + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Mail/mda.docbook b/Documentation/Manuals/Tcpi-ug/Services/Mail/mda.docbook new file mode 100644 index 0000000..4b8971f --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Mail/mda.docbook @@ -0,0 +1,9 @@ + + + Mail Delivery Agent + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Mail/mta.docbook b/Documentation/Manuals/Tcpi-ug/Services/Mail/mta.docbook new file mode 100644 index 0000000..eeabea3 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Mail/mta.docbook @@ -0,0 +1,9 @@ + + + Mail Transfer Agent + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Mail/mua.docbook b/Documentation/Manuals/Tcpi-ug/Services/Mail/mua.docbook new file mode 100644 index 0000000..319d167 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Mail/mua.docbook @@ -0,0 +1,9 @@ + + + Mail User Agent + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Mail/overview.docbook b/Documentation/Manuals/Tcpi-ug/Services/Mail/overview.docbook new file mode 100644 index 0000000..b9693a6 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Mail/overview.docbook @@ -0,0 +1,58 @@ + + + Overview + + + The mail service provides the software required to let you + send/receive mail messages to/from others. The mail service is + supported by three basic components: the Mail Transfer Agent + (MTA), the Mail Delivery Agent (MDA) and the Mail User Agent + (MUA). The MTA is the program your mail client sends mail + messages to. The MDA, on the other hand, is the program your + mail client reads mail message from (i.e., this is the program + that lets you access your mailbox). The saslauthd daemon is + used by the MDA to authenticate user's credentials (e.g., the + information required to grant access to an specific mailbox) + and in some cases by the MTA to authenticate users before + sending mail to it. The MTA will listen on all network + interfaces it is attached to and will receive mail sent to + specific users inside specific domain names. + + + + Inside &TCD; there is support for different MTAs (e.g., + Sendmail, Postfix and Exim). By default, the + Sendmail program is used as mail + transfer agent, however, we want to use Postfix for our + configuration. This way, to use Postfix as default mail + transfer agent and not Sendmail, it is required to use the + alternatives command. This command will + present you a menu to chose between available mail transfer + agents installed in the system, so you can choose Posfix as + default option. Now that you've made Postfix the default mail + transfer agent, you can saftly remove the sendmail package to + avoid unused software to remain inside the computer. + + + + Inside &TCD; there is support for different MDA (e.g., Cyrus + IMPA and Dovecot). By default, the Dovecot program is used as + mail delivery agent (which doesn't require any intermediate + daemon for athentication), however, we want to use Cyrus IMAP + for our configuration (which does require an intermediate + daemon called saslauthd for authentication). + + + + Inside &TCD; there is support for different MUA (e.g., + Evolution, Thunderbird and Mutt). By default, the Evolution + program is used and we stay with it :). + + + + In this chapter we describe how to configure each one of these + components to let you send/receive e-mails to/from your + friends. + + + diff --git a/Documentation/Manuals/Tcpi-ug/Services/Mail/saslauthd.docbook b/Documentation/Manuals/Tcpi-ug/Services/Mail/saslauthd.docbook new file mode 100644 index 0000000..4211a1b --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/Services/Mail/saslauthd.docbook @@ -0,0 +1,9 @@ + + + Sasl Authentication Server + + + ... + + + diff --git a/Documentation/Manuals/Tcpi-ug/tcpi-ug.docbook b/Documentation/Manuals/Tcpi-ug/tcpi-ug.docbook new file mode 100755 index 0000000..a677227 --- /dev/null +++ b/Documentation/Manuals/Tcpi-ug/tcpi-ug.docbook @@ -0,0 +1,80 @@ + + + + + + + +%Commons.ent; +%Preface.ent; +%Connectivity.ent; +%Services.ent; +%Licenses.ent; +]> + + + + + The CentOS Project Infrastructure + User's Guide + + + + Alain + Reguera Delgado + + + + + 2011 + &TCP;. All rights reserved. + + + + + Permission is granted to copy, distribute and/or modify + this document under the terms of the GNU Free + Documentation License, Version 1.2 or any later version + published by the Free Software Foundation; with no + Invariant Sections, no Front-Cover Texts, and no + Back-Cover Texts. A copy of the license is included in + . + + + + + + 1.0 + Today + + Alain + Reguera Delgado + + + + Under development. + + + + + + + + + &preface; + + + &connectivity; + &services; + + + &licenses; + + diff --git a/Documentation/Tcar-fs/en_US/Branches/chapter-menu.texinfo b/Documentation/Tcar-fs/en_US/Branches/chapter-menu.texinfo deleted file mode 100644 index e69de29..0000000 --- a/Documentation/Tcar-fs/en_US/Branches/chapter-menu.texinfo +++ /dev/null diff --git a/Documentation/Tcar-fs/en_US/Branches/chapter-nodes.texinfo b/Documentation/Tcar-fs/en_US/Branches/chapter-nodes.texinfo deleted file mode 100644 index 8b13789..0000000 --- a/Documentation/Tcar-fs/en_US/Branches/chapter-nodes.texinfo +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Documentation/Tcar-fs/en_US/Branches/chapter.texinfo b/Documentation/Tcar-fs/en_US/Branches/chapter.texinfo deleted file mode 100644 index 05e1ecb..0000000 --- a/Documentation/Tcar-fs/en_US/Branches/chapter.texinfo +++ /dev/null @@ -1,16 +0,0 @@ -@node Branches -@chapter The @file{branches} Directory -@cindex The @file{branches} Directory - -@c -- Chapter Introduction -This directory implements the Subversion's branches concept in a -trunk, branches, tags repository structure. The @file{branches} -directory structure provides an intermediate space for creating -temporal changes that might be later merged into @file{trunk} -directory structure (@pxref{Trunk}). - -@c -- Chapter Menu -@include Branches/chapter-menu.texinfo - -@c -- Chapter Nodes -@include Branches/chapter-nodes.texinfo diff --git a/Documentation/Tcar-fs/en_US/Licenses/chapter-menu.texinfo b/Documentation/Tcar-fs/en_US/Licenses/chapter-menu.texinfo deleted file mode 100755 index b8240ba..0000000 --- a/Documentation/Tcar-fs/en_US/Licenses/chapter-menu.texinfo +++ /dev/null @@ -1,4 +0,0 @@ -@menu -* GNU General Public License:: -* GNU Free Documentation License:: -@end menu diff --git a/Documentation/Tcar-fs/en_US/Licenses/chapter-nodes.texinfo b/Documentation/Tcar-fs/en_US/Licenses/chapter-nodes.texinfo deleted file mode 100755 index bd707d6..0000000 --- a/Documentation/Tcar-fs/en_US/Licenses/chapter-nodes.texinfo +++ /dev/null @@ -1,9 +0,0 @@ -@node GNU General Public License -@section GNU General Public License -@cindex GNU General Public License -@include trunk/Scripts/Bash/Functions/Help/Texinfo/Templates/en_US/Licenses/GPL.texinfo - -@node GNU Free Documentation License -@section GNU Free Documentation License -@cindex GNU Free Documentation License -@include trunk/Scripts/Bash/Functions/Help/Texinfo/Templates/en_US/Licenses/GFDL.texinfo diff --git a/Documentation/Tcar-fs/en_US/Licenses/chapter.texinfo b/Documentation/Tcar-fs/en_US/Licenses/chapter.texinfo deleted file mode 100755 index e5ffcbd..0000000 --- a/Documentation/Tcar-fs/en_US/Licenses/chapter.texinfo +++ /dev/null @@ -1,5 +0,0 @@ -@node Licenses -@appendix Licenses -@cindex Licenses -@include Licenses/chapter-menu.texinfo -@include Licenses/chapter-nodes.texinfo diff --git a/Documentation/Tcar-fs/en_US/Tags/chapter-menu.texinfo b/Documentation/Tcar-fs/en_US/Tags/chapter-menu.texinfo deleted file mode 100644 index e69de29..0000000 --- a/Documentation/Tcar-fs/en_US/Tags/chapter-menu.texinfo +++ /dev/null diff --git a/Documentation/Tcar-fs/en_US/Tags/chapter-nodes.texinfo b/Documentation/Tcar-fs/en_US/Tags/chapter-nodes.texinfo deleted file mode 100644 index 8b13789..0000000 --- a/Documentation/Tcar-fs/en_US/Tags/chapter-nodes.texinfo +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Documentation/Tcar-fs/en_US/Tags/chapter.texinfo b/Documentation/Tcar-fs/en_US/Tags/chapter.texinfo deleted file mode 100644 index cfd4897..0000000 --- a/Documentation/Tcar-fs/en_US/Tags/chapter.texinfo +++ /dev/null @@ -1,16 +0,0 @@ -@node Tags -@chapter The @file{tags} Directory -@cindex The @file{tags} Directory - -@c -- Chapter Introduction -This directory implements the Subversion's tags concept in a trunk, -branches, tags repository structure. The @file{tags/} directory -structure provides frozen branches. Generally, we use frozen branches -to make check-points in time for development lines under -@file{branches/} or @file{trunk/} directory structure. - -@c -- Chapter Menu -@include Tags/chapter-menu.texinfo - -@c -- Chapter Nodes -@include Tags/chapter-nodes.texinfo diff --git a/Documentation/Tcar-fs/en_US/Trunk/chapter-menu.texinfo b/Documentation/Tcar-fs/en_US/Trunk/chapter-menu.texinfo deleted file mode 100644 index fccaa2d..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/chapter-menu.texinfo +++ /dev/null @@ -1,23 +0,0 @@ -@menu -* Trunk Identity:: -* Trunk Identity Brushes:: -* Trunk Identity Brushes Corporate:: -* Trunk Identity Fonts:: -* Trunk Identity Images:: -* Trunk Identity Images Brands:: -* Trunk Identity Images Brands Logos:: -* Trunk Identity Images Brands Symbols:: -* Trunk Identity Images Brands Types:: -* Trunk Identity Images Themes:: -* Trunk Identity Models:: -* Trunk Identity Models Brands:: -* Trunk Identity Models Brands Logos:: -* Trunk Identity Models Icons:: -* Trunk Identity Models Themes:: -* Trunk Identity Palettes:: -* Trunk Identity Patterns:: -* Trunk Identity Webenv:: -* Trunk Scripts:: -* Trunk Scripts Functions:: -* Trunk Scripts Functions Prepare:: -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/chapter-nodes.texinfo b/Documentation/Tcar-fs/en_US/Trunk/chapter-nodes.texinfo deleted file mode 100644 index 1aba12c..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/chapter-nodes.texinfo +++ /dev/null @@ -1,21 +0,0 @@ -@include Trunk/identity.texinfo -@include Trunk/identity-brushes.texinfo -@include Trunk/identity-brushes-corporate.texinfo -@include Trunk/identity-fonts.texinfo -@include Trunk/identity-images.texinfo -@include Trunk/identity-images-brands.texinfo -@include Trunk/identity-images-brands-logos.texinfo -@include Trunk/identity-images-brands-symbols.texinfo -@include Trunk/identity-images-brands-types.texinfo -@include Trunk/identity-images-themes.texinfo -@include Trunk/identity-models.texinfo -@include Trunk/identity-models-brands.texinfo -@include Trunk/identity-models-brands-logos.texinfo -@include Trunk/identity-models-icons.texinfo -@include Trunk/identity-models-themes.texinfo -@include Trunk/identity-palettes.texinfo -@include Trunk/identity-patterns.texinfo -@include Trunk/identity-webenv.texinfo -@include Trunk/scripts.texinfo -@include Trunk/scripts-functions.texinfo -@include Trunk/scripts-functions-prepare.texinfo diff --git a/Documentation/Tcar-fs/en_US/Trunk/chapter.texinfo b/Documentation/Tcar-fs/en_US/Trunk/chapter.texinfo deleted file mode 100644 index 8421fe0..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/chapter.texinfo +++ /dev/null @@ -1,15 +0,0 @@ -@node Trunk -@chapter The @file{trunk} Directory -@cindex The @file{trunk} Directory - -@c -- Chapter Introduction -The @file{trunk} directory structure implements the Subversion's trunk -concept in a trunk, branches, tags repository structure. It provides -the main development line inside @value{TCAR} and is made of the -following components: - -@c -- Chapter Menu -@include Trunk/chapter-menu.texinfo - -@c -- Chapter Nodes -@include Trunk/chapter-nodes.texinfo diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-brushes-corporate.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-brushes-corporate.texinfo deleted file mode 100644 index 265f3fc..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-brushes-corporate.texinfo +++ /dev/null @@ -1,10 +0,0 @@ -@node Trunk Identity Brushes Corporate -@section @file{trunk/Identity/Brushes/Corporate} -@cindex Trunk identity brushes corporate - -... - -@c -- <[centos-art(SeeAlso) -@itemize -@end itemize -@c -- ]> diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-brushes.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-brushes.texinfo deleted file mode 100644 index ec6d853..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-brushes.texinfo +++ /dev/null @@ -1,80 +0,0 @@ -@node Trunk Identity Brushes -@section @file{trunk/Identity/Brushes} -@cindex Trunk identity brushes - -The @file{trunk/Identity/Brushes} directory exists to organize GIMP -brushes used inside @value{TCPCVI}. - -A brush is a pixmap or set of pixmaps used for painting through an -image manipulation program like GIMP. Inside the repository, brushes -are initially created in @file{.xcf} format and later exported to any -of the brush formats recognized by GIMP (e.g., @file{.gbr} or -@file{.gih}) using the same name of its source file. - -The @file{trunk/Identity/Brushes} directory is under version control. - -The @file{trunk/Identity/Brushes} directory contains no file, but the -following organizational directories: - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Identity Brushes Corporate} -@end itemize -@c -- ]> - -Content rendition inside @file{trunk/Identity/Brushes} directory is -not supported. - -In order for brushes to be loaded by GIMP, they should be stored in -the @file{~/.gimp-2.2/brushes} directory. This location is out of -@value{TCAR} and doesn't provide version control by itself. To be able -of using version controlled brushes inside GIMP, we store brush -related files inside @file{trunk/Identity/Brushes} directory and -create links to them from @file{~/.gimp-2.2/brushes} directory. - -@float Example,trunk-identity-brushes-1 -@verbatim -trunk/Identity/Brushes -|-- Corporate -| |-- symbol.xcf -| `-- symbol.gbr (file) <-- ~/.gimp-2.2/brushes/corporate-symbol.gbr (link) -|-- TreeFlower -| |-- flower.gbr (file) <-- ~/.gimp-2.2/brushes/treeflower-flower.gbr (link) -| |-- flower.xcf -| |-- branch.gbr (file) <-- ~/.gimp-2.2/brushes/treeflower-branch.gbr (link) -| |-- branch.xcf -| |-- trunk.gbr (file) <-- ~/.gimp-2.2/brushes/treeflower-trunk.gbr (link) -| `-- trunk.xcf -`-- Others - `-- ... -@end verbatim -@caption{Relation between brushes inside the workstation.} -@end float - -The entire link preparation and maintainance of brushes inside the -working copy is automated by @code{prepare} functionality of -@command{centos-art.sh} script. - -Inside the working copy, brushes might be created individually in -different locations, but they all need to be linked from one unique -location (i.e., @file{~/.gimp-2.2/brushes}). This configuration may -provoke brushes to overlap one another if a consistent name -convenction is not implemented correctly. In that sake, the brushes -file names are build using their directory and file names as reference -in order to build unique names that can be used as identifiers. - -Brushes produced with GIMP has a description field associated that is -shown in the Brushes panel of GIMP. This description is set when the -brush is created as @file{.xcf} file and can be updated when it is -exported either to @file{.gbr} or @file{.gih} format. It wouldn't be -too useful to have two or more brushes using the same description so, -we also make description of brush files unique, too. In that sake, use -the file name as description but without including the file extension -(e.g., if we have the @file{centos-flame-3.gbr} brush, its description -would be @code{centos-flame-3}). - -More information about GIMP brushes can be found in -@url{file:///usr/share/gimp/2.0/help/en/index.html,The Gimp Manual}, -specifically in the section related to -@url{file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.html, -Brushes}. diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-fonts.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-fonts.texinfo deleted file mode 100644 index a77a537..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-fonts.texinfo +++ /dev/null @@ -1,54 +0,0 @@ -@node Trunk Identity Fonts -@section @file{trunk/Identity/Fonts} -@cindex Trunk identity fonts - -The @file{trunk/Identity/Fonts} directory exists to organize -typographies used inside @value{TCPCVI} that aren't packaged inside -@value{TCD}. - -The @file{trunk/Identity/Fonts} directory is under version control. - -Content rendition inside @file{trunk/Identity/Fonts} directory is not -supported. - -@c -- describe, in one paragraph, what a font is. - -In order for fonts to be available inside programs like GIMP and -Inkscape, font files should be stored either in -@file{/usr/share/fonts} or @file{~/.fonts} directory. These locations -are out of @value{TCAR} and doesn't provide version control by -themselves. In order for version controlled typographies to be -available inside programs like GIMP and Inkscape, we store them under -@file{trunk/Identity/Fonts} directory and create links to them from -@file{~/.fonts} directory. - -@float Example, trunk-identity-fonts-1 -@verbatim -trunk/Identity/Fonts -`-- denmark.ttf (file) <-- ~/.fonts/denmark.ttf (link) -@end verbatim -@caption{Relation between fonts inside the workstation.} -@end float - -The creation and maintainance of links related to fonts inside the -working copy are automated by @code{prepare} functionality of -@command{centos-art.sh} script. - -Inside @value{TCPCVI}, the @samp{DejaVu LGC} typography is used as -default typography in all visual manifestations. The @samp{DejaVu LGC} -typography comes with @value{TCD} so there is no need to store it in -@file{trunk/Identity/Fonts} for you to use. - -Inside @value{TCPCVI}, the @samp{Denmark} typography is used as base -to build The CentOS Logo (i.e., the main graphic design that -connects/identifies all visual manifestations related to The CentOS -Project). The @samp{Denmark} typography doesn't come with @value{TCD} -so it is store in @file{trunk/Identity/Fonts} for you to use. - -The license information of @samp{Denmark} typography isn't very clear, -at least not as clear as the one in @samp{DejaVu LGC} typography is. -Using a typography with a doubtful license might put in risk the -content produced from it. To prevent such issues, it would be better -to move on from @samp{Denmark} typography to another typography (free, -preferably) that retain the same visual style of @samp{Denmark}, but -with a clearer copyright and license notice. diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-logos.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-logos.texinfo deleted file mode 100644 index 00a2741..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-logos.texinfo +++ /dev/null @@ -1,42 +0,0 @@ -@node Trunk Identity Images Brands Logos -@section @file{trunk/Identity/Images/Brands/Logos} -@cindex Trunk identity images brands logos - -The @file{trunk/Identity/Images/Brands/Logos} exists to organize -images related to The CentOS Logos, in different formats (e.g., PNG, -JPG, PDF, TIF, XBM, XPM) and dimensions. - -The CentOS Logo is a construction made of The CentOS Symbol and The -CentOS Type. The CentOS Symbol and The CentOS Logo are the main visual -manifestations of the organization known as @value{TCPROJ}. As The -CentOS Symbol, The CentOS Logo is used to ``brand'' images produced by -@value{TCPROJ} and provide a visual connection between images so they -can be monolithically recognized as part of @value{TCPROJ}. The CentOS -Logo must be exactly the same everytime it is printed out and a route -to reproduce it in such a way must be available so as to avoid -reproduction mistakes when images are branded with it. - -The @file{trunk/Identity/Images/Brands/Logos} directory and the files -inside it aren't under version control. - -The @file{trunk/Identity/Images/Brands/Logos} directory contains files -used by the @file{redhat-logos} package, specifically the files inside -the @file{/usr/share/pixmaps/redhat} directory. - -The @file{trunk/Identity/Images/Brands/Logos} directory organizes -files under directories numerically named (e.g., @file{48}, @file{64}, -@file{128}, etc.). Inside these directories, image files are stored -in specific heights and named as -@file{centos-.}, where @code{} -describes the file content and @code{} sets the file -extension. In all cases, the directory name can be used as reference -to determine the image height of files stored inside. For example, -the directory @file{48} stores image files of 48 pixels height in -different formats. - -Content rendition inside @file{trunk/Identity/Images/Brands/Logos} -directory takes place through the following command: - -@verbatim -centos-art render trunk/Identity/Images/Brands/Logos --dont-commit-changes -@end verbatim diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-symbols.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-symbols.texinfo deleted file mode 100644 index 3ac5b2f..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-symbols.texinfo +++ /dev/null @@ -1,40 +0,0 @@ -@node Trunk Identity Images Brands Symbols -@section @file{trunk/Identity/Images/Brands/Symbols} -@cindex Trunk identity images brands symbols - -The @file{trunk/Identity/Images/Brands/Symbols} exists to organize -images related to The CentOS Symbol, in different formats (e.g., PNG, -JPG, PDF, TIF, XBM, XPM) and dimensions. - -The CentOS Symbol is the graphical part of The CentOS Logo. As The -CentOS Logo, The CentOS Symbol is used to ``brand'' images produced by -@value{TCPROJ} and provide a visual connection between images so they -can be monolithically recognized as part of @value{TCPROJ}. The CentOS -Symbol must be exactly the same everytime it is printed out and a -route to reproduce it in such a way must be available so as to avoid -reproduction mistakes when images are branded with it. - -The @file{trunk/Identity/Images/Brands/Symbols} directory and the files -inside it aren't under version control. - -The @file{trunk/Identity/Images/Brands/Symbols} directory contains -files used by the @file{redhat-logos} package, specifically the files -inside the @file{/usr/share/pixmaps/redhat} directory. - -The @file{trunk/Identity/Images/Brands/Symbols} directory organizes -files under directories numerically named (e.g., @file{48}, @file{64}, -@file{128}, etc.). Inside these directories, image files are stored -in specific heights and named as -@file{centos-.}, where @code{} -describes the file content and @code{} sets the file -extension. In all cases, the directory name can be used as reference -to determine the image height of files stored inside. For example, -the directory @file{48} stores image files of 48 pixels height in -different formats. - -Content rendition inside @file{trunk/Identity/Images/Brands/Symbols} -directory takes place through the following command: - -@verbatim -centos-art render trunk/Identity/Images/Brands/Symbols --dont-commit-changes -@end verbatim diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-types.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-types.texinfo deleted file mode 100644 index c1b1f88..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands-types.texinfo +++ /dev/null @@ -1,44 +0,0 @@ -@node Trunk Identity Images Brands Types -@section @file{trunk/Identity/Images/Brands/Types} -@cindex Trunk identity images brands types - -The @file{trunk/Identity/Images/Brands/Types} exists to organize -images related to The CentOS Symbol, in different formats (e.g., PNG, -JPG, PDF, TIF, XBM, XPM) and dimensions. - -The CentOS Type is the typographical part of The CentOS Logo. -Comparing with both The CentOS Logo and The CentOS Symbol, The CentOS -Type by its own, provides poor visual connection between images that -intend to be recongnized as a monolithic part of @value{TCPROJ} and -shouldn't be used alone. Instead, The CentOS Logo or The CentOS Symbol -are prefered. The CentOS Symbol must be exactly the same everytime it -is printed out and a route to reproduce it in such a way must be -available so as to avoid reproduction mistakes when images are branded -with it. - -The @file{trunk/Identity/Images/Brands/Types} directory and the files -inside it aren't under version control. Files in this location are -mainly used to build The CentOS Logo from combining both The CentOS -Type and The CentOS Symbol in specific situations that might be needed -doing so. - -The @file{trunk/Identity/Images/Brands/Types} directory contains files -used by no package, as far as we've found out. - -The @file{trunk/Identity/Images/Brands/Types} directory organizes -files under directories numerically named (e.g., @file{48}, @file{64}, -@file{128}, etc.). Inside these directories, image files are stored -in specific heights and named as -@file{centos-.}, where @code{} -describes the file content and @code{} sets the file -extension. In all cases, the directory name can be used as reference -to determine the image height of files stored inside. For example, -the directory @file{48} stores image files of 48 pixels height in -different formats. - -Content rendition inside @file{trunk/Identity/Images/Brands/Types} -directory takes place through the following command: - -@verbatim -centos-art render trunk/Identity/Images/Brands/Types --dont-commit-changes -@end verbatim diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands.texinfo deleted file mode 100644 index f2d8270..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-images-brands.texinfo +++ /dev/null @@ -1,27 +0,0 @@ -@node Trunk Identity Images Brands -@section @file{trunk/Identity/Images/Brands} -@cindex Trunk identity images brands - -The @file{trunk/Identity/Images/Brands} directory exists to organize -brand information related to @value{TCPROJ}. - -The @file{trunk/Identity/Images/Brands} directory isn't under version -control. - -The @file{trunk/Identity/Images/Brands} contains no file, but the -following organizational directories: - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Identity Images Brands Logos} -@item @ref{Trunk Identity Images Brands Symbols} -@item @ref{Trunk Identity Images Brands Types} -@end itemize -@c -- ]> - -Content rendition inside @file{trunk/Identity/Images/Brands} directory -takes place through the following command: - -@verbatim -centos-art render trunk/Identity/Images/Brands --dont-commit-changes -@end verbatim diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-images-themes.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-images-themes.texinfo deleted file mode 100644 index ea7432e..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-images-themes.texinfo +++ /dev/null @@ -1,7 +0,0 @@ -@node Trunk Identity Images Themes -@section @file{trunk/Identity/Images/Themes} -@cindex Trunk identity images themes -... - -@menu -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-images.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-images.texinfo deleted file mode 100644 index 2a710e3..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-images.texinfo +++ /dev/null @@ -1,25 +0,0 @@ -@node Trunk Identity Images -@section @file{trunk/Identity/Images} -@cindex Trunk identity images - -The @file{trunk/Identity/Images} directory exists to store all image -files (e.g., PNG, JPG, PPM, etc.) related to @value{TCPCVI}. - -The @file{trunk/Identity/Images} directory is under version control. - -The @file{trunk/Identity/Images} directory contains no file, but the -following organizational directories: - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Identity Images Brands} -@item @ref{Trunk Identity Images Themes} -@end itemize -@c -- ]> - -Content rendition inside @file{trunk/Identity/Images} directory takes -place through the following command: - -@verbatim -centos-art render trunk/Identity/Images --dont-commit-changes -@end verbatim diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-models-brands-logos.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-models-brands-logos.texinfo deleted file mode 100644 index 3e01581..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-models-brands-logos.texinfo +++ /dev/null @@ -1,8 +0,0 @@ -@node Trunk Identity Models Brands Logos -@section @file{trunk/Identity/Models/Brands/Logos} -@cindex Trunk identity models brands logos - -... - -@menu -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-models-brands.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-models-brands.texinfo deleted file mode 100644 index e6bd846..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-models-brands.texinfo +++ /dev/null @@ -1,9 +0,0 @@ -@node Trunk Identity Models Brands -@section @file{trunk/Identity/Models/Brands} -@cindex Trunk identity models brands - -... - -@menu -* Trunk Identity Models Brands Logos:: -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-models-icons.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-models-icons.texinfo deleted file mode 100644 index 2c56d59..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-models-icons.texinfo +++ /dev/null @@ -1,10 +0,0 @@ -@node Trunk Identity Models Icons -@section @file{trunk/Identity/Models/Icons} -@cindex Trunk identity models icons - -... - -@c -- <[centos-art(SeeAlso) -@itemize -@end itemize -@c -- ]> diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-models-themes.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-models-themes.texinfo deleted file mode 100644 index e0c2c6a..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-models-themes.texinfo +++ /dev/null @@ -1,10 +0,0 @@ -@node Trunk Identity Models Themes -@section @file{trunk/Identity/Models/Themes} -@cindex Trunk identity models themes - -... - -@c -- <[centos-art(SeeAlso) -@itemize -@end itemize -@c -- ]> diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-models.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-models.texinfo deleted file mode 100644 index b725181..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-models.texinfo +++ /dev/null @@ -1,13 +0,0 @@ -@node Trunk Identity Models -@section @file{trunk/Identity/Models} -@cindex Trunk identity models - -... - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Identity Models Brands} -@item @ref{Trunk Identity Models Icons} -@item @ref{Trunk Identity Models Themes} -@end itemize -@c -- ]> diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-palettes.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-palettes.texinfo deleted file mode 100644 index 1502894..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-palettes.texinfo +++ /dev/null @@ -1,7 +0,0 @@ -@node Trunk Identity Palettes -@section @file{trunk/Identity/Palettes} -@cindex Trunk identity palettes -... - -@menu -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-patterns.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-patterns.texinfo deleted file mode 100644 index d4cf568..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-patterns.texinfo +++ /dev/null @@ -1,7 +0,0 @@ -@node Trunk Identity Patterns -@section @file{trunk/Identity/Patterns} -@cindex Trunk identity patterns -... - -@menu -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity-webenv.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity-webenv.texinfo deleted file mode 100644 index de47fe1..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity-webenv.texinfo +++ /dev/null @@ -1,7 +0,0 @@ -@node Trunk Identity Webenv -@section @file{trunk/Identity/Webenv} -@cindex Trunk identity webenv -... - -@menu -@end menu diff --git a/Documentation/Tcar-fs/en_US/Trunk/identity.texinfo b/Documentation/Tcar-fs/en_US/Trunk/identity.texinfo deleted file mode 100644 index 788f31e..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/identity.texinfo +++ /dev/null @@ -1,33 +0,0 @@ -@node Trunk Identity -@section @file{trunk/Identity} -@cindex Trunk identity - -The @file{trunk/Identity} directory describes @value{TCPCI}, what it -is and the components it is made of. - -@value{TCPCI} is the ``persona'' of the organization known as The -CentOS Project. The CentOS Project Corporate Identity plays a -significant role in the way The CentOS Project, as organization, -presents itself to both internal and external stakeholders. In general -terms, The CentOS Project Corporate Identity expresses the values and -ambitions of The CentOS Project organization, its business, and its -characteristics. @value{TCPCI} provides visibility, recognizability, -reputation, structure and identification to The CentOS Project by -means of Corporate Design, Corporate Communication, and Corporate -Behaviour. - -From Corporate Design, Corporate Communication and Corporate -Behaviour, it is the Corporate Design the one organized inside -@file{trunk/Identity} directory through the following components: - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Identity Brushes} -@item @ref{Trunk Identity Fonts} -@item @ref{Trunk Identity Images} -@item @ref{Trunk Identity Models} -@item @ref{Trunk Identity Palettes} -@item @ref{Trunk Identity Patterns} -@item @ref{Trunk Identity Webenv} -@end itemize -@c -- ]> diff --git a/Documentation/Tcar-fs/en_US/Trunk/scripts-functions-prepare.texinfo b/Documentation/Tcar-fs/en_US/Trunk/scripts-functions-prepare.texinfo deleted file mode 100644 index 2035cf9..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/scripts-functions-prepare.texinfo +++ /dev/null @@ -1,86 +0,0 @@ -@node Trunk Scripts Functions Prepare -@section @file{trunk/Scripts/Functions/Prepare} -@cindex Trunk scripts functions prepare - -The @file{trunk/Scripts/Functions/Prepare} directory exists to -organize the @code{prepare} functionality of @command{centos-art.sh} -script. The @code{prepare} functionality is written in Bash and its -main goal is to standardize the final configuration stuff your -workstation needs, once the working copy of @value{TCAR} has been -downloaded inside it. - -The @file{trunk/Scripts/Functions/Prepare} directory and all files -inside it are under version control. - -Content rendition inside @file{trunk/Scripts/Functions/Prepare} is not -supported. - -Inside @file{trunk/Scripts/Functions/Prepare} directory, file names -and function names share the same name convenction with the exception -that file names end with a @samp{.sh} suffix while function names -doesn't. Both, file names and function names, begin with -@samp{prepare_} prefix followed by a description of what the function -does. - -Inside @file{trunk/Scripts/Functions/Prepare} directory, you can find -the following functions: - -@defun prepare -The @code{prepare} (initialization) function creates the base -execution environment required to standardize final configuration -stuff needed by your workstation, once the working copy of -@value{TCAR} has been downloaded in it. -@end defun - -@defun prepare_getOptions -The @code{prepare_getOptions} function parses command options provided -to @command{centos-art.sh} script when the first argument in the -command-line is the @samp{prepare} word. This function decides what -action to perform based on options provided. To parse options, this -function makes use of @command{getopt} program. -@end defun - -@defun prepare_updateLinks -The @code{prepare_updateLinks} function updates the symbolic -link relation that connects your workstation with the files inside the -working copy of @value{TCAR}. This function makes brushes, palettes, -patterns and fonts inside the working copy available to programs like -GIMP and Inkscape installed in your workstation. -@end defun - -@defun prepare_updateImages -The @code{prepare_updateImages} function initializes image files -inside the working copy. This function makes a list of all design -models inside the working copy and renders them one by one to produces -the related output images. -@end defun - -@defun prepare_updateManuals -The @code{prepare_updateManuals} function initializes -documentation files inside the working copy. This function makes a -list of all documentation manuals source files inside the working copy -and produces related output for them. -@end defun - -@defun prepare_updatePackages -The @code{prepare_updatePackages} function verifies the required -packages your workstation needs to have installed in order for -@command{centos-art.sh} script to run correctly. If one or -more packages are uninstalled or out of date, the -@command{centos-art.sh} script asks you to confirm their -installation or actualization through the @command{sudo yum} command. -@end defun - -@defun prepare_getEnvars -The @code{prepare_getEnvars} function outputs a brief description of -relevant environment variables the @command{centos-art.sh} script -makes use of. -@end defun - -@defun prepare_getLinkName DIRECTORY, FILE -The @code{prepare_getLinkName} function takes a @var{DIRECTORY} path -as first argument and a @var{FILE} path as second argument to output a -file name with the path information that remains from substracting the -@var{DIRECTORY} path from the @var{FILE} path provided as argument. -@end defun - diff --git a/Documentation/Tcar-fs/en_US/Trunk/scripts-functions.texinfo b/Documentation/Tcar-fs/en_US/Trunk/scripts-functions.texinfo deleted file mode 100644 index d2e0116..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/scripts-functions.texinfo +++ /dev/null @@ -1,69 +0,0 @@ -@node Trunk Scripts Functions -@section @file{trunk/Scripts/Functions} -@cindex Trunk scripts functions - -The @file{trunk/Scripts/Functions} directory exists to organize common -and spectic functionalities related to the @command{centos-art.sh} -script. Common functionalities are loaded once the -@command{centos-art.sh} script is executed and made available for -sepecific functionalities to reuse. - -The @file{trunk/Scripts/Functions} directory and all files inside it -are under version control. - -Content rendition inside `trunk/Scripts/Functions' directory is not -supported. - -Inside @file{trunk/Scripts/Functions} directory, specific -functionalities are organized in the following directories: - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Scripts Functions Prepare} -@end itemize -@c -- ]> - -Inside @file{trunk/Scripts/Functions} directory, common -functionalities are stored in files prefixed with the @samp{cli} -string as described below: - -@defun cli "$@@" -The @code{cli} functionality initializes the command-line interface -(cli) of @command{centos-art.sh} script. This function evaluates the -first argument provided to @command{centos-art.sh} script and call the -specific functionality that respondes to it. The @code{cli} function -is directly called from @file{centos-art.sh} itself once global -variables are defined, working copy verification performed, common -functionalities exported into the execution environment, and signals -trapped. The @code{cli} function receives all positional parameters -passed to @command{centos-art.sh} as argument. - -The @code{cli} function creates the a new environment inside that one -created by @command{centos-art.sh} script execution. Variables defined -herein will be avaialble to all specific functionalities and common -functionalities used inside specific functionalities. - -@defvar FUNCNAM -The @var{FUNCNAM} variable stores the function name passed as first -argument to @command{centos-art.sh} script using the file convenction -specified by @code{cli_getRepoName} function. -@end defvar - -@defvar FUNCDIR -The @var{FUNCDIR} variable stores the absolute path of directory -holding @command{centos-art.sh} script functions, both common and -specific. -@end defvar - -@defvar FUNCDIRNAM -... -@end defvar - -@defvar FUNCSCRIPT -... -@end defvar - -@defvar ARGUMENTS -... -@end defvar -@end defun diff --git a/Documentation/Tcar-fs/en_US/Trunk/scripts.texinfo b/Documentation/Tcar-fs/en_US/Trunk/scripts.texinfo deleted file mode 100644 index 51d2a43..0000000 --- a/Documentation/Tcar-fs/en_US/Trunk/scripts.texinfo +++ /dev/null @@ -1,73 +0,0 @@ -@node Trunk Scripts -@section @file{trunk/Scripts} -@cindex Trunk scripts - -The @file{trunk/Scripts} directory exists to organize automation -scripts related to @value{TCPCVI}. Such automation scripts are -implemented through @command{centos-art.sh} script, a bash scripts -designed to automate most frequent tasks performed inside the working -copy of @value{TCAR} (e.g., image rendition, content documentation, -content translation, etc.). - -The @file{trunk/Scripts} directory and all files inside it are under -version control. - -The @file{trunk/Scripts} directory contains just one file, the -@file{centos-art.sh} file. This file is the invocation script the -@command{centos-art} command calls to. In addition to -@file{centos-art.sh} file, the following directories are available: - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Scripts Functions} -@end itemize -@c -- ]> - -Content rendition inside @file{trunk/Scripts} is not supported. - -Once the @command{centos-art.sh} script is executed, the following -variables are available all along the script execution: - -@defvar CLI_PROGRAM -The @var{CLI_PROGRAM} variable is read-only and contains the name of -the script, which is @samp{centos-art}, without extension. -@end defvar - -@defvar CLI_PROGRAM_ID -The @var{CLI_PROGRAM_ID} variable is read-only and contains the -process identification assigned to @command{centos-art.sh} script, -once executed. -@end defvar - -@defvar CLI_VERSION -The @var{CLI_VERSION} variable is read-only and contains the version -number of @command{centos-art.sh} script. -@end defvar - -@defvar CLI_BASEDIR -The @var{CLI_BASEDIR} variable is read-only and contains the absolute -path of directory where @command{centos-art.sh} script is stored in. -@end defvar - -@defvar CLI_TEMPDIR -The @var{CLI_TEMPDIR} variable is read-only and contains the absolute -path of directory where temporal files created by -@command{centos-art.sh} script are stored in. -@end defvar - -@defvar TEXTDOMAIN -The @var{TEXDOMAIN} variable is read-only and contains the name of the -program we are providing localization for (i.e., @samp{centos-art.sh}). -@end defvar - -@defvar TEXTDOMAINDIR -The @var{TEXTDOMAINDIR} variable is read-only and contains the -absolute path of directory holding localization messages for -@command{centos-art.sh}. In order for this variable to take effect, -its value must be set using the -@file{$@{BASEDIR@}/$@{LANG@}/LC_MESSAGES/$@{TEXDOMAIN@}} construction; -where @var{BASEDIR} is an absolute path inside your workstation, -@var{LANG} a language code based on the standards @samp{ISO-639} and -@samp{ISO-3166} (e.g., @samp{es_ES} for Spanish from Spain, -@samp{fr_FR} for French from France, etc.). -@end defvar diff --git a/Documentation/Tcar-fs/en_US/tcar-fs-index.texinfo b/Documentation/Tcar-fs/en_US/tcar-fs-index.texinfo deleted file mode 100755 index b197b13..0000000 --- a/Documentation/Tcar-fs/en_US/tcar-fs-index.texinfo +++ /dev/null @@ -1,8 +0,0 @@ -@node Index -@unnumbered Index -@syncodeindex fn cp -@syncodeindex vr cp -@syncodeindex ky cp -@syncodeindex pg cp -@syncodeindex tp cp -@printindex cp diff --git a/Documentation/Tcar-fs/en_US/tcar-fs-menu.texinfo b/Documentation/Tcar-fs/en_US/tcar-fs-menu.texinfo deleted file mode 100644 index 2209765..0000000 --- a/Documentation/Tcar-fs/en_US/tcar-fs-menu.texinfo +++ /dev/null @@ -1,7 +0,0 @@ -@menu -* Trunk:: -* Branches:: -* Tags:: -* Licenses:: -* Index:: -@end menu diff --git a/Documentation/Tcar-fs/en_US/tcar-fs-nodes.texinfo b/Documentation/Tcar-fs/en_US/tcar-fs-nodes.texinfo deleted file mode 100644 index d30344b..0000000 --- a/Documentation/Tcar-fs/en_US/tcar-fs-nodes.texinfo +++ /dev/null @@ -1,3 +0,0 @@ -@include Trunk/chapter.texinfo -@include Branches/chapter.texinfo -@include Tags/chapter.texinfo diff --git a/Documentation/Tcar-fs/en_US/tcar-fs.conf b/Documentation/Tcar-fs/en_US/tcar-fs.conf deleted file mode 100755 index 789f831..0000000 --- a/Documentation/Tcar-fs/en_US/tcar-fs.conf +++ /dev/null @@ -1,36 +0,0 @@ -# This file controls the manual configuration. This file is divided -# in configuration sections (e.g., `main' and `templates') which, in -# turn, are organized in the form `variable = value'. -# ---------------------------------------------------------------------- -# $Id$ -# ---------------------------------------------------------------------- - -[main] - -# Specify documentation backend used by documentation manual. This is -# the format used to write documentation manual source files. -manual_format = "texinfo" - -# Specify title style used by sections inside the manual. Possible -# values to this option are `cap-each-word' to capitalize each word in -# the section title, `cap-first-word' to capitalize the first word in -# the section title only and `directory' to transform each word in the -# section title into a directory path. From all these options, -# `cap-each-word' is the one used as default. -manual_section_style = "directory" - -# Specify the order used by sections inside the manual. By default new -# sections added to the manual are put on the end to follow the -# section `created' order. Other possible values to this option are -# `ordered' and `reversed' to sort the list of sections alphabetically -# from A-Z and Z-A, respectively. -manual_section_order = "ordered" - -[templates] - -# Specify relation between template files and section definition files -# inside the manual. Template definition is set on the left side using -# relative path. The section main definition file is described on the -# right using a regular expression. The first match wins. -Chapters/section-functions.texinfo = "^.+-functions-[[:alnum:]]+\.texinfo$" -Chapters/section.texinfo = "^.+\.texinfo$" diff --git a/Documentation/Tcar-fs/en_US/tcar-fs.texinfo b/Documentation/Tcar-fs/en_US/tcar-fs.texinfo deleted file mode 100644 index e1f6b42..0000000 --- a/Documentation/Tcar-fs/en_US/tcar-fs.texinfo +++ /dev/null @@ -1,83 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c -- Header -------------------------------------------------- - -@setfilename tcar-fs.info -@settitle The CentOS Artwork Repository File System -@documentlanguage en -@afourpaper -@finalout - -@c -- Variables ----------------------------------------------- - -@set TCENTOS The Community Enterprise Operating System -@set TCPROJ @url{http://www.centos.org/, The CentOS Project} -@set TCWIKI @url{http://wiki.centos.org/, The CentOS Wiki} -@set TCMLISTS @url{http://lists.centos.org/, The CentOS Mailing Lists} -@set TCBUGS @url{http://bugs.centos.org/, The CentOS Bugs} -@set TCMIRRORS @url{http://mirrors.centos.org/, The CentOS Mirrors} -@set TCPLANET @url{http://planet.centos.org/, The CentOS Planet} -@set TCFORUMS @url{http://forums.centos.org/, The CentOS Forums} -@set TCINFOML @email{centos-info@@centos.org, The CentOS Information Mailing List} -@set TCDEVSML @email{centos-devel@@centos.org, The CentOS Developers Mailing List} -@set TCDOCSML @email{centos-docs@@centos.org, The CentOS Documentation Mailing List} -@set TCARTWML @email{centos-artwork@@centos.org, The CentOS Artwork Mailing List} -@set TCL10NML @email{centos-l10n@@centos.org, The CentOS Localization Mailing List} -@set TCAR @url{https://projects.centos.org/svn/artwork/, The CentOS Artwork Repository} -@set TCAS @url{https://projects.centos.org/trac/artwork/, The CentOS Artwork SIG} - -@set TCPCVI The CentOS Project Corporate Visual Identity -@set TCPCI The CentOS Project Corporate Identity -@set TCPCVIS The CentOS Project Corporate Visual Identity Structure -@set TCPCMVIS The CentOS Project Monolithic Corporate Visual Identity Structure - -@set TCD The CentOS Distribution - -@c -- Summary description and copyright ----------------------- - -@copying -This manual describes the directories inside @value{TCAR}. You can use -this manual as reference to know where to store or look for -information inside your working copy of @value{TCAR}. - -Copyright @copyright{} 2009, 2010, 2011 The CentOS Project - -Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no -Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A -copy of the license is included in the section entitled @ref{GNU Free -Documentation License}. -@end copying - -@c -- Titlepage, contents, copyright --------------------------- - -@titlepage -@title The CentOS Artwork Repository -@subtitle File System -@author Alain Reguera Delgado -@page -@vskip 0pt plus 1filll -@insertcopying -@end titlepage -@contents - -@c -- `Top' node and master menu ------------------------------- - -@ifnottex -@node Top -@top The CentOS Artwork Repository File System -@insertcopying -@end ifnottex - -@include tcar-fs-menu.texinfo - -@c -- The body of the document -------------------------------- - -@include tcar-fs-nodes.texinfo - -@c -- The end of the document --------------------------------- - -@include Licenses/chapter.texinfo -@include tcar-fs-index.texinfo - -@bye diff --git a/Documentation/Tcar-ug/Identity.docbook b/Documentation/Tcar-ug/Identity.docbook deleted file mode 100644 index d36b086..0000000 --- a/Documentation/Tcar-ug/Identity.docbook +++ /dev/null @@ -1,17 +0,0 @@ - - - Corporate Visual Identity - - - - ... - - - - &identity-project; - &identity-brand; - &identity-distro; - &identity-web; - &identity-showroom; - - diff --git a/Documentation/Tcar-ug/Identity.ent b/Documentation/Tcar-ug/Identity.ent deleted file mode 100644 index 144c375..0000000 --- a/Documentation/Tcar-ug/Identity.ent +++ /dev/null @@ -1,19 +0,0 @@ - - - - - - - - - - - - - - - - - - - diff --git a/Documentation/Tcar-ug/Identity/Brand.docbook b/Documentation/Tcar-ug/Identity/Brand.docbook deleted file mode 100644 index 0c0ba19..0000000 --- a/Documentation/Tcar-ug/Identity/Brand.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - The CentOS Brand - - &identity-brand-intro; - &identity-brand-symbol; - &identity-brand-type; - &identity-brand-logo; - &identity-brand-motif; - - diff --git a/Documentation/Tcar-ug/Identity/Brand/intro.docbook b/Documentation/Tcar-ug/Identity/Brand/intro.docbook deleted file mode 100644 index 84a602a..0000000 --- a/Documentation/Tcar-ug/Identity/Brand/intro.docbook +++ /dev/null @@ -1,49 +0,0 @@ - - - Introduction - - - &TCBRAND; is the main visual manifestaion of &TCP;. &TCP; - uses &TCBRAND; to connect all the visual manifestions it is - made of (e.g., GNU/Linux Distributions, Web sites, Stationery, - etc.) and, this way, provides recognition - - - ... just as a GPG signature might do for RPM packages. - - - among similar projects available on the Internet. The CentOS - Brand is made of a graphical component (&TCSYMBOL;) and a - typographical component (&TCTYPE;) that, when put together, - make &TCLOGO;. The components that make &TCBRAND; can be used - together or separately, considering that, in hierarchy order, - &TCLOGO; is rather prefered than &TCSYMBOL;, as well as - &TCSYMBOL; is rather prefered than &TCTYPE;. - - - - In addition to those components mentioned above, &TCBRAND; - includes another component named &TCMOTIF;. &TCMOTIF; is - mainly used as background on images and is directly related to - the look and feel of all visual manifestations &TCP; shows its - existence on. In contrast with &TCLOGO;, &TCSYMBOL; and - &TCTYPE;; &TCMOTIF; might change from time to time providing a - vehicle to refresh how &TCP; looks and feels. - - - - &TCBRAND; and all the visual manifestations derivated from it - are available for you to study and propose improvement around - a good citizen's will inside &TCC;, but you are not allowed to - redistribute them elsewhere, without the given permission of - &TCP;. - - - - If you need to redistribute either &TCLOGO; or any visual - manifestation derived from it, write your intentions to the - The CentOS Developers mailing list (centos-devel@centos.org). - - - diff --git a/Documentation/Tcar-ug/Identity/Brand/logo.docbook b/Documentation/Tcar-ug/Identity/Brand/logo.docbook deleted file mode 100644 index 14c4a9a..0000000 --- a/Documentation/Tcar-ug/Identity/Brand/logo.docbook +++ /dev/null @@ -1,4 +0,0 @@ - diff --git a/Documentation/Tcar-ug/Identity/Brand/motif.docbook b/Documentation/Tcar-ug/Identity/Brand/motif.docbook deleted file mode 100644 index 7341757..0000000 --- a/Documentation/Tcar-ug/Identity/Brand/motif.docbook +++ /dev/null @@ -1,5 +0,0 @@ - - The CentOS Motif - ... - - diff --git a/Documentation/Tcar-ug/Identity/Brand/symbol.docbook b/Documentation/Tcar-ug/Identity/Brand/symbol.docbook deleted file mode 100644 index f22e38d..0000000 --- a/Documentation/Tcar-ug/Identity/Brand/symbol.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - The CentOS Symbol - ... - diff --git a/Documentation/Tcar-ug/Identity/Brand/type.docbook b/Documentation/Tcar-ug/Identity/Brand/type.docbook deleted file mode 100644 index 07c3b14..0000000 --- a/Documentation/Tcar-ug/Identity/Brand/type.docbook +++ /dev/null @@ -1,5 +0,0 @@ - - The CentOS Type - ... - - diff --git a/Documentation/Tcar-ug/Identity/Distribution.docbook b/Documentation/Tcar-ug/Identity/Distribution.docbook deleted file mode 100644 index 0236910..0000000 --- a/Documentation/Tcar-ug/Identity/Distribution.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - The CentOS Distribution - ... - - - Release Schema - ... - - - - ... - ... - - - diff --git a/Documentation/Tcar-ug/Identity/Project.docbook b/Documentation/Tcar-ug/Identity/Project.docbook deleted file mode 100644 index 9c39eb8..0000000 --- a/Documentation/Tcar-ug/Identity/Project.docbook +++ /dev/null @@ -1,41 +0,0 @@ - - - The CentOS Project - - - The CentOS Project Corporate Identity is the - persona of the organization known as The CentOS - Project. The CentOS Project Corporate Identity plays a - significant role in the way The CentOS Project, as - organization, presents itself to both internal and external - stakeholders. In general terms, The CentOS Project Corporate - Identity expresses the values and ambitions of The CentOS - Project organization, its business, and its characteristics. - - - - The CentOS Project Corporate Identity provides visibility, - recognizability, reputation, structure and identification to - The CentOS Project organization by means of Corporate Design, - Corporate Communication, and Corporate Behaviour. - - -
- The CentOS Project Corporate Identity. - - The CentOS Project Corporate Identity. - - - - - - -
- - &identity-project-mission; - &identity-project-design; - &identity-project-communication; - &identity-project-behaviour; - &identity-project-structure; - - diff --git a/Documentation/Tcar-ug/Identity/Project/behaviour.docbook b/Documentation/Tcar-ug/Identity/Project/behaviour.docbook deleted file mode 100755 index bd22f04..0000000 --- a/Documentation/Tcar-ug/Identity/Project/behaviour.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Corporate Behaviour - - - &TCP; corporate behaviour is focused on the effective - interaction of each member involved in the organization (e.g., - core developers, community members, etc.). It is related to - ethics and politics used to do the things inside the - organization. It is related to the sense of direction chosen - by the organization and they way the organization projects - itself to achieve it. - - - - &TCP; corporate behaviour takes place through &TCP; corporate - communication, as described in . - - - diff --git a/Documentation/Tcar-ug/Identity/Project/communication.docbook b/Documentation/Tcar-ug/Identity/Project/communication.docbook deleted file mode 100755 index c46dd12..0000000 --- a/Documentation/Tcar-ug/Identity/Project/communication.docbook +++ /dev/null @@ -1,141 +0,0 @@ - - - Corporate Communication - - - &TCP; corporate communication is focused on the effective - propagation of corporate messages. Propagation of corporate - messages is closely related to the media the organization uses - as vehicle to distribute its corporate messages. - - - - &TCP; corporate communication takes place through the - following visual manifestations: - - - - - - &TCD; - - - This visual manifestation communicates its existence - through software packages. There are packages that make a - remarkable use of images, packages that make a moderate - use of images, and packages that don't use images at all. - This visual manifestation is focused on providing &TCP; - images required by software packages that do use images in - a remarkable way, specially those holding the upstream - brand (e.g., anaconda, - grub, syslinux, - gdm, kdebase). - - - - - The Community Enterprise Operating System itself - (communicates the essense of &TCP; existence.). - - - - - Release Schema (Lifetime) and all the stuff related (e.g., - Release Notes, Documentation, Erratas, etc.). - - - - - - - - &TCW; - - - This visual manifestation communicates its existence - through web applications. These web applications are free - software and come from different providers which - distribute their work with predefined visual styles. - Frequently, these predefined visual styles have no visual - relation among themselves and introduce some visual - contraditions when they all are put together. Removing - these visual contraditions is object of work for this - visual manifestation. - - - - - The CentOS Chat. - - - - - The CentOS Mailing Lists. - - - - - The CentOS Forums. - - - - - The CentOS Wiki. - - - - - Special Interest Groups (SIGs). - - - - - Social Events, Interviews, Conferences, etc. - - - - - The extensive network of mirrors available for downloading - ISO files as well as RPMs and SRPMs used to build them up - in different architectures. - - - - - - - - &TCS; - - - This visual manifestation communicates its existence - through production of industrial objects carrying &TCBRAND;. - These branded objects are directed to be distributed on - social events and/or shops. They provide a way of - promotion and commercialization that may help to reduce - &TCP; expenses (e.g., electrical power, hosting, servers, - full-time-developers, etc.), in a similar way as donations - may do. - - - - - Stationery (e.g., Posters, Stickers, CD Lables and Sleeves). - - - - - Clothes (e.g., Shirts, T-shirts, Pullovers, Caps). - - - - - Installation media (e.g., CDs, DVD, Pendrives). - - - - - - - - diff --git a/Documentation/Tcar-ug/Identity/Project/design.docbook b/Documentation/Tcar-ug/Identity/Project/design.docbook deleted file mode 100755 index 7429c7f..0000000 --- a/Documentation/Tcar-ug/Identity/Project/design.docbook +++ /dev/null @@ -1,96 +0,0 @@ - - - Corporate Graphic Design - - - The corporate design is focused on the effective presentation - of corporate messages. As corporate messages we understand all - the information emitted from the organization; and when we say - all we mean everything that can be - perceived through the human senses. The corporate design takes - care of defining what this information is and controlling the - way it goes out the organization producing it. - - - - When the organization doesn't take control over the corporate - messages it produces, the organization is letting that area of - its identity to the unknown and the results might be good or - not so good, it is hard to know. The issue to see here is - that even the organization doesn't take control over its - corporate messages, they are always talking about the - organization. Taking control of corporate messages is a - decition the organization needs to take by itself, based on - its need of better describe what it is. - - - - In the very specific case of &TCP;, we'll concentrate our - attention on corporate messages that reach us through the - visual sense. This is, all the visual manifestations &TCP; is - made of. As visual manifestaions we understand all the visible - media &TCP; uses to manifest its existence on. At this point - it is necessary to consider what &TCP; is, what its mission is - and what it is producing. This, in order to identify which - visual manifestations the organization is demanding attention - of corporate design for. - - - - Inside &TCP; we identify and apply corporate design to the - following visual manifestations: - - - - - - - &TCD; — This visual manifestation exists to cover all - actions related to artwork production and rebranding, required - by &TCD; in order to comply with upstream's redistribution - guidelines. This visual manifestation is described in . - - - - - - &TCW; — This visual manifestation exists to cover all - actions related to artwork production required by &TCP; to - manifest its existence in the World Wide Web medium. This - visual manifestation is described in . - - - - - - &TCS; — This visual manifestation exists to cover all - actions related to artwork production required by &TCP; to - manifest its existence through media produced industrially - (e.g., stationery, clothes, CDs, DVDs, etc.). This visual - manifestation is described in . - - - - - - The visual manifestations identified above seem to cover most - media required by &TCP;, as organization, to show its - existence. However, other visual manifestations could be - added in the future, as long as they be needed, to cover - different areas like stands, buildings, offices, road - transportation or whaterver visual manifestation &TCP; - thouches to show its existence. - - - - Once all visual manifestations have been identified and - defined through design models, it is time to visually remark - their connection with &TCP;. This kind of connection is - realized by applying &TCBRAND; to design models inside visual - manifestations supported through corporate design. - - - diff --git a/Documentation/Tcar-ug/Identity/Project/mission.docbook b/Documentation/Tcar-ug/Identity/Project/mission.docbook deleted file mode 100644 index 507873d..0000000 --- a/Documentation/Tcar-ug/Identity/Project/mission.docbook +++ /dev/null @@ -1,40 +0,0 @@ - - - Corporate Mission - - - &TCP; exists to produce &TCD;, an Enterprise-class Linux - Distribution derived from sources freely provided to the - public by a prominent North American Enterprise Linux vendor. - &TCD; conforms fully with the upstream vendors redistribution - policy and aims to be 100% binary compatible. (&TCD; mainly - changes packages to remove upstream vendor branding and - artwork.). - - - - &TCD; is developed by a small but growing team of core - developers. In turn the core developers are supported by an - active user community including system administrators, network - administrators, enterprise users, managers, core Linux - contributors and Linux enthusiasts from around the world. - - - - &TCD; has numerous advantages including: an active and growing - user community, quickly rebuilt, tested, and QA'ed errata - packages, an extensive mirror network, developers who are - contactable and responsive of a reliable Enterprise-class - Linux Distribution, multiple free support avenues including a - Wiki, - IRC - Chat, Email Lists, Forums, and - a dynamic FAQ. - - - diff --git a/Documentation/Tcar-ug/Identity/Project/structure.docbook b/Documentation/Tcar-ug/Identity/Project/structure.docbook deleted file mode 100755 index a0d20f9..0000000 --- a/Documentation/Tcar-ug/Identity/Project/structure.docbook +++ /dev/null @@ -1,91 +0,0 @@ - - - Corporate Structure - - - &TCP; corporate structure is based on a &MCVIS;. In this - configuration, one unique name and one unique visual style is - used in all visual manifestation &TCP; is made of. - - - - In a monolithic corporate visual identity structure, internal - and external stakeholders use to feel a strong sensation of - uniformity, orientation, and identification with the - organization. No matter if you are visiting web sites, using - the distribution, or acting on social events, the one unique - name and one unique visual style connects them all to say: - Hey! we are all part of &TCP;. - - - - Other corporate structures for &TCP; have been considered as - well. Such is the case of producing one different visual style - for each major release of &TCD;. This structure isn't - inconvenient at all, but some visual contradictions could be - introduced if it isn't applied correctly and we need to be - aware of it. To apply it correctly, we need to know what &TCP; - is made of. - - - - &TCP;, as organization, is mainly made of (but not limited to) - three visual manifestions: &TCD;, &TCW; and &TCS;. Inside - &TCD; visual manifestations, &TCP; maintains near to four - different major releases of &TCD;, parallely in time. - However, inside &TCW; visual manifestations, the content is - produced for no specific release information (e.g., there is - no a complete web site for each major release of &TCD; - individually, but one web site to cover them all). Likewise, - the content produced in &TCS; is industrially created for no - specific release, but &TCP; in general. - - - - In order to produce the &TCPMCVIS; correctly, we need to - concider all the visual manifestations &TCP; is made of, not - just one of them. If one different visual style is - implemented for each major release of &TCD;, which one of - those different visual styles would be used to cover the - remaining visual manifestations &TCP; is made of (e.g., &TCW; - and &TCS;)? - - - - Probably you are thinking: yes, I see your point, but &TCBRAND; - connects them all already, why would we need to join them up - into the same visual style too, isn't it more work to do, and - harder to maintain? - - - - Harder to maintain, more work to do, probably. Specially when - you consider that &TCP; has proven stability and consistency - through time and, that, certainly, didn't come through - swinging magical wands or something but hardly working out to - automate tasks and providing maintainance through time. With - that in mind, we consider &TCPCVIS; must be consequent with - such stability and consistency tradition. It is true that - &TCBRAND; does connect all the visual manifestations it is present - on, but that connection is strengthened if one unique visual - style backups it. In fact, whatever thing you do to strength - the visual connection among &TCP; visual manifestations would - be very good in favor of &TCP; recognition. - - - - Obviously, having just one visual style in all visual - manifestations for eternity would be a very boring thing and - would give the idea of a visually dead project. So, there is - no problem on creating a brand new visual style for each new - major release of &TCD;, in order to refresh &TCD; visual - style; the problem itself is in not propagating the brand new - visual style created for the new release of &TCD; to all other - visual manifestations &TCP; is made of, in a way &TCP; could - be recognized no matter what visual manifestation be in front - of us. Such lack of uniformity is what introduces the visual - contradition we are precisely trying to solve by mean of - themes production in &TCAR;. - - - diff --git a/Documentation/Tcar-ug/Identity/Showroom.docbook b/Documentation/Tcar-ug/Identity/Showroom.docbook deleted file mode 100644 index db87232..0000000 --- a/Documentation/Tcar-ug/Identity/Showroom.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - The CentOS Showroom - ... - - - ... - ... - - - diff --git a/Documentation/Tcar-ug/Identity/Web.docbook b/Documentation/Tcar-ug/Identity/Web.docbook deleted file mode 100644 index 5a5ba5d..0000000 --- a/Documentation/Tcar-ug/Identity/Web.docbook +++ /dev/null @@ -1,7 +0,0 @@ - - - The CentOS Web - - &identity-web-intro; - - diff --git a/Documentation/Tcar-ug/Identity/Web/intro.docbook b/Documentation/Tcar-ug/Identity/Web/intro.docbook deleted file mode 100644 index 956fa35..0000000 --- a/Documentation/Tcar-ug/Identity/Web/intro.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Introduction - - - ... - - - diff --git a/Documentation/Tcar-ug/Locales.docbook b/Documentation/Tcar-ug/Locales.docbook deleted file mode 100644 index 656b9d8..0000000 --- a/Documentation/Tcar-ug/Locales.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Localization - - - ... - - - - ... - ... - - - ... - ... - - - - - - diff --git a/Documentation/Tcar-ug/Locales.ent b/Documentation/Tcar-ug/Locales.ent deleted file mode 100644 index 48245e8..0000000 --- a/Documentation/Tcar-ug/Locales.ent +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/Documentation/Tcar-ug/Manuals.docbook b/Documentation/Tcar-ug/Manuals.docbook deleted file mode 100644 index 44bacd4..0000000 --- a/Documentation/Tcar-ug/Manuals.docbook +++ /dev/null @@ -1,30 +0,0 @@ - - - Documentation - - - - &TCAR; documentation work line is implemented through - documentation manuals. Documentation manuals are - implemented through different documentation formats - provided inside &TCD; (e.g., - Docbook, - Texinfo, - LaTeX, etc.). Structuring - tasks related to documentation systems (e.g., creating, - editing, deleting, copying, renaming, etc.) are - standardized through the help functionality - of centos-art.sh script, as described - in . This way, people - writting documentation don't need to deal with underlaying - tasks like creating files, updating menus, nodes, cross - references and wondering where to put everything in - &TCAR;. - - - - - &manuals-production; - &manuals-formats; - - diff --git a/Documentation/Tcar-ug/Manuals.ent b/Documentation/Tcar-ug/Manuals.ent deleted file mode 100644 index c68bc34..0000000 --- a/Documentation/Tcar-ug/Manuals.ent +++ /dev/null @@ -1,13 +0,0 @@ - - - - - - - - - - - - - diff --git a/Documentation/Tcar-ug/Manuals/Formats.docbook b/Documentation/Tcar-ug/Manuals/Formats.docbook deleted file mode 100644 index 9fac62b..0000000 --- a/Documentation/Tcar-ug/Manuals/Formats.docbook +++ /dev/null @@ -1,10 +0,0 @@ - - - Documentation Formats - - &manuals-formats-intro; - &manuals-formats-texinfo; - &manuals-formats-docbook; - &manuals-formats-latex; - - diff --git a/Documentation/Tcar-ug/Manuals/Formats/docbook.docbook b/Documentation/Tcar-ug/Manuals/Formats/docbook.docbook deleted file mode 100644 index 99935e3..0000000 --- a/Documentation/Tcar-ug/Manuals/Formats/docbook.docbook +++ /dev/null @@ -1,47 +0,0 @@ - - - DocBook - - - This section describes the implementation of DocBook - documentation format inside the help - functionality of centos-art.sh script described in . In this section we assume you - have a basic understanding of DocBook documentation system. - - - - Document Structure - - ... - - - - - Document Templates - - ... - - - - - Document Expansions - - ... - - - - - Document Configuration - - ... - - - - - Document Internationalization - - ... - - - diff --git a/Documentation/Tcar-ug/Manuals/Formats/intro.docbook b/Documentation/Tcar-ug/Manuals/Formats/intro.docbook deleted file mode 100644 index 8facc02..0000000 --- a/Documentation/Tcar-ug/Manuals/Formats/intro.docbook +++ /dev/null @@ -1,26 +0,0 @@ - - - Introduction - - - &TCD; provides support for different documentation formats, - including Texinfo, LaTeX, DocBook and LinuxDoc. These formats - have their own specifications and requirements to create and - maintain documentation manuals written through them. Inside - &TCAR;, the help functionality of - centos-art.sh script provides an interface - where documentation format specifications have been already - considered for you to be able of creating and maintaining - documentation manuals without needing to take care of those - underlaying structuring tasks. - - - - This chapter describes how the help - functionality of centos-art.sh script - implements the different documentation source formats - available inside &TCD;, and the internationalization - issues related to documentation manuals produced through them. - - - diff --git a/Documentation/Tcar-ug/Manuals/Formats/latex.docbook b/Documentation/Tcar-ug/Manuals/Formats/latex.docbook deleted file mode 100644 index 6440ea2..0000000 --- a/Documentation/Tcar-ug/Manuals/Formats/latex.docbook +++ /dev/null @@ -1,47 +0,0 @@ - - - LaTeX - - - This section describes the implementation of LaTeX - documentation format inside the help - functionality of centos-art.sh script described in . In this section we assume you - have a basic understanding of LaTeX language. - - - - Document Structure - - ... - - - - - Document Templates - - ... - - - - - Document Expansions - - ... - - - - - Document Configuration - - ... - - - - - Document Internationalization - - ... - - - diff --git a/Documentation/Tcar-ug/Manuals/Formats/texinfo.docbook b/Documentation/Tcar-ug/Manuals/Formats/texinfo.docbook deleted file mode 100644 index 5efdce2..0000000 --- a/Documentation/Tcar-ug/Manuals/Formats/texinfo.docbook +++ /dev/null @@ -1,835 +0,0 @@ - - - Texinfo - - - This section describes the implementation of Texinfo - documentation format inside the help - functionality of centos-art.sh script - described in . In this - section we assume you have a basic understanding of Texinfo - documentation system. Otherwise, if you don't know what - Texinfo documentation system is, read the Texinfo manual first - (e.g., by running the info texinfo command) - and then, come back here. - - - - Document Structure - - The help functionality of - centos-art.sh provides a document structure - that makes documentation manuals created through it to be - scalable and maintainable through time. This document - structure follows the idea of an upside-down tree to organize - chapters, sections, subsections and the like, as described in - . - - - - The first time you use the help - functionality to create a documentation manual in Texinfo - format, the help functionality considers - the working directory you are placed in to determine where to - store the documentation manual source files. When the current - working directory is branches/Manuals/Texinfo, the - documentation manual directory is created therein. On all - other situations, the documentation manual directory is - created under trunk/Manuals directory. Once - the documentation manual directory has been created, the - help functionality creates the related - definition files using Texinfo documentation templates, as - described in . - - - - Inside the documentation manual directory, source files are - stored inside language-specific directories. The - language-specific directories are necessary to implement - internationalization of Texinfo source files, as described in - . - - - - Inside the language-specific directory, the following files - exist to store the manual's main definitions (e.g., title, - subtitle, author, copyright notice, chapters, appendixes, - indexes and all the similar stuff a documentation manual would - have). In addition to these files, there is one directory for - each chapter created inside the manual. Inside each chapter - directory, you'll found the files controlling the section - definitions related to that chapter they belong to. The - section files (a.k.a. documentation entries) - are suffixed with a texinfo extension and named - arbitrarily, as it is illustrated in . - Inside section files it is where you write the manual's - content itself. - - - - Texinfo document structure - - Texinfo document structure - - - trunk/Manuals/${MANUAL_NAME} -`-- ${LANG} - |-- ${CHAPTER_NAME} - | |-- chapter-menu.texinfo - | |-- chapter-nodes.texinfo - | |-- chapter.texinfo - | `-- ${SECTION_NAME}.texinfo - |-- Licenses - | |-- chapter-menu.texinfo - | |-- chapter-nodes.texinfo - | `-- chapter.texinfo - |-- ${MANUAL_NAME}.conf - |-- ${MANUAL_NAME}-index.texinfo - |-- ${MANUAL_NAME}-menu.texinfo - |-- ${MANUAL_NAME}-nodes.texinfo - `-- ${MANUAL_NAME}.texinfo - - - - - - - Texinfo (as in texinfo-4.8-14.el5) doesn't - support part sectioning inside documentation manuals, so - neither does the help functionality of - centos-art.sh script. Nevertheless, you can - create several documentation manuals and - considered them as part of a bigger - documentation manual to workaround this issue. - - - - In this document structure, the creation of documentation - manuals, chapters and sections is not limitted. You can create - as many documenation manuals, chapters and sections as you - need. The only limitation would be the amount of free space - required to store the Texinfo source files and the output - files produced from them. - - - - - - Document Templates - - Texinfo document templates provide the initial state the - help functionality of - centos-art.sh script needs in order to - create and maintain document structures, as that one described - in . - - - - Texinfo document templates are language-specific. This means - that there is (or, at least, must be) one Texinfo document - template for each language you plan to support documentation - manuals for. By default, &TCAR; provides a default Texinfo - document template under en_US - directory. This template structure is used when your current - locale is English language or when you are creating/editing a - documentation manual in a language other than English, but no - language-specific document template for that language exists - in the directory: - - - -trunk/Scripts/Bash/Functions/Help/Texinfo/Templates - - - This directory organizes all Texinfo document templates using - the format LL_CC, where LL is the language code (as in - ISO-639) and CC the country code (as in ISO-3166). The - directory structure of Texinfo document templates is - illustrated in the and - implemented through the following files: - - - - - manual.texinfo - - - This file can be found inside the language-specific directory - and contains the manual's main definitions (e.g., document - title, document language, document authors, copyright notice, - etc.). - - - - - - manual-menu.texinfo - - - This file can be found inside the language-specific directory - and contains the menu definitions of chapters inside the - manual. Menu definitions in this file are automatically - updated when a new chapter is created or deleted through the - help functionality of - centos-art.sh script. Generally, you don't - need to edit this file once the documentation manual has been - created. - - - When a documentation manual is created for first time, this - file is copied from Texinfo document template directory - structure to the documentation manual being currently created. - At this specific moment, this file contains the following - Texinfo menu definition: - - - @menu -* Licenses:: -* Index:: -@end menu - - - Later, when chapters are added to or deleted from the - documentation manual, the content of this file varies adding - or deleting menu entries accordingly. Nevertheless, the two - entries shown above are ignored when new chapters are added to - or removed from the list, so they will always be present in - this file. To preserve the manual consistency, the - help functionality prevents you from - deleting any of these chapters once the documentation manual - has been created. - - - - - - - manual-nodes.texinfo - - - This file can be found inside the language-specific directory - and contains the node definitions of all chapters inside the - manual. Node definitions in this file are automatically - created based on menu definitions (see - manual-menu.texinfo file above) and they - don't include any content here. Instead, as part of the node - definition, the @include command is used to - connect each node with its content. Generally, you don't need - to edit this file once the documentation manual has been - created. - - - - - - manual-index.texinfo - - - This file can be found inside the language-specific directory - and contains the Texinfo commands used to generated an - organized view of all indexes you defined inside documentation - entries so they can be quickly accessed. Generally, you don't - need to edit this file once the documentation manual has been - created. - - - - - - manual.conf - - - This file contains the initial configuration of documentation - manuals written in Texinfo format. When a documentation manual - is created for first time, this file is copied into its target - directory so you be able of later customizing specific - information like menu order, title styles and template - assignments. The content of this file is described in . - - - - - - chapter.texinfo - - - This file contains the Texinfo's main chapter definition used - by help functionality when new chapters - are created inside documentation manuals. When chapters are - created for first time, they come without any introduction or - documentation entry inside. If you want to add/update any - information inside the chapter definition itself, edit the - related chapter file inside the documentation manual you are - working on, not the template file used to create it. - - - - - - chapter-menu.texinfo - - - This file is part of Texinfo's main chapter definition and - should be initially empty. Later, when chapters are created - for first time, this file is copied as it is (i.e., empty) - into the documentation manual to store the Texinfo menu - entries related to all documentation entries created inside - the chapter. The Texinfo menu entries related to documentation - entries are automatically created using Texinfo source files - as reference. - - - - - - chapter-nodes.texinfo - - - This file is part of Texinfo's main chapter definition and - contains the node definition the help - functionality uses as reference to create the list of Texinfo - nodes related to all documentation entries created inside the - chapter. The node definition of documentation entries is - automatically created from the menu definition of - documentation entries (see - chapter-menu.texinfo file above), once it - has been updated from Texinfo source files. - - - - - - section.texinfo - - - This file contains the Texinfo section definition used by - help functionality when new documentation - entries are created inside the chapters of a documentation - manual. When documentation entries are created for first time, - they are created as empty documentation entries that you need - to fill up with content. Again, if you want to update the - content of sections inside the documentation manual, update - the related documentation entry inside the documentation - manual, not the template file used to create it. - - - - The creation of documentation entries inside the documentation - manual is represented by the - ${SECTION_NAME}.texinfo file, as - described in . In - this example, ${SECTION_NAME} is a variable - string refering the file name of documentaiton entries. - The file names of documentation entries is made of letters, - numbers and the minus sign (which is generally used to - separate words). - - - - Documentation entries are not limited inside a documentation - manual. You can create as many documentation entries as you - need to describe the content of your manual. - - - - - - - There are other files which aren't related to manual's source - files, but to manual's output files. Such files are described - below and can be found either inside or outside the - language-specific directories so you can control common and - specific output settings through them. These files aren't - copied into the directory structure of new documentation - manuals created through the help - functionality of centos-art.sh script. - Instead, they remain inside the template directory structure - so as to be reused each time the output of documentation - manuals is rendered. - - - - - manual-init.pl - - - This file can be found inside and outside language-specific - directories and contains the Texi2html initialization script. - When this file is outside the language-specific directory, it - contains common customizations to all language-specific - outputs (e.g., changing the output DTD). When this file is - inside the language-specific directory, it contains - translations for that language-specific output (e.g., special - words like See, Index, Contents, Top, etc., are localized - here). - - - - - - manual.sed - - - This file can be found inside and outside language-specific - directories and contain special transformations for Texi2html - output. Again, when this file is inside language-specific - directories the transformation have are applied to that - language-specific XHTML output and when it is outside - language-specific directories the transformations are applied - to all language-specific XHTML outputs. Most transformations - achived through this file are to produce admonitions since - Texinfo documentation format (as in - texinfo-4.8-14.el5) doesn't have an - internal command to build them. - - - - - - - Texinfo document template - - Texinfo document template - - - trunk/Scripts/Bash/Functions/Help/Texinfo/Templates -|-- ${LANG} -| |-- Chapters -| | |-- chapter-menu.texinfo -| | |-- chapter-nodes.texinfo -| | |-- chapter.texinfo -| | `-- section.texinfo -| |-- Licenses -| | |-- GFDL.texinfo -| | |-- GPL.texinfo -| | |-- chapter-menu.texinfo -| | |-- chapter-nodes.texinfo -| | `-- chapter.texinfo -| |-- manual-index.texinfo -| |-- manual-init.pl -| |-- manual-menu.texinfo -| |-- manual-nodes.texinfo -| |-- manual.conf -| |-- manual.sed -| `-- manual.texinfo -|-- manual-init.pl -`-- manual.sed - - - - - - - Inside the directory structure of Texinfo document templates, - the Chapters directory - organizes chapter specific models used to create and maintain - both chapter and sections files inside manuals. On the other - hand, the Licenses - directory organizes the license information linked from all - manuals. Notice the license information is not copied into - documentation manuals when they are created, but refered from - this location where they are maintained. This configuration - permites that all documentation manuals written in Texinfo - format inside &TCAR; do use the same license information and - if a change is committed to the license files, such changes be - immediatly propagated to documentation manuals the next time - their output files be updated. - - - - - Document Expansions - - The document expansions are special constructions used to - generate content dynamically inside Texinfo source files. - - - - The <code>SeeAlso</code> Expansion - - - This expansion creates a list of links with section entries - one level ahead from the section entry being currently - processed. In this construction, the TYPE variable can be - either itemize, enumerate or - menu. When no TYPE variable is provided, the - itemize value is considered as default. - - - @c -- <[centos-art(SeeAlso,TYPE) -@c -- ]> - - - This expansion might result useful when you are documenting - the repository file system. For example, if you are currently - editing the documentation entry related to trunk/Identity directory and want - to create a linkable list of all documentation entries in the - first level under it, the code you'll have once the - construction be expanded would look like the following: - - - -@c -- <[centos-art(SeeAlso) -@itemize -@item @ref{Trunk Identity Brushes} -@item @ref{Trunk Identity Fonts} -@item @ref{Trunk Identity Images} -@item @ref{Trunk Identity Models} -@item @ref{Trunk Identity Palettes} -@item @ref{Trunk Identity Patterns} -@item @ref{Trunk Identity Webenv} -@end itemize -@c -- ]> - - - - An interesting thing to notice here is that document - expansions are executed each time the related documentation - entry is edited or updated. Following with the example above, - if the documentation entries related to directories under - trunk/Identity changes - for some reason (e.g., they are removed from documentation - manual), the list generated as result of document expansion - will be updated automatically after editing the documentation - entry or updating the documentation manual structure. - - - - - - - - Document Configuration - - The document configuration is stored in the - ${MANUAL_NAME}.conf file, inside the - documentation manual directory structure. This file is - originally copied from manual.conf - template file when the documentation manual is created for - first time. The content of - ${MANUAL_NAME}.conf file is organized in - sections. Each section here is written in one line of its own - and have the form [section_name]. Under sections, - the configuration settings take place through - name="value" pairs set in one line each. Notice - that quotation marks around the option_value are required. - Comments are also possible using the # character - at the begining of lines. Comments and empty lines (including - tabs and white spaces) are ignored. In case more than one - section or option appear with the same name inside the - configuration file, the first one found will be used. Nested - section definitions are not supported. - - - [section_name] -# This is a comment. -option_name = "option_value" - - - The ${MANUAL_NAME}.conf file is specific - to document templates. If you are using Texinfo document - template to create documentation manuals, then the default - configuration file for that documentation manual is taken from - Texinfo document template directory structure. However, if you - are using a document template different to Texinfo document - template, the default configuration file will be taken from - the related document template directory structure you are - creating the documentation manual from. - - - - The <code>[main]</code> Section - - The [main] section organizes settings that let - you customize the way sections and menu definitions are - created inside the documentation manual. The following options - are available in this section: - - - - - manual_format - - - This option specifies the documentation format used by manual. - To write documentation manuals in Texinfo format, the value - of this option must always be: - - manual_format = "texinfo" - - - Once the documentation manual has been created, you must not - change the value of option. - This will produce an error. - - - - - - - manual_section_style - - - This option specifies the title style used by sections inside - the manual. Possible values to this option are - `cap-each-word' to capitalize each word in the section title, - `cap-first-word' to capitalize the first word in the section - title only and `directory' to transform each word in the - section title into a directory path. From all these options, - `cap-each-word' is the one used as default. - - manual_section_style = "cap-each-word" - - - - - manual_section_order - - - This option specifies the order used by sections inside the - manual. By default new sections added to the manual are put on - the end to follow the section order in which they were - `created'. Other possible values to this option are `ordered' - and `reversed' to sort the list of sections alphabetically - from A-Z and Z-A, respectively. - - manual_section_order = "created" - - - - - - - The <code>[templates]</code> Section - - The [templates] section provides the assignment - relation between template files and documentation entry files - inside the manual. The template definition is set on the left - side using relative path and the documentation entry files are - described on the right side using a regular expression. The - first match wins. - - Chapters/section.texinfo = "^.+\.texinfo$" - - - - - - Document Internationalization - - To produce localized documentation manuals through Texinfo - documentation format it is necessary to create one - documentation manual for each language it is desired to - support documentation for. Documentation manuals created in - this configuration don't have a direct relation among - themselves except that one adopted by people writting them to - keep their content syncronized. In this configuration - translators take one documentation manual as reference (a.k.a. - the source manual) and produce several translated manuals - based on its content. To keep track of changes inside the - source manual, the underlaying version control system must be - used considering that there is no direct way to apply - gettext - - The gettext program translates - a natural language message into the user's language, by - looking up the translation in a message catalog. For more - information about the gettext - program, run info gettext. - - procedures to Texinfo source files. - - - - In order to maintain localization of Texinfo source files - through gettext procedures, it is - necessary to convert the Texinfo source files into - XML format first. This way it would be possible to make use of - locale and render - functionalities from centos-art.sh script - to maintain translation messages in different languages - through portable objets and producing localized XML files - based on such portable objects, respectively. Once the - localized XML file is available, it would be a matter of using - an XSLT processor (see the xsltproc - command) to realize the convertion from XML to a localize - Texinfo (or possible other) format. Nevertheless, this - workaround fails because the Document Type Definition (DTD) - required to validate the XML file produced from - makeinfo (as in - texinfo-4.8-14.el5) is not availabe inside - &TCD; (release 5.5), nor it is the XSLT files required to - realize the transformation itself for such DTD. - - - - Another similar approach to maintain localization of Texinfo - source files through gettext - procedures would be to convert Texinfo source file to DocBook - format; for who the required DTD and XSLT files are available - inside &TCD;. This way, following a procedure similar to that - one describe for XML files above, it would be possible to end - up having localized DocBook files that can be used as source - to produce localized output for both online and printing - media. However, the DocBook output produced from - makeinfo command (as in - texinfo-4.8-14.el5) isn't a valid DocBook - document according to DocBook DTDs available inside &TCD; - (release 5.5) thus provoking the validation and transformation - of such a malformed document to fail. - - - - Document Language - - The language information of those documentation manuals - produced through Texinfo documentation format is declared by - Texinfo's @documentlanguage command. This - command receives one argument refering the language code (as - in ISO-639 standard) and must be set inside the manual's main - definition file. Generally, there is no need to change the - document language declaration once it has been created by the - help functionality of - centos-art.sh script; unless you - mistakently create the manual for a locale code different to - that one you previously pretended to do in first place, of - course. - - - - The language information used in both Texinfo source files and - XHTML output produced by the help - functionality of centos-art.sh script is - determined by the user's session LANG - environment variable. This variable can be customized in the - graphical login screen before login, or once you've login by - explicitly setting the value of LANG - environment variable inside the - ~/.bash_profile file. - - - - - To create documentation manuals in English language the - LANG environment variable must be set to - en_US.UTF-8 or something similar. Likewise, if - you want to create documentation manuals in a language other - than English, be sure the LANG environment - variable is set to the appropriate locale code. - - The appropriate locale code to set here can be found in - the output produced by the locale -a | - less command. - - - - - - When producing output from Texinfo source files using the - makeinfo command (as in the - texinfo-4.8-14.el5 package), the language - information set by @documentlanguage is ignored - in Info and HTML output, but cosidered by Tex program to - redefine various English words used in the PDF output (e.g., - Chapter, Index, - See, and so on) based on the current language - set in. - - - - - - Document Encoding - - The encoding information of documentation manuals produced - through Texinfo documentation format is declared by Texinfo's - @documentencoding command and can take either - US-ASCII, ISO-8859-1, - ISO-8859-15 or ISO-8859-2 as - argument. Nevertheless, you should be aware that the - help functionality of - centos-art.sh script doesn't declare the - @documentencoding inside Texinfo source files. - Let's see why. - - - - When the @documentencoding command is set in - Texinfo source files, the terminal encoding you use to read - the Info output produced from such files must be set to that - encoding information you provided as argument to - @documentencoding command; this, before using an - Info reader to open the Info output file in the terminal. - Otherwise, when the terminal and the Texinfo source files - encoding definition differ one another, characters defined - through Texinfo's special way of producing floating accents - won't be displayed as expected (even when the - is provided to - makeinfo command). On the other hand, when - the @documentencoding command is not set in - Texinfo source files, it is possible to write and read - documentation manuals using the UTF-8 encoding without needing - to use Texinfo's special way of producing floating accents - because the terminal encoding would be able to interpret the - characters entered when the Texinfo source files were written - in first place. - - - - When Texinfo's special way of producing floating accents isn't - used, HTML entities are not produced in XHTML output produced - by texi2html, nor in the HTML output - produced by makeinfo, nor in PDF output. - In this last case, when producing PDF output, you can realize - what the floating accents are by trying to produce an - accentuated Spanish i letter (e.g., - í). When you do so, you'll note that that - construction puts the accentuation mark - over the i letter's dot, - instead of removing the i letter's dot and - put the accentuation mark on its place. In the case of XHTML - output, however, it possible to produce well localized XHTML - output by setting - - - <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> - - - on the head section of each XHTML output to instruct the web - browsers what encoding to use to display the document content. - Of course, in order to display the document content correctly, - the web browser should provide support for UTF-8 encoding. - - - - These contradictions provide the reasons over which it was - decided not to set the @documentencoding in those - Texinfo source files produced by the help - functionality of centos-art.sh script. Now, - considering them, we can conclude that it is no viable way to - localize Texinfo source files through - gettext procedures so one - documentation manual must be created for each language we - desire to support documentation for. In this configuration, - it is difficult the production of well localized PDF output, - but it is possible to produce well localized Info, Text, and - XHTML outputs as long as no document encoding be explicitly - set inside Texinfo source files and UTF-8 be used as default - terminal character encoding. - - - - - - - - diff --git a/Documentation/Tcar-ug/Manuals/Production.docbook b/Documentation/Tcar-ug/Manuals/Production.docbook deleted file mode 100644 index 58451f0..0000000 --- a/Documentation/Tcar-ug/Manuals/Production.docbook +++ /dev/null @@ -1,12 +0,0 @@ - - - Documentation Production Cycle - - &manuals-production-intro; - &manuals-production-identifying-goals; - &manuals-production-identifying-title; - &manuals-production-identifying-structure; - &manuals-production-implementing-structure; - &manuals-production-maintaining-structure; - - diff --git a/Documentation/Tcar-ug/Manuals/Production/identifying-goals.docbook b/Documentation/Tcar-ug/Manuals/Production/identifying-goals.docbook deleted file mode 100644 index ace14cc..0000000 --- a/Documentation/Tcar-ug/Manuals/Production/identifying-goals.docbook +++ /dev/null @@ -1,50 +0,0 @@ - - - Identifying Document Goals - - - The first step in producing a documentation manual is to - clearly understand what you exactly need to document and why - you need to do so. The obvious answer to this question would - be to describe the basic ideas behind an implementation so it - can be useful once published. It is important that you find - out the reasons you need to do what you are doing and, also, - those helping you to retain the motivation to keep doing it in - the future. Otherwise, without such foundations, you'll surely - end up leaving the effort soon enough to make a lost cause - from your initial work. - - - - Before The CentOS Artwork Repository File - System documentation manual exist, there was an - emerging need to understand what each directory inside the - growing directory layout was for, how they could be used and - how they could be connected one another. At that moment, the - directory layout was very unstable and explaining the whole - idea behind it was not possible, there were too many changing - concepts floating around which needed to be considered in the - same changing way. So, to understand what was happening, the - The CentOS Artwork Repository File - System documentation manual was created. - - - - The The CentOS Artwork Repository File - System manual was conceived based on the idea of - individually documenting each directory inside the repository - and, later, by considering all directory documentations - together, it would be (hypothetically) possible to correct the - whole idea through an improvement cycle that would consolidate - the final idea we try to implement. - - - - Other documentation manuals can be based on reasons different - from those described above, however, no matter what those - reasons be, it will be helpful to make yourself a clean idea - about what you are going to document exactly before putting - your hands on it. - - - diff --git a/Documentation/Tcar-ug/Manuals/Production/identifying-structure.docbook b/Documentation/Tcar-ug/Manuals/Production/identifying-structure.docbook deleted file mode 100644 index a8ac28b..0000000 --- a/Documentation/Tcar-ug/Manuals/Production/identifying-structure.docbook +++ /dev/null @@ -1,142 +0,0 @@ - - Identifying Document Structure - - Once both the manual's title and the manual's directory name - have been defined, it is time for you to plan the document - structure through which the manual's content will be - organized. - - - - The document structure of documentation manuals is specific to - that documentation format used to write documentation source - files. Nevertheless, no matter what the documentation format - be, the document structure produce produced from the - help functionality of - centos-art.sh script follows and - upside-down tree configuration. In this configuration, - documentation manuals can be organized through parts, - chapters, sections, and several subsection levels based in - whether the chosen documentation format supports them or not. - - - - Considering the The CentOS Artwork Repository File - System documentation manual, we already know that - it was conceived to document each directory structure &TCAR; - is made of using Texinfo format and the sectioning levels - supported by it. At this point we phase that &TCAR; has more - levels deep than sectioning commands available inside Texinfo - formats. This way it is not possible to use one sectioning - command for each directory level inside the repository - directory structure we need to document. Based on these - issues, it is imperative to reaccomodate the document - structure in order to be able of documenting every directory - &TCAR; is made of, using the sectioning levels supported by - most documentation formats inside &TCD;, no matter how many - levels deep the repository directory structure has. - - - - As consequence, The CentOS Artwork Repository File - System ended up being organized through the - following documentation structure: - - - - - Chapter 1. The trunk - Directory - - - This chapter describes the trunk directory inside the - repository and all subdirectories inside it. The first level - of directories (i.e., the trunk directory itself) is - described inside the chapter entry. Deeper directory levels - are all documented through sections and have a file for their - own. It is also possible to write subsections and - subsubsections, however, they don't have a file for their own - as sections do. Subsections and Subsubsections should be - written as part of section files (i.e., when writting - sections). - - - - - - Chapter 2. The branches - Directory - - - This chapter describes the branches directory and all - directories inside it following the same structure described - for trunk directory - above. - - - - - - Chapter 3. The tags - Directory - - - This chapter describes the tags directory and all - directories inside it following the same structure described - for trunk directory - above. - - - - - - Appendix A. Licenses - - - This appendix is confined to organize licenses mentioned - in the manual. The content of this appendix is out of - documenatation manual scope itself and is shared among all - documentation manuals written through the - help of centos-art.sh - script inside &TCAR;. - - - - - - Index - - - This chapter organizes links to those index definitions you - defined inside the documentation manual. The index information - displayed by this chapter is auto-generated each time the - manual's output files are created so this chapter is not - editable. - - - - - - - The document structure illustrated above is also considered - the default document structure used by the - help functionality of - centos-art.sh script when you produce new - documentation manuals inside &TCAR;. In contrast with document - structure illustrated above, the default document structure - used by help functionality doesn't - include sectioning constructions like parts, chapters, - sections, subsections and the like. Such structuring - constructions should be specified by you when building the - documentation manual. The only exceptions to this restriction - are sectioning structures used to organize contents like - Index and Licenses, which are - considered inseparable components of documentation manuals - stored inside &TCAR;. - - - diff --git a/Documentation/Tcar-ug/Manuals/Production/identifying-title.docbook b/Documentation/Tcar-ug/Manuals/Production/identifying-title.docbook deleted file mode 100644 index 7f71b82..0000000 --- a/Documentation/Tcar-ug/Manuals/Production/identifying-title.docbook +++ /dev/null @@ -1,26 +0,0 @@ - - Identifying Document Title - - Once you've make yourself an clean idea of what the - documentation manual is for and the needs behind, it is time - for you to define the manual's title and the manual's - directory name. Both manuals' title and manual's directory - name describe what the documentation manual is about. The - manual's title is used inside the documentation while the - manual's directory name is used to store the related source - files inside &TCAR; directory structure. Generally, the - manual's title is a phrase of few words and the manual's - directory name is the abbreviation of that phrase set as - manual's title. - - - - Following with our example, the manual's title chosen was - The CentOS Artwork Repository File - System and its directory name was set to - Tcar-fs to comply with the - file name convenctions described at . - - - diff --git a/Documentation/Tcar-ug/Manuals/Production/implementing-structure.docbook b/Documentation/Tcar-ug/Manuals/Production/implementing-structure.docbook deleted file mode 100644 index 0f34347..0000000 --- a/Documentation/Tcar-ug/Manuals/Production/implementing-structure.docbook +++ /dev/null @@ -1,53 +0,0 @@ - - - Implementing Document Structure - - - This section describes the steps you should follow to - implement document structures like that one described in . - - - - Creating Document Structure - - - To create new documentation manuals inside &TCAR; you need to - use the help functionality of - centos-art.sh script, as shown in the - following command: - - - centos-art help --edit "manual-name" - - - The first time you execute this command, you will be prompted - to enter manual specific information like document format, - document title, document subtitle, document author, etc. Once - this information has been collected the - help functionality performs some - repository verifications and creates the manual source files - inside the manual's directory name you specified as - manual-name. - - - - When you create new documentation manuals, take care of the - locale information you are currently using. This information - is generally set in the LANG environment - variable and is used by the help - functionality of centos-art.sh script to - define the language of new documentation manual and the - document template used to build it, as well. - - - - Once the documentation structure has been created this way, - the recently created documentation manual is ready to receive - new chapters and sections as it is described in . - - - - - diff --git a/Documentation/Tcar-ug/Manuals/Production/intro.docbook b/Documentation/Tcar-ug/Manuals/Production/intro.docbook deleted file mode 100644 index 5b3f328..0000000 --- a/Documentation/Tcar-ug/Manuals/Production/intro.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Introduction - - - This chapter describes the procedure you should follow to - create and maintain documentation manuals inside &TCAR;. - - - - This chapter describes general concepts that can be applied - through the documentation formats supported inside the - help functionality of - centos-art.sh script. To illustrate the - production process related to documentation manuals inside - &TCAR;, this chapter uses the The CentOS Artwork - Repository File System (TCAR-FS) documentation - manual as example. - - - diff --git a/Documentation/Tcar-ug/Manuals/Production/maintaining-structure.docbook b/Documentation/Tcar-ug/Manuals/Production/maintaining-structure.docbook deleted file mode 100644 index fcd7d83..0000000 --- a/Documentation/Tcar-ug/Manuals/Production/maintaining-structure.docbook +++ /dev/null @@ -1,99 +0,0 @@ - - - Maintaining Document Structure - - - This section describes the steps you should follow to maintain - documentation structures like that one described in . - - - - Editing Document Structure - - - - - centos-art help --edit "tcar-fs::trunk" - - - - This command creates the base structure for the - trunk chapter and opens its main definition - file with your favorite text editor so you can update the - chapter introduction. This very same procedure is used to - create branches and tags - chapters, just be sure to change the chapter field - accordingly. - - - - - - - centos-art help --edit "tcar-fs::trunk:identity" - - - - This command creates the identity section - inside the trunk chapter. If the chapter - doesn't exist it will be created first. In this command, the - identity section refers to trunk/Identity directory inside - &TCAR;. In order to document other directories, follow the - same procedure but using minus signs to separate directories. - For example, to document the trunk/Identity/Models/Themes - directory you should use the - tcar-fs::trunk:identity-models-themes - documentation entry. - - - - - In the very specific case of - TCAR-FS manual, it is also possible - to refer chapters and sections using a path/to/dir format. - For example, the reference - tcar-fs::trunk:identity-models-themes - can be also specified as trunk/Identity/Models/Themes, - in case you feel more confortable with it than the former - one. - - - - - - - - - Copying Document Structure - - ... - - - - - Deleting Document Structure - - ... - - - - - Renaming Document Structure - - ... - - - - - Updating Document Structure - - ... - - - - diff --git a/Documentation/Tcar-ug/Repository.docbook b/Documentation/Tcar-ug/Repository.docbook deleted file mode 100644 index 739870e..0000000 --- a/Documentation/Tcar-ug/Repository.docbook +++ /dev/null @@ -1,90 +0,0 @@ - - - Repository - - - - Welcome to &TCARUG;, the official documentation of &TCAR;. - - - - This book describes the corporate visual identity of &TCP; and - the way it is produced. If you are interested in making &TCP; - a more beautiful project, this book is definitly for you. - - - - To make the information in this book managable, it has been - organized in the following parts: - - - - - - describes the convenctions you should - follow to keep everything organized and consistent inside the - repository directory structure, how to to install and - configure a working copy inside your workstation. At the end - of this part you will find a history of most relevant changes - committed to the repository along the years. - - - - - - describes the corporate visual - identity of the organization known as &TCP; and the production - tasks related to image rendition inside &TCAR;. If you are a - graphic designer, this part of the book might result - interesting to you. - - - - - - describes production tasks related to - content internationalization and localization inside &TCAR;. - If you are a translator, this part of the book might result - interesting to you. - - - - - - describes production tasks related - to content documentation inside &TCAR;. If you are a - documentor, this part of the book might result interesting to - you. - - - - - - describes automation of production - tasks inside &TCAR;. If you are a programmer, this part of the - book might result interesting to you. - - - - - - organizes the licenses mentioned - in this book. - - - - - - - This book assumes you have a basic understanding of &TCD;. If - you need help with it, go to the Help page inside - &TCWIKI; for or a list of different places you can find help. - - - - &repo-convs; - &repo-ws; - &repo-history; - - diff --git a/Documentation/Tcar-ug/Repository.ent b/Documentation/Tcar-ug/Repository.ent deleted file mode 100644 index e0f889f..0000000 --- a/Documentation/Tcar-ug/Repository.ent +++ /dev/null @@ -1,25 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions.docbook b/Documentation/Tcar-ug/Repository/Convenctions.docbook deleted file mode 100644 index 71f68f8..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - Repository Convenctions - - &repo-convs-mission; - &repo-convs-layout; - &repo-convs-worklines; - &repo-convs-filenames; - &repo-convs-relbdirs; - &repo-convs-syncpaths; - &repo-convs-extending; - &repo-convs-publishing; - &repo-convs-authoring; - &repo-convs-copying; - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/authoring.docbook b/Documentation/Tcar-ug/Repository/Convenctions/authoring.docbook deleted file mode 100755 index bc4d243..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/authoring.docbook +++ /dev/null @@ -1,30 +0,0 @@ - - - Repository Authoring - - - The content produced inside &TCAR; is copyright of &TCP;. - This is something you, as author, should be aware of because - you are contributing your creation's rights to someone else; - &TCP; in this case. This way, your work is distributed using - &TCP; as copyright holder, not your name (even - you remain as natural author of the work). Because &TCP; is - the copyright holder, is the license chosen by &TCP; the one - applied to your work, so it is the one you need to agree with - before making a creation inside &TCAR;. - - - - &TCP; is a community project controlled by its own community - of users. Inside the community, The CentOS Administrators - group is the higher authority and the only one able to set - core desition like the kind of license used inside the project - and subprojects like &TCAR;. - - - - The redistribution conditions of &TCAR; are described in . - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/copying.docbook b/Documentation/Tcar-ug/Repository/Convenctions/copying.docbook deleted file mode 100755 index 36658fa..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/copying.docbook +++ /dev/null @@ -1,60 +0,0 @@ - - - Repository Copying Conditions - - - &TCP; uses &TCAR; to produce &TCP; corporate visual identity. - - - - The &TCAR; is not in the public domain; it is copyrighted and - there are restrictions on their distribution, but these - restrictions are designed to permit everything that a good - cooperating citizen would want to do. What is not allowed is - to try to prevent others from further sharing any version of - this work that they might get from you. - - - - Specifically, we want to make sure that you have the right to - give away copies of &TCAR;, that you receive source code or - else can get it if you want it, that you can change this work - or use pieces of it in new free works, and that you know you - can do these things. - - - - To make sure that everyone has such rights, we have to forbid - you to deprive anyone else of these rights. For example, if - you distribute copies of the &TCAR;, you must give the - recipients all the rights that you have. You must make sure - that they, too, receive or can get the source code. And you - must tell them their rights. - - - - Also, for our own protection, we must make certain that - everyone finds out that there is no warranty for the &TCAR;. - If this work is modified by someone else and passed on, we - want their recipients to know that what they have is not what - we distributed, so that any problems introduced by others will - not reflect on our reputation. - - - - The &TCAR; is released as a GPL work. Individual packages - used by &TCAR; include their own licenses and the &TCAR; - license applies to all packages that it does not clash with. - If there is a clash between the &TCAR; license and individual - package licenses, the individual package license applies - instead. - - - - The precise conditions of the license for the &TCAR; are found - in . This manual specifically - is covered by the conditions found in . - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/extending.docbook b/Documentation/Tcar-ug/Repository/Convenctions/extending.docbook deleted file mode 100644 index 4df7761..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/extending.docbook +++ /dev/null @@ -1,44 +0,0 @@ - - - Extending Repository Layout - - - Occasionly, you may find that new components of &TCPCVI; need - to be added to the repository in order to work them out. If - that is the case, the first question we need to ask ourselves, - before starting to create directories blindly all over, is: - What is the right place to store it? - - - - To build a directory structure inside the repository you need - to define the concept behind it first. Later you need to - create a new directory inside the repository, remembering that - there are locations inside the repository that already define - concepts you probably would prefer to reuse. For example, the - trunk/Identity/Images/Themes - directory stores artistic motifs of different themes, the - trunk/Identity/Models/Themes - directory stores design models for themes, the trunk/Manuals directory stores - documentation, the trunk/Locales stores translation - messages, and the trunk/Scripts stores automation - scripts. - - - - The best suggestion we can probably give you would be to send - a mail with your questions to the CentOS developers mailing - list (centos-devel@centos.org). - This is the place where development of &TCAR; takes place and - surely, in community, it will be possible to find a place for - your new component inside the repository. - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/filenames.docbook b/Documentation/Tcar-ug/Repository/Convenctions/filenames.docbook deleted file mode 100644 index 9cde7ba..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/filenames.docbook +++ /dev/null @@ -1,23 +0,0 @@ - - - Repository File Names - - - Inside &TCAR;, file names are all written in lowercase (e.g., - 01-welcome.png, - splash.png, - anaconda_header.png, etc.) and directory - names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel - case (e.g., TreeFlower, - etc.). In the very specific case of repository documentation - entries, file names follow the directory naming convenction. - This is because they are documenting directories and that is - something we want to remark. So, to better describe what we - are documenting, documentation entries follow the name - convenction used by the item they document. - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/layout.docbook b/Documentation/Tcar-ug/Repository/Convenctions/layout.docbook deleted file mode 100644 index 1977365..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/layout.docbook +++ /dev/null @@ -1,67 +0,0 @@ - - - Repository Layout - - - &TCAR; is supported by Subversion, a - version control system which allows you to keep old versions - of files and directories (usually source code), keep a log of - who, when, and why changes occurred, etc., like CVS, RCS or - SCCS. - - - - &TCAR; is made of one source repository and - many working copies of that source repository. - The working copies are independent one another, can be - distributed all around the world and provide a local place for - designers, documentors, translators and programmers to perform - their work in a descentralized way. The source repository, on - the other hand, provides a central place for all independent - working copies to interchange data and provides the - information required to permit extracting previous versions of - files at any time. - - - - The first level of directories inside &TCAR; provides - organization through a convenctional trunk/, branches/ and tags/ layout. As proposition we - are assuming that: - - - - - - The trunk/ - directory is where development changes take place. - - - - - - The branches/ - directory is where maintainance changes take place. - - - - - - The tags/ directory - is where final releases take place. - - - - - - The second level of directories inside &TCAR; provides - organization for different work lines, as described in . All other subsequent - directory levels from third level on exist to organize - specific concepts related to the work line they belong to. - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/mission.docbook b/Documentation/Tcar-ug/Repository/Convenctions/mission.docbook deleted file mode 100755 index d4a2c95..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/mission.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Repository Mission - - - &TCAR; exists to produce &TCP; corporate visual identity. - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/publishing.docbook b/Documentation/Tcar-ug/Repository/Convenctions/publishing.docbook deleted file mode 100755 index fe1447e..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/publishing.docbook +++ /dev/null @@ -1,59 +0,0 @@ - - - Repository Publishing - - - When you perform changes inside your working copy, those - changes are local to your working copy only. In order for you - to share your changes with others, you need to commit them up - to the central repository the working copy you are using was - initially downloaded from. To commit your changes up to the - central repository you use the commit - command from the Subversion's client you've installed in your - workstation. - - - - Initially, when you get registered inside &TCAR;, you won't be - able to publish your changes to &TCAR; immediatly. It is - necessary that you prove your interest in contributing first - sending a mail to the CentOS - Developers mailing list (centos-devel@centos.org), - preferably in conjunction with a description of the changes - you pretend to commit. This restriction is necessary in order - to protect the source repository from spammers. - - - - Once you've received access to publish your changes, they will - remain valid to you and there is no need for you to request - permission to publish new changes as long as you behave as a - good cooperating citizen. - - - - As a good cooperating citizen one understand of a person who - respects the work already done by others and share ideas with - authors before changing relevant parts of their work, - specially in situations when the access required to realize - the changes has been granted already. Of course, there is a - time when conversation has taken place, the paths has been - traced and changing the work is so obvious that there is no - need for you to talk about it; that's because you already did, - you already built the trust to keep going. As complement, the - mailing list mentioned above is available for sharing ideas in - a way that good relationship between community citizens could - be constantly balanced. - - - - The relationship between community citizens is monitored by - repository administrators. Repository administrators are - responsible of granting that everything goes the way it needs - to go in order for &TCAR; to accomplish its mission (see ). - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/relbdirs.docbook b/Documentation/Tcar-ug/Repository/Convenctions/relbdirs.docbook deleted file mode 100644 index d9c9474..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/relbdirs.docbook +++ /dev/null @@ -1,121 +0,0 @@ - - - Repository Path Types - - - In order for automation scripts to produce content inside a - working copy of &TCAR;, it is required that all work lines be - related somehow. The relation between work lines is used by - automation scripts to know where to retrive the information - they need to work with (e.g., input files, translation - messages, output locations, etc.). This kind of relation is - built using two path constructions known as master - paths and auxiliar paths. - - - - Master Paths - - - A master path refers to a directory inside the repository that - contain input files required to produce output files through - automation scripts. Examples of master paths inside the - repository include: - - - - - - trunk/Identity/Models/Brands - - - - - trunk/Manuals/Tcar-ug - - - - - trunk/Identity/Models/Themes/Default/Distro/5/Anaconda - - - - - - - - Auxiliar Paths - - - An auxiliar path refers to directories inside the repository - considered auxiliar for one single master path. Auxiliar path - can be either for output or localization. Assuming the master - path provides the input information, the auxiliar paths - provide the auxiliar information which describes how and where - that input information must be rendered by automation scripts. - Examples of auxiliar paths inside the repository include: - - - - - - trunk/Identity/Images/Brands - - - - - trunk/Manuals/Tcar-ug/es_ES - - - - - trunk/Locales/Manuals/Tcar-ug/es_ES - - - - - trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES - - - - - trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES - - - - - - The relationship between master and auxiliar paths is built by - combining the second directory level of master paths with - directories in the second directory level of repository - layout. In the second directory level of repository layout, - the Identity, Manuals and Scripts directories are always - used to create the master paths and the output auxiliar paths. - The Locales directory, - on the other hand, is always used to create localization - auxiliar paths for all the master paths available under - Identity, Manuals and Scripts directories. - - - - For example, if the LANG environment - variable is set to es_ES.UTF-8 and you execute - the render functionality of - centos-art.sh script with the trunk/Manuals/Tcar-ug master - path as argument, it will produce &TCARUG; in Spanish language - using translation messages from - trunk/Locales/Manuals/Tcar-ug/es_ES - auxiliar path and would save final documentation output files - under trunk/Manuals/Tcar-ug/es_ES - auxiliar path. - - - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/syncpaths.docbook b/Documentation/Tcar-ug/Repository/Convenctions/syncpaths.docbook deleted file mode 100644 index c4f30aa..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/syncpaths.docbook +++ /dev/null @@ -1,99 +0,0 @@ - - - Syncronizing Repository Paths - - - Once both master and auxiliar paths have been related in the - repository, they shouldn't be changed except you absolutly - need to do so. In this cases, when you need to change master - or auxiliar paths, it is required that you also change the - relation between them so as to retain their bond. This - process of keeping master and auxiliar paths - connected between themselves is known as - path syncronization. - - - - Path syncronization is required for automation scripts to know - where to store final output, where to retrive translation - messages from, and whatever information you might need to - count with. If the relation between master paths and auxiliar - paths is lost, there is no way for automation scripts to know - where to retrive the information they need to work with or - where to store the output information produced from it. - Through path syncronization we organize and extend the content - production inside the repository. - - - - Path syncronization affects both movement of files and - replacement of content inside files. Movement of files is - related to actions like renaming files and directories inside - the repository. Replacement of content inside files is - related to actions like replacing information (e.g., paths - information) inside files in order to keep file contents and - file locations consistent one another after a file has been - moved. - - - - The order followed to syncronize path information is very - important because the versioned nature of the files we are - working with. When a renaming action needs to be performed - inside the repository, we avoid making replacements inside - files first and file movements later. This would demand two - commit actions: one for the files' internal changes and - another for the file movement itself. Instead, we prefer to - perform file movements first and files' internal replacements - later. This way it is possible to commit both changes as if - they were just one. - - - - - There is no support for URLs actions inside - centos-art.sh script. The - centos-art.sh script is designed to work - with local files inside the working copy only. If you need to - perform URL actions directly, use Subversion's commands - instead. - - - - - At this moment there isn't full implementation of path - syncronization inside centos-art.sh script - and that is somthing we need to do oursleves. However, the - texinfo backend inside the - help functionality does provide a restricted - implementation of path syncronization to documentation area - through the , - and options. You can read this - implementation and use it as reference to implement path - syncronization in other areas. - - - - The plan for a full implementation of path syncronization - inside centos-art.sh script would be to - create individual restricted implementations like the one in - texinfo backend for other areas that demand it - and then, create a higher implmentation that combines them all - as needed. This way, if we try to rename a repository - directory, the higher action can know which are all the - restricted actions that should be performed in order - to make the full path syncronization. - - - - For example, if the directory we are renaming is a master - path, it is required to syncronize the related output and - localization auxiliar paths. On the other hand, if the - directory we are renaming through full path syncronization is - an auxiliar path, it is required to determine first what is - the related master path and later, perform the syncronization - from master path to auxiliar paths as if the path provided - would be the master path not the auxiliar path. - - - diff --git a/Documentation/Tcar-ug/Repository/Convenctions/worklines.docbook b/Documentation/Tcar-ug/Repository/Convenctions/worklines.docbook deleted file mode 100644 index 7daef4e..0000000 --- a/Documentation/Tcar-ug/Repository/Convenctions/worklines.docbook +++ /dev/null @@ -1,183 +0,0 @@ - - - Repository Work Lines - - - The content production inside &TCAR; has been divided into - individual work lines that relate one another based on the - idea of doing one thing well. In this model, the content - produced individually by each work line is combined one - another later to achieve higher purposes (e.g., corporate - identity for &TCP;). The repository work lines, as conceived - here, provide a relaible environment for people to work - syncronized and descentralized. - - - - The action of combining work lines inside &TCAR; is known as - the corporate identity production cycle. The rest of this - section describes the work lines available in the repository - and how they fit inside the corporate identity production - cycle. - - - - - Visual Identity - - - The visual identity is the first component we work out in - order to produce a new corporate identity. Through this work - line, graphic designers create models and - motifs for all the visual manifestation &TCP; - is made of. Once design models and artistic motifs are set in - place, graphic designers use the render - functionality described in to combine both design models and artistic motifs into - final images. - - - - The main purposes of this work line is define all the visual - manifestations the &TCP; is made of and provide design models - and artistic motifs for them in order to render the set of - images required to transmit the visual style that identifies - &TCP; as unique organization. To know more about &TCPCVI;, - read . - - - - The visual identity work line takes palce in the trunk/Identity directory. - - - - - - - - Localization - - - The content localization is the second component that must be - worked out in the corporate identity production cycle. - Through this work line translators localize source files - (e.g., SVG, DocBook, Shell scripts) which are later use to - produce localized images, localized documentation and - localized automation scripts. To localize source files, - translators use - the locale functionality described in - which takes care of - retriving translatable strings from source files and provide a - consistent localization interface based on GNU - gettext multi-lingual message - production tool set and xml2po command. - - - - The main purpose of this work line is extend the visual - identity (produced in English language) to as many native - languages as possible in order for people which doesn't - understand English languague to feel more confortable with - &TCP; and its messages. To know more about the specific - localization process read . - - - - The localization work line takes palce in the trunk/Locales directory. - - - - - - - Documentation - - - The documentation work line is the third component that must - be worked out in the corporate identity production cycle. - Through this work line documentors settle down the conceptual - and practical used to edificate &TCAR;. To write - documentation, documentors use the help - functionality described in which provides a consistent interface for building - documentation through different documentation backends (e.g., - Texinfo, DocBook, LaTeX, etc.). - - - - The main purpose of this work line is describe the standard - procedures &TCAR; realies on, as well as conceive a place to - help you understand what &TCAR; is and what can you do with - it. - - - - The documentation work line takes palce in the trunk/Manuals directory. - - - - - - Packaging - - - The packaging work line is the fourth component that must be - worked out in the corporate identity production cycle. Through - this work line packager gather final images, final - translations and final documentation related to art works and - put all together inside RPM packages. For this purpose, - packagers use the pack describe in - which provides a - consistent interface for building packages inside the - repository. - - - - The main purpose of this work line is pack all the information - &TCP; requires to rebrand &TCD; according Red Hat - redistribution guidelines. - - - - The packaging work line takes palce in the trunk/Packages directory. - - - - - - - Automation - - - The automation work line is the fifth and last component that - must be worked out in the corporate identity production cycle. - This work line closes the production cycle and provides the - production standards graphic designers, documentors, - translators and packagers need to make their work consistent - and reusable. For this purpose, programmers develop the - centos-art.sh script described in . - - - - The main purpose of this work line is standardize the - interaction of work lines in a reliable way. - - - - The automation work line takes palce in the trunk/Scripts directory. - - - - - diff --git a/Documentation/Tcar-ug/Repository/History.docbook b/Documentation/Tcar-ug/Repository/History.docbook deleted file mode 100644 index 6f587c0..0000000 --- a/Documentation/Tcar-ug/Repository/History.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - Repository History - - - This chapter summarizes relevant changes committed to &TCAR; - along the years. - - - &repo-history-2008; - &repo-history-2009; - &repo-history-2010; - &repo-history-2011; - &repo-history-2012; - - diff --git a/Documentation/Tcar-ug/Repository/History/2008.docbook b/Documentation/Tcar-ug/Repository/History/2008.docbook deleted file mode 100644 index 42f6c6e..0000000 --- a/Documentation/Tcar-ug/Repository/History/2008.docbook +++ /dev/null @@ -1,67 +0,0 @@ - - - 2008's - - - &TCAR; started at The CentOS Developers - Mailing List around 2008, on a discussion about how to - automate slide images used by Anaconda (&TCD; installer). In - such discussion, Ralph - Angenendt rose up his hand to ask —Do you have - something to show?—. - - - - To answer the question, Alain Reguera - Delgado suggested a bash script which combined SVG and - SED files in order to produce PNG images in different - languages —in conjunction with the proposition of - creating a Subversion repository where translations and image - production could be distributed inside &TCC;—. - - - - Karanbir - Singh considered the idea intresting and provided the - infrastructure necessary to support the effort. This way, - &TCAS; and &TCAR; were officially created and made world wide - available. In this configuration, users were able to register - themselves and administrators were able to assign access - rights to registered users inside &TCAR;, both using a web - interface. - - - - Once &TCAR; was available, Alain Reguera Delgado uploaded the - bash script used to produce the Anaconda - slides;See Ralph Angenendt documented it very - well;See and people started to download working - copies of &TCAR; to produce slide images in their own - languages.See the following Google - search. - - - - From this time on &TCAR; has been evolving into an automated - production environment where &TCC; can conceive &TCP; - corporate visual identity. - - - - The exact changes commited to &TCAR; through history can be - found in the repository - logs so you can know the real history about it. For - those of you who just want to get a glance of changes - committed, see . - - - diff --git a/Documentation/Tcar-ug/Repository/History/2009.docbook b/Documentation/Tcar-ug/Repository/History/2009.docbook deleted file mode 100644 index 883943c..0000000 --- a/Documentation/Tcar-ug/Repository/History/2009.docbook +++ /dev/null @@ -1,55 +0,0 @@ - - - 2009's - - - Around 2009, the rendition script was at a very rustic state - where only slide images could be produced, so it was - redesigned to extend the image production to other areas, - different from slide images. In this configuration, one SVG - file was used as input to produce a translated instance of it - which, in turn, was used to produce one translated PNG image - as output. The SVG translated instance was created through SED - replacement commands. The translated PNG image was created - from the SVG translated instance using Inkscape command-line - interface. - - - - The repository directory structure was prepared to receive the - rendition script using design templates and translation files - in the same location. There was one directory structure for - each art work that needed to be produced. In this - configuration, if you would want to produce the same art work - with a different visual style or structure, it was needed to - create a new directory structure for it because both the image - structure and the image visual style were together in the - design template. - - - - The rendition script was moved to a common place and linked - from different directory structures. There was no need to have - the same code in different directory structures if it could be - in just one place and then be linked from different locations. - - - - Corporate identity concepts began to be considered. As - referece, it was used the book "Corporate Identity" by Wally - Olins (1989) and Wikipedia - related links. This way, the rendition script main's - goal becomes to: automate the production process of - a monolithic corporate visual identity structure, based on the - mission and the release schema of The CentOS - Project. - - - - The repository directory structures began to be documented by - mean of flat text files. Later, documentation in flat text - files was moved onto LaTeX format and this way &TCARUG; was - initiated. - - diff --git a/Documentation/Tcar-ug/Repository/History/2010.docbook b/Documentation/Tcar-ug/Repository/History/2010.docbook deleted file mode 100644 index eb859fc..0000000 --- a/Documentation/Tcar-ug/Repository/History/2010.docbook +++ /dev/null @@ -1,78 +0,0 @@ - - - 2010's - - - Around 2010, the rendition script changed its name from - render.sh to - centos-art.sh and became a collection of - functionalities where rendition was just one among others - (e.g., documentation and localization). - - - - The centos-art.sh was initially conceived - to automate frequent tasks inside the repository based in the - idea of Unix toolbox: to create small and specialized tools - that do one thing well. This way, functionalities inside - centos-art.sh began to be identified and - separated one another. For example, when images were rendered, - there was no need to load functionalities related to - documentation manual. This layout moved us onto common - functionalities and specific - functionalities inside - centos-art.sh script. Common - functionalities are loaded when - centos-art.sh script is initiated and are - available to specific functionalities. - - - - Suddenly, no need was found to keep all the links spreaded - around the repository in order to execute the - centos-art.sh script from different - locations. The centos-art command-line - interface was used instead. The centos-art - command-line interface is a symbolic link stored inside the - ~/bin directory - pointing to centos-art.sh script. As - default configuration, inside The CentOS Distribution, the - path to ~/bin is - included in the search path for commands (see - PATH environment variable). This way, using - the centos-art command-line interface, it - is possible to execute the centos-art.sh - script from virtually anywhere inside the workstation, just as - we frequently do with regular commands. - - - - Start using GNU getopt as default option parser inside the - centos-art.sh script. - - - - The repository directory structure was updated to improve the - implementation of corporate visual identity concepts. - Specially in the area related to themes. Having both structure - and style in the same file introduced content duplication when - producing art works. Because of this reason, they were - separated into two different directory structures: the design - models and the artistic motifs directory structures. From - this point on, the centos-art.sh was able - to produce themes as result of arbitrary combinations between - design models (structure) and artistic motifs (visual styles). - - - - In the documentation area, the documents in LaTeX format were - migrated to Texinfo format. In this configuration, each - directory structure in the repository has a documentation - entry associated in a Texinfo structure which can be read, - edited and administered (e.g., renamed, deleted and copied) - interactively through centos-art.sh script. - Additionally, the texi2html program was used to produced - customized XHTML output in conjunction with CSS from &TCW;. - - - diff --git a/Documentation/Tcar-ug/Repository/History/2011.docbook b/Documentation/Tcar-ug/Repository/History/2011.docbook deleted file mode 100644 index 3dfdb68..0000000 --- a/Documentation/Tcar-ug/Repository/History/2011.docbook +++ /dev/null @@ -1,51 +0,0 @@ - - - 2011's - - - Around 2011, the centos-art.sh script was - redesigned to start translating XML-based files (e.g., SVG and - Docbook files) through xml2po program and - shell scripts (e.g., Bash scripts) through GNU gettext tools. - This configuration provided a stronger localization interface - for graphic designers, translators and programmers. The SED - replacement files are no longer used to handle localization. - - - - The render, help and - locale functionalities consolidated - themselves as the most frequent tasks performed in &TCAR; - working copy. Additionally, the prepare - and tuneup functionalities were also - maintained as useful tasks. - - - - In the documentation area, it was introduced the - transformation of localized DocBook XML DTD instances through - the render and - locale functionalities. In this - configuration, you use locale - functionality to localize DocBook source files to your - prefered language and later, using the - render functionality, you can produce the - localized XTHML and PDF output as specified in a XSLT layer. - Unfortunly, the transformation DocBook XML -> FO -> PDF - (through PassiveTex) seems to be buggy inside CentOS 5.5, so - it was commented inside the centos-art.sh - script. Most documentation is now organized in DocBook format, - even Texinfo format remains as the only format with automated - production tasks. - - - - In the automation area, the centos-art.sh - script introduced the capability of reading configuration - files. The main goal here was moving some command-line options - from functionalities onto a more persistent medium. Most - configuration files were set to define the position of brands - inside images and documentation manual specific options. - - - diff --git a/Documentation/Tcar-ug/Repository/History/2012.docbook b/Documentation/Tcar-ug/Repository/History/2012.docbook deleted file mode 100644 index 420f41f..0000000 --- a/Documentation/Tcar-ug/Repository/History/2012.docbook +++ /dev/null @@ -1,255 +0,0 @@ - - - 2012's - - - &TCAR; development was eventually stopped at November 2011 - until July 2012 when we needed to make the - centos-art.sh script a bit more - customizable than it presently was. For example, it was - considered as a need that functionalities inside the - centos-art.sh script must be not just - conceived independent one another but reusable in different - contexts as well. - - - - - Make Localization Of <command>centos-art.sh</command> - Script Specific To Different Contexts - - - The procedure used to locale messages inside the - centos-art.sh script had to be re-designed - in order to accept such pluggable behavior into the script. We - couldn't publish unique centos-art.sh.po - and centos-art.sh.mo files because they - may contain different information in different contexts. For - example, if you are using the render and - help functionalities you only need - translation messages for them and not those from other - functionalities that may exist in the central repository but - you didn't download nor use into your working copy. - - - - One solution for this could be to have independent PO files - for each functionality of centos-art.sh - script which are combined to create the final PO and MO files - that gettext uses to retrive - translated strings when centos-art.sh - script is running. For this solution to be effective, you must - be selective about the functionalities and locales directories - you download into your working copy. For example, if you want - to use the render functionality and its locale messages only, - you must download the required directories and exclude others. - - - - - In case you don't want to be selective and download the whole - repository, the creation of the - centos-art.sh.po, - centos-art.sh.pot and - centos-art.sh.mo files will occur - automatically the first time you run the - prepare functionality (which require the - locale functionality to be available), or - later, by running the following command: - centos-art locale trunk/Scripts/Bash --update - - - - For more information about the prepare - and locale functionalities, see and respectively. - - - - - - As shown in , both - Commons and Locales - functionalities will always be required directories. The - Commons directory contains the common - functionalities and the Locales directory - contains the standard procedures you need to run in order to - build the final centos-art.sh.mo file - used by gettext to retrive - translation strings when the centos-art.sh - script is running. Remember that - centos-art.sh.pot, - centos-art.sh.po files aren't under - version control and they are built by combining each - funtionality message.po file into a PO and later a MO file. - - - - Directory structure of a rendering-only context - - Directory structure of a rendering-only context - - - -/home/centos/Projects/artwork/trunk/ -|-- Locales/ -| `-- Scripts/ -| `-- Bash/ -| `-- es_ES/ -| |-- Functions/ -| | |-- Commons/ -| | | |-- messages.po -| | | `-- messages.pot -| | |-- Locales/ -| | | |-- messages.po -| | | `-- messages.pot -| | `-- Render/ -| | |-- messages.po -| | `-- messages.pot -| |-- LC_MESSAGES/ -| | `-- centos-art.sh.mo -| |-- centos-art.sh.po -| `-- centos-art.sh.pot -`-- Scripts/ - `-- Bash/ - |-- Functions/ - | |-- Commons/ - | |-- Locales/ - | `-- Render/ - `-- centos-art.sh - - - - - - - - A practical example of using the solution described above may - be found when you are working on the corporate identity of - &TCP; and then need to start a new corporate identity project - for another organization. You want to keep the directory - structure of &TCAR; and its automation tool, the - centos-art.sh script. Your new project - requires you to introduce new functionalities to - centos-art.sh which don't fit the needs of - &TCP; (e.g., you want to introduce a - report functionality to mesure how much - connect time do you consume through your PPP internface.) or - you just want to keep the directory structure of your new - project as simple as possible. - - - - To go through this it is possible to mix specific parts of - different central repositories into one single working copy. - This is the working copy you'll use to manage your new - project. In , we - see how the Render, - Locales and Commons directories which come - from the &TCAR; has been integrated into the working copy of - your new project. - - - - Mixing automation functionalities. - - Mixing automation functionalities. - - - -/home/al/Projects/Myapp/trunk/ -|-- Locales/ -| `-- Scripts/ -| `-- Bash/ -| `-- es_ES/ -| |-- Functions/ -| | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/ -| | | |-- messages.po -| | | `-- messages.pot -| | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/ -| | | |-- messages.po -| | | `-- messages.pot -| | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ -| | | |-- messages.po -| | | `-- messages.pot -| | `-- Report/ -| | |-- messages.po -| | `-- messages.pot -| |-- LC_MESSAGES/ -| | `-- myapp.sh.mo -| |-- myapp.sh.po -| `-- myapp.sh.pot -`-- Scripts/ - `-- Bash/ - |-- Functions/ - | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/ - | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/ - | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ - | `-- Report/ - `-- myapp.sh - - - - - - - - At this point, your working copy contains files from two - different central repositories. One repository provides the - files of your new organization project and the other one - provides the files related to the render - functionality from &TCAR;. In this environment, all updates - commited to the Render, - Locales and Commons directories at &TCAR; - will be available to you too, the next time you update your - working copy. Likewise, if you change something in any of - these directories and commit your changes, your changes will - be available to poeple working in &TCAR; the next time they - update their working copies. - - - - Understanding the need of mixing different central - repositories into a single working copy is an important step - for reusing the functionalities that come with centos-art.sh - script, but it is not enough if you want to customize the - information produced by it. By default, the centos-art.sh - script uses information related to &TCP;. You probably need to - change this if you are producing images to a different - organization than &TCP;. For example, some of the information - you might need to change would be the copyright holder, - brands, domain names, mailing lists, and so forth. To change - this information you need to duplicate the file - centos-art.sh and rename it to something - else. Later, you need to edit the renamed version and change - variables inside according your needs. In , we used the name - myapp.sh instead of - centos-art.sh so the information we set - inside it could reflect the specific needs that motivated the - creation of a new project without affecting those from &TCP;. - - - - Most of the information you need to change in your duplicated - version of centos-art.sh file is - controlled by a set of read-only variables. You modify these - variables here and they will be available all along the script - execution time. For example, you can change the value of - CLI_WRKCOPY variable inside your duplicated - version of centos-art.sh to change the - absolute path you use to store your working copy. - - - - - Update DocBook Documentation Structure And Processing - - ... - - - - diff --git a/Documentation/Tcar-ug/Repository/Workstation.docbook b/Documentation/Tcar-ug/Repository/Workstation.docbook deleted file mode 100644 index cf55d5e..0000000 --- a/Documentation/Tcar-ug/Repository/Workstation.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Preparing Your Workstation - - &repo-ws-intro; - &repo-ws-install; - &repo-ws-config; - - diff --git a/Documentation/Tcar-ug/Repository/Workstation/config.docbook b/Documentation/Tcar-ug/Repository/Workstation/config.docbook deleted file mode 100644 index 35b055a..0000000 --- a/Documentation/Tcar-ug/Repository/Workstation/config.docbook +++ /dev/null @@ -1,349 +0,0 @@ - - - Configuring Your Workstation - - - 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. - - - - Define Your Workplace - - 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. - - - - Different absolute paths - - 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.) - - - - - - One unique absolute path - - 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. - - - - - Different absolute paths through dynamic expansion - - 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). - - - - - Different absolute paths, dynamic expansion, symbolic - links, relative links, and environment variables - - - With this solution it is possible to store working copies of - &TCAR; on different locations inside the same workstation - without lose relation between files. Here we use the - TCAR_WORKDIR environment variable to set the location of the - working copy inside the workstation. Later the centos-art.sh - scripts uses this value as reference to determine where the - working copy is. This value is also the one used for dynamic - expansion inside design models and other similar files. In the - case of web projects where different components are required - to produce the final content, we create symbolic links between - them and use relative paths so it is possible to reuse them - and retain the relation between them in different contexts. - - - - For example, lets consider the organization of XHTML manuals - rendered from DocBook source files. When you render a DocBook - manual inside &TCAR; it creates XHTML files. This XHTML files - use images and common style sheets for better presentation. - Both of these images and styles components live outside the - XHTML structure so, in order to make them available - relatively to the XHTML structure, we created symbolic links - from the XHTML structure to the outside location where they - are in. The creation of symbolic links takes place - automatically when each DockBook manual is rendered through - centos-art.sh, which uses the value of - TCAR_WORKDIR environment variable as reference to determine - the absolute path of the working copy. - - - - Bacause absolute paths are no longer stored inside permanent - files and centos-art.sh script uses the - TCAR_WORKDIR environment variable to determine where the - working copy is stored in the workstation, it should be safe - to download working copies of &TCAR; anywhere in the - workstation. One just have to be sure that the value of - TCAR_WORKDIR environment variable does match the location of - the working copy you are using. - - - - - - - - Download Your Working Copy - - - In order to use &TCAR; you need to download a working copy - from the central repository into your workstation. To - download such working copy use the following command: - - - svn co https://projects.centos.org/svn/artwork ~/ - - - This command will create your working copy inside your home - directory, specifically in a directory named artwork. Inside this directory - you will find all the files you need to work with inside - &TCAR;. If you want to have your working copy in a location - different to that one shown above, see . - - - - 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 to render them in order to produce - the final files (e.g., images and documentation) used to - implement &TCPCVI;. - - - - - - Configure Administrative Tasks - - - 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 through 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 (e.g., - installing themes locally from the working copy for testing - purposes.). - - - - 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 your username - allowing software commands. This configuration is illustrated - in . - - - - The <filename>/etc/sudoers</filename> configuration file - - /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. -al ALL=(ALL) SOFTWARE - - - - - - - - - - Run Preparation Tool - - Once you've both downloaded a working copy from &TCAR; - and configured the sudo's configuration - file successfully, run the prepare - functionality of centos-art.sh script to - complete the configuration process using the following - command: - - - ~/artwork/trunk/Scripts/Bash/centos-art.sh prepare - - - To know more about the prepare - functionality of centos-art.sh script, see - . - - - - - Changing Your Working Copy Default Path - - By default your working copy should be store in your home - directory, specifically in the location ~/artwork. This location may not - be the final location where you want to have your working copy - in situations where you are working on several projects at the - same time or you already have a define location to organize - your projects inside your home directory. Thus, you may need - to change the default location of your working copy to a more - appropriate location. - - - - The default path to your working copy is controlled by the - TCAR_WORKDIR environment variable. This - variable is firstly defined in your personal profile after - running the prepare functionality of - centos-art.sh script. So, to change the - path of your working copy correctly, do the following: - - - - - - Create the parent directory you will use to store your working - copy. For example: - mkdir -p ~/Projects/CentOS - - - - - Move the currently downloaded working copy from ~/artwork to - your new location. For example: - mv ~/artwork ~/Projects/CentOS/ - - - - - Edit ~/.bash_profile file to set the new - location (without trailing slash) of your working copy as value - of TCAR_WORKDIR environment variable. For example: - TCAR_WORKDIR=${HOME}/Projects/CentOS/artwork - - - - - Do log out from your active user's seesion and do log in again - so the environment changes take effect. Or just update the - current environment information by running the following - command: - . ~/.bash_profile - - - - - Update internal links by running the following command: - ${TCAR_WORKDIR}/trunk/Scripts/Bash/centos-art.sh prepare --links - - - - - - - diff --git a/Documentation/Tcar-ug/Repository/Workstation/install.docbook b/Documentation/Tcar-ug/Repository/Workstation/install.docbook deleted file mode 100644 index 8c0f46b..0000000 --- a/Documentation/Tcar-ug/Repository/Workstation/install.docbook +++ /dev/null @@ -1,41 +0,0 @@ - - - Installing Your Workstation - - - To install your workstation use &TCD; default configuration as - proposed by &TCD; installer. This includes default - partitioning and packages. &TCAR; is been completly develop - upon &TCD; and realies on such environment to achieve most - automation tasks. In order to get a reproducable environment, - it is convenient that you, too, use the same operating system - that we do. - - - - Supported Platforms - - - &TCAR; has been tested in the following platforms: - - - - - - The CentOS Distribution major release 5 update 5, for i386 and - i686 architectures. - - - - - - In case you be using a working copy of &TCAR; in a different - platform from those listed here, please send a mail to centos-devel@centos.org - notifying it. It is our intention to make &TCAR; as portable - as possible through different major releases of &TCD;. - - - - - diff --git a/Documentation/Tcar-ug/Repository/Workstation/intro.docbook b/Documentation/Tcar-ug/Repository/Workstation/intro.docbook deleted file mode 100644 index ec285ad..0000000 --- a/Documentation/Tcar-ug/Repository/Workstation/intro.docbook +++ /dev/null @@ -1,27 +0,0 @@ - - - Introduction - - - The workstation is the machine you use to store your working - copy of &TCAR;. The working copy is an ordinary directory - tree on your workstation, containing a collection of files - that you can edit however you wish. The working copy is your - own private work area related to &TCAR; where you perform - changes and receive changes from others. - - - - In order to make your workstation completely functional, it is - necessary that you install it and configure it to satisfy the - needs demanded by the working copy of &TCAR; you later - download in it. - - - - This chapter describes the steps you need to follow in order - to install and configure a workstation for using a working - copy of &TCAR; in all its extention. - - - diff --git a/Documentation/Tcar-ug/Repository/introduction.docbook b/Documentation/Tcar-ug/Repository/introduction.docbook deleted file mode 100644 index a059dc5..0000000 --- a/Documentation/Tcar-ug/Repository/introduction.docbook +++ /dev/null @@ -1,120 +0,0 @@ -
- - Overview - - - The corporations always have a corporate identity, even when - they don't take an intentional control over it. It is a choise - from the corporation to define how much control to take over - its identity. This kind of control is expensive and not all - corporations are able to maintain it. However, it is - necessary that, based on pragmatic facts, the corporation - assume an acceptable degree of compromise with its identity in - order to create a consistent idea of itself in a way that can - be progresively improved through time. - - - - During the years (2003-2009), we've seen a growing interest - inside &TCC; for helping on &TCP; development. Some people - seem to be very clear about what the project needs are and how - to maintain it being a very stable project, but others however - don't to get what &TCP; is (even it is explained time after - time) and sometimes decide to put their efforts in the wrong - direction making everything to be a waste of time and source - of distraction from what is really needed. - - - - &TCAR; phases the question What can I do for - &TCP;? by identifying different work lines you can - join in and providing automated production mechanisms that - complement one another according to each work line needs so - consistent results can be achieved inside a distributed - environment under version control. For example, consider an - environment where there are graphic designers to produce - images, documentors to produce documentation manuals (whose - can use images produced by graphic designers), programmers to - produce automation scripts (needed to standardize production - tasks) and translators to localize source files created by - graphic designers, documetors and programmers. Once such - environment has been implemented, it would be possible for - packagers to take localized images and localized documentation - from &TCAR; (through an automation script probably) to - rebrand/update the content of those packages inside &TCD; that - must include information specific to &TCP; itself (e.g., boot - loader, distribution installer, release notes, display - managers, release notes, web browsers default page, etc.). - - - - Most production tasks inside &TCAR; are focused on the files - needed to implement &TCP; corporate visual identity. - - Notice that, here, visual identity means everything - perceived through the human's visual sences (i.e., the - human eyes), but the corporate identity is a wider concept - that extends to all human senses (i.e., visibilty (eyes), - audition (ears), scent (nose), touch (fingers), and savour - (tongue)), not just that one related to visual aspects. - Nevertheless, we need to be consequent with the media - where &TCP; manifests its existence on, as described in - . - This includes everything from file edition - (e.g., text width, text indentation, line numbering, text - tabulation, etc.) up to how the web sites, distribution, and - industrial stuff (e.g., pullovers, caps, installation media, - etc.) look and feel. Notice that, more specific details like - typography, window design, icons, menu items, etc., inside - &TCD; are already covered by &TCP; upstream provider. In our - effort to be 100% binary compatible with the upstream provider - and also keeping maintainance low, we stand over those - specific details as much as possible assuming them as default. - However, if you feel brave enough (and prove your ability to - keep yourself being that way) it would be possible to open a - work line for you to maintain variants of such very specific - details inside &TCAR;. - - - - In addition to visual manifestations, there are also emotional - feelings and ethical behaviours that must be considered as - part of &TCP; corporate identity. A pleasant experience in - this area includes &TCWIKI;, specifically the way it was - conceived and administered. When the &TCWIKI; was published, - &TCP; published a list of needs with it so anyone could - contribute based on them. Not much time after that, the list - of tasks triggered some souls' motivations ruled by the good - will of initiating the translation of that content published - inside the wiki, redesigning its visual style, proposing the - TreeFlower theme for &TCD;, and reducing to zero the - contraditions of precoceived minds with respect, reason and - passion. As result of this experience, we found that &TCC; - posseses an incredible strong creative force, however, a long - path must be traveled before it can be focalized into the - right direction because: it isn't enough just telling what the - right direction is, it is also necessary to provide the - vehicles for &TCC; be able of moving through it. - - - - &TCAR; extends the feelings and ethicals behaviours from - &TCWIKI; to itself by identifying the visual manifestations - &TCP; is made of (i.e., tracing a direction) and allowing - people to develop them through standardized procedures inside - a colaborative environment (i.e., providing the vehicles). - - - - Finally, if you find yourself needing to do something for - &TCP; and &TCAR; isn't the place for it, be sure to define - what that something exactly is and also make it a community - effort so it can be validated as something useful to the - community itself. Otherwise, the effort would loose its - initial sense soon enough so as to be considered seriously. - Notice that the way these needs are described may take - different forms: they can be written and organized inside a - book, an article, or even a well documented program ;-). - - -
diff --git a/Documentation/Tcar-ug/Scripts.docbook b/Documentation/Tcar-ug/Scripts.docbook deleted file mode 100644 index 3645deb..0000000 --- a/Documentation/Tcar-ug/Scripts.docbook +++ /dev/null @@ -1,12 +0,0 @@ - - - Automation - - - ... - - - &scripts-bash; - - - diff --git a/Documentation/Tcar-ug/Scripts.ent b/Documentation/Tcar-ug/Scripts.ent deleted file mode 100644 index 584d443..0000000 --- a/Documentation/Tcar-ug/Scripts.ent +++ /dev/null @@ -1,10 +0,0 @@ - - - - - - - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash.docbook b/Documentation/Tcar-ug/Scripts/Bash.docbook deleted file mode 100644 index c3f53c3..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash.docbook +++ /dev/null @@ -1,14 +0,0 @@ - - - The Bash Script (<command>centos-art.sh</command>) - - &scripts-bash-intro; - &scripts-bash-environment; - &scripts-bash-prepare; - &scripts-bash-render; - &scripts-bash-locale; - &scripts-bash-help; - &scripts-bash-pack; - &scripts-bash-tuneup; - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/environment.docbook b/Documentation/Tcar-ug/Scripts/Bash/environment.docbook deleted file mode 100644 index 45d81db..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/environment.docbook +++ /dev/null @@ -1,234 +0,0 @@ - - - Execution Environment - - - When you login in your computer you enter into a unique user - environment which you can customize by setting environment - variables in the ~/.bash_profile - file.To know more about environment variables, - see the bash(1) man page. This way different - users can benefit from their own environment variables to - customize the execution of centos-art.sh - script in a safe way. For example, users can use the - variables of their environments to set different locations for - their working copies of &TCAR;.See - - - - When you execute the centos-art.sh script, - you create a new environment inside the user environment which - we call the script environment. This environment inherits all - variables from the user environment and contains the variables - and functionalities defined by the script itself. If your only - interest is using the centos-art.sh script - to accomplish tasks inside the working copy, you don't need to - know the whole environment it uses, but the user environment - only. However, if your interest is improving it somehow, to - know the environment where it is run is a fundamental - knowledge you need to be armed with in order to understand - where to put the code you want to contribute inside the - script. - - - - The script environment - - The script environment - - - -------------------------------------------------------- -User environment -----|-------------------|------------------------------ -. |-- TCAR_WORKDIR |-- EDITOR . -. |-- LANG |-- HOME . -. `-- centos-art.sh `-- ... . -. ----|---------------------------------------- . -. centos-art.sh script environment . -. ----|-----------------|---------------------- . -. . |-- CLI_NAME `-- init() . . -. . |-- CLI_VERSION |-- render() . . -. . |-- CLI_BASEDIR | |-- svg() . . -. . |-- CLI_FUNCDIR | `-- docbook() . . -. . |-- CLI_TEMPDIR |-- help() . . -. . `-- ... | |-- docbook() . . -. . | `-- texinfo() . . -. . |-- locale() . . -. . `-- ... . . -. ............................................. . -....................................................... - - - - - - - - To study the environment of centos-art.sh - script, you need to consider the directory structure under - trunk/Scripts/Bash/. In - this structure each directory under Functions/ creates a new function - environment inside the script environment. You can only - execute one function environment at a time for each script - environment. In some cases, it is possible to find a - sub-function environment which takes place inside the function - environment. Such is the case of the - render functionality which produces both - images and DocBook manuals. - - - - - If you need more environment levels from sub-function - environment on, then it is a good time for you to consider the - creation of a new function environment at all. - - - - - User's Profile (<filename>~/.bash_profile</filename>) - - - Default working copy - TCAR_WORKDIR=${HOME}/artwork - - The TCAR_WORKDIR environment variable is - specific to centos-art.sh script and - controls the working copy default location in the workstation. - This variable doesn't exist just after installing your - workstation. This variable appears inside the - ~/.bash_profile file (and so in the user - environment of yours) after configuring your workstation, as - described in . - - - - - - Default execution path - PATH=$PATH:$HOME/bin - - This is the location where we store links to executable files - inside the working copy. - - - - - Default text editor - EDITOR=/usr/bin/vim - - 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 none 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 use 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 zone information is a - straight-forward task and configuration tools provided by - &TCD; do cover time correction for most of the countries - around the world, thus we don't include it to your personal - profile. - - - - In case 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. - - - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/help.docbook b/Documentation/Tcar-ug/Scripts/Bash/help.docbook deleted file mode 100644 index 12c43c3..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/help.docbook +++ /dev/null @@ -1,247 +0,0 @@ - - - Standardizing Documentation Tasks - - - The help functionality is the interface - the centos-art.sh script provides to - standardize frequent documentation tasks, based on specific - documentation formats, as described in . - - - - Syntax - - centos-art help [OPTIONS] [DOCENTRY] - - - The DOCENTRY parameter specifies the - documentation entry you want to process. It can be provided - one or more times in the form - MANUAL:PART:CHAPTER:SECTION or - MANUAL::CHAPTER:SECTION based on whether the - manual documentation backend you are using supports - structuring through parts or not. When - DOCENTRY parameter is not provided, - &TCAR; Repository File System documentation - manual is used as default value. - - - - To determine the documentation format to use, when new - documentation manuals are created and no configuration file is - available, the help functionality request - you to enter one of the supported documentation formats and - then, uses it to create the documentation manual. Once the - documentation manual is created, the document configuration - file is available inside the manual directory structure and - used to retrive the document format information, instead. - - - - - Options - - The help functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - Supress all commit and update actions realized over files, - before and after the action itself had took place over files - in the working copy. - - - - - - - - - This option looks for KEYWORD inside the - manual specified in the documentation entry and display - related information you to read. - - - - - - - - - Edit documentation entry related to path specified by - DOCENTRY parameter. - - - The DOCENTRY parameter must point to any - directory inside the working copy. When more than one - DOCENTRY are passed as non-option - arguments to the centos-art.sh script - command-line, they are queued for further edition. The - edition itself takes place through your default text editor - (e.g., the one you specified in the EDITOR - environment variable) and the text editor opens one file at - time (i.e., the queue of files to edit is not loaded in the - text editor.). - - - - - - - - - Read documentation entry specified by - DOCENTRY path. This option is used - internally by centos-art.sh script to refer - documentation based on errors, so you can know more about them - and the causes that could have provoked them. - - - - - - - - - Update output files rexporting them from the specified backend - source files. - - - - - - - - - Duplicate documentation entries inside the working copy. - - - When documentation entries are copied, it is required to pass - two non-option parameters in the command-line. The first - non-option parameter is considered the source location and the - second one the target location. Both source location and - target location must point to a directory under the working - copy. - - - - - - - - - Delete documentation entries specified by - DOCENTRY inside the working copy. It is - possible to delete more than one documentation entry by - specifying more DOCENTRY parameters in the - command-line. - - - - - - - - - Rename documentation entries inside the working copy. - - - When documentation entries are renamed, it is required to pass - only two non-option parameters to the command-line. The first - non-option parameter is considered the source location and the - second one the target location. Both source location and - target location must point to a directory under the working - copy. - - - - - - - When documentation entries are removed (e.g., through - or - options), the help functionality takes - care of updating nodes, menus and cross references related to - documentation entries in order to keep the manual structure in - a consistent state. - - - - - Description - - ... - - - - - Environment - - ... - - - - - Authors - - The following people have worked in the - help functionality: - - - - - Alain Reguera Delgado <alain.reguera@gmail.com> - - - - - - - License - -Copyright (C) 2009-2012 The CentOS Project - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/intro.docbook b/Documentation/Tcar-ug/Scripts/Bash/intro.docbook deleted file mode 100644 index 00ee91e..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/intro.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - Introduction - ... - diff --git a/Documentation/Tcar-ug/Scripts/Bash/locale.docbook b/Documentation/Tcar-ug/Scripts/Bash/locale.docbook deleted file mode 100644 index 2596369..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/locale.docbook +++ /dev/null @@ -1,285 +0,0 @@ - - - Standardizing Content Localization - - - The locale functionality is the - interface the centos-art.sh script provides - to standardize localization tasks inside the working copy. - - - - Syntax - - centos-art locale [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process are stored in. This paramter can be - provided more than once in order to process more than one - directory path in a single command execution. When this - parameter is not provided, the current directory path where - the command was called from is used instead. - - - - - Options - - The locale functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - Reduce the list of files to process inside - DIRECTORY using REGEX as - pattern. You can use this option to control the amount of - files you want to locale. The deeper you go into the - directory structure the more specific you'll be about the - files you want to locale. When you cannot go deeper into the - directory structure through DIRECTORY - specification, use this option to reduce the list of files - therein. - - - - - - - - - Supress all commit and update actions realized over files, - before and after the actions themselves had took place over - files in the working copy. - - - - - - - - - This option updates both POT and PO files related to source - files. Use this option everytime you change translatable - strings inside the source files. - - - - - - - - - This option edits the portable object related to source files. - When you provide this option, your default text editor is used - to open the portable object you, as translator, need to change - in order to keep source file messages consistent with their - localized versions. In the very specific case of shell - scripts localization, this option takes care of updating the - machine object (MO) file the shell script requires to - displayed translation messages correctly when it is executed. - - - - - - - - - This option unlocalizes source files. When you provide this - option, the localization directory related to source files is - removed from the working copy in conjunction with all portable - objects and machine objects inside it. - - - - - - - - - This option suppresses machine objects creation when shell - scripts are localized. - - - - - - - - - Description - - - The localization process is very tied to the source files we - want to provide localized messages for. Inside the working - copy of &TCAR; it is possible to localize XML-based files - (e.g., SVG and Docbook) and programs written in most popular - programming languages (e.g., C, C++, C#, Shell Scripts, - Python, Java, GNU awk, PHP, etc.). - - - - The localization process initiates by retriving translatable - strings from source files. When source files are XML-based - files, the only requisite to retrive translatable strings - correctly is that they be well-formed. Beyond that, the - xml2po command takes care of everything - else. When source files are Shell script files, it is - necessary that you previously define what strings inside the - script are considered as translatable strings in order for - xgettext command to retrive them correctly. - To define translatable strings inside shell scripts, you need - to use either gettext, - ngettext, eval_gettext - or eval_ngettext command as it is following - described: - - - - - - Use the gettext command to display the - native language translation of a textual message. - - MESSAGE="`gettext "There is no entry to create."`" - - - - - Use the ngettext command to display the - native language translation of a textual message whose - grammatical form depends on a number. - - MESSAGE="`ngettext "The following entry will be created" \ - "The following entries will be created" \ - $COUNT`:" - - - - - Use the eval_gettext command to display the - native language translation of a textual message, performing - dollar-substitution on the result. Note that only shell - variables mentioned in the message will be dollar-substituted - in the result. - - MESSAGE="`eval_gettext "The location \\\"\\\$LOCATION\\\" is not valid."`" - - - - - Use the eval_ngettext command to display - the native language translation of a textual message whose - grammatical form depends on a number, performing - dollar-substitution on the result. Note that only shell - variables mentioned in messages will be dollar-substituted in - the result. - - MESSAGE="`eval_ngettext "The following entry will be created in \\\$LOCATION" \ - "The following entries will be created in \\\$LOCATION" \ - $COUNT`:" - - - - - Once translatable strings are retrived, a portable object - template (POT) file is created for storing them. Later, the - POT file is used to create a portable object (PO). The - portable object is the place where localization itself takes - place, it is the file translators edit to localize messages. - When translatable strings change inside source files, it is - necessary that you update these POT and PO files in order to - keep consistency between source file messages and their - localized versions. - - - - Inside source files, translatable strings are always written - in English language. In order to localize translatable strings - from English language to another language, you need to be sure - the LANG environment variable has been already - set to the locale code you want to localize message for or see - them printed out before running the - locale functionality of - centos-art.sh script. Localizing English - language to itself is not supported. - - - - To have a list of all locale codes you can have localized - messages for, run the following command: locale -a | - less. - - - - - Environment - - ... - - - - - Authors - - The following people have worked in the - locale functionality: - - - - - Alain Reguera Delgado <alain.reguera@gmail.com> - - - - - - - License - -Copyright (C) 2009-2012 The CentOS Project - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/pack.docbook b/Documentation/Tcar-ug/Scripts/Bash/pack.docbook deleted file mode 100755 index f52e18a..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/pack.docbook +++ /dev/null @@ -1,65 +0,0 @@ - - - Standardizing Packaging Tasks - - - ... - - - - Syntax - - ... - - - - - Options - - ... - - - - - Description - - ... - - - - - Environment - - ... - - - - - Authors - - ... - - - - - License - -Copyright (C) 2009-2012 The CentOS Project - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/prepare.docbook b/Documentation/Tcar-ug/Scripts/Bash/prepare.docbook deleted file mode 100644 index fdc9d5e..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/prepare.docbook +++ /dev/null @@ -1,259 +0,0 @@ - - - Standardizing Configuration Tasks - - - The prepare functionality is the - interface the centos-art.sh script provides - to standardize the content production tasks inside the working - copy. - - - - Syntax - - - Assuming this is the very first time you run the - centos-art command, you'll find that there - isn't such a command in your workstation. This is correct - because you haven't created the symbolic link that makes it - available in your execution path, yet. In order to make the - centos-art command available in the - execution path of your workstation, you need to run the - centos-art.sh script using its absolute - path first: - - - ~/artwork/trunk/Scripts/Bash/centos-art.sh prepare [OPTIONS] - - - Later, once the centos-art command is - available in your execution path, there is no need for you to - use any absolute path again. From this time on, you can use - the centos-art command-line interface - directly, as the following example describes: - - - centos-env prepare [OPTIONS] - - - - - Options - - - When the centos-art command is executed - with the prepare functionality, it - accepts the following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option whould have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - This option verifies packeges required by automation scripts - and installs or updates them as required. When required - packages aren't installed or need to be updated, the - centos-art uses the sudo - and yum to perform either installations or - actualizations tasks. In both cases, it is required that you - configure the /etc/sudoers configuration - file first, as discribed in . - - - - - - - - - - This option creates or updates the portable objects (PO) and - machine object (MO) used by gettext - to retrive translated strings related to - centos-art.sh script. This option calls - the locale functionality of centos-art.sh - with the option, as described in - . - - - - - - - - - This option maintains the file relation between your working - copy and configuration files inside your workstation through - symbolic links. When you provide this option, the - centos-art.sh script puts itself into your - system's execution path through its command line interface - centos-art and makes common brushes, - patterns, palettes and fonts inside the working copy, - available to applications like GIMP in order for you to make - use of them without loosing version control over them. - - - - This option removes all common fonts, brushes, patterns, and - palettes currently installed in your home directory, in order - to create a fresh installation of them all again, using the - working copy as reference. - - - - - - - - - - This option initializes image files inside the working copy. - When you provide this option, the - centos-art.sh calls the - render functionality to create images - related to each design model available in your working copy, - as described in . - - - - - - - - - This option initializes documentation files inside the working - copy. When you provide this option, the - centos-art.sh script calls both the - render and help - functionality to produce DocBook and Texinfo manuals, - respectively. - - - - - - - - - Print the name and value of some of the environment variables - used by centos-art.sh script as described - in . - - - - - - - - - Set default environment values to your personal profile - (~/.bash_profile). - - - - - - - - - Description - - - When no option is provided to prepare - functionality, the centos-art.sh script - uses the , - , - , and - options, in that order, as default - behaviour. Otherwise, if you provide any option, the - centos-art.sh script avoids its default - behaviour and executes the prepare - functionality as specified by the options you provided. - - - - Notice that it is possible for you to execute the - prepare functionality as many times as - you need to. This is specially useful when you need to keep - syncronized the relation between content produced inside your - working copy and the applications you use outside it. For - example, considering you've added new brushes to or removed - old brushes from your working copy of &TCAR;, the link - information related to those files need to be updated in the - ~/.gimp-2.2/brushes - directory too, in a way the addition/deletion change that took - place in your working copy can be reflected there, as well. - The same is true for other similar components like fonts, - patterns and palettes. - - - - - - Environment - - ... - - - - - Authors - - The following people have worked in the - prepare functionality: - - - - - Alain Reguera Delgado <alain.reguera@gmail.com> - - - - - - - License - -Copyright (C) 2009-2012 The CentOS Project - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/render.docbook b/Documentation/Tcar-ug/Scripts/Bash/render.docbook deleted file mode 100644 index 59b1ddd..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/render.docbook +++ /dev/null @@ -1,288 +0,0 @@ - - - Standardizing Content Rendition - - - The render functionality is the interface - the centos-art.sh script provides to - standardize the content production tasks inside the working - copy. - - - - Syntax - centos-art render [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process are stored in. This paramter can be - provided more than once in order to process more than one - directory path in a single command execution. When this - parameter is not provided, the current directory path where - the command was called from is used instead. - - - - - Options - - - The render functionality accepts the - following options: - - - - - - - - This option supresses all output messages except error - messages. When this option is passed, all confirmation - requests are supressed and a possitive answer is assumed for - them, just as if the option - would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - This option reduces the list of files to process inside - DIRECTORY using REGEX as - pattern. You can use this option to control the amount of - files you want to render. The deeper you go into the - directory structure the more specific you'll be about the - files you want to render. When you cannot go deeper into the - directory structure through DIRECTORY - specification, use this option to reduce the list of files - therein. - - - - - - - - - This option supresses all commit and update actions realized - over files, before and after the action itself had took place - over files in the working copy. - - - - - - - - - This option expands the =\RELEASE=, - =\MAJOR_RELEASE=, and - =\MINOR_RELEASE= translation makers based on - NUMBER value. Notice that translation - markers here were escaped using a backslash (\) - in order to prevent their expansion. Use this option when you - need to produce release-specific contents, but no release - information can be retrived from the directory path you are - currently rendering. - - - - - - - - - This option expands the =\ARCHITECTURE=, - translation makers based on ARHC value. - Notice that translation markers here were escaped using a - backslash (\) in order to prevent their - expansion. Use this option when you need to produce - architecture-sepecific contents but no architecture - information can be retrived from the directory path you are - currently rendering. - - - - - - - - - This option specifies the name of theme model you want to use - when producing theme artistic motifs. By default, if this - option is not provided, the Default theme - model is used as reference to produce theme artistic motifs. - To know what values does the NAME variable - can have, run ls - ~/artwork/trunk/Identity/Models/Themes command. - - - - - - - - - This option lets you apply a command as post-rendition action. - In this case, the COMMAND represents the - command-line you want to execute in order to perform in-place - modifications to base-rendition output. - - - - - - - - - This option lets you apply a command as last-rendition action. - In this case, the COMMAND argument - represents the command string you want to execute in order to - perform in-place modifications to base-rendition, - post-rendition and directory-specific rendition outputs. - - - - - - - - Description - - - Inside the working copy of &TCAR;, rendition tasks take place - inside renderable directories. The rendition itself is - performed through a serie of rendition flows named - base-rendition, post-rendition, last-rendition and - directory-specific rendition. - - - - Renderable directories are convenctional locations inside the - working copy where you can find source files, output files and - auxiliar files. Source files are used to produce output files. - Auxiliar files are used to modify the way output files are - produced from source files (e.g., to produce localized - output). Auxiliar files are optionals. - - - Renderable directories are made of several directories but - only the output dirctory path is passed to - render functionality as - DIRECTORY parameter in the command-line. - The directories related to source and auxiliar files are - automatically constructed based on a directory organization - convenction. This way, the render - functionality collects all the information it needs to work - with. - - - Inside the working copy, renderable directories are divided in - two categories in a way differences between them can be - preserved. These categories are named direct - production and theme production. These - categories provide the file organization convenction the - render functionality needs, to produce - content based on rendition flows. - - - - Direct Production - - ... - - - - - Theme Production - - ... - - - - - Base Rendition Flow - - ... - - - - - Post Rendition Flow - - ... - - - - - Last Rendition Flow - - ... - - - - - Directory-Specific Rendition Flow - - ... - - - - - - - Environment - - ... - - - - - Authors - - The following people have worked in the - render functionality: - - - - - Alain Reguera Delgado <alain.reguera@gmail.com> - - - - - - - License - -Copyright (C) 2009-2012 The CentOS Project - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - - diff --git a/Documentation/Tcar-ug/Scripts/Bash/tuneup.docbook b/Documentation/Tcar-ug/Scripts/Bash/tuneup.docbook deleted file mode 100644 index bf37edc..0000000 --- a/Documentation/Tcar-ug/Scripts/Bash/tuneup.docbook +++ /dev/null @@ -1,295 +0,0 @@ - - - Standardizing File Maintainance - - - The tuneup functionality is the - interface the centos-art.sh script provides - to standardize the maintainance tasks related to individual - files inside the working copy. - - - - Syntax - - centos-art tuneup [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process are stored in. This paramter can be - provided more than once in order to process more than one - directory path in a single command execution. When this - parameter is not provided, the current directory path where - the command was called from is used instead. - - - - - Options - - The tuneup functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - Reduce the list of files to process inside - path/to/dir using - REGEX as pattern. You can use this - option to control the amount of files you want to tuneup. The - deeper you go into the directory structure the more specific - you'll be about the files you want to tuneup. When you cannot - go deeper into the directory structure through - path/to/dir specification, use this - option to reduce the list of files therein. - - - - - - - - - Supress all commit and update actions realized over files, - before and after the action itself had took place over files - in the working copy. - - - - - - - - Description - - - Tasks related to file maintainance are repetitive. You might - find yourself doing them time after time inside the working - copy of &TCAR;. Some of these maintainance tasks do update top - comments on shell scripts, create table of contents for web - pages, update metadata related to design models and remove - unused definitions from design models. - - - - When you execute the tuneup functionality of centos-art.sh - script, it looks for all files that match the supported - extensions (e.g., .sh, - .svg and .xhtml) in the directory - specified, builds a list with them and applies the - maintainance tasks using file extensions as reference. - - - - When shell scripts are found, the tuneup - functionality of centos-art.sh script reads a comment template - from - trunk/Scripts/Functions/Tuneup/Shell/Config/topcomment.sed - and applies it to all shell scripts found, one by one. As - result, all shell scripts will end up having the same - copyright and license information the comment template does. - - - In order for the shell script top comment template to be - applied correctly, the shell scripts you write must have the - structure described in . - - - - Shell script top-comment template. - - Shell script top-comment template. - - - - 1| #!/bin/bash - 2| # - 3| # doSomething.sh -- The function description goes here. - 4| # - 5| # Copyright - 6| # - 7| # ... - 8| # - 9| # ---------------------------------------------------------------------- -10| # $Id$ -11| # ---------------------------------------------------------------------- -12| -13| function doSomething { -14| -15| } - - - - - - - - The tuneup functionality of - centos-art.sh script replaces all lines - between the Copyright line (e.g., line 5) - and the first separator line (e.g., line 9), inclusively. - Everything else will remain immutable in the file. - - - - When scalable vector graphics are found, the tuneup - functionality reads a SVG metadata template from - trunk/Scripts/Functions/Tuneup/Svg/Config/metadata.sed - and applies it to all files found, one by one. Immediatly - after the metadata template has been applied and, before - passing to next file, all unused definition are removed from - the file, too. - - - The metadata applied by the SVG metadata template is created - dynamicaly combining the absolute path of the file being - currently modified, the workstation's date information, the - centos-art.sh script copyright holder - (e.g., =COPYRIGHT_HOLDER=) as reference and the Creative - Common Distribution-ShareAlike 3.0 License as default license - to release SVG files. - - - The elimination of unused definitions inside SVG files takes - place through Inkscape's - option, as described in its man page (e.g., man - inkscape). - - - - When HTML files are found, the tuneup - functionality of centos-art.sh script - transforms web page headings to make them accessible through a - table of contents. The table of contents is expanded in - place, wherever the <div - class="toc"></div> piece of code be in the - file. Once the table of contents has been expanded, there is - no need to put anything else in the page. You can run the - tuneup functionality everytime you update - the heading information so as to update the table of contents, - too. - - - In order for this functionality to build the table of contents - from headings, you need to put headings in just one line. The - headin level can vary from h1 to h6 - with attribute definitions accepted. Closing tag must be - present and also match the openning tag. Inside the heading - definition an anchor definition must be present with attribute - definitions accepted. The value of name - and href attributes from the anchor - element are set dynamically using the md5sum output of - combining the page location, the head- - string and the heading content itself. If any of the - components used to build the heading reference changes, you - need to run the the tuneup functionality of - centos-art.sh script in order for the - anchor elements to use the correct information. - - - For example, the headings shown in produces the table of - contents shown in . - - - - HTML heading definition. - - HTML heading definition. - - - -<h1 class="title"><a name="head-8a23b56a28dfa7277d176576f217054a">Forms</a></h1> -<h2 class="title"><a name="head-629f38bc607f2a270177106b450aeae3">Elements</a></h2> -<h2 class="title"><a name="head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a></h2> - - - - - - - - HTML table of contents definition. - - HTML table of contents definition. - - - -<div class="toc"> <p>Table of contents</p> <dl><dt><a href="#head-8a23b56a28dfa7277d176576f217054a">Forms</a> <dl><dt><a href="#head-629f38bc607f2a270177106b450aeae3">Elements</a> </dt><dt><a href="#head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a> </dt></dl> </dt></dl> </div> - - - - - - - - - Environment - - ... - - - - - Authors - - The following people have worked in the - tuneup functionality: - - - - - Alain Reguera Delgado <alain.reguera@gmail.com> - - - - - - - License - -Copyright (C) 2009-2012 The CentOS Project - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - - diff --git a/Documentation/Tcar-ug/tcar-ug.docbook b/Documentation/Tcar-ug/tcar-ug.docbook deleted file mode 100644 index 15d29c3..0000000 --- a/Documentation/Tcar-ug/tcar-ug.docbook +++ /dev/null @@ -1,92 +0,0 @@ - - - - - %Entities; - - - - - %Identity; - - %Locales; - - %Manuals; - - %Repository; - - %Scripts; - - ]> - - - - - - The CentOS Artwork Repository - User's Guide - - - - Alain - Reguera Delgado - - - - - 2009 - 2010 - 2011 - 2012 - &TCP;. All rights reserved. - - - - - Permission is granted to copy, distribute and/or modify - this document under the terms of the GNU Free - Documentation License, Version 1.2 or any later version - published by the Free Software Foundation; with no - Invariant Sections, no Front-Cover Texts, and no - Back-Cover Texts. A copy of the license is included in - . - - - - - - 1.0 - Today - - Alain - Reguera Delgado - - - - Under development. - - - - - - - - - &preface; - &repo; - &identity; - &locales; - &manuals; - &scripts; - - - &licenses; - - diff --git a/Documentation/Tcpi-ug/Commons.ent b/Documentation/Tcpi-ug/Commons.ent deleted file mode 100755 index f5bcdd1..0000000 --- a/Documentation/Tcpi-ug/Commons.ent +++ /dev/null @@ -1,23 +0,0 @@ - - - - - - -&TC; Project"> - - -&TC; Mirrors"> -&TC; Wiki"> - - - - -The CentOS Artwork Repository"> -&TCPI; User's Guide"> diff --git a/Documentation/Tcpi-ug/Connectivity.docbook b/Documentation/Tcpi-ug/Connectivity.docbook deleted file mode 100644 index fd0139b..0000000 --- a/Documentation/Tcpi-ug/Connectivity.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - Connectivity - - - - This part of the book describes how to connect your computer - to the telephone network and configure the programs required - to establish the connection through which you will transmit - data using computers. - - - - &connectivity-ppp; - - diff --git a/Documentation/Tcpi-ug/Connectivity.ent b/Documentation/Tcpi-ug/Connectivity.ent deleted file mode 100644 index c0cee7e..0000000 --- a/Documentation/Tcpi-ug/Connectivity.ent +++ /dev/null @@ -1,7 +0,0 @@ - - - - - - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp.docbook deleted file mode 100644 index 018d471..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - PPP - - &connectivity-ppp-overview; - &connectivity-ppp-modem; - &connectivity-ppp-server; - &connectivity-ppp-client; - &connectivity-ppp-network; - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp/client.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp/client.docbook deleted file mode 100644 index 06405e0..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp/client.docbook +++ /dev/null @@ -1,17 +0,0 @@ - - - The Client Computer - - - When you are configuring the client computer, you need to - install the wvdial, pppd - and system-config-network packages. From - these packages, to configure your Modem connection, you only - need to use the interface provided by the - system-config-network package. This - interface controls configuration files related to - pppd and - wvdial programs for you. - - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp/modem.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp/modem.docbook deleted file mode 100644 index 3a168ee..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp/modem.docbook +++ /dev/null @@ -1,194 +0,0 @@ - - - The Modem Device - - - In order to establish a PPP link between two computers using - the telephone line as medium for data transmission, you will - need to install and configure a modem device in each computer - you plan to connect. On the other hand, if you're planning to - use PPP to connect the same computer to different networks - simultaneously (e.g., to build a proxy between them), you will - need to install and configure one modem device for each - different network you plan to establish such simultaneous - connection in the same computer. - - - - Installing Modem Devices - - To install a modem device in the computer, you need to attach - the modem hardware to the computer and later the telephone - line to the modem hardware. To attach the modem hardware to - your computer, you need to connect the serial or USB cable - that comes from the modem hardware to the appropriate input on - your computer (whether serial or USB). To connect the modem - hardware to the telephone line, you need to unplug the cable - that connects your telephone device and plug it on the modem - device, specifically in the port reserved for data - transmission. Later, using a similar cable, you could connect - your telephone device to the modem's telephone port, so you - can realize telephone calls when no data transmition take - place through modem's data port. - - - - To be on the safe side, do everything related to hardware - installation with the computer turned off. Then, when - everthing has been put in place, turn the computer on. Once - the operating system is up and running, you can verify the - modem hardware using either the lsusb or - lspci commands, based on whether you - attached the modem device to an USB or serial port, - respectivly. These commands need to be run with - administrative privileges, thus, you probably need to do - sudo on them or login as root user in order to execute - them. For example, assuming you logged in as root user and you installed an - USB modem hardware as mentioned before, the output of - lsusb command would be similar to that - following: - - - -Bus 003 Device 001: ID 0000:0000 -Bus 001 Device 001: ID 0000:0000 -Bus 001 Device 002: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader -Bus 002 Device 001: ID 0000:0000 -Bus 005 Device 003: ID 06e0:f104 Multi-Tech Systems, Inc. -MT5634ZBA-USB MultimodemUSB (new firmware) -Bus 005 Device 001: ID 0000:0000 -Bus 005 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse -Bus 004 Device 001: ID 0000:0000 - - - - The relevant line in this output is that one mentioning the - existence of your modem. For example, Multi-Tech System, - Inc. MT5634ZBA-USB MultimodemUSB (new - firmware) - - I want to thank my friend Brians Suarez Alonso for - bringing this modem hardware to me and for his paitient, - resisting my repetitive calls at night to realize - connection tests. - - . This line confirms that your modem hardware is - supported by &TCD; and it is possible to transmit data through - it. Otherwise, if the modem you installed doesn't appear in - this list, it is probably because such hardware is not - supported by &TCD;, yet. - - - - Once you have confirmed the modem hardware has been installed - in the computer (either client or server), you need to - determine the device name the operating system assigned to it. - This information is required by programs like - mgetty and - wvdial, so they can know what - device to talk to. Assuming you've connected your modem - device through an USB port, the operating system will assign - the the /dev/ttyACM0 device file to talk - to it. On the other hand, assuming you've connected your - modem device through a serial port, the operating system will - use the /dev/ttyS0 device file to talk to - it. To be absolutly sure about what device name the operating - system assigned to your modem hardware, you can use the - lshal command from hal - package. - - - - - Configuring Modem Devices - - - Inside &TCD;, modem devices can be configured using the - system-config-network tool. This tool is a - manages modem configuration files under the - /etc/sysconfig/network-scripts and - /etc/wvdial.conf. Inside - /etc/sysconfig/network-scripts, modem - configuration files can take different file names. To identify - them you need to open the file and checking the value set on - DEVICE variable. This variable can take - values like ppp0 for the first modem device, - ppp1 for the second modem device, and so on for - other modem devices. - - - - The configuration files of modem devices may vary based on - whether the computer is acting as server, client or both. - When you configure the modem device on the server computer, - you should take care of specifying both the IP address - (IPADDR) and the network mask (NETMASK) inside the - configuration file. Otherwise, the established connection - might end up having the wrong IP information you need to - transfer data correctly through it, assuming the other end - isn't configured to specify it. When you configure the modem - device on the server computer, there is no need for you to set - any configuration related to wvdial, unless you be thinking to - make your server computer to act as a client of another server - computer. In fact, in the server computer, you can create the - modem configuration file by yourself based on the information - provided at - /usr/share/doc/initscripts-*/sysconfig.txt - - - - - When you configure the modem device on the client computer, - you don't need to take care of specifying either the IP - address or network mask because the server computer will - assign them for you. The assignment of client computer IP - address is configured by ppp daemon - when it is executed by mgetty after - an incoming call has arrived to modem's port. - - - - Modem configuration file - - Modem configuration file - - - -# Please read /usr/share/doc/initscripts-*/sysconfig.txt -# for the documentation of these parameters. -TYPE=modem -DEVICE=ppp0 -BOOTPROTO=none -ONBOOT=no -USERCTL=yes -PEERDNS=yes -AC=off -BSDCOMP=off -VJCCOMP=off -CCP=off -PC=off -VJ=off -LINESPEED=115200 -MODEMPORT=/dev/ttyACM0 -PROVIDER=ProviderName -DEFROUTE=yes -PERSIST=no -PAPNAME=faith -WVDIALSECT=ProviderName -MODEMNAME=Modem0 -DEMAND=no -IPV6INIT=no -IDLETIMEOUT=600 -NETMASK=255.255.255.0 -IPADDR=192.168.1.1 - - - - - - - - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp/network.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp/network.docbook deleted file mode 100644 index 7fa47ba..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp/network.docbook +++ /dev/null @@ -1,637 +0,0 @@ - - - The Network Of Computers - - - This section describes how you could distribute server and - client computers to create a collaborative network. - - - - One PPP Network Of Two Computers - - - The simpliest configuration we can achieve over the telephone - network involves two computers only, where one computer would - be acting as server and another as client. In this - configuration, the client computer establishes connection to - the server to make use of internet services provided therein. - - - - When the client computer calls the server computer, the call - is attended by mgetty and then - passed to pppd for establishing a - PPP conversation between the two computers. The first thing - in a PPP conversation is the user authentication and then - (after a sucessful athentication), the IPCP conversation takes - place to set IP addresses and start data transmission over the - link recently created. In this configuration, the client - computer can set its IP address when configuring the Modem - device (see ) or - leave the server computer to assign one (assuming you are - calling a server computer). If you are configuring a server - computer, then it is necessary that you set the IP address and - netmask of the IP network you are planning to set, using the - Modem device configuration file. - - - - Configuring the IP address and netmask information inside - Modem device configuration file is very important in order to - prevent errors when transmitting data across the link. When - the the netmask information isn't set in the Modem device - configuration file, the pppd daemon on the server computer - tries to retrive such information from the client computer and - if the client computer didn't specify one either, the network - recently created would end up having a wrong information - (e.g., 255.255.255.255) which provokes - the point-to-point connection to fail when someone tries to - transfer data through it. - - -
- One PPP network of two computers - - One PPP network of two computers - - - -Provice-A PPP Server Province-A PPP Client ---------------------------\ /-------------------------- -192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 ---------------------------/ \-------------------------- - - - - -
- - - The - describes the simpliest configuration we can implement for a - point-to-point connection. This configuration involves two - computers only, one acting as server (the server computer) and - other acting as client (the client computer). The client - computer calls the server computer to establish a PPP - connection in order to use whatever internet service the - server computer provides. In the figure we can see that there - are two IP addresses involved (192.168.1.1 and 192.168.1.2) inside the same - newtork (255.255.255.0). - - - - This configuration might be convenient for people in the same - location, near one another. Here, the client computer - establishes connection by mean of a local telephone call and - can use whatever internet service the server computer - provides. Since the connection lifetime is limited (see ) and only two - peers can be connected at the same time (assuming only one - Modem is attached to the server computer), the implementation - of some internet services like chat may be not a practical - offer for the server computer to provide. However, internet - services like e-mail fit perfectly on this environment where - more than one client computer would be struggling among - themselves for establishing connection with the server - computer (e.g., people connect to send/receive their e-mail - messages to/from the server computer). - - - - - - One PPP Network Of Several Computers - - - Based on , it is - possible to provide an extended version including several - server computers that may communicate between themselves to - distribute data collected from client computers they serve to. - For example, consider the telephone network of a country which - is organized in provinces and each province is divided in - several municipalities. In such organization, it would be - possible to set one or more server computers for each province - and let near people to dial-up on them to use whatever - internet service they provide. Later, it could be possible - for each server computer to establish a dial-up connections - with other near server computers in order to share information - from one province to another, as it is illustrated in . - - - - When setting the IP information, it is important that each - server computer sets both IP address and IP network mask - information in the Modem device configuration file so - different IP address can be use between different server - computers. It is also important that they all be configured to - use authentication between themselves before transmitting any - data across a PPP established connection so the information - being transmitted can be protected. - - - - When making telephone calls, if someone in Province-A needs to - send a message to someone in Province-C (which is far away - from Province-A and making a telephone call there would imply - a considerable amount of money), there is no need (even it is - possible and sometimes prefered) for that person to realize a - direct telephone call from Province-A to Province-C. Instead, - that person in Province-A can send its messages to the server - computer on its province (the nearest server on its location) - making a local telephone call and then, such server computer - would take care of delivering the information using other - server computers, following the same concept of nearest - delivery. - - -
- One PPP network of several computers - - One PPP network of several computers - - - -Provice-A PPP Server Province-A PPP Client ---------------------------\ /-------------------------- -192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 ---------------------------/ | \-------------------------- - | -Provice-B PPP Server | Province-B PPP Client ---------------------------\ | /-------------------------- -192.168.1.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.4/24 ---------------------------/ | \-------------------------- - | -Provice-C PPP Server | Province-C PPP Client ---------------------------\ | /-------------------------- -192.168.1.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.6/24 ---------------------------/ \-------------------------- - - - - -
- - - The more distant a telephone call is, the more expensive it - is. This way, to move information from one province to - another, each server computers must be configured to send - information to the nearest province until reaching its - destination. For example, if you are in Province-A and want to - send an e-mail message to Province-D, the server computer - configured in Province-A must sed the e-mail message to - Province-B, then server in Province-B must be configured to - send such message to Province-C, and finally C to D. This is - required because making a direct call from Province-A to - Province-D would be otherwise too much expensive to pay. - - - - Since telephone calls are required to establish connections - between computers and each call costs money based on the - location and the destination, it is required to set a - convenction in how telephone calls are realized from one - server computer to another, specially if you plan to establish - connection between server computer placed on different - provices in order to exchange data between them. - - - - - - Do you make direct telephone calls to make direct data delivery? - — This configuration could be very expensive to maintain - (considering the telephone call distances), but data will be - delivered very fast to their destinations. - - - - - Do you call the nearest server computer and let it to deliver - your data to its destination? — This configuration could - be less expensive to maintain (considering the telephone call - distances), but data delivery will take much more time to - reach their destinations and there is no way to be sure it - will do. - - - - - - - Whatever calling schema be chosen, the server computers will - always talk through UUCP to transfer data from one place to - another. The server computers will operate with two IP - addresses each, unless you plan to connect one of the server - computers to a different network (Internet, maybe?). One IP - address would identify the server computer itself and the - other would identify the client computer establishing PPP - connection to the server computer. In this configuration it - is very importat that each server and client computer does - have one unique IP address. This way it would be possible to - move the information from one computer to another. Notice that - the number of PPP clients is directly related to the number of - telephone lines a server computer has configured to receive - incomming calls on. If there is only one telephone line - attached to the server computer then, only one client computer - will be able to establish connection to that server computer. - Other PPP clients will need to wait until the telephone line - gets free in order to establish connection with that server - computer. On the other hand, if the server computer has two - (or more) attached telephone lines, it would be possible to - attend incoming calls from two (or more) PPP client at the - same time. As resume, we can say that: the more telephone - lines the server computer has attached in, the more - simultaneous connections that computer will be able to - attend/realize from/to other computers. - - - - - - One PPP+Ethernet Network Of Several Computers - - - Assuming all server computers with a Modem device have also - one (or more) Ethernet interface attached (which is very - common nowadays), it would be possible to extend the - configuration described in - creating one Ethernet network for each server computer in the - configuration. For this configuration to be implemented it is - required one or more switch devices (based on the amount of - computers such network needs to have) for each ethernet - network interface a server computer has, as described in . - - -
- One PPP+Ethernet network of several computers - - One PPP+Ethernet network of several computers - - - -Province-A PPP/ETH Server Province-A PPP Client ---------------------------\ /-------------------------- -192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 ---------------------------/ | \-------------------------- -192.168.0.1/24 | Ethernet | ----------------------|---- | - | | - +--------+ | - | Switch | | - +--------+ | - | | ----------------------|-- | -LAN1: 192.168.0.2-254/24 | ------------------------- | -Province-A ETH Clients | - | -Province-B PPP/ETH Server | Province-B PPP Client ---------------------------\ | /-------------------------- -192.168.1.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.4/24 ---------------------------/ | \-------------------------- -192.168.2.1/24 | Ethernet | ----------------------|---- | - | | - +--------+ | - | Switch | | - +--------+ | - | | ----------------------|-- | -LAN2: 192.168.2.2-254/24 | ------------------------- | -Province-B ETH Clients | - | -Province-C PPP/ETH Server | Province-C PPP Client ---------------------------\ | /-------------------------- -192.168.1.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.6/24 ---------------------------/ \-------------------------- -192.168.3.1/24 | Ethernet ----------------------|---- - | - +--------+ - | Switch | - +--------+ - | ----------------------|-- -LAN3: 192.168.3.2-254/24 ------------------------- -Province-C ETH Clients - - - - -
- - - In this configuration, computers connected to the switch will - also be considered as client computers. It is necessary that a - coordination be implemented at time of setting IP addresses to - new server computers so no IP address be duplicated on the - computer network. The illustration above describes one main - network (192.168.1/24) which connects - all the server computers using the telephone lines as medium - for data transmission. The Modem interface connects just one - computer at a time either client or server (assuming only one - Modem device is installed and configured in - the computer acting as server). The telephone line is used by - client computers to establish PPP connections with the server - computer and by server computers to exchange data with other - server computers, as well. On the other hand, the ethernet - interface attached to each server computer let the - administrator of each server computer to connect up to 252 - computers simultaneously, assuming a class C network as shown - above be used. - - There are also class A and class B network types which can be - used to connect much more computers than a class C network - allows to. - - - - - - - - About Bridging Calls To Transfer Data - - - When the server computers call other server computers to - bridge data delivery, the server computer in, let's say, - Province-A (srv-1.a.domain.tld) will never know that there is - a server computer on Province-C (srv-1.c.domain.tld) or - Province-D (srv-1.d.domain.tld), but in Province-B - (srv-1.b.domain.tld) - only, its nearest location. So, when a message is sent from - srv-1.a.domain.tld to the server computer in - srv-1.d.domain.tld, the server computer in srv-1.a.domain.tld - contacts its nearest server computer (i.e., - srv-1.b.domain.tld) and delivers to it all messages sent to - srv-1.d.domain.tld. Later, since srv-1.b.domain.tld doesn't - know about srv-1.d.domain.tld server either, it delivers all - messages directed to srv-1.d.domain.tld to its nearest server - computer (i.e., srv-1.c.domain.tld). Later, the server - computer in srv-1.c.domain.tld, which knows about - srv-1.d.domain.tld, delivers to it all the messages it has for - it. Notice that, in order for this configuration to work, - system administrators attending the server computers must work - syncronized to garantee a well defined route for messages to - follow. Otherwise, if one of the server computers in the path - creates a route for a server computer that doesn't exist - (or doesn't define a route at all), the information will never - reach its destination when such computer is acting as a bridge - between other two server computers. - - - -+------------------------+ +------------------------+ +------------------------+ +---------------------+ -| To: bob@d.domain.tld | | To: bob@d.domain.tld | | To: bob@d.domain.tld | | Bob's mailbox | -| From: mat@a.domain.tld | | From: ana@b.domain.tld | | From: jef@c.domain.tld | | (Final destination) | -| Body: 500KB | | Body: 500KB | | Body: 500KB | | | -+---|--------------------+ +---|--------------------+ +---|--------------------+ +------------------^--+ - | | | | -----v--------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|------------------|--- -srv-1.a.domain.tld | 75Km Call | srv-1.b.domain.tld | 75Km Call | srv-1.c.domain.tld | 75Km Call | srv-1.d.domain.tld --------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|---------------------- -relay to: | 5 min | relay to: | 10 min | relay to: | 15 min | -srv-1.b.domain.tld | 500KB | srv-1.c.domain.tld | 1.0MB | srv-1.d.domain.tld | 1.5MB | - - - - - About Directing Calls To Transfer Data - - - When the server computers make direct telephone calls (no - bridge in-between is used to transfer data), the server - computer in Province-A (srv-1.a.domain.tld) contacts the - server computer in Province-D (srv-1.d.domain.tld) making a - direct telephone call up to it. In this configuration, the - telephone call might cost more than those in a bridged - configuration where several smaller telephone calls are dialed - in-between the final server computer; or less, considering - that when server computers in a bridged configuration exchange - data they may move data accumulated from other server - computers, while a direct telephone call would transmit data - from one server computer to another without any accumulated - data from other server computers. There is no need to - overload the server computers with foreign data when each - server computer could call themselves to transfer data - directly. - - - -+------------------------+ +---------------------+ -| To: bob@d.domain.tld | | Bob's mailbox | -| From: mat@a.domain.tld | | (Final destination) | -| Body: 500KB | | | -+--|---------------------+ +------------------^--+ - | | ----v---------------------|<~~~~~~~~~~>|-------------------|--- -srv-1.a.domain.tld | 225Km Call | srv-1.d.domain.tld --------------------------|<~~~~~~~~~~>|----------------------- -relay to: | 5 min | -srv-1.d.domain.tld | 500KB | - - - - The elapsed time in a server-to-server conversation is - directly related to the amount of data that need to be moved - from one server to another and the baud rate of the connection - established between the two Modem devices. In a direct - telephone call configuration, telephone calls could result to - be less expensive than those in bridged configurations where - server computers may accumulate traffic from other server - computers in the path. The accumulation of traffic between - server computers increases the amount of time the last server - computer in the path before the final destination needs, in - order to transmit everything to the final destination. In a - bridged telephone call configuration, server computers acting - as bridges do act as servers as well and produce their own - traffic which is added to that one already accumulated in - them from other server computers. This may provoke a heugh - traffic in a server-to-server conversation (remarkably on the - last destination before the final destination), that could be - potentially increased with each new server computer added to - the string of server computers acting as bridges one another. - - - - - - About Authenticating PPP Users - - - The client computers will need to authenticate against the - server computer each time they intend to establish a PPP - connection. The username and password required by client - computers will be public and will be rarely changed. - - - - Credentials for PPP authentication - - Credentials for PPP authentication - - - - ISP Name: projects.centos.org -ISP Phone: +53043515094 - Username: faith - Password: mail4u.2k10 - - - - - - - - The server computer provides only one telephone line available - (e.g., +53043515094) to receive incoming calls. This affects - directly the possibilities a client computer has to establish - connection with the server computer in an environment where - several client computers are struggling among themselves to - establish a dial-up connection with the server computer. To - prevent this kind of issues from happening, it is innevitable - for the server computer to provide more telephone lines for - incoming calls (at least one for each user the server computer - expects to receive incoming calls from). - - - - - - About Restricting PPP Connections - - - The server computer restricts the lifetime of established - Modem connections to 15 minutes from the establishment moment - on. Once the connection has been established, if the link is - idle for 1 minute, the server computer will also close the - established connection to free the telephone line. This - control can be implemented through the - and options - inside the pppd's configuration - file as described in . - - - - The server computer restricts the incoming calls from client - computers every night from 10:00PM to 12:00AM. Outside this - range of time, the telephone could be answered by a person, - not a computer. This control can be implemented through a cron - job and the /etc/nologin.ttyxx file; - where ttyxx represents the device name of your Modem (e.g., - /etc/nologin.ttyACM0 would prevent the - Modem device installed in /dev/ttyACM0 - from answering calls). - - - -# Activate Modem to attend incoming calls. -59 21 * * * [ -f /etc/nologin.ttyACM0 ] && /bin/rm /etc/nologin.ttyACM0 -# Deactivate Modem to prevent incoming calls from being attended. -59 23 * * * [ ! -f /etc/nologin.ttyACM0 ] && /bin/touch /etc/nologin.ttyACM0 - - - - - - About Providing Internet Services - - - The implementation of internet services which require - persistent connections (e.g., - chats) should not be considered as - a practical offer for PPP client computers. Instead, only - asynchronous services (e.g., - e-mail) should be supported for - them. This restriction is required to reduce the connection - times demanded such services. For example, consider an - environment where you establish connection with a server - computer to send/receive e-mails messages and then quickly - disconnect from it to free the telephone line so others be - able of using it. In this environment, there is no need for - you and others to be both connected at the same time to - send/receive e-mail messages to/from each other. The e-mails - sent from other person to you will be available in your - mailbox the next time you get connected to the server computer - and use your e-mail client to send/receive e-mail messages. - Likewise, you don't need to be connected to the server - computer in order to write your e-mail messages. You can - write down your messages off-line and then establish - connection once you've finished writing, just to send them out - and receive new messages that could have been probably sent to - you. - - - - Another issue related to e-mail exchange is the protocol used - to receive messages. Presently, there are two popular ways to - do this, one is through IMAP and another through POP3. When - you use IMAP protocol, e-mail messages are retained in the - server computer and aren't downloaded to client computer. - Otherwise, when you use POP3 protocol, e-mail messages are - downloaded to the client computer and removed from server - computer. Based on the resources we have and the kind of link - used by the client computer to connect the server computer, - using POP3 is rather prefered than IMAP. However both are made - available. - - - - Assuming you use IMAP protocol to read your mailbox, be aware - that you need to be connected to the server computer. Once - the connection is lost you won't be able to read your messages - (unless your e-mail client possesses a feature that let you - reading messages off-line). Moreover, you run the risk of - getting your mailbox out of space. If your mailbox gets out of - space, new messages sent to you will not be deliver to your - mailbox. Instead, they will be deferred for a period of time - (e.g., about 5 days when using - Postfix defaults) hoping you to - free the space in your mailbox to deliver them. If you don't - free space on your mailbox within this period of time, the - deferred e-mails will be bounced back to their senders and you - will never see them. On the other hand, assuming you are - using POP3 protocol to read your mailbox, you always keep your - mailbox free to receive new e-mails messages and keep them for - you until the next time you establish connection with the - server computer and download them to your client computer - using your e-mail client. - - - - The information generated inside the server computer is - isolated from Internet. This way, any information generated - inside the server computer will be available only to people - connected to the same network the server computer is connected - to. For example, don't ever expect to send/receive e-mails - to/from Internet e-mail accounts like Gmail or Yahoo, nor - visiting web sites like Google or Wikipedia either. For - this to happen, an established connection must exist first - between the server computer you are establishing connection - through and the Internet network those services are available - in. Without that link, it is not possible to direct your - requests to those sites, nor receive any response from them. - - - - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp/overview.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp/overview.docbook deleted file mode 100644 index de2356f..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp/overview.docbook +++ /dev/null @@ -1,55 +0,0 @@ - - - Overview - - - This chapter describes how you can use the Point-to-Point - Protocol (PPP) to create collaborative networks in situations - where the telephone network is the only medium you and your - friends have access to. With PPP you can prepare a server - computer to provide internet services for client computers - that use the telephone network as medium for data transmition. - The configuration described here can be thought as one client - computer that establishes connection to a server computer in - order to use the internet services it provides, however, based - on this concept, other configuration are also possible to - satisfy situations where more than two computers need to be - involved. - - - - The operating system used by both server and client computers - will be &TCD; release 5.5 - - Thank to my friend Manual Chavez Manzano (Manny) for - finding a way to download this release of &TCD; and bring - it to me as a gift when I was completly isolated from - Internet without any possibility of downloading it by - myself. - - . The configuration described in this book doesn't - use third party software. All the software needed in this - configuration is available inside &TCD;. In case you are - using a different operating system in your client computer, - you'll need to look the appropriate application your operating - system provides to establish PPP connections and configure it - to establish connection with the server computer described in - . Generally, the - most you need to establish connection with the server computer - is a telephone number and the credentials for authentication, - if any. - - - - In this chapter you'll find how to configure your client - computer to dial-up the server computer automatically when - client applications (e.g., e-mail clients, web browsers, etc.) - request data transmition for the server computer at a moment - where no connection has been established with it, yet. Also, - this chapter covers different considerations you could take - into account to keep the telephone line as free as possible, - so different client computers be able of establishing - connection to the same server computer as quickly as possible. - - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp/policy.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp/policy.docbook deleted file mode 100644 index 5bcef6c..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp/policy.docbook +++ /dev/null @@ -1,5 +0,0 @@ - - - Usage Convenctions - - diff --git a/Documentation/Tcpi-ug/Connectivity/Ppp/server.docbook b/Documentation/Tcpi-ug/Connectivity/Ppp/server.docbook deleted file mode 100644 index 57160e0..0000000 --- a/Documentation/Tcpi-ug/Connectivity/Ppp/server.docbook +++ /dev/null @@ -1,288 +0,0 @@ - - - The Server Computer - - - When you are configuring the server computer, you need to - install and configure both mgetty - and pppd programs. The - mgetty program lets you attend - incoming calls and must be configured to run through - init daemon in order - to take control over the Modem device. By default, inside - &TCD; (release 5.5), mgetty isn't - configured to start with init daemon so you need to do it - yourself (see ). - Later, for attending connection requests, you need to - configure mgetty to use the - pppd program, so the Point-to-Point - Protocol (PPP) can be talked and IP packages can be exchange - between the client computer and the server computer. Later, - you need to configure pppd to - adjust it to your needs (see ). Once - you've configured both mgetty and - pppd programs, the server computer - should be ready to attend incoming calls. - - - - <package>mgetty</package> - - Taken from mgetty man page: — Mgetty - is a smart getty replacement, designed to be - used with hayes compatible data and data/fax modems. Mgetty - knows about modem initialization, manual modem answering (so - your modem doesn’t answer if the machine isn’t ready), UUCP - locking (so you can use the same device for dial-in and - dial-out). Mgetty provides very extensive logging facilities - —. - - - Before using the configuration provided here, it would be - useful for you to read the documentation provided in the - mgetty and SysVinit - packages. This will let you to understand what you are - configuring. - - - - <filename>/etc/inittab</filename> - -# Run mgetty to control a Multi-Tech (MT5634ZBA-USB) modem attached to -# `/dev/ttyAMC0' device. Incoming calls will be attended without fax -# initalization. -ACM0:2345:respawn:/sbin/mgetty -D ttyACM0 - - - - - <filename>/etc/mgetty+sendfax/login.config</filename> - -# Automatic PPP startup on receipt of LCP configure request (AutoPPP). -# mgetty has to be compiled with "-DAUTO_PPP" for this to work. -# Warning: Case is significant, AUTOPPP or autoppp won't work! -# Consult the "pppd" man page to find pppd options that work for you. -# -# NOTE: for *some* users, the "-detach" option has been necessary, -# for others, not at all. If your pppd doesn't die after hangup, try -# it. -# -# NOTE2: "debug" creates lots of debugging info. LOOK AT IT if -# things do not work out of the box, most likely it's a ppp problem! -# -# NOTE3: "man pppd" is your friend! -# -# NOTE4: max. 9 arguments allowed. -# -#/AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap login debug -/AutoPPP/ - a_ppp /usr/sbin/pppd 192.168.1.1:192.168.1.2 - - - - In this configuration, we set both local and remote IP - addresses to fix the IP information used by computers once the - PPP connection has been established. All other options are - taken from the options file (see ). If we - don't specify both local and remote IP addresses when pppd is - initialized, pppd will try to take such information from the - first Modem device you configured (e.g., ppp0) and will expect - the remote peer to provide its IP address. This situation can - introduce some contraditions (e.g., the local and remote - address may be on a different network.) that would make the - connection to fail. - - - - Another issue we might face out would be the netmask - specification of the poin-to-point network established between - the two computers. Inside the pppd-2.4.4 man page there is no - reference to the option, however, - there is a mention to it on the sample files installed with it - which is quiet confussing. It seems to be required that one of - the two computers establishing connection defines the netmask - information of the network they are creating. So, to do it on - the server computer (the one receiving calls), it is needed to - set the netmask definition in the Modem device configuration - file of it () along with the local IP address. Otherwise, even local and - remote IP addresses be specified through the pppd, the - connection will end up having the 255.255.255.255 netmask - which would let you ping the computer on the other end but - that will not last too long before it fails and iptables seems - to get very confused about it. - - - - Since we are already using pppd to attend login requests, - there is no need to invoke the - login program. So, comment the - related line as described below. - - - -#* - - /bin/login @ - - - - - - <filename>/etc/mgetty+sendfax/dialin.config</filename> - - I didn't touch this file, but you might need to. - - - - - <filename>/etc/mgetty+sendfax/mgetty.config</filename> - - I didn't touch this file, but you might need to. - - - - - - - <package>pppd</package> - - Taken from pppd man page: — PPP is the protocol used for - establishing internet links over dial-up modems, DSL - connections, and many other types of point-to-point links. - The pppd daemon works together with the kernel PPP driver to - establish and maintain a PPP link with another system (called - the peer) and to negotiate Internet Protocol (IP) addresses - for each end of the link. Pppd can also authenticate the peer - and/or supply authentication information to the peer. PPP can - be used with other network protocols besides IP, but such use - is becoming increasingly rare —. - - - - Before using the configuration provided here, it would be - useful for you to read the documentation provided in the - ppp package. This will let you to - understand what you are configuring. - - - - <filename>/etc/pppd/options</filename> - -# Enables connection debugging facilities. If this option is given, -# pppd will log the contents of all control packets sent or received -# in a readable form. The packets are logged through syslog with -# facility daemon and level debug. This information can be directed -# to a file by setting up /etc/syslog.conf appropriately (see -# syslog.conf(5)). -debug - -# Require the peer to authenticate itself before allowing network -# packets to be sent or received. This option is the default if the -# system has a default route. If neither this option nor the noauth -# option is specified, pppd will only allow the peer to use IP -# addresses to which the system does not already have a route. -auth - -# Specifies that pppd should create a UUCP-style lock file for the -# serial device to ensure exclusive access to the device. By default, -# pppd will not create a lock file. -lock - -# Specify which DNS Servers the incoming Win95 or WinNT Connection -# should use Two Servers can be remotely configured. -ms-dns 192.168.1.1 - -# If this option is given, pppd will send an LCP echo-request frame to -# the peer every n seconds. Under Linux, the echo-request is sent when -# no packets have been received from the peer for n seconds. Normally -# the peer should respond to the echo-request by sending an -# echo-reply. This option can be used with the lcp-echo-failure -# option to detect that the peer is no longer connected. -lcp-echo-interval 30 - -# If this option is given, pppd will presume the peer to be dead if n -# LCP echo-requests are sent without receiving a valid LCP echo-reply. -# If this happens, pppd will terminate the connection. Use of this -# option requires a non-zero value for the lcp-echo-interval -# parameter. This option can be used to enable pppd to terminate -# after the physical connection has been broken (e.g., the modem has -# hung up) in situations where no hardware modem control lines are -# available. -lcp-echo-failure 4 - -# Specifies that pppd should disconnect if the link is idle for n -# seconds. -idle 60 - -# Specifies that pppd should disconnect if the link have been active -# for n seconds. -maxconnect 900 - -# Disable the IPXCP and IPX protocols. -noipx - - - - - <filename>/etc/pppd/cha-secrets</filename> - -# Secrets for authentication using CHAP -# client server secret IP addresses - -# Specify the client configuration. This is when this manchine calls -# someone's else machine and tries to establish a point-to-point -# connection. Most of this configuration is handled by the -# `system-config-network' utility. -# -####### redhat-config-network will overwrite this part!!! (begin) ########## -####### redhat-config-network will overwrite this part!!! (end) ############ - -# Specify the server configuration. This is when someone's else -# machine calls this machine trying to establish a point-to-point -# connection. This part of the configuration isn't handled by -# `system-config-network' utility. By default, there is one line to -# verify client's identity with authenticating it and one line to let -# the server computer to authenticate itself with the client computer -# in case the client computer requires so. All client computers will -# be authenticated through the `faith' user. However, it is possible -# to provide anonymous authentication to client computers by using an -# empty client identity (as explained in pppd's man page) in order to -# restrict the IP address they can use. -# -"faith" "projects" "mail4u.2k10" "192.168.1.2" -#"" "projects" "" "192.168.1.2" -"projects" * "mail4u.2k10" - - - - Assuming the hostname of the server computer is - projects, when a client computer uses the faith - username to login on it, the 192.168.1.2 IP address will be - assigned to that client computer after a successful - authentication. This configuration is just for one Modem - device attached to the server computer. In case you have more - than one Modem device attached to the server computer, it - would be necessary to add one username for each Modem device - you have, in order to permit the client computers to connect - simultaneously. It is not possible to have two or more - computers with the same IP address in the same network. - - - - - - <filename>/etc/pppd/pap-secrets</filename> - - This file contains the same information of - cha-secrets file does. See . - - - - - - diff --git a/Documentation/Tcpi-ug/Licenses.docbook b/Documentation/Tcpi-ug/Licenses.docbook deleted file mode 100755 index bcb5cec..0000000 --- a/Documentation/Tcpi-ug/Licenses.docbook +++ /dev/null @@ -1,7 +0,0 @@ - - - Licenses - - &licenses-gfdl; - - diff --git a/Documentation/Tcpi-ug/Licenses.ent b/Documentation/Tcpi-ug/Licenses.ent deleted file mode 100755 index dd7f27a..0000000 --- a/Documentation/Tcpi-ug/Licenses.ent +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/Documentation/Tcpi-ug/Licenses/gfdl.docbook b/Documentation/Tcpi-ug/Licenses/gfdl.docbook deleted file mode 100755 index 33f6e8c..0000000 --- a/Documentation/Tcpi-ug/Licenses/gfdl.docbook +++ /dev/null @@ -1,591 +0,0 @@ - - - GNU Free Documentation License - - Version 1.2, November 2002 - - Copyright © 2000, 2001, 2002 Free Software Foundation, - Inc. 675 Mass Ave, Cambridge, MA 02139, USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - Preamble - - The purpose of this License is to make a manual, - textbook, or other functional and useful document - free in the sense of freedom: to assure - everyone the effective freedom to copy and redistribute it, - with or without modifying it, either commercially or - noncommercially. Secondarily, this License preserves for the - author and publisher a way to get credit for their work, while - not being considered responsible for modifications made by - others. - - This License is a kind of copyleft, which - means that derivative works of the document must themselves be - free in the same sense. It complements the , which is a copyleft license - designed for free software. - - We have designed this License in order to use it for - manuals for free software, because free software needs free - documentation: a free program should come with manuals - providing the same freedoms that the software does. But this - License is not limited to software manuals; it can be used for - any textual work, regardless of subject matter or whether it - is published as a printed book. We recommend this License - principally for works whose purpose is instruction or - reference. - - - - - - Applicability and definitions - - This License applies to any manual or other work, in any - medium, that contains a notice placed by the copyright holder - saying it can be distributed under the terms of this License. - Such a notice grants a world-wide, royalty-free license, - unlimited in duration, to use that work under the conditions - stated herein. The Document, below, refers to - any such manual or work. Any member of the public is a - licensee, and is addressed as you. You accept - the license if you copy, modify or distribute the work in a - way requiring permission under copyright law. - - A - Modified Version of the Document means any work - containing the Document or a portion of it, either copied - verbatim, or with modifications and/or translated into another - language. - - A - Secondary Section is a named appendix or a - front-matter section of the Document that deals exclusively - with the relationship of the publishers or authors of the - Document to the Document's overall subject (or to related - matters) and contains nothing that could fall directly within - that overall subject. (Thus, if the Document is in part a - textbook of mathematics, a may not explain any mathematics.) The relationship could be - a matter of historical connection with the subject or with - related matters, or of legal, commercial, philosophical, - ethical or political position regarding them. - - The Invariant Sections are certain - whose titles are - designated, as being those of Invariant Sections, in the - notice that says that the Document is released under this - License. If a section does not fit the above definition of - Secondary then it is not allowed to be designated as - Invariant. The Document may contain zero Invariant Sections. - If the Document does not identify any Invariant Section then - there are none. - - The - Cover Texts are certain short passages of text - that are listed, as Front-Cover Texts or Back-Cover Texts, in - the notice that says that the Document is released under this - License. A Front-Cover Text may be at most 5 words, and a - Back-Cover Text may be at most 25 words. - - A - Transparent copy of the Document means a - machine-readable copy, represented in a format whose - specification is available to the general public, that is - suitable for revising the document straightforwardly with - generic text editors or (for images composed of pixels) - generic paint programs or (for drawings) some widely available - drawing editor, and that is suitable for input to text - formatters or for automatic translation to a variety of - formats suitable for input to text formatters. A copy made in - an otherwise file format whose - markup, or absence of markup, has been arranged to thwart or - discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of - text. A copy that is not is called Opaque. - - Examples of suitable formats for copies - include plain ASCII without markup, Texinfo input format, - LaTeX input format, SGML or XML using a publicly available - DTD, and standard-conforming simple HTML, PostScript or PDF - designed for human modification. Examples of transparent - image formats include PNG, XCF and JPG. Opaque formats - include proprietary formats that can be read and edited only - by proprietary word processors, SGML or XML for which the DTD - and/or processing tools are not generally available, and the - machine-generated HTML, PostScript or PDF produced by some - word processors for output purposes only. - - The Title - Page means, for a printed book, the title page itself, - plus such following pages as are needed to hold, legibly, the - material this License requires to appear in the title page. - For works in formats which do not have any title page as such, - Title Page means the text near the most - prominent appearance of the work's title, preceding the - beginning of the body of the text. - - A section Entitled XYZ means a named - subunit of the Document whose title either is precisely XYZ or - contains XYZ in parentheses following text that translates XYZ - in another language. (Here XYZ stands for a specific section - name mentioned below, such as Acknowledgements, - Dedications, Endorsements, or - History.) To Preserve the Title - of such a section when you modify the Document means that it - remains a section Entitled XYZ according to - this definition. - - The Document may include Warranty Disclaimers next to - the notice which states that this License applies to the - Document. These Warranty Disclaimers are considered to be - included by reference in this License, but only as regards - disclaiming warranties: any other implication that these - Warranty Disclaimers may have is void and has no effect on the - meaning of this License. - - - - - - Verbatim copying - - You may copy and distribute the Document in any medium, - either commercially or noncommercially, provided that this - License, the copyright notices, and the license notice saying - this License applies to the Document are reproduced in all - copies, and that you add no other conditions whatsoever to - those of this License. You may not use technical measures to - obstruct or control the reading or further copying of the - copies you make or distribute. However, you may accept - compensation in exchange for copies. If you distribute a - large enough number of copies you must also follow the - conditions in section . - - You may also lend copies, under the same conditions - stated above, and you may publicly display copies. - - - - - - Copying in quantity - - If you publish printed copies (or copies in media that - commonly have printed covers) of the Document, numbering more - than 100, and the Document's license notice requires Cover - Texts, you must enclose the copies in covers that carry, - clearly and legibly, all these : - Front-Cover Texts on the front cover, and Back-Cover Texts on - the back cover. Both covers must also clearly and legibly - identify you as the publisher of these copies. The front - cover must present the full title with all words of the title - equally prominent and visible. You may add other material on - the covers in addition. Copying with changes limited to the - covers, as long as they preserve the title of the Document and - satisfy these conditions, can be treated as verbatim copying - in other respects. - - If the required texts for either cover are too - voluminous to fit legibly, you should put the first ones - listed (as many as fit reasonably) on the actual cover, and - continue the rest onto adjacent pages. - - If you publish or distribute Opaque copies of the - Document numbering more than 100, you must either include a - machine-readable copy along with each Opaque copy, - or state in or with each Opaque copy a computer-network - location from which the general network-using public has - access to download using public-standard network protocols a - complete copy of the Document, free of added - material. If you use the latter option, you must take - reasonably prudent steps, when you begin distribution of - Opaque copies in quantity, to ensure that this - copy will remain thus accessible at the stated location until - at least one year after the last time you distribute an Opaque - copy (directly or through your agents or retailers) of that - edition to the public. - - It is requested, but not required, that you contact the - authors of the Document well before redistributing any large - number of copies, to give them a chance to provide you with an - updated version of the Document. - - - - - - Modifications - - You may copy and distribute a of the Document under the - conditions of sections and above, - provided that you release the under precisely this License, with the filling the role of the - Document, thus licensing distribution and modification of the - to whoever possesses a - copy of it. In addition, you must do these things in the - : - - - - - Use in the (and on - the covers, if any) a title distinct from that of the - Document, and from those of previous versions (which - should, if there were any, be listed in the History - section of the Document). You may use the same title - as a previous version if the original publisher of - that version gives permission. - - - List on the , as - authors, one or more persons or entities responsible - for authorship of the modifications in the , together with at least - five of the principal authors of the Document (all of - its principal authors, if it has fewer than five), - unless they release you from this requirement. - - - - State on the the - name of the publisher of the , as the - publisher. - - - - Preserve all the copyright notices of the - Document. - - - - Add an appropriate copyright notice for your - modifications adjacent to the other copyright - notices. - - - - Include, immediately after the copyright - notices, a license notice giving the public permission - to use the under the terms of this - License, in the form shown in the Addendum - below. - - - - Preserve in that license notice the full lists - of and required - given in the Document's - license notice. - - - - Include an unaltered copy of this License. - - - - Preserve the section Entitled - History, Preserve its Title, and add to - it an item stating at least the title, year, new - authors, and publisher of the as given on the . If there is no section - Entitled History in the Document, create - one stating the title, year, authors, and publisher of - the Document as given on its , then add an item describing the as stated in the previous - sentence. - - - - Preserve the network location, if any, given in - the Document for public access to a copy of the Document, and - likewise the network locations given in the Document - for previous versions it was based on. These may be - placed in the History section. You may - omit a network location for a work that was published - at least four years before the Document itself, or if - the original publisher of the version it refers to - gives permission. - - - - For any section Entitled - Acknowledgements or - Dedications, Preserve the Title of the - section, and preserve in the section all the substance - and tone of each of the contributor acknowledgements - and/or dedications given therein. - - - - Preserve all the of the Document, - unaltered in their text and in their titles. Section - numbers or the equivalent are not considered part of - the section titles. - - - - Delete any section Entitled - Endorsements. Such a section may not - be included in the . - - - - Do not retitle any existing section to be - Entitled Endorsements or to conflict in - title with any . - - - Preserve any Warranty Disclaimers. - - - - - If the includes new - front-matter sections or appendices that qualify as and contain no material copied - from the Document, you may at your option designate some or - all of these sections as invariant. To do this, add their - titles to the list of in the 's license notice. These titles - must be distinct from any other section titles. - - You may add a section Entitled - Endorsements, provided it contains nothing but - endorsements of your by various - parties–for example, statements of peer review or that - the text has been approved by an organization as the - authoritative definition of a standard. - - You may add a passage of up to five words as a - Front-Cover Text, and a passage of up to 25 words as a - Back-Cover Text, to the end of the list of in the . Only one passage of - Front-Cover Text and one of Back-Cover Text may be added by - (or through arrangements made by) any one entity. If the - Document already includes a cover text for the same cover, - previously added by you or by arrangement made by the same - entity you are acting on behalf of, you may not add another; - but you may replace the old one, on explicit permission from - the previous publisher that added the old one. - - The author(s) and publisher(s) of the Document do not by - this License give permission to use their names for publicity - for or to assert or imply endorsement of any . - - - - - - Combining documents - - You may combine the Document with other documents - released under this License, under the terms defined in - section above for - modified versions, provided that you include in the - combination all of the of - all of the original documents, unmodified, and list them all - as of your combined work - in its license notice, and that you preserve all their - Warranty Disclaimers. - - The combined work need only contain one copy of this - License, and multiple identical may be replaced with a single - copy. If there are multiple with the same name but - different contents, make the title of each such section unique - by adding at the end of it, in parentheses, the name of the - original author or publisher of that section if known, or else - a unique number. Make the same adjustment to the section - titles in the list of in - the license notice of the combined work. - - In the combination, you must combine any sections - Entitled History in the various original - documents, forming one section Entitled - History; likewise combine any sections Entitled - Acknowledgements, and any sections Entitled - Dedications. You must delete all sections - Entitled Endorsements. - - - - - - Collection of documents - - You may make a collection consisting of the Document and - other documents released under this License, and replace the - individual copies of this License in the various documents - with a single copy that is included in the collection, - provided that you follow the rules of this License for - verbatim copying of each of the documents in all other - respects. - - You may extract a single document from such a - collection, and distribute it individually under this License, - provided you insert a copy of this License into the extracted - document, and follow this License in all other respects - regarding verbatim copying of that document. - - - - - - Aggregation with independent works - - A compilation of the Document or its derivatives with - other separate and independent documents or works, in or on a - volume of a storage or distribution medium, is called an - aggregate if the copyright resulting from the - compilation is not used to limit the legal rights of the - compilation's users beyond what the individual works permit. - When the Document is included in an aggregate, this License - does not apply to the other works in the aggregate which are - not themselves derivative works of the Document. - - If the Cover Text requirement of section is applicable to these - copies of the Document, then if the Document is less than one - half of the entire aggregate, the Document's may be placed on covers that bracket - the Document within the aggregate, or the electronic - equivalent of covers if the Document is in electronic form. - Otherwise they must appear on printed covers that bracket the - whole aggregate. - - - - - - Translations - - Translation is considered a kind of modification, so you - may distribute translations of the Document under the terms of - section . Replacing - with translations - requires special permission from their copyright holders, but - you may include translations of some or all in addition to the original - versions of these . You - may include a translation of this License, and all the license - notices in the Document, and any Warranty Disclaimers, - provided that you also include the original English version of - this License and the original versions of those notices and - disclaimers. In case of a disagreement between the - translation and the original version of this License or a - notice or disclaimer, the original version will - prevail. - - If a section in the Document is Entitled - Acknowledgements, Dedications, - or History, the requirement (section ) to Preserve its Title - (section ) will - typically require changing the actual title. - - - - - - Termination - - You may not copy, modify, sublicense, or distribute the - Document except as expressly provided for under this License. - Any other attempt to copy, modify, sublicense or distribute - the Document is void, and will automatically terminate your - rights under this License. However, parties who have received - copies, or rights, from you under this License will not have - their licenses terminated so long as such parties remain in - full compliance. - - - - - - Future Revisions of this License - - The Free Software Foundation may publish new, revised - versions of the GNU Free Documentation License from time to - time. Such new versions will be similar in spirit to the - present version, but may differ in detail to address new - problems or concerns. See . - - Each version of the License is given a distinguishing - version number. If the Document specifies that a particular - numbered version of this License or any later - version applies to it, you have the option of - following the terms and conditions either of that specified - version or of any later version that has been published (not - as a draft) by the Free Software Foundation. If the Document - does not specify a version number of this License, you may - choose any version ever published (not as a draft) by the Free - Software Foundation. - - - - - - How to use this License for your documents - - To use this License in a document you have written, - include a copy of the License in the document and put the - following copyright and license notices just after the title - page: - - -Copyright (C) YEAR YOUR NAME. - -Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, -Version 1.2 or any later version published by the Free Software -Foundation; with no Invariant Sections, no Front-Cover Texts, and -no Back-Cover Texts. A copy of the license is included in the -section entitled GNU Free Documentation License. - - - If you have , - Front-Cover Texts and Back-Cover Texts, replace the - with...Texts. line with this: - - -with the Invariant Sections being LIST THEIR TITLES, with the -Front-Cover Texts being LIST, and with the Back-Cover Texts being -LIST. - - - If you have - without , or some other - combination of the three, merge those two alternatives to suit - the situation. - - If your document contains nontrivial examples of program - code, we recommend releasing these examples in parallel under - your choice of free software license, such as the GNU General - Public License, to permit their use in free software. - - - - diff --git a/Documentation/Tcpi-ug/Preface.docbook b/Documentation/Tcpi-ug/Preface.docbook deleted file mode 100755 index 3291a2b..0000000 --- a/Documentation/Tcpi-ug/Preface.docbook +++ /dev/null @@ -1,69 +0,0 @@ - - - Preface - - - Welcome to &TCPIUG;. - - - - This book describes how you can configure &TCD; to use the - telephone network as physical medium for data transmission - using computers, so you can create your own collaborative - networks to share information with your friends in freedom. - - - - To implement the configuration described in this book, you - need two or more computers connected to the telephone network - of your country by mean of modem devices. Optionally, you - could use Ethernet devices (e.g., switches) to create local - area networks (LANs) on both ends of each connection - established over the telephone network for sharing information - between them. For example, consider an infrastructure where - you have one LAN for each province in your country and then, - each of these LANs is connected one another to share - information between them using the country's telephone - network. This infrastructure would be as expensive as - telephone calls and consume of electrical power required by - computers and communication devices would be. - - - - To make the information of this book managable, it has been - organized in the following parts: - - - - - - describes how to configure - server and client computers to transfer IP packages through - the telephone network. This is the first step you need to - setup in order to use the internet services described in . - - - - - describes how to configure server - and client computers to exchange information using internet - services over the telephone network. Once you complete this - part of the book, your collaborative network should be ready - for production. - - - - - describes the lincense documents - mentioned in this book so you can know what you can and cannot - do with the information provided in this book. - - - - - &preface-overview; - &preface-docconvs; - &preface-feedback; - - diff --git a/Documentation/Tcpi-ug/Preface.ent b/Documentation/Tcpi-ug/Preface.ent deleted file mode 100755 index 263be1d..0000000 --- a/Documentation/Tcpi-ug/Preface.ent +++ /dev/null @@ -1,4 +0,0 @@ - - - - diff --git a/Documentation/Tcpi-ug/Preface/docconvs.docbook b/Documentation/Tcpi-ug/Preface/docconvs.docbook deleted file mode 100755 index 1c2da7b..0000000 --- a/Documentation/Tcpi-ug/Preface/docconvs.docbook +++ /dev/null @@ -1,68 +0,0 @@ -
- - Document Convenctions - - - In this manual, certain words are represented in different - fonts, typefaces, sizes, and weights. This highlighting is - systematic; different words are represented in the same style - to indicate their inclusion in a specific category. The types - of words that are represented this way include the - following: - - - - - - ... - - - - - - Additionally, we use several different strategies to draw your - attention to certain pieces of information. In order of - urgency, these items are marked as a note, tip, important, - caution, or warning. For example: - - - - - Remember that Linux is case sensitive. In other words, a - rose is not a ROSE is not a rOsE. - - - - - - The directory /usr/share/doc/ contains - additional documentation for packages installed on your - system. - - - - - - If you modify the DHCP configuration file, the changes do - not take effect until you restart the DHCP daemon. - - - - - - Do not perform routine tasks as root — use a regular - user account unless you need to use the root account for - system administration tasks. - - - - - - Be careful to remove only the necessary partitions. - Removing other partitions could result in data loss or a - corrupted system environment. - - - -
diff --git a/Documentation/Tcpi-ug/Preface/feedback.docbook b/Documentation/Tcpi-ug/Preface/feedback.docbook deleted file mode 100755 index c532212..0000000 --- a/Documentation/Tcpi-ug/Preface/feedback.docbook +++ /dev/null @@ -1,14 +0,0 @@ -
- - Send In Your Feedback - - - If you find a bug in this manual, we would like to hear about - it. To report bugs related to this manual, send an e-mail to - the docs@projects.centos.org mailing list - specifying the manual name, the section where you found the - bug, why you considered it a bug and anything that help us to - identify where the problem is exactly. - - -
diff --git a/Documentation/Tcpi-ug/Preface/overview.docbook b/Documentation/Tcpi-ug/Preface/overview.docbook deleted file mode 100755 index 027aef8..0000000 --- a/Documentation/Tcpi-ug/Preface/overview.docbook +++ /dev/null @@ -1,399 +0,0 @@ -
- - Overview - - - Since 1999, I've been working for cuban State as Webmaster and - lately as system administrator. On April 2009, I decided to - stop working for cuban State due the increasing feeling of - repression I experimented with the restrictions impossed by - cuban State in the information area when I tried to find an - alternative way to express myself different from what such - restrictions impossed. This environment made me find that the - cuban political system lacks of such independent alternatives - for cubans to use. I don't pretend to use this book to detail - the political system I live on, but I do want to say that the - more I got involved with the cuban political system the more - distance I felt between the most pure of myself and the - actions the system expected from me to do as system - administrator, and what could be an alternative way for cubans - inside the island that, like me, feel the same need of - independent expression. - - - - Everything in the human life is directly related to - information. Our actions are based on the information we have. - The information is the base of education and evolution. It is - the only way we can know how to do the right thing for us and - others. I beleive that, in order to provide a good education, - the universal information must be accessable to everyone in a - transparent way, based on facts and without any manipulation - (i.e., in way others can reproduce or verify what the - information refers to). That kind of information is good - information to based our lives on. However, there are also bad - information that we need to differentiate from good - information using our own conscience, not that one from - others. I like the idea of structuring my life over pragmatic - fatcs that I can verify together with a deep faith on what I - am that help me to persist along the duty. The pragmatic fatcs - provides the steps of the stair of my life and the faith, the - force my body needs to climb up the stair. - - - - The years I worked for cuban State coincided with those years - I began to realized myself about the steps of my stair and the - faith on my movements. Lot of contradictions have been - appearing in front of me since then, but a magical thing - inside me (conscience) always tell me not to abandon the must - pure of my self and keep going with this travel I'm still - walking on; even when moving up one step in the stair feels - like rasping the skin of my body against a rough wall. I know - it will heal, but it hurts when happens. The only way to - support the pain is to have faith on the rightness of your - actions. That's the price of don't loosing oneself when - walking over pragmatic facts in a confussed and unarmed - society. That's the price of showing out that truth is inside - us, not outside us. It is the way of showing the truth is in - the one's faith, no matter what it be, but in feeling it - somehow, specially when it comes from understanding what we - are and the immense gift it is to have conscience of our - univeral existence as part of that unknown nature we, as - living humans, cannot ever have conscience of. - - - - I've experimented faith in free software and the philosophy - behind it by mean of &TCP;, but no possible way to manifest it - independently from cuban State. The cuban State controls all - the communication media and very few possibilities are - available for cubans to build up independent collaborative - networks using computers inside the island for sharing - information apart from cuban State restrictions and - conditions. One of these possibilities is the telepohne - network the cuban State provides, which has national scope. - Generally, cubans use the telephone network to talk among - themselves, but it is also possible to use this network to - transmit information that cannot be communicated using the - regular method of human talking. It is possible to attach - computers to the telephone network the cuban State provides to - transmit whatever information a computer can produce (e.g., - images, documents, programs, etc.) from one location in the - island to another and encrypting the information traveling - along the wire to garantee its privacy (e.g., the source - computer protects the information in a way that only the - target computer is able to unprotect. If the information is - intercepted by a computer located in the transmission middle, - it would be useless for that computer since only the target - can use it once it has been unprotected). We'll see more about - this later. - - - - In these last years (2009-2011), the cuban State has shown - signs to start using free software with the idea of - reaching a technological independency which is - quiet contradictory to me. What independency we are talking - about here? Independency for whom, and from whom? Based on - the meaning of the word, independency is the lack of any - dependency, so the only way I see the cuban State will be able - to reach such technological independency would be creating and - maintaining an entire technological infrastructure (e.g., - computers, communication devices, operating systems written - from scratch, etc.) inside its political boundaries without - any intervention from the outside world. Otherwise, the cuban - State would be inevitably dependent from someone else that can - differ at some point of the production string and that would - be something unacceptable, because it would compromise the - idea the cuban State had about independency in first place - (i.e., no dependency). - - - - If the vision described above about what the cuban State tries - to mean by reaching a technological - independency sounds appropriate to you, the cuban - State is misunderstanding or trying to distort the real - meaning of free software and the philosophy behind it. The - free software is built from people and dedicated to people who - might be in need of it, with the hope of being useful and - garantee the freedom of computer users paying or not a - monetary price for it. The cuban State, on the other hand, - introduces free software at convenience because there are - entire operating systems free of charge which the cuban State - can study and change as needed, not in the sense of - guaranteeing the freedom it provides to people, but as a way - to control what software does cubans use and the way they do - that. It is another impositions cubans should comply with, no - matter what they think about it. - - When I was working in the health sector of cuban State - (2003-2007), my superior told me once that I couldn't keep - using &TCD; on servers any longer, because system - administrators at central level stopped using Red Hat - related distribution and started to use Debian. I don't - want to enter in a debate why one or another distribution, - that's not the point. But I do want to mention that this - decision shouldn't be taken from one day to another - without any consideration about all the time people spent - studying (and working for) one specific GNU/Linux - distribution. My opinion was rejected and they kept - themselves showing me that it was a matter of politics one - should follow, no matter what one thought about it. I - couldn't accept that and fired up myself from that - institution. I cannot change from one operating system to - another just because someone else wants to. - - Some people might think that there is no problem - in that because it is free software anyway. Yes, that's true, - but think that again: Shouldn't you have the freedom to decide - what free software to use, and also what community you join - to? No one must impose you anything about which social - community you participate in, that is a decision you need to - take by yourself, not from someone else. - - - - The free software isn't free because of its name, but the - legal, social, economical and political environment it is used - in. If licenses used by software producers to release their - works (either freely or privatively) aren't protected somehow - in that environment, software producers wont be motivated to - create any software at all (either free or privative). - Consider what is happening in Cuba with Windows, the operating - system produced by Microsoft corporation: when someone install - the Windows operating system, one of the first screens in the - installation process is the License Agreement under which - Microsoft corporation releases its product. This agreement - relys on the copyright concept, a legal instrument that was - initially created to motivate authors to create more. - Likewise, the Free Software Foundation relys on the copyright - concept to distribute free software. The fact the License - Agreement of Windows operating system isn't complied in Cuba - (e.g., no cuban pays Microsoft corporation for using its - operating system) as Microsoft imposses in its License - Agreement, is a clear sign of international copyright - violation, no matter if Cuba can or cannot establish - commercial treatments with Microsoft corporation because of - the Embargo impossed by United States of America against Cuba. - It is an ethical matter cubans need to comply with in order to - help reducing the tension against both nations by showing - respect for their creators and the way they expect their - products to be distributed world-wide. Personally, I don't - use Windows operating system since 2003 when I discovered the - free software philosophy, - - I want to thank my teacher Jesús Aneiros Sosa for - intructing me in the free software philosophy and for - leading the Linux User Group (LUG) of Cienfuegos during so - many years and transmiting the feeling of freedom. - - but I am worried about the legal issues cubans - might face when developing free software. For example, will - the cuban State treat the free software license in the same - way it treats privative software licenses? If the cuban State - has no legal regulation to protect the international copyright - concept (i.e., letting authors to publish their works the way - they want to and provide the legal protections needed to - deprive people from using those creations in a way different - from that one conceived by their authors), it would be very - difficult to truly motivate people to create free software (or - anything else) in Cuba. The main problem here is that you can - write free software, but what instrument you have to protect - it from others to make your code privative and forbbid you, - this way, from using further improvements over the code you - wrote yourself. - - - - It is important to remember that the free software movement - was initiated by Richard Stallman in the United States of - America, based on the legal system of that country, - specifically in the copyright concept being in force. In order - to use free software, in the sense of freedom thought by - Richard Stallman, it is required that a similar underlaying - legal system in matters of copyright concepts be present in - Cuba, or an agreement be complied among all countries (e.g., - The Berna Treatment) for this matters. I've heard that Cuba - signed The Berna Treatment, however what is happening with - Windows operating system gives the impression that cuban State - is not complying with the agreement it signed on there. For - cuban society to understand what free software and the - philosophy behind it really are, it is required to force a - strong concept of copyright in the cuban legislation, even - when some authors might want to deny the cuban State from - using the work they produce or use it under conditions the - cuban State doesn't agree with. It is required to give that - legal power to cuban authors, the people who create. I wonder - if the cuban State is ready for that; and if not, why? I - really would like to know in order to find a solution. - - - - Free software communities are the place where free software is - produced. There are international, national and local - communities grouped under the free software philosophy. In - Cuba, because all the communication media are controlled by - the cuban State and conceived to its own benefit, it is - difficult for anyone differing from cuban State to have access - to communication media where the free software communities - live in. I strongly beleive that for the free software - philosophy to touch the heart of cubans, all free software - communities must be accessable to cubans. However, while the - cuban State keeps itself being inbetween, controlling how the - cubans can or cannot integrate any specific way of living, - there will not be free software in Cuba, nor any freedom for - cubans to make use of. - - - - Another frequent topic mentioned by the cuban State - information media is the migration from privative software to - free software. The migration from privative software to free - software must be initiated from people's deepest comprehension - of what they are doing, not from impositions of another - inquestionable order everybody needs to comply with. So, - cubans need to feel what freedom is and express it in order to - perceive a deep impact of free software in cuban society. We - cannot pretend that cubans will use free software based on a - lie or a distorted idea about the freedom it provides, an idea - like that wont last much before it falls itself into pieces. - People need a way of identifying themselves apart from any - social or political system in order for them to be able of - decide whether or not to be part of one. - - - - It is impossible to truly defend freedom if one doesn't have - felt what it is. The cuban State never talks (at least - officially) about introducing free software for freeing the - cuban society from privative software. In fact, if you compare - the privative software and the way cuban State restricts the - information management, - - See resolution 129 emitted by cuban Ministerium of - Informatics and Telecommunications (MIT). - - you may find them very similar. The resolutions - emitted by cuban State are specific to statal instituions that - use computers to share information. I don't know of any legal - estipulation about using information and communication - technologies by nautural people outside the statal sector and, - spite of it, I've heard of cubans that has been called by the - cuban State security departament to explain why they built a - computer network in the neighbourhood to share information - (isn't that obvious) and finally they were intimidated to stop - doing so. There isn't a legal instrument in either direction - that one can use as pattern to act legally. The cuban State - has all the legal power to condemn you as cuban, but you are - completly unarmed against it. If the cuban State really wants - to be democratic, it needs to give to cubans the arms they - need to fight against it without fear of being defeated. - Indeed, there would be no defeating at all, but evolution into - new political states based on cubans needs. It is the majority - of cubans who should define how The Cuban Tree evolves, not a - few minority that opresses the unarmed masses. - - - - Internet access is another obscured issue inside Cuba. Around - 2008, Cuba and Venezuela signed up an agreement to connect - both nation with a trasatlantic fiber optic cable for high - speed Internet access. In 2011 the cuban State announced the - arrival of such cable to cuban national territory, but nothing - more has been mentioned since then. There is a terrible - silence about it that make people woundering what happend with - that millionary invertion. Some people ask themselves why to - spend so much money on that if cubans cannot make use of it - and others prefer to think that the entire project failed. It - is difficult to know what happend exactly because, again, - there isn't any alternative way of communication but those - provided and controlled by the cuban State. The fact is that, - at present time (2011), there isn't a legal way for cubans to - contract an Internet service at home, nor even a viable way to - acquire a fixed telephone line at home either. - - I know of people that have requested a fixed telephone - line for their home and more than three years have passed - and they haven't the line yet. It is also known by - everyone that others don't even have to make any request - to have a fixed telephone line at home. - However, the same isn't true for extrangers - coming from other countries who are visiting Cuba or staying - inhere as residents. The cuban State permits these persons to - access Internet paying a service in offices called Telepuntos - or from home using different fees. Some cubans cannot - understand this, nor the logic behind it either. Have cubans - to change their nationality in order to have Internt access - from their homes in Cuba? - - - - In Cuba there is only one telecommunication corporation named - ETECSA. This organization gives the impresion of being very - tied to cuban State and controlling everything related to - telephone networks and dedicated links for data transmistion - in the island. - - I heard of a case where someone tried to establish an - independent connection from Cuba to another country using - the air as phisical medium for data trasmission and that - person is pressently suffering years in a cuban prison - because the cuban State considered such action as illegal - actions. At this moment I haven't more information about - this case. It is very difficult to be accurate about such - things without an alternative information medium, apart - from those under cuban State control. - - Based on the fact that cuban telephone network is - the only communication medium most cubans have direct access - to, my attention is centered on it as phisical medium for - exchanging information using computers. It is important to - remark that, when using the telephone network as medium for - data transmission, there are limitations in the number of - simultaneous connections it is possible to phisically - establish between computers, it could be difficult to obtain - the Modem devices inside the island, and it could be too much - expencive to make international calls in order to exchange - information with public services available on different - networks outside Cuba's political boundaries. Besides all - these restrictions, the cuban telephone network has a national - scope that can be efficiently used by cubans inside the island - to share information using computers at a monetary cost of - national telephone calls and the electrical power consumed by - computers and communication devices (e.g., modems and - switches). - - - - I beleive that most of problems the cubans presently have are - caused by a lack of information we need to face in order to - understand what we are and where we are going to, in the sense - of an interdependent human being's society. To face the - information problem, it is needed to make available - independent ways for cubans to express themselves in freedom - and provide, this way, the base arguments needed to edificate - the solutions of those problems we face today. That's my goal - with this work: educating myself in the compromise of - providing an independent space for cubans to discuss and - coordinate how to create collaborative networks using the - cuban telephone network - - Considering that I and most cubans haven't access to - dedicated links or real IP addresses for data transmission - at present time. - - as phisical medium to transmit information using - computers in freedom. - - - - The motivation for this work was taken from the free software - philosophy exposed by Richard Stallman in his book - Free Sofware Free Society and my - personal experience from 2003 to 2009 as active member inside - &TCP; international community. - - -
diff --git a/Documentation/Tcpi-ug/Services.docbook b/Documentation/Tcpi-ug/Services.docbook deleted file mode 100644 index 014d921..0000000 --- a/Documentation/Tcpi-ug/Services.docbook +++ /dev/null @@ -1,10 +0,0 @@ - - - Services - - &services-dns; - &services-mail; - &services-http; - &services-ldap; - - diff --git a/Documentation/Tcpi-ug/Services.ent b/Documentation/Tcpi-ug/Services.ent deleted file mode 100644 index b76c2c0..0000000 --- a/Documentation/Tcpi-ug/Services.ent +++ /dev/null @@ -1,13 +0,0 @@ - - - - - - - - - - - - - diff --git a/Documentation/Tcpi-ug/Services/Dns.docbook b/Documentation/Tcpi-ug/Services/Dns.docbook deleted file mode 100644 index 78dd877..0000000 --- a/Documentation/Tcpi-ug/Services/Dns.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - Domain Name Service - - - ... - - - &services-dns-overview; - - diff --git a/Documentation/Tcpi-ug/Services/Dns/overview.docbook b/Documentation/Tcpi-ug/Services/Dns/overview.docbook deleted file mode 100644 index 2f57c37..0000000 --- a/Documentation/Tcpi-ug/Services/Dns/overview.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Overview - - - ... - - - diff --git a/Documentation/Tcpi-ug/Services/Http.docbook b/Documentation/Tcpi-ug/Services/Http.docbook deleted file mode 100644 index ce85a8b..0000000 --- a/Documentation/Tcpi-ug/Services/Http.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - Web Service - - - ... - - - &services-http-overview; - - diff --git a/Documentation/Tcpi-ug/Services/Http/overview.docbook b/Documentation/Tcpi-ug/Services/Http/overview.docbook deleted file mode 100644 index 00335b6..0000000 --- a/Documentation/Tcpi-ug/Services/Http/overview.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Overview - - - ... - - - diff --git a/Documentation/Tcpi-ug/Services/Ldap.docbook b/Documentation/Tcpi-ug/Services/Ldap.docbook deleted file mode 100644 index eba7579..0000000 --- a/Documentation/Tcpi-ug/Services/Ldap.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - Directory Service - - - ... - - - &services-ldap-overview; - - diff --git a/Documentation/Tcpi-ug/Services/Ldap/overview.docbook b/Documentation/Tcpi-ug/Services/Ldap/overview.docbook deleted file mode 100644 index f2af74e..0000000 --- a/Documentation/Tcpi-ug/Services/Ldap/overview.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Overview - - - ... - - - diff --git a/Documentation/Tcpi-ug/Services/Mail.docbook b/Documentation/Tcpi-ug/Services/Mail.docbook deleted file mode 100644 index 04a47d2..0000000 --- a/Documentation/Tcpi-ug/Services/Mail.docbook +++ /dev/null @@ -1,10 +0,0 @@ - - - Mail Service - - &services-mail-overview; - &services-mail-mta; - &services-mail-mda; - &services-mail-mua; - - diff --git a/Documentation/Tcpi-ug/Services/Mail/mda.docbook b/Documentation/Tcpi-ug/Services/Mail/mda.docbook deleted file mode 100644 index 4b8971f..0000000 --- a/Documentation/Tcpi-ug/Services/Mail/mda.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Mail Delivery Agent - - - ... - - - diff --git a/Documentation/Tcpi-ug/Services/Mail/mta.docbook b/Documentation/Tcpi-ug/Services/Mail/mta.docbook deleted file mode 100644 index eeabea3..0000000 --- a/Documentation/Tcpi-ug/Services/Mail/mta.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Mail Transfer Agent - - - ... - - - diff --git a/Documentation/Tcpi-ug/Services/Mail/mua.docbook b/Documentation/Tcpi-ug/Services/Mail/mua.docbook deleted file mode 100644 index 319d167..0000000 --- a/Documentation/Tcpi-ug/Services/Mail/mua.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Mail User Agent - - - ... - - - diff --git a/Documentation/Tcpi-ug/Services/Mail/overview.docbook b/Documentation/Tcpi-ug/Services/Mail/overview.docbook deleted file mode 100644 index b9693a6..0000000 --- a/Documentation/Tcpi-ug/Services/Mail/overview.docbook +++ /dev/null @@ -1,58 +0,0 @@ - - - Overview - - - The mail service provides the software required to let you - send/receive mail messages to/from others. The mail service is - supported by three basic components: the Mail Transfer Agent - (MTA), the Mail Delivery Agent (MDA) and the Mail User Agent - (MUA). The MTA is the program your mail client sends mail - messages to. The MDA, on the other hand, is the program your - mail client reads mail message from (i.e., this is the program - that lets you access your mailbox). The saslauthd daemon is - used by the MDA to authenticate user's credentials (e.g., the - information required to grant access to an specific mailbox) - and in some cases by the MTA to authenticate users before - sending mail to it. The MTA will listen on all network - interfaces it is attached to and will receive mail sent to - specific users inside specific domain names. - - - - Inside &TCD; there is support for different MTAs (e.g., - Sendmail, Postfix and Exim). By default, the - Sendmail program is used as mail - transfer agent, however, we want to use Postfix for our - configuration. This way, to use Postfix as default mail - transfer agent and not Sendmail, it is required to use the - alternatives command. This command will - present you a menu to chose between available mail transfer - agents installed in the system, so you can choose Posfix as - default option. Now that you've made Postfix the default mail - transfer agent, you can saftly remove the sendmail package to - avoid unused software to remain inside the computer. - - - - Inside &TCD; there is support for different MDA (e.g., Cyrus - IMPA and Dovecot). By default, the Dovecot program is used as - mail delivery agent (which doesn't require any intermediate - daemon for athentication), however, we want to use Cyrus IMAP - for our configuration (which does require an intermediate - daemon called saslauthd for authentication). - - - - Inside &TCD; there is support for different MUA (e.g., - Evolution, Thunderbird and Mutt). By default, the Evolution - program is used and we stay with it :). - - - - In this chapter we describe how to configure each one of these - components to let you send/receive e-mails to/from your - friends. - - - diff --git a/Documentation/Tcpi-ug/Services/Mail/saslauthd.docbook b/Documentation/Tcpi-ug/Services/Mail/saslauthd.docbook deleted file mode 100644 index 4211a1b..0000000 --- a/Documentation/Tcpi-ug/Services/Mail/saslauthd.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Sasl Authentication Server - - - ... - - - diff --git a/Documentation/Tcpi-ug/tcpi-ug.docbook b/Documentation/Tcpi-ug/tcpi-ug.docbook deleted file mode 100755 index a677227..0000000 --- a/Documentation/Tcpi-ug/tcpi-ug.docbook +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - -%Commons.ent; -%Preface.ent; -%Connectivity.ent; -%Services.ent; -%Licenses.ent; -]> - - - - - The CentOS Project Infrastructure - User's Guide - - - - Alain - Reguera Delgado - - - - - 2011 - &TCP;. All rights reserved. - - - - - Permission is granted to copy, distribute and/or modify - this document under the terms of the GNU Free - Documentation License, Version 1.2 or any later version - published by the Free Software Foundation; with no - Invariant Sections, no Front-Cover Texts, and no - Back-Cover Texts. A copy of the license is included in - . - - - - - - 1.0 - Today - - Alain - Reguera Delgado - - - - Under development. - - - - - - - - - &preface; - - - &connectivity; - &services; - - - &licenses; - -