On 5/15/2016 7:44 PM, Karl-Philipp Richter wrote: > Am 15.05.2016 um 20:15 schrieb Benjamin Kaduk: >> There are some errors early on about "failed to restart bosserver (you are >> not authorized for this operation)" that make me wonder if travis is doing >> something with users and permissions that is destined to fail. > According to > http://stackoverflow.com/questions/29043709/is-it-possible-to-use-linux-bridges-on-travis-ci > travis doesn't support kernel module loading.
The openafs kernel module not only is necessary to perform the steps that require file access to /afs/your-cell-name.com/ but it also provides the pioctl support necessary to store and retrieve afs tokens for use by the bos, pts, and vos commands. > The post recommends > wercker.com on which the script fails with `kinit: Cannot contact any > KDC for realm 'test' while getting initial credentials` which I had > figured out once, but issues are harder to investigate on web CI > services. Having a working Kerberos realm is a precursor requirement to an OpenAFS deployment. There is little point in working on automated scripting of the OpenAFS pieces until automated scripting for Kerberos is in place. One of the challenges of Kerberos in an isolated continuous is that Kerberos is dependent upon working DNS for the associated domain and IP addresses. While it would be possible to forge AFS impersonation tokens and bypass the Kerberos requirement, the resulting scripts would not mirror the instructions provided in a quick start guide for administrators. > Thus, I'd like to get feedback how much sense you think this > script (assume it'll be working one day) makes. I can't figure out so > many failures because neither did I get AFS running ever nor am I a > kerberos admin. I'd be willing to proceed from failure to failure until > it works one day if you support me. Any and all automated testing of OpenAFS is beneficial. However, there are definitely limitations to what is possible using OpenAFS as it exists today. As Marc Dionne described at the end of his presentation on the Docker based continuous integration testing environment that AuriStor, Inc. constructed http://workshop.openafs.org/afsbpw15/talks/friday/dionne-docker.pdf for AuriStorFS, there were many changes necessary to the service startup logic to ensure reliable starting of cells when all of the servers were started at once. In addition, AuriStorFS also has many changes to avoid the dependency on a kernel module for administrative tasks and the execution of service processes as "root". While it would be possible to write a script that performs all of the OpenAFS administrative tasks using the -localauth option it won't be possible to test the resulting setup using normal methods of authentication. > My motivation is to get AFS working (for years now with interruptions) > and given the many issues I experienced a reference implementation of > installation instructions seems to make sense for me. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
