Re: [OpenAFS] Re: Moving Magic Trio to another domain
Hi Andrew and Russ, On Sun, 22 Sep 2013 11:09:38 +0300 (EEST) Jukka Tuominen jukka.tuomi...@finndesign.fi wrote: I'm facing a major challenge. I'm trying to move a populated OpenAFS/Kerberos/OpenLDAP installation under another domain name. The IP address remains the same. Hopefully there is a way save the users, their passwords, accounts etc. The user accounts are on afs. The system can go offline, if necessary. Do you mean you're using OpenLDAP as a kerberos backend, or just that you're storing passwd/group information in ldap? A few years back, I followed these instructions to set up the trio: http://techpubs.spinlocksolutions.com/dklar/kerberos.html http://techpubs.spinlocksolutions.com/dklar/afs.html http://techpubs.spinlocksolutions.com/dklar/ldap.html ... so the ldap is used for serving metadata only. OpenAFS has been updated to 1.6 since, and some configuration tweaks were needed to make them all play nicely with the graphical log-in. For Kerberos, if you're using about MIT or Heimdal, this may be difficult, since usually the keys for user principals are all salted with the realm name. In the past I believe doing this was considered impossible to do with existing code, but maybe things have improved. This is more appropriate for the relevant Kerberos list, but someone may respond here further anyway. AD I assume has an easier time with this, since it stores passwords and not keys. So, MIT kerberos is used, but generating new passwords is certainly doable if the homedirs on afs can still be saved. Any suggestions how to best do this? OpenAFS servers and such usually don't care much about the name of the cell. You can generally just treat this as adding a new realm for the cell (and later removing the old realm/cell, if you want to). This means you generate a new kerberos principal for afs/newcell@NEWREALM, add it to the KeyFile/rxkad.keytab, and add the new realm to openafs's krb.conf. If you ever use the '-cell' option in any scripts or anything, of course that would need to change. You may want to just take down all of the servers, update ThisCell and CellServDB, and restart, but doing that I don't think is strictly necessary. So, IIUC the homedirs aren't actually moved, they only get new reference points (or something)? For clients, just point them at the same servers with the new cell name. So, update their client CellServDBs or your AFSDB/SRV records, etc. You can point two different cell names at the same servers; clients don't ever send the cell name when talking to afs servers; it's just used for deciding which dbservers to contact and for acquiring/storing credentials. I duplicated a client and updated all its server pointers, including ldap. I suppose the new kerberos key needs to be added to the keytab, as well? br, jukka -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Naming of backup and up commands
[added release-team] On Sun, 22 Sep 2013 23:42:55 -0500 Andrew Deason adea...@sinenomine.net wrote: On Sun, 22 Sep 2013 17:51:40 -0700 Russ Allbery r...@stanford.edu wrote: What would people think if I submitted a patch to OpenAFS to rename up to afs-up and backup to afs-backup? Would that break a bunch of critical software? It would be really nice to fix AFS's camping on obvious namespace. Would it be appropriate to also have an optional compat package that could symlink the original names? yes, I think so. Thing is, for SuSE I renamed scout to afs_scout. I'm not sure if RedHat/SL did some similar renaming (probaly using yet another scheme for it) So, on possible solution is to fix the renaming on gerrit. Then the packagers can create their own compatibility packages for this, since they are sure of the future binary-names. Either way, sure, makes sense to me. But the people that actually use those commands really do need to say something, even if it's just yes, sounds good. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Naming of backup and up commands
On Mon, 23 Sep 2013 09:19:07 +0200 Christof Hanke christof.ha...@rzg.mpg.de wrote: [added release-team] On Sun, 22 Sep 2013 23:42:55 -0500 Andrew Deason adea...@sinenomine.net wrote: On Sun, 22 Sep 2013 17:51:40 -0700 Russ Allbery r...@stanford.edu wrote: What would people think if I submitted a patch to OpenAFS to rename up to afs-up and backup to afs-backup? Would that break a bunch of critical software? It would be really nice to fix AFS's camping on obvious namespace. Would it be appropriate to also have an optional compat package that could symlink the original names? yes, I think so. Thing is, for SuSE I renamed scout to afs_scout. I'm not sure if RedHat/SL did some similar renaming (probaly using yet another scheme for it) Actually I found on SL6: /usr/bin/pagsh.openafs, so we have now afs-* afs_* and *.openafs as renaming-schemes... So, on possible solution is to fix the renaming on gerrit. Then the packagers can create their own compatibility packages for this, since they are sure of the future binary-names. Either way, sure, makes sense to me. But the people that actually use those commands really do need to say something, even if it's just yes, sounds good. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Naming of backup and up commands
Hello, my answer is YES - we use this commands and YES renaming 'd be fine. If no compat-packages gets provided I'd write/expand my own 'afs-fixit' script. I'd prefer to see the 'afs' prefix rather than a suffix. I think this makes things more easy especially for new people. (type 'afs' and double press TAB to get things back mind) Imho this is also much closer to the command suit idea of afs. Have a good day Mathias Feiler On So, 2013-09-22 at 21:10 -0400, Jeffrey Altman wrote: Russ, I would like to hear from sites that actively use these commands. That said my personal opinion is that they should be renamed in the next major release. (Not 1.6.x). I have no objection to separate packaging. Jeffrey Altman On 9/22/2013 8:51 PM, Russ Allbery wrote: In the Debian packaging for OpenAFS, I've renamed the up command to afs-up for years now. There's now also a conflict with the backup command (which is a horrible name for a command), and I'm rather tempted to do the same thing, but since it's a whole command suite with multiple documentation pages and cross-references, it's more of an undertaking. What would people think if I submitted a patch to OpenAFS to rename up to afs-up and backup to afs-backup? Would that break a bunch of critical software? It would be really nice to fix AFS's camping on obvious namespace. Failing that, I'm probably going to split butc, backup, and fms into a separate package to make it easier for other packages to conflict with it due to the poorly-chosen command name instead of conflicting with all of openafs-client. -- Mathias Feiler Universitaet Hohenheim Kommunikations-, Informations- und Medienzentrum (630) IT-Dienste | Abt. IT-Infrastruktur (ITI) Raum 04.24/227 Schloss Westhof-Sued | 70599 Stuttgart Tel. + 49 711 459 23949 | Fax + 49 711 459 23449 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS installation messes up Windows 8 file access control
On 9/18/2013 8:17 PM, Tim Adye wrote: Hi Jeffrey, Jeffrey Altman jalt...@secure-endpoints.com wrote on 16 September 2013: if you are experiencing undesirable behavior on paths located in the AFS name space then the afs redirectorcan be involved. if the path is local disk or CIFS then the redirector cannot b The Windows Multiple UNC provider simply will not send those file system operations to the afs file system. Yes, the problem is on my local disk (eg. C:\Program Files). It's just the installation of OpenAFS that provokes it. An installation of OpenAFS consists of: 1. two device drivers 2. the three shell extensions in both x86 and x64 variants 3. the network provider in both x86 and x64 variants 4. the authentication provider 5. the service 6. the smb pipe service emulators i can certainly believe that the explorer shell has bugs that are triggered by the mere existence of a non Microsoft file system. The explorer shell has a lot of hard coded assumptions that require NTFS or CIFS. this is part of the reason that their new ReFS file system is not supported on client systems. If the installer isn't messing with Explorer's permissions settings, then the presence of the OpenAFS IFS does sound like the likely culprit for provoking an Explorer bug. I have installed some other IFS systems on my machine, but it looks like only OpenAFS causes the problem. what other IFSs have you installed? Are they network file systems? Do they provide all of the system components that OpenAFS provides? Can I test this by uninstalling or disabling the OpenAFS IFS alone? I can switch off all the OpenAFS programs (with autoruns and the Services control panel), but the problem remains. It takes a full OpenAFS uninstall to cure it. It would narrow down the problem if I can disable or uninstall just the IFS and check if that is the crucial step. The device drivers can be disabled in the registry HKLM\SYSTEM\CurrentControlSet\Services\AFSRedirector HKLM\SYSTEM\CurrentControlSet\Services\AFSLibrary The Start parameter determines whether or not (and when) the driver is loaded. A value of 4 disables the device driver. The service will switch to SMB mode if the drivers are not available. SMB mode requires the microsoft loopback adapter be installed. The service is HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon it is also possible that another file system filter installed on the machine is altering the return code which prevents user account control from be triggered. however, it sounds like the real problem is that the explorer shell thinks the volume you are working on is readonly and therefore decides to hide the UI controls. The symptoms are a little different from a read-only device. For example, the delete button is not greyed out, and attempting to delete a file still brings up the are you sure you want to move this to the recycle bin prompt (if delete prompts are enabled) before silently failing. I just checked with a read-only SD card and the behaviour is different there. What are the differences in behavior as viewed by SysInternals Process Monitor? this would be an explorer shell bug which must be addressed by Microsoft. That does seem likely, but how to get them to do so? Tracking down a more specific cause would probably help. I don't know the best forum/way to report a Windows bug. Reporting bugs to Microsoft requires a Professional Support Contract for the operating system in question or payment for a support incident. If it's not some combination of things on my specific system, then everyone who installs OpenAFS on Windows 8 (64 bit? Standard Edition?) will hit this really annoying problem. Is it just me? Does anyone else here see it? I was lucky to spot that it appeared when I installed OpenAFS; many people might not. I'm planning on upgrading to Windows 8 Pro, so I hope soon to see if the issue is specific to the Standard Edition. None of YFSI's support customers have complained about this behavior. That being said, none of our support customers are deploying Windows 8 in a production end user environment. Thanks, Tim. Jeffrey Altman On 9/15/2013 10:03 PM, Tim Adye wrote: Hi Jeffrey, Thanks for the information. The only interaction between OpenAFS and the Explorer Shell is the AFS Shell Extension which provides the AFS Context Menu, the AFS Property Sheets, and Mount Point and Symlink Overlay Icons. This is the functionality you would have disabled using autoruns. Yes, I tried disabling all of those, but that didn't help. If, as you suggest, it isn't OpenAFS running, then there must be something that the OpenAFS installer and uninstaller do to affect Windows Explorer. I installed and uninstalled OpenAFS many times (often with no other action except for the reboot) and the problematic behaviour I described appeared if, and only if, OpenAFS was installed (whether running
[OpenAFS] OpenAFS integrated login failed
Hi, we had problems with OpenAFS 1.6.1 crashing on a Windows XP workstation. Eventlog said: - OpenAFS Stopping due to error (cm_scache.c:787): CM_SCACHEFLAG_INHASH set. So I tried to switch to OpenAFS 1.7.26. But now integrated login doesn't work anymore. - Integrated login failed: Cache Manager is not initialized / afsd is not running But afsd_service.exe is running and if I login with a local user, get a kerberos ticket and open \\afsfile:///\\afs... path I have no problems. Does someone know, what's going wrong and how to fix it? It seems tob e a problem with AFS cache!? Mit freundlichen Grüßen Michael Richter -- Michael Richter Technische Universität Berlin Universitätsbibliothek, IT-Service Fasanenstraße 88 10623 Berlin Tel: 030/314-76310
Re: [OpenAFS] Naming of backup and up commands
On 9/22/13 20:51, Russ Allbery r...@stanford.edu wrote: Failing that, I'm probably going to split butc, backup, and fms into a separate package to make it easier for other packages to conflict with it due to the poorly-chosen command name instead of conflicting with all of openafs-client. Up/upserver and the backup suite probably should be in their own packages anyway. -- brandon s allbery kf8nhsine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad
Re: [OpenAFS] OpenAFS integrated login failed
On 9/23/2013 9:13 AM, Richter, Michael wrote: Hi, we had problems with OpenAFS 1.6.1 crashing on a Windows XP workstation. Eventlog said: - OpenAFS Stopping due to error (cm_scache.c:787): CM_SCACHEFLAG_INHASH set. This bug is fixed in 1.7. So I tried to switch to OpenAFS 1.7.26. But now integrated login doesn’t work anymore. - Integrated login failed: Cache Manager is not initialized / afsd is not running One of two possibilities: 1. afsd_service.exe is not running at the time that winlogin.exe executes the authentication provider but is running by the time the user desktop is loaded. 2. pioctl operations on \\afs\all\_._afs_ioctl_._ are blocked for the calling process from within winlogin.exe But afsd_service.exe is running and if I login with a local user, get a kerberos ticket and open \\afs file:///\\afs... path I have no problems. All this indicates that is that by the time the user desktop is displayed whatever is blocking the service from starting or blocking pioctl path operations has completed. OpenAFS has a dependency on the network stack and because it still contains smb support has a dependency on the smb redirector. Until the dependencies are met the service will not start. OpenAFS also has a dependency on the Windows Firewall service. Does someone know, what’s going wrong and how to fix it? You have not provided enough information about the state of the system to identify the root cause of the problem. It seems to be a problem with AFS cache!? What do you mean by AFS cache? If you are referring to the %windir%\temp\AFSCache file, what leads you to that conclusion? Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
[OpenAFS] Re: Moving Magic Trio to another domain
On Mon, 23 Sep 2013 09:08:35 +0300 (EEST) Jukka Tuominen jukka.tuomi...@finndesign.fi wrote: For Kerberos, if you're using about MIT or Heimdal, this may be difficult, since usually the keys for user principals are all salted with the realm name. In the past I believe doing this was considered impossible to do with existing code, but maybe things have improved. This is more appropriate for the relevant Kerberos list, but someone may respond here further anyway. AD I assume has an easier time with this, since it stores passwords and not keys. So, MIT kerberos is used, but generating new passwords is certainly doable if the homedirs on afs can still be saved. If you can regenerate all of the keys/passwords, then it sounds like you can just create a new realm from scratch. Just destroy the data from the old realm and set up a new realm, as if you were setting it up for the first time, and create all of the principals that existed in the original realm. If you want a migration period where the old and new realm are both available, I _think_ you can run multiple realms from the same kdc, but it takes some additional configuration. OpenAFS servers and such usually don't care much about the name of the cell. You can generally just treat this as adding a new realm for the cell (and later removing the old realm/cell, if you want to). This means you generate a new kerberos principal for afs/newcell@NEWREALM, add it to the KeyFile/rxkad.keytab, and add the new realm to openafs's krb.conf. If you ever use the '-cell' option in any scripts or anything, of course that would need to change. You may want to just take down all of the servers, update ThisCell and CellServDB, and restart, but doing that I don't think is strictly necessary. So, IIUC the homedirs aren't actually moved, they only get new reference points (or something)? Well yes, they aren't moving; you said the server isn't changing, right? There's nowhere to be moving to :) You just add the new.example.com cell to CellServDB (or AFSDB/SRV DNS, or whatever), and then you access someone's home directory via e.g.: /afs/new.example.com/user/foo instead of: /afs/old.example.com/user/foo If you do not restart the client, you'll need to add the new cell information with 'fs newcell'. If you are not using dynroot, you'll also need to add the new.example.com mountpoint to root.afs, like you did for the original cell setup. So, more generally, just treat it as a new cell, which happens to contain the data you want in it. I duplicated a client and updated all its server pointers, including ldap. I suppose the new kerberos key needs to be added to the keytab, as well? To the OpenAFS rxkad.keytab/KeyFile? Yes, you need to generate a new key for a new principal with the new cell name in it. The old principal was presumably called afs/old.example@old.example.com, and you need to create a new one called afs/new.example@new.example.com, and add it to rxkad.keytab or KeyFile, according to the normal instructions. Just make sure that the kvnos for the 'old' and 'new' principals are different, if you want to use both of them at the same time (for a migration period). -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Naming of backup and up commands
Andrew Deason adea...@sinenomine.net writes: Russ Allbery r...@stanford.edu wrote: What would people think if I submitted a patch to OpenAFS to rename up to afs-up and backup to afs-backup? Would that break a bunch of critical software? It would be really nice to fix AFS's camping on obvious namespace. Would it be appropriate to also have an optional compat package that could symlink the original names? Yeah, we could do that, I suppose, although it's going to be hard to know when to drop the package. Although I'd really rather do something that OpenAFS is also going to adopt, since I have to rename the command in all the man pages. Either way, sure, makes sense to me. But the people that actually use those commands really do need to say something, even if it's just yes, sounds good. Yes, indeed. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Naming of backup and up commands
Brandon Allbery ballb...@sinenomine.net writes: On 9/22/13 20:51, Russ Allbery r...@stanford.edu wrote: Failing that, I'm probably going to split butc, backup, and fms into a separate package to make it easier for other packages to conflict with it due to the poorly-chosen command name instead of conflicting with all of openafs-client. Up/upserver and the backup suite probably should be in their own packages anyway. up is unrelated to upserver. It's basically an AFS-aware cp -p. upserver/upclient are currently packaged in openafs-fileserver, as are buserver. While they probably don't really need to be there, I'll probably leave them there as they're not really hurting anything. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS integrated login failed
Hi, Could you try 1.7.23 and check if problem exists there as well? I think I am experiencing the same issue as you with versions = 1.7.24 -K. On 09/23/2013 04:13 PM, Richter, Michael wrote: So I tried to switch to OpenAFS 1.7.26. But now integrated login doesn’t work anymore. -Integrated login failed: Cache Manager is not initialized / afsd is not running But afsd_service.exe is running and if I login with a local user, get a kerberos ticket and open \\afs file:///\\afs... path I have no problems. smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS release-team] Re: [OpenAFS] Re: Naming of backup and up commands
Christof Hanke christof.ha...@rzg.mpg.de writes: Actually I found on SL6: /usr/bin/pagsh.openafs, so we have now afs-* afs_* and *.openafs as renaming-schemes... This may be a little different. That naming in Debian (which I suspect may be where it came from originally) was because we had pagsh.openafs and pagsh.krb, which could be managed by alternatives. It's convention in Debian for cases like this to use a suffix instead of a prefix for the various binaries that contribute to an alternative if there's no obviously better naming system. I think all the other providers of pagsh have now gone away, actually. See also klog.afs and klog.krb5. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Naming of backup and up commands
Maybe have an 'openafs' command, which has all the other commands as sub-commands. Similar to the openssl command. That command would just be a front-end to the other excutables, and then those executables could use whatever naming convention which works best for installation, whether that be openafs-backup, afsbackup, or backup.openafs. An 'openafs' command implies that all the commands would be under it, including 'fs', 'pts' etc. If that isn't a path we want to go down, then have the command be 'afsutil' or 'afstools'. I do think there is an advantage to having all of these findable via a single command. How many afs users even know that the 'up' command exists, for instance? It wouldn't surprise me too much if I'm the only one at RPI. -- Garance Alistair Drosehn Senior Systems Programmer Rensselaer Polytechnic Institute; Troy NY ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Naming of backup and up commands
On Mon, 23 Sep 2013 09:13:19 -0700 Russ Allbery r...@stanford.edu wrote: Would it be appropriate to also have an optional compat package that could symlink the original names? Yeah, we could do that, I suppose, although it's going to be hard to know when to drop the package. Well, not doing it at all is equivalent to just dropping it immediately. So if this is an improvement at all, even just doing it for one or two debian releases seems better than nothing. Although I'd really rather do something that OpenAFS is also going to adopt, since I have to rename the command in all the man pages. Yes, I was kind of thinking for openafs, too. While making the old names not work may not be appropriate for the 1.6.x timeframe, I don't see a reason not to rename them with appropriate symlinks immediately. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Moving Magic Trio to another domain
On Mon, 23 Sep 2013 09:08:35 +0300 (EEST) Jukka Tuominen jukka.tuomi...@finndesign.fi wrote: For Kerberos, if you're using about MIT or Heimdal, this may be difficult, since usually the keys for user principals are all salted with the realm name. In the past I believe doing this was considered impossible to do with existing code, but maybe things have improved. This is more appropriate for the relevant Kerberos list, but someone may respond here further anyway. AD I assume has an easier time with this, since it stores passwords and not keys. So, MIT kerberos is used, but generating new passwords is certainly doable if the homedirs on afs can still be saved. If you can regenerate all of the keys/passwords, then it sounds like you can just create a new realm from scratch. Just destroy the data from the old realm and set up a new realm, as if you were setting it up for the first time, and create all of the principals that existed in the original realm. I first tried to dpkg-reconfigure krb server packages so I could introduce the new domain, but it persisted to use the old domain without asking a thing, so I manually replaced all old domains in the .conf with the new one. I was then able to create the new realm. How do I destroy the old realm data? If you want a migration period where the old and new realm are both available, I _think_ you can run multiple realms from the same kdc, but it takes some additional configuration. OpenAFS servers and such usually don't care much about the name of the cell. You can generally just treat this as adding a new realm for the cell (and later removing the old realm/cell, if you want to). This means you generate a new kerberos principal for afs/newcell@NEWREALM, add it to the KeyFile/rxkad.keytab, and add the new realm to openafs's krb.conf. If you ever use the '-cell' option in any scripts or anything, of course that would need to change. You may want to just take down all of the servers, update ThisCell and CellServDB, and restart, but doing that I don't think is strictly necessary. I was able to add the new cell princ key, but not the server princ key, as it returned cannot specify keysaltlist when not changing key when given the command kadmin.local: ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal afs/[server.name]. But that was my earlier attempt (see a few lines below what I did), so it may be different when I follow your suggestions more closely... So, IIUC the homedirs aren't actually moved, they only get new reference points (or something)? Well yes, they aren't moving; you said the server isn't changing, right? There's nowhere to be moving to :) You just add the new.example.com cell to CellServDB (or AFSDB/SRV DNS, or whatever), and then you access someone's home directory via e.g.: /afs/new.example.com/user/foo instead of: /afs/old.example.com/user/foo I renamed the old /vicepa and was going to create a new one, but I quess I shouldn't have done that but used the existing one as is? Luckily I can easily restore an earlier snapshot and try it the other way. If you do not restart the client, you'll need to add the new cell information with 'fs newcell'. If you are not using dynroot, you'll also need to add the new.example.com mountpoint to root.afs, like you did for the original cell setup. So, more generally, just treat it as a new cell, which happens to contain the data you want in it. I duplicated a client and updated all its server pointers, including ldap. I suppose the new kerberos key needs to be added to the keytab, as well? To the OpenAFS rxkad.keytab/KeyFile? Yes, you need to generate a new key for a new principal with the new cell name in it. The old principal was presumably called afs/old.example@old.example.com, and you need to create a new one called afs/new.example@new.example.com, and add it to rxkad.keytab or KeyFile, according to the normal instructions. Just make sure that the kvnos for the 'old' and 'new' principals are different, if you want to use both of them at the same time (for a migration period). Not quite there yet, but will do so. Thanks, again. br, jukka -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Moving Magic Trio to another domain
On 9/23/2013 3:06 PM, Jukka Tuominen wrote: kadmin.local: ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal afs/[server.name]. But that was my earlier attempt (see a few lines below what I did), so it may be different when I follow your suggestions more closely... Please do not create AFS keys with DES. See Security Vulnerability: OPENAFS-SA-2013-003 Brute force DES attack permits compromise of AFS cell http://www.openafs.org/pages/security/#OPENAFS-SA-2013-003 smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Re: Moving Magic Trio to another domain
Thanks, I would have missed that! br, jukka On 9/23/2013 3:06 PM, Jukka Tuominen wrote: kadmin.local: ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal afs/[server.name]. But that was my earlier attempt (see a few lines below what I did), so it may be different when I follow your suggestions more closely... Please do not create AFS keys with DES. See Security Vulnerability: OPENAFS-SA-2013-003 Brute force DES attack permits compromise of AFS cell http://www.openafs.org/pages/security/#OPENAFS-SA-2013-003 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] OpenAFS installation messes up Windows 8 file access control
Hi Jeffrey,
Thanks for all the information and hints.
I've upgraded from Windows 8 Standard Edition to Pro, but still had the File
Explorer bug with OpenAFS. I tried your recipe for disabling the OpenAFS device
drivers, but that didn't help either. But then I noticed (in Sysinternal's
Process Explorer) that explorer.exe was loading various OpenAFS DLLs even
though I had disabled them all in Sysinternal's Autoruns. This undermines our
earlier elimination of the AFS Shell Extensions as possible culprits.
By several long processes of elimination, I found that afs_shl_ext.dll was
being loaded by a registry key:
[HKEY_CLASSES_ROOT\Folder\shellex\{00021500---C000-0046}]
@={5F820CA1-3DDE-11DB-B2CE-001558092DB5}
which autoruns doesn't know about. If I remove that key, my bug is fixed! I
checked that this key is added as part of the OpenAFS installation and removing
it is all that's needed to fix File Explorer's administrator access control.
What does this key do? Will it break anything to remove it? I didn't see any
problem, and the OpenAFS icon overlays and context menus seem to work.
Thanks,
Tim.
-Original Message-
From: Jeffrey Altman [mailto:jalt...@your-file-system.com]
Sent: 23 September 2013 13:21
To: Adye, Tim (STFC,RAL,PPD)
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] OpenAFS installation messes up Windows 8 file
access control
On 9/18/2013 8:17 PM, Tim Adye wrote:
Hi Jeffrey,
Jeffrey Altman jalt...@secure-endpoints.com wrote on 16 September
2013:
if you are experiencing undesirable behavior on paths located in the
AFS
name space then the afs redirectorcan be involved. if the path is
local
disk or CIFS then the redirector cannot b The Windows Multiple UNC
provider simply will not send those file system operations to the afs
file system.
Yes, the problem is on my local disk (eg. C:\Program Files). It's just
the installation of OpenAFS that provokes it.
An installation of OpenAFS consists of:
1. two device drivers
2. the three shell extensions in both x86 and x64 variants
3. the network provider in both x86 and x64 variants
4. the authentication provider
5. the service
6. the smb pipe service emulators
i can certainly believe that the explorer shell has bugs that are
triggered by the mere existence of a non Microsoft file system. The
explorer shell has a lot of hard coded assumptions that require NTFS or
CIFS. this is part of the reason that their new ReFS file system is
not
supported on client systems.
If the installer isn't messing with Explorer's permissions settings,
then the presence of the OpenAFS IFS does sound like the likely culprit
for provoking an Explorer bug. I have installed some other IFS systems on
my machine, but it looks like only OpenAFS causes the problem.
what other IFSs have you installed? Are they network file systems? Do
they provide all of the system components that OpenAFS provides?
Can I test this by uninstalling or disabling the OpenAFS IFS alone? I
can switch off all the OpenAFS programs (with autoruns and the Services
control panel), but the problem remains. It takes a full OpenAFS uninstall
to cure it. It would narrow down the problem if I can disable or uninstall
just the IFS and check if that is the crucial step.
The device drivers can be disabled in the registry
HKLM\SYSTEM\CurrentControlSet\Services\AFSRedirector
HKLM\SYSTEM\CurrentControlSet\Services\AFSLibrary
The Start parameter determines whether or not (and when) the driver is
loaded. A value of 4 disables the device driver. The service will
switch to SMB mode if the drivers are not available. SMB mode requires
the microsoft loopback adapter be installed.
The service is
HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon
it is also possible that another file system filter installed on the
machine is altering the return code which prevents user account control
from be triggered. however, it sounds like the real problem is that
the explorer shell thinks the volume you are working on is readonly and
therefore decides to hide the UI controls.
The symptoms are a little different from a read-only device. For
example, the delete button is not greyed out, and attempting to delete a
file still brings up the are you sure you want to move this to the
recycle bin prompt (if delete prompts are enabled) before silently
failing. I just checked with a read-only SD card and the behaviour is
different there.
What are the differences in behavior as viewed by SysInternals Process
Monitor?
this would be an explorer shell bug which must be addressed by
Microsoft.
That does seem likely, but how to get them to do so? Tracking down a
more specific cause would probably help. I don't know the best forum/way
to report a Windows bug.
Reporting bugs to Microsoft requires a Professional Support Contract for
the operating system in
Re: [OpenAFS] OpenAFS installation messes up Windows 8 file access control
On 9/23/2013 8:36 PM, Tim Adye wrote:
By several long processes of elimination, I found that afs_shl_ext.dll was
being loaded by a registry key:
[HKEY_CLASSES_ROOT\Folder\shellex\{00021500---C000-0046}]
@={5F820CA1-3DDE-11DB-B2CE-001558092DB5}
which autoruns doesn't know about. If I remove that key, my bug is fixed! I
checked that this key is added as part of the OpenAFS installation and
removing it is all that's needed to fix File Explorer's administrator access
control.
What does this key do? Will it break anything to remove it? I didn't see any
problem, and the OpenAFS icon overlays and context menus seem to work.
This is the registration for the InfoTip handler. When you hover the
pointer over a mount point or symlink an infotip is displayed that shows
the target object.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Re: Naming of backup and up commands
On Mon, 23 Sep 2013, Russ Allbery wrote: Andrew Deason adea...@sinenomine.net writes: Either way, sure, makes sense to me. But the people that actually use those commands really do need to say something, even if it's just yes, sounds good. Yes, indeed. We use the backup suite here at SIPB, and I expect we could cope with a rename without much trouble. I'm pretty sure that 'up' never gained much traction at MIT; I don't remember encountering it in our documentation for how to use AFS. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Moving Magic Trio to another domain
On Mon, 23 Sep 2013 22:06:16 +0300 (EEST) Jukka Tuominen jukka.tuomi...@finndesign.fi wrote: I first tried to dpkg-reconfigure krb server packages so I could introduce the new domain, but it persisted to use the old domain without asking a thing, so I manually replaced all old domains in the .conf with the new one. I was then able to create the new realm. How do I destroy the old realm data? I assume you just delete the kdc files in /var/lib somewhere before recreating the database. But I'm not looking up the details right now, and I don't think I've ever done the procedure you are performing :) I was able to add the new cell princ key, but not the server princ key, as it returned I'm not sure what exactly you're talking about here. There is only one afs/* principal, the cell principal. The afs/cellname principal. cannot specify keysaltlist when not changing key when given the command kadmin.local: ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal afs/[server.name]. But that was my earlier attempt (see a few lines below what I did), so it may be different when I follow your suggestions more closely... This is just what the error message says. Using -norandkey means you extract existing keys into /tmp/afs.keytab, but using -e is for specifying the enctypes for new keys to be written out. It doesn't make sense to use both of them at the same time. You're either extracting existing keys, or you're generating new keys and writing them to /tmp/afs.keytab. And yeah, you probably want to use non-DES for the new principal. I renamed the old /vicepa and was going to create a new one, but I quess I shouldn't have done that but used the existing one as is? Correct. You don't need to recreate any data or databases or whatever for afs, just update some config files. Luckily I can easily restore an earlier snapshot and try it the other way. Unless you changed it, you can just move it back... -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
