search for: oeminform

I was too quick to send my previous email. It can't really be a problem of the package since I have, as mentioned, another system with the exact same setup and the exact same package versions and it all works there... On Sun, 23 Dec 2018 at 11:18, Viktor Trojanovic <viktor at troja.ch> wrote: > Yes, I tried running dbcheck (see first email), it showed 0 errors from > the start, I

The two systems I'm referring to are on different domains, different locations. No connection whatsoever except me being the one administering both. According to oEMInformation the server was provisioned by 4.3.3. I just checked the Samba log file and it seems that version 4.7.4 was running before the update. I'm now looking at the logs right before the upgrade and indeed, there have been errors so it looks like we found the reason for my issues. As a matter of...

...y to repair it? Thanks. On Sun, 23 Dec 2018 at 13:12, Viktor Trojanovic <viktor at troja.ch> wrote: > The two systems I'm referring to are on different domains, different > locations. No connection whatsoever except me being the one administering > both. > > According to oEMInformation the server was provisioned by 4.3.3. I just > checked the Samba log file and it seems that version 4.7.4 was running > before the update. > > I'm now looking at the logs right before the upgrade and indeed, there > have been errors so it looks like we found the reason for my...

...t before and big inplace upgrade is done. Get the patches from : - for example from site. - from server and show patches from "detected" version of the provisioning. - special patch supplied by sernet if you have a sernet subscription. We can use the data which already there. Like : oEMInformation: Provisioned by SAMBA 4.1.17-SerNet-Debian-10.wheezy So if all we need here is, show database upgrades as of version X.y.x And apply the upgrades in the correct order. If upgrade is done, tag/add a new field to the server it own AD record and add field upgraded-to (X.Y.Z). I really think t...