Summary

Summary

In this chapter, we have examined how to remotely access a Solaris system using traditional and the newer, more secure tools. In addition, we examined how to perform distributed authentication using Kerberos and how to practically connect Solaris systems to the Internet.

Questions

1.	What is the function of the telnet close command? Quit telnet session Close connection Print connection characteristics Change mode
2.	What is the function of the telnet logout command? Quit telnet session Close connection Print connection characteristics Change mode
3.	What is the function of the telnet display command? Quit telnet session Close connection Print connection characteristics Change mode
4.	What is the function of the telnet mode command? Quit telnet session Close connection Print connection characteristics Change mode
5.	What is the function of the telnet open command? Open connection Quit telnet session Send special characters Set connection characteristics
6.	What is the function of the telnet quit command? Open connection Quit telnet session Send special characters Set connection characteristics
7.	What is the function of the telnet send command? Open connection Quit telnet session Send special characters Set connection characteristics
8.	What is the function of the telnet set command? Open connection Quit telnet session Send special characters Set connection characteristics
9.	What is the function of the telnet unset command? Unset connection characteristics Display connection status Change connection characteristics Toggle special character mode
10.	What is the function of the telnet status command? Unset connection characteristics Display connection status Change connection characteristics Toggle special character mode
11.	What is the function of the telnet toggle command? Unset connection characteristics Display connection status Change connection characteristics Toggle special character mode
12.	What is the function of the telnet slc command? Unset connection characteristics Display connection status Change connection characteristics Toggle special character mode
13.	What is the function of the telnet z command? Unset connection characteristics Suspend connection Spawn shell Update environment variables
14.	What is the function of the telnet ! command? Unset connection characteristics Suspend connection Spawn shell Update environment variables
15.	What is the function of the telnet environ command? Unset connection characteristics Suspend connection Spawn shell Update environment variables

Answers

1.	A. The function of the telnet close command is to quit the telnet session.
2.	B. The function of the telnet logout command is to close the telnet session.
3.	C. The function of the telnet display command is to print the session characteristics.
4.	D. The function of the telnet mode command is to change the telnet mode.
5.	A. The function of the telnet open command is to open a connection.
6.	B. The function of the telnet quit command is to quit the telnet session.
7.	C. The function of the telnet send command is to send special characters.
8.	D. The function of the telnet set command is to set connection characteristics.
9.	A. The function of the telnet unset command is to unset connection characteristics.
10.	B. The function of the telnet status command is to display the session status.
11.	D. The function of the telnet toggle command is to toggle the special character mode.
12.	D. The function of the telnet slc command is to toggle the special character mode.
13.	B. The function of the telnet Z command is to suspend a connection.
14.	C. The function of the telnet ! command is to spawn a shell.
15.	A. The function of the telnet environ command is to update environment variables.

File Versioning

< Day Day Up >

File Versioning Every file in a product should have a version number; a four-part number separated by periods such as the one that follows seems to be the established best practice. There are many variations of what each part represents. I will explain what I think is the best way of defining these parts. <major version>.<minor version>.<build number>.<revision> Major version� The component owner usually assigns this number. It should be the internal version of the product. It rarely changes during the development cycle of a product release. Minor version� The component owner usually assigns this number. It is normally used when an incremental release of the product is planned instead of a full feature upgrade. It rarely changes during the development cycle of a product release. Build number� The build team usually assigns this number based on the build that the file was generated with. It changes with every build of the code. Revision� The build team usually assigns this number. It can have several meanings: bug number, build number of an older file being replaced, or service pack number. It rarely changes. This number is used mostly when servicing the file for an external release. Note These numbers range between 0 and 64K and can be enforced by a prebuild test tool or a build verification test. As a rule of thumb, each codeline in a source tree should have its own build number, and that number should start at zero when the branch is created. If it is a build off of the main trunk, the build number should go into the <revision> field. Keep your mainline incrementing with each build as long as it is still the tip of your source tree. See Chapter 16, "Managing Hotfixes and Service Packs," for detailed examples on this labeling. For example, 5.1.2600.2180 is a typical file version for a Windows XP SP2 binary. Let's break this down in more detail: 5.1 is the major and minor internal version number of Windows XP that is always used in our bug tracker. If this was a Windows 2003 kernel, this number would be 5.2. If it was Longhorn, it would be 6.0. 2600 is the RTM (released to manufacturing) build number of Windows XP. 2180 is the RTM build number of Windows XP SP2. How can this revision build number (2180) be smaller than the original XP RTM build (2600)? The reason is because the SP2 codeline is a branch off the XP mainline (the 2600 codeline). When the branch was made, the build number was reset to 0. The large number of builds is a result of SP2 containing all the SP1 changes, which was the same branch. (The RTM build number was 1086 for SP1.) If this was a one-off hotfix rather than a service pack release, the <revision> field might have the number of the bug that was being fixed, such as 1000 (if this was the bug number). Again, to better visualize this, see the sample VSS tree drawings in Chapter 16. Warning: Product Marketing Numbers Mixed in Version Strings Are a "Bad Thing." There seems to be a common misuse of product marketing version numbers for the major and minor numbers in the version string. Don't use the product marketing version in the file version string because different products use some of the same components. Furthermore, marketing numbers don't always follow a sequential order, and sometimes they're random. If, on the occasional circumstance, the marketing people want to use the internal version number of a product, such as NT 4.0, for their marketing version, this would be okay. Just don't link the two numbers in a permanent way.

< Day Day Up >

Section 7.5. Conclusion

7.5. Conclusion In this chapter we looked at the process of creating and managing stored objects (procedures, functions, and triggers). Let's conclude with an outline of what we regard as the best practices for creating and managing stored objects: Make sure that the reference (e.g., official) copy of each of your stored programs exists as a file on disk, not as the copy stored in the MySQL server. Stored programs might need to be shared between multiple servers, and you therefore need at least one copynot on a serverthat represents the current version. Use a version control system to maintain a copy of any version of a stored program that is deployed to a MySQL server. In other words, subject stored program code to the same discipline that you apply to other program code. When you are editing a stored program, check it out of the source control system and load the checked-out copy into the MySQL Query Browser or other tool. Figure 7-14. Viewing the INFORMATION_SCHEMA.ROUTINES table When you are satisfied with your changes, save the stored program code to a disk file and check it into the version control system. Deploy the stored program by creating command-line routines using the MySQL client program, and embed these into Make files or other build/deploy scripts that you can use to apply schema changes and other server object changes. Figure 7-15. Viewing the INFORMATION_SCHEMA.TRIGGERS table

Chapter Summary

[Page 459 (continued)] Chapter Summary Technical Terms array array initializer array length binary search data structure element element type insertion sort multidimensional array one-dimensional array polymorphic sort method selection sort sequential search sorting subscript two-dimensional array Summary of Important Points An array is a named collection of contiguous storage locations, each of which stores a data item of the same data type. Each element of an array is referred to by a subscriptthat is, by its position in the array. If the array contains N elements, then its length is N and its indexes are 0, 1, . . . N-1. [Page 460] Array elements are referred to using the following subscript notation arrayname[subscript], where arrayname is any valid identifier, and subscript is an integer value in the range 0 to arrayname.length - 1. The array's length instance variable can be used as a bound for loops that process the array. An array declaration provides the name and type of the array. An array instantiation uses the keyword new and causes the compiler to allocate memory for the array's elements: int arr[]; // Declare a one-dimensional array variable arr = new int[15]; // Allocate 15 int locations for it Multidimensional arrays have arrays as their components: int twoDarr[][]; // Declare a two-dimensional array variable twoDarr = new int[10][15]; // Allocate 150 int locations An array's values must be initialized by assigning values to each array location. An initializer expression may be included as part of the array declaration. Insertion sort and selection sort are examples of array-sorting algorithms. Both algorithms require several passes over the array. When an array is passed as an argument to a method, a reference to the array is passed rather than the entire array. Swapping two elements of an array, or any two locations in memory, requires the use of a temporary variable. Sequential search and binary search are examples of array-searching algorithms. Binary search requires that the array be sorted. For multidimensional arrays, each dimension of the array has its own length variable. Inheritance and polymorphism are useful design features for developing a hierarchy of computer games.

Some Tough Questions

[ Team LiB ]

Some Tough Questions One reason that new innovations move into practice slowly is that some of them don't work very well in practice! Not all innovations are useful, and the Early Majority, Late Majority, and Laggards have some good reasons for being cautious. When presented with an innovation, they ask tough questions like these:[23] Do experimental results prove conclusively that the innovation will work in practice? Are successes a result of the innovation itself, or might they be the result of the people using it? Is the innovation complete, or does it need to be adapted or extended before it can be applied? Does the innovation have significant overhead (training, documentation) that offsets its value in the long run? If the innovation was developed in a research setting, does it apply to real-world problems? Does the innovation generally slow down the programmers? Can the innovation be misapplied? Is information available about the risks involved with using the innovation? Does the innovation include information about how to integrate it with existing practices? Must the innovation be applied in its entirety to realize significant benefits? Very few software engineering practices have had data collected and disseminated widely enough to prepare software practitioners to answer questions like these. As a result, the software engineering practices described in Table 21-1 are stuck on the left side of the chasm. Early Adopters have been using many of those techniques for 15 years or more, while the later adopter groups are largely unaware of them. The numbers from Rogers's adopter categories are close to the numbers of projects that use code-and-fix development�about 75 percent of projects are still using code and fix or its close cousins, and a similar percentage of adopters fall onto the right side of the chasm. Why is this? In Rogers's framework, one reason that innovations are diffused to Innovators and Early Adopters more quickly is that Innovators and Early Adopters tend to have more resources�they are in better positions to afford costly mistakes. Later adopters are more cautious partly because they aren't as resource rich. As I mentioned in Chapter 12, however, the scarce resource in this case isn't money; it's time. Lagging-edge practices such as code-and-fix development are associated with significant schedule overruns. The overtime that usually accompanies such overruns doesn't leave time for investigating and adopting more effective innovations.

[ Team LiB ]

Questions the SRS Answers for a Project

< Free Open Study >

Questions the SRS Answers for a Project The major question that the SRS addresses concerns the problem domain in which the product will exist. As shown in Figure 17-3, all software products can be viewed from three perspectives: data, process, and behavior. Figure 17-3. Three Perspectives of Software Products The data view looks at identifying the primary data objects to be processed by the software system. The definition of each object as well as where it resides is identified. One object's relationship to other objects and the processes that act on them are also part of the data view. For an ATM machine, an important piece of data would be a customer's personal identification number (PIN). As the data within a software system moves, it is modified by a series of transformations. The process view of the problem domain focuses on these data transformations. The transformation of data from inputs to outputs satisfies the business requirements of the system as captured in the SRS. With our ATM, a process would be the validation of the PIN. The behavior view of the system focuses on the states a system assumes. The state is any externally observable mode of behavior. After a PIN is entered in the ATM, the machine is in the state of validating the PIN. Processes are running and data is being transformed, but the user is only observing a message that may indicate that his or her PIN is being validated. The SRS is the first step in a project that moves from the recognition and definition of the problem domain to a solution domain. The solution domain fills in the three perspectives with requirements models tailored to capturing data, process, and behavioral characteristics (see Figure 17-4). The development of these individual models will be covered later in this book. The SRS provides the framework for holding the models. Figure 17-4. Process, Data, Behavior Once we look at the views of our software system, questions arise that lead to the requirements collection. These questions relate to the quality of the SRS produced and to how we eventually validate the completed SRS. Construx Software (www.construx.com) provides a series of software development checklists. IEEE 830-1998 provides the set of quality characteristics an SRS exhibits: Correctness Unambiguousness Completeness Consistency Ranking for importance and/or stability Verifiability Modifiability Traceability Using the checklist model and the standard, an SRS aids in answering questions for these key characteristics: Correctness Is the expected response time, from the user's point of view, specified for all necessary operations? Are other timing considerations specified, such as processing time, data transfer, and system throughput? Are all the tasks the user wants to perform specified? Does each task specify the data used in the task and data resulting from the task? Is the level of security specified? Is the reliability specified, including the consequences of software failure, vital information protected from failure, error detection, and recovery? Are acceptable trade-offs between competing attributes specified, for example, between robustness and correctness? Are external people, software, and hardware interfaces defined? Is the definition of success included? Of failure? Unambiguousness Are the requirements clear enough to be turned over to an independent group for implementation and still be understood? Are functional requirements separated from non-functional? Completeness Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency? Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format? Are all the communication interfaces specified, including handshaking, error checking, and communication protocols? Where information isn't available before development begins, are the areas of incompleteness specified? Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable? Is there a sense of unease about any part of the requirements? Are some parts impossible to implement and included just to please a customer or a boss? Has a complete risk analysis been done with special emphasis on any missing requirements? Consistency Do the requirements avoid specifying the design? Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail? Ranking for importance and/or stability Is each item relevant to the problem and its solution? Verifiability Are the requirements written in a language and with a vocabulary the user understands? Do the users agree? Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied? Modifiability Are all possible changes to the requirements specified including the likelihood of each change? Is the maintainability of the system specified, including the ability to respond to changes in the operating environment, interfaces with other software, accuracy, performance, and additional predicted capabilities? Traceability Do all the requirements avoid conflicts with other requirements? Can each item be traced to its origin in the problem environment?

< Free Open Study >

Section 5.7.  Branching, Tagging, and Merging

5.7. Branching, Tagging, and Merging As I explained in earlier chapters, most version control systems allow you to create branches and tags from the main trunk of your repository. Tags allow you to mark specific points in your development (such as releases) for later referral, and branches allow you to split the development of your repository and continue development in parallel on a secondary path. Unlike many other version control systems, Subversion doesn't actually have a built-in concept of branches or tags. Instead, it just uses cheap server-side copies that preserve history, while not taking up any additional space. Subversion just marks the location of the copied file or directory and notes where it came from. It then allows you to merge the changes from a "branch" back into the main trunk of the repository at a later date. Although the current implementation of Subversion's copy-merge system does pose the occasional problemfor instance, you can quickly lose track of a file's full merge/branch history if it becomes more than trivially complexthe flexibility of the paradigm more than makes up for its shortcomings in most cases. 5.7.1. Creating a Branch or Tag Creating a branch or tag in Subversion is trivially easy. All you need to do is run svn copy on the file or directory that you want to branch/tag. Generally, your repository will be set up with one or more directories named branches and tags, which will be where you want to place copies that are conceptually branches or tags. This is a convention, however, and is in no way enforced by Subversion. As far as Subversion is concerned, directories named branches or tags are identical to any other directories. A typical repository layout is to have three top-level directories in the repository, named trunk, branches, and tags. The trunk directory contains the main development branch of the repository, and all branches and tags are created by putting copies in their respective directories. By separating the three directories at the top level, you can then check out only the TRunk directory, and deal with branches and tags only in the repository most of the time. When you need to use or edit parts of the repository that are in branches, you can use svn switch to swap them into your working copy of the TRunk directory. Creating a Branch/Tag in the Repository The most efficient way to branch or tag a part of the repository is usually to perform the copy entirely in the remote repository. When Subversion performs a copy in the repository, it doesn't make a copy of the data, but instead just points the copy back to the data from the original. This allows copies of any sized file to occur in a constant amount of time, be it five kilobytes or five hundred megabytes. On the other hand, if the copy is performed in the local working copy, the repository-side copy still occurs in constant time, but you also make a copy of the data in the working copy, which is proportional to the amount of data to be copied. A repository-only copy is performed using svn copy with repository URLs for both source and destination. When the command is run, Subversion performs an immediate commit, which means that it opens an editor to allow you to enter a log message if you don't supply one on the command line. As an example, the following command shows how you might create a branch of your entire trunk in a typical repository. [View full width] $ svn cp --message "Created a new branch" http://svn.example.com/repos/trunk http://svn .example.com/repos/branches/mybranch Committed revision 2353. Creating a Branch/Tag from the Working Copy Sometimes, creating a branch or tag entirely on the repository is impractical. For example, you might want to create a tag or branch that includes uncommitted local modifications, or consists of multiple mixed revisions. In such cases, you need to pass svn copy a working copy path as a source. You can also pass a working copy path as the destination of the copy, but that is generally not what you want, because that would result in the data being copied on your local copy. Instead, if you make sure the destination is still a URL, Subversion only sends the local changes to the repository and all other copies are done as the usual cheap repository-side copies. [View full width] $ svn cp --message "Tagging a snapshot of the local working copy" ~/repos/trunk http://svn .example.com/repos/tags/mytag Committed revision 2193. Switching to the Branch/Tag Regardless of how you create a branch or tag, the best way to edit it locally is usually to use svn switch to change the URL that all or part of your working copy points to. If you have a working copy of your trunk already checked out, you will generally save a lot of bandwidth by using the switch command, because it only downloads the differences necessary to switch the URL. The other advantage of svn switch is that it allows you to branch only a portion of your trunk, and then switch that portion in your working copy to the branch without invalidating any relative paths to the rest of your working copy. 5.7.2. Merging a Branch As you work with a branch, you may periodically want to update it with changes from the main trunk, in order to get changes made by others. You will also usually want to merge the changes that you make in the branch back into the main trunk after they have reached a stable point. Both of these situations are handled with the svn merge command. The svn merge command is conceptually the hardest Subversion command to deal with, but after you understand how it works, using it is not that complicated. The most basic usage of svn merge is to run it with two revision numbers and a source, as in this example: $ svn merge --revision 100:150 http://svn.example.com/repos/branches/mybranch U goodbye.cpp A hello.cpp In this example, svn merge takes the differences between revisions 100 and 150 in the mybranch branch and applies them to the current working copy. The application of the changes occurs just as if you had done an svn update, and any conflicts are handled accordingly. Another way to run svn merge is to give it two URLs or working copy paths, with revision numbers, and perform a merge of their differences. $ svn merge branches/mybranch@1426 branches/myotherbranch@253 D goodbye.cpp U hello.cpp As you can see, in the preceding example, there is no requirement that the first revision number should be lower than the second. In fact, regardless of which revision is lower, Subversion will always merge the differences calculated by subtracting the lefthand revision from the righthand revision. So, if a file exists in the righthand revision and not in the lefthand revision, it will be added by the merge. Conversely, if it exists in the lefthand revision but not the righthand, it will be removed. You will also notice in the last example that I used peg revisions to identify which revisions should be used to identify the files. Peg revisions in a merge work the same as they did for svn diff (see Section 5.4.1, "Getting Information on the Current State"). Keeping Track of Merges One of the things that Subversion handles poorly is a file or directory's merge history. Subversion does not keep a record of what has been or hasn't been merged. Because of this, it is important for you to keep your own merge history, in order to avoid merging a change twice (which could cause that change to be undone). The easiest way to keep track of your merge history is to record in the commit log what files/revisions were merged. $ svn merge --revision 305:356 branches/mybranch U Makefile $ svn commit --message "Merged in revisions 305 to 356 of mybranch" Committed revision 1398. Then, the next time you want to merge the changes from mybranch into trunk, you can use svn log with grep to quickly see which revisions have already been merged in. $ svn log | grep 'Merged' Merged in revisions 305 to 356 of mybranch Merged in revisions 284 to 305 of mybranch Merged in revisions 246 to 320 of myotherbranch $ svn merge --revision 356:423 branches/mybranch Reverting Changes with Merge Another use for the merge command is to revert changes that were applied in a previous revision. Say, for instance, that you removed a couple of functions (named doFoo() and getBar()) from your source file, but now realize that you actually need them. Assuming that they were both removed in discrete commits (i.e., nothing else was changed in the source file at the same time those functions were removed), merging them back into the HEAD revision is quite simple. First, you'll want to check the logs to find out which revisions the function removals actually took place in. If the file is an active one, with a long log, you might want to use the grep command to pare the output down to something a little more manageable. As an example, the following command will search for any lines containing the word "removed" as well as lines that begin with "r" and a number (most likely log entry headers). $ svn log | grep -E 'removed|^r[0-9]' r15 | bill | 2004-06-14 19:44:06 -0500 (Sat, 14 Jun 2004) | 98 lines r76 | bill | 2004-07-17 12:35:24 -0500 (Sat, 17 Jul 2004) | 32 lines removed doFoo() r85 | bill | 2004-07-23 10:23:19 -0500 (Fri, 23 Jul 2004) | 15 lines r97 | bill | 2003-08-07 15:54:29 -0500 (Thu, 05 Aug 2004) | 145 lines removed getBar() After you know which revisions the functions were removed in, you can revert the removals by performing a merge with a range that goes backwards, from the revision where the removal took place, to the revision immediately preceding the removal. This will merge the removed sections back into your current working copy, where you can make any necessary modifications and then commit. $ svn merge --revision 76:75 foobar.c U foobar.c $ svn merge --revision 97:96 foobar.c U foobar.c $ svn status M foobar.c $ svn commit --message "Reverted changes from revs 76 & 97 to foobar.c" Sending foobar.c Transmitting file data . Committed revision 245. Looking before You Merge Merges can cause a lot of changes to be applied to the files in your working copy, and undoing those changes can be difficult if there are a lot of local changes. It can be helpful, then, to find out exactly which files Subversion will change (as well as what conflicts will occur) before actually performing the merge. Subversion allows you to do just that with the --dry-run option. When svn merge is invoked with --dry-run, Subversion will perform all of the necessary calculations for the merge and output a list of files that will be modified (as well as how those files will be modified), but it will not actually change any of your local files.