next message in archive
next message in thread
previous message in archive
Index of Subjects
I'd like to welcome the new readers... ;-) For those who may have been startled by the subject line, you can still go camping this week-end we're in the planning stage. I've moved this to csuite-tech which should be the home of these discussions... ---- In reply to Jeff's comments below... In fact there have been considerable deliberations about where we should put what... I'll try to lay out a couple of the guiding principles... 1) Wheter it's for demonstration purposes, or an installation that will become a production CSuite server at some time in the future... we have to expect that CSuite may/will be installed on an already functioning system which is currently using some/all of the systems/packages included in the CSuite install... GP#1 we don't want to muck up somebody's perfectly good system! (if we can help it...;-) As a result our mailer, httpd, ftpd, etc are installed under CS_ROOT... UNLESS this 'guiding principal' is overturned, all CSuite files will still go under CS_ROOT 2) Although Linux (and currently Redhat) is the primary OS development package we want to ensure that CSuite can be installed and setup under Solaris and other OS's. We started out with Debian Linux and we could switch again if reason presents itself. We don't want to get caught up with thinking that Redhat and it's locations are our only target. ----- Now... this makes some things harder but it also makes cross-platform things easier. At least we know where we put them. The original discussions with respect to zmailer's location on our systems can be somewhat removed from CSuite. We will soon be operating 6 machines with CSuite including the grandfather system (non conforming data files, etc.) and _we_ need a level of consistency between our systems that may not be as important to other sites... it really slows down the work when you move from system to system and have to keep looking to find out where we've hidden zmailer this time... david potter On Wed, 2 Jun 1999, Jeff Warnica wrote: > > I supose my point is, apache, zmailer and other things we dont mess with the > source in arent realy csuite. Functionality additions and (more importantly) > bug fixes will hapen indepent of us, lets not worry about them. > > > > > John Nemeth has already been upgrading some of CSuite functions so I've > > included him on the discussion. The CVS tree will have to be included in > > any changes to CSuite source and relocation of files. > > > > On Wed, 2 Jun 1999, Jeff Warnica wrote: > > > > > I think for the new server (since it will likely be a fork in the csuite > > > developement, anyway) and even potential for v1.1 we should > > move all of the > > > apps that are not actuay csuite apps to where they think they > > should go, and > > > move all there confi files from CS_ROOT/etc to [root]/etc > > > > > > Then when people want to do a zmailer upgrade they just do a > > > > > > rpm -u zmailer-NNNN > > > > > > It might be slightly tramitic to move (other peoples) stuff out > > of CS_ROOT > > > but once it is done, then its done. Upgrading zmailer is a matter of > > > following the zmailer uppgrade instructions. Upgrading apache > > is a matter of > > > following the apache upgrade instructions. > > > > > > True, if its an upgrade from source there wont be a difference, but with > > > RPMs all over the place, why are we making work for ourselves (and other > > > csuite admins) by esentialy forcing them to do from source upgrades? > > > > > > Unless we are playing around with .c's then there $someone_else > > problem, and > > > there install files should go where $someone_else thinks they shold go. > > > > > > > Assuming this is also related to the soon to be CSuite v1.1 .... > > > > > > > > There are at least 2 very different upgrade paths... which can > > > > probably be characterized as involving either a `make all`, or a `make > > > > install`. > > > > > > > > The ability to 'back-out' of a upgrade is affected by whether an > > > > application utilizes binary/configuration files scattered in various > > > > directories, or whether the files are contained within a > > single directory > > > > (structure). > > > > > > > > As an example the mgetty `make install` will update a variety > > of files, > > > > overwriting the previous contents... (very much more difficult to back > > > > out... ;-( > > > > > > > > --- > > > > > > > > Backing out is harder/difficult (almost impossible) if we > > don't know what > > > > was modified. This suggests we need to document the install > > > > process for each > > > > application. > > > > > > > > In the past we have, on ocassion (and for self-contained > > applications), > > > > built the new version in it's own directory and then used > > some method to > > > > swap to the new version without loosing the previous... > > > > > > > > Something like... > > > > > > > > - make_new_directory zmailer-2.99.50s18 > > > > - make (compile) zmailer > > > > - copy all the associated files (aliases, etc.) to the new directory > > > > structure > > > > - kill zmailer > > > > - move zmailer/ zmailer_old && move zmailer-2.99.50s18/ zmailer > > > > - start zmailer > > > > > > > > We could also move the old zmailer out of the way (after > > killing it) and > > > > replacing it by creating a symbolic link pointing to the new version. > > > > The nifty thing about a symbolic link is that it's easy to > > switch it back > > > > if necessary. > > > > > > > > We should remember that sometimes the new application appears to work > > > > fine for several hours/days before we discover that we have to switch > > > > back. Any upgrade system should allow that... > > > > > > > > --- > > > > > > > > Maybe we need to start using a > > CS_ROOT/upgrade/program_name-version.number > > > > type of system (rather than building new versions in our home > > directories > > > > and moving them over...) > > > > > > > > david pottter > > > > > > > > On Wed, 2 Jun 1999, David Murdoch wrote: > > > > > > > > > On Wed, 2 Jun 1999, Liliane Bassil wrote: > > > > > > > > > > > Is there a process for installing zmailler > > > > > > > > > > > > what dir should zmailler be installed in ? anything specific ? > > > > > > > > > > The question that we should asnwer is "when we are upgrading > > > > packages what >