Client Development

[jcoffland]

Hello. This is a discussion thread for development of the client and web front end and pre-alpha release discussions.

The latest bleeding edge builds can now be download from https://master.foldingathome.org/builds/fah-client/

@kbernhagen, @Hou5e, @marcosfrm

[jcoffland]

Has anyone tested accounts and remotes with v8.3.x on windows? And on which browsers?

[Hou5e]

I compiled from source on (4) Linux Mint 21.1 (Ubuntu 22.04) PCs today and did update installs on top of existing FAH v8.2.4. I've only tested with Firefox, so far. I could log-out and log into my account. I can't access any of my PCs remotely but they show up in the list (since it was introduced in FAH v8.2. My account: https://stats.foldingathome.org/donor/id/245474 might need to be fixed or something). I also get this error for each startup: #178

[jcoffland]

Do you get the #178 error with ARM Linux or something else?

[marcosfrm]

systemd has tons of hardening options. Evaluate add a few to our Linux service file for paranoia:

https://docs.arbitrary.ch/security/systemd.html

Some options are supported since ages (PrivateTmp= and NoNewPrivileges= for example), others require recent versions.

[jcoffland]

This would be a good thing to open an issue for.

[marcosfrm]

ca-certificates dependency in DEB package is indeed necessary. fah-client will static link libssl.a and libcrypto.a provided by libssl-dev and Debian only pulls it in weakly (Suggests) via openssl package (not via libssl1.1/libssl3). Minimal installs thus can lack ca-certificates.

On Fedora/RHEL, openssl-libs requires ca-certificates. Hence linking system OpenSSL guarantees ca-certificates is present. See #153 (comment) for a viable approach (static libraries are not provided anymore there).

[marcosfrm]

When possible I think fah-client should link system core libraries. zlib and bzip2 are good candidates, as their ABI is not going break soon (or ever). Installing zlib1g-dev and libbz2-dev on Debian 12 results in:

Depends: ca-certificates, libbz2-1.0, libc6 (>= 2.36), libsystemd0 (>= 222), zlib1g (>= 1:1.1.4)

And zlib-devel and bzip2-devel on CentOS Stream 8:

$ rpm -q --requires fah-client
...
libbz2.so.1()(64bit)
...
libz.so.1()(64bit)
...

Symbol versioning was added in zlib 1.2.0 (2006) and DEB/RPM will make use of it. libbz2 does not have it, but its API is frozen for a long time (two decades?) anyway.

Requires CauldronDevelopmentLLC/cbang@5e4dfec.

[marcosfrm]

Investigate whether setting core's scheduling policy to SCHED_BATCH on Linux (keeping nice level at 19) is beneficial.

https://man7.org/linux/man-pages/man7/sched.7.html
https://man7.org/linux/man-pages/man2/sched_setscheduler.2.html

SCHED_BATCH is Linux-specific. Requires _GNU_SOURCE, which is always defined by g++ and clang++ on Linux I think.

Test patch for cbang:

diff --git a/src/cbang/os/SystemUtilities.cpp b/src/cbang/os/SystemUtilities.cpp
index e66ca262..79e09636 100644
--- a/src/cbang/os/SystemUtilities.cpp
+++ b/src/cbang/os/SystemUtilities.cpp
@@ -81,6 +81,10 @@
 #include <mach-o/dyld.h>
 #endif // __APPLE__
 
+#ifdef __linux__
+#include <sched.h>
+#endif // __linux__
+
 #include <sstream>
 #include <fstream>
 #include <iomanip>
@@ -859,6 +863,13 @@ namespace cb {
 
       if (SysError::get())
         THROW("Failed to set process priority: " << SysError());
+
+#if defined(__linux__) && defined(SCHED_BATCH)
+      struct sched_param sp = {0};
+
+      if (priority == ProcessPriority::PRIORITY_IDLE)
+        sched_setscheduler((pid_t)pid, SCHED_BATCH, &sp);
+#endif
 #endif
     }
 

[marcosfrm]

Implemented with SCHED_IDLE instead:

CauldronDevelopmentLLC/cbang@da4890c

See discussion at CauldronDevelopmentLLC/cbang#171 .

[marcosfrm]

What do you think about adding the following to the compilation instructions to compile a specific version?

Get the code

git clone https://github.com/cauldrondevelopmentllc/cbang
git clone https://github.com/foldingathome/fah-client-bastet
git clone https://github.com/foldingathome/fah-web-client-bastet

Optionally, if you want a specific version:

pushd cbang ; git checkout bastet-v<version> ; popd
pushd fah-client-bastet ; git checkout v<version> ; popd
pushd fah-web-client-bastet ; git checkout v<version> ; popd

Maybe repeat "Where <version> is the software version number.".

[jcoffland]

Done

[marcosfrm]

Nice. You forgot the instructions for creating the RPM package -- note that fah-web-client-bastet is purposely absent there.

[jcoffland]

I haven't created any RPMs for v8. Can you submit a PR?

[marcosfrm]

Done: #279.

[marcosfrm]

If /etc/fahclient/config.xml (v7) exists and /etc/fah-client/config.xml (v8) does not, the DEB package always copies the former to the latter on initial installation and on subsequent updates of the v8 package. The RPM, on the other hand, only does this on initial install.

I want to unify this behavior. I think importing only on initial install is better, as the contract I envision is "okay, here's your old configuration, from now on it's up to you".

What do you all think?

[jcoffland]

Yes, that makes sense as long as it's not overly complicated to implement.

[marcosfrm]

The working units use cbang to load the GPU compute libraries, right? If they could be recompiled with commits

CauldronDevelopmentLLC/cbang@e890707
CauldronDevelopmentLLC/cbang@e5c0fa9
CauldronDevelopmentLLC/cbang@9908fa9

backported, it would be of great help, as it would simplify the instructions on which packages need to be installed on Linux distributions, without relying on development packages.

[jcoffland]

I guess by, "working units" you mean the cores. It's unlikely they will be rebuilt.

[marcosfrm]

Yeah, that's what I suspected. Let's hope that future cores have these changes applied...

[jcoffland]

I'm going to build a new GROMACS core soon. It will use the latest C!. The OpenMM guys seem to be updating C! with each core release.