Using kmod's are fine, but dkms can be easier when upgrading kernels.
To use the dkms rpm, add the epel repo, remove the kmod's, and run
"sudo yum dkms openafs-dkms"
dkms automatically compiles the needed openafs kernel module when
the kernel is upgraded.
dkms is fine as long as you don't care about reproducibility. But
allowing each machine to build its own kernel at an unpredictable
moment significantly increases the number of variables you have to
deal with when debugging large installations. For example - how do you
know which tool chain a given kernel module was built with? How can
you be sure that a module was built correctly, if just one machine is
experiencing problems? And so on ...
For systems where you need to know exactly what's being run, there are
definite benefits to shipping binary modules to the clients. We don't
ship kmods because we're bored :)
On that note, I should probably apologise for the lack of new kmods
over the holidays. We're experiencing cooling issues in the machine
room where the build host is situated, and it's one of the machines
that has been shut down to reduce the thermal load.
Cheers,
Simon.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
