|May the source be with you, but remember the KISS principle ;-)|
|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|News||Recommended Links||Tutorials||FAQs||Recommended Papers|
|Unix Configuration Management Tools||Cons||Host factory|
Some concepts useful for both software and OS/application configuration management:
Concept of review [Aegis]: checking-in file can trigger information to people who supposed to be informed about a particular change.
Recent start-ups in this area are mValent (expensive, written in Java GUI-based configuration management for major Java infrastructure applications like Websphere ) and Opsware:
[July 28, 2004]
Infrastructure Automation Suite: automates the application migration process and eliminates pain points, like configuration inconsistency between versions (as is the case with an upgrade from WebSphere 4.x to WebSphere 5.x), with tools it calls "enablers." Version 2.2 contains enablers designed for WebLogic and WebSphere users looking to manage disparate and interdependent configuration definitions underlying the app server platforms.
The mValent Infrastructure Automation Suite, "addresses system downtime due to configuration errors," Andrew Bird, vice president of marketing and business development for mValent told ServerWatch. It does this by automatically running a series of checks to confirm configurations are consistent and correct across all environments and components.
The product is designed to be used early in the adoption cycle -- in the "pre-production, post-development phase," Bird said.It is designed to complement, not replace, a provisioning tools and management software, Bird emphasized.
The WebSphere and WebLogic enablers found in v2.2 automate the creation and management of configurations for those platforms. Key tools are:
- Prebuilt, customizable templates for domain configuration files enable standardization of management processes because all configurations are based on a common template, rather than re-invented every time.
- Automatic Verification ensure parameters are within the domain and site-specific ranges defined in the standard templates. As a result, parameters are validated before deployment.
- Application Server Replication enablers provide functionality to generate a perfectly replicated application server in a few mouse clicks.
- Assisted Discovery and Configuration Management Database Population simplifies the process of creating a consolidated source for all infrastructure configurations. The enablers understand the specific domain environment and read, validate, and translate existing application server configurations, and then load them directly into the configuration management database.
The mValent's Infrastructure Automation Suite is available for immediate purchase. Pricing is based on the number of users, with entry-level deployments starting at $50,000.
Founded two years ago, mValent currently claims 10 clients, including MFS Investment Management, Raytheon, and State Street. It also has four of the world's top-10 financial services organizations as customers.
The Machine Inventory Database (MID) is a Perl-based CGI interface to manage the machines on and off your network, both from the IP assignment perspective and the asset-tracking perspective. On top of acting as a frontend to a handful of MySQL tables, it handles IP assignment and acts as a frontend to the configuration files for BIND, YP, and DHCPD to reduce the chance for typos in the configuration files which tend to bring down service.
PerlNuke is a Content Management System like phpNuke but based on Perl.
filofant is an email and document indexing server with a customizable Web interface like a Web search engine. It is designed for companies and other groups which want to share their information in an easy and fast way.
A full-featured GUI for the GNU Arch revision control system.
Before you get out your torches please consider that there are honestly still people out there-good, intelligent people-who still have no idea what they are missing by staying with CVS. I know, I know, unbelievable. But asking people if they've been in a hole for the past two years does not build a relationship conducive to change-adoption, a lesson I think I may have learned the hard way. But to their credit, I discovered something that opened my eyes a bit. Many don't even know they are in that hole.
The IDE Hole
Many who use an IDE such as Eclipse or Rational Software Architect (with its $5500 price tag, 7GB disk and 1 GB RAM requirements) also have only known CVS support from the plugin. They have no desire to learn the command-line options nor do they ever manage the source tree themselves. These folks are happy to save their project and commit without ever seeing all of CVS's warts, and probably with little thought to tagging, branching, use of symbolic links, handling of binaries and any number of other things that Subversion primarily addressed. The IDE takes care of compilation and all sorts of things that might otherwise be handled more painfully from the command-line. "CVS works. Why use anything else? Especially if I have to migrate," is their opposition based on a sense or familiarity and security. But they are deceived. The IDE is largely hiding the real reason they should be considering SVN.
The Real Reason No One Should Ever Use CVS Again
I won't go into all the reasons to switch to Subversion. The subversion web site makes this case well, including that the people who wrote the book on CVS spent three years on Subversion to replace it; or that SVN doesn't corrupt binary files when you forget to list them in .cvswrapper properly; or that CVS doesn't do atomic commits or symbolic links; or how old and unwieldy the CVS internals are preventing anything like the many SVN plugins available; or that SVN let's you switch a sandbox directory between versions with one command; or that in SVN you can easily checkout any portion of your subtree. No I won't go into those reasons. Instead I want to focus on a much more subtle-perhaps the most important-reason developers and team leads should drop CVS like a bad taco salad.
The Whole Point
The whole point of any SCM tool is to make restoring a point in time, merging between them, and branching off experiments from the trunk as easy, reliable, and cheap as possible. Sure CVS does this but Subversion makes it as easy as copying directories and files, literally. This intuitive design makes you want to branch and tag more frequently. There isn't any nagging checkout of another tagged set into another directory like in CVS because the tag is the directory. This plays wonderfully off what a lot of developers might do with SCM to reserve something they want to remember, a tagged point in their code. In CVS this is a nightmare. "Let's see did I tag all these files or just these few." And anyone who has had to deal with dangling files and directories, permissions problems and other issues in CVS requiring root access to the SCM server to fix knows exactly what I am talking about.
Subversion further helps by allowing user-defined properties to be associated easily with a file, directory, or subdirectory recursively. The light-weight nature of tagging makes them even friendlier and adoptable.
Be honest. How many of you have actually used CVS effectively to branch and merge something, even from behind a monolithic IDE? How many have actually had to revert or go back to a point in time and recreate something in your source? Chances are you are like me and haven't had to that much. And here is where those asleep inIDE stupor are really going to get a harsh wake up call one day.
A Real World Example
[Beware, explicit FUD ahead.] I recently spoke with a respectable developer in the local community who, as I have done, keeps all his source in Subversion even if he has to make regular commits to some other ugly alternative. Some time ago his customer wanted a point in time restore. They were not able to do it with their own CVS because of its inadequacies mixed with those of the internal development team. He turned out to be something of a hero when he produced the source from his own Subversion tree. He succeeded because even though it might have been possible in both systems, it was easier for him to actually deliver on the restore request.
But what about backups?
Backing up CVS is a complicated process of freezing the CVSROOT on the server, to which you must have access followed by tar scripts and permissions preservation in order to actual restore it. Subversion lets any user keep backups of your entire repo with a single svn hotcopy or svn dump command. The internal SVN files are themselves also re visioned, something else CVS doesn't do. So developers that are particularly paranoid about their repository backups can do their own. This is good medicine for that sorry-our-last-backup-is-feb-2005 disease that creeps into most any developer shop, no matter how careful they are.
Subversion does have its share of warts, but they aren't visible to most. The one I find the most annoying is remembering to svn update after doing any kind of directory restructuring and recommitting so you don't get the 'out of sync' error. Another is learning to get into the habit of svn status to make sure you haven't adding something without adding it to the system. SVN does warn you, however, when you commit about that and if you use the filesystem integration or an IDE then you don't have to mess with that. I'll gladly take these inconveniences over binary file corruption any day.
Technical Leadership Required
My experience has been that most developers don't like to be bothered with SCM in general, if they even know what that TLA means. Most developers don't need to care because someone else is supposed to. They just want something to restore that file they accidentally deleted when they were too mouse or keyboard happy. I've run into projects using tar and the filesystem for their SCM strategy. The reality is it takes development leadership to step in and direct a move to any SCM including Subversion. Here's hoping more team leads and project managers will see the reduced risk and efficiency gains Subversion has to offer and join the rapidly growing number of significant projects, both open and internal, that are now saying "CV-what"? ersion control systems that support moving or renaming.
SSU (SourceSafe for Unix) provides command-line access to local and remote Source Safe/VSS repositories through TCP.
SandWeb is a Web-based Sandbox Management Client. Since we currently only support CVS, it could also be described as a Web-based CVS client. It can be used to check out modules from a VCS such as CVS, manage files, edit, commit, and much more.
cvs2cl.pl generates GNU-style ChangeLogs for a CVS working copy. There are many options to control the output.
ArchZoom is a Web-based browser for the GNU Arch revision control system with minimal requirements and decent configurability. It provides easy-to-use navigation from managed archives to complete revision trees and features multiple views, like expanded changeset information with colored diffs inline.
Mikhael Goikhman [contact developer]
Codestriker is a Web application that supports online code reviews. Traditional document reviews are supported, as well as reviewing diffs generated by an SCM (Source Code Management) system and plain unidiff patches. There are integration points with CVS, Subversion, Clearcase, Perforce, Visual SourceSafe, and Bugzilla. There is a plug-in architecture for supporting other SCMs and issue tracking systems. It minimizes paper work, ensures that issues, comments, and decisions are recorded in a database, and provides a comfortable workspace for actually performing code inspections. An optional highly-configurable metrics subsystem allows you to record code inspection metrics as a part of your process.
David Sitsky <sits [at] users [dot] sourceforge [dot] net> [contact developer]
Package: wnpp Severity: wishlist * Package name : libvcs-lite-perl Version : 0.05 Upstream Author : Ivor Williams <firstname.lastname@example.org> * URL : http://search.cpan.org/dist/VCS-Lite/ * License : Dual GPL/Artistic Description : Minimal version control system This module provides the functions normally associated with a version control system, but without needing or implementing a version control system. Applications include wikis, document management systems and configuration management. . It makes use of the module Algorithm::Diff. It provides the facility for basic diffing, patching and merging.
PRCS vs. CVS comparisons project numbering and associating file with the project is definitely a nice feature.
scm98A paper describing PRCS ( ps, pdf) was presented at the 8th International Symposium on System Configuration Management.
Below is a brief list of the features that most distinguish Gnu Arch from competing systems. This list presumes that you are somewhat familiar with revision control systems in general. (See also, What is Revision Control?)
Whole Tree Changesets: Atomic Commits and Add/Delete/Rename Handling
Transactions in Gnu Arch are on whole source trees. For example, let's suppose that you modify three files in order to fix a bug. When you commit this change, you commit all three files at once. Arch records a new revision that contains exactly the modifications to those three files (relative to some earlier revision).
Atomic, whole-tree commits are very convenient. To continue the example: you could record the name of the new revision in your bug database as the revision that contains the bug-fix. Or you could send the name of the new revision to a fellow-programmer, who can then merge exactly those changes and no others into his own branch. A project maintainer can ask arch to display exactly those changes in order to review your work.
Whole tree changesets in Arch correctly handle file, directory, and symbolic link additions, removals, and renames. "Correctly handle" means not only that such changes are recorded as part of the changeset, but also that you can merge changes back and forth between versions that do and do not have those tree-structure changes, and the merging process will take that into account.
Symbolic Revision Names
Arch assigns revisions meaningful, symbolic names that are globally unique among a community of arch users. Thus, it is always possible to refer unambiguously to any given revision, in any Arch archive. Strange annoyances such as CVS's "even/odd length" branch and revision numbering scheme or Subversions global repository revision number are avoided in Arch.
Easy Branching and Smart Merging
Creating a branch in Arch can be accomplished with a single, fast command.
Merging between branches in Arch is history sensitive which means that Arch helps to avoid spurious merge conflicts by avoiding redundant merges whenever it can.
In fact, there are many different kinds of merging that are useful in the world (e.g., CVS-like updates, cherry-picking, vendor-branch-style tracking, mutual 3-way merges between branches...). Rather than provide just one merge command, Arch provides a toolbox of several merge commands, allowing you to pick the right tool for each job.
Tags in Arch are as easy to create as branches (in fact, the same mechanism is used).
Tags can be "moved" in Arch and, when the are, data about their old location is preserved. In other words, tags are revision controlled just like source.
Lightweight, Standard Servers; Simple On-disk Formats
Arch uses a collection of simple disk formats for archives and ancillary databases. It does not require or use a relational database, hash-table database, object database, or CVS-like ",v" files.
Consequently, creating a new local archive is utterly trivial: a single arch command does it, basically by creating some new directories.
And, consequently, remote archives do not require an Arch specific server! Your existing
WebDavserver can be used as an Arch server. Your existing
HTTPserver can be used as a read-only Arch server.
Branches, in Arch, are not required to be in the same archive as the branched-from version. In fact, creating a branch requires nothing more than read-only access to the branched-from version.
Operation across archive boundaries in Arch is essentially seemless: commands operate equally well on local and remote archives and on versions scattered across multiple archives.
For public and inter-organizational development projects distributed operation is an especially valuable feature: contributors can form and publish their work on their own branches of your mainline sources -- without requiring that they have write access to your archive. You can merge in their changes as easily as if they had been committed to your own archives.
Integrity Checking and Signed Revisions
Archive revisions are protected against storage-media corruption by checksum files which are verified during ever retrieval. Additionally, committed revisions can be cryptographically signed by their creators, and those signatures verified on retrieval.
It is trivial to set-up and incrementally update read-only mirrors of any arch archive. A common pattern of use in public projects is to improve performance by creating private local copies of remote archives.
Since Linus Torvalds' decision to stop using BitKeeper for the Linux kernel - for licensing reasons, not technical reasons - a number of people have suggested Subversion as a possible replacement version control system. Linus himself has said he doesn't want to switch to Subversion, most recently in a footnote at the end of http://lwn.net/Articles/130681/.
We, the Subversion development team, would like to explain why we agree that Subversion would not be the right choice for the Linux kernel.
Subversion was primarily designed as a replacement for CVS. It is a centralized version control system. It does not support distributed repositories, nor foreign branching, nor tracking of dependencies between changesets. Given the way Linus and the kernel team work, using patch swapping and decentralized development, Subversion would simply not be much help. While Subversion has been well-received by many open source projects, that doesn't mean it's right for every project.
Someday, Subversion may have the features Linus needs, but they're just vaporware until then, and they haven't been our immediate priorities. For example, the feature we added most recently (in response to user demand) was file locking - not exactly something the Linux kernel team was clamoring for. Linus needs a version control system that supports his working model today, something like Monotone, which he mentioned in his post, or GNU Arch, or SVK (which implements distributed functionality on top of Subversion), all of which support at least some of the features that attracted Linus to BitKeeper in the first place.
One very positive result of the move away from BitKeeper will be that people can set up Subversion mirrors of kernel activity without worrying about conflicts with BitMover, Inc (see http://subversion.tigris.org/bitmover-svn.html#licensing for the history of that situation). BitMover Inc has been extremely sensitive about any attempts to reverse-engineer or duplicate BitKeeper functionality, and has done its best to prevent open source developers from implementing BitKeeper-like features in other version control systems. We have always found this a disappointing assault on the freedom of open source programmers, and strongly disagree with Larry McVoy's claim, quoted at http://kerneltrap.org/node/4966, that BitMover Inc represents "as open-source friendly a commercial organization as you are *ever* going to see". We are happy that this situation will be minimized by the Linux kernel's move away from BitKeeper.
We wish Linus and the kernel team luck in finding a truly free version control system that supports their model well. That system probably won't be Subversion, but at least there won't be any more obstacles for people who want to set up Subversion mirrors or other Subversion-based tools for their personal Linux development.
-The Subversion Development Team
$Date: 2005-04-06 14:37:15 -0700 (Wed, 06 Apr 2005) $
The New Breed of Version Control Systems
by Shlomi Fish
A version control system enables developers to keep historical versions of the files under development and to retrieve past versions. It stores version information for every file (and the entire project structure) in a collection normally called a repository.
Inside the repository, several parallel lines of development, normally called branches, may exist. This can be useful to keep a maintenance branch for a stable, released version while still working on the bleeding-edge version. Another option is to open a dedicated branch to work on an experimental feature.
Version control systems also let the user give labels to a snapshot of a branch (often referred to as tags), to ease later extraction. This is useful to signify individual releases or the most recent usable development version.
Using a version control system is an absolute must for a developer of a project above a few hundred lines of code, and even more so for projects involving the collaboration of several developers. Using a good version control system is certainly better than the ad-hoc methods some developers use to maintain various revisions of their code.
Traditionally, the de-facto open source version control system was CVS, but lately many others have emerged that aim to be better in some or every way. This article provides an overview of several alternatives.
Version control systems come in all shapes and sizes, but there are common guidelines for their design. Some systems support Atomic Commits, which means that the state of the entire repository changes all at once. Without atomic commits, each file or unit changes separately and so the state of the entire repository at any one point may not be preserved.
Most common VCSs allow merging of changes between branches. This means that changes committed to one branch will be committed to the trunk or another branch as well, with one automatic (or at least semi-automatic) operation.
A distributed version control system allows the cloning of a remote repository, producing an exact copy. It also allows changes to propagate from one repository to another. In non-distributed VCSs, a developer needs repository access in order to commit changes to the repository. That leaves developers without repository access as second-class citizens. With a distributed VCS, this is a non-issue, as each developer can clone the master repository and work on it, later propagating his changes to the master repository.
Another common factor is whether the repository allows versioned file and directory renames (and possibly copies well). If a file changes location, will the repository preserve its history? Can changes applied to the organization of the older files be applied to the new organization?
Of these features, CVS itself supports only merging.
Related ReadingTable of Contents
CVS, the Concurrent Versions System, is a mature and relatively reliable version control system. Many large open source projects, including KDE, GNOME, and Mozilla use CVS. Most open source hubs such as SourceForge support it as a service, which as a result caused it to be used by many other projects.
Despite its popularity, CVS has its limitations. For example, it does not support file and directory renaming. Furthermore, binary files are not handled very well. CVS is not distributed and the commits are not atomic. As there are already better alternatives that aim to be a superset of its functionality, you are probably better off starting a new project by using something else.
On the plus side, CVS is extensively documented in its own online book and in many online tutorials. There are also many graphical clients and add-ons available for it.
Subversion aims to create a better replacement for CVS. It retains most of the conventions of working with CVS, including a large part of the command set, so CVS users will quickly feel at home. Aside from that Subversion offers many useful improvements over CVS: copies and renames of files and directories, truly atomic commits, efficient handling of binary files, and the ability to be networked over HTTP (and HTTPS). Subversion also has a native Win32 client and server.
Subversion has recently entered its beta period after being alpha for a long time. As such it may still have some minor quirks, and its performance in some areas is lacking. Nevertheless, it's very usable for a beta-stage software, and was so even in a large part of its alpha-stage.
The HTTP (or HTTPS)-based Subversion service is difficult to deploy in comparison to other systems, as it requires setting up an Apache 2 service with its own specialized module. There is also an "svnserve" server that is less capable but easier to set up (and faster) and uses a custom protocol. Moreover, Subversion's support for merging is limited and resembles that of CVS. (i.e., merges to branches where files were moved will not be performed correctly). It is also relatively resource intensive, especially with large operations.
Subversion is extensively documented in the free online book, Version Control with Subversion. The rudimentary online help system supplied by the Subversion client can also prove useful for reference. Subversion has many add-ons, but they are still less mature than their CVS counterparts.
GNU Arch is a VCS originally created by Tom Lord for his own version control needs, as well of those of other free software projects. Arch was initially prototyped as a collection of shell scripts, but its main client now is tla, which is written in C and should be portable to any UNIX. It has not been ported to Win32; while it is possible to do so, it is not a priority for the project.
Arch is a distributed version control system. It does not require a special service in order to set up a network-accessible repository, and any remote file-service service (such as FTP, SFTP, or WebDAV) is a suitable Arch service. This makes setting up a service incredibly easy.
Arch supports versioned renames of files and directories, as well as intelligent merging that can detect if a file has been renamed and applies the changes cleanly. Arch aims to be superior to CVS, but there are still some individual features missing. Arch is a post-1.0 system and, as such, is declared mature and stable for any use.
Arch is documented with a very basic online help system and a tutorial.
OpenCM is a version control system created for the EROS project. OpenCM does not aim to be as feature-rich as CVS is, but it does have a few advantages. OpenCM has versioned renames of files and directories, atomic commits, automatic propagation of changes from branch to trunk, and some support for cryptographic authentication.
OpenCM uses its own custom protocol for communicating between the client and the server. It is not distributed. Since OpenCM is not very feature-rich, it is possible that other systems will better suit your needs. However, you may prefer using OpenCM if one or more of its features is attractive to you.
OpenCM runs on any UNIX and on Windows under the Cygwin emulation layer. It features a CVS-like command set and is well documented.
Aegis is a source configuration management (SCM) system created by Peter Miller. It is not networked, and all operations are done via UNIX file-system operations. As such, it also uses the UNIX permissions system to determine who has permission to perform what operation. Despite the fact that Aegis is not networked, it is still distributed in the sense that repositories can be cloned and changes can be propagated from one repository to the other. Allowing network access requires using a file system such as NFS.
Being an SCM system, Aegis tries to assure the correctness of the code that was checked in. Namely, it:
- Manages automated tests, prevents check-ins that do not pass the previous tests, and requires developers to add new tests.
- Manages reviews of code. Check-ins must pass the review of a reviewer to get into the main line of development.
- Has various other features that aim to ensure code quality.
Its command set reflects this philosophy and is quite tedious if you desire only a plain version control system.
Aegis is documented in several troff documents that are then rendered into PostScript. As such, it is sometimes hard to browse the documentation to find exactly what you want. Still, the documentation is of high quality.
The Monotone Version Control System was created by Graydon Hoare, and exhibits a different philosophy than all of the above systems. It is distributed, with changesets propagated to a certain depot that can be a CGI script, an NNTP (Usenet news) receiver, or SMTP (email). From there, each developer pulls the desirable changes into his own copy of the repository.
This may have the unfortunate effect of causing the history or current state of the individual repositories to fall out of sync with each other, as individual repositories do not receive the appropriate changes, or receive inappropriate ones.
Monotone relies heavily on strong cryptography. It identifies files, directories, and revisions by SHA1 checksums. RSA certificates govern repository permissions.
Monotone supports renames and copies of files and directories. It has a command set that aims to be as CVS-compatible as possible, with some necessary deviations due to its different philosophy. It should be portable to Win32, but was not explicitly ported yet.
Monotone is still under development, and may still have some behavioral glitches. The Monotone developers expect to resolve these problems as work continues.
All in all, Monotone holds a lot of promise, and is well worth examining.
BitKeeper is not an open source version control system, but is listed here for completeness because some open source projects use it. BitKeeper is very reliable and feature-rich, supporting distributed repositories; serving over HTTP, file, and directory copies, and renames; patches management; tracking changes from branch to trunk; and many other features.
BitKeeper comes in two licenses. The commercial license costs a few thousands dollars per seat (lease or buy). The gratis license is available for development of open source software, but has some restrictions, among them a non-compete clause and a requirement to upgrade the system as new versions come out, even if they have a different license. Furthermore, the source code is not publicly available, and binaries exist only for the most common systems, including Win32.
A handful of projects use BitKeeper, including some of the Linux kernel developers and the core MySQL developers. It has been the subject of much controversy in the Linux Kernel Mailing List. Due to its license, BitKeeper is not suitable for open source development, as this will alienate more "idealistic" developers, and impose various problems on the users who choose to use it. If you are working on a non-public project and can afford to pay for BitKeeper, it is naturally an option.
You probably should not use CVS, as there are several better alternatives, unless you cannot get hosting for something else. (Note that GNU Savannah provides hosting for Arch, and there is documentation for using it with SourceForge). You should also not use the free version of BitKeeper because of its restrictions.
Other systems are nicer than CVS and provide a better working experience. When I work in CVS, I always take a long time to think where to place a file or how to name it, because I know I cannot rename it later, without breaking history. This is no problem in other vect in which I was involved decided to rename their directories and split the entire project history.
And you certainly have a lot of choice.
An item-by-item comparison of these systems can be found at the Better SCM Site. Rick Moen has a list of Version Control and SCMs for Linux on his web site. Finally, the DMOZ Configuration Management Tools directory provides many other useful links.
Finally, more information about version control systems and configuration management tools can be found in the comp.software.config-mgmt FAQs page.
Autoconfiscating Amd Automatic Software Configuration of the Berkeley Automounter -- a very interesting paper.
Process Improvement -- slides
Wilma is a suite of CGI scripts that allows you to easily manage a list of items (broken into discrete categories) on the Web. With Wilma, you can make lists of bookmarks, resources, reviews, classified ads, 'what's new' lists, bulletin boards and much more. Anything that needs to be indexed and easily maintained is a good candidate for Wilma.
Version 1.xMN of Wilma is independent of the original distribution by E-doc. It is free for non-commercial use (i.e., as long as you don't make money off it-- see the license), and requires
Perl 5on a Unix machine.
Wilma is extremely flexible. You can have a public submission facility, to allow anyone to add resources, or you can password protect it
(with .htaccess)to restrict access to selected people; in this way, you can manage lists of meeting minutes, job offerings or items for sale. You can even use Wilma (or several Wilmas) to manage an entire site's index. By keeping control over the organization of a site with Wilma while allowing people to add and update pages at will, you can take the headache out of Intranet management.
The most current version of Wilma is 1.36MN, which includes bugfixes and several new features. It's probably a good idea to read some documentation first. Wilma is available in a tarred, gzipped archive. To unpack it, move it to the desired directory and type$ gzip -d wilma1.36.tar.gz $ tar -xvf wilma1.36.tar
I'd love to hear what you think of my version of Wilma; drop me a line!
About this Version
This version of Wilma is by Mark Nottingham, and is unsupported by E-doc. While there have been many enhancements, none of it would be possible without their generous contribution of the original software to the 'net. Thanks, Andrew and Daniel! Support queries and bug reports should go to Mark Nottingham. Please check the FAQ before mailing. If you're upgrading from a previous version, you'll find that changing to this version only requires entering your values to the new wilma.conf file, as well as copying your data directory over. Please pay attention to the license information found in the docs/ directory, as use of this software implies responsibilities to the current author, as well as the original authors. Enjoy!
Softpanorama hot topic of the month
Configuration Management Tools Summary -- overview of free tools
Configuration Management: RCS, CVS, etc.
Although, or perhaps because, I quit my first real job (at a quickly defunct startup company called Enfoprise, building "business workstations") on the first day because they had changed my job assignment from UNIX driver writing to "Systems Integration", I have had a longstanding love/hate relationship with configuration management tools like SCCS and RCS.
My first published paper was "Boxes, Links, and Parallel Trees: Elements of a Configuration Management System" in the first USEnix Workshop on Software Management. In this I described a centralized RCS database, with multiple "views" and hardlink cloning to save space and time, as used by Gould Computer Systems Division's UNIX team.
Dissed by CVS
Brian Berliner (who preceded me at Gould, before he left for Prisma) deprecates my approach in one of the CVS papers, mainly because he advocates an optimistic concurrency control approach, whereas he thought that I advocated locking. Actually, I advocate optimistic concurrency control, but I also advocate locking in case the optimistic version gets into livelock; and, I usually insist that there be a single, identified, serial schedule of source code checkins so that testing can proceed in a linear manner. I require programmers to test that their new code works in a system with all previous fixes applied. (Although I recognize that even this requirement can be relaxed.) I am amused that locking has slowly been creeping back into CVS.
Bug#280395 ITP libvcs-lite-perl -- Minimal version control system
Package: wnpp Severity: wishlist * Package name : libvcs-lite-perl Version : 0.05 Upstream Author : Ivor Williams <email@example.com> * URL : http://search.cpan.org/dist/VCS-Lite/ * License : Dual GPL/Artistic Description : Minimal version control system This module provides the functions normally associated with a version control system, but without needing or implementing a version control system. Applications include wikis, document management systems and configuration management. . It makes use of the module Algorithm::Diff. It provides the facility for basic diffing, patching and merging. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (10, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15
CVSweb (Henner Zeller version) - CVSweb is a perl script that uses RCS commands to give a web interface to CVS. Allows browsing of source code looking for revision, tags, and releases.
perl.com Distributed Version Control with svk
rcsfreeze.pl is a perl script to freeze a configuration of sources checked in under RCS. This perl script is a complete rewrite (with some nice enhancements) of the rcsfreeze.sh shell script contained in the RCS package.
Infrastructure A Prerequisite for Effective Security
A software construction system: http://www.telerama.com/~bgarcia/cons/
CONS is a Perl5-based replacement for MAKE, though it is not compatible with make. Reportedly, it has a number of capabilities not found in other software construction systems, including make. CONS is distributed under a license similar to the BSD license.
Creating multiple, identical copies of a system can be hard work; it becomes even harder if patches and diffs need to be maintained. Multiply this by hundreds of computers ... and Unix sysadmins go crazy. The Working Version company has created a system version control and distribution mechanism to manage entire installed system versions.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017