CVS backup, distribution, simplify your configuration file
Level: primary
Teodor Zlatanov
(Tzz@bu.edu) programmer, Gold Software Systems 2004 July
General developers are used to position, learn, and debug configuration files, which is longer than you expect. However, using a tool that you might use every day: CVS tree, you can save those time - and reduce the burden on energy and setbacks. Use these techniques to back up, release the Linux® configuration file that maxims your headache, and make it portable.
When using Linux and your computer, the usage of the configuration file is usually confusing. Although some have been proposed, there is no standard. For example, Samba and Rsync use the INI-style configuration; Passwd is used in the format separated by colon decades ago, and does not allow the colon to appear in any domain; sudo comes with some Visudo programs, let people not in the sudoers file Enter the wrong message; Emacs uses LISP as a configuration file. and also...
Now, I no longer complain the diversity of the configuration file. I understand the historical reasons and practical reasons for Configuration Tower of Babel. For example, if you change the format of the Samba configuration, you will have a hassle. Another example, Emacs's internal language is LISP, which is a powerful high-level language, so use any other thing as an Eamcs configuration file is ridiculous.
No, I have to point out that this diversity is impact on Linux users: Linux users have a large part of the computer time to learn, write and debug configuration files. In this way, it is necessary to have a system that these profiles (1) are automatic backups in this system, and (2) is automatically released, (3) can be used in a variety of styles of Unix and multiple Linux release versions. This article explains how to achieve the first two goals and guide you to reach the third goal.
Plan We will use CVS to control the configuration file. Any other version of the system can be used freely. Subversion is being quickly popular. FSF has GNU TLA (GNU Arch) and is another excellent version of the system. All those and many other systems, including non-free Rational® ClearCase?, Etc., you will provide the features you need.
In my configuration mode, each profile is in a separate directory or its subdirectories. The configuration file is uniquely named, the directory is indicated by the machine or platform, not the location. In this way, the file name is uniquely mapped to a location in the file system. For example, Passwd will always be used for / etc / passwd, while CSHRC will be used by the user TZZ for /Home / TZZ/.cshrc.
For some programs I use every day, I will show how to manage multiple platforms with the help of my configuration system, so that they call themselves.
All examples I show have used c shell to set the environment variable. Modify them to use GNU Bash or other shells should not be particularly difficult.
Installing Settings CVS You may have installed CVS on your machine. If not, then get it (see the reference part) and install it. If you are using another version of the system, then try to set some of the contents that I am displayed below.
First, you need to create a CVS warehouse. I will assume that you can use OpenSSH or PServer CVS Access (PServer is a communication protocol used by CVS; see Resources to get more information) Access a machine that can be used as a CVS server. Then, you need to create a module named config, I will use it to manage the sample configuration file. Finally, you need to arrange a way to use your CVS warehouse remotely, you can pass OpenSSH, PServer or any feasible way. The last point is extremely dependent on your specific system management skills, paranoid levels, and the environment, so I just pointed out some information for you in the reference. In the rest of this article, I will assume that you have configured non-interactive (SSH-Agent) login through OpenSSH. Listing 1. Create a CVS warehouse on a machine
# Assume that / cvsroot is your repository's home> setenv CVSROOT / cvsroot # this will use $ CVSROOT if no -d option is specified> cvs init # check that it worked> ls / cvsroot # you should see one directory called CVSROOT CVSROOT
Since the warehouse has been established, you can use it remotely (you can also perform the following steps on the CVS server - just let CVSROOT are still shown in Listing 1).
Listing 2. Remotely add config modules to CVS
# User tzz, machine home.com, directory / cvsroot is the CVSROOT> setenv CVSROOT tzz@home.com: / cvsroot # use SSH as the transport> setenv CVS_RSH ssh # use a temporary directory for the module creation> cd / tmp> Mkdir config> cd config # tzz is the "vendor name" and "and" and initial is the "release tag", They can # be anything; the -m flag tells cvs not to ask US for a message # if this fails Due To Ssh Problems, see the Resources> cvs import -m '' config tzz initial No conflicts created by this import # now let's do a test checkout> cd ~> rm -rf / tmp / config> cvs co config cvs checkout: Updating config # check everything is Correct> LS Config CVS
Now you have already checked a copy of the Config CVS module under the home directory; we will use this as a starting point. In this article, I will use my username TZZ and home / home / tzz, but of course, you should properly use your own username and directory.
Let us create a separate file. CVS Options file CVSRC looks more appropriate because I will use CVS more.
Listing 3. Create and add CVSRC files
> CD ~ / Config> Echo "CVS -Z3"> CVSRC> Echo "Update -p -d" >> CVSRC> CVS Add Cvsrc # you real Don't Need Log Messages Here> CVS commit -m ''> ln - S ~ / config / cvsrc ~ / .cvsrc Since then, all of your CVS options will be in ~ / config / cvsrc, you will update that file instead of ~ / .cvsrc. The specific option you add tells CVS to reload the directory when the directory does not exist, and delete the empty directory. This is usually desirable. For other machines you want to set this setting, you need to check the config module again and re-link.
Listing 4. Check the Config module and construct a CVSRC link
> cd ~ # set the folloading two for remote access> setENV cvsroot ...> STENV CVS_RSH ... # Now Check Out "config" - this will get all the files> cd ~ / config> ln - S ~ / config / cvsrc ~ / .cvsrc
In addition to the symbolic link you just created, you may know Linux also support hard links. They do not apply to this mode for the limitations of hard links. For example, suppose you create a hard link to ~ / .cvsrc to ~ / config / cvsrc, and later you move ~ / config / CVSRC (this happens under many conditions). ~ / .cvsrc file will still hold the original old content of ~ / config / cvsrc. Now you have again instead ~ / config / cvsrc. However, ~ / .cvsrc file will not be updated. This is why the symbolic link is better in this case.
Let us assume that you modify CVSRC to add more options:
Listing 5. Modify and submit CVSRC
> CD ~ / Config> Echo "Checkout -P"> CVSRC> CVS commit -m ''
Now, in order to update the ~ / .cvsrc on each machine you use, just do the following work:
Listing 6: Modify and submit CVSRC
> CD ~ / Config> CVS Update
this is very simple. More satisfied is that the CVS update shown above will update each file in the ~ / config, so using a command you can immediately enable the files that remain in this CVS mode be the latest. This is the essence of the configuration mode shown here; others are just auxiliary role.
Note that once you check a module, there will be a directory called "CVS". There are enough information about CVS in the CVS directory, you do not need to specify a cvsroot variable you can do update, submit, and other CVS operations.
Automatic update and submission To automatically update and submit, I have written a particularly simple Perl program, maintain.pl. The longest part of the program is the help text, so you can imagine it is not complex code. Anyway, I will describe it in detail, but don't forget, if needed, the shell script can complete the same task.
MAINTAIN.PL unique things are constructed symbolic links. Since the symbolic link can only be constructed once, and in some systems you don't want a large-scale construction link, the complexity of the task is clear relative to the manual completion of this task. I know because I have written symbolic link code, and later deleted it. I have to write and maintain another configuration file mapped to many operating systems. There will be a lot of abnormalities; for example, the Linux and Solaris systems I use have different settings in nature. There are too many things to consider, and I found that the handmade link is simpler. Of course, your experience may be different - I encourage you to try to find a way that best suits your own environment.
The beginning of the maintain.pl script is the definition of the practice, including the configuration option, the loading of the command line parameters, and the help text.
Listing 7. MAINTAIN.PL script preparation work
#! / usr / local / bin / perl -w # {{{modules and constants use strict; use appconfig qw /: expand: argcount /; #}}} $ | = 1; # autoflush the output my $ config = appconfig -> New (); $ config-> define ('help' => {argcount => argcount_none, default => 0, alias => 'h'}, # Update level, higher checks out more 'level' => { Argcount => argcount_one, default => 5}, 'conffile' => {argcount => argcount_one, alias => 'f', default => glob ("~ / config / maintain.conf")}, 'cvs' = > {aRGCOUNT => ARGCOUNT_ONE, DEFAULT => 'cvs'}, 'CVS_RSH' => {aRGCOUNT => ARGCOUNT_ONE, DEFAULT => 'ssh'}, 'UPDATE' => {aRGCOUNT => ARGCOUNT_HASH}, 'DRYRUN' = > {Argcount => argcount_none, default => 0, alias => 'n'}, 'commit' => {argcount => argcount_none, default => 0, alias => 'c'}, $ config-> Args (); if (-r $ config-> conffile () && -f $ config-> conffile ()) {$ config-> file ($ config-> conffile ());} else {print "the file" . $ config-> conffile (). "WAS Not Readable, Skipping / N";}} ($ config-> help ()) {print << Eohippus; $ 0 run $ 0 help @ {[$ config-> conffile ()]} and update everything in it at level @ {[$ config-> level ()]} or less. Switches: -level (default @ {[$ Config-> level ()]}: Check out everything at this level or less -help (-h): print this help -conffile (-f, default @ {[$ config-> conffile ()]}: loading This Configuration -CVS (Default @
{[$ config-> cvs ()]}: where to find the cvs program -cvs_rsh (default @ {[$ config-> cvs_rsh ()]}: sets the cvrsh environment variable -update: populate the Update Hash in The Configuration File or Like this: -update / home / tzz / see below for explanation -commit (-c): don't just update, also do a commit of anything change -dryrun (-n): don't run anything , just test directories and levels Configuration file: Very simple AppConfig format; everything in the switches can be specified in the configuration file as well, eg COMMIT = 1 UPDATE / home / tzz / config = 0 The example above says that / home / tzz / Config Will Be Updated At Level 0 or Higher, And That You Always Want To Commit When You Run This Program. ENVPUS EXIT 0;} $ env {cvs_rsh} = $ config-> cvs_rsh (); if you are not familiar with Appconfig module, Then you should look at the reference part to get practical information about management configuration.
I have written a glob () call to determine the default Confding because the user's home directory may be in any location. If conffile contains illegal data, AppConfig will automatically stop the entire program (this can be modified to only a warning). The script doesn't even need to configure the file.
After printing the help text, I set CVS_RSH to the appropriate value (default is SSH). This is to let users do not have to set environment variables in other ways, which is especially convenient for users who put maintain.pl in crontab.
After completing the preparation, let us see the core part of the script:
Listing 8: Main cycle of maintain.pl
Foreach MY $ SPOT (Keys% {$ config-> Update ()}) {MY $ level = 0 $ config-> Update () -> {$ spot}; Next if $ level> $ config-> level () PRINT "SPOT $ SPOT, Level $ Level / N"; ChDIR $ Spot; IF ($ config-> Dryrun ()) {Print "Not Updating Due to Dryrun / N";} else {system ($ config-> cvs (). "-q Update");} f ($ config-> commit ()) {= ($ config-> Dryrun ()) {print "not committing due to dryrun / n";} else {system ($ CONFIG-> CVS (). "Commit -m '')}}}
This is a simple loop. I traverse each Spot (these actually a directory), if the level of Spot is lower than or equal to the level configuration variable (default is 5), execute CVS Update. Also, if a commit tag is set, I will execute cvs commit -m '', which will submit all modifications and give an empty log message. In fact, if there is no Dryrun logo, this loop will only have a few lectures. I use system () in a string format instead of multi-parameter format. You can use the second way - View Perldoc -f System to get details about this function call usage.
In addition, I didn't check the result of system () calls because there is no need. When a CVS update or submission issues occur, Maintain.pl cannot (or should not) anything, because these are important configuration files, we don't want to update blindly.
The configuration file itself is simple:
Listing 9. Maintain.conf
# t Number is the update level update / home / tzz / emacs = 0 Update / Home / TZZ / config = 0 Update / home / tzz / articles = 1 Update / Home / Tzz / GNUS / GNUS = 1
Don't forget, here you can set any appconfig variables, so for example, you can override the default Level or CVS_RSH. I update my Emacs, Config, Articles, and Gnus directories through maintain.pl, but their update levels are different to reflect the frequency of my update (I update the level of 0 every day twice, level 1).
Organizing your new configuration This section will cover my personal experience in the configuration system you have established so far. Please use these thoughts freely, but don't forget that my personal settings are not for everyone.
I save the directory based on the machine and operating system and the specific extent they need. For example, I saved Linux unique configuration under "Linux", because my home machine "Heechee" has a special keyboard, so I have a Heechee directory for Heechee unique configuration.
However, the overlay rule should be that if you can describe a configuration in a file instead of multiple versions for multiple platforms, then do it. Otherwise, most of your time will consume two or more versions of the same file, that is not interesting.
Let us start with an example in my CSHRC file, one version of this file can be used for all machines. I use the C shell language built-in judgment logic to make a choice:
Listing 10. Define precmd for different platforms
Switch ($ OSTYPE) Case "Solaris": Case "Sunos": alias precmd '/ bin / echo "/ 033] 0; $ {Host}: $ cwd / 007 / c"' Breaksw Case "Linux": alias precmd ' Echo -n "/ 033] 0; $ {Host}: $ cwd / 007" 'Breaksw Endsw
The above command indicated the different versions of the same content. Linux Echo requires a -n switch to avoid printing into a new row, while the Solaris version needs to have one / c at the end of the string. The effect of this is that every time the prompt is printed, the title of the XTERM window is set to Host: / Directory. Obviously, as long as you can make a decision in the configuration file itself, you don't need to generate multiple versions of the same file in different directories. For example, only one version of all about six machines used frequently has only one version - some of which run Emacs 20, that is the old antique in many years!
Sometimes you have to do some decomposition. For example, the XMODMAPRC file sets the mapping between keyboard codes and key names (you can also do very much). I saved a version for my home machine in ~ / config / heechee / xmodmaprc, saved another version in the ~ / config / sun / xmodmaprc for all the Sun machines I used. There is no logic in XModMAPRC, so decomposition is the only solution. However, I really created only an XMODMAPRC file for all Sun machines because their keyboard types are the same.
CRONTAB file (I saved in ~ / .crontab, it is required to be loaded into crontab) is an extreme example of the configuration file specified for each machine. The crontab of my household machine will not apply to any other machine, and there is no logic in the standard crontab format to be used to select any conditions other than time in the CRON task.
The key is that you should determine if a profile needs to have multiple versions, then determines the best way to organize those multiple versions. Your goal should be to have a stable environment and don't take a lot of time to write and maintain profiles. I hope that I can confirm that the technology described in this article is helpful for your ideal realm of your exploration.
Conclusion I hope you feel interesting and practical in this article. Do your best to use it - I have used it for many years to improve my setting, it should have benefits to you.
Multi-step steps are switched to this mode, don't be intimidated. You can easily rewrite your configuration for a few days - so step by step, you will have fun from this process.
The biggest benefit you will see is the automatic update function. On any of your machines, you can submit a file, then you will appear on all other machines when you maintain.pl. Even if you don't agree with the directory structure, you should also consider the ability to automatically update and how they will help you.
The second advantage you get is to configure archive. Each version of your configuration will be in the version control system! If you make an error, you can return to an earlier version. If you have lost your entire machine, for example, a hard disk error occurs - you can recover all the profiles written for it for a few minutes.
Don't try to convert all content to this mode. Convert only what you want to save or reuse. Binary files are not suitable for using CVS - at least, does not have the DIFF capabilities provided by CVS for text files. In addition, CVS will have problems when renamed catalogs, although it is of course possible that you have also renamed the directory in the warehouse.
Finally, make a backup for your CVSROOT warehouse, no matter where it is. I hope you will never use them.
Reference
Download the maintain.pl script and maintain.conf configuration files in this article. Read all the Perl articles of the TED in the PERL column. There are many CVS related links in CVS Home. The free software version of the system includes Subversion and GNU Arch (also known as GNU TLA). Commercial products include Rational Clearcase. Jennifer Vesperman's Essential CVS (O'Reilly & Associates, 2003) is a good CVS overview, Gregor Purdy's CVS Pocket Reference, 2nd Edition (O'Reilly & Associates, 2003) is an excellent CVS Quick Reference - I truly recommend it. Open Source Development with CVS, 3rd Edition (Paraglyph Press, 2003) of Karl Fogel and Moshe Bar; you can also buy a book in the bookstore. Version Control With Subversion (O'Reilly & Associates, 2004) is an interesting reading. To learn C shell, Bash, Emacs, and many other configurations of the Linux and UNIX programs, dotfiles.com is an excellent reference. It is highly recommended; when you use it for this site to browse this site, don't complain about us. OpenSSH is a standard, free, very good implementation for the SSH protocol. CVS PServer is very good for anonymous CVS, but not safe. In Daniel Robbins OpenSSH Key Management (DeveloperWorks, July 2001) This series of articles describe how non-interactive logins with the help of SSH-Agent. AppConfig is a CPAN module for parsing command line options and profiles. In Perl: Application configured with Perl (DeveloperWorks, October 2000), TED demonstrates how the AppConfig module can process local configuration storage for Perl program, and how this configuration can be stored in the database so that Access from any machine on the network. You may also want to read the Linux profile (DeveloperWorks, December 2001), which explains those configuration files that control user permissions, system applications, background programs, services, and other management tasks in the Linux system. At the same time, debugging Configure (December 2003) discusses how to do when the configuration file is corrupted and the auto-configuration script does not take effect. Tips for users and developers will help you minimize failures. More reference materials for Linux developers can be found in the developerWorks Linux zone. Order the release of Linux books in the Developer Bookstore Linux area. Develop and test your Linux application with the latest IBM tools and middleware through developerWorks Subscription: You can get IBM software from WebSphere?, DB2?, Lotus?, Rational?, And Tivoli? All licenses for these software are used, all cost is lower than what you imagine.
Speed-start your Linux app download area from developerWorks Linux can run on top of the free test version to selected developerWorks Subscription products, including WebSphere Studio Site Developer, WebSphere SDK for Web services, WebSphere Application Server, DB2 Universal Database Personal Developers Edition , Tivoli Access Manager and Lotus Domino Server. To get started faster, see how-to articles and technical support for each product. About the author Teodor Zlatanov graduated from the Boston University in 1999, a master's degree in computer engineering. He has worked in programmers since 1992, using Perl, Java?, C and C . His interest is a text analysis, three-layer client-server database architecture, Unix system management, CORBA, and project management open source work. You can contact TED with TZZ@bu.edu.
