Kolab update

[Jeffrey Walls]

Last night I finally did the update to current (11/08/2004).  Here are some 
thoughts on the update, for what they are worth to the developers.  

The update went almost flawlessly. By almost, I mean it couldn't find some 
files, however I stopped the update, downloaded the files to local disk and 
continued on.  No errors other then that.  I have had that problem on and off 
before, where I had to download the src.rpm's, and other times, openpkg 
ignored the current packages on my local drive and downloaded anyway.  
Inconvienient, but not terrible.

So all goes well, I restart kolab, and try to do a kolabconf.  LDAP errors. I 
go to the kolab webadmin page. Unable to bind to LDAP.  Needless to say, some 
words were spoken.

I stopped and restarted.  Checked for running processes. Still nothing. I 
checked the openldap.log file.  Nothing noticable. 

I finally decided I had to do what I dreaded doing, attempting to backup and 
restore the LDAP database, and the Cyrus mailbox.db.  I followed the 
instructions Steven gave me.  Have to be Cyrus admin to run ctl_mboxlist.  I 
tried manager. Nope. Can't write to this directory. Can't read mailbox.db. I 
finally (10:30 pm) got it to work using the kolab user and writing to /temp.  

I did the bootstrap.  I just KNEW I was gonna loose my users mail.  I started 
kolab, checked the web admin page.  No users. Went out and use slapadd. 
Looked good. Web admin page. No users.  Did it again. No users. checked the 
man page.  LDAP needs to be off.  Ok. shut down and try again.  Restart and 
still no users. Ok, an error line 12 of the slapcat dump file.  Ok, its the 
kolab dataname.  Reread slapadd man page. Use -c to ignore errors. Do slapadd 
again. Restart kolab. HOT DAMN I HAVE USERS.

Now, the most important part.  The mailboxes.  Will I have a bunch of VERY 
unhappy users in the morning?

Reread the ctl_mboxlist man page.  OK, got it.  Dump the dump file back into 
Cyrus.  Look at my mail program.  I can recieve, no errors.  I send a file to 
my business account from my home account. It's THERE. Hot damn.

All in all, 4 hours to do an upgrade from the 9/28/2004 version.

My feelings?

1. No upgrade should EVER put you in a position of loosing your data. EVER.
2. The kolab update should ALWAYS backup whatever data may be lost. ALWAYS.
3. The kolab update should check your data AFTER the update.
4. I spent a lot of time diggin through man pages and experimenting. This 
procedure MUST be documented. In SIMPLE terms, in excruciating detail. Assume 
NOTHING. I couldn't replicate what I did again, without spending hours 
researching. Again. 

The worst part of this whole thing was not the time spent.  It was the feeling 
of helplessness at 10:30 pm US time, knowing the developers were not 
available.  And having to show up in the morning and explain how I lost 
everybodies email messages, and not knowing I if I could recover them. I 
still believe this package is great, BUT.............

Until you document it, for users and admins
Until you make it as bombproof as possible
Until you answer ALL questions presented (including "We Don't Know" as an 
answer, not responding to questions asked is a BIG problem here)

This project will suffer.  In my opinion.

Many of us fight against proprietary software in our businesses every day, but 
things like this make it hard for us to justify open source.

Sorry for the rant.  I STILL support and will use Kolab.

I hope this will help in some little way.

On Thu November 4 2004 11:21 am, you wrote:
> Just to update, I have been toying with this for the past couple of weeks,
> afraid to try to backup and restore, since I've lost things before.  So I
> looked again at the problem, and did a
>
>  /kolab/libexec/openpkg/rpm -ql gcc-3.4.1-2.1.0 |less
>
> to see if the file (crtbegin) SHOULD be there. It came back that it should.
> So I thought, why not just overlay the gcc again, with the same file?  So I
> did from /kolab/RPM/PKG.
>
> /kolab/libexec/openpkg/rpm -Uvh --force gcc-3.4.1-2.1.0.ix86-rhl9-kolab.rpm
>
> then............
>
> ls -la /kolab/lib/gcc/i686-pc-linux-gnu/3.4.1
>
> and BINGO
>
> -rw-r--r--    1 kolab    kolab        1620 Aug 10 12:31 crtbegin.o
> -rw-r--r--    1 kolab    kolab        2136 Aug 10 12:31 crtbeginS.o
> -rw-r--r--    1 kolab    kolab        2016 Aug 10 12:31 crtbeginT.o
>
> There they are.  So I think I will try to do the update again tonight and
> see what happens.
>
> The people (Windows and KDE) here are getting anxious to get the shared
> calander (to keep track of the outside salesmen) and the shared addressbook
> active, so I want to keep up to date.
>
> On Mon October 25 2004 03:39 pm, Jeffrey Walls wrote:
> > This is overlaying an existing Kolab 2 install from the end of September
> > (09/27?).  The first module is comes to to rebuild and install (it skips
> > over the rest) is pth.  So I assume it is installed correctly from then.
> >
> > On Mon October 25 2004 03:32 pm, Martin Konold wrote:
> > > Am Montag, 25. Oktober 2004 18:29 schrieb Jeffrey Walls:
> > >
> > > Hi,
> > >
> > > > I did a find on crtbegin* and found nothing.
> > >
> > > Did you install the gcc correctly?
> > >
> > > Regards,
> > > -- martin
> > >
> > > "I am committed to helping Ohio deliver its electoral votes to the
> > > President next year."  -- Wally O'Dell - CEO of Diebold, Inc.
> > > e r f r a k o n
> > > Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
> > >
> > > _______________________________________________
> > > Kolab-users mailing list
> > > Kolab-users at kolab.org
> > > https://kolab.org/mailman/listinfo/kolab-users

-- 
Jeffrey Walls
IT Manager 
Brown Transmission and Bearing Co.