Re: [OpenAFS] OpenAFS Windows 10 roaming profiles, new path
Am 31.07.2015 um 11:23 schrieb Richter, Michael: I've tried Windows 10 Pro 64bit with OpenAFS 1.7.32. Worked so far. Did you encounter problems? Jeffrey told about some problems. So far no problems... (knocks on wood and crosses fingers) Windows 7 Pro Update to Windows 10 As Jeffrey Altman wrote: at first, AFS didn't work, but after a Repair with the yfs-openafs Installer, I could again access the AFS. The integrated login however still didn't work. After Uninstall and Reinstall (yfs-openafs-en_US-AMD64-1_7_3202.msi), even the integrated-login functionality came back. I am not using Windows as my main system, so I only clicked around a little bit, but even a Thunderbird with Mail-Directory in the AFS and a Firefox-Profile including Cache in the AFS works flawlessly. Oh yes. this is NOT a roaming profile, just an AFS-Share that is mounted and unlocked on login. Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Alternate source of Windows grind all Kerberos
Am 24.08.2016 um 07:35 schrieb Neil Davies: It appears that secure-enpoints web site is broken since, at least, Monday. Anyone know where I can lay my hands on copy of heimsal Kerberos and the network identity manager for Windows? We have a copy on our website, see here: https://itwiki.math.uni-hamburg.de/doku.php/en:user:afs:install#windows (Only for 64-bit Windows, I don't have a copy of the 32-bit files) In recent tests, I found MIT Kerberos to work better for "Single-Sign-On", both putty and firefox (with proper settings) can access the Kerberos-Ticket. I didn't manage to get that to work with Heimdal. Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.8.0 alpha 1 available
Am 29.12.16 um 17:22 schrieb Gaja Sophie Peters on openafs-info@openafs.org: I guess this is more of a "success" story, than a bug, so I'll provide my feedback (little as it may be) here, in case it may be helpful to anybody. [skip the steps for building] - Next I installed with "dpkg -i" the three packages that are needed for a client-install and courageously rebooted - only to find out that AFS wasn't find my home-dir. (All other directories were working fine, except the one above my homedir and my homedir...) - Any combination of "fs flush" "fs flushmount" and "fs flushall" didn't help either, so I manually cleared out the AFS-cache and restarted again. Hm, maybe some kind of "bug-report" after all. Today when I logged in with SSH with a user that has an AFS-Homedirectory, I had the same phenomenon: Could not chdir to home directory /afs/math.uni-hamburg.de/users/it/fmsv030: No such file or directory Possible reason (not sure): The directory /afs/math.uni-hamburg.de/ is readable for system:anyuser - the next subdir /afs/math.uni-hamburg.de/users is readable by system:authuser (but not by "anyuser"), so during login (when my credentials aren't yet known to the system), "root" (or "the kernel") thinks, the directory /afs/math.uni-hamburg.de/users/it" doesn't exist. ls -al shows it at first as ?? ? ?? ?? it and after some experiments with flush/flushmount as d? ? ?? ?? it This state remains even after login. I could solve it one time by using fs flush / fs flushmount / fs flushall as root (not as logged-in user). After that, the directory appeared as normal and a regular SSH-Login now works as well without error. However, after a reboot, I tried to reproduce the "make-the-directory-available-again" without success. However much I "flush"ed, the directory remained unaccessible: $ cd /afs/math.uni-hamburg.de/users/ $ fs lsmount it 'it' is a mount point for volume '#math.uni-hamburg.de:users.it' $ fs listacl it fs: File 'it' doesn't exist When I rebooted and logged in with a non-afs-user, then used kinit / aklog and checked the directory, it was there AND worked afterwards also on login with afs-user... Apologies for the maybe unclear and confused description. As a final test, I made a cross-test and tried the same compile/install routine for openafs 1.6.20-2 and ssh-login worked there the first time (and the second) Greetings (in the hope that any of this may be helpful), Gaja Peters P.S. All this on Ubuntu 14.04 with Kernel 3.13.0-106-generic, compilation of OpenAFS as described in the post https://lists.openafs.org/pipermail/openafs-info/2016-December/041997.html Login(-attempts) were made with kinit / ssh -K ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.8.0 alpha 1 available
Am 14.12.16 um 05:57 schrieb Benjamin Kaduk: The OpenAFS Guardians are hapy to announce the availability of the first prerelease candidate of OpenAFS 1.8.0. A large number of bugfixes and new features are included, and there are also behavior and functional changes that may require administrator action as part of the upgrade; please consult the release notes for details. I was looking for the release-notes, but didn't find them - but I wanted to try the client-bit myself, so this is my "story". I guess this is more of a "success" story, than a bug, so I'll provide my feedback (little as it may be) here, in case it may be helpful to anybody. I used the Debian-Git-Repository of OpenAFS to build a package that can be installed on Ubuntu 14.04, which we use on most of our Linux-Clients. The procedure wasn't quite straight-forward, and I can make no promises that I did everything completely right - however, it runs for me now, and seems to work. So far, I tested only the client-part of OpenAFS 1.8. The servers are still 1.6.18 (or so - the version from jessie-backports). This is as much a reference for myself, what I actually did, because I didn't find anywhere a description, how to build a Debian-Package (not even a generic one)... At least I eventually found that there's a program "dpkg-build-package", which does most of the job. Building a .deb-package with dpkg-buildpackage didn’t (quite) work with an AFS-Home-directory, the build got stuck at "chown" - seems like the "fakeroot" didn’t quite do what it was supposed to, so I started over in /var/tmp... cd /var/tmp git clone https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git cd openafs git checkout $(git tag|grep debian/1.8|tail -1) sudo apt-get build-dep openafs sudo apt-get install debian-keyring heimdal-multidev libperl-dev dpkg-buildpackage -d -b -uc -us sed -i s/rk_base64_/base64_/ src/auth/userok.c dpkg-buildpackage -d -b -uc -us -nc rm debian/tmp/usr/lib/perl/ukernel.so debian/tmp/usr/lib/perl/AFS/ukernel.pm sed -i 's/dh_strip --dbgsym-migration/dh_strip #--dbgsym-migration/' debian/rules dpkg-buildpackage -d -b -uc -us -nc cd .. Now the building itself is finished. Next install it... sudo dpkg -i openafs-modules-dkms_1.8.0*_all.deb openafs-krb5_1.8.0*_amd64.deb openafs-client_1.8.0*_amd64.deb sudo rm -rf /var/cache/openafs/* /var/cache/openafs-client sudo reboot Some comments: - The original openafs-source is missing the "debian"-subdirectory which contains the pre-defined rules for "Configure". I could probably have done it manually, but since the Debian-Git already contains everything, I used that as a starting point. - The "checkout" line tells git to use the 1.8. tree, instead of the 1.6.20 tree - the "build-dep" for openafs is not sufficient, because it takes only OpenAFS 1.6.X into account, so two more packages are needsd. I don't remember, why I put "debian-keyring" also into the list. I remember it was needed for SOMEthing, but not if it was for this build. - The parameters -uc and -us "dpkg-buildpackage" (unsigned source, unsigned .changes) are probably not needed any more, because I told it to only create binary packages anyways, the "-d" tells it to ignore pre-depends, it wouldn't build on Ubuntu 14.04 otherwise, and the "-b" tells it to only create binary packages, no source-packages. - Something in the debian/rules makes it garble the file "src/auth/userok.c", which fixes the following sed-line. The file is ok before I called the dpkg-buildpackage -- probably some difference between Debian and Ubuntu - The next call to "dpkg-buildpackage" includes the parameter "-nc", to not clear the source-tree, otherwise it would have to rebuild some things that it already built. - Two files are generated (or copied) during the build, which need to be removed (ukernel.so and ukernel.pm), otherwise it won't continue. The "rm" takes care of that. Also, the command dh_strip, which is called towards the end of the dpkg-buildpackage doesn't know the parameter --dbgsym-migration under Ubuntu, so just comment it out with sed. - The third run of "dpkg-buildpackage" continues until the end and produces the final package-files in /var/tmp - Next I installed with "dpkg -i" the three packages that are needed for a client-install and courageously rebooted - only to find out that AFS wasn't find my home-dir. (All other directories were working fine, except the one above my homedir and my homedir...) - Any combination of "fs flush" "fs flushmount" and "fs flushall" didn't help either, so I manually cleared out the AFS-cache and restarted again. - Current state: AFS apparently working. Didn't use it as a "real" (graphical) home-directory yet, because I did all this remotely, but copying files to and from the AFS seems to work fine. In case anybody can (or wants to) make use of these packages, I copied them to the AFS in the publicly accessible directory
Re: [OpenAFS] OpenAFS 1.8.0 alpha 1 available
Am 01.01.17 um 23:07 schrieb Jeffrey Altman: On 1/1/2017 1:38 PM, Gaja Sophie Peters wrote: I wonder if this problem is related to the matlab "bug" (a little off-topic maybe, but who knows) Matlab simply won't start from a directory with @sys in the path, I'm curious about this "matlab" incompatibility. Can you clarify what you mean by "a directory with @sys in the path"? Do you mean: 1. a path component "@sys" is being passed to Matlab? /afs/cell-name/appl/@sys/bin/prog Exactly. Starting Matlab with the path /afs/math.uni-hamburg.de/software/@sys/matlab2016b/bin/matlab shows only the window "Activate Matlab Software". Starting explicitly /afs/math.uni-hamburg.de/software/amd64_linux26/matlab2016b/bin/matlab Matlab starts cleanly (interestingly today even after I had started it once with @sys - which at some point a few years ago didn't work until after a reboot) 2. a path component that is a symlink whose target path contains @sys? /afs/cell-name/appl/bin/prog That as well. $ ls -al /afs/math.uni-hamburg.de/software/bin/matlab2016b-syslink lrwxr-xr-x 1 root root 30 Dez 31 22:52 /afs/math.uni-hamburg.de/software/bin/matlab2016b-syslink -> ../@sys/matlab2016b/bin/matlab Starting the command /afs/math.uni-hamburg.de/software/bin/matlab2016b-syslink results also just in the activation windows. We use a starting-script that looks explicitly for @sys in the "syslink" symbolic link and replaces it with $(fs sysname), so that the command /afs/math.uni-hamburg.de/software/bin/matlab2016b in the end finds the correct location for matlab Some time in early 2014 I tried (unsuccessfully) to tweak the actual starting-script for matlab, but then came other things, and I postponed it again. (also, our work-around works...) The "real" problem is within the MATLAB executable (or some java-libary) itself. works: /afs/math.uni-hamburg.de/software/amd64_linux26/matlab2016b/bin/glnxa64/MATLAB doesn't work (asks for activation): /afs/math.uni-hamburg.de/software/@sys/matlab2016b/bin/glnxa64/MATLAB Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.8.0 alpha 1 available
Am 01.01.17 um 02:03 schrieb Benjamin Kaduk: The release notes are at http://openafs.org/dl/openafs/candidate/1.8.0pre1/RELNOTES-1.8.0pre1 which should be linked from the main http://openafs.org/main.html page but may have been missing for a short while at one point. Thanks - I found them now - guess I was looking at the wrong place. - Next I installed with "dpkg -i" the three packages that are needed for a client-install and courageously rebooted - only to find out that AFS wasn't find my home-dir. (All other directories were working fine, except the one above my homedir and my homedir...) Do you think there was anything other than your home directory in your local cache at the time you installed the new packages? At the time I installed the packages, most likely. However, I cleaned the cache multiple times (or even deleted all files in the cache-directory and restarted) and SSH-Login still won't find my home-directory - though it finds everything else. I wonder if this problem is related to the matlab "bug" (a little off-topic maybe, but who knows) Matlab simply won't start from a directory with @sys in the path, so one has to specifically go via amd64_linux26 (or whatever is appropriate). Since it's just "luck", which path to the final directory the kernel sees first (depending on what else got called in what order), sometimes Matlab won't even start from amd64_linux26 because it STILL thinks, it's called from @sys -- whatever the kernel sees first, it remembers and will continue to remember until a reboot... This might be a similar case - the kernel (-module?) sees first "there is no such directory" (because root doesn't have the appropriate token) and remembers this even after the token is there, and the kernel should check again. Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.8.0 beta 4 available
(I tried sending this email about a week ago, but apparently unsuccessfull, so I am retrying with a different sender-address now.) Am 06.01.2018 um 03:22 schrieb Benjamin Kaduk: The OpenAFS Guardians are happy to announce the availability of the fourth prerelease candidate of OpenAFS 1.8.0. What better opportunity to test the new release, than when the DKMS of the old release from jessie (1.6.9-2+deb8u6) AND from jessie-backports (1.6.18.2-1~bpo8+1) fails to build on the new kernel with the "Meltdown"-fixes (which for Debian-Jessie is 3.16.0-5-amd64)... I created packages in a way similar to what I wrote in https://lists.openafs.org/pipermail/openafs-info/2016-December/041997.html only that I did it all on a Debian Jessie system, instead of Ubuntu 14.04. So far everything works fine, the DKMS-module was built successfully and the AFS-client seems completely usable. Greetings, Gaja Peters P.S. In case anybody can (or wants to) make use of these packages, I copied them to the AFS in the publicly accessible directory /afs/math.uni-hamburg.de/public/fmsv030/openafs-1.8.0~pre4-1_amd64_Debian-Jessie -- +-- | IT-Gruppe, Systemadministration | Universität Hamburg, Fachbereich Mathematik | Bundesstr. 55 (Geomatikum) | Raum 212; Tel. 42838-5175 +-- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.8.0 beta 4 available
Am 06.01.2018 um 03:22 schrieb Benjamin Kaduk: The OpenAFS Guardians are happy to announce the availability of the fourth prerelease candidate of OpenAFS 1.8.0. What better opportunity to test the new release, than when the DKMS of the old release from jessie (1.6.9-2+deb8u6) AND from jessie-backports (1.6.18.2-1~bpo8+1) fails to build on the new kernel with the "Meltdown"-fixes (which for Debian-Jessie is 3.16.0-5-amd64)... I created packages in a way similar to what I wrote in https://lists.openafs.org/pipermail/openafs-info/2016-December/041997.html only that I did it all on a Debian Jessie system, instead of Ubuntu 14.04. So far everything works fine, the DKMS-module was built successfully and the AFS-client seems completely usable. Greetings, Gaja Peters P.S. In case anybody can (or wants to) make use of these packages, I copied them to the AFS in the publicly accessible directory /afs/math.uni-hamburg.de/public/fmsv030/openafs-1.8.0~pre4-1_amd64_Debian-Jessie ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Windows 10, KDC not reachable / AFS integrated login failed
Am 30.01.2018 um 14:09 schrieb Andreas Ladanyi: Windows 10 Pro , Auristor AFS client package When starting the device and before login screen appears the messages appears: [snip] AFS integrated login failed before it is possible to enter credentials at windows login box (display manager). This is a rather late answer, but since I just happened to stumble again over the solution, I thought I'd post it here in case it is still useful for anybody. Is it possible to start kerberos client and afs client after entering the credentials at windows 10 ? Yes, that is possible. The solution is basically what is posted on this website: https://www.tenforums.com/tutorials/49963-use-sign-info-auto-finish-after-update-restart-windows-10-a.html Apparently, Windows 10 since some version is able to "remember" login-credentials over a reboot, and will use these internal credentials to sign-in to windows even before you enter the password. This unfortunately triggers also the "integrated login" to AFS, but since there is no password for it to work with, it will fail. Once this option in Windows is disabled, Windows will not try to do an integrated login without password and everything is ok. Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Obtaining tokens at login on Ubuntu 18.04
Am 17.08.2018 um 02:41 schrieb Prasad K. Dharmasena: I've installed OpenAFS and pam-afs-session on Ubuntu 18.04 (bionic) via (a) vendor supplied packages, and (b) building from source (1.6.22.3). On both machines, logging in via gdm doesn't get me a token. Has anyone else seen this on Ubuntu 18.04? (I've had this working for a while now on Ubuntu 16.04 -- building from 1.6.20+ source with pam-afs-session 2.6.) We had some success with an "aklog.service" as described in https://www.mail-archive.com/openafs-info@openafs.org/msg40604.html The main problem that we face at the moment is that there are TWO sessions opened, and (especially in "Ubuntu"-Session) depending on which program is started, it lives in the one or the other. Most notable "xterm" and "gnome-terminal" have to different sessions - which in the end means that an "aklog" needs to be performed in both... The above mentioned script tries to help with that, but it's not quite perfect yet. Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Linux: systemctl --user vs. AFS
Am 08.03.2018 um 20:08 schrieb Jonathan Billings:
> There's a google doc in the Debian bug that I wrote
> (https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub),
>
> which was to create an /etc/systemd/user/aklog.service that is
> automatically started as part of the login,
I did some testing on Ubuntu 18.04 alpha (or beta?), and ran into the
same problem, which I solved with a variant of the above, which seems to
work for the time being.
The systemd-file itself goes to
/etc/systemd/user/aklog.service
The link to start it goes to
/etc/systemd/user/default.target.wants
Main advantage of course, that you don't have to make your
AFS-Homedirectory world-readable...
> what it does is runs an
> aklog so that the processes started by systemd --user have tokens. This
> assumes that it's got its own keyring.
This seems to work. "xterm" and "gnome-terminal" are still in separate
PAGs, but since both can read the Kerberos-Ticket, both can get the
AFS-Token. I added an "unlog" to ExecStop, so that the Token will be
destroyed on logout. Without that, the once-obtained token will remain,
even after logout and immidiate re-login. (Tested with manual,
non-scripted aklog...)
> This works, to a certain extent. I also have a startup script that I
> wrote that runs dbus-monitor to watch org.gnome.ScreenSaver, and restart
> the aklog.service user service every time you unlock the screensaver, so
> those tokens get renewed with the updated krb5 credentials.
I tried to combine both parts into a single "aklog.service" file (see
below). I don't know much about systemd and even less about dbus, so
there might be things that are backwards... An added complication for me
was that at the point where I wanted the aklog.service to be executed,
the environment-variable KRB5CCNAME wasn't yet set, so I used a somewhat
hackish fragment to construct the variable from the file that existed
already in /tmp.
File /etc/systemd/user/aklog.service
>
[Unit]
Description=aklog for session --user
Before=gnome-keyring-ssh.service
[Service]
Type=simple
ExecStartPre=/bin/sh -c ' \
KRB5CCNAME=FILE:$(ls -t /tmp/krb5cc_${XDG_RUNTIME_DIR#/run/user/}*|head
-1) aklog -d'
ExecStart=/bin/sh -c ' \
dbus-monitor --profile path=/org/freedesktop/secrets/collection/login |
\
while read TYPE LINE; \
do \
[ "$TYPE" = "mc" ] && systemctl --user reload aklog; \
done'
ExecReload=/usr/bin/aklog
ExecStop=/usr/bin/unlog
[Install]
WantedBy=default.target
>
Explanation: the dbus-monitor needs to run all the time for new logins,
so I made it the main-process of the service. Before that, aklog needs
to be started with a (re-)constructed KRB5CCNAME which is at that time
missing from the environment, so I look for the newest krb5cc-file with
the current user-ID in /tmp. The user-ID itself doesn't exist in the
environment at that point, only the username (in $LOGNAME and $USER),
however the userid is found as part of the $XDG_RUNTIME_DIR, so I used that.
The dbus-monitor watches "something" that seems to be called exactly
once on each login - no idea if there are better things to watch for
(disadvantage of screensaver seemed to be that there are two lines, one
for locking, one for unlocking). The first few returned lines start with
"sig" or "#" and aren't interesting, the interesting lines have "mc" as
their first word and will reload the aklog.service (KRB5CCNAME doesn't
need to be set again).
When the service ends, unlog will destroy the AFS-Token. For the
"Before=" line, I simply looked for something that was run fairly early
in the boot-process and told systemd, I want to run even before that.
Greetings,
Gaja Peters
P.S. I have tested this ONLY in Ubuntu 18.04, it might be completely
different in another system! D-Bus might have to be monitored for
something else, and the variable XDG_RUNTIME_DIR might point to
something different.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] problems with ubuntu 18.04 client
Am 02.10.2018 um 15:44 schrieb Andreas Ladanyi: We were probably just lucky, or the packages from the 1.8 ppa http://ppa.launchpad.net/openafs/stable/ubuntu never had the problem. Did you use 1.8.0 from ppa for the clients in the past or did you start at 1.8.2 when switching from 1.6 release ? Apologies for the late answer. We had to switch to the PPA ages ago (since some time in 2013), since the regular Ubuntu DKMS-module made occasionally troubles with Ubuntu kernel updates. So the switch for us was at the same time when 1.8 appeared in the PPA. Looking back, it was on the 25th of April 2018 - we had to change our "apt-get update" line to something like this, before it worked, though apt-get --allow-releaseinfo-change-label update Without that, Ubuntu 18.04 wouldn't accept the name-change of 'OpenAFS 1.6.x stable releases' to 'OpenAFS stable releases (1.8.x)' (Ubuntu 14.04 and 16.04 accepted it without that) Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] problems with ubuntu 18.04 client
Am 02.10.2018 um 08:58 schrieb Andreas Ladanyi: we had the same problems. We are using the 1.6 release from ppa ( https://launchpad.net/~openafs/%2Barchive/ubuntu/stable ) on server and client now and there seems to be no problems anymore. We were probably just lucky, or the packages from the 1.8 ppa http://ppa.launchpad.net/openafs/stable/ubuntu never had the problem. At the moment, we live with all clients and all servers at 1.8.2 and (crossing fingers and knocking wood) everything seems to work. The one problem we occasionally have (which has nothing to do with the above) is that when people force a shutdown or reboot at an inopportune moment during an OpenAFS update, the AFS is entirely lost (the old DKMS-package deleted, the new not yet built), but the system thinks, "oh the home-directory should be /afs/math.uni-hamburg.de/users/../... - let's just create that directory and the entire tree". In that case, a simple rebuild of the DKMS-module and "service openafs-client force-start" fixes the problem however. Greetings, Gaja Peters ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Behaviour of OpenAFS 1.8.7 on MacOS
(apologies for possible duplicate post, I used the wrong sender-address the first time) Dear List, just some observations I had after updating the MacOS Catalina-computer with the OpenAFS 1.8.7 provided by SineNomine (thanks for that): % ls /afs | wc 41 41 466 % sudo grep -c '>' /var/db/openafs/etc/CellServDB 203 % ls /afs/grand.central.org | wc ls: /afs/grand.central.org: No such file or directory 0 0 0 % ls /afs/sinenomine.net | wc 6 6 42 % fs --version openafs 1.8.6-14-g1f84796 I haven't yet found a common denominator between Cells that work and Cells that don't. I was thinking, it might have to do with presence or absence of AFSDB and SRV DNS-records, but in the end not sure. CELLWORKS ls /afs ? DNS-records ? sinenomine.net WORKS LISTED has both AFSDB and SRV cern.ch WORKS NOT LISTED has both AFSDB and SRV rec grand.central.org NOT-FOUND NOT LISTED has only SRV desy.de WORKS NOT LISTED has only AFSDB math.uni-hamburg.de NOT-FOUND NOT LISTED has only AFSDB kth.se WORKS LISTED has only AFSDB A similar (if not so extensive) test with Auristor (thanks also for providing THAT) has found no inaccessible Cells... Greetings, Gaja Peters -- +-- | IT-Gruppe, Systemadministration | Universität Hamburg, Fachbereich Mathematik | Bundesstr. 55 (Geomatikum) | Raum 212; Tel. 42838-5175 +-- -- +-- | IT-Gruppe, Systemadministration | Universität Hamburg, Fachbereich Mathematik | Bundesstr. 55 (Geomatikum) | Raum 212; Tel. 42838-5175 +-- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Behaviour of OpenAFS 1.8.7 on MacOS
Am 25.01.21 um 20:54 schrieb Marcio Barbosa: The reported problem was fixed and a new version is available. Thank you for reporting this issue. Thank *you* for reparing the issue. :-) Both the Catalina and the BigSur-Version now work. The BigSur computer took some three minutes to shutdown after the test, but that was not necessarily related to the OpenAFS installation (it's an older MacBook with only 4 GB RAM). Greetings, Gaja Peters -- +-- | IT-Gruppe, Systemadministration | Universität Hamburg, Fachbereich Mathematik | Bundesstr. 55 (Geomatikum) | Raum 212; Tel. 42838-5175 +-- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
