Upgrade/downgrade procedure [Was: What is blocking a Samba4 Tech Preview?]

Steve Williams steve at celineandsteve.com
Fri Dec 23 14:44:55 GMT 2005


Steve Langasek wrote:

>On Tue, Dec 20, 2005 at 08:01:23AM -0800, Jeremy Allison wrote:
>  
>
>>On Tue, Dec 20, 2005 at 12:55:00AM -0800, Steve Langasek wrote:
>>    
>>
>>>On Mon, Dec 19, 2005 at 03:42:04PM +0100, Steinar H. Gunderson wrote:
>>>      
>>>
>>>>On Mon, Dec 19, 2005 at 03:52:02AM -0800, Steve Langasek wrote:
>>>>        
>>>>
>>>>>>There currently is an upgrade script that reads in a Samba3 smb.conf
>>>>>>file and the various Samba3 TDB files and writes out the appropriate
>>>>>>Samba4 data files. I guess you'd be using these in upgrades. 
>>>>>>            
>>>>>>
>>>>>Ok.  Does the current packaging use this? :-)
>>>>>          
>>>>>
>
>  
>
>>>>No, currently it doesn't. I'm a bit unsure if we really want to make the
>>>>samba4 packages direct upgrades from samba, though (ie. calling them just
>>>>"samba" with a version number of 3.9.something), given that a downgrade would
>>>>be downright impossible... This is definitely your call, though; we could
>>>>probably adjust the packaging to match names more properly (giving direct
>>>>upgrades) if there's a desire for it.
>>>>        
>>>>
>
>  
>
>>>Does having them installed under a different package name make it easier for
>>>the user to downgrade?  Isn't the best-case downgrade process in both cases
>>>going to be "uninstall the samba4 version of the package, manually massage
>>>your config back into a usable state (or restore from backup), and install
>>>the samba3 version"?  If so, I see no reason to not begin supporting direct
>>>upgrades (and debugging them).
>>>      
>>>
>
>  
>
>>As we have something of a code fork in development, it's probably a good
>>idea to keep the Samba4 prefix to make sure that this isn't seen as a
>>seamless upgrade. I don't think it will be.
>>    
>>
>
>I appreciate that this is the situation today, but I don't foresee shipping
>both samba3 and samba4 together in a stable Debian release.  If the eventual
>target is that samba4 will be a direct replacement for samba3, then I
>consider it our responsibility as Debian package maintainers to make it a
>direct, automatic, and seamless replacement by the point we're ready to
>include it in a stable release.  With this goal in mind, it makes sense to
>me that we would want to start working out the bugs in this upgrade path
>sooner rather than later.
>
>Cheers,
>  
>
CC List trimmed!

I have been using Samba in production since the 1.X days.  I am not 
using Samba4 yet.  I have always followed a very simple process to 
handle easily upgrading/downgrading.

When I compile a new release of Samba, I always do a (for example) 
"./configure --prefix=/usr/local/samba-3.0.14a

Then, when I "make install", it gets installed into it's own directory.

Stop the Samba server, copy over the "critical files", (smb.conf, tdb 
files, etc).

All my shell scripts are "generic", pointing to /usr/local/samba.

Simply by changing the symlink around, I can backrev with no problems at 
all!  (please note, this is not a production system!!)

eg:
lrwxrwxrwx   1 root     system           16 Aug 10 14:39 samba -> 
samba-3.0.20pre2
drwxr-xr-x  10 root     system          512 Jun 27 18:07 samba-3.0.14a
drwxr-xr-x  10 root     system          512 Aug 24 01:31 samba-3.0.20p1
drwxr-xr-x  10 root     system          512 Aug 10 13:28 samba-3.0.20pre2

I even have shell scripts "use_new_samba", and "use_old_samba", where 
"use_new_samba" is:
#/bin/sh
kill `cat samba/var/locks/nmbd.pid samba/var/locks/smbd.pid`
sleep 1
kill `cat samba/var/locks/nmbd.pid samba/var/locks/smbd.pid`
sleep 1
ps -ef | grep mbd

rm -f samba
ln -s samba-3.0.20pre2 samba
samba/bin/startsmb

I know that part of the concern is about "Package Naming", but I thought 
I'd throw my 2 cents in "for the record" (email list archives), because 
I have found this to be an amazingly simple way of handling installation 
of releases on a production system while having a VERY simple fall back 
to a "last known working configuration".

When the time comes, I won't hesitate to test drive Samba 4, because I 
know that I can revert (change symlink) very easily.

I hope this finds a happy home in the email archives :-D

Cheers,
Steve W.



More information about the samba-technical mailing list