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

George Liu George.Liu at noaa.gov
Fri Dec 23 15:02:59 GMT 2005


I use Samba with ldap in a production environment. When I was migrating
from Samba 2 to Samba 3,  it was really hard because of  the major
change of the samba parameters. I hope the hardship will be lessened
when I migrate samba 3 to 4. 



Steve Williams wrote:

> 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