Bug 8504 - Integrate "findprovisionusnranges" into "upgradeprovision"
Integrate "findprovisionusnranges" into "upgradeprovision"
Status: RESOLVED FIXED
Product: Samba 4.0
Classification: Unclassified
Component: Tools
unspecified
All All
: P5 minor
: ---
Assigned To: Matthieu Patou
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-29 17:24 UTC by Christoph Theis
Modified: 2012-03-27 14:47 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Theis 2011-09-29 17:24:51 UTC
During the upgrade process to alpha 17 (from maybe alpha 15, but the original installation is much older) I came across some small glitches, most of them outdated or wrong documentation

The file "upgrading-samba4.txt" says
  * Go into the source4 dir
  * do make install
but "make install" can be called only from the root dir, only here we have the Makefile

"make install" did not completely replace my binaries, some from the old installation remained. Is there a way to uninstall the binaries only? I remember something like "make uninstall-bin" from previous versions.
This mess with old and new files created problems when running "samba-tool dbcheck" of the next step: it found files from alpha 15 and refused to work.

In the end I called "make uninstall", removed the non-binary directories (bin, sbin, modules, lib and includes) and installed again. Fortunately that step kept my database :) Is it safe to assume that "make uninstall" will keep the private files intact? I would feel safer if I could uninstall everything but keeping my data and have a clean installation after than to not know if some old file is still somewhere, waiting to cause trouble ...

The next step should be "run samba-tool dbcheck". samba-tool is not installed and is located in the bin/ directory. So either it shall be installed or the command shall be "bin/samba-tool dbcheck"

samba-tool offers to guess the ranges via running bin/findprovisionusnranges
1.) source4/scripting/bin/findprovisionusnranges is not linked to the bin/ directory, so doing this will fail.

2.) findprovisionusnranges calls python "directly", that is, with "#!/usr/bin/python". Of course, under FreeBSD python is located under /usr/local/bin. All (or most) other scripts take care of this and call python via "#!/usr/bin/env python", the remaining scripts shall do this, too.


I could workaround through those bugs and the new installation is working well without problems so far :)
Comment 1 Matthias Dieter Wallnöfer 2011-09-30 13:44:16 UTC
(In reply to comment #0)
> During the upgrade process to alpha 17 (from maybe alpha 15, but the original
> installation is much older) I came across some small glitches, most of them
> outdated or wrong documentation
> 
> The file "upgrading-samba4.txt" says
>   * Go into the source4 dir
>   * do make install
> but "make install" can be called only from the root dir, only here we have the
> Makefile

Okay, I will write a correction.

> 
> "make install" did not completely replace my binaries, some from the old
> installation remained. Is there a way to uninstall the binaries only? I
> remember something like "make uninstall-bin" from previous versions.
> This mess with old and new files created problems when running "samba-tool
> dbcheck" of the next step: it found files from alpha 15 and refused to work.
> 
> In the end I called "make uninstall", removed the non-binary directories (bin,
> sbin, modules, lib and includes) and installed again. Fortunately that step
> kept my database :) Is it safe to assume that "make uninstall" will keep the
> private files intact? I would feel safer if I could uninstall everything but
> keeping my data and have a clean installation after than to not know if some
> old file is still somewhere, waiting to cause trouble ...

Well, "make uninstall" is the suggested way. At the moment we hadn't much focus regarding changing names of modules/binaries between alpha releases (keep in mind they are still alpha!).
In the future we will pay more attention on keeping denominations consistent. Andrew, do you have something to add?

> 
> The next step should be "run samba-tool dbcheck". samba-tool is not installed
> and is located in the bin/ directory. So either it shall be installed or the
> command shall be "bin/samba-tool dbcheck"

Okay, this can be fixed as well.

> 
> samba-tool offers to guess the ranges via running bin/findprovisionusnranges
> 1.) source4/scripting/bin/findprovisionusnranges is not linked to the bin/
> directory, so doing this will fail. 

Also this can be fixed.

>
> 2.) findprovisionusnranges calls python "directly", that is, with
> "#!/usr/bin/python". Of course, under FreeBSD python is located under
> /usr/local/bin. All (or most) other scripts take care of this and call python
> via "#!/usr/bin/env python", the remaining scripts shall do this, too.

Also this can be fixed.

> 
> I could workaround through those bugs and the new installation is working well
> without problems so far :)

No, it is perfectly fine for us to get such issues reported as well.
Comment 2 Matthias Dieter Wallnöfer 2011-10-08 08:59:10 UTC
Two patches (case 1 + 5) which fix issues described here will be committed soon. Case 4 requires a more complete solution ("findprovisionusnranges") which will be worked out by Matthieu Patou.
Comment 3 Matthias Dieter Wallnöfer 2012-03-15 09:09:12 UTC
ekacnet, could you please look at what still needs to be done?
Comment 4 Matthieu Patou 2012-03-17 07:19:56 UTC
Fix pushed to autobuild.
Comment 5 Matthias Dieter Wallnöfer 2012-03-27 14:47:42 UTC
This has been fixed.