[cobalt-users] Re: Backups and Restore for Raq

[Tom Ritchford <tom@xxxxxxxxxx>]

"Carrie Bartkowiak" <ravencarrie@xxxxxxxx> writeth:

> > The point is, The backup solutions DOES NOT WORK as it should. its a
> real
> > pain in the a** to create 200 sites and their users and then restore
> their
> > sites even if you knew the sequence in which the sites were created.
> It took
> > us a week to restore 50 site, just think of 200 sites
>
> I think what it is, is that Cobalt's idea of "backing up sites" is
> quite different than what we out here in the real-use world expect it
> to be.
>
> A week to restore 50 sites? Egads. Learn to use the shell tools.

Well, it took me a week to transfer my 80 domains and
it wasn't for lack of knowledge of general shell tools.

Is there a specific set of Cobalt shell tools that I don't
know about?  If so, how would I have learned about them
and not had to bother you lot?


> Other
> than tarring up the sites and subsequently untarring them later (which
> you could write a script to do), it should take you an hour... a few
> at the most... to setup 50 sites and their users.

The tar part is easy.  However, the sites part is not.

If you are referring to cmuImport/cmuExport, the two command
line Cobalt tools I'm aware of, then there are critical
bugs in these tools.

1. if any user has a directory with the same name as the
   user, the backup fails in a bad way:  it sets up all
   the sites and starts them up but does not populate
   any of the actual files after the failure.

   this was Bad News for me because I suddenly had a
   machine running a lot of sites, empty, and no way
   to quickly delete them... so I had quite a few minutes
   of downtime.

   unfortunately, the user was amelia@xxxxxxxxxxx, one
   of the very first sites.

   WORKAROUND:  change a "die" to "warn" in the script.

2. symlinks are not copied, instead the actual file is.

discussion:  this has to do with site numbers not being
  preserved across backups (I just caught the tail end of
  that discussion here) but it's quite dangerous.

  I got into a situation early where I had a symlink loop
  that caused me to run out of disk space by generating an
  infinitely large tar file.

  (I had the symlink loop there for a reason, to workaround
  the known "java applet with multiple virtual domains on
  an IP" problem)

fix:  site numbers need to be fixed.  pending that,
  symlinks should be exported as links, anyway with a
  warning.

workaround:  change the flags to tar in the script.
  make sure that the site numbers are the same.


3. some ownerships are screwed up.

discussion:  I didn't spend any time on this
  issue because I noticed it very late in the process.

fix: assume it's again a site # issue.

workaround:  curse.  realize that group perms are OK
so it's not a problem most of the time.  fix "by hand".


add this, moving the news server (the finnicky
INN which I had not installed), CVS and perforce,
and replacing bad old Jakarta with Resin






> With the shell tools you can...
> create sites (specifying everything... ip addy, features to enable,
> web aliases, etc.)
> create users (and all features to enable/disable, quotas, fp password,
> etc.)
> delete sites
> delete users
> suspend sites and/or users and unsuspend them

there are specific shell tools for this (as opposed to
emacs and /etc/* files)?  I want these!



> As with writing HTML, I am convinced that doing it by hand is the best
> way to make sure it gets done correctly.

True, but only because the tools are lame.

Already there are HTML things that I "can't" do by hand
like those complicated multi-rectangle rollovers you can
do with Fireworks.  It would never be economic for an
individual to take time to make the sections for multiple
revisions "by hand" (yes, I know, we did rollovers this way in
the dawn of time, but people expect far more now...)


I don't see why it's unreasonable to want to be able
to "push a button" and transfer an entire site from
one Raq to another.  It's a purely mechanical task,
there should be no decision-making involved except
for name conflicts, I'd rather do something else
with my time.


Ditto, twice, with backups.

	/t


...electronic a cappella madness <http://volectrix.com>.........
...extreme internet radio        <http://extremeNY.com/radio>...