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 :)
(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.
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.
ekacnet, could you please look at what still needs to be done?
Fix pushed to autobuild.
This has been fixed.