Package/Download questions

Using FoundationDB
1

Hey there, I’m getting things moving on our CI infrastructure for FoundationDB at Apache CouchDB.

Our primary build platform is Debian, so we’re OK there with the Ubuntu packages.

For our full platform matrix, we have a couple of holes:

  • There’s no RHEL/CentOS EL8 package. Can we use the EL7 package successfully? I notice it has a hard-coded dependency on /usr/bin/python (does this mean it expects/requires 2.x?) and EL8 does not create a /usr/bin/python link if you install python3 (which is all we need for our build process…) I didn’t try installing python2 yet.
  • FreeBSD, I’ll work with @dch on. Looks like he’s put 6.1.8 into ports, but the -devel package is already updated to 7.0.0.a which is possibly too aggressive for us.
  • Other Linuxes - there are binary downloads available for the server, and for the client dynamic library, but not for the headers, so we can’t build our Erlang driver with these. Could these be added to the C language binding downloads, or in a separate package? Initially I was going to have our build process use this route instead of the distro-specific packages, but I don’t see a path forward just yet.
  • Windows hasn’t been started on yet. Are there options for the MSI to install both the client and the server non-interactively using msiexec?
2

I had replied on dev@couchdb.apache.org about this. The EL7 package will work on centos8. (As tested by Ronny in the CouchDB community. Thanks again!). The python dependency was an accident, and will be removed in whatever next release we publish that’s >6.2.15 (which is mostly whenever the TLS rewrite is finally stabilized).

I’ve already pinged him out of line about our 7.0 release cut being about a month out. I’ve also offered to help out with that port if some extra effort is needed to make sure it makes the cut. There’s more conversations that we should have about if FreeBSD is to be marked as a stable/supported platform, what sort of qualification testing needs to be done, and what ongoing testing is required, but all of that is gated on having FDB building on FreeBSD anyway.

This… is indeed an oversight, and a completely reasonable request. I’ve filed Publish fdb_c headers as a downloadable build artifact #2880 to track this.

Maybe @KrzysFR has advice on the best way to package up an FDB for auto installation on windows? :slight_smile:

3

If my memory is correct, there was no real difficulty in auto installing FDB on Windows, simply use the regular mechanism for unattended install: msiexec path/to/foo.msi /qn. The only difficulty we had was that by default it runs create new single memory which is not what we wanted. We simply modified the MSI to run create new single ssd instead by decompiling, patching, and rebuilding the MSI whenever a new version was released.

There are a few things that are not great with the current Windows MSI:

  • It is not signed, so Windows will by default show a popup asking to confirm the installation of unsigned binary from an unknown vendor which is kinda scary (also may be forbidden by policy on some systems). The MSI would need to be signed by a valid authenticode key. It would be best if Apple could use its own key which is used to sign other Windows binaries (iCloud, iTunes for windows, etc…). I don’t think you have to sign all binaries, but at least the MSI. **
  • It automatically runs “configure new single memory” and there is no way to prevent it from doing it (except by patching the MSI like we did but that defeats the authenticode signing!)
  • If you want to update an existing server, you have to manually stop the fdbmonitor service before running the MSI, or else it will want to restart the server. The MSI does not attempt to stop the service by itself so all the files are locked and the default fallback behavior is to reboot the server. This makes a 30sec update take several minutes if a pending Windows Update is looming in the shadows :slight_smile:

**: note that we had issues with some Windows Servers that don’t have access to internet (null routed) that will timeout when checking a certificate if they were not able to re-validate the Certificate Trust List with Microsoft’s CDN for some time. This timeout is long and sometimes creates cascading issue during starting of services. Solution is either to let the server talk with Microsoft CDN (akamai) or dowload and install the CTL on the server.

Of course there’s always the possibility of installing the service and client binaries yourselves as part of your own setup… It could be fine as long as nobody tries to install fdb using the official binary on the same server (possible collision on the fdbmonitor service name).

1 Like
4

Hey everyone, thanks for replies.

I had replied on dev@ about this.The EL7 package will work on centos8. (As tested by Ronny in the CouchDB community. Thanks again!).

Ah, I overlooked this thread! Thanks for the pointer. Sorry to re-discover this.

The python dependency was an accident, and will be removed in whatever next release we publish that’s >6.2.15 (which is mostly whenever the TLS rewrite is finally stabilized).

Awesome. How far off is that? Will it just be 7.0? I don’t want to work around the python dependency if I can avoid it, since we worked extra hard to get all Python 2.x dependencies out of our environment. We’re not in a rush to fix our broad builds yet, so we can wait.

FreeBSD

Cool, I’ll poke him about it as well.

This… is indeed an oversight, and a completely reasonable request.

Awesome, thanks! This will open the door to us supporting things like Arch Linux, etc. which have long been requested.

If my memory is correct, there was no real difficulty in auto installing FDB on Windows, simply use the regular mechanism for unattended install: msiexec path/to/foo.msi /qn .

How do you select whether you want client/server/bindings installed? Usually there’s MSI variables for this stuff. Here’s example from our package: GitHub - apache/couchdb-glazier: Glazier is a set of batch files, scripts and toolchains designed to ease building CouchDB on Windows. Fortunately right now the defaults are the options we need.

However, when we build our own installer, we will need to rip the MSI apart anyway - because you can’t directly embed one MSI into another MSI. (Or, we just tell people “You have to install FoundationDB first” and wimp out. Heh.)

It is not signed

We sign our MSI so that at least gets around that problem, but we’ll have to do the embedding workj.

It automatically runs “configure new single memory”

How did you patch this?

If you want to update an existing server, you have to manually stop the fdbmonitor service before running the MSI, or else it will want to restart the server. The MSI does not attempt to stop the service by itself so all the files are locked and the default fallback behavior is to reboot the server.

The CouchDB MSI stops our processes before updating. Here’s the logic if it’ll help:

5

I’ve asked around, and it appears the few minor TLS bugs are the only thing stopping us from cutting a 6.2.20 that would be publicly releasable. I’ll try to get those finished early next week, so that we can hopefully get a new set of packages published, and those would drop the python dependency.

Until then, you should also be able to just do rpm -i --force instead, if you’re willing to temporarily live with that workaround.

I’m actually not sure why we default to the memory engine. I feel like this has just caused more trouble for people due to --storage_memory defaulting to 1GB. Maybe we should also open the discussion of having packages default to configure single new ssd for 6.3 and onwards…

6

I believe the rationale at the time was that we wanted it to work well enough for anyone who installed the packages locally to try out, and we didn’t want people with spinning drives to have a bad first experience. I agree though, that the memory limit seems to have resulted in a different unpleasantness for a lot of people, so that tradeoff isn’t quite so clear cut.

7

Until then, you should also be able to just do rpm -i --force instead, if you’re willing to temporarily live with that workaround.

Perfect. I was nervous to do that until I was sure it didn’t actually need Python at /usr/bin/python. I’ll do this right away.

8 
# wget -q https://www.foundationdb.org/downloads/6.2.15/rhel7/installers/foundationdb-server-6.2.15-1.el7.x86_64.rpm
# wget -q https://www.foundationdb.org/downloads/6.2.15/rhel7/installers/foundationdb-clients-6.2.15-1.el7.x86_64.rpm
# rpm -i --force ./foundationdb*
error: Failed dependencies:
        /usr/bin/python is needed by foundationdb-server-6.2.15-1.el7.x86_64

I tried again with rpm -i --nodeps. The install then completes, but I get these errors:

[root@host] # rpm -i --nodeps ./foundationdb*
tr: write error: Broken pipe
tr: write error
tr: write error: Broken pipe
tr: write error
[root@host] # echo $?
0

Note: I don’t get these on EL7. I don’t know if these are a problem.

[ETA: Opened as a ticket.]

9

@wohali , 6.2.20 is finally live on the downloads page, and should install cleanly without the /usr/bin/python dependency on EL8. (But again due to not having a convenient centos8 image, it’s hard for me to test, so please let me know if it doesn’t.)

10

Looking good! There’s still these weird errors on install:

[root@d38613b45ce8 /]# rpm -i --nodeps ./foundationdb*rpm
tr: write error: Broken pipe
tr: write error
tr: write error: Broken pipe
tr: write error
[root@d38613b45ce8 /]#

but I can confirm it installs now without python at /usr/bin/python. Thank you!